Sjur Usken

Views on new technologies and business opportunities from Sjur Usken

Tag Archives: security

Will SIP TLS be the solution to SIP Security?


SIP is now mostly run over UDP. This is scalable but unsecure. Microsoft uses only TCP and encrypted TLS. But TLS has its own flaws as shown by this webpage.

There are three general attacks against HTTPS discussed here, each with slightly different characteristics, all of which yield the same result: the attacker is able to execute an HTTP transaction of his choice, authenticated by a legitimate user (the victim of the MITM attack). Some attacks result in the attacker-supplied request generating a response document which is then presented to the client without any certificate warning or other indication to the user. Other techniques allow the attacker to forward or re-purpose client certificate authentication credentials.

They use HTTPS, but it could most likely also be done in SIP as well. When everybody is using SIP TLS, there will still be security issues….

More info in here.

[ad]

Advertisements

An RFC for SIP security! Excellent!


The RFC draft-ietf-speermint-voipthreats-01 was release in July and summarizes several of the threats towards VoIP.

SIP Request Spoofing

   Most SIP request spoofing require first a SIP message eavesdropping
   but some of the them could be also performed by guessing or
   exploiting broken implementations.  Threats in this category are:

      session teardown - the attacker uses CANCEL/BYE messages in order
      to tear down an existing call at SIP layer, it is needed that the
      attacker replicates the proper SIP header for the hijacking to be
      successful (To, From, Call-ID, CSeq);

      Billing fraud - the attacker alters an INVITE request to bill a
      call to a victim UE and avoid paying for the phone call.

      user ID spoofing - SSPs are responsible for asserting the
      legitimacy of user ID; if an SSP fails to achieve the level of
      identity assertion that the federation it belongs expects, it may
      create an entry point for attackers to conduct user ID spoofing
      attacks.

      Unwanted requests - the attacker sends requests to interfere with
      regular operation, i.e. sends a REGISTER request to hijack calls.
      The SPEERMINT architecture as defined in [refs.speermintarch] does
      not require registrations between the signaling functions (SF) of
      the connected SSPs.  Superfluous requests like REGISTERs should be
      rejected.

There is also a part of how to spoof messages:

SIP Reply Spoofing

   Threats in this category are:

      Forged 200 Response - the attacker sends a forged CANCEL request
      to terminate a call in progress tricking the terminating UE to
      believe that the originating UE actually sent it, and successfully
      hijacks a call sending a forged 200 OK message to the originating
      UE communicating the address of the rogue UE under the attacker's
      control;

      Forged 302 Response - the attacker sends a forged "302 Moved
      Temporarily" reply instead of a 200 OK, this enables the attack to
      hijack the call and to redirect it to any destination UE of his
      choosing;

      Forged 404 Response - the attacker sends a forged "404 Not Found"
      reply instead of a 200 OK, this enables the attack to disrupt the
      call establishment;

The RFC has a good overview how to protect yourself against these security issues in the end and elaborates on each of them what to do.

Here is a smaller part of it:

4.13.  Encyrption and Integrity Protection of Signalling Messages

   Encryption of signalling messages can be achieved with TLS or IPSec.
   Similar to strong identity assertion, a PKI infrastructure is assumed
   to be in place for TLS (or IPSec) deployment so that SSPs can obtain
   and trust the keys necessary to decrypt messages and verify
   signatures sent by other SSPs.

4.14.  Encyrption and Integrity Protection of Media Stream

   The Secure Real-time Transport Protocol (SRTP) [RFC3711] adds
   security features to plain RTP by mainly providing encryption using
   AES to prevent eavesdropping.  It also uses HMAC-SHA1 and index
   keeping to enable message authentication/integrity and replay
   protection required to prevent media hijack attacks.  Secure RTCP
   (SRTCP) provides the same security-related features to RTCP as SRTP
   does for RTP.  SRTCP is described in [RFC3711] as optional.  In order
   to prevent media session teardown, it is recommended to turn this
   feature on.

