Hacking Linksys IP Cameras (pt 1)

Mon, 20 Apr 2009 07:40:35 GMT

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-pl1029 according to /proc/version plus Busybox (confirmed as the file /bin/busybox exists 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

  1. Wizard (SetupWizard.exe) sends UDP request to 255.255.255.255:916
  2. Camera responds back to 255.255.255.255 using the DCERPC protocol and presents itself with identity info such as the value of the defname variable which looks like LKXXXXXX, where X is a hex digit. This identity info is picked up by SetupWizard.exe. Some of this info such as MAC address, IP address and subnet mask is shown in the wizard.
  3. From now on, SetupWizard.exe uses the camera's defname variable when talking to it, so that the camera knows what requests submitted to 255.255.255.255:916 it 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:

  1. 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
  2. Run SetupWizard.exe
  3. Click on Click Here to Start / Setup Camera / Next (after accepting EULA) / Next (4 more times in total)
  4. The discovery process is quite flaky, so if the wizard hasn't found your camera yet, click on Search Again as many times as required until it works
  5. You should now see your camera's name under the Camera List column and also various configuration data under the Status column:
    Wizard Cam Discovery
  6. You now need to dump the process memory of SetupWizard.exe using your favorite tool:
    setupwizardexe Mem Dump 2
  7. Then open the memory dump file using your favorite hex editor
  8. 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:
    Admin Password Extraction 1 Admin Password Extraction 2
  9. 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.

TodTod
Aw man, no pcap? Don't make me go out and buy one of these things just to see if I can't decode the handshake...
ZachRZachR
Very nice. Keep up the great work!
pagvacpagvac
@Tod: the only reason i didnt post the pcap file is because the handshake (whether truly encrypted or not) will include config data that's specific to my camera (i.e.: MAC address). call me paranoid, but i rather not post it. besides, these cameras are relatively affordable. @ZachR: thanks for the nice comment :)
j-zeroj-zero
yeah linksys. epic fail.
CERTCERT
http://www.kb.cert.org/vuls/id/528993 Old news
pdppdp
ahhhhhhh, r u sure this is the same vuln?
JustinJustin
Ok I just ordered one to try this myself. [email protected]
pagvacpagvac
@CERT: the US-CERT note you mentioned (VU#528993) is the same as CVE-2008-4390 which I *did* talk about in this post. It might not be the same exact issue but it's hard to tell as there is very little info provided by CVE-2008-4390/VU#528993. Please note that: 1) a different model (WVC54GC) was reported to be vulnerable on CVE-2008-4390/VU#528993 2) the data didn't seem to travel unencrypted in the case of the WVC54GCA during communications with the setup wizard (maybe just encoded/obfuscated?). VU#528993 mentions: "This packet is sent over the network unencrypted", which doesn't appear to be true for the WVC54GCA (at least at first sight, further digging might reveal otherwise) 3) there is no fix available for the WVC54GCA at time of writing, while Linksys did release a fix for the WVC54GC I tried contacting Andre Protas and Greg Linares who found the issue you mentioned (CVE-2008-4390/VU#528993) in order to gather more details, but I received no response. It might be possible that Linksys did fix the issue of sensitive data traveling in the clear when the wizard communicates with the camera, but might have still left unfixed a fundamental flaw: the camera sends the admin password to the wizard before the user even enters them on the wizard. I guess the developer(s) didn't think of someone examining the memory of the wizard process?
shawnmershawnmer
Looks like the Linksys Setup utility has been pullled from the link you provided above: WVC54GCA-CD-Content-10-25-2007_SetupWiz.zip
pagvacpagvac
@shawnmer: Linksys updated the wizard URL. The new link is http://downloads.linksysbycisco.com/downloads/WVC54GCA-CD-Content-10-25-2007_SetupWiz,0.zip FYI:
$ md5sum SetupWizard.exe 
1c7cb77e906152376102b88604650577  SetupWizard.exe
------
Has anyone tried to sniff and playback the video stream (probably mpeg4) of these IP cameras?
WaylandWayland
I can confirm that the camera does lock up on occasion but clears itself and it's light sensitivity is not as good as a Sitecom Wifi camera. However it's an excellent price and works very well with Go1984. It would be interesting to turn a router or a print server into a mini USB camera server.
rmadeatrmadeat
Very nice. Thank you
william cwilliam c
if its running linux why hasn't anyone written a replacement os like dd-wrt for the routers. the cameras credentials for the plugin are out of date so the only way to view it with out the pc software is to make your browser vulnerably to unsigned content. so why doesnt some code genius do just that and write a more updated os for the camera i mean look what dd-wrt did for the wrt54g