Sjur Usken

Views on new technologies and business opportunities from Sjur Usken

Monthly Archives: September 2009

Confirmed: At least four IP PBXes in Norway part of the attack

The SIP attack yesterday hit several Norwegian IP addresses, where several insecure IP PBXes were located. The attacker managed to several of these ringing the Citibank number. I have confirmed from different sources that minimum four PBXes were abused the last 24 hours. These were Cisco and Asterisk PBXes, but configured insecure. There were no abuse of security holes or similar, only totally insecure configuration.

I will recommend all IP PBX owners and VoIP Service Providers to check if it is tried calling to the Citibank number (+442075005000). The attacker has tried different prefixes in front, so search for the digits “%442075005000”.

Also check my previous blog about how to secure your VoIP equipment.

Citibank UK number was target for a "lawnmower" telephone attack today!

Citibank is or has been under a telephone calling attack latest 12 hours. Here I will explain the attack and how it was done.

Have you seen the movie “lawnmower man”, when in the end, all phones rings in the who city? This was the aim for todays attack on Citibank in UK. The attack was simple, but probably effective when it was active. Send SIP INVITE to open SIP gateways and PBXs, who then will actually use the traditional phonesystem (POTS) to call the target. Suddenly you need DoS protection on your traditional POTS lines….

The SIP INVITE looks like this.

INVITE sip:00442075005000@x SIP/2.0
Via: SIP/2.0/UDP;branch=z9hG4bKaergjerugroijrgrg
To: <sip:x>
From: <sip:>;tag=Zerogij34
Call-ID: 213948958-34384780214-384748@
Max-Forwards: 69
Contact: <sip:sip@;transport=udp>
Content-Type: application/sdp
Content-Length: 520
Session-Expires: 3600;
Allow-Events: refer..
       o=sip 2147483647 1 IN IP4
       c=IN IP4
       t=0 0
       m=audio 29784 RTP/AVP 8 0 4 18 18 18 18 96 3 98
       a=rtpmap:96 telephone-event/8000
       a=rtpmap:18 G729AB/8000
       a=rtpmap:18 G729B/8000
       a=rtpmap:18 G729A/8000
       a=rtpmap:18 G729/8000
       a=rtpmap:4 G723

Lets walk through the SIP packet and see what info we can get from it:

A quick google search on the tag: Zerogij34  reveals that this attack has been around since at least 6th of August.

The IP ( this packet should be located in Portugal but the other attacks originate from both UK and Netherlands.
There is no User-Agent listed, so the packet is very likely crafted from tools like sipsak or sipp.
The codec list seems real, but they use an obscure address ( for the RTP. If they would use their own IP address, it could case a small DoS with RTP traffic for every successful call. The port 29784 is within the range of Cisco units (26 000-32 000)

The other INVITES reveals that the attacker is trying to figure the extension to get a dial-tone:

  • INVITE sip:00442075005000@ SIP/2.0
  • INVITE sip:011442075005000@ SIP/2.0
  • INVITE sip:0442075005000@ SIP/2.0
  • INVITE sip:0000442075005000@ SIP/2.0
  • INVITE sip:0011442075005000@ SIP/2.0
  • INVITE sip:900442075005000@ SIP/2.0
  • INVITE sip:9011442075005000@ SIP/2.0
  • INVITE sip:90442075005000@ SIP/2.0
  • INVITE sip:442075005000@ SIP/2.0
  • and several more…

But is this a DoS attack on Citibank? I doubt it. Why call the Citibank on a Sunday 5 a.m.? This is more likely that Citibank has lots of lines and therefore the SIP INVITES does not generate an error (busy or others). The attacker does not hear any ringtone, but he/she should see the 180 Ringing / 180 Session in Progress. Then he or she knows that he could actually get through to the PSTN on this SIP proxy. If it would be a ringing attack, why does the attacker just send one single SIP INVITE through each gateway that actually calls this destination?

The machines with the attacking IP addresses should be put under surveillance to see who connects to these. They are probably just some bots in a larger network, but they need to relay back which gateways actually responded successfully.

Sad to say, but I believe this is only the small beginning….

Copy everything…. the Planet UMG-2000 and Cisco UC500

I’m a gadget person and I like cool technologies. I get a lot of e-mails with new products and I let my mind spin around this product how it can be used the best way and in which situations.

I do notice that there is a lot of copy products. All from an iPhone with dual SIM and a lot of other features not on the regular one, to one special that caught my eye, the Planet Unified Office Gateway (which IMHO is a UC500 copy…)

Some background:
Cisco is trying to capture the SMB market (In US it is probably just called the Small Business Market) with their Cisco Unified Communications 500 series. This product has everything in one unit and can be quite complex to sell and install, but gives the buyer (the business) most services in one unit.

Planet has then launced their own version of this “all-in-a-box” solution with their UMG-2000. It has a lot of the same features as well, but I haven’t seen the interface for admin or what firmware it is running on. But as in most cases, you get what you pay for. Wish both Planet and Cisco good luck!

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

      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

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

      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

      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!


Embarrasing with the Norwegian Police website…

The Norwegian Police are limping after web 2.0 and finally made a website where you can report a crime (only if your wallet, bicycle or mobile phone is stolen). The only stupid thing is that it results in an e-mail sent to another system. But hey, they promise to send a letter in your (snail) mail within 14 days after the report. Great promise when you know only 3% of bicycle thefts are solved.

I think it is great that the police are trying to make it easier for you and me. The only problem is when they also make it easy for the bad guys. The Norwegian police is using the URL to point to graphics and then it is open for you and me to write whatever we want ourselves… great… no wonder this hits the front page on the largest tabloid newspaper (Link in Norwegian).