Problem solveGet help with specific problems with your technologies, process and projects.

Security in a SIP network: Identifying network attacks

Learn about security in a SIP network and find out how an organization can protect itself from SIP-based VoIP and network attacks. This chapter details the different types of SIP attacks and discusses various security measures and solutions to protect your network.

I agree to TechTarget’s Terms of Use, Privacy Policy, and the transfer of my information to the United States for processing to provide me with relevant information as described in our Privacy Policy.

Please check the box if you want to proceed.

I agree to my information being processed by TechTarget and its Partners to contact me via phone, email, or other means regarding information relevant to my professional interests. I may unsubscribe at any time.

Please check the box if you want to proceed.

By submitting my Email address I confirm that I have read and accepted the Terms of Use and Declaration of Consent.

Learn about security in a SIP network and find out how an organization can protect itself from SIP-based VoIP and network attacks. This chapter details the different types of SIP attacks and discusses various security measures and solutions to protect your network.

Security in the IP network is most certainly the most important part of any implementation for traditional service providers. This is because they have been operating in a highly secure network environment for decades. Today's legacy networks are very mature and highly secure networks, mostly due to the implementations by their operators.

Certainly if you ask operators of the world's leading telephone companies what keeps them up at night, you will quickly find network security at the top of that list. In fact it is security that has kept many companies from quickly embracing IP as a network transport and adopting IP for all their service delivery.

It is very ironic, then, that with security as such a concern, many operators have such lackluster security measures. This includes established VoIP providers who have been victimized more than once by skillful and ingenious hackers and fraudsters. It is not that IP cannot be secured as much as the implementations are weak from a security perspective.

One of the reasons may be that securing a network can be difficult and requires a lot of specialized expertise. Most service providers do not want to accept the expense of hardening the security around their networks, and many more simply do not understand the measures that must be taken to prevent security breaches.

Should operators be concerned about security? According to statistics from both the GSM Association and from the Communications Fraud Control Association (CFCA), absolutely. Both of these organizations show that fraud is on the rise, mostly due to the deployment of IP technologies in the network.

In fact, fraud was on the decline until recently. As operators began deploying more and more VoIP networks, they began to see these networks come under attack by highly organized and well-funded organizations looking for ways to earn profits either by pumping their own traffic over other operators' networks, or by bypassing operators altogether and building their own peer-to-peer networks connecting through the operators' data networks.

These organizations are also highly educated and possess the resources necessary to breach even secure networks, although they would rather focus their efforts on those networks that are just too easy to breach and require little effort or resources.

When you look at the types of breaches being realized, you quickly learn that the attacks could have been prevented through some very simple measures. For example, a young man on the West Coast was sentenced just this year for hacking into thousands of computer systems looking for platforms that still had their default passwords intact.

He would then scan the systems looking for open ports that could be used for pumping his own traffic, or he would open up ports himself. Armed with the IP addresses of the systems he hacked and reconfigured, he worked with his partner (who actually perpetrated the whole business) to sell routes to legitimate telephone companies at cheap rates.

They routed millions of telephone calls through application servers sitting in businesses and universities across the U.S., charging telephone companies for access to their "network" and pocketing millions in profits. The main perpetrator has fled the country and cannot be found.

I bring this incident up as an example of how telephone companies (and in this case even well-established VoIP operators) can be defrauded of millions of dollars by even small operations. The hacker was later quoted as saying how easy it was to break into the computers and systems and change their configurations.

Excerpted with permission from Session Initiation Protocol (SIP): Controlling Convergent Networks, by Travis Russell, Copyright 2008. Published by McGraw-Hill, June 2008. For more information about this book and other titles, please visit McGraw-Hill Professional.

What was the most surprising aspect of this? That established service providers had deployed VoIP servers without changing the factory default passwords! The most rudimentary security measure had been skipped in these networks. In the many lectures I have done on the topic, I am always amazed at how many people do not change their passwords on a regular basis.

But passwords are only one measure. Changing passwords regularly is certainly one way of slowing down hackers and fraudsters, but there are many more measures that should be taken to further protect any SIP network.

Why is it then that we know security is important, and yet no one seems to be concerned about it (or at least not concerned enough to implement robust security measures)? Security can be very inconvenient not only for the operator, but for the subscriber as well.

Types of Network Attacks

There are many different forms of network breaches, but here we will talk about those that occur the most often. In fact, these are the types of attacks that are seen repeatedly not only in VoIP networks, but the Internet as well.

The Internet can serve as an excellent model of what could go wrong given its wide-open nature. Nothing can be trusted in today's Internet, and fraud and Denial of Service (DoS) attacks are rampant. Anyone who spends any time following security alerts and law enforcement activities in this area quickly understands the Internet is a risky place to do business unless you are prepared to lose a large portion of profits to fraudsters.

