Heya, Has anyone done any research or have any anecdotal numbers related to how common it is to have a SIP gateway sitting out on the Internet with no ACL or authentication? Recently we have noticed a couple of instances where we get abuse complaints from companies who claim that one of our hosting clients 'stole SIP service' from them. This reminds me somewhat of the 'SMTP open relay' days. We obviously take action and shut the offending user down but I can't help but wonder how common this practice is. Usually I just ask the company why their system allows anyone to use their SIP gateway and they usually say something like "We can't predict what IP our users will come in from... etc" I am just wondering if anyone else has noticed this trend. -Drew
On 2/5/10 9:33 AM, Drew Weaver wrote:
Heya,
Has anyone done any research or have any anecdotal numbers related to how common it is to have a SIP gateway sitting out on the Internet with no ACL or authentication? Recently we have noticed a couple of instances where we get abuse complaints from companies who claim that one of our hosting clients 'stole SIP service' from them. This reminds me somewhat of the 'SMTP open relay' days. We obviously take action and shut the offending user down but I can't help but wonder how common this practice is. Usually I just ask the company why their system allows anyone to use their SIP gateway and they usually say something like "We can't predict what IP our users will come in from... etc"
I am just wondering if anyone else has noticed this trend.
While it's true you can't predict the source IP when you have remote users with dynamic IP (think SIP at home or softphone on the road), that's no reason to omot basic MD5 digest auth. ~Seth
If you are using Asterisk (and many derived PBXs), and your installation is old enough, and your default context will complete a call...then you may find you are giving free calling out. This was fixed at some point in the Asterisk default configuration files. We have noticed a lot of issues with Asterisk 1.2 and some 1.4 rollouts. FreePBX had some truck-sized holes in it. 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 years. It's definitely increasing - the modern equivilent of the open-DISA access many old PBX/VMs offer. On the plus side, they ususal start calling North Korea or Somalia or something which triggers the alarms, so they get shut down right away; we offer a default "Axis of Evil" block to stop international calling to the high-fraud countries that are out there and only allow calling there upon customer request. I wouldn't be at all surprised to find much cleverer people that have hacked PBXs and are making calls at a moderate pace to domestic or other inexpensive areas as to avoid detection. Cheers, David. ----- On Fri, 5 Feb 2010, Drew Weaver wrote:
Heya,
Has anyone done any research or have any anecdotal numbers related to how common it is to have a SIP gateway sitting out on the Internet with no ACL or authentication? Recently we have noticed a couple of instances where we get abuse complaints from companies who claim that one of our hosting clients 'stole SIP service' from them. This reminds me somewhat of the 'SMTP open relay' days. We obviously take action and shut the offending user down but I can't help but wonder how common this practice is. Usually I just ask the company why their system allows anyone to use their SIP gateway and they usually say something like "We can't predict what IP our users will come in from... etc"
I am just wondering if anyone else has noticed this trend.
-Drew
On Fri, Feb 05, 2010 at 12:45:13PM -0500, David Birnbaum 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.
FreePBX 2.6.0 defaults to refusing anonymous SIP calls. If you enable inbound anonymous calls, it includes only the "from-trunk" context, making it behave like a standard incoming over over a configured trunk. If you've configured FreePBX to allow outgoing calls from the trunk context, you have larger problems in general. -- Brandon Ewing (nicotine@warningg.com)
I should have prefaced that with "older installations" as well. As far as we can see, most of the newer packages have fixed the known truck-sized holes in their default configurations, but given the lack of any formal framework for testing this stuff, even the "big" switches have been found to have security issues from time to time. I have to admit I was surprised at the number of people I've run into over the years who unpacked Asterisk, played with a few phones, and stuck themselves on the Internet without any clear understanding of how exposed they are. Cheers, David. ----- On Fri, 5 Feb 2010, Brandon Ewing wrote:
On Fri, Feb 05, 2010 at 12:45:13PM -0500, David Birnbaum 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.
FreePBX 2.6.0 defaults to refusing anonymous SIP calls. If you enable inbound anonymous calls, it includes only the "from-trunk" context, making it behave like a standard incoming over over a configured trunk. If you've configured FreePBX to allow outgoing calls from the trunk context, you have larger problems in general.
-- Brandon Ewing (nicotine@warningg.com)
Eventually I'll have to get around to setting up netflow so I can detect the scanners before it becomes a problem =) Just not a great deal of 'cohesiveness' with the current open source netflow implementations, and then all of the different Cisco gear has different caveats related to NF, so it's hard to use that as a good way to detect this sort of thing, although I'm guessing it can't be too hard to figure out which hosts are making a bunch of outbound connections to random IPs on 5060 =) -Drew -----Original Message----- From: David Birnbaum [mailto:davidb@pins.net] Sent: Friday, February 05, 2010 1:22 PM To: Brandon Ewing Cc: nanog@nanog.org Subject: Re: How common are wide open SIP gateways? I should have prefaced that with "older installations" as well. As far as we can see, most of the newer packages have fixed the known truck-sized holes in their default configurations, but given the lack of any formal framework for testing this stuff, even the "big" switches have been found to have security issues from time to time. I have to admit I was surprised at the number of people I've run into over the years who unpacked Asterisk, played with a few phones, and stuck themselves on the Internet without any clear understanding of how exposed they are. Cheers, David. ----- On Fri, 5 Feb 2010, Brandon Ewing wrote:
On Fri, Feb 05, 2010 at 12:45:13PM -0500, David Birnbaum 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.
FreePBX 2.6.0 defaults to refusing anonymous SIP calls. If you enable inbound anonymous calls, it includes only the "from-trunk" context, making it behave like a standard incoming over over a configured trunk. If you've configured FreePBX to allow outgoing calls from the trunk context, you have larger problems in general.
-- Brandon Ewing (nicotine@warningg.com)
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
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
On Fri, 5 Feb 2010, Drew Weaver wrote:
Has anyone done any research or have any anecdotal numbers related to how common it is to have a SIP gateway sitting out on the Internet with no ACL or authentication? Recently we have noticed a couple of instances where we get abuse complaints from companies who claim that one of our hosting clients 'stole SIP service' from them. This reminds me somewhat of the 'SMTP open relay' days. We obviously take action and shut the offending user down but I can't help but wonder how common this practice is. Usually I just ask the company why their system allows anyone to use their SIP gateway and they usually say something like "We can't predict what IP our users will come in from... etc"
Just because one of your users stole SIP service from a site doesn't mean their gateway doesn't do authenticate. We operate a number of SIP gateways, some of which do need to be relatively wide open ACL-wise. Like any other service, good usernames and passwords are a must. I've seen people trying to brute force SIP access on our servers just as they do with SSH (if you leave that open) or POP3. Stealing phone service is nothing new. SIP's just the latest vector for it. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On 05/02/2010 17:33, Drew Weaver wrote:
Has anyone done any research or have any anecdotal numbers related to how common it is to have a SIP gateway sitting out on the Internet with no ACL or authentication? Recently we have noticed a couple of instances where we get abuse complaints from companies who claim that one of our hosting clients 'stole SIP service' from them. This reminds me somewhat of the 'SMTP open relay' days. We obviously take action and shut the offending user down but I can't help but wonder how common this practice is. Usually I just ask the company why their system allows anyone to use their SIP gateway and they usually say something like "We can't predict what IP our users will come in from... etc"
I am just wondering if anyone else has noticed this trend.
If you register your phone numbers in e164.arpa it is pretty useless adding records for a sip server that requires authentication because hardly anybody is going to be able to reach you! (e164.arpa provides phone number to service mapping, like ip6.arpa provides ipv6 address to hostname mapping)
On 05/02/2010 17:33, Drew Weaver wrote:
Has anyone done any research or have any anecdotal numbers related to how common it is to have a SIP gateway sitting out on the Internet with no ACL or authentication? Recently we have noticed a couple of instances where we get abuse complaints from companies who claim that one of our hosting clients 'stole SIP service' from them. This reminds me somewhat of the 'SMTP open relay' days. We obviously take action and shut the offending user down but I can't help but wonder how common this practice is. Usually I just ask the company why their system allows anyone to use their SIP gateway and they usually say something like "We can't predict what IP our users will come in from... etc"
I am just wondering if anyone else has noticed this trend.
The VoiceOps mailing list (http://www.voiceops.org/) would probably have more info for you on this. Although many people are on NANOG too and may chime in. On Fri, Feb 5, 2010 at 9:50 AM, Chris Hills <chaz@chaz6.com> wrote:
If you register your phone numbers in e164.arpa it is pretty useless adding records for a sip server that requires authentication because hardly anybody is going to be able to reach you!
If the call is to Me, then I don't care about authentication. If the call is to someone else, then I require authentication. That is fairly easy to configure on every SIP platform that I have used. -Jonathan
participants (9)
-
Brandon Ewing -
Chris Hills -
David Birnbaum -
Drew Weaver -
John Todd -
Jon Lewis -
Jonathan Thurman -
Scott Howard -
Seth Mattinen