123456 Owning ELRO IP Cameras
Sitting at a camping with a broken toe makes you bored, very bored in fact. So bored I started to look at the camping network structure.
Scanning the environment
The first thing I noticed was the cameras with a nice little antenna hanging all over the place. In an old DefCon talk I saw the security of most IP cameras was shit, so I decided to give it a shot myself.
The camera model I am currently talking about is the ELRO C903IP.2. I reversed the firmware of another ELRO camera and it had very similar directory structures and web commands, so I believe it is safe to assume all ELRO cameras are affected.
Because I had no idea of the network layout beforehand I ran a little nmap scan to get the list of online IP addresses in the local subnet:
MacBook-Air:~# nmap -sP 192.168.1.0/24 Starting Nmap 6.47 ( http://nmap.org ) at 2015-08-10 00:28 CEST Nmap scan report for 192.168.1.1 Host is up (0.0055s latency). Nmap scan report for 192.168.1.4 Host is up (0.00048s latency). Nmap scan report for 192.168.1.6 Host is up (0.057s latency). Nmap scan report for 192.168.1.7 Host is up (0.054s latency). Nmap scan report for 192.168.1.8 Host is up (0.047s latency). Nmap scan report for 192.168.1.11 Host is up (0.052s latency). Nmap scan report for 192.168.1.17 Host is up (0.044s latency). Nmap scan report for 192.168.1.24 Host is up (0.11s latency). Nmap scan report for 192.168.1.26 Host is up (0.0028s latency). Nmap scan report for 192.168.1.101 Host is up (0.0085s latency). Nmap scan report for 192.168.1.102 Host is up (0.0084s latency). Nmap scan report for 192.168.1.105 Host is up (0.021s latency). Nmap done: 256 IP addresses (12 hosts up) scanned in 9.12 seconds
The thing that struck me was the low addresses after the gateway
192.168.1.1 so I first checked those out. Turned out the lower addresses were DHCP (my MacBook was
192.168.1.4). I did find a nice open printer though:
Web authentication gone wrong
After some more checking I found a login screen at
192.168.1.101. This could be a camera!
Trying some default stuff (admin:admin, admin:1234) etc. didn’t appear to work, so I just pressed the Cancel button:
Besides the lack of even a self-signed HTTPS certificate it was obvious that even the login screen had serious security issues. After the initial state of shock I decided to check out the page source code:
check_user.cgi appears to be the page generating the HTTP authentication (which is plain text by the way). The page only shows us
401 Unauthorized and the name and version of the web server
mini_httpd/1.19 19dec2003. There are some known vulnerabilities for that version, but they had no POC code for reading files so I put that on halt for the time being.
get_status.cgi requires no authentication (wtf) and it shows some identifying information like the system version and some other status information
Since there were some links on the login page I decided to try and sign in to the camera web interface. Clicking the link and pressing cancel a few times showed the full web interface, but unfortunately the feed was black.
An unexpected surpise
Trying to click some of the terrible popup menus on the left (I had been a few hours on the web interface at this point) gave some more device information (obtained from the
get_status.cgi), but the P2P menu showed some actually interesting stuff!
The iframe led me to
p2p.htm, which contained some GUID, a username and a password (you are kidding me right?) Just setting the input type to
text with the inspector revealed the details in full glory:
Checking the source it turns out that
get_tutk_account.cgi has no
.htpasswd protection which is why it shows the password in the web interface.
Theory in practice
Googling for a P2P IP Camera app gives this nice app that automatically gets the running cameras:
Selecting the right camera and entering the password given by the web interface shows this nice feed by the campfire (notice me walking around with crutches):
The other cameras have the same vulnerability (probably the same model):
Going for gold
After this serious issue I couldn’t get much further with the web interface (just some directory listings, but no directory traversal or anything). I did try to access
.htpasswd (read something about that for old versions of mini_httpd), but it gave a graceful 403.
Let’s try another nmap scan to see what services are running on the device:
MacBook-Air:~# nmap -sV -vv 192.168.1.101 Starting Nmap 6.47 ( http://nmap.org ) at 2015-08-10 00:52 CEST NSE: Loaded 29 scripts for scanning. Initiating Ping Scan at 00:52 Scanning 192.168.1.101 [2 ports] Completed Ping Scan at 00:52, 0.00s elapsed (1 total hosts) Initiating Parallel DNS resolution of 1 host. at 00:52 Completed Parallel DNS resolution of 1 host. at 00:52, 0.02s elapsed Initiating Connect Scan at 00:52 Scanning 192.168.1.101 [1000 ports] Discovered open port 80/tcp on 192.168.1.101 Discovered open port 23/tcp on 192.168.1.101 Increasing send delay for 192.168.1.101 from 0 to 5 due to max_successful_tryno increase to 4 Completed Connect Scan at 00:52, 6.99s elapsed (1000 total ports) Initiating Service scan at 00:52 Scanning 2 services on 192.168.1.101 Completed Service scan at 00:52, 7.00s elapsed (2 services on 1 host) NSE: Script scanning 192.168.1.101. NSE: Starting runlevel 1 (of 1) scan. Nmap scan report for 192.168.1.101 Host is up (0.0026s latency). Scanned at 2015-08-10 00:52:16 CEST for 14s Not shown: 998 closed ports PORT STATE SERVICE VERSION 23/tcp open telnet BusyBox telnetd 80/tcp open http mini_httpd 1.19 19dec2003 Read data files from: /usr/local/bin/../share/nmap Service detection performed. Please report any incorrect results at http://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 14.24 seconds
There is telnet! Trying
telnet 192.168.1.101 asks for a login and password, but at least it is not blocking connections! Not sure how that would work out remotely, but I suspect it would connect just fine.
Trying some of the worst passwords of 2014 it appears to actually be using the worst password in the world for root access:
MacBook-Air:~# telnet 192.168.1.101 Trying 192.168.1.101... Connected to 192.168.1.101. Escape character is '^]'. (none) login: root Password: BusyBox v1.12.1 (2012-11-19 22:34:42 PST) built-in shell (ash) Enter 'help' for a list of built-in commands. #
Some firmware reversing adventures led me to check in the
/mnt/5350 directory (I might write something about that another time):
# ls var tmp sbin mnt lib home etc bin usr sys proc media init etc_ro dev # cd mnt # ls pdbmountfs 5350 mtd bin test.sh tmp nfs # cd 5350 # ls mini_httpd.conf modules web etc user_info usb_reset_logfile lib
user_info file looks interesting:
# cat user_info admin:1357#
Well, looks like plaintext credentials for the web interface to me. Trying it and it works perfectly fine:
So that would be about it for this blogpost. Before I finish I do want to say that this research was done just for fun and no cameras were harmed in the process. Another thing is that I had access to the local network. I think that if you isolate these camera’s on a separate subnet and make sure they are not accessible from the outside (or only accessible from a fixed IP address with firewall rules in the router) you will be fine.
After this post is published I will send a link to ELRO to inform them about the security issues discussed here. If they release a firmware update to fix these issues I will update this post.
Till next time,
PS For Natalia: ❤️️
blog comments powered by Disqus