HARASSING CALLS AND TELEPHONY DENIAL OF SERVICE (TDOS) - APPLICATION ATTACKS - Praise for Hacking Exposed: Unified communications & VoIP Security Secrets & Solutions, Second Edition (2014)

Praise for Hacking Exposed: Unified communications & VoIP Security Secrets & Solutions, Second Edition (2014)

PART II. APPLICATION ATTACKS

CHAPTER 7. HARASSING CALLS AND TELEPHONY DENIAL OF SERVICE (TDOS)

We are under attack. We are a target. This is serious s***. I am one attack away from being on the cover of Newsweek!

—Top-five U.S. bank executive on the topic of TDoS

A phone or a UC network can be used for nefarious purposes in various ways, especially when directed against an individual or an organization. These ways include harassing, threatening, and disruptive inbound types of calls, which can be manually generated or automated “robocalls.” Here are descriptions of some of the most common call types:

• Harassing calls Prank calls or just annoying calls intended to irritate the victim. This could be from any person, such as an ex-spouse or competitor. These calls are normally manual, but can be automated.

• Threatening calls These include outright threatening calls, such as bomb threats in public places (for example, retail sites or government agencies). These also include SWATting, where the attacker pretends there is an emergency and tricks the authorities into sending the police or SWAT team to the victim’s location. These calls are normally manual, but automation could be used to launch a bomb threat to many locations.

• Telephony denial of service (TDoS) A flood of calls that inadvertently or intentionally denies service to the target. An inadvertent TDoS might be some other attack that happens to generate enough volume to be disruptive. TDoS differs from the other forms of DoS we cover in this book, in that it involves calls rather than various forms of packets at different protocol layers. TDoS is usually automated, but can also be delivered manually by organizing many individuals through social networking. The term TDoS was originally coined by the FBI and first reported in 2010 in several bulletins.1,2

• Call or traffic pumping A fraud attack we covered briefly in Chapter 5. Call pumping involves an attacker generating many inbound calls into contact centers in order to make money delivering 1-800 calls.

• DTMF fuzzing Delivering inbound calls to a contact center Interactive Voice Response (IVR) with DTMF content designed to create a DoS effect.

• Voice SPAM An attack against consumers and enterprise users, where the attacker is trying to sell something. Similar to email SPAM, but delivered over the UC network. Voice SPAM can occur on both TDM and UC networks, so we avoid using the term SPAM over Internet Telephony (SPIT). We cover voice SPAM in Chapter 8.

• Social engineering/Voice phishing (vishing) An attack, normally against consumers and enterprise users, where the attacker is trying to trick the user into calling a number and divulging personal or corporate information. Vishing can also occur by including callback numbers in emails. We cover social engineering and voice phishing in Chapter 9.

Figure 7-1 summarizes these attacks.

Image

Figure 7-1 Forms of harassing calls

Some attacks involve a small number of generally manual but very dangerous calls, which can include generating bomb threats or SWATting calls. Most of the remaining attacks are similar in that they involve numerous unwanted inbound calls. How all of these attacks differ is in their intent, audio content, the volume of calls, the destination numbers, and whether the calls are automated or manually generated.

For some types of harassing calls, such as TDoS and call pumping, the number of calls will be high and the target is usually a specific number or group of numbers. These targets are called repeatedly for extended periods of time to create the denial of service. Enterprise contact centers and 911 centers are easy targets, because a single, well-known number can be used. Audio content for these attacks will vary from harassing content to something that will clog the inbound lines as long as possible in an IVR or contact center. Calls are usually generated automatically, but can also be from many individuals.

Voice SPAM and voice phishing vary in that, although there are often many calls, the call rate per individual is less of an issue and there are many target numbers. The attacker may have a list of targeted numbers, or they may just be marching through every number in an exchange. This chapter will focus on harassing calls, TDoS, and call pumping. We cover voice SPAM in Chapter 8 and social engineering/voice phishing calls in detail in Chapter 9.

The ease with which numerous calls can be generated has also contributed to harassment and TDoS becoming much easier and also more of an issue. Whereas in the old days you had to call your victim over and over, automating harassing calls now does the work for you. Free PBX software such as Asterisk, call-generation programs, and SIP access to the UC network make the process of generating harassing calls quite easy. Automation can turn an annoying or threatening harassing call attack into one that is overwhelming.

Harassing calls and TDoS will become increasingly difficult problems. It will become progressively easier to generate thousands or even tens of thousands of simultaneous calls, thus overwhelming IVRs, contact center agents, 911 centers, and other parts of enterprises. TDoS attacks will become increasingly more sophisticated in terms of DTMF and audio content, making it more difficult to differentiate TDoS from legitimate calls. Attackers will update botnets to be “UC aware” so that it’s easy to generate a massive number of calls from many locations, making it extremely difficult to detect and mitigate the attack. TDoS will become one of the most significant threats to enterprises.

Note
Image

One last point about all of these attacks is that they involve unwanted inbound calls. They can occur in enterprises whether the trunking and PBXs are TDM, the latest SIP trunking and UC, or some mix in between. The attackers don’t care.

Harassing and Threatening Calls

Harassing and threatening calls have been around for a long time. Initially, harassing calls were manually generated from the calling party to the called party. Manual harassing calls still occur, but spoofing the calling number greatly simplifies the ability to obfuscate the calling party. This makes it safer to make harassing calls and creates some new types of attacks. Remember, it is not illegal to manually call someone repeatedly, as long as you do not threaten your target. We cover various types of harassing and threatening calls in the following sections.

Image Manual Harassing Calls

Image

Prank, annoying, and irritating harassing calls have been around for a very long time. For many years these problems improved due to the widespread availability of calling number and Caller ID, where these services allowed the called party to see who was calling before they answered. As we discussed in Chapter 6, it is now trivial to call from an anonymous or spoofed number. If the intent of the call is to annoy or verbally harass the victim, spoofing the calling number can help to trick the victim into answering the call or mask the caller’s identity.

Some callers can be remarkably persistent. However, as mentioned before, as long as the caller doesn’t threaten the victim or affect business operations, making numerous calls is legal. A persistent caller can really irritate their victim, as you may know. Figure 7-2 shows a graph of a persistent harassing caller, who called an enterprise hundreds of times over a several-month period, including almost 100 times in one day. Note that after a two-week period, the majority of the harassing calls were terminated. The graph does not include calls where the calling number was restricted and these calls were also terminated.

Image

Figure 7-2 Persistent harassing caller (does not include Caller ID Restricted, or CIDR)

We won’t spend a lot of time on these types of calls. They aren’t new, and unless you are the victim, they aren’t a big issue for an enterprise. Of course, you can also automatically generate calls to annoy or harass a victim. This is really an automated TDoS attack against the individual or a single number.

Image Manual Harassing Calls Countermeasures

There isn’t a whole lot you can do about manual harassing calls. In the old days, you could just not answer calls from a known harasser. Now, with anonymous calling and calling number spoofing, this isn’t possible.

You can treat (terminate or redirect) the harassing calls if the caller uses the same calling number. You can also treat the calls if the caller blocks or restricts their calling number. Some callers will use a predictable pattern, perhaps from the same country, area code, or exchange.

Of course, you can change your number if the calls get really bad. But even this countermeasure won’t protect you if the harassing caller gets your new number.

The key to addressing all of the attacks in this chapter is to have visibility and fine-grained control over all inbound call traffic. This can be performed to some degree with some IP PBXs and other UC systems; however, most of these systems only offer limited capability. Most large enterprises have a mixture of these systems, so any countermeasure must be repeated across all systems, usually in a different way. The trunking into most enterprises remains TDM, with a growing amount of SIP. Session Border Controllers (SBCs) can provide some protection, but do not operate at the application layer where they are monitoring for malicious calls. Of course, SBCs do not operate on TDM networks. SecureLogix (www.secureogix.com) provides application-layer security products for TDM and SIP networks and can be used to detect harassing calls. TrustID (www.trustid.com) provides solutions that detect spoofed calling numbers. The TrustID calling number authentication and spoofing service is also integrated with SecureLogix products.

