All your video are belong to us. The Foscam webcam

There are two issues in older firmware for the Foscam FI9831P webcam – fortunately these are fixed in the late versions of the software, so I can write about them. If you have one of these things you should upgrade though.

The lessons here are twofold – first, always keep your firmware up to date, and second, ensure that your software isn’t vulnerable to such problems.  If you haven’t updated, go and find the latest firmware here http://foscam.us/firmware – or use the link within the web interface of the device.

XSS

The first problem is that the firmware will happily do a site survey of wireless channels in the area, but doesn’t correctly sanitise the SSIDs before they are written to the web page. This means that if you create a wireless access point with SSID as follows:

Then you will get javascript code execution on the web interface of the Foscam – i.e. a cross-site scripting (or XSS) vulnerability when you perform a wireless site survey. Note that you need to purchase a very short domain to fit this into the limit of 32 characters for an SSID.

That’s one issue, which could in theory allow an attacker to alter the configuration of your device, or to redirect you to a phishing page for example.

The second problem  is a Cross Site Request Forgery problem, which is an unwelcome peculiarity of the web browser/server ecosystem.

Cross Site Request Forgery

The issue around CSRF arises because a web server can’t always tell the difference between a genuine request and one that is forged by another site using JavaScript. Essentially the only difference is a few headers like Referer. The cookies for the site get sent automatically by the browser so you cannot just rely on a valid session cookie.

Checking the Referer header is sensible is generally sufficient in the absence of XSS issues, but there are better ways to fix it.

Anyway, because we think the Foscam is likely to be on a home network, and we can read the computer’s own IP address on some browsers, we can spray the CSRF around the local network. In this PoC I’ve chosen to match on something like 192.168.1-10/24 and then send the attack to every address on whatever network we find.

I’ve provided the code to do this below; some of it is borrowed off random people on the Internet, so thanks very much for that to “mido” on stack overflow. (See http://stackoverflow.com/questions/391979/how-to-get-clients-ip-address-using-javascript-only ) This isn’t anything like production quality and was only hacked together to prove the point.

https://github.com/pentestpartners/bits-for-blog/blob/master/foscam.html

And here’s the two files that are invoked as IFRAMEs. The first sets the FTP server details:

https://github.com/pentestpartners/bits-for-blog/blob/master/iframe-foscam.html

And the second configures the frequency of uploads:

https://github.com/pentestpartners/bits-for-blog/blob/master/iframe-foscam2.html

Now, host these three files on a website you control, log in to the web cam and then visit the URL of the first file.

It should spawn something like five hundred IFRAMEs to conduct an attack against the local network, two for each IP address. (It’s not subtle, but it works – in real life, I’d probably hide these if I was conducting a genuine attack rather than creating a proof of concept.)

Then, with a reasonable amount of luck and a tail wind, you can see the web cam start uploading files to your nominated FTP server:

So, please do make sure your software isn’t vulnerable to CSRF or XSS, or really quite bad things can happen – in this case, people can get a feed  of pictures off your internal security cameras. In this case, I’m only testing and it’s not very interesting.

XSS can be prevented by HTML encoding all user-supplied input before it is written to the web page – even things like SSIDs which you might not expect to be malicious. CSRF is best dealt with by having a per-session token which needs to be submitted with each request, however in a pinch and in the absence of XSS it is sufficient to check the Referer header is coming from your device and not other sites.

Please don’t assume that because your thing is consumer grade it isn’t at risk from attackers, or that it doesn’t contain information worth stealing.

I should also say thanks to Petko D Petkov / GNU citizen for inspiration in the BT Home Hub series of blog posts they did quite a few years back. This is also why full disclosure is best – PDP’s post from that long ago has led to quite a few embedded devices being fixed for CSRF / UPnP issues before Internet of Things was a thing. (Back when we used to call these things “embedded devices”.)

References:
http://www.gnucitizen.org/blog/bt-home-flub-pwnin-the-bt-home-hub/
http://www.gnucitizen.org/blog/bt-home-flub-pwnin-the-bt-home-hub-5/