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

[Stephen Kingham]

Hi

We have also discussed similar problems and come to a similar conclusion 
for a solution, ie a damping of incoming messages.

However we have not seen such an attack yet :-|.

Stephen Kingham

John Todd wrote:
> 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
>
>
>
>
> _______________________________________________
> Voipsec mailing list
> Voipsec at voipsa.org
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
>