jtodd at loligo
Feb 6, 2010, 5:11 PM
Post #11 of 11
(1339 views)
Permalink
|
|
Re: How common are wide open SIP gateways?
[In reply to]
|
|
On Feb 5, 2010, at 1:27 PM, Scott Howard wrote:
> On Fri, Feb 5, 2010 at 9:45 AM, David Birnbaum <davidb [at] pins>
> 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
|
