CVE-2014-1849 Foscam Dynamic DNS predictable credentials vulnerability

CVE-2014-1849 Foscam Dynamic DNS predictable credentials vulnerability

 

Date Published: 05-08-2014

Class: Design error

Remotely Exploitable: yes

Vulnerability Description:

 

Foscam IP camera vendor provides a Dynamic DNS (DynDNS) service. Every Foscam camera has a preassigned FQDN of xx####.myfoscam.org format, where 'x' is an alphabetic ASCII character and '#' is a digit. Each camera has a unique host name associated with it. That host name is flashed into the camera memory and is printed on a sticker on the bottom of the camera. The corresponding unique entry is created in Foscam DNS server for every manufactured camera. If the Foscam DynDNS option on the camera is enabled then that entry is updated with the current IP address of the user on every camera boot.

For updating DNS entries Foscam employs a custom protocol over UDP. This custom protocol uses the camera subdomain as a username and password to verify the authenticity of the request thus making it possible for an attacker to overwrite an arbitrary camera record in the Foscam DNS server. Existing setup doesn't have a mechanism to change the username/password neither on DynDNS nor on the camera. 

Report timeline:

* January 30th, 2014 - Foscam was notified

* February 6th, 2014 - Vendor acknowledges the receipt of the email and asks for technical details

* February 19th, 2014 - Vendor contacted again and asked to confirm the vulnerability

* February 19th, 2014 - Vendor acknowledges the vulnerability and outlines the plan to address the issue. Vendor asks to withhold the disclosure until May 1st, 2014 so that the fix can be rolled out.

* April 30th, 2014 - Vendor notifies that newly manufactured cameras will contain the fix. Vendor confirms that the existing cameras will not be fixed.  

---

Some details on how things work there:

Every time Foscam sends a manufacturing order to their vendor, they create a large batch of consecutive entries in the DynDNS to be used with new cameras. Those entries are initialized with 127.0.0.1, which distinguishes them from nonexistent subdomain entries.  Currently, valid entries are in the range of aa0000 -ep9310 with some blank pots in the middle, which gives us roughly 700K valid records. More than 300K records resolve to routable IP addresses, which means that many cameras have enabled Foscam DynDNS service at some point, and are possibly under threat of being hijacked.

Prior to firmware version  11.37.2.49, it was impossible to turn off Foscam's DynDNS, but was possible to use third party services. Version 11.37.2.49 introduced an option to turn off communication to Foscam DynDNS.

The use of UDP and predictable credentials make it possible to spoof source IP address to populate arbitrary DNS records with bogus/target IP addresses. 
Here is how DNS entry updated works:

- first packet goes to server ONE to port 8080 which is the actual DNS server. If credentials match, it replies with a packet, which includes an IP address and port of server TWO. The value of that IP address varies between two IP addresses

- client sends almost identical to the first one packet to server TWO, after which the server ONE updates the DNS record on DNS running on server ONE with source IP of first message.

Proof of concept code can be found at here . Attacker issues a UDP packet to the server ONE and immediately after that to server TWO at both possible IP addresses that can appear in the response to initial request, which makes possible spoofing source IP address, since receiving replies is irrelevant.

Several attack scenarios are possible using this vulnerability:

- Attacking the camera: rewrite the DNS entry to point to the fake camera login page to steal credentials/respond with HTTP 401 to capture credentials cached by the browser

- Attacking the browser: set up a reverse proxy that injects script element in the original response pointing to malicious script to do ui redress attacks, hook with BeEF, etc.

- Attacking third party website: rewrite multiple DynDNS records to a victim IP address and get a HTTP request flood DDoS. Not confirmed, as our ISP filters IP packets with spoofed source. UDP proxies to the rescue, may be 

Anyway, Foscam is not going to address this issue for existing devices, so the only thing to recommend - do not use Foscam DynDNS.

Our slides on other stuff around wireless IP cameras

Ride safe, 

Sergey Shekyan and Artem Harutyunyan

 

Update 05/15/2014: Foscam surprised us yesterday by releasing firmware update for all of their current cameras that addresses predictable credentials vulnerability.

Firmware version 2.x.4.8 for HD cameras is available here.

The cameras supported in this firmware upgrade are as follows:

FI9821W V2
FI9821P
FI9826P
FI9826W
FI9831W
FI9805W
FI9805E
FI9804W
FI9828W