That is not to say that the Internet is a losing proposition; certainly there are many businesses thriving on the Internet. But they are also losing a lot of money from fraud, and they could be making a lot more if they didn't have to deal with security issues.

A case in point is the current concerns over Web sites and e-commerce. Certainly there have been numerous reports of sites being compromised, sensitive information being stolen from online sites, and consumers attacked with spam and phishing attacks on a regular basis.

Since SIP is a derivative of HTTP and SMTP, both Internet protocols that are exploited on a daily basis, it only makes sense to understand the vulnerabilities these protocols experience today to better understand the potential threats within a SIP implementation. The 3GPP and the IETF are also actively adding new procedures and enhancements to the protocol to further harden the protocol against network attacks.

Let's look at the various types of network issues, how they work, and how they impact the network operator and the subscriber. Then we will look at ways in a SIP network to prevent these attacks from happening (or at least some good measures to decrease the probability of their occurring).

Understanding how hackers approach a network is important to understanding how attacks begin, and what one should look for. Hackers approach attacks in stages, beginning with probing of the network.

Hackers first look for networks with easy access. This means a network with open gateways and platforms with default passwords still in use. They then begin looking for vulnerabilities in those platforms by scanning the platforms. Once a vulnerability is found, it is recorded for later use.

Many security breaches can be found at the scanning stage. In fact, you could use this approach on your personal computer to find possible viruses and bots that are scanning ports for open access (this is done through software utilities that provide information regarding the activities on your computer platform). This is the same technique used for network elements.

There are distinct characteristics to probing activities that you can look for to determine if there is pre-attack activity going on in the network—for example, multiple requests to the same server from the same UA, or maybe many requests from one UA to multiple servers and proxies.

Once a vulnerability has been identified and validated, it is used later for a larger attack. It is a combination of vulnerabilities that allows hackers to reach through many different networks, traverse through all of these networks unnoticed, and launch large-scale DoS attacks on unsuspecting networks.

Here are some common methods used when attacking a SIP-based network.

Registration Hijacking

SIP uses clear text messages, meaning anyone with a computer and some programming knowledge can "tap" into a network and capture SIP messages. This is different from bit-oriented protocols that simply transport "frames" of bits that when grouped into a defined format can be decoded to specific messages and parameters. ISDN and SS7 are good examples of bit-oriented protocols.

Since SIP uses clear text, if a hacker can capture these messages, that hacker is able to read subscribers' sensitive information such as their public and private identities. This information can then be used to "spoof" a subscriber. In other words, the hacker can use this information to gain access into the operator's network for his or her own use.

Let's say a subscriber has registered with the network, and the subscriber's location is recorded by the registrar. All calls and e-mails, instant messages, and any other session traffic are sent to this location.

The hacker then accesses the same network and uses the same subscriber information captured when "sniffing" or "tapping" the network to register with the network. Since the hacker is using the identity of the legitimate subscriber, her or she is granted access. However, the registration from the legitimate subscriber is not changed.

To the network it appears as if the subscriber has changed locations in the network and sent a new registration. The hacker has changed this through his or her own registration with a new location that now gets stored in the registrar. This means that all session traffic for the legitimate subscriber will now be sent to the hacker's destination instead of the subscriber's device.

Now eventually the subscriber will change the registration again while changing locations (provided the subscriber is mobile), but the hacker already has the subscriber's identities and network permissions and is therefore able to use this information to gain network access anytime he or she wishes.

Another means of accomplishing registration hijacking is to capture a subscriber's registration message and then "replay" the same message using a new location. This effectively registers the subscriber with the hacker's location. This is one of the more common means for hijacking registrations.

Session Hijacking

Session hijacking works much like registration hijacking, but this attack is used differently. A session hijacking is used to take over a session in progress. Session hijacking began with the World Wide Web.

A Web server is not a stateful server. A session consists of the UAS accessing a page from the Web server. If a subsequent page is accessed, that comprises another session (or at least new authentication from the user and the Web server). To alleviate the need of authenticating continuously when using a Web site, Web developers created the concept of cookies.

A cookie is nothing more than a data file, usually consisting of the session ID. The Web server sends the browser the cookie when the site is first accessed. The cookie is then sent by the browser application each time it accesses the Web server for another page to identify itself.

This concept was expanded for use with online shopping sites to maintain the shopping cart. When you visit an online site and wish to review your shopping cart, the cookie sends your authentication information so that you don't have to keep typing in your password.

If these cookies are intercepted and copied, they allow the interceptor full access to the session already in progress. This means the hacker now has access to all of your transactions and account information (so long as the session is still in progress). A cookie can be expired when the session is over, or it can be set for longer durations.

