tag:blog.tmcnet.com,2013:/blog/tom-keating//4/tag:blog.tmcnet.com,2008:/blog/tom-keating//4.38041- 2013-02-22T21:04:40Z Comments for Analysis of a VoIP Attack VoIP & Gadgets blog - Latest news in VoIP & gadgets, wireless, mobile phones, reviews, & opinions Movable Type 4.38 tag:blog.tmcnet.com,2008:/blog/tom-keating//4.38041 2008-10-23T15:00:43Z 2008-10-23T14:55:53Z Analysis of a VoIP Attack VoIP security is often overlooked by IT administrators as well as VARs and resellers that deploy VoIP in the enterprise. They do so at their own peril, however. One of the main factors behind using VoIP is to save money.... Tom Keating http://blog.tmcnet.com/blog/tom-keating/
star-trek-deflector-shields-borg.jpg

This laissez faire towards defensive security reminds me of Star Trek, where for whatever reason the Enterprise flies through space with danger lurking around every corner but they keep their defensive deflector shields off and often turn them on when it's too late. The Enterprise has a fusion reactor with nearly limitless power, so why not keep the deflector shields on all the time? Maybe they're just being "green" and shooting for five nines (99.999%)  of efficiency.

In any event, security in general is often overlooked, whether it's securing your web server or your email server, or confidential database servers. But in most cases when these particular systems are hacked it's usually just an inconvenience (defaced web pages, spamming through your email server) with minimal financial impact. Not so when it comes to VoIP. The financial impacts of a hacked SIP server or VoIP gateway could be tremendous. This is especially true for larger organizations which already have hundreds or thousands of calls per month, including international business calls. How does accounting find the fraudulent calls in the phone bills which are 4 inches thick? It's like finding the proverbial needle in a haystack.

If the hackers are smart, they will limit the amount of traffic they route through a hacked gateway as not to set off any red flags. It could be months or possibly even years before anyone notices anything is amiss. I'm reminded of an old PBX technology called DISA (Dialed In Switch Access) which was one of hackers first tricks to get free calling. DISA was designed to allow employees to remotely call into the PBX and get second dial-tone. With this second dial-tone using touchtones they could logon to ACD queues, monitor agents calls, and of course initiate outbound calls.

In fact, many years ago, TMC was hit with a DISA-like attack on our Comdial PBX resulting in quite a few international calls. If I recall, there was a vulnerability in the Keyvoice voicemail system which allowed someone to make outbound calls. Needless to say, I was able to shut it down pretty quickly.

Part of the attack also involved using a scripted dialer which accessed the voicemail system by automatically sending the # key, then sending a chosen extension (say 100), and then iterating through all the various PINs (0000 - 9999). Since TMC has a toll-free 800 number, the attacker only has to make at most 10,000 calls to find a PIN to a particular extension. Obviously, chances are they'd find the script in much less than 10,000 calls and you get 3 tries before the voicemail hangs up. Once the PIN is found, not only does the attacker have access to the the user's voicemail, they also have access to any DISA capabilities of the voicemail system. More reason why IP-PBXs today need to have a PIN expiration feature just like Active Directory supports password expiration. No matter how many times IT staff reminds employees to change their passwords/PINs, they just don't do it unless the system forces them to. I don't believe any of the Asterisk systems I've tested have password expiration - so my open source Asterisk fans, if you're listening, add it to the code, will ya?

With all this in mind, I was fascinated to read an article by an Austrian company IPCom titled "Analysis of a VoIP Attack". It's an excellent read. Let me give you the abstract:
Recently, several IT news websites reported VoIP attacks against home users, containing lots of myths and incorrect statements. Unfortunately, they also give wrong security advices. This article analyzes the attacks and describes the motivations behind. Further, it shows simple workarounds how "insecure" software can be used in a secure way.
Here's a teaser:

1 The Attack
1.1 Analysis
On 23.09.2008, heise.de reported an attack against VoIP devices of German VoIP users [heise]. This article references a thread in the IP-Phone-Forum [ipphone] in which people report that their VoIP phones started ringing in the middle of the night and displayed incoming calls from the phone number 5199362832664. One of the users presented a log file of a Patton SIP device which captured the suspect INVITE request:

02:12:42 SIP_TR> [GW] < Stack: from 213.130.74.70:3808
INVITE sip:810525551690000@1.2.3.4;transport=udp SIP/2.0
Via: SIP/2.0/UDP 213.130.74.70:3808;branch=100100101101011111101110
00100213.130.74.701.2.3.41863480914;rport
Max-Forwards: 100
From: <sip:5199362832664@1.2.3.4>;tag=21671132663-
4985269162167113266321671132663213.130.74.70
To: <sip:810525551690000@1.2.3.4>
Call-ID: 83764811100011101110010010110101101100111001001011
0101111110111000100213.130.74.701.2.3.41863480914f
df23881052555169000021671132663-
4509759162167113266321671132663213.130.74.70174046 6380
CSeq: 1 INVITE
Contact: <sip:fdf238@213.130.74.70:3808;transport=udp>
Content-Type: application/sdp
Allow: ACK, BYE, CANCEL, INFO, INVITE, MESSAGE, NOTIFY, OPTIONS, PRACK, REFER, REGISTER, SUBSCRIBE, UPDATE, PUBLISH
User-Agent: X-Lite release 1006e stamp 34025
Content-Length: 394

