PwnPhone: Default passwords allow covert surveillance.

A few weeks ago, I was asked to observe an installation of several wireless access points & VoIP phones, with a view to making recommendations on how best to improve security while maintaining ease of deployment.

It didn't take long for several trends to appear; chief amongst which was the use of

We'll just use defaults, for now. That password will do, for now.

Of course, as soon as the device burst into life, it's on to the next one. At which point, "now" becomes a distant memory, along with any thoughts of hardening the device for use in a commercial setting.

This was not a fly-by-night company either, nor do they install cheap & cheerful hardware; we're fitting enterprise-grade Cisco, Snom & Ubiquiti UniFi equipment. With a tight schedule & reputable brand names, I completely understand why many installers trust the default configurations so vehemently.

A default config is rarely a secure config.

A default configuration is only intended to restore a device to a "default" state, such that a competent installer can configure it to meet the client's needs.

Note: This is neither aimed at nor unique to Snom devices. I'm aware of similar exploits against current Cisco devices too.

In the following example, I've reset a Snom 320 VoIP phone (running 8.7.5.13 firmware) back to factory "default" settings.

Even before we begin, there's a serious problem... there's no authentication whatsoever!

To their credit, some manufacturers provide a default set of credentials... even if they're usually "admin/admin", thus equally insecure.

Snom however, opted to place a tiny "HTTP password not set" warning at the top of the configuration screen. That'd be fine if it forced you to set a password during the setup process, but it doesn't.

To make matters worse, it's only too happy to accept a single character/number password too.

They're sat behind a strong firewall, so what's the big deal?

A reasonable argument, you might think. So, let's put it to the test.

Hijacking the Snom 320

Step 1: Visit a site which contains the exploit payload.

That's it.

Simply by opening a malicious site (or a genuine site containing the malicious payload), the attacker has complete control over our VoIP phone.

To demonstrate this vulnerability, I enlisted the help of two colleagues... Per Thorsheim & Scott Helme. Per will play the part of our attacker, embedding the exploit on a site which he controls. Meanwhile, I'm reading Per's site while having a private conversation with Scott, via Skype.

Unbeknownst to me, Per has forced my VoIP phone to call his premium rate number and disabled the speaker, so unless I'm looking at the phone, I wouldn't know it's dialling.

Note: We've left the activity LED on during this demo, as it's difficult to read the screen. When the light illuminates, the phone is dialling out.

What can the attacker do?

Virtually anything.

Make calls, receive calls, transfer calls (even before it rings), play recordings, upload new firmware and crucially... use the device for covert surveillance.

Our self-defeating approach...

If we look beyond the IP telephony sector to the industry as a whole, many companies ship devices which have no "default" security... or permit the use of weak credentials which provide nothing more than a false sense of security.

It has to stop.

Vendors - If you must supply devices with "default" credentials, disable all other functionality until a suitably-secure password is set to replace it.

Summary

The term "covert surveillance" is usually only associated with nation states, certain 3-letter agencies and those closed-minded individuals pushing the Investigatory Powers Bill (IPBill / Snoopers Charter).

In this demonstration, the attacker has not only compromised your phone & privacy with just a browser, but you've paid him for the privilege!

If you install, use or just find yourself sat next to one of these devices, just remember... it's basically a PC, with all the security vulnerabilities associated with them. Don't assume it's safe because it's running as the manufacturer intended; seek professional advice.

1. Use strong passwords, derived from a password manager.
2. VLAN / network segregate your phones, if possible.
3. Restrict access to APIs, even if they're only visible internally.
4. Check & upgrade your firmware regularly, ensuring it doesn't revert to "defaults" afterwards.

Just today, Professor Alan Woodward of Surrey University published an article entitled "Are you the only one using your VOIP phone?" which discusses the various attack vectors & implications associated with VoIP devices. If you haven't yet subscribed to Alan's RSS feed, I'd strongly suggest doing so.

Thanks to Per Thorsheim & Scott Helme for their help with this demonstration.

That's it folks... for now.