Image Threatening/SWATting Calls

Image

Bomb and other dangerous threats are a specific type of harassing calls. These can be very disruptive, because most organizations that are open to the public have a policy of evacuating the building, school, office, or retail site when they receive a threat. Many threats into retail sites are simply current employees trying to get a day off or embittered former employees trying to create disruption. These attacks occur more often than you think, even though it is usually easy to recognize the caller’s voice. Certainly anonymous calling and calling number spoofing services make this attack easier. Aside from the disruptive and financial impact of bomb threats, the chaos that can follow can also create physical harm to individuals.

SWATting is a fairly well-known and dangerous offense where the attacker calls an emergency service such as 911 and fakes an emergency. In turn, the authorities arrive, often in full force, expecting to deal with a dangerous situation such as a murder or a hostage situation. This is a nasty attack that we will only give a brief mention of because it can definitely result in physical harm to an individual. The term SWATting comes from the idea that the call results in the authority’s Special Weapons And Tactics (SWAT) team arriving at the victim’s location, ready to deal aggressively with the situation.

SWATting is not a new issue, but the ability to spoof one’s calling number makes the attack more effective and anonymous. There are many well-known cases where both normal individuals and celebrities were SWATted. As an example, in March 2013, Brian Krebs, a well-known security and cybercrime expert, experienced both a DoS attack against his website and had 10 armed police officers show up at his residence after a SWATting attack. See “The World Has No Room for Cowards”3 for more information.

It has become easy to disguise your voice for these sorts of attacks. Some of the calling number spoofing services also allow you to disguise your voice. Again, one of the oldest and best is SpoofCard (www.spoofcard.com). As mentioned before, SpoofCard even lets you use their service for free. Now, they might record the numbers you’ve used, but as long as you call from some phone other than your own, they won’t have a record. We tested this and used the “female” voice changer. As expected, the call was delivered with the spoofed calling number. We left a voicemail message and the resulting audio was easily understood, and you could not tell that it was our voice. Perhaps it could be determined with some detailed audio analysis, but this is likely beyond the capability of the target.

Many free tools are available that convert text to speech. Simply type text to speech into Google and you will find more than you could ever try. Virtually all of these sound good enough to create an understandable message, with a male or female voice, and different accents, to sound like a specific type of person. All you need to do is call up the victim, run one of these applications/demos, type in the desired text, and let your system play it into a microphone. You can do all of this from one computer if you are using a softphone. Figure 7-3 shows one sample text-to-speech capability.

Image

Figure 7-3 Text-to-speech website

Any effective manual attack can be made worse by calling multiple locations. For example, you could gather the phone numbers of all of the locations of a major retailer in your area. You could call all of these, one by one, and make a bomb threat. This attack could be even more disruptive if automation were used to make the calls. Of course, if you make too many calls, the target will likely realize it is a hoax and cease to take the threat seriously. We will cover how to automate such an attack later in the “Automated TDoS Attack” section.

Image Commercial Robocall Services

Image

One way to automate the generation of threatening calls is to use one of the many commercial robocall services. If you type robocalls into Google, you will get a long list of companies that are in the business of generating robocalls. Most of these companies appear to be legitimate and are focused on generating legitimate political messages, advertisements, and reverse 911 messages. However, these services can also be used to generate harassing and threatening calls. The services are also suited to generating voice SPAM and voice phishing, which we will cover in Chapters 8and 9. These services are not free—they charge around $.02 to $.10 a call, so they would get expensive for a large voice SPAM, voice phishing, or TDoS attack.

The robocall services we reviewed all state that they are only to be used for legitimate purposes. We have to believe that if you tried to use one and targeted 911 services, they would block your call. We also assume that if you tried to generate a threatening call, such as a bomb threat, this would be detected. However, we have not confirmed this and did not want to upset any of the companies trying to prove that they would not detect it.

One of the coolest features about some of the services is the free trial. Several of these robocall services offer free trials, and at least one of which lets you test the service completely anonymously through their website. Call-Em-All (www.callemall.com) seems like a legitimate, well-designed service that allows you to set up a test with up to 25 free calls. The test process is well designed and easy to use. You create an account, decide between voice calls or text messages, set the calling number, set the numbers to dial, set the time to dial, and provide the audio message to be used. The audio message definition process is very easy—all you do is call a number and record a message. The whole process only takes a few minutes. Figure 7-4 shows the setup screen.

Image

Figure 7-4 Call-Em-All setup screen

We tested Call-Em-All and it works great. We configured it to call 25 of our enterprise direct inward dial (DID) numbers. Sure enough, we received 25 calls and had 25 voicemails. The voicemails were recorded correctly in that they were not clipped, which means the service is smart enough to wait for the voicemail system to be ready to record the message.

You can use a service like this to anonymously generate harassing and threatening calling campaigns. The process is quick and completely anonymous. Again, we would expect that if you generated a truly threatening audio message or tried to send calls to an obviously off-limits number such as 911, this service (and others) would detect that attack. However, this detection capability will probably vary with the different services. We also briefly cover these robocalls services in Chapters 8 and 9, when we cover voice SPAM and voice phishing. These services could possibly be used for these types of attacks.

Image Manual Harassing/Threatening Calls Countermeasures

If you receive a threatening call, such as a bomb threat, it is best to report it to both the authorities as well as your service provider. If the threat is serious, they should attempt to trace it back to the source. Of course, if the attacker is clever and is using a service or a softphone and Wi-Fi hotspot, it will be very difficult to trace them to their source.

One of the best countermeasures is to record calls on your public numbers (the ones likely to have a threatening call). This ensures you will have everything recorded about the attack. Depending on the state you live in, recording calls requires one- or two-party consent, so you may need to warn callers that their calls may be monitored. If you are running a contact center, you are probably already recording calls, at least for the call center agents because IVR calls are normally not recorded.

Note
Image

Just playing an announcement that the call will be recorded will deter some attackers. It will often deter an attacker whose voice would be recognized. Just playing an announcement, but not actually recording, may be a legal issue. In any case, be sure you work with your legal staff before you start to record calls. Also, you don’t have to archive recorded calls for very long—just long enough to make sure you capture an attack, which is usually no more than a few days’ worth of data. There are many call-recording solutions available.

SWATting is illegal and a misdemeanor or even a felony in some municipalities. This is one attack that authorities will take very seriously and will do their best to track down the attacker. Remember, 911 centers record all calls, which may be useful in tracking down or convicting the attacker. They can also adopt procedures, such as attempting to call the victim back, as a countermeasure to calls from spoofed calling numbers. If the real victim is at the location of the calling number, they can let the authorities know that the attack was a hoax.

The same solutions discussed in the previous section, including some IP PBXs, SBCs for SIP trunks, and application firewalls, can be used to record all details for a bomb threat or SWATting attack.

Social Networking TDoS

One way to generate a TDoS attack is to organize a large group of individuals into calling a target all at once. In the past, organizing large groups of people into calling a targeted number would be difficult and impractical. Now with social networking, it is much easier. Socially organized harassing call attacks have leveraged sites such as Facebook and Twitter. In this case, an attacker or disgruntled individual “organizes” a large group of people, all of whom call over and over, to a group of numbers. If enough calls can be generated, TDoS occurs.

