First of all, before I go on and add additional information on the previous post – I’d like to do one thing – sound the ALL CLEAR alarm signal. It would appear that while the Humbug engine had identified an anomaly, it had identified something that was out there for some time now, was catered by Asterisk internally – however, we didn’t have a clear indication of what it looks like as the attack is going on. And now, with a bit more details.

Thanks to a highly vigilant group of Humbug and Asterisk users and developers, the post that we’ve put up last week had generated some serious web/mail traffic. When I say serious, my personal mailbox had received over 1000 emails within 72 hours of posting that post – which is an amazing number in my personal box. So, during the weekend I sat down to ascertain what we are seeing. In order to do so, I’ve dug up some old (and I do mean OLD!) Asterisk PBX images that I had. These images were of PBX systems that were hacked in some manner, in the course of 2009 till 2011. Each PBX was imaged into a VMWARE environment and what I tried was simply to utilize the same format that Humbug had picked up, in order to validate the outcome. It would appear that the hack attempt is related to the CDR XSS security bug that was fixed a few months ago and that was previously handled by FreePBX – so that negates our initial assumption from our previous post – however, not completely and I’ll explain why in a moment.

So, what did I find out over the weekend – the integrators “If it ain’t broken – don’t fix it” methodology is to blame for this. Most Asterisk integrators, I’m really sorry to say, do a fairly dirty job. They usually download a tool like Elastix or trixbox, install it, configure it and be done with it. In this case, the hack was successfully executed on systems that were running Asterisk 1.2.X and early 1.4.X versions – of course. Now, if your integrator doesn’t care to upgrade your system, left port UDP/5060 and TCP/80 open to the world – don’t be surprised if some form of flat worm crawls up and bites the system from that area.

So, how does this relate to FreePBX? simple – again the integrators. Some integrators like to portray themselves as vendors – that’s fine, as long as you have a clue about what you do. One of the systems that I tested over the weekend had exhibited some fairly weird behavior, specifically, it was performing the ‘wget’ while running the dialparties FreePBX script – which was very odd for me, as it wasn’t supposed to do that. What I noticed was that dialparties script was modified by the integrator, to perform some funky caller ID and destination mangling and as a result, had executed arbitrary code. Now, while the actual affect on the system was the result of the CDR XSS, this had also raised an eyebrow – however, when an integrator changes PHP code that he doesn’t fully understand – expect funky stuff to happen.

So, let’s say you have a really old Asterisk system (Asterisk 1.2.X, Old trixbox, God Forbid Asterisk@Home, etc) – here are some recommendations on how to protect yourselves from these attacks:

• Allow access to port UDP 5060 to only authorized systems – If your system is for internal use only, there is no use of allowing access from the world to the UDP/5060 port. Open access from your providers only, that should protect you at the preliminary level.
• Mobile workers should access via a VPN – it may be a hassle, but if you have mobile clients such as soft phones, have a VPN installed on the persons computer or cellphone – even a simple PPTP or L2TP VPN will do in most cases.
• Disable guest SIP access to your Asterisk system – this is always a good practice. If you use services such as DIDX, DIDWW or other DID providers around the world and you are allowing them access via the SIP Guest access, don’t be surprised if other people come in the front door as well.
• Accountability is everything – when a hacker hacks in, once they exploit the system, they’ll do their best to erase their tracks. CDR records are not bullet proof, using the same attack they can be deleted and manipulated. Utilizing an external tool, such as Humbug or an external syslog facility can assist you in accounting for the hack attempt and proving to your carrier that you were robbed – and to your insurance company.
• Update your system – well, don’t go about and install every little Asterisk patch that exists. If your system works for you and there are no security fixes, usually that is not required. If a security fix was issued, to your best to update your system as fast as possible.

And I believe the best advice would be – stay alert and vigilant. The fact that you are not paranoid, doesn’t mean that they are not out to get you. If you put a server onto the internet with a password of 123456, it takes less than 12 hours for the server go get hacked/hijacked and utilized.