Firmware version 11.xx.2.59 for MJPEG cameras:

FI8910W
FI8916W
FI8918W
FI8903W
FI8904W
FI8905W
FI8906W
FI8919W
FI8907W
FI8909W

FI8904W

Carefully read included PDF before starting the update process.

We already installed it and will provide more details soon.

 

Update 05/20/2014: We were contacted by Ramparts and told that they have disclosed that vulnerability independently on 1/25/2014. The link that is supposed to substantiate the claim is broken and we could not verify the claim;)

However, they need to advertise their company and it doesn't hurt us to put the link, thus, per their demand – voilà, c'est tout!

The last update: Kashmir Hill turned this boring stuff into an entertaining story!

SlowHTTPTest 1.6 is out

Yesterday I released another version of SlowHTTPTest, that includes all the performance fixes that were sitting in the repository since last year, as well as:

   - CLI got funny colors and less scrolling for better perception
   - HTML reports look prettier
   - Help screen is finally readable

     

I tested it on OSX Mavericks, Ubuntu Precize Pangoline and latest Fedora. Things looks fine, but just in case, here are some useful tips:

- if configure complains about the version of automake that was used to generate it, running autoreconf  and following on screen instructions should fix most of the problems

- there is some chance that you'll need to install libssl-devel

- if you hate colors, edit them in slowlog.h or undef USE_COLOR in config.h

- if you don't like the new CLI layout, using other than default verbosity (-v 2 and up) level will turn on the old good logging-style output

 Hope this version doesn't add more trouble and any feedback is always welcome. Enjoy!

 

 

Funny OS/Browser fingerprinter

As of today, this page should crash any webkit-based application that uses CoreText font rendering framework on iOS or OSX 10.8.4

Using getmecamtool

To support the presentation about controlling IP cameras all over the world, we'll try to share some details on what the getmecamtool is doing and how to make it work.

getmecamtool is a tool-set to manipulate software of Foscam FI8910W, FI8908W, FI8909W and their clones.

It has the following components:

- packer/unpacker for system, WebUI and camera settings files (syspack, sysextract, uipack, uiextract, confpack, confextract)

- the main shell script that automates the flow with predefined commands (getmecamtool)

getmecamtool DOES NOT bypass authentication or get credentials for you. Instead, authentication credentials should be provided to the tool to successfully manipulate the camera software.

Check out the presentation to get the idea on how credentials can be potentially harvested.

Before building getmecamtool, there are couple of prerequisites:
 - genromfs is needed to manipulate romfs, which is used on the camera ($ sudo apt-get install genromfs)
- cmake is required to build the getmecamtool ($ sudo apt-get install cmake)
Once ready, get getmecamtool from github

$ git clone https://github.com/artemharutyunyan/getmecamtool

$ cd getmecamtool

$ mkdir build

$ cd build

$ cmake ..

$ make

But we are not done with the installation yet. getmecamtool requires to have a library of firmware files, normally distributed by the camera vendors. Due to legal issues, we are not hosting that software, but you can easily re-create the directory structure and download necessary files by yourself.

Create fwlib directory somewhere. In our examples, we assume it is next to getmecamtool directory cloned from github. The fwlib/ directory should contain unmodified dystem firmware and Web UI from camera vendor.

When run, getmecamtool will determine the current version of dystem firmware (or webUI depending on the operation) on the camera and will try to locate the corresponding file in fwlib directory. Typically,  camera vendors package both system firmware and webUI within the same .zip archive. fwlib should contain two subdirectories sys/ and web/, where corresponding original files should be placed.  For example a directory structure for a camera with webUI version 1.2.3.4 and system firmware version 5.6.7.8 should look like this:

fwlib

|-- sys

|   `-- lr_cmos_5_6_7_8.bin  

|-- web

|   ` -- 1.2.3.4.bin

 Here is an example of running the tool to inject a proxy server or anything else that can be cross-compiled using tools from the corresponding with board support package. We used board support package supplied for Winbond W90N745 board available here:

$ sudo env PATH=$PATH:$(pwd)/../build/bin ./getmecamtool -a X.X.X.X:80 -u admin -p '' -c inject_proxy -e /home/sergey/camtool/getmecamtool/misc/proxy/proxy -s ../../fwlib -o 81

which tells the tool to:

- connect to X.X.X.X:80

- authenticate with 'admin' username and empty password

