We’re now seeing even traditional “security” products such as burglar alarms feature Internet of Things type functionality and, as similar vulnerabilities in these types of products could have serious consequences, we thought we’d take a look.
The first product we looked at was a Yale smart burglar alarm system which, at the time of purchase, was available through major high street retailers for around £600 and is designed to be installed by the end user. The smart burglar alarm system allows activation and monitoring of the alarm and cameras via a smart phone over the Internet. It also has the option to add smoke detectors to the system. Crucially, it’s a secondary security system, in that it monitors but doesn't control access.
The concept of an easy fit smart alarm system is very appealing as it provides the ability to remotely monitor your home security whilst at work or on holiday. However, from a security standpoint, this feature could open up new attack vectors against a product that owners expect to work when it matters most. With this in mind, we decided to see how secure the product was.
The first thing that we did was to unpack all the items and set them up, although we did disable the external alarm to avoid deafening ourselves! Having set up the device, we started capturing traffic between the mobile application and the control box. This gave us a high level understanding of the systems components and their interactions, as shown in the following diagram:
The design of the system immediately highlights a number of areas that could be of particular interest:
- The main control box, which communicates wirelessly with the cameras and sensors in the home, as well as being connected to the Internet in order to provide remote activation and monitoring via the corresponding Yale smartphone application
- The Zigbee protocol and 868MHz ISM band communications to the peripheral devices
- The communication between the control box and the app running on the mobile phone
The next step was to capture and analyse the communications taking place. This revealed that the communications with the mobile app were transmitted to a Yale server and used XMPP (XMPP is a simple message protocol based on XML). It’s worth highlighting that the XMPP communications between the control box and the Yale server are unencrypted. Some examples of the XMPP traffic can be found below.
The XMPP commands are sent to and from the control box. They provide status updates and allow for operations such as arming and disarming the alarm. This traffic is interesting as it uses basic authentication (clear text password) and all the requests can be viewed.
This indicated that the control box was a good candidate for closer inspection. Our next step was a port scan of the central unit, which revealed an internal web user interface running on port 80. On trying to access the page a username and password prompt was displayed:
If incorrect credentials are submitted an unauthorised page is displayed. Even from this initial page it is clear this is not a polished UI for home use and appears to be more for diagnostics and maintenance. There’s no mention of it in the manual, so why is it running? The page titles also give a clue to the likely functionality.
After manually entering some common passwords with no success we needed to find a way to get hold of the credentials. We considered brute force, but were keen to get to know the box a little better so we decided to take a more hands on approach.
The next step in trying to get the default credentials was to take a look inside the control box. We identified a 10-pin ARM JTAG header on the bottom left of the control panel. A quick continuity check confirms that the pins on the header are connected to the JTAG pins on the System on Chip (SoC), a Cortex-M4 based Freescale chip. Our hope was that the firmware could be extracted via JTAG so that we could search for the password in the firmware image. The datasheet for the SoC says that it supported read-protection on the JTAG interface.
However, no such protection existed, and the firmware was easily extracted. At this point we were about to embark on another IDA Pro adventure, but before getting too deeply involved we ran ‘strings’ just to see if there was anything interesting. One string in particular stood out - surely this wasn’t the password for the web interface? Yes the interface we didn’t even try to brute-force against had a password that could be found by simply running strings over the firmware.
Now we had access to the web UI we started playing around with the various options. The device management page had lots of interesting buttons to press and, given we had disabled the large siren, one of our number decided it was safe to press the “test siren” button…
… we soon learnt that the control panel also had an internal buzzer that could be very loud in a small space. This was quickly disabled for future tests!
The page that was of particular interest was the panel control page which has options for arming and disarming the alarm. These were tested and they do indeed activate and deactivate the alarm system. The traffic for these commands was analysed in Wireshark and the specific packets quickly identified.
We wrote a short python script to login to the web server using the admin credentials and submit the disarm request. This allows for the alarm to be deactivated by simply locating the control box, unplugging the Ethernet cable and directly connecting the laptop running the python script. It is worth noting that when a sensor detects movement and the control box is armed there is a 30 second default time period to allow the user to disarm the system. Once the control box is located it can be disarmed in seconds without any alerts being reported back to the corresponding phone app.
Our initial assumption that choosing an IoT security product from an established vendor would potentially provide a difficult target was proven to be false. After just a couple of days of analysis we were able to show that within a few seconds of physical access to the control box, the alarm can be disabled trivially.
In summary the key issues identified were:
- Running the web server on the hub with a fixed username and password
- Not enabling the JTAG read protection on the System on Chip
- Not encrypting the XMPP traffic from the hub to the Yale servers
Disclosure and comment from Yale
We first reported our findings to Yale in February 2015, and have been in discussion with them since then. We would like to thank them for their positive response to our findings.
Yale released an update to their firmware in July 2015, and also provided us with the following comment:
"We would like to thank Context IS for the responsible way in which they have carried out their testing and for giving us the opportunity to discuss it in confidence.
We would certainly agree with Context’s point that the “internet of things” and connected systems present new challenges, especially in the home market where consumers are not always aware of the potential risks.
Our policy is neither to confirm nor deny any reports about the security of Yale products, as any comment could inadvertently disclose information which might aid criminal activity.
As one of the most trusted brands in home security, Yale takes product security very seriously and we have a robust, continuous testing and upgrade process."
More details on Context's responsible disclosure policy can be found here.
Contact and Follow-Up
Neil leads the Research team and is based in Context's Cheltenham office. See the Contact page for how to get in touch.