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

[Jim Donovan]

Hi John - Thanks for sharing the details of this attack.   This attack
(and similar ones) are specifically why SIP firewall technology has been
developed.  Covergence is an example of a company providing this
capability (we have a library of policies in our SIP Session Manager
product that address your example and many other ones like it).
Although many network firewalls claim to be "SIP-aware", they are simply
not going to be able to stop the type of SIP-specific attack you
describe below.   SIP firewall functionality, whether used as a
complimentary device to a network firewall, or embedded in a Session
Border Controller, is the only effective way of detecting and preventing
this sort of problem.   In summary, I agree 100% with you that a more
complete solution to VoIP security would be to use a dampening system
(i.e. SIP firewall technology) to address type the types of attacks you
describe.   

Jim
jdonovan at covergence.com      

-----Original Message-----
From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org] On
Behalf Of John Todd
Sent: Wednesday, May 24, 2006 2:07 AM
To: voipsec at voipsa.org
Subject: [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