Category Archives: VoIP Vulnerabilities

7 Asterisk VoIP Security Advisories Issued

Asterisk logoThe Digium / Asterisk Security Team has obviously been extremely busy ensuring that Asterisk is as secure as possible given that yesterday they released 7 security advisories, although only one of them (AST2014-16) was rated as “Critical”.  The others are rated as “Moderate” or “Minor” – but still are good reasons to upgrade to the latest versions of Asterisk.  The list of advisories is:

The issues are all fixed in the latest versions of Asterisk:

  • Asterisk Open Source 1.8.32.1, 11.14.1, 12.7.1, 13.0.1
  • Certified Asterisk 1.8.28-cert3, 11.6-cert8

Kudos to the Digium/Asterisk Security Team for the work they do in keeping Asterisk secure – and also for their openness in reporting the issues publicly!

Asterisk Remote Crash Vulnerability in SIP Channel Driver

Asterisk

The folks over at the Digium security team today released security bulletin AST-2011-012 for a remote crash vulnerability in the SIP channel drive. For info about the attack, they state only:

A remote authenticated user can cause a crash with a malformed request due to an uninitialized variable.

An assumption from this statement would be that an UNauthenticated user could not carry out this attack… but I admit to not personally knowing the SIP channel driver of Asterisk enough to be able to stand behind this conclusion.

Regardless, updates have been released in the form of new versions 1.8.7.1 and 10.0.0-rc1.

Two Asterisk Security Advisories, Including One Critical Remote Vulnerability

The Digium security team issued two security advisories this week for Asterisk:

The second one, AST-2011-004, is the far more concerning because it indicates that a remote attacker could connect to an Asterisk system and cause it to crash.

The solution, in both cases, is to upgrade to the latest Asterisk releases.

UPDATE: 3/18/11 – Olle Johansson pointed out on Twitter:

Either upgrade or do not use SIP/TCP. Installations only using SIP/udp is not affected and do not need to upgrade.

Thanks for the clarification, Olle.

VoIP Abuse Project

Brief History

Throughout the course of three years I have been studying the Voice Over IP attack canvas. As a security engineer, I have had the privilege of seeing an enormous amount of attacks while working at a Managed Services Provider. Because I have multiple roles in the company I am working at, I get the best of multiple worlds. Sometimes I’m a VoIP engineer, sometimes a pentester, sometimes systems engineer, other times it depends highly on my mood. Overall I’m a Senior Coffee Tasting Engineer working at a company that gives me great flexibility to do what I want. This allowed me to create my own Voice Over IP Honeypot I called Arkeos for data analysis.

My original security application began as a “blacklisting” slash “VoIP Intrusion Prevention System” program using Asterisk. The goal was simple, keep an eye on live servers and when an attacker made a move, initiate a mechanism to automatically block the attacker, send the engineers a report, place the offender in a list to be distributed to all other PBX’s in my company so they too can block them. Initially my VoIP IPS worked just as programmed however, because I have clients all over the world, it became difficult to outright block entire CIDR ranges. I quickly whitelisted many addresses, re-hashed the IPS which worked fine for years.

The Arkeos idea came to mind after browsing around to see that there really wasn’t anyone to correspond with in this matter. People looking for and sharing similar data were few as opposed to normal networking slash abuse. I decided to build my honeypot based on what I was seeing from monitoring logs. Anyone who has known me for years can tell you that I kept tons of terminals opened with good old faithful tail -f running alongside whatever logging applications I have in house (Splunk, etc). As months passed by, I began archiving data from attacks spread across 20-30 Internet facing PBX’s. My current company sells VoIP trunks, managed VoIP services, T1-OCx connections, managed security services, video conferencing, digital signage, etc.; if it’s out there, then we likely do it. This gives me a high degree of visibility for not only VoIP attacks, but other attacks as well.

Arkeos is a program primarily used on Unix based servers running the Asterisk Open Source PBX. The application mimics a valid extension in which an attacker, after bruteforcing an account, attempts to place calls. What the attacker doesn’t know is that their calls go nowhere. The sole purpose of allowing them to perceive they have an account is to track them. Where they come from, what accounts they use, what VoIP account scanners they use, what numbers they try to dial. Because of the flexibility of Asterisk and Unix as a whole, the application does a lot more than stated however, I will not disclose too much otherwise any attackers reading this might catch on. Then I won’t have anyone to play with.

As time progressed customers who purchased SIP trunks from us were getting “owned” from time to time and to date, I have been called to handle incident response and forensics on over 75 VoIP servers ranging from Asterisk, Avaya, pbxnsip, CME and a mixture of everything in between. Usually the outcome has been the same: weak accounts and weak passwords.

2007 – 2008’s Attackers trends