Attacks of this type were first seen in 2011, when Facebook was used to coordinate large numbers of individuals to take particular actions, usually as protest movements, the “Occupy” movements, and in some instances the London riots. These “organized complaints” groups have long used call flooding as a means to have a social impact for their issues. Social networking has made this activity much easier to organize. This method is effective because it is easy to set up, easy to set up the target, and is not illegal for individuals to be making the calls. As with any TDoS attack, the participation rate can be relatively low, but as long as it is enough to overwhelm an individual or small part of an enterprise, the attack can be very effective. Figure 7-5 illustrates this type of attack.

Image

Figure 7-5 Social network TDoS

Anyone can anonymously create Facebook pages that incite, educate, and organize a group of individuals to flood an enterprise with calls. Also, a careless celebrity with many Twitter followers can tweet and start a calling campaign, whether intentional or not. A hacked Twitter account of a celebrity or company can be used for the same purpose. We will continue to see these low-tech attacks grow due to the popularity of social networking sites.

Note
Image

Social networking TDoS is arguably less disruptive than automated TDoS (covered in the next section) because it is a little more challenging to sustain the attack. The individuals will usually give up calling after a period of time.

Image Social Networking TDoS with Facebook

Image

A Facebook page can be quickly set up to coordinate a large group of people in flooding an “unpopular” enterprise. The Facebook page can provide the reason, the numbers to call, and the time the calls should be placed. Although neither high tech nor UC specific, these are nonetheless significant threats to enterprise voice systems. Figure 7-6 shows some examples of real Facebook pages used to create calling campaigns.

Image

Figure 7-6 Social networking examples on Facebook

In one example, the attack was organized on Facebook, with the date, time of the attack, the list of numbers to target. Many targets will be local numbers or 1-800 numbers, so there will be no calling charge. Instructions were given to keep agents on the phone as long as possible. If enough calls are generated, the result can move from harassment to TDoS. The impact also depends on the target’s capacity. If calls are generated to a few key individuals or relatively small contact center, the result can be a TDoS condition. If enough callers participate, an impact to even large contact centers can occur.

The duration of an attack will vary, but even if a Facebook page is taken down, persistent users can still continue to call. Facebook will take down a specific page if notified, but there aren’t automated tools to search for these kinds of things. Unfortunately, these attacks are yet another thing for security people to worry about and monitor.

Image Social Networking TDoS with Twitter

Image

Any individual with many followers can use Twitter to generate a TDoS attack. The individual needs simply to generate a tweet or set of tweets, encouraging followers to all call a selected number at a designated time. The tweet could encourage the followers to call over and over, increasing the disruption.

One real-world example is when the rapper “The Game” requested on Twitter that followers call the Los Angeles County Sherriff’s Office. More than 580,000 people received the message and generated a call volume that ended up shutting down both administrative and emergency services. See Figure 7-7 for an article summarizing this attack. See “Rapper The Game May Face Charges Tied to Flash Mob Calls”4 for a link to the full article.

Image

Figure 7-7 Sample Twitter attack

This attack is available to any user of Twitter and gets more effective as the number of followers increase. As of the writing of this book, Justin Bieber held the top spot with over 42,255,966 followers. Imagine what would happen if an account like his was used to organize a calling campaign? Even a take rate of 1 percent would result in 422,559 users making calls. If the participants continued to call for a while, this volume would overwhelm any contact center or enterprise in the world.

Twitter is approaching thousands of users who have over a million followers. There are many thousands of users with over 10,000 followers. The bottom line is that many Twitter users have the power to generate a TDoS attack, whether intentionally or accidently. Figure 7-8 shows a brief list of some of the Twitter users with the most followers.

Image

Figure 7-8 Twitter users with the most followers

Accidental social networking TDoS attacks can happen as well. We saw a case where a celebrity in the United Kingdom generated a tweet promising concert tickets to the first set of callers. However, they “fat fingered” one digit in the destination number, which happened to be the number of a local law enforcement individual. This individual was inundated with calls from teenagers looking for concert tickets.

A related attack occurs if one of these Twitter accounts is compromised. If an attacker gains access to an account with many followers, they can generate a tweet that incites the followers into executing a TDoS attack. The attacker could also trick users by promising some sort of merchandise or “promotion,” such as concert tickets, if they call a specific number. This type of attack could be very disruptive. Although individual followers would quickly give up because so many followers will be calling in, the target system could be disrupted for an extended period of time. Followers will continue to call in as long as they get busy signals. A clever attacker would also change the password on the Twitter account so the legitimate owner could not remove or invalidate the original tweet. Twitter would certainly respond quickly, but not quickly enough to avoid some disruption at the target.

A final type of attack is to create a fake account that imitates that of a known celebrity. It is amazing how quickly a fake account can gather followers. Although such an account probably can’t assemble millions of followers, it is certainly possible to gather as many as 100,000 followers. Once such an account is set up, the attacker can generate the TDoS set of tweets as described previously. See “Fake Pope Twitter Account Gains More Than 100,000 Followers,”5 describing how an individual imitated the new pope to gather over 100,000 followers in a brief period of time.

Image Social Networking TDoS Countermeasures

These social networking TDoS attacks are difficult to detect and mitigate. The attacking calls need to be quickly detected and terminated to ensure bandwidth is available for legitimate users. The best location in the UC network to deal with these attacks is on the ingress trunks. This prevents an attack from affecting downstream systems, while also saturating the inbound trunks.

A typical user making calls will not have the capability to spoof their calling number, so most of the calls will have real numbers. However, with so many individuals and calling numbers participating in the attack, it isn’t practical to try to add these numbers to a static blacklist. Of course, you would not know beforehand which numbers would be calling in.

Some attacks recommended the callers block or restrict their calling number, which actually works in the favor of the enterprise because they can start blocking these calls—but at the risk of blocking a call from a legitimate user who also happens to block/restrict their calling number.

The same solutions discussed in the previous section, including some IP PBXs, SBCs for SIP trunks, and application firewalls, can be used to provide protection against these attacks. Because this is a TDoS attack, the mitigation needs to involve determining which calls are part of the attack and quickly terminating them to provide bandwidth for legitimate callers. IP PBXs can be used to block calls from specific numbers, but rapidly adding new attack numbers isn’t practical. Plus, you have the challenge of performing this on multiple IP PBXs. SBCs can be used to provide some mitigation, but they have the same challenge and are only useful if you have SIP trunks. Application firewalls (such as one from SecureLogix) can dynamically track attacks from new numbers and terminate the attack calls. This can be performed on both TDM and SIP networks.

Automated TDoS

Automated TDoS occurs when an attacker automatically generates so many calls that the target system is overwhelmed or significantly disrupted. Automated TDoS has the same intent and targets as social networking TDoS, but the calls are automatically generated, rather than originating from many individuals. The ability to automatically generate calls (robocalls) has been made easy with SIP trunks and tools such as the free Asterisk PBX and call-generation software. Right now it is easy to set up an automatic calling operation and generate a large amount of traffic. Figure 7-9 illustrates an automated TDoS attack.

Image

Figure 7-9 Automated TDoS attack

Automated TDoS is similar to other DoS and DDoS attacks in that the goal is to generate packets and consume so much bandwidth or resources on the target system that legitimate users have difficulty gaining access or can’t get access at all. Automated TDoS differs from all other types of DoS that we cover in this book in that the item of attack is a fully setup call, whereas other forms of DoS typically involve malicious packets, such as TCP SYN floods, UDP floods, SIP INVITE floods, or SIP REGISTER storms. With automated TDoS, an attacker simply needs a cheap or free way to introduce calls into the network. Determining the target numbers is easy because the target is often a 1-800 contact center or even possibly 911 (which is a very reckless attack). The 1-800 numbers can be easily found on the target’s website and don’t require any scanning or IP addresses.

Image Automated TDoS Attack

Image

