SIPvicious Attacks on SIP Devices & Peers

[ralph]

I put this in the "Non-Mitel Chatter" section because it could easily apply to just about everything.

Here's the set up:
This AM I got a ticket for a customer that said console went nuts.  She'd answer a call and it would be dead air.  The console then said it had 54 calls waiting.   She ended up answering and hanging up on most of them and then phones all around the office starting ringing.  (Think about the movie Lawn Mower Man)  She finally put the system in night mode to get a break.   It wasn't happening this AM so I simply went through the logs.  The logs showed hundreds of calls coming in to all kinds of extensions and voice mail.   It appeared to be a problem with the carrier to me that resolved it self.   I did a DTS read on the logs and there was no issues on the span - but it wouldn't have been a span problem because of it ringing so many different phones.   I simply chalked it up to a carrier issue and agreed with customer to leave ticket open.

Then, I got another ticket from a different customer.   Found the same thing in there system, but because of their feature set a call went out twice to my primary contact's cell phone.   The caller ID read SIPVicious.   The customer told me they had the same carrier that the 1st customer was using.   I verified that the call went out through the PBX.   Again the SMDR logs show dozens of calls to internal extensions.

Fortunately my systems have pretty tight security only allowing what needs to go out, go out.

I did a quick google search and found this blog.

It turns out that my customers are using 'flex' circuits.   This appears to be a SIP hack attempt.  The hacker scans for SIP responses and then applies a couple of tools to find a weak passwords for SIP.   Once a password is found, if security isn't tight enough, they will be able to set up a system to use your customers SIP trunks.   (Bear in mind this applies especially to SIP devices)

The blog has a short video on how it's done and where to dl the software.

So this is a big warning to be sure your security is tight because if there's a hole it's going to be found.

If you're not familiar with my ARS security programming recommendations you should at least read this.

Ralph

[dilkie]

Hi Ralph,

I'm a bit confused with your description. You say a "SIP hack attempt" but not against what. Was the attempt made against Mitel gear or the SIP trunking provider or the SIP trunk betweent he two?

Do you have MBG deployed between the MCD and the SIP trunk provider?

[ralph]

The carrier delivers voice traffic to a SIP router on customer prem and hands off via PRI to us. 
We call that a 'Flex' Circ.
The attack was against the carriers router.

After my last post I called the carrier involved.  When I explained what I saw they knew exactly what I was talking about.
In my opinion, the carriers router should not be responding to anything other than their own servers so these types of hacking tools wont get a response.

Ralph

[dilkie]

thanks for the education, learned something today.

Yes, I agree, the link between the customer prem equipment and the carrier should be 'locked down' to prevent this. I'm surprised it isn't.

[ralph]

Happened with me with two customers, same day, same carrier.

So lets say that one of these customers was successfully hacked and the bad guys set up a router (or an astrisk box) and made thousands of dollars in international calling via this spoofed router.   How do you prove this wasn't a hack through your system?   I can see a huge problem bubbling up...

Ralph

[wilsonjc]

We are a sip provider and system installer (by god that makes things much easier!) but most devices ( even your media gateway type devices) have fire-walling built in, if not most are linux based (usually debian, with some asterix type add-on) you can add your own ip table rules to stop that.

If you are feeling particularly devious, you can setup fail2ban or indeed ip tables to limit the number of connects per second, (in our experience people trying to hack sip trunks, rarely are polite and just try one call).

I don't want to bore you all with details linuxy details, but if you would like them just holler,

You can always use sipvicious against yourself, its a very easy way to make sure you are relatively safe,

John

[ralph]

You can always use sipvicious against yourself, its a very easy way to make sure you are relatively safe,

This may be something we want to do as a normal service process.   If carriers don't secure their own equipment, how else would you know?

Ralph

[ralph]

I'll put this update here since I suspect it's related.
I've been made aware that there is an ongoing series of denial of service attacks against 911 centers and other emergency services centers.    I'll explain why I think this is related to the SIPvicious tools in a sec.

