Sjur Usken

Views on new technologies and business opportunities from Sjur Usken

Another day, another (VoIP) fraud…

What the heck is the customers Asterisk calling Guatemala about quarter to five in the morning? 1000 calls to Guatemala, but very few actually went through or had any long duration. This was around 11 o’clock in the evening for Guatemala. What was the purpose of this abuse?

It would have been nice to have a tap into this unsecure Asterisk and listen in on the abuse calls. Was this open PBX sold as a gateway to a cash calling card company, or was it used to just free calling for the hacker itself? Ideas and comments are appreciated!


11 responses to “Another day, another (VoIP) fraud…

  1. mek October 22, 2009 at 5:09 am

    was, and possible not only
    Guatemala (+502) but also Cuba (+0053) involved?

    • sjur October 22, 2009 at 9:14 am

      You should definitely change the VoIP password on your VoIP user-agent and figure out how they got hold of this. There will be a lot more of these cases where the VoIP password has been compromised, since it is much more valuable than an e-mail password. This password should minimum be 8 preferably 12+ digits, letters and other characters.

      Ways it could have been compromised:

      * The password was sent in plain text in your mail (for manually voip phone installation)
      * The MD5 Digest was sniffed from your network when sending REGISTER or INVITE and done a brute force
      * The softphone stores the password in plain text in the registry
      * The VoIP unit has open web/CLI access and the VoIP password was shown here
      * The password was so weak that it was brute-forced directly towards the SIP Server

      And this is just the beginning…

  2. nick November 2, 2009 at 5:09 pm

    Have a question regarding the SIP Digest leak issue that you did an interesting post on some time ago…

    SIPDigestLeak works with SIP phones [some]. Would you know if it works with SIP Phones that use an asterisk pbx for routing? I.e. if we gain access to an Asterisk PBX’s sip [UDP] port, enumerate extensions, then try to attack each extension – would that work? Or is there any other way to ‘create’ such an attack in this case – some form of redirection in the SIP protocol that can get us to talk directly to the SIP phone?

    PS: I am auditing a clients installation, and guess what – asterisk with an extension with a weak password. Guess I better tell them to block all guatemala numbers 🙂

    PPS: As to ‘why’ call guatemala numbers, just think of anybody who would want to hide their source telephone address – could be anything illegal or underground.

    • sjur November 2, 2009 at 9:02 pm

      The SIP Digest leak does not work through an Asterisk. It should work through a SIP Proxy, but the Asterisk is a B2BUA.
      The fastest way would just be to do brute force on the user extensions directly towards the Asterisk PBX.

  3. nick November 3, 2009 at 11:37 am

    Thanks for the clarification – yes, the bruteforcing is being done, with good results. Just wanted to cover all my bases with my client, and not miss out an obvious vulnerability/issue.

    Thats an interesting point – so asterisk relays all communications to and from the SIP phone. I wonder if there is a way to trick it into revealing the SIP phone IP address…assuming the SIP phone is on the publicly accessible internet.

    • sjur November 3, 2009 at 2:43 pm


      Asterisk does not relay, but it sets up a new session to the other phone. A SIP Proxy relays messages (after possible altering them). If the option REINVITE => YES is set, then you should see the IP of the phone in the Re-Invite after the first call setup is done. Typically the first RTP packes wil traverse the Asterisk, then the RTP traffic will be moved directly between the phones communicating.

  4. nick November 5, 2009 at 8:25 pm

    Now thats interesting. So actually, one could use the RTP stream to figure out the IP address of the SIP phone. And then try to do a direct SIP digest leak attack on the SIP phone – would that work?

    Trying this approach here, the way to do it would be to setup the call to an extension on the PBX. So I bruteforced a few extensions on the asterisk box, but issuing an INVITE command [via my C-code] of this form – INVITE SIP/2.0
    – that results in an SIP/2.0 484 Address Incomplete – maybe it requires the username of the actual user?

    PS: Thanks for your insightful comments, this is an interesting area, and new to somebody who is experienced in web app security / other fields…

  5. nick November 5, 2009 at 8:27 pm

    Minor correction, my invite is something like this [where is the edited IP of the PBX server listening on port 5060].

    INVITE sip:4076@ SIP/2.0
    To: “4076”

    [other fields unimportant]

  6. scream November 24, 2009 at 10:43 pm

    * goes with a tons of default configurations. Inexperience users usually install e.g. with h323 activated. H323 in * is very poorly protected. This way you can easy reach the dialplans (extensions), and eureka you can now make one or many outgoing calls.

    Thats actually not the dumbest part. The dumbest part is when idiots put * boxes out on public net without protecting it with a firewall, on an XXMB line.

  7. Matt December 23, 2009 at 6:49 pm

    I got my * hit from the IP

    However i have a few questions. the only IP trunk leading from the box is a private VLAN from the carrier providing a SIP trunk.
    Everything else is on the lan and from over the Firewall i have only SSH access to the * box.

    I`m going over log files on this now , trying to figure out how it could have happened.
    Any ideas on what to look for . Perhaps the private VLAN IP space of the carrier is not as private as they think.?


    • sjur December 23, 2009 at 11:52 pm

      I had one customer calling telling we had called him and we probably got hacked. It was his Asterisk with both inbound and outbound privileges in same context. He had a re-routing from default to his mobil. But that was just a simple INVITE.

      For you I would set firewall rules on the “private VLAN” as well. If you still don’t know where the attack came from, run IDS or just a simple pcap dump from the traffic…. But ssh could also still be misused.. have you changed all the passwords etc? In the honeynet project we have seen 40 000 SSH attempts from just one single host….

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: