2

I am running: FreePBX 12.0.76.2 Asterisk 11.18.0 FreePBX 64bit distro 6.12.65

I have many POTS lines for incoming and outgoing calls, and a Twilio SIP trunk for outbound International calls.

I just had repeated calls from three different caller IDs from southern California that attempted to call many internal extensions in our company. Employees receiving the call would hear an "underwater garble of digital tones" and then a hangup. Then these callers discovered some way to dial hundreds of dollars of international calls being made through both my Twilio and my local POTS lines. Destinations were Burkina Faso and Philippines mobile numbers (about three of them called repeatedly, some successful for 15 minutes, some 4 minutes and most were not answered).

I saw there was a vulnerability into the AMI, but I've had that patched since the patch came out.

I blacklisted the phone numbers that were calling in (using the blacklist module) and this stopped the calls. But I still don't know what vulnerability they managed to exploit.

In the CDR I do see the context they seem to be using when they make the outbound calls, "macro-dial-one" and then "from-internal-xfer" or "from-trunk-sip-TwilioTrunkOutB".

This same thing happened to our old FreePBX that was running PIAF v1.2.9, Asterisk 1.4.21.2, except they seemed to take advantage of a Misc Destination to a cell phone (since removed) that somehow allowed them to call international numbers from our system. So it doesn't seem to be related to any remote code execution or escalation of privilages. It is some IVR exploit.

Any ideas how this could happen? I have google searched every combination I can and have not seen any mentions of this exploit.

Megan Speir
  • 3,745
  • 1
  • 15
  • 25
ITIA
  • 123
  • 2
  • 8
  • if you have it, can you capture and post the full output of the rouge call flow from the console? It sounds like someone has found a way in either via DISA/SIP/IAX or an internal ext with a DDI that allows transfer to pstn. – user3788685 Apr 13 '16 at 16:56

1 Answers1

5

Resolved!!!

When I turned on DTMF under "FreePBX web gui / Settings / Asterisk Log File Settings" which saves in Asterisk's /var/log/asterisk/full.log, I caught the offender dialing random extensions until they got a valid one, and the moment an employee picked up, they dialed *2 (In-Call Asterisk Attended Transfer), which is intended for our employees to dial. the moment the offender dials *2, Asterisk gives them control of transferring the call (whereupon they can dial out any number they wish), giving our employee silence and then a hangup, and the offender continues with his international (free) call, and once that call is done they hit *2 again and dial another international call.

Ouch. How painful.

Solution 1: So in "FreePBX web gui / Admin / Feature Codes" you can disable *2 and ## (and any other useless feature codes that could possibly be taken advantage of by a bot).

Solution 2: In "FreePBX web gui / Settings / Advanced Settings / Dialplan and Operational / Asterisk Dial Options & Asterisk Outbound Trunk Dial Options" you can remove "Tt" on both and leave the first one with "r" (which edits the defaults on every trunk... unless you bypassed this on any trunk). And make sure to push the green check mark next to each and hit the big red "Apply Config". I tested re-enabling the *2 and ## features, and this change cut them off as well.

I chose to apply both solutions.

Thanks guys for your help and I hope this helps anyone else being hacked with toll fraud, redialing, war dialing, or whatever they are calling this. And to hell with the fraud calling card companies or hackers using this vulnerability!

Note: I actually listened in on one of these calls (with ChanSpy) and found myself in a two-way communication in Spanish with someone in Philippines. It must be a shady calling card service piggy backing on unsuspecting Asterisk victims. Shame. I hope my many postings on this issue gets properly indexed on Google so everyone else experiencing this will know how to fill the hole.

EDIT: After filing a ticket with FreePBX, they hopped on it and will have a fix out in a few days (as of 13 April 2016) that gives you the option to limit the "T" option to internal staff calling out of the system. Callers in will have "T" removed from the Dial() parameters no matter what. Apparently they can't just remove the default "Tt" parameter from their distros because there are many users that require that functionality for their situation. It's apparently been an issue since day one of Asterisk.

ITIA
  • 123
  • 2
  • 8