Sjur Usken

Views on new technologies and business opportunities from Sjur Usken

Tag Archives: sip

The MeshPotato, the future of the Internet?


Imagine you had this technology which you only needed two devices to call to each other and get IP connection. If you got more members, only thing they needed was this device and the network would grow stronger and stronger, each member helping the network to grow in distance and robustness. Communication would be free, each member pays for their own device and this device would be a part of the network.

When the network has grown very large, there would be free management tools to map all devices to the map, giving a very good overview of the whole network and easy the further expanding.

And this is reality! The Village Telco project has spent three years making it real, creating the MeshPotato. The MeshPotato is a very low power WLAN mesh and VoIP device, creating its network while being rolled out. It uses 2,4GHz WLAN to create a mesh network and running IP and VoIP traffic over this network.
The Village Telco project uses open source tools like Afrimesh and A2Billing to create a full management and billing system, all free to download and deploy.
And all you needed to start is two MeshPotatoes. What is stopping you?
The future is bright!

Filter away those SIP attacks


Finally, an open-source solution to filter away those SIPVicious and other SIP attacks. SecSIP is Stateful SIP Protection Systemwhich analyses the SIP signalling on the fly and decides wether to forward it or not. It can throttle number of SIP messages (useful since one of mye VoIP honeypots was hit with 16 000 INVITES within 8 minutes..).

Great work and I’m looking forward to test it out live!
[ad]

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]

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]

And the Cisc 7940 phones leaks its password hash..


With some help from Sean in the US, Sandro and I could access a Cisco 7940 phone (with a SIP stack) from the Internet. We called it from our public ip (showed as 192.168.1.1).

[ Fri Apr 10 21:16:16 2009 ](192.168.1.1/32) Proxy auth:
[‘Digest username=”5555914760″,realm=”localhost”,uri=”sip:192.168.2.2″,response=”a718dsf8c742799f1c22fbcd1d4637d801b”,nonce=”a”,algorithm=MD5’]
[ Fri Apr 10 21:16:16 2009 ](192.168.1.1/32) The phone rings on extension 5555914760
[ Fri Apr 10 21:16:16 2009 ](192.168.1.1/32) Launching the password cracker
[ Fri Apr 10 21:16:18 2009 ](192.168.1.1/32) Password was not guessed
[ Fri Apr 10 21:16:18 2009 ](192.168.1.1/32) Use the SIP Digest Cracker to perform an extensive bruteforce
[ Fri Apr 10 21:16:18 2009 ](192.168.1.1/32) username: 5555914760
[ Fri Apr 10 21:16:18 2009 ](192.168.1.1/32) nonce: a
[ Fri Apr 10 21:16:18 2009 ](192.168.1.1/32) realm: localhost
[ Fri Apr 10 21:16:18 2009 ](192.168.1.1/32) uri: sip:192.168.2.2
[ Fri Apr 10 21:16:18 2009 ](192.168.1.1/32) method: BYE
[ Fri Apr 10 21:16:18 2009 ](192.168.1.1/32) response: a7188cfwet742799f1c22fbcd1d4637d801b

Then we could start our brute forcing of the password, and then either log-in and receive calls as Sean, or make outbound calls as him. Next phone to test is the Snom phone.
[ad]

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]

Probing with OPTIONS messages


I’m part of the Norwegian Chapter of the Honeynet Project. We have lots of honeypots with different services up and running. The most interesting for me is the VoIP honeypot. It captures all VoIP traffic and answers all incoming calls as a normal gateway or IP PBX (e.g. Asterisk) would do.

The latest traffic is again from the Piradius network.

The piradius network is now using “OPTIONS” to probe for existing IP PBX they can abuse for free calls.

Internet Protocol, Src: 124.217.230.65 (124.217.230.65), Dst: 195.159.X.X (195.159.X.X)
User Datagram Protocol, Src Port: rapido-ip (2457), Dst Port: sip (5060)
Session Initiation Protocol
Request-Line: OPTIONS sip:3392@195.159.X.X SIP/2.0
Message Header
Via: SIP/2.0/UDP 0.0.0.0:2457;branch=E7C34B92-11CE-87FE-DC76-8AA77F25C6B1;rport
Max-Forwards: 70
To:
From: ;tag=FB84E0A1-04AC-E4C2-D7E5-E49A34E3E90D
Call-ID: 185B191D-379F-888E-ABEB-E78C1B5DA498
CSeq: 1 OPTIONS
Contact:
Accept: application/sdp
Content-Length: 0