For the better part of 2007 and 2008, attackers had a common modus operandi: scan a host for an open account, register a device (soft phone, another SIP trunk) and fire away thousands of calls. I have personally seen a company spend over a quarter of a million US dollars because of these attacks. Before I dive more into stats a bit, I will explain a bit about the financial loss for those who don’t think that it’s a big deal. I currently have a client who purchases a heavy amount of SIP trunks from my company, they in turn have a “Vonage” like business. Their customers buy an ATA, number, connect and place calls from Latin America. My client one day sends me an e-mail asking me if I would be willing to take a look at his network as his upstream was sending them abuse messages. Game on.

My client has approximately 20 servers in the continental US and 20 in Latin America. They were using a mixture of Asterisk and other equipment. What was happening to their servers was two-fold, attackers were leveraging VoIP accounts and placing thousands of calls. During the times when attacks took place, their bandwidth was so saturated that normal clients’ calls experienced horrible quality and drops. This led to loss of clients, enormous phone bills to places like Sierra Leone, Romania and the list goes on. To make a long story short, it took me approximately six weeks to clean up their shop as I could NOT take any of their servers offline. I essentially had to analyze what occurred, cut the bleeding, implement a fix and implement post remediation. Ultimately I programmed a distributed “cleaning” application to clean up accounts, create appropriate firewall rules, clean up backdoored binaries, implement an SIEM. This was another cost the client had to contend with. When I say over a quarter of a million dollars I am being very conservative. That was only the first instance of what occurred in their network, the second was, a few of their servers had become bots – but that is another story. Moving back into the statistics and trends of attackers I’ve seen, attackers are becoming smarter and the attacks seem more focused and targeted.

2009 – 2010’s Attackers trends

On a daily basis I see approximately six or seven attacks on each one of my Internet facing PBX’s, this estimate is based on solid numbers. The total amount of attacks divided by the amount of servers I have. While it may not seem like a big deal but the fact of the matter is, if one attack cost a company a quarter of a million in damages, the last thing I need to see is an attack on my company. Management’s first response would be “why didn’t you stop it.” The reality is, my company too was the victim of tollfraud via legacy VoIP accounts. We experienced 96 billable hours from our carrier to calls made to numbers in Sierra Leone. I know firsthand that these attackers are not “script kiddies” but focused fraudsters. Altogether during a highly volatile week, I can see approximately 150 – 200 attacks per day.

Previously (between 2007 – 2008) when I monitored the attacks, the attack phase was: “get an account, fire and forget,” whereas now, there seems to be less automation and more intervention. This is evident in the way attackers are placing calls. Here is an entry from today in my Arkeos database of an attacker coming from an address in Germany. Take note that I have sanitized data to keep the identity of my honeypot at bay:


# more peer-verbose-Mon-21-Sep-2009-11\:59\:34-AM-EDT.txt
 -- General --
           Name: SIP/300-b6b241c0
           Type: SIP
       UniqueID: 1253548774.7688
      Caller ID: 1xxxxxxxxxx
 Caller ID Name: xxxxxxxxxx
    DNID Digits: 16085541772
          State: Ring (4)
          Rings: 0
  NativeFormats: 0x2 (gsm)
    WriteFormat: 0x40 (slin)
     ReadFormat: 0x40 (slin)
 WriteTranscode: Yes
  ReadTranscode: Yes
1st File Descriptor: 39
      Frames in: 0
     Frames out: 0
 Time to Hangup: 0
   Elapsed Time: 0h0m0s
  Direct Bridge:
Indirect Bridge:
 --   PBX   --
        Context: xxxxxxxx
      Extension: xxxxxxxx
       Priority: 2
     Call Group: 0
   Pickup Group: 0
    Application: Dial
           Data: SIP/1xxxxxxxxxx
    Blocking in: ast_waitfor_nandfds
      Variables:

SYSTEMSTATUS=SUCCESS
SIPCALLID=146ef044580a3a795de94b541db21249@xxx.xxx.xxx.xxx
SIPUSERAGENT=Asterisk PBX
SIPDOMAIN=xxx.xxx.xxx.xxx
SIPURI=sip:300@85.214.85.180

  CDR Variables:
level 1: clid=xxxxxxxx
level 1: src=xxxxxxxx
level 1: dst=xxxxxxxx
level 1: dcontext=xxxxxxxx
level 1: channel=SIP/300-b6b241c0
level 1: dstchannel=SIP/xxxxxxxx
level 1: lastapp=Dial
level 1: lastdata=SIP/xxxxxxxx
level 1: start=2009-09-21 11:59:34
level 1: answer=2009-09-21 11:59:34
level 1: end=2009-09-21 11:59:34
level 1: duration=0
level 1: billsec=0
level 1: disposition=NO ANSWER
level 1: amaflags=DOCUMENTATION
level 1: uniqueid=1253548774.7688