Many sites generate cookies using an algorithm that uses the timestamp and the IP address of the user to generate a unique identifier. This is an easy identifier for hackers to guess using random generators. Cookies themselves are somewhat controversial for many reasons, but mostly because they are misunderstood (many believe they are executables rather than data files). The usage of cookies is full of vulnerabilities, however, making them very susceptible to session hijacking, so their use within a SIP network is not highly recommended.

This is especially true if WiFi is going to be the access method into the network. WiFi networks are still very susceptible to eavesdropping, and the use of any clear-text transmissions is risky. Cookies can easily be captured through eavesdropping on access points, which would then compromise network services.

One simple check for hijacking is to check the time and date stamp of an incoming request or response. When a UAS receives a request, it should check the date and time with its own internal clock. If there is a discrepancy (more than 30 minutes, for example), then it is very likely that the request was intercepted and has been replayed with a changed destination address.

This happens when a session is hijacked and the message is captured for replay. The hackers will change the origination address of a message to their own and insert the message back into the network. If they do not update the DATE header, then the message will appear as if it has been traversing the network for some time, which is not normal—a session request that has been traversing the network for a long period of time (30 minutes is a long time) will most likely be deleted, as the interval specified in its MAX-FORWARDS header will have been exceeded.

Impersonating a Server

If you spend any amount of time on the Internet, you will most likely run into this form of security breach. There are many Web sites that look exactly like their official sites but are in fact hacker sites used for stealing information from unsuspecting consumers.

For example, there have been many documented cases where hackers have created sites to look like bank or credit card Web sites, using official logos and modeling the Web site to look exactly like the real Web site. When the subscriber types in the URL for these sites, they get redirected by a redirect server.

The redirect server is compromised by the hacker to send consumers to their Web site rather than the real Web site. Once the consumer has reached this site, they are asked for password information and other sensitive account information. This information is then stored on the server by the hacker and sold on the Internet to other hackers.

Sometimes the hacker will send out e-mails prompting consumers to go to the hacker's Web site to update their accounts or to claim refunds. Again once they reach these sites, they are asked for sensitive account information that can then be used to access the consumers' accounts. There are many breaches of this nature, from text messaging as well as e-mails.

Then of course there is always the possibility of compromising the DNS. This is known as DNS poisoning, where the DNS server is hacked and the IP address for specific servers is changed to a spoofed Web site or address. This is very likely in SIP networks where DNS is used to identify the IP address for domains and their applications.

The damage would be the same in a SIP network as anywhere else. For subscribers to be redirected to rogue application servers could have serious impacts on both the subscriber and the operator.

Tampering with Message Bodies

Since SIP is forwarded in clear text, it is not necessary for someone to have a decoder. Simply capturing the message is good enough, and this is easy to accomplish if one has access to any number of sniffing utilities and is connected to the same network. Once the hacker has captured a message, the message body and the headers in the SIP message can be modified.

For example, a hacker may capture an INVITE from a subscriber and change the FROM header to reflect his or her own address. This would provide the hacker access to a network he or she is not authorized to use, and would allow him or her to initiate sessions with other subscribers while pretending to be someone else.

There are other concerns with message tampering. Since text messaging is sent in a SIP message body and is also in clear text, a hacker could easily intercept SMS messages and change their content. This could be especially troublesome if messages were being sent by government agencies during catastrophic events.

Message tampering can be easily prevented, as can many of the scenarios we talk about in this section through encryption. Encryption prevents the hacker from being able to decipher the text, and therefore the hacker would be unable to change it and route it back to the network.

Tearing Down Sessions

Tearing down sessions is a concern but not as troublesome as a denial of service attack. Hackers could intercept requests from various subscribers and simply send a BYE message as a response (as if it came from a proxy or other network element). This would then terminate the session and cause it to be torn down.

This is more of a nuisance attack and is most likely to be launched against individuals, since it is far easier to launch a DoS attack against the network or network elements, with much more devastating and far-reaching effects.

Denial of Service and Amplification

Denial of service (DoS) attacks can take many different forms and can be launched using many different techniques. The easiest form is simply flooding the network with specific traffic types. For example, using a call generator, a hacker can send millions of INVITEs into the network attempting to flood the network with call requests.

We see these types of attacks take place many times, and they have even occurred in the PSTN. The use of SIP and IP provides much easier access to hackers, enabling these types of attacks much more frequently.

Another form of DoS attack involves application servers. By launching a flood of requests to an application server, the network element is immediately flooded and congested, taking it out of service. This can also happen with the DNS through flooding with DNS queries (similar attacks of this nature have occurred many times already). When the DNS is attacked, the entire network can be impacted, depending on where the server sits within the DNS hierarchy and whether or not redundancy has been implemented.

When redirect servers are used, the potential for amplification occurs. One message is forked into many different messages, which will also result in many different responses. An attack relying on amplification will send many requests toward targets known to be redirected, knowing that those targets will result in the request being multiplied.

