Total surveillance made easy with VoIP phones

Mon, 11 Feb 2008 23:03:43 GMT

Remember the article about call jacking with the BT Home Hub? Here is something comparable but pretty new. Since Ronald and pdp had announced the router hacking challenge, I've decided to play around a little bit and as a result I've managed to find a rather interesting issue. Although not directly related to the router hacking contest, the results I've got were rather disturbing and made me get a totally new view on the VoIP phone security landscape.

Most modern VoIP phones come with a Web interface which you can use for administrative purposes mainly. The user can adjust the device's settings, like change the display messages, maintain the address books and on some models even make phone calls from the Web interface. Since the device we've tested supports that particular functionality (call a number via a simple POST request) I've decided to have a look at the markup a little bit closer, not knowing what hornet's nest I was eventually going to stir up. The device we are talking about is the Snom 32x - a pretty common device that can be found in several medium and large offices.

The Web interface of the Snom 32x VoIP phone suffers from many vulnerabilities that may cause financial and reputation trouble for the organizations that trusts them in their network. The vulnerabilities are based on common attack vectors, such as XSS and CSRF.

It is essential to keep in mind that, in order to attack the Snom 32x Web interface, the attacker requires knowledge of its IP address. This knowledge can be obtained by using a XSS Intranet scanning technique or via a plain guessing/bruteforce method. By looping through several IP addresses with JavaScript, looking for URLs like, we can easily locate the Web interface of the device. Of course a quick nmap scan delivers equivalent results with more ease and less time required. It is important to note that some networks use predictable names which also can also be used to pin-point a vulnerable device.

After discovering the device the attacker has several possibilities for evilness. Let's have a look at some of them:

  • call arbitrary people via the Web interface via the means of CSRF.
  • make the call history invisible by calling a number like "'); which causes the Flash application displaying the most recent calls to crash.
  • steal the phone history from the logs including any other details attached to the calls via XHR.
  • poison the address book with a persistent XSS - the name is encoded correctly but not the phone number.
  • inject a JavaScript worm to gain total control over the user by changing the visible output by performing XHR-CSRF attack.
  • change the settings of registered phones, including the displayed text on the phone's display.
  • Last but not least, monitoring the victim by making a phone call to the attacker's number, who in tern will accept the call and recording the incoming sound. Note that the phone doesn't give any noticeable feedback (ring tones, etc) while the victim was kept under surveillance. Keep in mind that the victim pays for the call.

It is also important to note that:

  • None of the tested forms use tokens or other methods to make it harder to perform CSRF attacks against the Web interface.
  • The phone comes with a default password, which is 0000. You can pick this information from Google.

Let's have a look at a proper scenario. If the attacker knows the IP of the device's Web interface he/she can disable and/or hijack the whole phone within a few minutes. By crafting a XSS-CSRF vector he/she can inject a persistent XSS into the address book. When the victim visits the phone book, the XSS worm is silently executed and the attacker gains a total control over the interface and the actions that will be performed in the future. This also circumvents any protection mechanisms like VPN or comparable network layers, etc. And yes, in the worst case scenario the attacker will be able to survey the sound in the room in and cleanup the logs afterwords.

The whole device seemed to be especially designed for these issues to work. It is not like the situation where a small design flaw endangers the entire security model like many other cases. This time almost any available feature was buggy and vulnerable, and it kind of seems like a wonder that those phones are shipped all over the world and nothing major have happened yet. I've tried to patch the phone with the latest firmware but that didn't work - the phone was temporarily disabled after the process and when it began responding again the firmware version was still the same. So, even if there are patches for those devices they sometimes can't be used at all. It is very probable that other phones from other companies have the same or at least similar issues, so don't consider this post as a blame on a certain company. We'd rather point out severe issues that kind of compare to Web hacking scene in the nineties and have them fixed urgently - no matter what phone is used or which company have built it.

Please check the VoIP devices that you use and verify that the Web interfaces implements strong passwords and enforces some minimum security level. Contact the company who built the device and do bug them with you concerns. This will help generating a less dangerous situation for you and other VoIP phone users. Vulnerabilities like the one mentioned above could cost you or your company great amounts of money, reputation loss and even large scale information theft.

