Thursday, May 8, 2014

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.

Screen Shot 2014-05-07 at 11.35.26 AM

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!

7 comments:

  1. I generally check this kind of article and I found your article which is related to my interest. Genuinely it is good and instructive information. Thankful to you for sharing an article like this.security cameras Naples fl

    ReplyDelete
  2. It is very informative blog I was looking for the somethings exactly like this as I am an essay writer and work for the Urgent essay writing service so i need some data and info which is I found in your article so therefore i want to thanks you for this is.

    ReplyDelete
  3. Hi, Thank you very much for the article which was exactly what I was looking for.I’m not an expert of Apache therefore I left more or less your configuration unchanged except for the host and ports. Further i just want to say this article has been very helpful. Although instead of setting up Apache, I found quite a neat alternative solution. I run a DD-WRT router at home, and I installed Optware and Pound on it. It is much easier to configure Pound than Apache, and I believe it has a lighter footprint than Apache. regards :-
    cheap assignment writing services

    ReplyDelete
  4. A dedicated cage and a dedicated high restrict slot group to elevate your experience each go to. Add ease to your gaming experience as we redefine what comfortably luxurious gaming really means. No matter how fortunate or expert the participant is, the operator has assured profit. It typically feels like some algorithm is at play, preventing a sure feature from happening too quickly after starting a slot recreation and only happening {once|as quickly as} you have lost sufficient money 까모벳 to cover the feature's payout.

    ReplyDelete
  5. Foscam uses a unique UDP protocol to update DNS records. This unique protocol makes it feasible for an attacker to rewrite any camera record in the Foscam DNS server since it utilises the camera subdomain best muscle growth supplements as both a username and password to confirm the legitimacy of the request. Neither on DynDNS nor the camera is there a way to modify the login or password in the current configuration.

    ReplyDelete
  6. Hello, I've read a lot of articles on internet but very few have posted such a nice articles. This blog is for appreciation. OOTW provides online creatine gummies usa for better muscle built with no side effects.

    ReplyDelete

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 Exploit...