Sjur Usken

Views on new technologies and business opportunities from Sjur Usken

Monthly Archives: March 2009

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!

The SIP Digest leak

There is a security flaw that makes a VoIP adapter send out its password. How serious is this flaw?

Sandro Gauci demonstrated on this video how a voip analog adapter sends the credentials to the other ringer. This is a lab setup, but still possible in the real world.

First, you need should be sending the traffic from the SIP Registrar (but a lot of user-agents works to send directly as well). Most VoIP SIP user-agents only accepts SIP messages from the SIP Registrar they are connected up to. Either fake the packets from the SIP Registrar, but be in-line of the traffic to receive the response, or get a real account on the SIP Registrar/Proxy and hope they do not filter these messages.

Second, you need to know the extension. This could be all from a 3-digit number, to a user name with numbers and letters of varying length.

Third, the password you receive is encrypted with MD5. You will need to brute-force this. If it is below 8 digits/letters, this is really no problem for todays computer.


Yes it is possible, but it does take some time and several requirements must be met. The easiest way is still (IMHO) to sniff the hourly REGISTER message (which contains the same MD5 hashed password).


Just tested this on Linksys SPA2100, Grandstream GXV3000 and Fritz7270(in LAN client mode) and it worked to get the password from all of them. This is bad… really bad… further updates are coming..


Are your provider ready for VoIP?

Companies are jumping on the VoIP wagon, but need to do their homework before implementing it locally and choosing a provider!

Tyler Merritt has written a nice article about it, I borrowed the bullet points:

Ask the provider detailed questions about their backbone.
Do they host their servers in a reputable data center? Do they get their bandwidth from a well-known provider like Level 3? A friend of mine thought it would be neat to start a VoIP company and began offering services through machines hosted in his garage. He did some good business for awhile, but his company didn’t last long.

Make sure your VoIP service requires authentication.
This point may seem like a no-brainer, but many VoIP providers do not require registration from the customer, making toll fraud incredibly easy for even amateur hackers. Authentication strings that use a hash in place of a clear-text password provide required security.

Find out what kind of VoIP architecture the provider uses.
Is their network built on a proprietary solution like Broadsoft or do they make use of Open Source VoIP solutions like Asterisk? Proprietary may turn out products with fewer initial bugs and open lines of communications to the developer via a support team, but Open Source means a much larger community of devoted followers hammering away at the application out of sheer pride and commitment to excellence. Asterisk is the most widely deployed Open Source telephony platform in the world precisely because so many people have contributed hours upon hours towards development and stability.

Figure out the DTMF type up front!
With analog lines and PRIs, DTMF was never really a consideration. VoIP companies have choices like rfc2833, inband, and info – and some companies use a different DTMF setting for inbound calls and outbound calls! If customers can reach your Auto Attendant but can’t dial an extension because key presses aren’t recognized, you might as well not have a phone system at all. This one is the Achilles Heel for almost every company I know.

Make sure your network supports QoS.
It cannot be stated enough that VoIP traffic on your network needs an all-access pass to the HOV lane. Because VoIP uses UDP instead of TCP, there are no second chances for these packets. They need to arrive in order, unchanged every time. If your network equipment does not support QoS, simple things like sending an email when someone is on the phone will have a noticeable effect to the conversation. Some customers may detect “clipping” or “clicking” on the line however briefly. A good QoS policy protecting VoIP easily soothes its greedy need for dedicated bandwidth. VoIP does not like to share.


Google Voice has arrived!

Then GrandCentral has been re-launched as Google Voice.

Look at the interfaces here: or go to go get your own account (will be opened for new users within days..)