A new address
There is also a new IP address where the same attack is coming from. You can see it from the same structured OPTIONS message.

Internet Protocol, Src: 67.215.13.194 (67.215.13.194), Dst: 195.159.X.X (195.159.X.X)
User Datagram Protocol, Src Port: sybase-sqlany (1498), Dst Port: sip (5060)
Session Initiation Protocol
Request-Line: OPTIONS sip:2658@195.159.X.X SIP/2.0
Message Header
Via: SIP/2.0/UDP 0.0.0.0:1498;branch=BCEA2F83-1CEF-FC6A-2989-54C18CE6425E;rport
Max-Forwards: 70
To: <sip:2658@195.159.X.X>
From: <sip:8571@195.159.X.X>;tag=723535DC-E71F-E3D4-D572-2B41E58782E8
Call-ID: 4203F1B5-3E1F-E6D6-32FF-B8C2DFAA190F
CSeq: 1 OPTIONS
Contact: <sip:@0.0.0.0:1498;transport=udp>
Accept: application/sdp
Content-Length: 0

The packet would have been stopped in a firewall understanding SIP. The “VIA” and “Contact” field can not have a 0.0.0.0 IP address.

The OPTIONS command

From voip-info.org web page:
The SIP method OPTIONS allows a UA to query another UA or a proxy server as to its capabilities. This allows a client to discover information about the supported methods, content types, extensions, codecs, etc. without “ringing” the other party.

For example, before a client inserts a Require header field into an INVITE listing an option that it is not certain the destination UAS supports, the client can query the destination UAS with an OPTIONS to see if this option is returned in a Supported header field.

All UAs MUST support the OPTIONS method.

There has been less security concern about the OPTIONS implementations, since it is the INVITE that generates the call. But the OPTIONS can reveal a lot about what User-Agent/Server it is and version. Then it is just a quick search to find a bug or backdoor on this…..
[ad]

VoIP attacks are here again!


Have you seen the movie “The Lawnmower Man“? When, in the end, all phones in the whole world is ringing? This was the scenario for several firms in Norway this week. The phones rang every 20 minutes!

Whose fault is it?

And the guilty one? Several are to blame.

First; the Piradius (again…) network doing SIP and H.323 scans on open phones and gateways.
Second; the phone producer not making a secure enough phone.
Third; the people putting such a solution onto the Internet with no security.

What the attacker did

The Piradius network was scanning the network sequential and sending H.323 Call Connect to each IP address. The phones were open to invites from any IP address. The phones then rang, and when answered by some people there were nobody in the other end.

Information about the packet

In the h.323 packet the claim to use Cisco equipment, but I’ve never heard about a “balhophone”. If you do know, please comment! The version does sound too suspicious (1.666666). I’m guessing on an Asterisk….

vendor
           t35CountryCode: United States (181)
            t35Extension: 0
           manufacturerCode: 18
                             H.221 Manufacturer: Cisco (0xb5000012)
                            productId: balhophone
                            versionId: v 1.666666

The contact information within the H.323 packet for audio so totally different from where the TCP traffic is originated from. It is an unallocated space.

AS  | IP             | BGP Prefix   | CC | Registry | Allocated  | AS Name
NA | 36.27.177.136   | NA           |    |          |            | NA

The attacker has just used this IP address as a /dev/null for the audio of those that actually answered the phone. This RTP traffic back from mass calling can be a DoS attack in itself. If every packet you send on 1500 bytes generates a continues stream of 0,1Mbit (G711), it could take down the attacker itself….

The called number

Called party number: ’40#5926693444′

I’ve seen that they do include the # in several attacks previously, but this is not used in any part of Scandinavia to make an outbound call. If you know why an attacker is using the #, please let me know.
[ad]