I suppose there are many people out there who want to achieve a greater good, fight evil corp and “show those guys”. So why not set a statement and become part of a botnet? #Irony!!! Of course I suppose (hope) that none of you actually want to be part of something like an IoT botnet, but joining could in theory be dead easy. So quite a while back I bought a dead cheap WiFi camera for use at home. It was kind of just as insecure as I had expected, so it got it’s own VLAN and stuff and here is why….
Recently KrebsOnSecurity.com was DDOSed by an apparent IoT botnet and although there does not seem to be any actual evidence, that the attack sourced from IoT devices it is by far not unrealistic. Many IoT devices offer certain Plug’n’Play functionality, like automatically making sure that the user is able to access them via phone. While the more expensive ones use some kind of backend service as a broker for the connections, the cheap ones use direct port forwarding. Most routers nowadays support UPnP – Universal Plug and Play – which enables a network client to automatically request a port forwarding. Although this might sound strange, there are valid use cases (for non-tekkies): Ensure, that friends can join a game instance on my box or a chat program can use direct file transfer or a file sharing tool can also allow other peers to connect (i.e. for sharing OpenSource software!). As such these programs are able to contact the router on the network, send a few requests and make the router expose port X towards the Internet and then forward all this traffic towards the user’s box. This of course comes with all pros and cons, as everybody on the Internet is able to fiddle with the exposed service and protection relies on either transport or application security (or both).
The same features come in a lot of “modern” IP webcams: Hook it up to the network, hit the cam’s web interface click a few buttons and there you go! It’s easy enough so that everybody who manages to attach the cam to the network can also enable the port forwarding. Of course the router has to support UPnP and it has to be enabled, but from what I’ve seen so far this is often the default configuration.
For this blog post neither model nor manufacturer are relevant. Not because I do not want to disclose any information, but because I have seen the same firmware on a lot of different webcams with different brandings. It is also the exact same firmware for both cameras with motors (pointing the camera) and ones without. For the latter there simply are controls in the web interface which don’t do anything. The only thing they have in common is the hardware on the inside and a price range of between 20€ and 60€. And they run on an RALink SoC with a MIPS architecture. (There also are other cameras with very similar issues.)
My cameras support both WiFi and Ethernet and run a web interface on port 81 and a Telnet server on port 23.
A Note on Using UPnP
When running UPnP I’ve so far seen two different results: (1) Only the web interface is exposed, (2) telnet is also exposed. One of my cameras had this feature enable by default, so the moment you attach it to your network it will rip a hole into your defense lines.
Also when activating UPnP the camera does not enforce the activation of authentication, so if its exposed to the Internet it will be owned.
When going through the settings menu you can change IP settings, usernames and passwords (max 8 characters or it will kind of break), set alarms but there is no sign of Telnet settings. Also quite a few settings aren’t necessarily functional: When you set something, store it and go back to menu the setting will be reset. This is the fact for a random variety of settings (but it seems static for each one). As such the web interface seems very very broken. I have to admit, I’ve never had the heart to actually break the web interface even further especially as its very unstable.
I’m not planning on starting a discussion on Telnet now but it’s insecure and simply not made to be exposed to the public Internet. Especially if the user himself has no way of actually configuring telnet and does not even know the password. Luckily, using some secret sophisticated Hacker magic and some advanced tools I was able to crack a valid account on the device: root:123456 .
I myself actually used this account to add a few extra tools to the camera to attach it to my network.
As the camera’s platform is generally open it would be trivial to put together a small binary for running on the webcam and, well, making it your slave. Above this there also seem to be quite a few of these online (they can be found easily with all well-known search engines). As mentioned before, the Telnet credentials are not generally documented for the camera so this interface can probably be misused on every available camera. On the other hand the telnet port is not always exposed to the Internet. From my experience with the camera, even though I have not analyzed the web interface, I do expect there to be a few critical vulnerabilities available which might be exploited. (Otherwise one might just use the firmware updating mechanism.)
This blogpost only covered one small range of IoT devices and I do expect that there are very many more devices with similar issues. Still I have not, yet, been able to make up my mind if the potential flaws in the web interface and the open telnet port actually are the big problem. Yes, they suck, they must not be there in a commercial product – but: No password -> No Security! Even if the cameras them selves were secure, users would still expose unconfigured cameras to the Internet. As such I’d love to see IoT devices which will not connected to the Internet before being properly configured (only allow the use of UPnP if a secure password has been set on the device). Most surely this sounds easier than it is, but it will probably be the only way of protecting users from themselves.
For those interested in IoT security: I will discuss hardware security of IoT devices at the IoT Insight Summit 2016 in a few weeks, and my colleagues will host some other cool sessions, too 🙂
A Quick Addition
Looking at Trend Micro’s documentation on “ELF_BASHLITE.SMB” from November 2014 you can actually see that my camera would already have been a target back then. ELF_BASHLITE.SMB has a scanner functionality which will generate random IP addresses, test for telnet and try to login using “root”:”123456″ (among other credentials). As such it could have been close to it’s second botnet birthday while I was writing this post.