Sjur Usken

Views on new technologies and business opportunities from Sjur Usken

Tag Archives: hacking

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: (, 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;branch=E7C34B92-11CE-87FE-DC76-8AA77F25C6B1;rport
Max-Forwards: 70
From: ;tag=FB84E0A1-04AC-E4C2-D7E5-E49A34E3E90D
Call-ID: 185B191D-379F-888E-ABEB-E78C1B5DA498
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: (, 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;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
Contact: <sip:@;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 IP address.

The OPTIONS command

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

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

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

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!


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:


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

The second two IP addresses belongs to a VoIP company in Bulgaria, 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 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.


  • 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