Asterisk PBX Hack Attack (or, how scammers hijacked my phone system to place unauthorized calls)
I was awoken by what you might say was my cell phone “blowing up.” I started getting calls from 808 numbers one after the other. I answered the first couple, and the people seemed sure that I had called them. I quickly jumped to the helm and punched up the Asterisk console. There were all these dialing attempts scrolling up my screen. I was under attack.
I’d hoped the inaugural post to this blog would be on a more introductory note, but this matter has bubbled up the chain this morning. We’ll have to get back to the pleasantries at a later time. Anyway…
Last week the wife was out of town and I was on the old coding binges throughout the week. On Thursday, as I was recouping during an early evening nap, I was awoken by what you might say was my cell phone “blowing up.” I started getting these calls from 808 numbers one after the other. I answered the first couple, and the people seemed sure that I had called them. I quickly jumped to the helm and punched up the Asterisk console. There were all these dialing attempts scrolling up my screen. I was under attack.
Identify (and block) the Attackers
My first course of action was to find the IP addresses of the attackers. That was easy using tcpdump, there were two of them in fact. So I blocked those IPs using iptables. Also easy. Done, ok. All traffic from the IPs was being silently dropped, so they couldn’t make any more connections to Asterisk and the dialout problem abated.
A basic tcpdump expression (adjust to taste) to watch SIP connections:
tcpdump port 5060
Here are the IP addresses and the iptables rules I used to block them:
iptables -A INPUT -s 188.8.131.52 -j DROP iptables -A INPUT -s 184.108.40.206 -j DROP
Through my diagnostics I’d ascertained that the attackers were able to connect to Asterisk in some way and initiate calls through the dialplan. I was a little perplexed that it seemed to be going through the dialout context that my phone extensions used, but I have a pretty complex dialplan, so I didn’t pay much attention to this fact at first. I have Asterisk scripted to set the outgoing callerID to my cell phone. So all these people that received who knows what telemarketing message, saw my CallerID info as if I had called them. Nice.
A False Conclusion and Other Remedies
A few days earlier on this Asterisk box, I’d set up an international long distance forwarder for a friend using IPKall numbers and his own SIP account. To get that working required a nominal amount of debugging, which probably meant that the sip.conf entries for those peers were probably not very optimized (a euphemistic way of saying they were not secure). I went in and identified what I thought were the vulnerabilities in those entries, locked them down to deny all but the IPKall servers to make connections through them. Cool, fixed it! I thought.
However, throughout the evening I was getting up to 5-6 return calls per minute from people in the 808. So I shut off my cell phone, which then routes all the calls to my Asterisk PBX. I put my phone extension on Do Not Disturb. My phone did not need to ring, I did not need to talk to these people. Then my voicemail box filled up. 100 messages. I moved those to another folder and I recorded a nice message that explains briefly what happened and then hangs up on anyone calling from the 808 area code.
; Send callers from the 808 area code to a recorded message exten => incoming/_808.,n,Goto(spammed)
I took my phone out of DnD. Then I started getting calls from some blocked numbers, so I implemented the privacy screening flag (‘p’) on the Dial application that connects calls to my phone. Callers with blocked CallerID have to say their name, then it rings my phone, tells me their name and I can decide to accept or reject the call (send them to voicemail, a torture script or a “do not call again” message, which I set to be the “sorry you got spammed” sound file, so I can just direct callers who I don’t know to that). Being able to manipulate the dialplan to handle these callers indirectly has taken a lot of the headache out of this for me.
These are pretty agressive tactics, but one of the things that I love about having my own Asterisk system is that I have regained control over my phone. Usually it’s used to reduce these types of spam calls from coming in, but I’m not above using it for any call handling purpose that keeps my phone from ringing unneccessarily. Bear in mind that these measures shouldn’t be necessary for more than a week or so.
At this point, I considered the problem solved. All was quiet over the weekend. In fact, I’d downloaded the CSV file of the activity from my Asterisk box, and wrote some code to parse it. It was instructive data. The scammers had placed 4390 calls in under an hour, at times hitting 150-175 calls per minute. Also, in a three hour period, I’d received approximately 134 return calls (so I estimate the return call rate at around 5%).
This data was graphed with Flot, and parsed Asterisk’s CSV-format CDR (Call Data Record) via a custom PHP script. I don’t know if my parsing script is completely accurate, and maybe some of those are call attempts and not actual placed calls. Even if the number of calls were a quarter of that, it’s still outrageous. They ran out the minutes on one of my accounts, and I’m paying minutes to field all these return calls.
Incidentally, through the few people I did talk to I learned that the calls placed were soliciting some kind of “credit service” – great, I can only imagine how that all ends up. Most of these people seemed confused or pissed off. I didn’t ask them why they call back random numbers on their CallerID, especially if they think it’s a telemarketer. Don’t do that.
Return of the Scammers
Then this morning at about 7am PST, it started up again. This time from a different IP, to a couple of new area codes. Clearly the hole was not plugged, so this time I was determined to get more information and solve the problem. First, I shut down Asterisk. Then I blocked the attacking IP. I brought Asterisk back up. I made some changes to the configuration that seemed to mitigate the dialout behavior. So I unblocked that IP, which was still attempting to make many connections. I wanted to see what he was doing.
What I found concerning was that it appeared that the scammer’s IP was registering with Asterisk. How could this be? I scoured the sip.conf file again. Several times I thought I found the issue, reloaded the sip config, but the registrations were still happening. So I brought out the big guns. I’d been dumping all the traffic to and from this IP during the entire event for later analysis, but I needed to see it immediately, so I started tethereal (included with Wireshark on Linux). To see it quickly from the terminal without it scrolling too fast I piped it through less like so:
tethereal -Ttext -V -l 'host 220.127.116.11' 2>&1 | less
That is the IP that was attacking me this morning. I’m not sure if all that syntax is really necessary, but I was in a hurry and I’ll leave further investigation those symbols to the reader. I scanned over the verbose amount of information until the problem immediately jumped out at me in one of the first few frames. (It helps a lot if you understand TCP/IP…this is not for the faint of heart! And, I probably could have just used something like “sip show debug” in Asterisk…that would have been too easy.)
The registrations were for a phone that I’d unplugged on Sunday!
So they weren’t hijacking through any guest means, they actually knew my extensions and passwords. I changed the password on that friend in sip.conf. The registrations failed twice from the scammer’s IP, and it stopped trying to register. Then it started again. I watched the traffic closely only to notice that it was now registering as another extension it seemed to know. Wow. So I changed the password for that one (in fact, all of my extensions), and it failed twice, and stopped. All was quiet.
The day I installed Asterisk, I ordered two VoIP desk phones which arrived a few days later and have been connected to Asterisk since. When I originally connected them, I set them up with really simple passwords. I guess this turned out to be a bad idea, as I am reasonably convinced that they were brute-force attacked. (They were really simple, so this was probably easy to do.) In hindsight, this was partially my fault, but I absolutely did not anticipate an attack like this. Lessons learned.
About an hour later this morning, the IP initiated a few more registration attempts, either retrying the old credentials or trying to crack new ones (I’ll follow up the pcap file later in Wireshark). It doesn’t appear that the behavior is very rapid unless it’s able to connect outgoing calls, then it starts going nuts. So maybe they were just periodically trying passwords for the last couple years and only found them last week. For all I know, these are the same scammers just using a different IP address. Anyway, now it should take them many years to randomly hit on these passwords. If this starts happening again, I’ll know that there’s something more sinister going on.
So, while it appears there are scammers out there now trying to crack SIP accounts, this didn’t start happening to me until last week, when it was apparently possible on my setup for the last couple years. I changed my passwords to values that should be sufficiently difficult to guess, so I expect that has finally put a real stop to this issue. I thought others might be interested in this information, as I’m sure I’m not the only one who’s been hosed by this. I only hope others can be as quick to respond, before these jerks waste more people’s time (and minutes).