Category Archives: VoIP Security Research

VoIP Attackers – Sometimes They Come Back

In my previous post I briefly touched on information that I had been collecting for over 19 months via what began as VoIP Intrusion Detection system I had whipped up from scratch. The framework for Arkeos began almost three years ago while working here at an ITSP slash managed service provider. One of our services is a “managed VoIP service” similar to Packet8 or Vonage for small to mid-sized business. I lost count of how many PBX’s we maintain nowadays but I will comfortably float this number at around 60’ish. Altogether I have about 1,600 clients mainly small to mid-sized businesses with a couple of Fortune 500’s in the mix. My company also provides SIP trunks and we have about 30-35 VoIP companies who use us as their backbone for their VoIP services. Because of my position in my company (multiple roles), I have great visibility into many different VoIP hardware and software vendors in fact, I can’t think of a VoIP related vendor I haven’t dealt with in the past 5 years. Avaya, Nortel, Mitel, Cisco, Acme Packet, Audiocodes, Allworx, PBXNSIP, Asterisk and the list goes on. Because my “main cup of tea” is security, I began meshing security with VoIP.

Arkeos does a few things: 1) Collects information on bruteforcers 2) Collects information on attackers 3) Records the calls an attacker is trying to send and 4) Mimics a phone so that an attacker thinks they are placing a valid call. When I first scripted it, I had to customize it in accordance to the device it was being deployed on, these were mainly Asterisk based PBX’s. Because I was using different versions of Asterisk, I had to tweak the script almost daily as the columns in Asterisk’s message file was different. For example:

2010-09-25 21:02:48 NOTICE[14155] chan_sip.c: Registration from '"3068" ' failed for '' - Wrong password
2010-09-25 21:02:50 NOTICE[14155] chan_sip.c: Registration from '"3068"' failed for '' - Wrong password

These are two different entries to parse with awk. To obtain the first entry, I would use ‘awk {print $10}’ whereas the other would be awk ‘{print $9}’. I initially thought of going with Python, then Perl, but settled on good old fashioned shell scripting. This ensured me that no matter what system I deployed it to, I would be able to use readily available tools on the system without introducing another application. Arkeos in all honesty is a nightmare to look at if you’re a coder, yet completely functional for what it does.

After tweaking it to my needs, I began to see many patterns die and many emerge. Years back, I saw the “fire and forget” method of attacks where you had a bruteforcer compromise an account, then that same bruteforcer fire of as many calls as they could possibly send. Nowadays I see “bruteforce” drive-bys and an attacker come from left field. Without giving up information to potential attackers who may read this, let’s assume I have an account of 5000 with a password of 5000, I’ll see say 10,000 attempts from an address of trying to guess the password, with an attacker from registering to use the account. From more or less November of 2009 through now, I have yet to see a bruteforcer gain an account AND log in at the same time. On the contrary, I don’t see bruteforcers’ addresses on my honeypots anymore.

mysql> use arkeos;
Database changed
mysql> select * from attackers where attacker_address='';
ZZZZ,, Zoiper rev.5324, XXXX, 2010-09-11, 03:16:28
1 row in set (0.00 sec)

mysql> select * from bruteforcers where attacker='';
Empty set (0.01 sec)

mysql> select * from bruteforcers where start_date='2010-09-11';
Empty set (0.00 sec)


NOTE: I modified the output to fit it to page, the exact format of Arkeos and its tables can be seen at: and the audio for this call can be heard at

So why is this information not only important to engineers (be they VoIP, Security, Network or Systems engineers) but also to perhaps law enforcement, the answer is a bit complex so I will try my best to explain my point of view, theory and concept. Imagine that right now I saw a bruteforce attack from say Korea with the account actually being used from say Romania. Romania hoses my machine and costs me say 100,000.00. For the time it would take for an investigation to even take place, get subpoenas in order, go around the world, get those companies to co-operate, at the end of the day, the investigation would likely yield NOTHING. I say this because of the ease of readily available networks and hosts that are likely compromised and used for bruteforcing and attacking. However, this is SOLELY for the bruteforcers. Did I mention the actual attacker is coming from elsewhere?

