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.

good job

Also, thanks a lot for your feedback. It’s always a very good habit to question everything you read.

It appears that if you set a password you can resolve the unauthorized POST “initiate call” request issue: http://blog.tmcnet.com/blog/to.....solved.asp

Careful: no password is set by default!

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

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!

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?

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

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?

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 ;)

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.

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.