Re: How common are wide open SIP gateways?

[John Todd <jtodd () loligo com>]

On Feb 5, 2010, at 1:27 PM, Scott Howard wrote:

> On Fri, Feb 5, 2010 at 9:45 AM, David Birnbaum <davidb () pins net>  
> wrote:
> > We have noticed a lot of issues with Asterisk 1.2 and some 1.4  
> > rollouts.
> > FreePBX had some truck-sized holes in it.
>
> Most/all of the big issues that existed in previous version of
> Asterisk/FreePBX have been resolved in later releases.
>
> The majority of the "stolen SIP" cases I've heard of have come down to
> brute forcing of often very insecure passwords - quite often stupid
> insecure passwords like the same as the username.  And of course the
> username itself is normally the extension, which makes is relatively
> easy to guess (if "100" doesn't exist, then "200" or "1000" probably
> does, etc).
>
> Then there's the issue of unencrypted/unsecured phone provisioning
> files, complete with SIP usernames/passwords,  hosted on internet
> webservers - often with the only security being your ability to guess
> the MAC address...
>
> > On our relatively small client base, we are seing SIP probing on  
> > more or
> > less a non-stop basis, and some of our customers have been hacked  
> > over the
>
> Presuming you're running Asterisk, fail2ban can help.  The only real
> issue I've had with it is that many softphones will repeated try to
> register if you get the password wrong, so a user entering their
> username/password even only once will get them blocked for X minutes.
>
>  Scott


I'll second Scott's comments, and add a few.

SIP servers aren't much good unless they're "wide open", if you're  
serving to a large number of diverse users whose networks you do not  
control with a VPN or a customized client.  This invites probing to  
determine identity choice weakness.  It seems that new SIP servers are  
discovered within about 5 days of being put up without filtering, at  
least looking at my logs.

The most commonly-available toolset for such attacks seems to have  
moved SIP attacks into script-kiddie land about a year and a half  
ago.  The tool has three functions: scan for SIP servers (UDP 5060),  
identify SIP identities via login failure or other error message  
information leakage, and lastly guess passwords in brute-force manners  
on those identified SIP extensions.

The attacks seem to be geographically diverse - I've seen originations  
both in North America as well as non-NA origins, though the ultimate  
origin is often a mystery due to compromised servers being used for  
probe sweeps.  The attacks also seem to have a variety of purposes.   
The four that I've most commonly seen are:

 1) Experimenting, "joy riders".
 2) Attacking to obtain free international long distance
 3) Attacking to obtain access into the PBX network with fraudulent  
identity to perform fraudulent internal activity ("This is Bob from  
accounting...")
 4) Attacking to create large numbers of domestic calls for phishing  
scams ("This is your bank.  Please enter your credit card number now.")

Of these, #4 seems to be the only one that gets significant attention  
of LEA resources.

I wrote some notes for security basics on this a while back as it  
pertains to Asterisk in particular, but the problem remains with some  
very old installations that accept inbound calls into the default  
Asterisk context (which is not a "bug", but really a configuration  
error) or it crops up anew with administrators who do not adequately  
create sufficiently random SIP identities and passwords.  Asterisk is  
fairly robust against such attacks, but often the flexibility of a  
complex system allows administrators to inadvertently expose  
themselves in ways they wouldn't ordinarily think about.  More here:

  http://blogs.digium.com/2009/03/28/sip-security/

As far as network impacts: some of these probes are fairly significant  
in bandwidth consumption (3-5 mbps, from what I've seen) and may cause  
problems with whatever your SIP authentication method is due to the  
volume of requests.   A distributed attack at higher volumes has less  
chance of success because most SIP platforms do not have the ability  
to respond to high volumes of requests anyway.  Fail2Ban can be  
implemented on most SIP platforms at the application level, and works  
quite well against most probe methods.

I can't even comment on the issue of unencrypted/unauthenticated  
provisioning servers.  If you're provisioning in an unauthenticated  
way across the "big" internet, then... well, you takes yer chances.


Lastly: SIP is very flexible in handling alternate ports for  
communications in URIs or other pointers, though I have never seen a  
SIP server using anything other than 5060/5061.  Perhaps related, I've  
never seen a suspicious system probing on 5060 looking at any other  
ports.  Maybe changing ports would siipmly solve problems pretty  
quickly for people seeing attacks who have some ability to influence/ 
configure their end devices or trunking peers.  (At least, for a  
little while.  Remember: when chased by a bear, you just need to be  
faster than the guy behind you.)

JT