The proof of concept (POC) code can be found over here (please use it responsibly):


... and some supporting screenshots follow here:

Snom Screen1 Snom Screen2 Snom Screen3 Snom Screen4

Snom has been contacted in several ways but we haven't got any responded yet. We will keep you posted about any news. Feel free to comment - we are very looking forward discussing those issues more in depth.

Update: 14 Feb 2008

We've received a response from Snom. This is what they say.

To prevent this we will take the following measurments:

  • We will publish an article on "how to make your snom phone saver" on our website (including a link to it on the start page)
  • We will send out a newsletter to all our registred VARS and distributers with this information
  • We will work on the FW to improve security (just checked, on FW Ver. 7 the Flash applet is disabled by default)
  • We will publish a new email adress, for security matters (mostlikly [email protected]), which goes to a bunch of people (including me).>

We are thankful for letting us know about your future plans.

Gareth HeyesGareth Heyes
Awesome stuff Mario!
Nice research. I'd like to add that some VoIP phones come with intercom mode enabled by default. This means that by sending it a special SIP request (using the SIP header: Call-Info: ; answer-after=0), one can monitor what is being said in the room, just by calling the phone, as the phone automatically answers the call and puts it thru the speakerphone. One example of such a phone is the Linksys SPA941 (which in its older firmware versions used to have the intercom mode enabled by default). There are probably others that come with this "feature" enabled by default and there is always the possibility that one could use an XSS/CSRF to enable it if disabled.
cirrus, this is very, very interesting. 10x for the tip.
Interesting indeed! I haven't had a deeper look into those kinds of features but probably will during the next weeks.
Just FYI: Meanwhile I was contacted by Snom and we managed to work out plans for securing the affected devices. Hats off to Snom - long time no such great reaction!
one of the nice things about Snom, instead of just web page linked to there that initiates a call with an HTTP string, just do it from outlook
Also, the more interesting attack to me would be to factory reset the phones remotely. "http://phonesIpAdr/advanced.htm?reset=Reset" will factory default a phone. In many service provider based setups there will be QoS tagging, VLAN tagging, proxy information, along with the SIP credentials. If you managed a CSRF attack to factory default the phone, better yet, a scripted attack that could scan a whole subnet, find the Snom phones and pass the HTTP GET, you're looking at a significant outage.
@reid: This sounds very interesting. Keep the Snom guys posted - they are currently implementing a [email protected] mail address and many other clever ideas of securing the devices so the intent of the article has come reality - awareness was generated - win-win.
Sorry, a bit of a distraction but I was doing a bit more googling, it's disturbing what you can come up with by a simple inurl: search on google (the /img/logo2.gif doesn't pop up anything so I was trying a couple others) Are you guys doing anything as far as seeing what data can be mined from the SIP traces (also available w/out admin rights on the phone)? The reason I ask is that I haven't done much personally on going through the SIP traces trying to figure out if it's possible to grab version and vulnerability info on the SIP server, proxy, SBC, whatever the phone is registering to. so consider, by getting to the phonoe itself I can draw out application version info and hardware specific info (MAC, etc.) on the specific phone as well call history, possibly SIP credentials. Flip that around, what if I can draw out information about the proxy or registrar common to ALL phones within a business and find an attack vector? Goes a little beyond a simple XSS attack I think but something maybe worth looking into. Would also potentially be much a much wider attack surface for MITM and spearphishing attacks. Alright, I'm going to stop the use of jargon and acronyms now because it's begining to annoy even me.
Nice writeup, i've actually stumbled upon this myself during the last year or so while working with SNOM320's. They indeed do have a large number of vulnerabilities BUT, the firmware is open source(not many people know this). Thus you could go fix it yourself if you do stumble upon a bug that needs immediate attention. Also it might be worth mentioning, a lot of VOIP-platforms are ran on a popular piece of software called Asterisk(or distros using Asterisk such as FreePBX/CentPBX/Elastix/Trixbox/etc). You'd be amazed exactly how many vulnerabilities are in their software that can easely result in bankruptcy.
I just returned from CeBIT in Hannover, Germany where I was invited to a event organized by snom due to this exact article and it was pretty interesting. Peter Cox was there and other very interesting people to talk to. I had pretty good discussions with the developers of the snom web interface and I got a preview on the new phone firmware. It definite has been improved a lot and I got a phone for my private lab to test for more issues. So my impression of this day is a good thumbs up to snom - let's see what can be found in the most recent firmware ;)
Ok, I've got a bunch of these on public IPs. Am I in trouble? This article clearly states that if the IP is known an attacker can hijack the phone. Snom says otherwise; only if you have failed to set a password on it (obviously). I came here from the Snom security announcement which downplays this attack. This worries me gravely. On the other hand this article is light on details. The only code is how to make calls once you're in, which would be unrelated to the actual attack. Now that the manufacturer has responded, can you please publish more information so we can properly determine if we are at risk?
Adrian 'pagvac' PastorAdrian 'pagvac' Pastor
@Jonas: put it this way, if the attacker can talk to the Snom's IP phone web server (as in the case of Internet-visible phones), then he can make the phone start any VoIP calls WITHOUT a password. This is because the CGI script that handles such POST requests is publicly available (can be talked to, without a password). Quoted from .mario's post, some possible attacks include: "monitoring the victim by making a phone call to the attacker’s number, who in tern will accept the call and recording the incoming sound. Note that the phone doesn’t give any noticeable feedback (ring tones, etc) while the victim was kept under surveillance. Keep in mind that the victim pays for the call." If I were you I would restrict access to such phones from the LAN only *immediately*.
Adrian: Thank you for your reply. It does not help me however. If I just POST the data to the phone it replies with "unauthorized", obviously, as I did not send the required HTTP authentication. Apparently there is something else to this. Can somebody PLEASE speak up on this! I just need to know this is actually an issue. I can't start limiting access to phones based on nothing. Can you just show a dump on a working request, or anything at all that can convince me this works?
Adrian 'pagvac' PastorAdrian 'pagvac' Pastor
@Jonas: it's not just any POST request, it has to be the request that starts a conversation. Just use the PoC (proof of concept): Sorry, but we can't make it easier than that. Keep in mind that .mario tested the attacks on Snom 32x and by the way, all the vulnerabilities were confirmed by Snom, so you can bet this IS a real issue. Also remember that stealing calls and eavesdropping the room where the phone is located are not the only vulnerabilities found by .mario. As I said, connecting these phones directly to the internet is asking to get pwned!
Adrian: I'm not sure what you mean by starting a conversation, but I mean the POST request that initiates a call, normally called through the web interface. I wouldn't have asked if your proof of concept worked. I have tried it on several models on Snom phones, including the 320. Snom did not confirm the vulnerabilities by the way. Did you read their security announcement? I read CVE-2008-1248, which gave me the impression that a manufacturer was trying to downplay a security issue which is why I came here to find the truth. But now I suspect that there was no issue to begin with..?
Adrian 'pagvac' PastorAdrian 'pagvac' Pastor
Hi Jonas, It appears that if you set a password you can resolve the unauthorized POST "initiate call" request issue: Careful: no password is set by default!
Adrian 'pagvac' PastorAdrian 'pagvac' Pastor
@Jonas: forgot to add that this is NOT my research, but Mario's (as shown in the post). Therefore, I suggest you to contact him directly if you have any more specific questions. Also, thanks a lot for your feedback. It's always a very good habit to question everything you read.
Don't know if you're aware, but this article made it's way into the "News Briefs" section of IEEE's Security & Privacy (March/April 2008) :) good job
okay so this is probably a bit old, but I found it amusing anyway. We use snom phones internally and also for a hosted voip solution. I was looking for a phone on our LAN and (stupid) decided to do a quick port scan for it. nmap 5.0 running service scan (-sV) option against a snom phone may cause the phone to reboot. I can do this on snom v7.1.33 and 7.1.39. Foudn it out this afternoon so i'm still raising a ticket with Snom. i've run earlier versions of nmap previously and it doesn't cause this kind of error. highly amusing to know i can jump on someone's LAN and cause all their phones to reboot.