- determine the version of system firmware running on the camera, get same version from fwlib, unpack it, embed proxy binary into it

- change the camera settings to make web server listen to port 81 (and proxy would listen on the old port, 80 in this case)    

- pack the system firmware file back, verify the integrity, push it on the camera and restart it

sudo is required by mount, which is used to mount the romfs that was extracted from the system firmware.

We chose to push a proxy on the camera, because it demonstrates how an attacker can utilize the forwarded port on NAT by making proxy server listen to it. If the client is aware that it's a proxy - it acts as a proxy, otherwise it acts as a reverse proxy by forwarding requests to local web server on a camera.

Another example runs the tool to host an arbitrary file on the camera, making it, for instance, a malware distributor:

$ sudo env PATH=$PATH:$(pwd)/../build/bin ./getmecamtool -a X.X.X.X:80 -u admin -p '' -c host_file -f /home/sergey/camtool/getmecamtool/misc/install_flash_player.exe -s ../../fwlib

tells the tool to:

- connect to X.X.X.X:80

- authenticate with 'admin' username and empty password

- determine the version of webUI firmware running on the camera, get same version from fwlib, unpack it, embed install_flash_player.exe  into it

- pack the webUI firmware file back, verify the integrity, push it on the camera and restart it

 Two other commands are inject_exec and poison_webui. First one would inject arbitrary executable, and the second one will add a user with admin role and patch the webUI to hide it, as well as it adds a line to one of HTML files to source a javascript from external location, demonstrating how easy is to have a persistant XSS in the victim's browser.

Go, IP cameras and DNS

While working on presentation about IP cameras, Artem crafted a handy shell script that searches for active IP cameras by going over camera vendor's DNS records. The result was some handy numbers, as well as information on how people are using camera vendor provided DDNS service.

Last week I was visting a friend (привет, Виктор!) in Seattle. Between beers, he mentioned Go - a programming environment he uses in one of his projects. He combined next pint with a Go programming lesson and as a result, we wrote a 100 line amazingly simple multi-threaded  scanner that does the same as above mentioned script, but in much more configurable and reliable way.

Get the Go, get the getmecamtool, and in the misc directory you will find the scanner.go file. Simply type:

$ go run scanner.go --help

and the rest should be clear. It currently searches for records with prefix xx1234(two letters and 4 digits), but it should be trivial to change the pattern that matches particular camera vendor's DNS records.

To Watch or Be Watched: Turning Your Surveillance Camera Against You

Last year I was lucky enough to attend the Hack In The Box security conference in Amsterdam. Dhillon and the rest of organizers put a great event and since then I was eager to return.

Subject line of this post is the title of the talk that we are going to present at #HITB2013AMS with my fresh colleague and old neighbor back in Armenia - Artem Harutyunyan.`

We'll try to get some attention on security flaws of widely available IP surveillance cameras that you can get at Home Depot for as low as $70. It's quite a challenge for us, because we never dealt with embedded devices before, although security issues in the embedded web server of the camera themselves are enough to do whatever you/bad guy/Chinese government want.

See you in Amsterdam. 

Follow The RFC!

About 40 minutes before our WebSocket presentation at BayThreat I decided to do the final dry run. The slide with stacktrace of crashed desktop Safari caught my attention and I re-checked if there is still a problem. While current OSX Safari was fixed and I removed the slide, I decided to navigate to that page using Safari on my iPhone running IOS6.

The result was quite surprising, since I thought Apple is using the same webkit engine for all platforms: Safari simply hanged, while minimizing and re-opening caused a crash. Chrome on IOS6 behaved in similar way, while Chrome on OSX was always handling that code properly. Trying it on friends' Galaxy something caused the entire UI of Android to behave funny.

For those who are curious what the code is doing: it does nothing but trying to open several thousand WebSocket connections to non-existing server.

RFC 6455 is quite clear on this:

"There MUST be no more than one connection in a CONNECTING state. If multiple connections to the same IP address are attempted simultaneously, the client MUST serialize them so that there is no more than one connection at a time running through the following steps."

Most likely, mobile versions of popular browsers are just not implementing this policy, causing to either drain the file descriptors pool, or random number generator, or the memory.

This isn't a big deal, I just decided to document this in my blog to see how long would it take to port the policy to the mobile versions. As of today, January 6, the problem still exists, and the web page with deadly javascript is right here .