So what occurred here? The who, what, where and how? The four most important variables are easy to parse:


How: Name: SIP/300-b6b241c0
Where: DNID Digits: 002314599711
What: SIPUSERAGENT=Asterisk PBX
Who: SIPURI=sip:300@85.214.85.180

How? An attacker leveraged a SIP account on the honeypot (username=300) Where? They tried dialing 16085541772 What? They likely tried trunking the SIP account to their Asterisk box Who? 85.214.85.180 So who owns the server? A company reselling hosting:


inetnum:        85.214.16.0 - 85.214.139.255
netname:        STRATO-RZG-DED2
descr:          Strato Rechenzentrum, Berlin
country:        DE
admin-c:        SRDS-RIPE
tech-c:         SRDS-RIPE
remarks:        ************************************************************
remarks:        * Please send abuse complaints to abuse-server@strato.de   *
remarks:        * or fax +49-30-88615-755 ONLY.                            *
remarks:        * Abuse reports to other e-mail addresses will be ignored. *
remarks:        ************************************************************
status:         ASSIGNED PA
mnt-by:         STRATO-RZG-MNT
source:         RIPE # Filtered

Wondering if this is spoofed (since some seem to think it is):


# nmap -sU -p 5060 85.214.85.180

Interesting ports on server1.stacheshof.de (85.214.85.180):
PORT     STATE         SERVICE
5060/udp open|filtered sip

Nmap finished: 1 IP address (1 host up) scanned in 1.755 seconds

Likely not spoofed however, this does not stop someone from compromising a host and using it to do other things. The likelihood of this server being compromised AND running a PBX on it is low and here is my reasoning for this comment, I’ve seen this address quite a few times connecting to different addresses during different months. I would think a server’s administrator would notice a PBX server running on their system. What makes things even more interesting is the following, the attacker tries to make one call, then starts changing his (or her) dialing patterns:


002314599711 - 20100921-11:41:33
92314599711 - 20100921-11:47:42
9002314599711 - 20100921-11:54:31
90112314599711 - 20100921-12:00:29

The calls were placed at odd times to make me think they were automated. The first call was at 11:41 followed by six minute gap, followed by a 7 minute gap, followed by another 6 minute gap. In previous times, automation was instant. Even odder is, how is this person aware that a call didn’t go through and that they should be changing the dial plan? My response is, they have some form of visibility into that destination number. Calls from my honeypot sound just as any other call with the exception they all end up in one place. Voicemail to a non-existent account. This further allows me to hear the audio if any is left.

After accumulating all of this data, I figured it would be best to share it with others in the industry via the “VoIP Abuse Project.” The purpose of the project is to create a blacklist of sorts for any engineer or admin to be able to use to block out the bad guys. Alongside blocking out the bad guys, it always offers a place to showcase the realities of “abuse desks” of companies whose networks are being used in attacks. That goal too is simple, systems are attacked and reported, companies responding and correcting issues should be applauded, companies ignoring the issue should know that it will only be a matter of time before their clients cost them more in lost revenue. It’s their networks, they should be more responsible about what leaves their network. Anyhow, this has become rather long so I will leave this as a part one. Stay tuned for more.

More on Telephony Denial of Service (TDoS) Attacks

I assume most everyone has seen the FBI press release on Telephony Denial of Service (TDoS). For those who have not, see:

http://newark.fbi.gov/pressrel/pressrel10/nk051110.htm

I am also seeing the term used to describe enterprise-directed DoS, where an attacker typically floods a contact center with calls. I have recently worked with both enterprises, service providers, and hosted IVR companies that have seen these attacks. The current motive seems to be traffic pumping/revenue generation, not DoS per se, but the side impact is that operation at the target sites is degraded or seriously disrupted, depending on call volume and trunk capacity. Interestingly, the targets I have talked to are primarily using TDM trunks, while the attackers (according to the service providers I have talked to) are using VoIP. I have a post on my blog with more information:

http://voipsecurityblog.typepad.com/marks_voip_security_blog/2010/06/more-on-telephony-dos-tdos.html

Is anyone else seeing these attacks?

Dialstring injection vulnerability in Asterisk

Olle Johansson recently alerted us that there is a “dialstring injection” vulnerability in Asterisk. As Olle notes in his post about the vulnerability, this is similar to a SQL injection attack against a database where there is not enough filtering being done on strings that are being input to the system. Olle writes:

Many VoIP protocols, including IAX2 and SIP, have a very large allowed character set in the dialed extension, a character set that allows characters that are used as separators to the dial() and the queue() applications, as well as within the dialstring that these applications send to the channel drivers in Asterisk. A user can change the dial options and dial something we should not be able to dial in your system. This article describes the issue in more detail and gives you some help on how to avoid this causing trouble in your Asterisk server.

