Spare Clock Cycles Hacking is freedom.

23May/1112

Exploiting an IP Camera Control Protocol

When I first started on this post, I intended to write about some fun things one can do with a $30 Rosewill IP camera (RXS-3211). While I still intend to do this in the near future, I decided instead to document an interesting password disclosure vulnerability I found that appears to affect at least 150 different IP-based surveillance cameras. This vulnerability allows a remote, unauthenticated attacker to read and/or change the administrator password on affected devices by sending a single UDP packet. This gives an attacker full control over the device, including access to the video streams. Relatedly, a passive attacker on the local network can retrieve the current password without a MITM attack if the device is currently being administrated.

Before I start, though, I would like to clarify: I have only tested this attack against the RXS-3211, as it is the only one I own / can afford. That said, I believe that it is a problem with the management protocol rather than just the device itself. It is possible that the problem is limited just to the RXS, but I have tested the Windows admin interfaces of other cameras with similar results. Doing this actually helped me improve the attack, so it seems likely that it will work elsewhere. Regardless, I would definitely love to hear from anyone who has a possibly affected device and get feedback / pcap dumps.

The list of affected devices, pulled using strings from the Rosewill admin executable, can be grabbed here. It includes devices from Edimax, Hawking, Rosewill, Intellinet, Nilox, Zonet, 2Direct, among others. Many of these appear to be rebrands, but I can't really know without devices to look at. This list does not include the large number of "UnKnown" entries that could also be affected.

Why I Can't Have Nice Things (I Break Them)

I bought the previously mentioned camera this week as a cheap way to monitor my apartment. Not content simply to set the thing up and leave it be, I first wanted to kick the metaphorical tires a bit. It turned out to be running an embedded version of Linux, and had TCP ports 80 (HTTP), 554 (RTSP), and 4321-2 (proprietary viewing protocol) open. At this point, I became curious to see if I could run my own code on the thing (which could make it quite useful), so I started poking around for vulnerabilities that might allow for that.

The web interface quite probably provides a number of ways to get a shell, but I decided first to look at how the administrative control application that was provided with it worked. Interestingly, as soon as I opened the application, it had detected my camera. I fired up Wireshark, and it turned out that it was communicating to the device via UDP broadcast messages to port 13364.

How Not To Design a Protocol

After some glancing over the traffic logs, it was pretty clear that this control protocol was terrible. I could go on for awhile about the design problems with it, but it would be rather off topic.

The real problem I uncovered was how the protocol handles authentication. It's a simple protocol, and consists of request packets (sent by the admin software) and reply packets (sent by the device). Depending on the request, the response is either sent broadcast or unicast. The packets all follow the same format before diverging:
6 bytes -> Concerned device (FF:FF:FF:FF:FF for all, device MAC for specific)
1 byte -> Request or response (0 or 1 respectively)
3 bytes -> Req/resp type (some unique ID that the software understands)
Rest -> Req/resp specific payload (optional)

Each type of request/response seems to have a set size, and if you send one of an unexpected size, the packet is ignored. From the large number of null bytes in the packets, it seems that there are extra fields that can be provided that I haven't explored yet. The one we care about, however, is obvious: the password field. Yes, the password is sent, (and in some cases, broadcast) in clear text following an unauthenticated request from anywhere. The admin interface reads this password, authenticates users client side, and, if it passes, will allow the user to send configuration requests. In addition to just being able to steal the device password remotely, we can also change the password and do it with a spoofed UDP packet, hiding the source of the attack.

I ran into a bit of a problem with the Rosewill-provided management interface, but it wasn't too difficult to overcome. It only supported broadcast queries and settings, which made it impossible to read the password remotely (i.e, outside the local network), and no response would be given if one set the password, making scanning much more difficult. However, I assumed they must have a way to get a unicast response instead, as some other camera manuals advise users to forward UDP port 13364 on their routers. Rather than trying the codes manually, I downloaded a few different management interfaces until I found one that supported remote cameras. I set it up to talk to mine, and voila, unicast commands were mine.