What happens is, a 911 service center will receive a call demanding large sums of money or they will shut their service down.   When the money is refused all lines begin to ring in incessantly.   If you answer the call it is simply dead air.   This can go on for days or until the carrier can block the IP of the device doing it. krebsonsecurity.com/wp-content/uploads/2013/04/DHSEM-16-SAU-01-LEO.pdf

I believe this is related to the SIPvicious tool because, putting 1 and 1 together, if a carrier's router is compromised it can be used for this DOS attack and may not be traceable to the source.   

So bottom line is, it may not be a bad idea to test the routers yourselves to be sure their secure.   Or at least confirm with the carrier their routers are only accessible to their servers.   I've also read a recent article where it was found that at least one carrier is not even changing the default password on the routers they install.

Ralph

[cmeilleur]

Ralph,

I Am comming for the Carrier side of things and we see sip viscous attatcks all the time.  Usually they are scan's done in ip netblocks all in close succession.  This is likely why you seen 1 customer with an issue and then another one shortly after.  The gateways were likely on the same subnet or rather close.  A few things we do to protect against this:

1: fail2ban on all linux servers passing sip traffic.  I get on the norm 3 emails daily of IP's that are getting blocked.
2. ALL our voice gateways (with the exception of customer VoIP ATA's and what not) are on private vlan's and ACL'd so as no traffic is allowed into or out of that vlan from the internet.  Only back to the SBC, Switch or PSTN terminatin gateway
3. Firewall on the Gateway terminating the trunk.  This will drop any packets not coming from our trunking server, and the server is set to pass traffic to the gateways IP only.
4. When Registering, ensure not only the SIP password is safe, but the Username as well.  SIPVicious in doing it's scan, will be able to tell the difference between "SIP 404" and "SIP 401"  Once it finds a username of a peer that is "unauthorised" vs "not found", it can keep hammering at it to auth, this is where fail2ban comes in.
5. Notification on ALL toll call activity out of the norm, or IP's blocked by Fail2Ban and firewall triggers.  It is essential to get this information quickly in the event there are serious issues that arise.
6. Secure mailbox passwords ( this is a must)

As far as liability goes, If it was the SIP gateway that was compromised and it is owned and maintained by the provider, then they are on the hook.  Conversely, if the trunk is secure and this was a dial in hack or "phreak", then the end user is on the hook.

I have personally never has one of our gateways or servers compromised, but have seen many customer side devices get hacked for toll fraud that were incorrectly configured.  Luckily with our monitoring in place, we mitigated the damages by either killing the destinations or halting the sip peer.

[ralph]

Thanks cmeilleur,
I've been having a hard time finding anyone who knows more about this than I do (which isn't much at this point) so I really appreciate your input.

Let me ask you about this:
4. When Registering, ensure not only the SIP password is safe, but the Username as well.  SIPVicious in doing it's scan, will be able to tell the difference between "SIP 404" and "SIP 401"  Once it finds a username of a peer that is "unauthorised" vs "not found", it can keep hammering at it to auth, this is where fail2ban comes in.

What is a good policy of a "safe" username?

Ralph

[cmeilleur]

Let me make a quick correction, when i am refering to the "Username" i was actualy meaning the Peer name and the Username. 

When an endpoint registers ( trunk or otherwise) on asterisk for example, asterisk checks so see if that is the correct user / password.  IF the username is found but the password is correct, a 401 Unauthorized is sent.  If the User name is NOT found then a 404 will be sent.  The attacker now knows that that is a valid username. 

Same goes for an attack that is scanning by way of using SIP invites.   It will send an invite to the sip server using the prospected "peer name".  In this scenario the attacking script will note a difference in "Not found" and "Unauthorized"

Quite simply, stay away from dictionary names.  Change it up, use capitols and numbers.  For example, instead of "tomato" (cuz tomatoes are a super yummy friut) i would use "t0Mat0".

Cheers,

Cmeilleur