Automated TDoS is arguably the most disruptive and likely type of UC-based DoS attack, although in this book we will cover various fuzzing and packet-based attacks. Obviously, if you have internal network access and know about a critical system vulnerability and/or have tons of bandwidth between you and your target, you can create a lot of havoc. One thing about TDoS attacks is that they are the only way you can execute a DoS attack against a UC system from the untrusted telephone network. The public voice network still has a lot of TDM and built-in security, so even if the target uses SIP trunks and the latest UC hardware, it would be all but impossible to generate an INVITE flood or send a malformed SIP packet across the network to the target. You can, however, generate TDoS calls and achieve the same effect. Another benefit is that you can target any enterprise, whether it uses TDM or SIP trunks. From an attack point of view, you really don’t care how the malicious calls arrive at the target.

As with any DoS attack, the intent is to affect the most critical or limited resource as aggressively as possible. This, in some cases, might be the trunk capacity at the enterprise. If you can overwhelm the trunk, then you will affect the overall call-processing capacity of the target. However, even if you can’t overwhelm the organization’s trunks with calls, you may be able to focus on a specific target, such as the premium service part of a contract center that supports high-net-worth individuals. If you generate a flood against the relevant 1-800 number(s), you can deny service to an important part of the enterprise’s customer base.

To execute an automated TDoS attack, you need to prepare the following five things:

• Access You need VoIP or SIP access to the public voice network so you can cheaply or freely generate calls.

• Targets You need to determine the phone numbers to target. This is easy, because the target is often a 1-800 number or even 911.

• Audio file(s) You need some sort of audio content that maximizes time in the target and increases the difficulty of differentiating good from bad calls.

• Call generator You need a way to generate lots of calls, which is easy with tools such as Asterisk and a call generator, which we cover later in this chapter.

• Attack time You need to decide when to execute your attack because this determines how effective it will be.

Finally, you have to execute the attack. We cover each of the five steps and follow up with a case study of a real-world TDoS attack.

SIP Trunking

SIP trunks have made gaining access to the public voice network to generate enough calls for a TDoS attack much easier, and there are many ways to generate calls into the network. Unfortunately, the public voice network is not the Internet just yet. You can’t create a flood of SIP INVITEs toward your target because the public voice network isn’t IP all the way. In fact, odds are that the target will still be using TDM trunking. To be able to place your calls into the public voice network, you will need to find a way to originate SIP calls from your attacking platform into the network and let it handle getting the calls to the target, which will probably mean traversing multiple TDM and SIP networks.

How effective this attack will be also depends on the target—obviously, it is easier to flood a target with 100-session capacity versus one with a 10,000-session capacity. However, if you can generate enough calls to crowd out even a small percentage of legitimate traffic, you will have an impact. This is especially true for TDM targets, because TDM has a fixed bandwidth/number of channels, and you can’t just turn up more capacity without adding physical circuits. As the ability to generate more traffic increases—and it certainly will get easier as this book ages—the likelihood of generating enough calls to completely disrupt your target will be possible. Even a very large enterprise or contact center with a call capacity in excess of 10,000 concurrent call capacity will be at risk. Let’s start by discussing some of the possible sources we could use to generate the TDoS calls:

• Internet-based SIP access If you Google “SIP trunks,” you will find that there are many sources of SIP trunks and ways of generating SIP-based calls over the Internet. These services are not free yet, but they are cheap and getting cheaper. By the time you read this book, there may be some free ones. You can use one or more of these services to generate an attack.

• Service provider You can also scan the Internet for vulnerable SIP services that you could use to generate traffic. If you were able to gain access to a service provider’s private network, you could generate calls for free. An insider could do this as well. A service provider would likely be able to quickly detect the increase in traffic, but perhaps not quickly enough to prevent the attack from affecting the enterprise target. We discussed an Internet-wide scan for SIP servers in the case study for this part of the book. We believe the scan was primarily intended for service provider SIP servers that could be used for attacks such as TDoS.

• Compromised enterprise As we discussed for toll fraud, you can run a call generator inside an enterprise, directly on SIP trunks or through a VoIP gateway to TDM trunk. A large enterprise could have a significant amount of capacity available for outbound calls. You could even generate outbound calls, which are routed back to the enterprise by dialing their own DIDs. Granted, the enterprise should detect heavy use of their outbound trunks, but again, perhaps not quickly enough to prevent the attack from affecting the target.

• Commercial calling services We mentioned commercial calling services earlier in the chapter. These services are really designed more for managing calls going to many different users, but you could perhaps use one of these services for some small-scale TDoS.

• TDoS services There are even TDoS services set up and ready to go, just waiting for payment. See the “DDoS Crooks: Do You Want Us to Blitz Those Phone Lines Too?”,6 an article describing such a service.

Obviously, an attack that can leverage multiple sources will have a higher likelihood of causing disruption and also be more difficult to shut down. For example, an attack that uses two or more SIP trunks would be more effective than an attack from a single source. Figure 7-10 illustrates an attack using multiple sources.

Image

Figure 7-10 TDoS attack from multiple sources

For most of these attacks, you will need sufficient Internet bandwidth to handle the calls you are generating. If bandwidth is limited, you could try to execute an attack without generating audio. You can also use codecs, such as G.729, that consume less bandwidth. Most homes have access to a high-speed Internet connection. Most public Wi-Fi access points have enough bandwidth available to generate perhaps 50 to 100 calls.

TDoS can also leverage the concepts from traditional DDoS, with a botnet being used to generate traffic from many sources. We won’t cover botnets here (you can find a lot of material out there describing them). This type of attack requires distribution of a piece of malware to hundreds or even thousands of PCs, all of which need the ability to generate SIP calls. This attack can also be quite disruptive because it comes from many origination points and will be very difficult for a service provider to effectively shut down. The piece of malware would be a piece of code from any free softphone or a SIP call generator such as SIPp. The attacker would strip off any GUI and other unnecessary code and embed it in the malware. This will get even easier with technologies such as WebRTC, where the ability to make calls will be built into every browser. We cover WebRTC in Chapter 17. Figure 7-11 illustrates a distributed TDoS attack.

Image

Figure 7-11 Distributed TDoS attack from a botnet

Again, the effectiveness of such an attack depends on the amount of traffic generated and the bandwidth of the target. Enterprises, especially contact centers, size their capacity for worst-case scenarios and the busiest times, so a lot of traffic is needed to overwhelm them. Later, we will cover timing an attack when it will be the most disruptive.

Getting Target Numbers

TDoS can affect and be targeted at any enterprise or any part of an enterprise. As we have discussed, contact centers are a common target and are very easy to gather destination numbers for because they are often widely published. In Chapter 2, we showed how easy it is to get 1-800 numbers for contact centers, in banking, finance, insurance, and just about every service-related industry. Just go to your target’s web page, and you’ll see that they are prominently displayed. You can also type the name of the target and 1-800 into Google, and you will find all you need. You can also find contact numbers on the back of credit cards. They can be found wherever you look.

If you are targeting an individual, you probably already have their numbers. You can also target executives, government officials, and even fax machines. Fax machines are an interesting target. Generally, an enterprise does not have that many fax machines/servers, but they can be very critical to operations, especially for financial services enterprises. You can find these by scanning an enterprise’s number range using tools such as WarVOX. For the TDoS attack, you don’t have to send faxes to these systems but instead can just make voice calls, which will keep the fax busy for a while. You could also build an audio file that plays a fax negotiation.

It is also fairly easy to get a set of numbers or DIDs for an enterprise. Varying the target numbers may make the attack a little more difficult for a service provider to detect, unlike someone making thousands of calls to a single 1-800 number.

Tip
Image

We covered this in Chapter 2, but for convenience, you can use the following Google search terms to find phone numbers for your target enterprise. The first term finds all phone numbers, whereas the second finds numbers for a specific area code: 111..999-1000..9999 site:www.example.com 210 111..999-1000..9999 site:www.example.com