With these, it's trivial to read or change the password of the device. This can be exploited remotely and, as mentioned, with a spoofed source address for the set command (yay connectionless protocols). Having the password then gives full administrative control over the device, allowing an attacker to basically do anything, from simply watching the camera feeds to exploiting the device further. If you have one of these devices yourself, you can test with my proof-of-concept code: rxs-3211-changepw.py and rxs-3211-retrievepw.py (both require Scapy) . I also went ahead and made a Metasploit module that will scan a network for vulnerable hosts: rxs-32111-retrievepw.rb . If it's in the list but is not the RXS-3211, then the packets that need to be sent may be significantly different (probably  just the changepw packets), but the underlying protocol problem should still be present. Wireshark/tcpdump are your friends; use them, and you should be able to figure it out.

EDIT: The Metasploit people were kind enough to improve my module and throw it into their SVN, so you can grab it there. Thanks, guys!

Disclosure

The fact that this vulnerability appears to be a design issue that requires both firmware and client software patches, combined with the large number of affected devices, makes it very difficult (if not impossible) to patch in any reasonable timeframe. This, together with the confusion over who actually maintains this software, led me to decide to release this before patching so users could protect themselves by blocking access to port 13364. I did contact Rosewill prior to this post, but have not yet received a reply.

The Rest

If you have one of these devices, block all external access to UDP port 13364, regardless of what your user manual instructs you to do. If attackers might have local network access, there is not much you can do but cut it off from the rest of the network. Other cameras might be different, but mine did not have an option to disable UDP management.

I know cracking some of these embedded devices is a lot like beating a three year old at a foot race, but it was a good way to occupy a few hours. Hopefully I'll be back in a short while with more fun things to do with a cheap IP camera; until then, peace.

Comments (12) Trackbacks (1)
  1. I’m lovin’ the Metasploit module. Keep up the good work as this is valuable information for others to learn from.

  2. Great post, thanks for the hard work and info! I just had 5 of these cameras delivered today. I’m wishing I would have found this post before I made my Newegg purchase. If you don’t mind I’d like to link this url in my review.

  3. @Anti-Forensics Thanks, I’m glad it was useful!

    @Matt Thank you as well! I appreciate the praise. Feel free to link to this post anywhere you’d like!

  4. Your findings seem to confirm my thoughts about IP cameras:
    http://www.csaba.se/2011/05/13/nothing-to-hide-vs-nothing-to-fear/

  5. @supernothing : Thanks, I’ve included this in my Newegg review now. You said “It turned out to be running an embedded version of Linux” and “The web interface quite probably provides a number of ways to get a shell”. Would you elaborate on those two please? I’m also curious about running custom apps.

  6. Exploit confirmed on Edimax IC-1510WG. Unfortunately, some other settings are exposed, such as the camera name, smtp server, email address, email subject. But nothing compares to seeing my beloved password in plain text. Must change that firmware…

  7. Well, my overall goal was to be able to compile my own firmware for the thing, but Rosewill didn’t provide any images on their site. Instead of that, my temporary goal was to find a way to get a shell on the device so I could confirm the specs and possibly find what device it was a rebrand of. Often a good way to do that on these embedded devices before cracking it open and hoping for a serial connection is to look for command injection vulnerabilities in the web interface.

    As it is, I *believe* I have managed to track down the rebranded model, and am working on modifying the firmware now. I’ll hopefully have a how-to post here in the near future on how to get everything working.

  8. Guys there is a serial port inside this camera, I posted it over on hackaday.com. I managed to brick the ethernet interface on my first one. I just erased the NOR on the second one. I’m stuck at the Prolific bootloader, anyone finds a flash file for this, post it please.

  9. Shawn: I saw the post, well done. Interesting that they have one, but it’s actually not necessary to crack it open to customize the thing. The camera is a rebranded Edimax IC3005, so you can actually repackage that device’s firmware and flash it onto the RXS-3211. I’ve done it successfully a couple times now, but I made an idiotic mistake and bricked it soon afterwards (squashfs != squashfs-lzma -_- ). Waiting on getting a new one before posting details on how to do it, but if you’re interested, email me (supernothing 4T spareclockcycles D 0t org)

  10. Already had this, been using it to compile firmware images. Thanks anyway for the tip though, appreciate it.

  11. nice post…. i like this….


Leave a comment