GET pwned: Web CCTV cams can be hijacked by single HTTP request

Server buffer overflow equals remote control

An insecure web server embedded in more than 35 models of internet-connected CCTV cameras leaves devices wide open to hijacking, it is claimed.

The gadgets can be commandeered from the other side of the world with a single HTTP GET request before any password authentication checks take place, we're told. If your camera is one of the at-risk devices, and it can be reached on the web, then it can be attacked, infected with malware and spied on. Network cameras typically use UPnP to drill through to the public internet automatically via your home router.

Proof-of-concept code to exploit the vulnerable web server in the cameras can be found right here on GitHub. It was published a few hours ago by a security pro going by the name of Slipstream, who reverse-engineered the cams' firmware and discovered the hole. Slip has previously appeared in these pages for exposing security shortcomings in UK school software, Dell computers and Microsoft's Secure Boot. The web server is present to allow owners to configure their cameras from their browsers.

It appears the exploited bug is thus: if the URL query string contains a parameter called "basic", its value is copied byte by byte from the URL into a fixed a 256-byte buffer on the stack. If you send a query longer than 256 bytes, you overflow the buffer and start overwriting the stack. An attacker can do this to prime the stack with memory addresses to control the flow of execution.

Instead of doing what its programmers told it to do, the server starts dancing to the hacker's tune – such as opening a remote-control backdoor. It's a textbook stack buffer overflow with return-oriented programming to hijack the server.

It gets better: the overflow happens before the server has time to authenticate the user, so even if someone has changed the default passwords, their gadget is still vulnerable. This is the offending code:

// ptr = start of the query's parameter value string
while ((ptr[i] != NULL) && (ptr[i] != '&'))
{
  queryval_cpy[i] = ptr[i]; // queryval_cpy is a 256-byte char array on the stack
  i++;
}

Hang on, we're not done yet: whoever crafted the firmware shared by all these devices modified the Goahead embedded web server and seemingly introduced the bug. According to Slip, more than seven internet-of-things CCTV camera vendors use the dodgy firmware.

Bug seems to be 2.5 years old (from ~april 2014). Titathink appears to be the responsible vendor (they sell whitelabel and to end users).

— slipstream/RoL (@TheWack0lian) November 29, 2016

The exploit's author claimed the following cameras carry the bug in their software:

• UCam247's NC308W and NC328W, Ucam247i/247i-HD, and 247i-1080HD/247-HDO1080 models (UCam247 says its latest firmware is not vulnerable, although version pre-6.10 is affected, by the way).
• Phylink's 213W, 223W, 233W, 325PW and 336PW.
• Titathink Babelens, TT520G, TT520PW, TT521PW, TT522PW, TT610W, TT620CW, TT620W, TT630CW, TT630W, TT730LPW and TT730PW (as Slipstream notes, it seems to be the entire product line, at least those still supported).
• Any YCam device running firmware 2014-04-06 or later.
• Anbash NC223W, NC322W and NC325W.
• Trivision 228WF, 239WF, 240WF, 326PW, 336PW.
• Netvision NCP2255I and NCP2475E.

Alert readers will have spotted repeating model-number patterns across different vendors. That's because while Slipstream first spotted the bug in UCam247 cameras, the upstream source of the software seems to be Titathink, with the other vendors taking its tech as white-label, along with the bug. Other cameras could well be vulnerable.

As we noted, it happens pre-authentication, so the best idea is not to let the cameras talk to the internet at all (which, of course, ruins the IoT's value-add that you can see the camera from your smartphone app, while letting the vendor harvest data).

The PoC works against firmware running in QEMU's ARM emulation; it's not always successful against real hardware due to small differences in builds and libc breaking the exploit's stack chain. These are easy to fix up if you're targeting a particular device.

The Register has contacted all the affected vendors for comment. We'll let you know if we hear back from any of them.

Would it surprise readers to learn that at least one of the vendors in question, Phylink, issued a firmware patch in October after the Mirai botnet hammered Dyn DNS, to remove a default password?

Of course not. ®