If you are targeting a large enterprise, once you figure out the area code and exchange, you can generally figure out the DID range by reviewing the numbers returned by the searches. Some enterprises may have an entire range of DIDs within an exchange. Keep in mind that if you want to make 1,000 concurrent calls, you really don’t need 1,000 numbers because many phones have multiple lines. You won’t usually get a busy signal but instead will get transferred to voicemail, so not only are you consuming a trunk session or channel as well as IP PBX resources, but you may also be overwhelming voicemail.

Targets also include 911, emergency rooms, and Intensive Care Units (ICUs). In March 2013 there were reports of attackers calling the administrative parts of 911 centers and threatening automated TDoS attacks if the center did not pay. The same attackers also called emergency rooms and ICUs. When the target did not pay, they would become the victim of a sustained TDoS attack. See the “References” section for more information on this attack.7,8,9 See the case study at the start of this part of the book for a description of the “Payday Loan SCAM.”

Audio Content

It is possible to generate a TDoS attack without ever generating any audio. This is easier, but will also make the attack less effective, because the service provider may disconnect the call. What’s more, it makes it easier for the target to detect the attack.

TDoS attacks can use many different audio files that include simple audio content such as white noise or silence (often dismissed as a technical problem), foreign language audio representing a confused user, and repeated DTMF patterns (which attempt to cause calls to dwell in IVRs). You can also use random audio, such as music or other files, and mutate the audio. If you change the calling number for every call, any detection and mitigation system must examine the audio to detect the TDoS calls. Changing the calling number every time along with the audio files will make it difficult for the target to detect and mitigate the attack.

Note
Image

We refer to dual-tone multifrequency (DTMF) many times in this chapter and the book. DTMF is a series of tones used to represent numeric digits and alphabetic characters (the alphabetic characters have been all but dropped from modern keypads). DTMF is used to signal information such as the destination number; you use a keypad and DTMF to indicate the number. DTMF is also used to interact with IVRs by selecting items from menus, entering information such as account numbers, and so on. DTMF can be transmitted through the network in-band in the audio as the actual tones and is also converted to digital values for UC, which can be present in RTP according to RFC 2833 or as messages in SIP itself.

We talk about call pumping later in this chapter. This is the process of performing fraud by making 1-800 calls into an IVR. Call pumping is designed not to be noticed, so the attacker does not want to generate too many calls or have a call come out of the IVR and be sent to an agent. DTMF patterns or audio such as “main menu” can be used to dwell in the IVR. For TDoS, the same DTMF and audio can be used to dwell as long as possible in the IVR, consuming resources, preventing consumers from gaining service, and preventing them from ever getting to an agent. An example we have seen used in a real-world attack involves simply playing an “8” every few seconds, which causes the call to endlessly loop back to the main menu. Some IVRs may require a more complex pattern, but this can be easily determined by listening to the IVR to plan the attack. The trick here is to subtly change the content and timing between digits to make it more difficult for any system to detect the TDoS calls.

If the target is the contact center agents, another audio pattern would be to move through the IVR as quickly as possible by playing DTMF or the appropriate audio phrase (such as “I would like to speak to an agent”) and then playing some sort of audio to take up the agent’s time. Again, good candidates are white noise, silence, a long-winded introduction and request for information, and faked audio problems. This attack can be very disruptive because some contact centers assume the majority of calls can be handled by the IVR and have more capacity in it than with agents.

Another effective use of audio is to simply play random content for each call. For example, play a random song from a music library for each call. Coupled with calling number spoofing, this will make detection and mitigation very difficult.

For calls into enterprise DIDs, the audio content really does not matter. Users will normally quickly hang up when they realize the call is not legitimate or let it go to voicemail when they do not recognize the calling number displayed on their phone. Voicemail systems normally have a limited number of calls that they can record, so it is possible to consume this resource as well.

Call Generation

The actual call generation for a TDoS attack is straightforward. We recommend you use the Asterisk (or a variant like Trixbox) IP PBX and a call generator. You can also use load generation and testing software such as SIPp, but this has less flexibility. Asterisk is not only powerful, but is also efficient and can be run on a variety of hardware platforms. We could cover other tools, but Asterisk is so well known and effective, there really isn’t much point. We cover the details of how to use Asterisk and a call generator named “spitter” in the forthcoming attack demonstration.

Attack Timing

A well-timed attack won’t be at night—it will be at the busiest time of the day or over a period when seasonality increases traffic. Some enterprises have much more call traffic at certain times of the year. Here are some simple examples:

• Retail sites are busy over the holiday season.

• Government organizations such as the IRS are busy during tax season.

• Insurance companies are busy during and after disasters.

• For banking and finance, home loan activity goes up and down. However, credit card activity is high over the holidays.

• At any time 911 and 311 are dangerous targets. They are more vulnerable at night, during poor weather, and so on.

TDoS Attack Demonstration

Here, we cover a TDoS attack demonstration to step through the process of executing the attack. We launch a TDoS attack against our company, SecureLogix. We recognize that our company is small and our UC infrastructure only has one PRI (23 channels) and a handful of analog trunks. Therefore, we are easier to flood than a huge contact center, but this shows the process, which could be expanded for a larger target.

We follow the process described earlier, identifying SIP trunks for network access, selecting target numbers, selecting the audio content to deliver, setting up Asterisk and spitter to generate the calls, and then picking a time to run the attack.

SIP Trunking

First, we need a SIP trunk from which to make these calls into the public voice network. Numerous providers are identified by Google or listed on the VoIP-Info.org site (www.voip-info.org/wiki/view/Sip+Trunking+Providers) and at the VoIP Provider List (www.voipproviderslist.com), as shown in Figures 7-12 and 7-13, respectively. The rates for SIP trunks vary significantly; you should be able to find one that provides 2,000–2,500 outbound minutes for $15–$50 after looking around. There are also services that have pay-as-you-go rates that charge by the minute, if that is more suitable to your needs. We used Teliax, RapidVox, and 1-VoIP for this case study and were quite satisfied with the results.

Image

Figure 7-13 VoIP Providers List

Image

Figure 7-12 VoIP-info.org results

When researching your SIP trunk provider, check the acceptable use policies and make sure that there aren’t any limits placed on the maximum outbound concurrent calls. If there are limits, make sure they will not inhibit your ability to place the number of calls you need. We discuss the attacks in more detail in a moment.

Most SIP trunk providers will have instructions on their website describing how to configure Asterisk to connect to your new SIP trunk. If you can’t find instructions on the SIP trunk provider’s website, multiple websites are available that describe the trunk-configuration process in as much or as little detail as you need to allow you to start placing calls. We were able to find the information we needed to connect our SIP trunk using a combination of the FAQs on the provider’s website. Also see the “References” section for details on setting up a SIP trunk,10,11 one of which is shown in Figure 7-14 as an example.

Image

Figure 7-14 How to set up a SIP trunk

Getting Target Numbers

The next step is to identify the target numbers to call. We built the list of numbers like we were an external attacker. We went to the SecureLogix corporate website and went to the “Contact” page shown in Figure 7-15.

Image

Figure 7-15 Getting ideas for numbers from a web page

We first gathered our main number right from the top of the page. We could have been nastier and called our 1-800 number or our customer support line, but chose not to. Our main number provides an announcement that allows the caller to select an extension to dial or search the company directory. This announcement loops forever, so any call to this number stays up as long as the caller desires. Multiple calls can also be placed to this number, enough to saturate our ISDN PRI trunk.

Second, we created a list of 25 DIDs, which is enough target numbers for 25 concurrent calls, again enough to saturate the ISDN PRI trunk. We could have generated calls against all the numbers on the page (14 of our salespeople). Rather, if you look closely, you will see that most of the numbers are scattered across the country, while several share an area code and exchange. Turns out all of our numbers at our corporate headquarters are in and around these numbers. We used this information to tweak the search string mentioned earlier for Google:

