Hacking Linksys IP Cameras (pt 1)
During the easter break, I was playing with my my wireless Linksys IP camera which, although I bought several months ago, I hadn't taken my time to give the attention this beauty deserves until now! :)
The model in particular is the WVC54GCA, which I would say is one of the most affordable Wi-Fi IP cameras out there (about GBP 80 in the UK), making it a great toy to tinker with. I found the camera to be quite good functionalities-wise, although I've experienced availability problems with it. It seems the camera freezes every once in a while. Well, this is true at least when you heavily customized its configuration which is what I've ultimately done after playing so much with it.
I've loved playing with embedded devices for a while, and as a security researcher I find it quite an interesting topic as many "de facto" security principles that are usually (attempted to be) followed when designing other types of systems are not often applied to embedded devices. This, I believe is due to lack of limitations in hardware resources, and lack of awareness on consequences of getting a miscellaneous device compromised. i.e.: "who cares if my IP camera gets owned?"
During the next days, I'll be posting some vulnerabilities I've found. Some of them are fun and serious, while others you might find kind of boring.
Meet the target
You can learn a lot about the specs of a device by simply reading the product's literature. However, sometimes not enough info is provided in these documents. The following are some of the specs I confirmed by interacting with the camera in various ways:
- CPU:
Faraday FA526id(wb) rev 1 (v4l)according to/proc/cpuinfo - OS:
Linux version 2.4.19-pl1029according to/proc/versionplus Busybox (confirmed as the file/bin/busyboxexists on the filesystem) - HTTPD:
thttpd 2.25b(extracted from banner returned on default html error pages and 'Server:' HTTP headers) - Memory: 30908kB (32 MB?) according to
/proc/meminfo - Firmware Version: V1.00R22 and V1.00R24 (latest version available as on 16th April 2009)
It also comes with a telnet daemon (/usr/sbin/telnetd) but unfortunately for hackers out there, the daemon is disabled as the following line is commented out on /etc/init.d/rcS:
# ---- Start Telnet Server (debug) ---- #
#/usr/sbin/telnetd &I have not yet managed to get a remote root shell by enabling the telnet daemon but have found some vulnerabilities which might help accomplishing this goal. I will be releasing these vulnerabilities in the next days. Please let me know if you know how to enable the telnet daemon on Linksys IP cameras! Ideally, I'd like to accomplish this without physically connecting to the camera or flashing the firmware.
Remote admin compromise by unauthenticated attackers due to wizard design error
I found this vulnerability while investigating CVE-2008-4390. I wanted to know if CVE-2008-4390 affected my camera, even though it was reported to affect a different Linksys IP camera firmware and model. The CVE entry states:
The Cisco Linksys WVC54GC wireless video camera before firmware 1.25 sends cleartext configuration data in response to a Setup Wizard remote-management command, which allows remote attackers to obtain sensitive information such as passwords by sniffing the network.
So I started trying to figure out if the WVC54GCA also discloses sensitive information when communicating with the wizard. According to the vendor, the issue has been fixed:
Solution: 2300 and 210 have encrypted data and have no such issue. To decode the data, an administrator username/password is a MUST.
At first sight, when capturing the traffic between the wizard and the cam, I couldn't see the data traveling in human readable form. While trying to figure out how the data is sent over the network (i.e.: encoded/encrypted), I realized there was something seriously wrong with the handshake mechanism.
The following is a very generic (and possibly inaccurate) description of the handshake
- Wizard (
SetupWizard.exe) sends UDP request to255.255.255.255:916 - Camera responds back to
255.255.255.255using the DCERPC protocol and presents itself with identity info such as the value of thedefnamevariable which looks likeLKXXXXXX, whereXis a hex digit. This identity info is picked up bySetupWizard.exe. Some of this info such as MAC address, IP address and subnet mask is shown in the wizard. - From now on,
SetupWizard.exeuses the camera'sdefnamevariable when talking to it, so that the camera knows what requests submitted to255.255.255.255:916it should respond to.
At this point the wizard has discovered the camera and the user can go through the setup procedure. For security reasons, the user needs to enter the admin username and password, before the setup process can start. Otherwise anyone could make changes to the camera without authenticating.
Now, here is the important bit. If you capture the network traffic while running SetupWizard.exe, you'll notice that when the user is asked to enter the admin username and password after the camera is discovered, there are NO requests sent from the wizard to the camera in order to verify that the entered username/password combination is correct!
"How is this possible? What the heck is going on?!" I thought. I was terrified to confirm my worst fear: the wizard already knows the camera's admin username and password at this point, thus there is no need to ask the camera again. Indeed, at this point - before the user enters the admin username and password that is - the camera's credentials are already loaded into the memory of the SetupWizard.exe process. This is because the camera has previously transfered the admin credentials along with other configuration data!
In case I didn't explain myself properly I'll summarize the issue by saying that the camera transfers the admin username and password to the wizard before the user enters them. The following steps demonstrate how an unauthenticated attacker can remotely obtain the camera's admin username and password:
- Download the setup wizard. You might need to download a different wizard if you want to test this vulnerability on a different Linksys IP camera model
- Run
SetupWizard.exe - Click on
Click Here to Start / Setup Camera / Next(after accepting EULA) /Next(4 more times in total) - The discovery process is quite flaky, so if the wizard hasn't found your camera yet, click on
Search Againas many times as required until it works - You should now see your camera's name under the
Camera Listcolumn and also various configuration data under theStatuscolumn: - You now need to dump the process memory of
SetupWizard.exeusing your favorite tool: - Then open the memory dump file using your favorite hex editor
- Now you can either search for admin and find the admin password after a few null bytes, or tell your hex editor to go to decimal position 75058 (
Address / Goto ...menu on XVI32). In my case the admin password would always fall within this position:  - Have fun! (the most important step really)
It is somehow ironic that a free tool provided by the vendor of a product can be used as a hacker tool against their own product.
As far as I know, this vulnerability cannot be exploited over the Internet, since the camera only responds to wizards located in the same LAN. Never say never though, so if you find a way to exploit this vulnerability over the Internet, please contact us.
UPDATE: CPU and additional OS info added.
Archived Comments
Tod
$ md5sum SetupWizard.exe
1c7cb77e906152376102b88604650577 SetupWizard.exe