An attacker is, who I categorize in my writing, someone who has actually tried to place a call through my honeypot. Heck, bruteforcers I can easily block, prior to my honeypot I had created my own Asterisk based IPS capable of blocking bruteforcers in real-time. Attackers I want to believe are a bit more static in the sense that I believe whoever is behind is the culprit who needs to be either arrested or rubber-hosed (depending on your view of justice). So what is relevant for an investigator outside of the attacking IP? For starters, Zoiper is a softphone (for those who don’t already know this) which means this attacker is likely using either a desktop or a laptop. Further, because I’m also tracking the number(s) being called, I gained the following insight:

awk '/407272/{print $1}' /usr/share/arkeos/calls/*

What have we here? Intervention is what. Arkeos mimics a telephone so unless an attacker was on the opposite end of the number dialed, how would they know to try 011, 001, 9011, 900 and so on and so forth. Hence the title “Sometimes they come back.” I have seen quite a few attackers coming back week after week from the same addresses sometimes, using the same accounts, trying to call the same number. So where would I look if I were an investigator? Directly at whomever owns that number they’re trying to call, that’s where. I theorize that if one tracked the owner of that number, searched the computers of who owned that number for Zoiper, I’m willing to bet they’re one in the same. Coincidental? Highly unlikely. An IP address, a phone number AND a softphone client ALL coincidentally belonging to one person is more than coincidental.

Anyhow, I have created an online submission form for others to submit attacker data and am trying to figure out a way I can streamline Arkeos to be a “plug and play” script for anyone willing to use it. I will eventually create a database which others who collaborate can update and pull from but I don’t want to run into a thousand emails asking me to “customize” Arkeos. This is the only reason I haven’t made it public. Remember, I made this from scratch and it was tailored to my machines and since all machines differ, I do know that I will receive those emails. To which I have little time to respond to. I try to answer as many emails as I can, but the fact is, I’m all over the place sometimes (literally.)

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


  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
Who: SIPURI=sip:300@

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? So who owns the server? A company reselling hosting:

inetnum: -
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   *
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

Interesting ports on (
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.

Weaponizing the Nokia N900 – Part 1

In the 80s movie “The Color of Money” there’s a great scene where a player challenges Tom Cruise’s character to a game. He strolls up to Vincent and says “So what you got in there?” — to which Vincent replies. “Doom.”

This is akin to how I felt a few weeks ago after I finally got ahold of a Nokia N900 smartphone. Calling it a phone is a bit of a stretch, as it is primarily a Debian Linux tablet with impressive hardware specs and a huge number of .deb packages available for installation…oh, and you can make cellular phone calls with it. Many people use this phone, and despite some glitches it is rapidly developing into a formidable platform for security tools and penetration testing.

Broadly speaking, the objective of this series of blog posts is to introduce folks to the tools available and the potential for this phone as a security testing platform. Given the fact I’m a bit late in obtaining this phone, some smart people out there have already started to address the n900’s capabilities and available tools, and I would be remiss not to mention, and build upon, their insightful work. The key phrase here is “build upon” and get the word out, not to steal or simply re-hash their fine work and efforts!

I’ve one caveat to this series of blog posts. As my n900 is for now a “production phone” for me in that I need to use it and can’t brick it just yet, the path of this blog series on “Weaponizing the Nokia N900” will progress from known, tested and functioning security tools on this phone — and therefore lower risk of bricking — to more advanced, edgy tools that require more tweaks and modifications, such as replacing the stock kernel. If someone out there finds this series useful, and has interest in furthering research on running security tools on the n900, I’d welcome the donation of a n900 for development and testing, and would credit them for their support. Please ping me offline if you’re interested 🙂

NeoPwn and the Nokia N900

One project to watch in particular is the upcoming release of NeoPwn, which is based on BackTrack and bills itself as the “First Ever Network Auditing Distribution for a Mobile Phone Platform” and is due for release sometime this month, hopefully before DefCon. I am fortunate to be in the BETA and will write up a blog post for this series on NeoPwn once I get full access to the NeoPwn toolset.

Worthy Resources on Nokia n900 Security Tools

1. Metasploit on the Nokia n900. ‘Nuff said.

metaspolit n900

2. Blog SimonLR wrote an excellent post on “Using the N900 for Fun and Profit” that covers several awesome tools, such as Metasploit, Dsniff, SSLstrip, Aircrack-NG, etc. He’s clearly savvy and his future blogging on tools for the n900 will be great to see.

3. Asterisk on the n900

Asterisk n900

When I added the extra package repositories to my n900, I was more than a bit surprised to see a full version of Asterisk available as a .deb package. Wow. Think about this for a moment. One can run a full Asterisk server on a phone in their pocket. The capability of Asterisk on the n900 could enable attackers to do all sorts of mischief, such as running the SPITTER tool from their pocket as a simple example. From a surveillance aspect, think of “bad people” with n900s in their pockets running Asterisk servers on their phones and connecting to each other point-to-point over encrypted tunnels — now that’s a challenge.

Stay tuned for more posts on “Weaponizing the Nokia N900” 🙂

Should vendors have to PAY a security research firm to receive detailed vulnerability disclosure?

This is a guest post from Andy Zmolek, Senior Manager, Security Planning and Strategy at Avaya, and past participant in VOIPSEC mailing list discussions and other VOIPSA activities. Andy asked if I could publicize this because he believes it is a discussion which we in the security community need to have.

Text by Andy Zmolek of Avaya:

Is it appropriate for a security research firm to require payment from a product vendor prior to detailed vulnerability disclosure? I received the following notification this morning from the CEO of a VoIP security startup:

“I wanted to inform you that VoIPshield is making significant changes to its Vulnerabilities Disclosure Policy to VoIP products vendors. Effective immediately, we will no longer make voluntary disclosures of vulnerabilities to Avaya or any other vendor. Instead, the results of the vulnerability research performed by VoIPshield Labs, including technical descriptions, exploit code and other elements necessary to recreate and test the vulnerabilities in your lab, is available to be licensed from VoIPshield for use by Avaya on an annual subscription basis.

“It is VoIPshield’s intention to continue to disclose all vulnerabilities to the public at a summary level, in a manner similar to what we’ve done in the past. We will also make more detailed vulnerability information available to enterprise security professionals, and even more detailed information available to security products companies, both for an annual subscription fee.”

I would like to solicit opinions about what appears to me to be a new challenge to infosec industry best practices. For those of you who work for software or equipment vendors, have you ever received similar notices from legitimate security researchers? Does anyone here believe the practice of equipment vendors making payments to security researchers in order to receive details about potential exploits is an acceptable business practice?

For infosec professionals, would you be comfortable purchasing services from a security research firm that follows such a policy?

NOTE from Dan York: In an effort to get VoIPshield’s perspective, I attempted to reach CEO Rick Dalmazzi but could only get his voicemail. (Perhaps because it is Canada Day and they are in Ottawa.) Andy Zmolek informed me on a call today that he had emailed Rick this morning asking when VoIPShield would be updating their Vendor Disclosure Policy (dated Nov 2007) that is on their Vulnerability Advisories page, as this email from Rick represents a significant departure from that stated policy. I also called the number of the PR contact listed on VoIPShield’s website but that extension went to a “general delivery” mailbox.

This post will be updated with information from VoIPShield Systems when such information can be obtained.

Technorati Tags:
, , , ,

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…

Variable Bitrate Compression Flawed

Some researchers over at Johns Hopkins University have discovered that due to the way Variable Bitrate Compression does it’s thing, even if the audio stream is encrypted it is still possible to determine entire words and phrases based on the lengths of the packets with a high degree of accuracy.

According to the article referenced above it appears that the proof of concept tool is fairly limited, but given a little time and additional effort it’s capabilities could be greatly expanded, potentially to the point of transcribing entire conversations.

The researchers’ paper was presented at the 2008 IEEE Symposium on Security and Privacy a few weeks ago.

VoIPshield announces discovery of “over 100 vulnerabilities” in Cisco, Avaya, Nortel VoIP systems

voipshield.jpgSo today VoIPshield Laboratories announced the discovery of over 100 security vulnerabilities in systems from Avaya, Cisco and Nortel and, somewhat predictably, this has already resulted in coverage from the Wall Street Journal BizTech blog and InfoWorld’s Security Watch blog. I will expect to see more coverage in the days ahead as it works its way out into the mainstream media. The news release is a good one and includes great quotes from Gartner’s Lawrence Orans and our (VOIPSA) own Jonathan Zar.

VoIPshield has disclosed all the vulnerabilities to the vendors and has made 44 of the vulnerabilities available at (That is the number I currently see on the page.)

I should note that VoIPshield Systems, under whom VoIPshield Laboratories falls, is a member of the VOIPSA Technical Board of Advisors. I also have met the VoIPshield folks several times and Jonathan and I interviewed CTO Bogdan Materna eons ago back on Blue Box podcast #12. We’ve been on panels together and I have a high degree of respect for what they are doing and how they are doing it.

This familiarity, though, does not prevent me from feeling a bit uneasy about two aspects of this announcement today. First, if you look down the list of vulnerabilities in almost all cases (41 of 44) the vendor response state is “Attempting to address the issue“.

In other words, these are current, open vulnerabilities. No patches. No fixes. (Outside of the stated recommendation to follow network security best practices and potentially to purchase a VoIP security product such as the one VoIPshield makes.)

Now in many cases the vulnerability announcements are sufficiently vague that an attacker is not going to be able to do a whole lot with them. However, in other cases, there’s enough information there to point the way for an attacker. For instance, this one for Cisco for “UCM Multiple Hardcoded Passwords” indicates:


By knowing and using the hardcoded account names and passwords (a total of three have been identified) on the UCM platform, an attacker can connect to the system and issue database commands which can result in code execution, denial of service, license exhaustion or theft, etc.

So now we know there are three account names (at least) with default passwords that can be used to administer a Cisco UCM system. How long will it be now before someone sitting there with a brute-force password script will figure out those names and post them to one of the various default password lists out there?

Now, this particular vulnerability announcement does state:

Cisco acknowledges the presence of these hardcoded passwords and is working to have the values set to an administrator definined setting during installation.

This will undoubtedly involve a new release of the software (since it refers to the installation process). That will take some time, obviously, and in the meantime any Cisco Unified Communications Manager installations out there are potentially vulnerable to abuse through these hardcoded usernames and passwords.

I understand that VoIPshield did contact these vendors and at least per the WSJ article gave them at least 30 days notice. I also realize that vendors may not always be able to create quick solutions and also may not assign the same priority to issues (or may in fact dispute/dismiss the issue). Having been on the vendor side, I well understand the dynamics of working with security research firms. I know there can be challenges on both sides. Still, I personally would have been a lot more comfortable with seeing this information out there if they had waited a bit until more than just 3 of the 44 listed vulnerabilities have vendor patches available.

Which brings me to my second concern. The vulnerability notices posted do not include any “mitigating circumstances”. They state the description of the problem and offer the recommendation to use network security best practices and VoIP security products such as those sold by VoIPshield, but they do not provide a sense of how to evaluate the risk involved. For instance, with the hardcoded passwords, I am assuming the attacker needs to be on the internal network, but is that correct to assume? With the DFR Cancel Backup Command Injection vulnerability, does the attacker need to be on the internal network? Or could they be on the public Internet? (if systems traversed the Internet)

Now perhaps VoIPshield is waiting to provide this type of information until there is a fix out there. This is also their first time issuing public vulnerability notices in this form. Perhaps with feedback such as this they will provide that added information. But without that kind of information, it’s not clear to me that I have enough information to understand the potential risk to my systems. (And perhaps we’ll have to have them on a podcast to talk about all of this.)

Regardless of these two concerns, the fact remains that VoIPshield Laboratories has entered the space as a new research entity and has already brought out a wealth of research. Per their news release, this is just the first step and more information will be coming soon. That all is good to hear as having such research groups focusing on the VoIP security space is a definite good thing. We need more research in the field and so it’s great to see VoIPshield entering the space publicly. (They’ve obviously been doing this research privately for their products for some time.)

And, if you are the administrator of a system from Avaya, Cisco or Nortel, I would strongly encourage you to review the vulnerabilities and try to understand which of them may or may not affect your installations.

Technorati Tags:
, , , , , ,

Hacking ZyXEL Gateways

An interesting paper recently published by Adrian Pastor of ProCheckup discusses vulnerabilities and attacks against ZyXEL gateways, including (yikes) Remote wardriving/attacking internal networks over the Internet, among others:

  • Privilege escalation from “user‟ to “admin‟ account
  • SNMP read and SNMP write access enabled by default
  • Persistent XSS via SNMP
  • Poor session management allows hijacking of admin sessions
  • Authentication vulnerable to replay and password cracking attacks
  • Disclosure of credentials
  • Considering the code reuse among various products made by most vendors of these residential gateways, not to mention the widespread deployment by service providers, I think it would be quite interesting for VOIPSA folks to expand on Adrian Pastor’s work and pursue this type of testing on some of the VoIP gateway products that ZyXEL offers, specifically the Analog Telephone Adapter, Station Gateway and Integrated Access Device to start. Also, the web interface of embedded devices like these are especially problemmatic from a security perspective, and it’s well worth a look at another one of Adrian Pastor’s papers over at OWASP.

    “So what” you might say about the security of these types of devices? Well, SANS diary notes some strange things afoot at the Circle K with Dlink, and there is the recent BT Home Hub CVE-2008-1334 vulnerability. More routers and details at GNU Citizen’s router hacking challenge.

    Underpowered Hardware

    One of the issues with VoIP endpoints that I regularly encounter as a security researcher is the problem with underpowered hardware. Many VoIP hardware devices are initially designed with just enough horsepower to do their job in order to keep costs low and stay competitive in the market. Due to VoIP technologies evolving so rapidly and devices being updated to include many additional new features shortly after being brought to market, the software running on these devices generally outgrow the hardware and will consume the few remaining unused resources available on the device. Vendors then have to play a balancing game of what software features can be crammed onto a particular device and it still work properly.

    Not only does this condition of the technology promote attacks like Denial of Service via resource exhaustion, floods, and so forth, but it also gives rise to other vulnerabilities such as this one which was detailed yesterday by Larry Dignan & George Ou. Due to the resource limitations of the hardware device, corners were cut when adding support for the device’s 802.1x PEAP authentication feature which resulted in the server certificate not being checked during authentication, which then devolves into a number of other security issues. Not only does this affect the device being discussed in the article, but it apparently also affects a number of other devices as well who’s designers cut the same corner, likely for the same reason.

    Because VoIP technology evolves so rapidly, and generally grows in resource requirements by leaps and bounds while doing so, VoIP hardware vendors really should be providing much more processing power than the initial software needs when the devices are brought to market. Unfortunately the cost of including this extra horsepower initially is borne by the vendor, whereas the cost of having to upgrade (i.e., replace) masses of deployed hardware devices when their resource limitations become insurmountable is borne by the consumer.  Device replacement results in additional sales and profits for the vendor, so don’t expect properly resilient hardware devices anytime soon…

    Slides about Peer-to-peer SIP (P2PSIP) security now available

    ietflogo-1.jpgWant to learn more about the voip security aspects of peer-to-peer SIP? As I mentioned in the VOIPSEC mailing list last week, researchers from Huawei and the University of California recently released an Internet-Draft called “P2PSIP Security Analysis and Evaluation” which dives into an analysis of security issues in P2PSIP. It’s a good overview and one I’d strongly recommend to folks. (Note – you may want to read “P2PSIP Concepts” first to understand the language being used.)

    Beyond the Internet-Draft, though, the researchers announced yesterday that their slides are now available (PPT) that go into the issues. These are being prepared from presentation at the upcoming IETF 71 meeting March 10-14 in Philadelphia, so if you are attending the event you’ll be able to hear the presentation yourself.

    Peer-to-peer SIP is a fascinating area of current research and it’s good to see work like this being put into exploring the security aspects. Note – the researchers are looking for feedback so if you have comments on what you read, their contact information is in the Internet-Draft.

    Technorati Tags:
    , , , , , , ,