Let's have a look at this SIP message. The funny thing is that absolutely nothing in this SIP message is trustworthy: Probably the SIP message has been received via UDP and the source IP address could be easily spoofed. Further, every data in the SIP message is user generated (in this case by the attacker) and does not necessarily reflect real data. Nevertheless, let us try to analyze the message:
  • Source IP address 213.130.74.70 and source port 3808: Although the IP address could be easily spoofed, in this case it may be the real address of the attacker as the IP address is also present in the Via: header (used for sending back responses). Further, if the attacker wants to know the result of the attack, he has to receive the SIP responses meaning that he has to provide his real IP address.
  • The Call-ID looks like a random string and contains the source IP address. As the Call-ID is invalid (per RFC 3261 the Call-ID must not contain spaces), it can be assumed that the attacker did not use a fullfledged SIP stack, but some scripts to generate the request.
  • The User-Agent header displays "X-Lite" as client. However, if you compare the above request with an INVITE request sent by X-Lite you will find out that the random strings (call-id, tags, branch
Ok, you've been thoroughly 'teased', now go read the full article (PDF). Good stuff!
]]> tag:blog.tmcnet.com,2008:/blog/tom-keating//4.38041-comment:40105 Comment from Ward Mundy on 2008-10-23 Ward Mundy http://nerdvittles.com/ A very timely article! When we introduced PBX in a Flash, we were the first Asterisk aggregation to include a preconfigured IPtables firewall in the default installation. But the bad guys have gotten more sophisticated. Just recently, we've added the latest release of Fail2Ban to all PBX in a Flash systems using our software update service. Fail2Ban blocks SIP and IAX attacks which are becoming more and more prevalent by locking IP addresses out of your server for a specified period of time whenever a designated number of invalid passwords are submitted. This pretty well secures most telephony systems except those where the user never bothered to change extension passwords that were preconfigured to match extension numbers.

BOTTOM LINE: If your server provides SIP or IAX access from the Internet (as most VoIP servers do), you'd better make darn sure ALL of your extension passwords are secure. After all, it's your phone bill.

]]> 2008-10-23T16:59:30Z tag:blog.tmcnet.com,2008:/blog/tom-keating//4.38041-comment:40106 Comment from Tom Keating on 2008-10-23 Tom Keating http://blog.tmcnet.com/blog/tom-keating/ Interesting stuff Ward. Neat idea to use iptables to lock out certain IP addresses for a certain period of time. I know iptables isn't "too" resource intensive, but is it OK to run on the same hardware as the phone system? Let me know your experience.

Also, any plans to add voicemail password expiration to PBX in a Flash?

Though really you'd also have to have a password expiration for the phone itself. As you know, many IP phones use the MAC address or the extension for both the username and the password when registering with the SIP server. Forcing users to periodically change the phone's password could be a chore. Either they have to logon to the phone's advanced settings (often locked by administrators) or use the web interface, which is also often password protected by admins. Giving users full access to the web interface isn't a good idea.

I suppose an outside hacker trying to guess the MAC address is very difficult since there are millions of combinations. Then again, someone "inside" the network could sniff out the IP phone's MAC addresses and then easily hack in.

What are your thoughts?

]]> 2008-10-23T17:40:59Z tag:blog.tmcnet.com,2008:/blog/tom-keating//4.38041-comment:40107 Comment from Ward Mundy on 2008-10-23 Ward Mundy http://nerdvittles.com/ At least in our Asterisk and FreePBX world, it would be fairly easy to regularly and automatically refresh extension passwords and then flash all of the phones with the new passwords. All it would take is a few days of programming time from a paying customer to cover the development work. It would be especially easy with Aastra phones which could be rebooted remotely as part of the password refresh.

]]> 2008-10-23T18:12:15Z tag:blog.tmcnet.com,2008:/blog/tom-keating//4.38041-comment:40110 Comment from cosmicwombat.myopenid.com on 2008-10-23 cosmicwombat.myopenid.com It is OK to run IPTables on the same hardware as the phone system. I'd actually say it is the correct place to place your rules as attacks happen from the inside too.

I'd like to applaud the PBX in a Flash team for being as aggressive as they have been in addressing known security holes and for providing the right tools to at least try and be a diligent VoIPologist.

I wonder how it would be to have FreePBX handle the lockdown of trunks? Regardless, it is a good idea to only allow SIP/IAX traffic to providers via IPTables and/or VPNed SIP clients.

]]> 2008-10-23T22:29:42Z