A MUST read and “are we covered” for all VoIP Service Providers! Good luck!

[ad]

Get the password from ANY SIP device?!?! It is fully possible!


If I know the IP address of your SIP User-Agent and your extension, I can get your password. Not true? Here is how Sandro and I did it! Sandro Gauci also has a tool (voippack for Canvas) which automates the whole process, you can watch the video here!

The fault is that a User-Agent actually answers on an authorization request, even though there is no reason for it. We first send an INVITE, the user-agent rings and the user picks up the phone. When the user hangs-up, we reply the BYE message with an authorization request, which the User-Agent normally answers with a SIP Digest (with the encrypted password). We brute force this digest.

The master plan:

  1. Check up on the Internet which ISPs are delivering VoIP. Check RIPE for their IP ranges. Scan them for SIP devices.
  2. Get the extensions they are using (or their ranges of usernames (e.g phone numbers, then do brute force on these ranges on each IP)
  3. Send an INVITE to the correct extension and the phone will ring. When the user hangs-up, we have the password.

The details:

We make the phone send a PROXY AUTHENTICATION when the SIP UserAgent sends the BYE message. We answer with “407 Proxy authorization required” and then the SIP UserAgent actually answers this with the password in a MD5 hash.

The problem

  • The SIP stack is not connected to the IP Stack. Why is the SIP User Agent answering on SIP messages from other IPS than the SIP Registrar it is connected to? There should be automatically a rule saying “all SIP messages from other servers than what I’ve registered to = drop them!”
  • Why does the User Agent blindly answer a challenge on the BYE message. Just send it a “407” and the SIP UA answers with the password…

Units tested (and we managed to get the password)

The units that will be tested further:

  • Polycom
  • Thompson ST2030
  • Snom

How to protect yourself (for users)

  • Make sure your VoIP provider has credit limits! You don’t want to get a huge phone bill!
  • Report any unusual phone calls or strange behavior!

How to protect yourself (for VoIP providers)

  • Protect your SIP user-agents! This is hard with the Fritz units
    which is normally used as a router
  • Have very long SIP passwords and use all characters that is possible! (#¤%” and others)
  • Change the SIP password regularly
  • Run VoIP honeypots to detect scans in your area

How serious do you think this is? Write your comments now!

Presention VoIP attacks, tools and how to make a VoIP honeypot!


I’m soon off on a trip to Asia to do a presentation about VoIP security and how to make a VoIP honeypot!

The presentation does an introduction to VoIP protocols and how SIP works.
Then more details about the attacks seen the last 12 months.

Watch the whole presentation here. Comments are always appreciated!

[ad#std_banner]

[ad#250×250-hj%c3%b8rnegreier]

Asterisk vulnerabilites can be abused


I remember in the old times when Cisco was running the Call Manager on a Windows 2000 system. The Call Manager servers were always six months behind with patches and updates, and had to be protected at all costs. Caution has to be taken as always when enabling new services, and especially when it can hurt financially. PC World reports that “yes, you can abuse Asterisk with a bug for a time ago” in this article. They sited the IC3s article about VoIP fraud.

Do we need another firewall for all new services? There are several Media specialized firewalls, often called Session Border Controller that does this, but is this the way to do it? Probably not. IMHO it is to have a good security audit and overview of your own infrastructure, take control! Don’t buy yourself out of the current biggest threats, there will be new! Take control with IDS and even IPS, and have backup plans in case serious bugs and flaws makes your services vulnerable!

And good there is several other people talking about security, like Mark Collier and the folks behind the bluebox security podcast! Good job!

[ad]

VoIP system abused in an English bank service company…


I’ve had several responses to my previous article about VoIP attacks, and people are approaching the Honeynet organisation for help to figure out what they to do after being abused. This is both good and bad. Good that they seek help, bad that they do not have a IT security plan.

IT hacking costs money, and when implementing mis configured VoIP it shows up on the telephony bill as well. Previously it was costs that were not that obvious, down-time for the firm, stolen documents used against them in business competitions or just abuse of their Internet bandwidth to hurt others. How would the world been if all the security faults a firm had would show up on their monthly Internet bill? “Your computers have been participating in a DDoS attacking costing a firm 5 million, this is your cost”

The companies need to take security more serious. It is a war going on on the Internet where the strongest one will survive. And the war has begun for a long time ago…
[ad]

VoIP attacks are escalating


There has been numerous VoIP attacks from very different sources the latest months. In this article we will go through attacks towards two different companies in Norway. I will explain how they did it and how you can protect yourself against it.

Who was the attackers?

The attackers IP adresses:

  • 124.217.230.238
  • 124.217.230.225
  • 213.130.74.70
  • 213.130.74.72

The first two IP adresses belongs to “Piradius” network in Malaysia.

The second two IP addresses belongs to a VoIP company in Bulgaria, www.iconnectbg.net. These people has not been successful with their actions, but they had about 1000 SIP INVITES while trying to get through.

There was also some port scannings on port 5060 from an American IP, so we contacted the firm and it was most likely a break-in on the local servers.

The attackers business models

There seems to have been to way to make money. One way was to directly use it as an outbound gateway. This is quite risky since you have an existing business to protect.

The other way was to sell these minutes to another provider. One company specializing in discovering and making the gateway ready, then selling this access to prepaid phone card providers.

There are several others, like calling expensive numbers in other countries and then charging the terminating fees.

How did they find the VoIP gateways

The Piradius network (or the people hiring place in this network) did their port scanning from 124.217.252.238. First they search just for open ports, port 5060 (UDP and TCP!) and 1720 (h323). If you have a Cisco PSTN gateway, remember that the Cisco gateways can do both SIP UDP/TCP and H323. The first machine tried all different numbers similar to this.525551690000.

Example:

  • 00525551690000
  • 000=23525551690000
  • 00100525551690000

They tried a lot of different variations of this, and after a while they went over to a brute force way, just counting their way upwards

  • 26100525551690000
  • 26200525551690000
  • 26300525551690000
  • 26400525551690000

The always used caller ID 5199362832664 on all calls. They probably had an Asterisk on the other phone number, noticing when it rang and which gateway that then had been used.

What was configured wrong?

One of the customers with an Asterisk had included the “outbound” context to the SIP provider within the reach for the inbound context. Calls coming in and there were no matching numbers internally was routed out to the SIP provider. This is such a bad idea…

Another customer had a Cisco gateway. Cisco gateways just routes VoIP traffic the same as IP based on the dial-peers. It was configured properly with dial-peers but not with the correct access lists. The Cisco just needs 1 dial-peer configured to bounce traffic like this.

The motives

These two attacks were directed to get free calling. The calls were going to expensive countries like Cuba and Jamaica. There has been no directly breach on the system with username/passwords to gain access and get information. The objectives were to send free telephony traffic through the unsecured PBXs.

How to protect your VoIP equipment

  • Always have a firewall or session border controller (SBC is just a specialized VoIP firewall) between you and the Internet.
  • Limit your access to your VoIP servers from the rest of the world
  • Do not let inbound contexts in Asterisk have access to outbound.
  • Be careful with dial-in features and get a new dial-tone based on a password.
  • Update the software regularly.
  • Use VPN tunnels to protect the VoIP traffic going over the Internet
  • Use SIP TLS and SRTP if possible (we are waiting on hardware manufacturers here as well)
  • Shutdown all services on equipment that is not in use. Example H323 on a Cisco gateway used only for SIP

[ad]

The quarterly VoIP vulnerability list


The VoIPSA blog released a quarterly overview of VoIP vulnerabilites for Q1 2008. Yes, it is a little old at the moment, but still interesting. The Cisco phones are on top when it comes to number of vulnerabilities. It is slightly more scary that a VoIP expert, InGate, also has errors on their equipment. It was an easy to exploit Denial-of-Service(DoS) bug, critical for those relying on InGate to protect them from DoS attacks.
[ad]