As the request is multiplied, it is sent to several different destinations. Each one of those destinations will then send an appropriate response back to the forking proxy. It is not necessary for the responses to be successful responses, since the object is to create a large volume of SIP traffic in the network with the hope that this causes enough congestion to result in a DoS.

Since congestion is the ultimate goal, one request is obviously not enough. Nor is one target sufficient for such an attack. Therefore the attacker will use many targets and millions of requests, and will continue to send these requests until the congestion occurs.

The registrar can also be the target of such an attack. A hacker can register a subscriber listing many different user identities for the same subscription. This then provides the registrar with a list of multiple destinations for a request. The hacker then launches requests toward the public identity, which the registrar and proxies then send to multiple destinations based on the registration made by the hacker.

This is also considered amplification, as the registrar is "amplifying" the effects of the attack by sending to multiple destinations. The impacts are the same as a forking proxy, bearing the same results.

A similar kind of attack toward the registrar involves registering many different identities. Each identity consumes memory within the registrar, and therefore if a large number of registrations take place, the registrar runs out of memory.

This only works in open networks with little to no security where anyone can register and use the services of the network to route requests. Hopefully most networks will prevent this from happening just through simple authentication, preventing unauthorized subscribers from accessing the registrar.

The forking proxy in turn will continue to fork the requests into many requests and will continue to manage many responses from the various targets until it becomes congested (or some upstream network element becomes congested). At any rate, the end result is that the network becomes too congested to handle any further traffic and begins denying service to other subscribers. Some of the network elements may even crash due to the levels of traffic.

Bots and DDOS Attacks

Bots are simple scripts that are carried to a subscriber's device through Web sites, or other viruses transported using text messaging or e-mail. Even Bluetooth is highly susceptible to viruses, and cell phones have fallen victim to these as well.

A bot sits on a device and first looks for any open ports or connections that it can use to access the Internet. The bot then looks for other computers or devices connected to the same network and begins exploiting these systems. This is what makes bots especially dangerous, since they have the ability to self-propagate whenever the device is connected to a network. Even firewalls cannot prevent bots from infecting other computers when an infected computer connects behind the firewall.

But the most troublesome aspect of a bot is the ability to control the script from a remote server. Bots use the Internet Relay Chat (IRC) protocol to communicate with a URL programmed into the script. They then receive commands from a server connected to the URL that basically launches the script. The server is the command and control server.

Many bots are used for accessing Web sites and specific links on those Web sites to increase the number of "hits" to a Web site fraudulently. There are some businesses that make money based on the number of hits to a Web site or Web site link, and therefore the bots inflate the revenues at will.

Bots have now moved on to more menacing and threatening uses, causing DoS attacks in many networks. When one hacker successfully launches bots, they create their own little network of bots known as botnets. All of the scripts are now under the control of one person, which if launched against a target could be devastating for that target.

For example, if the bots were instructed to access the same URL at the same time, millions of machines could be accessing the same Web site simultaneously. This would certainly cause the server to crash because it would not be able to handle such a huge demand. The Web site would then be out of service.

This has happened more than once, causing businesses to close their Web sites for days. The losses quickly ramp up when your Web site, your sole source of revenue, has been attacked and shut down. Imagine now if that Web site was a bank, or a credit card company.

The largest botnet to date was recorded in 2007. Millions of computers were under the command of one botnet. If that botnet were directed to any URL, it would have a devastating effect. Of course, bots affect more than just computers.

Imagine if cell phones were infected with these bots. Already we are seeing cell phones become infected with experimental viruses, propagating through text messages and Bluetooth. If a botnet were to be amassed, the hacker would have millions of cell phones at his or her disposal. Imagine now if all of those cell phones placed a call at the same time to the same destination. That portion of the network would be out of service for an undetermined amount of time.

Even if the bots were instructed to do something as simple as send a text message to a cell phone, the end result would be a lengthy denial of service for that portion of the network. It has already been demonstrated that just a few text messages could be sent to a single cell site resulting in a lengthy outage. Millions of phones sending messages to many phones in a sustained attack could easily cause an entire network to quickly crash.

The effects of such an attack would be crippling. Not only would the operator lose substantial revenues, they would also lose the faith of the subscribers. Of course, if the attack were held in conjunction with a physical attack, the results would be especially devastating.

Fortunately law enforcement agencies have been diligently searching for botnets and have successfully stopped many of them, but they continue to proliferate. It has become more important than ever to prevent unauthorized attacks on your networks and protect the resources from being compromised.

Start the conversation

0 comments

Register

I agree to TechTarget’s Terms of Use, Privacy Policy, and the transfer of my information to the United States for processing to provide me with relevant information as described in our Privacy Policy.

Please check the box if you want to proceed.

I agree to my information being processed by TechTarget and its Partners to contact me via phone, email, or other means regarding information relevant to my professional interests. I may unsubscribe at any time.