210 546-1000..1133 site:www.securelogix.com

This search returned the same “Contact” page and also a couple of other numbers, also in the “(210) 546” exchange. The “Contact” page and search did not give us a perfect list of numbers, but we have an idea of the range of extensions. We used Warvox to scan each number in the range of (210) 546-1000 to (210) 546-1133. We then called to select the specific extensions. We did this at night and it was easy to tell from the voicemail prompts which numbers we could use. We quickly built a list of 25 DIDs to call. This would obviously take longer for a larger enterprise, but you could automate it and the list doesn’t have to be perfect anyway.

Audio Content

For audio content, we were not too particular and we simply created a .wav file that was 10 minutes long, which is long enough to occupy a trunk channel for the file’s duration while a long voicemail is being recorded. The length of the audio is important because if it is too short, when the TDoS attack is in progress, if another TDoS call can’t grab a trunk channel, this provides a chance for a legitimate call to get in.

Call Generation

As discussed, Asterisk is the de facto open-source IP PBX. There are several ways to install Asterisk; some of these ways, such as using AsteriskNow or Trixbox, come as a bootable DVD ISO image and can be installed on any computer by simply booting up the system with the ISO in the ROM drive and following the prompts. Both AsteriskNow and Trixbox come with web-based administrative GUIs, thus further simplifying configuration and use of the underlying Asterisk IP PBX.

You will need an attacking system to generate calls. Keep in mind the platform you install Asterisk on may limit your ability to place calls. Although Asterisk can run on many different kinds of platforms, with a wide variety of resources, installing on an older system with a slower processor and limited RAM can inhibit your ability to generate larger call volumes.

ImageOnce you have Asterisk up and running and communicating with a SIP trunk, you will need a TDoS tool capable of generating call files. Several tools are available for this, written in C, Python, Java, and shell script. We used spitter, which is available at the SecureLogix website (www.securelogix.com) and on our companion website (www.voipsecurityblog.com), and a shell script called generateCalls.sh, written by Sam Rausch and available on the VoIP-Info site.12 Both of the tools require some modification to get them to work correctly. In the “References,” we included other references to other tools and techniques using Asterisk for call generation and TDoS.13,14,15

Each tool generates “.call” files that are placed in Asterisk’s spooling directory, which Asterisk uses to generate a call. The number of calls that can be generated at one time depends on several factors, including the horsepower of the platform on which Asterisk is installed, the maximum number of concurrent calls the SIP trunk is either configured for or can handle, and how fast the tool places the call files in the spooling directory. Both spitter and generateCalls.sh allow the user to limit the number of calls placed in the spooling directory in order for Asterisk to throttle the attack as needed.

The .call files tell Asterisk how to place calls. The spitter tool requires the user to generate their own .call files for the attack to be successful. Here is a small portion of one of the attack .call files for four calls:

Image

You can see that the Channel line notes from which trunks the call is routed and what number will be dialed. The CallerID line shows what number will appear when calling the target. You can obviously get more creative with this value. The MaxRetries value shows how many times Asterisk will try to call if the call is busy. The RetryTime value is the time to wait between call attempts. The WaitTime value is the number of seconds the system will wait for a call to be answered. The Context value tells Asterisk which item to use in the dial plan. Finally, the Set value allows you to set channel variables, which, in this case, is the .wav file that will be played when the call is answered.

Asterisk dial plans are very flexible. One of the great things about this flexibility is that they allow the user the ability to modify the dial plan so it has the maximum effect on the targeted enterprise. This includes the ability to wait a specific period of time for a call to be answered, play a .wav file, and then terminate the call. Knowing all of this is important when considering your target. Here is the autodialer dial plan we found on the VoIP-Info website and then modified for the targeted phone system:

Image

You can see that this dial plan allows for the outbound call to connect to the trunk, wait for the called party to answer, wait another five seconds, play the attack.wav file, and then end the call. For more information on Asterisk, see the “References” section.

Running the Attack

Running the attack midday would have had the greatest impact, but we did not want to cause too much disruption, so we executed the attack early in the morning. Our system has the benefit of a SecureLogix application firewall, which we used to monitor the PRI during the attack, and we captured a number of screenshots to illustrate the attack. We disabled any mitigation capability in this system, so that it would not affect the attack. We used our own Internet connection, which had plenty of bandwidth to make the outbound SIP trunk calls. These arrived back at our location as inbound TDM calls on our PRI trunk.

During the attack, the PRI trunk was completely saturated and no other calls could be processed. We tried over and over to dial into the organization, but as soon as a TDoS call would end, another would come in and take the available channel. Figures 7-16 and 7-17 present a Call Monitor user interface that shows all active calls on the PRI trunk. These figures show a TDoS attack against the 25 DIDs.

In these screens, you can see 23 calls all starting about the same time. The entire PRI trunk was saturated almost immediately. You see the same source number for all the calls; we did not vary it in this test. You also see the different destinations or DIDs. Note the duration differing between the two screens. Although the audio file was 10 minutes long, our voicemail system shut the call down at about the 2:42 minute mark. You see a few new calls coming in as the previous calls were removed. Note that while we tried and tried to make other calls, we could not, and none are shown in these screens.

We also ran the TDoS test against our single main number. Our IP PBX is programmed to play an announcement, which continues indefinitely. Also, this announcement can be played to at least 23 inbound callers, so if you call this number 23 times, you can saturate the PRI trunk and not even worry about finding 23+ DIDs to call. This behavior makes it even easier to execute a TDoS attack. Figures 7-18 and 7-19 illustrate the attack.

You will see a couple of differences between the two sets of figures. First, in the second set (Figures 7-18 and 7-19), the destination number is the same for all calls—our main number. Second, in Figures 7-18 and 7-19 we captured the screens a little later during the attack and all calls had been typed as voice (and the algorithm determines this more quickly because the announcement is played). The final difference is in Figure 7-19, where you will see that the duration of the calls is longer, close to 7 minutes. This is because the announcement plays indefinitely and the calls are not cut short by our voicemail system, as is the case with the calls to the 25 DIDs. The second TDoS attack is simpler and actually more disruptive!

Image

Figure 7-16 TDoS attack against 25 DIDs: start of attack

Image

Figure 7-17 TDoS attack against 25 DIDs: later in the attack

Using Virtual Queues

One last type of automated TDoS can occur through the exploitation of virtual queues and callbacks. Contact centers often use virtual queues to improve the consumer experience, the idea being that the consumer calls into the contact center IVR, leaves their number, and is called back when an agent is available. This way, the consumer does not need to wait on hold until an agent can help them. This improves the consumer experience and improves the use of resources in the contact center because a session or channel is not occupied while the consumer is waiting for the agent.

Image

Figure 7-18 TDoS attack against a single number: start of attack

Image

Figure 7-19 TDoS attack against a single number: later in the attack

Virtual queues can be manipulated for automated TDoS—the idea being that once an attacker finds a contact center that uses virtual queues, they can call in and trick the system into calling any number back. Virtual queues will normally only queue a single call for any given number. That being the case, if you call in many times and try to set up numerous callbacks to one number, such as a single 1-800 number, it won’t work. You can, however, set up many callbacks if you use multiple target numbers. Once you have selected the option that allows you to use the virtual queue, you will be told what number you are dialing from, which is usually your calling number. Often, you have an option to use your calling number or enter a new number. Because you will normally expect to be called back to the number you are calling from, most of the time you would not enter a new number.

You can use virtual queues to attack another enterprise, or use the virtual queues to target the same enterprise’s contact center that is providing the service you’re currently exploiting. As we have discussed, it is easy to assemble a list of the target’s DIDs since you will need multiple target numbers and will use the contact center and virtual queue to provide the data.

