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