[VOIPSEC] Attacks in the wild: brute force password hacking

[John Todd]

I've witnessed within the last few days a brute force attack on SIP 
REGISTER requests in some type of automated fashion.  I'm wondering 
if others have seen similar issues on their networks who would be 
interested in sharing any experiences publicly or privately.

A brute-force password attack was launched against a SIP-based PBX in 
what appeared to be an attempt to guess passwords.  Queries were 
coming in about 10 per second.  Extension/identities were 
incrementing during each attempt, and it appeared that a full range 
of extensions were cycled over and over with the new password.  The 
User-Agent: string was almost certainly falsified (it reports 
"Polycom".)  I can provide more details to anyone who is interested 
in the specifics.

I don't know when this problem was discovered in relation to the time 
that it started.  The extension ranges that were being attacked were 
valid extensions, unknown to anyone other than the administrator of 
the system, which was primarily a testbed (leading to an assumption 
of random scanning for UDP 5060 responses on public IP addresses as 
the vector for the attacker.)  Some brief testing against Asterisk 
shows that there are different replies when a valid extension versus 
an invalid extension is supplied in a REGISTER attempt (no surprise 
there, since an unknown user will result in an immediate "404" error 
upon REGISTER attempt, while a known user but bad nonce during 
REGISTER will result in a "401" error.)  Therefore, it may be the 
case that the attacker scanned a large number of sequential or random 
extensions until a valid range was discovered, then the range was 
narrowed and password brute-force attacks started once valid SIP 
identities were established.  This is a guess, but it fits the 
evidence at hand.

While Asterisk was the platform under attack, this is not an 
Asterisk-specific attack method.  The brute-force method used is 
applicable to any SIP registrar/proxy that accepts and processes such 
requests.  The method by which the attacker may have obtained valid 
SIP peers (presentities) on Asterisk has been identified, and 
Asterisk has since been patched (SVN-TRUNK and 1.2 TRUNK) to include 
a method that allows administrators to obscure SIP response codes on 
INVITE, SUBSCRIBE, and REGISTER from 404 to 401 in the case of 
non-existant hosts ("alwaysauthreject" option in sip.conf.)  Thanks 
to Kevin Fleming for quick turnaround on this.  While Asterisk does 
not seem from current evidence to be vulnerable to any particular 
password attack method, it is the case that previous versions to 
today are farm-able for valid extensions on which attacks may be 
attempted.

The attack does not seem to be a "bot" attack, as only one IP address 
was originating requests, but of course that can quickly change based 
on the intent of the attacker and their resource availability. 
Blocking the attack is simply performed with an IP address filter on 
the router or filter table on the host.  However, this is obviously 
insufficient for larger scale problems where multiple attacking hosts 
or targets are involved.  A more complete solution has been discussed 
which would involve a dampening system that would slow replies (or 
ignore requests) for any authentication methods for individual 
presentities based on frequency of requests for that presentity or 
frequency of requests from that originating host.  Are there comments 
on the usefulness or validity of such a dampening system?  Has anyone 
deployed such a system already, and could you speak to the results of 
such a method?

JT



Example packets (not a full transaction, IP addresses obscured) look like this:

Origin (SIP UA): 10.1.1.1
Destination (SIP registrar): 172.16.16.16

REGISTER sip:171.16.16.16;transport=udp SIP/2.0
Via: SIP/2.0/UDP 10.1.1.1:1025;branch=z9hG4bKa53940dcDB34E039
From: "2665" <sip:2665 at 171.16.16.16>;tag=52F481E6-70A248F5
To: <sip:2665 at 171.16.16.16>
CSeq: 1 REGISTER
Call-ID: 9c0014fa-b7ec2828-facb896f at 10.0.100.14
Contact: <sip:2665 at 10.1.1.1:1025;transport=udp>;methods="INVITE, ACK, 
BYE, CANCEL, OPTIONS, INFO, MESSAGE, SUBSCRIBE, NOTIFY, PRACK, 
UPDATE, REFER"
User-Agent: PolycomSoundPointIP-SPIP_600-UA/1.3.0
Max-Forwards: 70
Expires: 3600
Content-Length: 0