Snom VoIP phone vulnerability enables phone history theft, addy book poisoning, and more
Fellow VoIP blogger and multi-skilled polymath Tom Keating picks up on security consultancy GNUCitizen.org's description of a security vulnerability in snom Technology's model 320 VoIP phone.
GNUCitizen, in turn, found this via what they term a "side result" of a router hacking challenge for this phone.
What's come out of this is the realization of a hack that could enable outbound calling using a spoofed CallerID.
Dude, that's so not OK.
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.
Yes, the bad people would need the IP addy to get a hack going, but as Hackers will need the IP address of the phone being targeted to launch the attack, but as Tom points out, a scanner could be utilized to launch a cross-site scripting attack to hack the phone's built-in management UI.
Now, there's nothing stopping a hacker but his or her conscience.
Not to say that hackers have a conscience.
So at this point they might not overcome the temptation to:
- 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.
But that's just for starters. As Tom points out, that hypothetical evildoer (my term) could call the victim's number. Their snom-enabled connection would accept the call and make a recording of the incoming sound. What makes this even more perilous is that this phonedoes not offer any audio alert-like feedback that a call is coming in. No ring tones or anything like that.
Cascading this scenario further:
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.
Snom has not sent a patch through, but now that all this stuff (such a gentleman I am) has hit the fan, I'd be looking for something in that vein soon.