Olle goes on to explain the issue in more detail and explain about how input from VoIP channels should be filtered before being sent to the Asterisk ‘dialplan’ for processing. He includes a plea for assistance:

We need everyone involved to pump this information out in all the veins that runs through the Asterisk eco-system. Audit your dialplans, fix this issue. And do it now. Everyone that runs a web site with dialplan examples – audit your examples, fix them. Everyone that has published books – publish errata on your web site. Please help us – and do it now.

Olle’s article goes into much more detail and offers suggestions for what you can do to protect your system. If you are an Asterisk administrator, it’s definitely an issue you should investigate and act on.


If you found this post interesting or helpful, please consider either subscribing via RSS or following VOIPSA on Twitter.


Asterisk Security Advisory – RTP Remote Crash Vulnerability

asterisklogo.jpgEarlier this week, the security team at Digium released Asterisk Projects Security Advisory AST-2009-010 identifying an interesting attack where an attacker can send a malformed RTP packet within the RTP stream and crash the Asterisk system. The fix identified is to upgrade to the latest version of Asterisk.

My one bit of feedback to the folks at Digium would be that their advisories do not provide any information about mitigating circumstances. (Would be great if they could add such a section.)

In this particular case, I confirmed with Digium that this advisory only affects systems that allow public unauthenticated calls over an IP connection. So Asterisk systems that are only used for PSTN connectivity – or only allow authenticated connections/calls – are not vulnerable to this attack. My Digium contact indicated:

The attacker would have to be capable of negotiating a RTP stream and then sending the Comfort Noise payload within the stream to crash the system.

He also indicated that IAX connections are not affected as they do not use RTP streams. So basically you are only vulnerable to this attack if you allow anyone to connect to your Asterisk box over an IP network presumably using the SIP protocol.

If you aren’t allowing those connections, it’s probably still good to upgrade… but you are apparently not vulnerable to the specific attacks outlined in the advisory.

Tricking SIP Endpoints Into Divulging Authentication Credentials

This is a neat trick. By doing a little up-front scanning and/or guesswork, an attacker can send an INVITE directly to a SIP user agent, causing the device to ring.  Then, when the user agent issues the BYE message to hang-up, the attacker can respond with a 407 Proxy authorization required message, causing the endpoint to then respond with it’s authentication credentials, essentially handing them directly to the attacker.

The page linked above indicates that this attack is currently implemented in the VoIP Pack for CANVAS, so it’s essentially packaged and ready to use for you CANVAS users.  You can see a video of this being used in CANVAS here.  I would expect to see this credential-harvesting attack in other exploitation frameworks or stand-alone tools shortly…

Two new Asterisk security advisories…

asterisklogo.jpgThe security team over at Digium today released two new security advisories. In both cases, the fixes are in the latest version of Asterisk and all Asterisk users should upgrade to those new versions.

AST-2008-010 – IAX2 ‘POKE’ RESOURCE EXHAUSTION

The first advisory, AST-2008-010, outlines a denial of service attack where an attacker can basically send a large number of IAX2 “POKE” requests and consume all available capacity to make or receive calls using IAX2. The only workaround seems to be to upgrade to the newest version. It does not say but one would imagine that if you do not use IAX2 connections you could presumably block that port and not allow any inbound IAX2 connections. (Although the safer course is, naturally, to upgrade.)

AST-2008-011 – IAX2 FIRMWARE PROVISIONING SYSTEM

The second advisory, AST-2008-011, outlines a scenario in which an attacker could flood a site with bogus requests to download a firmware image which would result in the generation of a large amount of traffic on the network. Essentially, since there is apparently no “handshake” before the initiation of the firmware transfer, an attacker can spoof the source address. With a large number of such requests, the Asterisk system can wind up generating a large amount of network traffic destined for spoofed sources. As noted in the advisory, the workaround is simply to remove the firmware image. This firmware download service has been disabled by default in the new version.

As noted in both advisories, Asterisk users are strongly recommended to upgrade as soon as possible to the listed version.

Technorati Tags:
, , , , , ,

Avaya, Cisco and Nortel VoIP security vulnerabilities to be announced today

News reports are coming out now (FierceVoIP, Network World and others) that in about 30 minutes or so, Avaya, Cisco, Nortel and VoIPShield Systems will be jointly announcing VoIP security vulnerabilities – and corresponding fixes.

We are delighted to see that in contrast to the previous announcement of vulnerabilities discovered by VoIPshield Systems, all three major vendors will be participating in today’s announcement.

Stay tuned… and if you are an Avaya, Cisco or Nortel user, you should probably be standing by to allocate some time to patching.

Technorati Tags:
, , , , , , ,