This blog post has been created for completing the requirements of the SecurityTube Offensive Internet of Things course.

http://www.securitytube-training.com/online-courses/offensive-internet-of-things- exploitation/index.html

Student ID: IoTE-728

 

In my previous post, I examined the firmware of a mydlink web camera with the binwalk tool. In this post I continue the examination of the IoT device with dynamic analysis.

I configured the device and ran an SYN scan with nmap tool to detect the open TCP ports. Open TCP ports are important, since we can access to the device via these ports. The services, which are accessible via these open ports, might have vulnerability, that an attacker could exploit.

camera01

Nmap showed, that the 80, 443 and 8039 ports were open. Most of the IoT devices can be configured via web interface and run a simple web server on TCP port 80 and/or 443. Web applications have lots of well-known vulnerabilities which are low hanging fruit for the bad guys. We can check the existence of those vulnerabilities. Besides the web related vulnerabilities, the publicly accessible services might be vulnerable to buffer overflow attack, which is another attack vector.

 

Since the 443 port was open, I ran the testssl tool first. This tool checks several SSL/TLS related vulnerabilities. The tool identified one (Secure renegotiation).

camera02

When I extracted the firmware with binwalk, I found a file called servercert.pem. I checked the certificate of the HTTPS, but it was different. It seems that a new self signed certificate is generated during device setup.

 

Then I tried to open the web page. I managed to open the page in Internet Explorer successfully, however I received an error message when I tried the same in Firefox.

camera03

It turned out that there was a bug in the latest firmware. I solved this problem by using a User Agent Switcher Firefox plugin. I set the User Agent to Internet Explorer 8 and the admin page of the device opened. The page required username and password. I configured Burp Suite and checked the request-response pairs.

camera04

The device uses Basic authentication over HTTP! The username:password string is base64 encoded and included in the HTTP request as a header. An attacker can sniff the network traffic, base64 decode the value in the authorization HTTP header and steal the username:password. Actually it is not even necessary to reverse the password. The attacker can simply include the captured authorization HTTP header into every request he or she sends.

For example the /image/jpeg.cgi captures an image and sends it via HTTP. If an attacker sniffs the traffic and captures the authentication header, he or she can craft a request to see the image of the camera. It is also possible to change the admin password of the device, or even update the firmware with a crafted request!

camera05

I also tried to see the image without the authentication header, but it did not work.

camera06

 

In order to capture the authentication header, the user should access to the device while the attacker sniffs the network traffic. If this is not feasible, the attacker could brute force the username:password.

I used hydra to brute-force the password.. My password was very simple and hydra find it quickly. A complex password could slow down the attacker, however it could not prevent the attack.

camera07

 

Another possible attack might be when the attacker sniffs the network while the user sees an image. The image file can be recovered from the TCP dump with the Wireshark tool. This is the TCP flow of the image download.

camera08

In Wireshark I selected File/Export Objects/HTTP.

camera09

Then I saved the image. Its name was jpeg.cgi, however this was the image of my room, created by the device. The image was extracted from the network traffic!

camera10

 

I examined the page where the user can change the admin password. I found that the admin password can be found in the page in encoded form. The form checks if the user entered a valid password.

camera21

camera22

Although the client side validation can reduce unnecessary network traffic and sometimes a good idea, the validation should always occur on the server side. The client side can be manipulated and can never be trusted. Besides that checking the admin password makes it necessary to download the password in some form. Even if it is encoded or hashed, an attacker could try to reverse it. Since the device uses Basic authentication, it is easier getting the password from the authentication header.