usken.no – VoIP news!

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 0×80, 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.

Slightly interested in security?

Do you want to learn more about investigating attacks?

Here is your challenge!

The Honeynet Project has released this years first Scan of the Month challenge! It has many levels and now you can test if you are up to it!

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.

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)

• Linksys SPA2102
• Grandstream GXV3000 (latest firmware)
• AVM Fritz 7270 (firmware december 2008)

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!

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…..

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.

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!

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