Blog: Internet Of Things
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.
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:
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
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.
And here’s the two files that are invoked as IFRAMEs. The first sets the FTP server details:
And the second configures the frequency of uploads:
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”.)