IoT Adventures: The LeFun WiFi Camera

Esteban Rodriguez, Consultant, Coalfire Labs, Coalfire

Recently I happened to be in the market for a baby monitor, so I decided to search Amazon for an affordable device that would fit my needs. A search for “baby monitor” within the “electronics” department brought me to the LeFun WiFi Camera. For $39.99 (at the time of my purchase), this seemed like it could be a good deal.  Knowing the reputation of Internet of Things (IoT) devices, I was curious about its security. This was addressed in the product description with the guarantee that when I connect to any device, it will be via a “secure and safe network” and will be secured with “financial-level encryption.” It also boasts that they are “CE, FCC, and RoHS certified,” which is good, despite those certifications only dealing with safety and not information security.

click to enlarge image

I decided to purchase it and see for myself if their security assurances were actually true. To connect to the camera, the first thing I did was download an app. Because I use MacOS at home, I downloaded the MacOS app from the website as instructed in the manual. When connecting, a security app installed on my computer warned me that the application did not have a code signature. This was the first sign of the trouble to come, as code signatures are an important security mechanism to ensure software has not been modified maliciously.

When I ran the desktop app, it appeared to be nothing more than a web browser that was pre-configured to only go to a cloud camera login page. Aside from being just a framed webpage, it also cropped out the top part of the page, making it difficult to use. 

Before using the app, I made sure that all my web traffic would be proxied though Burp Suite so I could understand how the app was communicating. What I found was a bit unsettling.

All traffic was via the HTTP protocol. All the data transferred via the app was completely unencrypted in transit. If a user of this app were to view their camera, anyone passively monitoring the communication channel could see everything the user of the app was seeing. The app was a bit clunky to use, so I instead connected directly to the endpoint with my browser so that I could better navigate it. When viewing the camera, the user has the option of using Flash player or plain HTML. I decided to go with HTML to start. Each time the browser would request a screen update the server would respond with a .jpg image of what was currently in view. 

click to enlarge image

To validate that anyone monitoring the channel could effectively view what was on the screen, I parsed out the .jpg image from the application response in Burp Suite with a hex editor.

After doing so and saving the file as a .jpg, I was able to see a snapshot of what was being viewed.

After analyzing the HTML viewer, I decided to enable the Flash viewer. When viewing the traffic in Burp Suite, I found that the Flash application was using the Real-Time Messaging Protocol (RTMP). This provided a better user experience as the video was smoother, but still suffered from security issues. If someone were to sniff out the URI for the stream, they could then connect to it unauthenticated. 

click to enlarge image

The only thing preventing others from viewing this stream is the secrecy of the URI. Once sniffed however, an attacker would no longer have to actively monitor the session and could receive the video stream from the server directly unencrypted and unauthenticated.

The MIPC application was also available for iPhone, so I decided to test it out as well. After downloading the MIPC app from the App Store, I found it to have an interface very similar to the desktop/web app. 

Much to my satisfaction, I found that the iPhone application connected to a different endpoint, and this time it used HTTPS! This seemed all well and good until I realized I was capturing traffic in Burp Suite, but I had never installed the Burp Suite root certificate into my iPhone. Even though I was using HTTPS, the application was not doing anything to ensure that the certificate presented by the endpoint was valid. What this means is that any attacker with the position to intercept and modify the traffic could serve a fake certificate to the client and Man-In-The-Middle (MITM) the connection. This would allow an attacker to inspect the traffic, and the user would have no indication that their communication with the server was being intercepted. 

Disappointed by both the MacOS and iPhone app, I turned to the MIPC website itself. This proved to be the only relatively safe choice to view the feed and control the camera, as the website was being served over HTTPS, and any properly configured browser will warn the user when presented with a non-trusted certificate. While almost a secure alternative, I found that the website was still supporting the SSLv3 and SSLv2 protocols. If the client were to fall victim to a MITM attack, this would leave them vulnerable to both the POODLE and DROWN attacks.

click to enlarge image

With the encryption questions answered, there was still one more issue to address, and that was “how and where is my data stored?” All the data from the camera is streamed up to a server in the cloud.  While this makes sense for usability, it also brings about additional concerns. There really is no way of knowing who controls your data and what they might do with it. This is one of the risks that comes with storing your data on a system that you do not have direct control over. 

While the camera functioned well, the lack of reliable encryption and the uncertainly of how the data was stored in the cloud was a deal breaker for something that was going to be recording within my home. With the increased reliance on cloud-based solutions, the risk of data loss increases as well and should always be considered before purchasing a cloud-enabled device. Attempts were made to contact the manufacturer of the device, however no response was received. The failings of the LeFun device could have easily been prevented had they gone through an application security assessment. From now on I will be continuing to test any IoT device that I buy, and will be writing about here in what will hopefully be an ongoing IoT series of blog posts. 

Esteban Rodriguez


Esteban Rodriguez — Consultant, Coalfire Labs, Coalfire