Sjur Usken

Views on new technologies and business opportunities from Sjur Usken

Tag Archives: VoIP

Using botnets to do SIP scanning


The lastest week there has been a tremendous SIP scanning from IPs all over the world latest week. The scannings are coming from a lot of IPs but the same signature, so it is probably only one person/firm behind this.

The scanning is this:

OPTIONS sip:100@X.X.X.X SIP/2.0
Via: SIP/2.0/UDP 192.168.1.9:5060;branch=

z9hG4bK-31055767;rport
Content-Length: 0
From: “sipsscuser”<sip:100@192.168.1.9>; tag=01669016334862887007103185718785156498385702949

Accept: application/sdp
User-Agent: sundayddr
To: “sipssc”<sip:100@192.168.1.9>
Contact: sip:100@192.168.1.9:5060
CSeq: 1 OPTIONS
Call-ID: 022827170099429274868738305
Max-Forwards: 70
The lay-out of the OPTIONS messages is the same as in SIPVicious scannings, so the author has taken this python code and just changed the User-Agent.
And this is just the beginning….

Extreme SIP scanning latest week


There have never been so many SIP scannings in so short time for all my VoIP honeypots.They have tried all types, INVITES, REGISTER, SUBSCRIBES and OPTIONS.  A short list of some of the attackes latest 48 hours. Normally just doing a couple hundred extensions and passwords, some of these IPs trying up to 10 000 different extensions/passwords.

IP addresses [User-agent] Provider

119.147.116.157    [Asterisk]
193.47.153.14         [SIPVicious]
86.47.46.147          [First SIPVicious, then SIPPER for PhonerLite]
174.143.245.120  [SIPVicious]
174.129.52.240    [SIPVicious]     Amazone EC2
24.190.38.4            [SIPVicious]

So keep your systems ready for the flood to come! This is just the start.

SIP scanning causes DDoS on IP 1.1.1.1


RIPE said a long time ago that IPv4 is running out of addresses. Now they are also allocating the 1.x.x.x network for production traffic. But this is a bit problematic, since people have been using IP addresses like 1.1.1.1 and 1.2.3.4 as examples in scripts, tools and manuals. People who don’t know any better, they try contact these. When they routes to these networks where alive, a LOT of traffic started coming in.

What made it interesting for Sandro in EnableSecurity was that most traffic was UDP (60 %) and almost 90 % to IP addresss 1.1.1.1. This is a text from RIPEs article about it:

We found that almost 60% of the UDP packets are sent towards the IP address 1.1.1.1 on port 15206 which makes up the largest amount of packets seen by our RRC. Most of these packets start their data section with 0x80, continue with seemingly random data and are padded to 172 bytes with an (again seemingly random) 2 byte value.

This can actually be RTP traffic (VoIP audio traffic) generated from hosts that are vulnerable to SIP INVITE attacks, as Sandro points out in his comment and on his blog.

This is also alarming! This scanning with default RTP audio to IP 1.1.1.1 and port 15206 seems to be doing REALLY well on the Internet. There are a lot of VoIP unsecure platforms accepting and responding to ANY SIP INVITE they get. The software doing it is NOT SIPVicious, but another. It normally uses port 3058 to send the SIP INVITES from. If anybody knows something about this software, please contact me.

I have had a slide in my VoIP presentations about this scenario. If you do a SIP INVITE sweep, you should NOT have a valid IP address for the audio. Every successful INVITE would then generate at least 20 seconds of 0,1Mbit per second stream (g711 audio) to your IP address. Your SIP INVITE sweep with your IP as receiver for RTP traffic will not take long before it backfires on you and you get a DDoS on yourself (well earned though IMHO).

So what is next?

I would love to have a honeypot or get access to the traffic going to port 1.1.1.1. All hosts that would send RTP traffic to this address, should be contacted and asked to secure their servers!

Status now from RIPE:

Since the traffic patterns seemed to be stable we decided to withdraw the announcement of 1.1.1.0/24 and 1.2.3.0/24 on 2 February 2010.

Vulnerability in FreePBX 2.5 and 2.6


The Exploit Database reports that FreePBX version 2.5 and 2.6 is vulnerable to Cross-Site Scripting (XSS).

An affected user may unintentionally execute scripts or actions written by
an attacker. In addition, an attacker may obtain authorization cookies
that would allow him to gain unauthorized access to the application.

This is just the beginning of vulnerabilities in different VoIP applications. Up until now, there has not been the need of vulnerabilities to exploit VoIP services. Too many IP PBXes has been configured insecure, and easy to abuse.

The next wave will see more exploits beeing used towards IP PBXes. They are often based on same protocols and applications as any other server….

[ad]

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]

Number of VoIP scannings has exploded


If you have an IP PBX on a public IP, and you are not quite sure if it is secure enough, you should get to it now!

Scannings on port 5060 has exploded the lastest days. Previously it was a couple hits in the week, now it’s up to a 100 a day. This means that if your VoIP setup is not 100% secure, others will find it and abuse it!And you will get the telephony bill!

Get to it, secure your VoIP communication platform right now!

Check the following:

  • All users has strong passwords
  • Access Lists are updated and preferably both ways (both incoming and outgoing traffic on the server)
  • No unused services are enabled
  • Latest patches are on the server OS
  • Latest patches are on the application
  • Latest SECURE firmware on the hardware endpoints (phones etc.)
  • Other services on the plattform like Web servers, TFTP, FTP, SSH are locked down or VERY strong passwords
  • Encrypt the traffic from the user and into the server (to make eavesdropping harder)
  • Make the PCs accessing your platform secure. Any keycatchers or sniffers installed here?
  • Forgotten someting? Please comment

[ad]

Why are there VoIP attacks from port 3058?


Been picking up more and more hits in the VoIP honeypots lately. What puzzles me, is that several of those originate from different IPs but same port number. IANA assigned port 3058 to the following:

videobeans 3058/tcp videobeans
videobeans 3058/udp videobeans

IPs that has hit one or more of our honeypots the latest days:

From port 3058
64.62.243.6
67.23.3.128
69.64.38.111

Other ports
174.129.70.133
207.239.216.52
207.239.216.53
208.38.164.48

Notice the two consecutive IPs, 207.239.216.52 and .53.

But why port 3058… the reason is probably simple, but for now I’m guessing on the same software running on PCs with a public IP.
[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]

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!