Witnessing an attack on an Asterisk server / 2009-02-05

Recently I was busy configuring the home asterisk server and I used a softphone to test connected to the demo server I run for several asterisk projects. It all started to work, I could leave voicemail, retrieve voicemail, delete voicemail. Great. Because I was debugging stuff, I had several asterisk consoles open to view messages about my tests.

That demo-server is connected to the internet-at-large. The idea is that one can take a sip-client and 'dial' sip:eham@idefix.net and hear the latest weather. So there is an Asterisk context for guest sip callers. It also has a few accounts for other tests.

While working on my stuff I suddenly saw lots of messages on the console of the demo-server. Loads and loads about failed registrations. Constantly flooding messages. Just as I was to going to tcpdump the traffic to save it it stopped: less than 10 minutes.

Log entries from the attack

I'm not going to post all 19511 entries.
First, what seems to be a probe:

Feb  3 22:54:31 NOTICE[28514] chan_sip.c: Registration from '"613430211"<sip:613430211@xxx.yyy.zzz.xxx>' failed for '86.72.2.248' - Username/auth name mismatch

Then, possible accounts are enumerated:

Feb  3 22:54:31 NOTICE[28514] chan_sip.c: Registration from '"0"<sip:0@xxx.yyy.zzz.xxx>' failed for '86.72.2.248' - Username/auth name mismatch
Feb  3 22:54:31 NOTICE[28514] chan_sip.c: Registration from '"1"<sip:1@xxx.yyy.zzz.xxx>' failed for '86.72.2.248' - Username/auth name mismatch
Feb  3 22:54:31 NOTICE[28514] chan_sip.c: Registration from '"2"<sip:2@xxx.yyy.zzz.xxx>' failed for '86.72.2.248' - Username/auth name mismatch
Feb  3 22:54:31 NOTICE[28514] chan_sip.c: Registration from '"3"<sip:3@xxx.yyy.zzz.xxx>' failed for '86.72.2.248' - Username/auth name mismatch
Feb  3 22:54:31 NOTICE[28514] chan_sip.c: Registration from '"4"<sip:4@xxx.yyy.zzz.xxx>' failed for '86.72.2.248' - Username/auth name mismatch
Feb  3 22:54:31 NOTICE[28514] chan_sip.c: Registration from '"5"<sip:5@xxx.yyy.zzz.xxx>' failed for '86.72.2.248' - Username/auth name mismatch

Running through the numbers:

Feb  3 22:54:32 NOTICE[28514] chan_sip.c: Registration from '"98"<sip:98@xxx.yyy.zzz.xxx>' failed for '86.72.2.248' - Username/auth name mismatch
Feb  3 22:54:32 NOTICE[28514] chan_sip.c: Registration from '"99"<sip:99@xxx.yyy.zzz.xxx>' failed for '86.72.2.248' - Username/auth name mismatch
Feb  3 22:54:32 NOTICE[28514] chan_sip.c: Registration from '"100"<sip:100@xxx.yyy.zzz.xxx>' failed for '86.72.2.248' - Username/auth name mismatch
Feb  3 22:54:32 NOTICE[28514] chan_sip.c: Registration from '"101"<sip:101@xxx.yyy.zzz.xxx>' failed for '86.72.2.248' - Username/auth name mismatch
Feb  3 22:54:32 NOTICE[28514] chan_sip.c: Registration from '"102"<sip:102@xxx.yyy.zzz.xxx>' failed for '86.72.2.248' - Username/auth name mismatch

Only giving up at:

