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

Mon May 29 05:33:55 CDT 2006

Hi all,

I am currently collaborating with the Tcom research group (I was
working there for a while) and we published a paper at the
last VoIP Management and Security workshop in Vancouver on this
implementation. The implementation is different from the one of the
Snocer project since we do not use the Snort rules but we use a
written-from-scratch preprocessor to analyse and block SIP DoS attacks.

You can find here http://www.noms2006.org/docs/13_Niccolini.pdf 
the presentation I gave in Vancouver where you can find some details
about the Snort preprocessor we wrote.

If you are interested in other presentaiton have a look at http://www.noms2006.org/content/workshop.html#voip

We are currently continuing the collaboration inside a Swiss-funded
project and we are adding functionalities on such preprocessor.
If you are interested to discuss about the topic or interested in
a collaboration feel free to contact me.

Cheers,
Saverio

> -----Original Message-----
> From: Voipsec-bounces at voipsa.org 
> [mailto:Voipsec-bounces at voipsa.org] On Behalf Of Bruno FAVRE
> Sent: Wednesday, May 24, 2006 4:58 PM
> To: 'John Todd'; voipsec at voipsa.org
> Subject: Re: [VOIPSEC] Attacks in the wild: brute force 
> password hacking
> 
> Hi John,
> 
> As i have previously underlined here the work-in-progress of 
> some people,
> you can find the beginig of an extension to snort to support 
> SIP exchange
> and prevent SIP-DoS.
> As they say on their web site : "These rules have been 
> developed to detect
> several DoS attacks, including INVITE / REGISTER flooding and 
> SQL injection
> attacks."
> The rules can be found here : 
> http://www.snocer.org/Paper/sip-rules.zip
> And a paper relative to the technology deployed (a thesis) is 
> available here
> (but in french, I don't kno if thez yet translate it) :
> http://www.iict.ch/Tcom/Projets/VoIP/Rapport_Kuhn.pdf
> 
> 
> Regards,
> Bruno Favre 
> 
> -----Message d'origine-----
> De : Voipsec-bounces at voipsa.org 
> [mailto:Voipsec-bounces at voipsa.org] De la
> part de John Todd
> Envoyé : mercredi 24 mai 2006 08:07
> À : voipsec at voipsa.org
> Objet : [VOIPSEC] Attacks in the wild: brute force password hacking
> 
> 
> 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
> 
> 
> _______________________________________________
> Voipsec mailing list
> Voipsec at voipsa.org
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> 