If you use the virtual queue to mask the attack, you will also consume resources and agent time in the targeted contact center as well as DIDs for other parts of the contact center, such as other 1-800 numbers. This scenario is possible for larger contact centers with many 1-800 numbers. You could also target other DIDs within the same enterprise. This would not only “double” the attack, but also possibly consume two sessions or channels if the outbound and inbound calls use the same trunking infrastructure.

Virtual queues are quite common. You can easily scan any contact center to determine if they have this capability. When you have found one, you can use the same automated TDoS techniques covered earlier in this section. The primary difference between this attack and other TDoS attacks is the audio content you would use. Ideal audio content would include DTMF or keywords that get you to the point in the menu where you set up the callback. You will need to enter the proper IVR menu option that selects the callback, and we recommend you select the option that uses the calling number. This means that you will need to set the calling number for each call, but this is a lot easier than having your audio generation smart enough to enter a different target number for each call.

A final variant of this attack is to set up callbacks to premium numbers that would cost the contact center money to call. This is a combination automated TDoS and toll fraud attack.

Using Automated DoS to Cover Fraud

Automated TDoS can also be used to cover up financial fraud. If a TDoS attack is generated against a financial contact center, it may tie up agent resources, increase the number of users waiting for agents, increase the frustration level, and result in agents becoming more accommodating and lax in their security processes.

Another example occurs when an attacker is removing funds from a consumer account. The financial organization will often try to contact the consumer to validate the transaction. The attacker can make this impossible by using automated TDoS to flood the consumer’s phone, thus preventing a verification call. In fact, this was the original attack occurring when the FBI coined the term “TDoS.”

Image Automated TDoS Countermeasures

Automated TDoS attacks are similar to social networking TDoS in that they are difficult to detect and mitigate. The TDoS calls need to be quickly detected and terminated to provide bandwidth for legitimate users. As with social networking TDoS, the best location in the UC network to deal with the attack is on the ingress trunks. This prevents an attack from affecting downstream systems while also saturating the inbound trunks.

Automated TDoS attacks can be more disruptive due to the volume and likelihood of an extended duration attack, because an attack could go on for hours or days. Sophisticated attackers are also likely to be able to spoof their calling number, making it more challenging to differentiate a TDoS attack from legitimate calls. If the TDoS attack calls block or restrict their calling number, then these calls can be blocked, but a sophisticated attacker would not do this.

If the TDoS attack is spoofing the calling number, any detection and mitigation solution must examine the audio content. The solution must monitor for repeated DTMF patterns and timing and/or specific audio content. As discussed, it is very unlikely that service providers will ever perform this function because they are not “officially” allowed to sample call content.

The same solutions discussed in the previous section, including some IP PBXs, SBCs for SIP trunks, and application firewalls, can be used to provide protection against these attacks. Because this is a TDoS attack, mitigation needs to involve determining which calls are part of the attack and quickly terminating them to provide bandwidth for legitimate callers. IP PBXs can be used to block calls from specific numbers, but this is ineffective if the attacker is spoofing the calling numbers. Plus, you have the challenge of performing this on multiple IP PBXs. SBCs can be used to provide some mitigation, but they have the same challenge and are only useful if you have SIP trunks. Application firewalls, such as one from SecureLogix, can detect and mitigate automated TDoS attacks by examining patterns, signaling information such as the source number, and the actual audio content.

Call Pumping

Call pumping, also called traffic pumping, is an inbound fraud attack, generally confined to contact centers, where the attacker generates a large number of calls into a 1-800 number. We briefly mentioned call pumping in Chapter 5 because it is a form of fraud, but in terms of how it appears to an enterprise, it closely resembles automated TDoS. In fact, some clumsy call pumping attacks have been mistaken for TDoS attacks.

Image Call Pumping

Image

For a call pumping attack, the attacker generates a large number of inbound calls to toll-free 1-800 numbers, generally in larger contact centers. Larger contact centers are preferable targets because there is a good chance the fraudulent calls won’t be noticed. Some of the largest contact centers in the United States can have upward of a 10,000 concurrent call capacity in their IVRs, so an attacker who can generate, say, 100 concurrent calls might not be noticed quickly, if at all. Obviously, an attacker who isn’t greedy can generate a lower number of concurrent calls and go unnoticed for a much longer time. Figure 7-20 illustrates this attack.

Image

Figure 7-20 Call pumping

The incentive for call pumping is that the various service providers that carry the 1-800 calls get a piece of the revenue. The revenue is small because the 1-800 service is often only pennies per minute and divided among multiple service providers. Again, we are dealing in volume, and the fraud can add up over time with a lot of calls. The attacker will normally be an unscrupulous service provider who artificially inflates the number of 1-800 calls and charges the service provider and enterprise that deliver and own the number. As an example, you could set yourself up as a SIP access provider. Users of your service would be making inbound calls, including some to 1-800 numbers. You would then just inflate the number of calls, at a level that makes money, but is not quickly detected.

The attacker can be going after the connect charges, which occur when the call is established. The attacker then quickly disconnects the call. In this case, the attacker often “sprays” many separate 1-800 numbers, scattered across the country and many enterprises. This type of attack requires the collection of more 1-800 numbers, but this is not difficult, as clever use of Google will provide many numbers to call. When calling these numbers, multiple calls can be placed to each number, especially those for larger contact centers, but again, the attacker would be wise to avoid calling any one contact center or 1-800 number too many times, because the attack might be noticed. As with all inbound call attacks, call pumping is more effective if the calling number is spoofed. However, as long as calls are being sprayed across many 1-800 numbers, the need to spoof is reduced.

Call pumping may also be designed to collect per-minute charges for the 1-800 calls. In this case, the attacker will desire long calls and will use DTMF payloads or audio patterns to keep the calls up as long as possible in an IVR, where the attack will not be detected as quickly as it would if it affected an agent. A well-designed call-pumping attack will only dwell in the IVR because of the per-minute charges. However, the contact center will quickly discover that something is going on if the call-pumping calls leave the IVR and are routed to agents. Some of the call pumping DTMF and audio patterns we have seen in the wild include the following:

• DTMF patterns that loop through the IVR Simple patterns such as playing an “8” to go back to the main menu are possible. More clever attackers build patterns that mimic a confused user. Such patterns would be difficult to differentiate from a real user.

• DTMF timing An unsophisticated attacker may play a DTMF script or preconstructed audio file that is identical. This makes detection easier. A more sophisticated attacker varies the DTMF and also the timing between tones, making the attack more difficult to detect.

• Silence Different IVRs interpret silence in different ways. Most will allow it, and eventually the call will exit the IVR and be routed to an agent. If the attacker has done a little analysis of the IVR, they will know how long this time is and can set the time of the call to this wait period. The attacker could even make the call a little longer because the call will always be on hold for some period of time in the agent queue.

• White noise/static/foreign language Similar to silence. The call would exit the IVR after a period of time and be routed to an agent.

Again, a well-designed call pumping attack will not be noticed by the agents. Once a call gets to an agent, the use of silence, white noise, foreign languages, and other ploys might keep an agent on the line a little longer than, say, abusive audio, but once these calls start getting to the agents, the attack will start to be noticed. This is a major difference between call pumping and automated TDoS, where the intent is to tie up all of the infrastructure and agents in a contact center.

From an attack-execution point of view, call pumping resembles automated TDoS. The differences are that a call pumping attack generated for connect charges will use short calls, no audio, and will be targeted at many 1-800 numbers. Fewer calls will be sent to any single 1-800 number. Call pumping that is designed to also collect the per-minute charges will closely resemble automated TDoS, with calling number spoofing, a moderate number of calls directed at specific 1-800 numbers, and IVRs known to have certain behavior, which is manipulated by the audio containing the proper DTMF or the audio pattern that dwells in the IVR. Because call pumping is designed not to be detected or have an impact, it can be generated during non-peak times, such as at night or on the weekend. This insures that the calls won’t crowd out legitimate users. A competing argument though is that generating the calls at the peak time may cause them not to be noticed since there is so much else going on.

