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

[Bruno FAVRE]

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