IoT is everywhere right now and there are a lot of products out there. I have been looking at an IP Gateway lately and found some serious issues. The Busch-Welcome IP-Gateway from Busch-Jaeger is one of the devices that bridges the gap between sensors and actors in your smart home and the network/Internet. It enables the communication to a door control system that implements various smart home functions. The device itself is offering an HTTP service to configure it, which is protected by a username and password. Some folks even actually expose the device and its login to the Internet. I tried to configure one of these lately and stumbled upon some security issues that I would like to discuss in this blog post.
I started configuring the device via the HTTP interface and was running Burp (you always should! ;)) in the background. When looking at the requests and responses I realized that there was no real Session Cookie. Just a Cookie called “upnpMD5loginpass” which was not MD5 at all but rather plain text. The name of the Cookie says it all, it is basically the password of the user. So that means access controls are probably hard to manage with this kind of session management and I was curious if it is possible to just fire arbitrary requests in an unauthenticated manner without knowing a password. Turns out this works pretty well. The application does not check if you are authenticated and there is no secret token that an attacker needs to know to send arbitrary requests to the device.
With this in mind I kept digging a little deeper to identify interesting functionality that could be abused by an attacker. Changing administrative passwords, DNS or routing information is a nice option but is something you want on a Router instead of an IP Gateway. Full control of the device on OS level would be great but there is no built-in functionality for this. Why would an attacker not necessarily stop at gaining high privileges on the front-end? Because this device is a bridge to a bus that might give you full access to home automation features not available or protected in the UI. So just resetting the administrative password does not necessarily give you any advantages in terms of reaching the bus and talking to the devices directly. So I started looking for vulnerabilities in the UI that might get me OS access.
Turns out the UI lets you do the usual stuff, setting up devices on the bus, adjusting network configuration and basic configuration of the system. If you go for low hanging fruits you might want to think about how all these settings will be handled on operating system level. This is exactly what I did. For one setting the user supplied input was passed directly to a shell interpreter. The user supplied input was not sanitized and enabled me to gain an administrative shell on the device with full operating system access. This enabled me to use the device as a jump host from the network to the devices connected via the bus without authentication.
The disclosure with Busch-Jaeger went extremely smooth and they published an advisory today with the following CVEs: CVE-2017-7931, CVE-2017-7906. An Update is also referenced in the document above that you should apply ASAP. Additionally, do not expose devices like these to the Internet!
Cheers,
Florian