Image Call Pumping Countermeasures

Call pumping is similar to automated TDoS attacks in many ways, but differs in intent and call volume. Well-designed call pumping, designed just to collect connect charges, which spoofs the calling number and sprays many 1-800 numbers with short calls, is all but impossible for the enterprise to stop. Luckily the connect charges are generally low and normally the attacker won’t target a specific 1-800 number or enterprise with too many calls. If the attacker is generating many calls to a single 1-800 number or enterprise, then the service provider will need to address the issue. IP PBXs, SBCs, and UC application security products may be able to detect many very short duration calls.

Call pumping designed to also collect the per-minute charges is also difficult, but possible, to detect and mitigate. Detection and differentiation of the call pumping versus legitimate calls is critical. If the attacker is not sophisticated and is using the same calling number, then call pumping can be fairly easy to detect: simply monitor for the most frequent callers and analyze the audio after the fact to confirm the attack. If the attacker is changing the calling number for every call, detection is more difficult. A sophisticated attacker who isn’t too greedy and is mutating their calling number and Automatic Number Identification (ANI) will be very difficult to detect.

If the call pumping attack is spoofing the calling number, any detection and mitigation solution must examine the DTMF and audio content. The solution must monitor for repeated DTMF patterns and timing and/or specific audio content. As discussed, it is unlikely that service providers will ever perform this function because they are not officially allowed to sample call content.

Again, if the calls get to the agents who hear DTMF or strange audio, after enough calls, the contact center will know something is going on. Even then, it can be a challenge to stop the attack.

The same solutions discussed in the previous section, including some IP PBXs, SBCs for SIP trunks, and application firewalls, can be used to provide protection against these attacks. IP PBXs can be used to block calls from specific numbers, but this is ineffective if the attacker is spoofing the calling numbers. Plus, you have the challenge of performing this on multiple IP PBXs. SBCs can be used to provide some mitigation, but they have the same challenge and are only useful if you have SIP trunks. Application firewalls, such as one from SecureLogix, can detect and mitigate call pumping attacks by analyzing the DTMF and audio for patterns designed to dwell in an IVR.

DTMF DoS and Fuzzing

IVRs interact with consumers through a combination of DTMF, keywords, and natural language. Because these systems must process a variety of inputs, it is certainly possible to create some malformed DTMF or audio payload that affects or crashes the IVR. We cover various forms of packet fuzzing in later chapters, especially in the area of SIP message fuzzing. DTMF and IVR fuzzing are more obscure areas that we will cover briefly in this section.

Image DTMF Fuzzing

Image

If you search Google for “IVR Fuzzing” or “DTMF Fuzzing,” you will find some research performed by Rahul Sasi. A recent presentation can be found on YouTube.16 In summary, Rahul demonstrates that by entering very long strings of digits, such as “11111111111111….” or using phrases such as “test,” “debug,” and “support,” you can create errors in certain IVRs. There is no evidence that these vulnerabilities exist in enterprise-grade production systems, but it is certainly possible. Considering the complexity of these systems, there is a good chance that some issues exist. If you want to try this on your IVR, it is easy to do: simply make calls and try out different DTMF patterns and audio phrases.

The research also discusses the possibility of generating modified audio frequencies, amplitudes, and duration, which might also affect a core DTMF processing system. Again, this type of attack has not been seen on production systems, but if it were possible to affect an IVR with a single “fuzzed” DTMF, this could have a significant effect on the IVR. Because a lot of DTMF processing implementations share base code from certain “stack” vendors, a vulnerability could be wide reaching. Also, many IVRs still in use are older designs, which would be difficult to modify if an issue is found.

Image DTMF Fuzzing Countermeasures

The best countermeasure for these attacks is a well-designed IVR that handles all forms of malformed and unexpected DTMF and audio inputs. These types of audio attacks are difficult to detect by third-party systems because audio can’t be held and queued—it must be played in real time, so a detection system may let attacks through. A detection system could monitor for known attack signatures and detect them and terminate the call before the IVR is affected. Such a system could also watch for certain audio phrases that might create an issue, but, of course, if these are known, the IVR could be programmed not to accept them.

Summary

Harassing calls and TDoS represent attacks ranging from nuisance to dangerous calls to floods that can overwhelm an enterprise or contact center. TDoS can be particularly disruptive, and through the use of social networking and automation, it’s becoming easier and easier to generate. Automated TDoS is rapidly becoming the most talked about issue affecting enterprise systems. As shown in the case study that began Part II of this book, TDoS is being used effectively now to extort money from victims. By the time many of you read this book, TDoS will have become as common as DoS and DDoS against Internet-based sites. TDoS, along with various types of fraud, will comprise the most significant threats against UC systems.

References

1. Phony Phone Calls Distract Consumers from Genuine Theft, www.fbi.gov/newark/press-releases/2010/nk051110.htm.

2. TDoS: Telecommunication Denial of Service, www.fbi.gov/news/podcasts/inside/tdos-telecommunication-denial-of-service.mp3/view.

3. “The World Has No Room for Cowards,” Krebs on Security, http://krebsonsecurity.com/2013/03/the-world-has-no-room-for-cowards/.

4. “Rapper The Game May Face Charges Tied to Flash Mob Calls,” Fox News, www.foxnews.com/entertainment/2011/08/14/rapper-game-may-face-charges-tied-to-flash-mob-calls/.

5. “Fake Pope Twitter Account Gains More Than 100,000 Followers,” MSN news, http://news.msn.com/world/fake-pope-twitter-account-gains-more-than-100000-followers.

6. John Leyden, “DDoS Crooks: Do You Want Us To Blitz Those Phone Lines Too?” The Register, www.theregister.co.uk/2012/08/02/telecoms_ddos/.

7. “Lots of Press on Telephony Denial of Service (TDoS),” Mark Collier’s VoIP/UC Security Blog, http://voipsecurityblog.typepad.com/marks_voip_security_blog/2013/04/article-in-cso-online-on-telephony-denial-of-service-tdos.html.

8. “DHS Warns of ‘TDoS’ Extortion Attacks on Public Emergency Networks,” Krebs on Security, http://krebsonsecurity.com/2013/04/dhs-warns-of-tdos-extortion-attacks-on-public-emergency-networks/.

9. “Additional Bulletins Warning of Telephony Denial of Service (TDoS) Attacks on 911 Centers,” Mark Collier’s VoIP/UC Security Blog, http://voipsecurityblog.typepad.com/marks_voip_security_blog/2013/06/additional-bulletins-warning-of-telephony-denial-of-service-tdos-attacks-on-911-centers.html.

10. Setting Up a SIP Trunk, http://tyler.anairo.com/?id=3.1.0

11. Setting Up VoIP Provider Trunks, www.freepbx.org/book/export/html/1912.

12. VoIP-Info site, www.voip-info.org/wiki/view/Bulk+Call+Generation+Using+ Asterisk.

13. Autodialing with Asterisk, http://neverfear.org/blog/view/89/Performing_a_Denial_of_Service_DoS_Attack_on_a_Phone_Line.

14. Autodialing with Asterisk, http://wiki.docdroppers.org/index.php?title=Asterisk_Autodialer.Autodialing with Asterisk.

15. Asterisk auto-dial out, www.voip-info.org/wiki/view/Asterisk+auto-dial+out.

16. Presentation by Rahul Sasi on DTMF Fuzzing, YouTube, www.youtube.com/watch?v=QXQnVXbat4A.