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:
Here's a teaser: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.
1 The Attack
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 188.8.131.52:3808
INVITE sip:firstname.lastname@example.org;transport=udp SIP/2.0
Via: SIP/2.0/UDP 184.108.40.206:3808;branch=100100101101011111101110
CSeq: 1 INVITE
Allow: ACK, BYE, CANCEL, INFO, INVITE, MESSAGE, NOTIFY, OPTIONS, PRACK, REFER, REGISTER, SUBSCRIBE, UPDATE, PUBLISH
User-Agent: X-Lite release 1006e stamp 34025
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 220.127.116.11 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