Abstract.
This writeup is a basic introduction on how to setup a basic Man-in-the-Middle scenario for IOT as well as other mobile devices and common pitfalls that can occur during such an assessment. Furthermore, the discovery of a permanent Denial-of-Service vulnerability, due to an unencrypted firmware update process, will be described.
Intro.
Recently, I stumbled accross an IOT alarm system in a popular german supermarket. On the package some keywords caught my attention:
- Highest
- Security
- SmartHome
- Cloud
The first step was, to take a look at the so called Homematic IP Access Point (HAP). This device must be connected to the home router, to get internet access. All the other devices such as the alarm sirene, window-/ door-contacts, as well as motion detection sensors can be connected to the HAP by radio with a frequency band of 868,0-868,6 MHz or 869,4-869,65 MHz. The following picture shows the front view of the HAP.
The Setup.
Since it was important not to miss any (maybe unique) information during the first startup, I decided to prepare the capture setup first. Therefore, a MikroTik (MT) RouterBoard which allowed to configure port and protocol forwaring on my needs, was prepared.
For the DNS resolution the mod0Umleitung tool was chosen which was created by __ths__ and a Windows 10 Host as the Man-in-the-Middle notebook with Burp Suite Professional as HTTP/S proxy was setup.
According to the manual, a iOS or Android mobile phone with the according app was required for the inital setup of the HAP. My choice fel on the iOS mobile app available in the iOS App Store Homematic IP iOS app. Since the MT also supports a Wireless Network, the mobile phone was connected to this network.
This is a common setup, that I use a lot during my business hours.
The HAP was connected with a ethernet cable with the MT, the DNS server and the proxy were started. On the MT the firewall rules were applied to forward all requests on port 80 and 443 to my proxy (Burp Suite) which was running on port 8080, all requests on port 53 (DNS) were also forwarded to the notebook on port 53 (mod0Umleitung). The following scheme shows the setup at this point.
First problem.
Now the time was come to turn on the HAP, according to the manual, the LED on the HAP should turn constantly blue when the device is connected to the internet. Guess what?
It did not… it kept flashing blue
No HTTP/S requests showed up in my proxy, nor a error message, stating a failed SSL/TLS connection, was raised. The mod0Umleitung showed that the HAP actually performed DNS requests.
So Wireshark was used to analyze the incoming and outgoing network traffic to/from the notebook. The capture showed a DNS query on two hosts:
- lookup.hmip-oem0840.com
- lookup2.hmip-oem0840.com
Both DNS queries were resolved to 81.14.202.198, then four ping (ICMP packet) requests were sent to each of the resolved hostnames.
Since the notebook was between the HAP and the hosts on the internet, the ping requests were not answered. All I had to do at this point was to answer the ping requests. Therefore, an additional firewall rule on the MT was created, to forward all ICMP packets to the notebook. Fortunately, the notebook answered on all ping requests.
The LED was now constantly blue.
Note: Ping requests are not a sufficient way to determine if a specific host can be reached. As this example shows the requests can be answered by another host, and the sender will not be able to distinguish between a legal and a fake ping response.
Firmware update?
As everybody knows the most important thing for a high security product is, to keep the firmware up to date. So the HAP was asking for the latest available firmware version. This was done with a HTTP request, on the following host:http://fwupdate.homematic.com
The mindful reader maybe realised that the firmware update process seems to be performed via an unsafe non-encrypted HTTP connection. This means that a Man-in-the-Middle can read and manipulate the data that is transfered. The HAP seemed to had the latest firmware installed, since no further action was performed after the initial request. That was a unfortunate situation. I wanted to get my hands on the firmware… So what if it was possible to manipulate the server response, to trick the HAP into requesting the new firmware. An easy way to achieve this was to apply a Match and Replace rule in the Burp Suite proxy.
The following rule was applied:
Firmware update!
The HAP fell for the trick, and it performed a HTTP request on a new URL to grab the fake (non-existing) firmware file:
- /download?sgtin=xxx&coprocessor=3.4.16&hap_firmware_pack=1.2.26
The next step was to replace the wrong URL parameters with the right ones, this allowed me to download the following firmware blobs:
- coprocessor
- application_update
- local_bootloader_update
- web_bootloader_update
The binaries were HEX encoded, as can be seen on the following screenshot. Until the time of writing I had no time to look into the actual content of the files, but this will be a future task.
Denial-of-Service D:
Unfortunately, the request on a non-existing firmware file turned the HAP into a non-responsive mode. A Denial-of-Service (DoS) was the result of the failed firmware process…
Lessons learned.
- Ping requests are not a good idea if you want to look up a specific host
- Intercept and Drop HTTP requests on not existing firmware
Next steps to take.
- Analyse the firmware binaries
- Try to fix the broken HAP with this information
- Analyse the HAP hardware
- Analyse the radio protocol