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.
My Camera(s)
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.
Web Interface
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.


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


Playing Botnet
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.)
Some Thoughts
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.
Brian
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.