Feb  3 22:56:12 NOTICE[28514] chan_sip.c: Registration from '"9993"<sip:9993@xxx.yyy.zzz.xxx>' failed for '86.72.2.248' - Username/auth name mismatch
Feb  3 22:56:12 NOTICE[28514] chan_sip.c: Registration from '"9994"<sip:9994@xxx.yyy.zzz.xxx>' failed for '86.72.2.248' - Username/auth name mismatch
Feb  3 22:56:12 NOTICE[28514] chan_sip.c: Registration from '"9995"<sip:9995@xxx.yyy.zzz.xxx>' failed for '86.72.2.248' - Username/auth name mismatch
Feb  3 22:56:12 NOTICE[28514] chan_sip.c: Registration from '"9996"<sip:9996@xxx.yyy.zzz.xxx>' failed for '86.72.2.248' - Username/auth name mismatch
Feb  3 22:56:12 NOTICE[28514] chan_sip.c: Registration from '"9997"<sip:9997@xxx.yyy.zzz.xxx>' failed for '86.72.2.248' - Username/auth name mismatch
Feb  3 22:56:12 NOTICE[28514] chan_sip.c: Registration from '"9998"<sip:9998@xxx.yyy.zzz.xxx>' failed for '86.72.2.248' - Username/auth name mismatch
Feb  3 22:56:12 NOTICE[28514] chan_sip.c: Registration from '"9999"<sip:9999@xxx.yyy.zzz.xxx>' failed for '86.72.2.248' - Username/auth name mismatch

It seems the reply tells the difference between valid and invalid account, because the attacker knows the valid accounts seen and starts trying those, probably trying to guess the password:

Feb  3 22:56:30 NOTICE[28514] chan_sip.c: Registration from '"1082"<sip:1082@xxx.yyy.zzz.xxx>' failed for '86.72.2.248' - Wrong password
Feb  3 22:56:30 NOTICE[28514] chan_sip.c: Registration from '"1082"<sip:1082@xxx.yyy.zzz.xxx>' failed for '86.72.2.248' - Wrong password
Feb  3 22:56:30 NOTICE[28514] chan_sip.c: Registration from '"1082"<sip:1082@xxx.yyy.zzz.xxx>' failed for '86.72.2.248' - Wrong password
Feb  3 22:56:30 NOTICE[28514] chan_sip.c: Registration from '"1082"<sip:1082@xxx.yyy.zzz.xxx>' failed for '86.72.2.248' - Wrong password
Feb  3 22:56:30 NOTICE[28514] chan_sip.c: Registration from '"1082"<sip:1082@xxx.yyy.zzz.xxx>' failed for '86.72.2.248' - Wrong password
Feb  3 22:56:30 NOTICE[28514] chan_sip.c: Registration from '"1082"<sip:1082@xxx.yyy.zzz.xxx>' failed for '86.72.2.248' - Wrong password

The interesting difference: 98 tries for account 1082 and 9612 for account 1071. All failed: I guess using pwgen for sip passwords was a good idea after all.

It's a fast attack

Less than 10 minutes and if I would have had any weak passwords on one of the sip accounts I would have been toast. Most probable use of a found account: trying to call internationally on my dime.

I would almost consider setting up a dummy account with a bad password that would end up in a context where I just log all numbers tried. Almost.

What tools were probably used

Quite likely SIPVicious. I downloaded it myself and tried it on an asterisk server and got the same patterns in the logs. Using svwar you can map valid extension numbers and whether they need authorization and feed those to svcrack with a file of possible passwords.

How to defend against this

First of all: don't expose your SIP server to the Internet unless you really have good reasons to do so. And this is an interesting conflict: interesting SIP peering tricks depend on open access to your SIP port. But, at least Asterisk has an option to somewhat open yourself to the Internet at large but keep your own phones limited to your internal network: use deny and permit based acls.

Give your SIP accounts good passwords. Use pwgen or another password generating tool. A good reason to use automatic provisioning tools were both the configfile for the phone and the SIP account are autogenerated: you can use complicated generated passwords for your SIP accounts, add them to your PBX config automatically, add them to the phone config automatically and only the phone and the PBX need to know... that at least keeps out external attackers. The phone can still read the password from the config so an attacker with access to the config files can get at them too. And your provisioning tools can clean out any unused phone accounts so dormant accounts aren't abused either.