Burglar and Hacker – When Physical Security Is Compromised by IoT

Introduction

The Internet of Things (IoT) is taking shape as the next mega trend. Equipment is becoming more digital and connected, forming networks of machines and new ecosystems. According to Gartner, 20.8 billion IoT devices will be connected worldwide by 2020. Those devices will be used almost anywhere, anytime – at home, in the car and as wearables. As the market grows, so do the cyber threats. Each of these connected devices is vulnerable to attacks that might cause damage and breach of privacy. Many studies show that security and privacy are the number one concern of consumers adopting IoT devices into their daily lives.

Dojo’s discovery of multiple flaws in iSmartAlarm is another example of a poorly engineered device that offers attackers an easy target. Once an attacker infiltrates the home/business network and find such a device, they could fully compromise the device. It is needless to list the potential damages of a compromised physical security system such as alarm system.This paper details the vulnerabilities inside the iSmartAlarm and their impact.

Overview

iSmartAlarm has multiple vulnerabilities that can lead to full device compromise. An unauthenticated attacker can persistently compromise the iSmartAlarm by employing a number of different methods leading to full loss of functionality, integrity and reliability, depending on the actions taken by the attacker. For example, an attacker can gain access to the entire iSmartAlarm customer base, its users’ private data, its users’ home address, alarm disarming and “welcome to my home sign”. This blog will explain how to hack iSmartAlarm and how to use its ecosystem in order to gain full ownership of a compromised device.

Summary of related CVEs:

Preface

As a security researcher, I really wanted to test internet connected alarm systems and see what I could get out of it. In my research, I came across a company named iSmartAlarm that received a lot of reviews and quite large market share. https://www.ismartalarm.com/why-ismartalarm#awards_and_reviews

iSmartAlarm is one of the leading IoT manufactures in the domain of smart alarm systems. It provides a fully integrated alarm system with siren, smart cameras and locks. It functions like any alarm system, but with the benefits of a connected device: alerts pop up on your phone, offering you full remote control via mobile app wherever you are. Perfect candidate for a research!

After setting up my lab, the bits started to flow and I was able to find a first vulnerability.

• iSmartAlarm cube SSL Certificate Validation Vulnerability (CVE-2017-7726)​

When first turned on, iSmartAlarm cube communicates with iSmartAlarm backend on tcp port 8443. However, the cube does not validate the authenticity of the SSL certificate presented by the server during the initial SSL handshake. So after forging a self-signed certificate, I was able to see and control the traffic to and from the backend.

SSRF vulnerability (CVE-2017-7727)

One of iSmartAlarm’s API contained a redirection, which lead me to try and exploit it.

Quite surprisingly, it worked! An auspicious start for new research, but I wanted something juicier: I wanted to control anyone’s alarm system. While examining the iSmartAlarm’s API, I was able to fetch an encryption key.

I wanted to see how the app and the cube communicate, and figure out if I could gain control over the alarm system remotely without the app. The iSmartAlarm app works in two modes. One option is when the cube and the app are on the same local network. The other mode is when they are on different networks. While examining the first mode, I was able to sniff the encrypted traffic between the cube and the app on tcp port 12345.

Denial of service vulnerability (CVE-2017-7730)

Because the cube and the app communicate directly over the LAN, I was able to stop the cube from running.

While running a DoS attack on the cube, the legitimate user loses control over the alarm system, and he or she is not capable of operating it neither remotely nor locally. Reversing the protocol took some time and it is out of the scope of this paper, but eventually the protocol between the cube and the app looks like this: First the app and the cube authenticate by using sophisticated 4 way handshake, which looks like this:

App: ISAT\x01\x00*3\x01\x00*7

Cube: ISAT\x02\x00*3\x01\x00*3\x10\x00*3 + “Cube generated Secret Key”

Encryption algorithm: With the “Secret key” and the IPU (encryption key) the app decrypts a new key. (Remember the IPU from before ;) ) iSmartAlarm uses an XXTEA encryption algorithm (although their implementation is broken). After that, the algorithm takes the output of the XXTEA enc, and then reverses the output with the “new key”!! So now, we have the encryption key, and we can do whatever we want with the alarm.The encryption key creation looks like this:

reverse(xxtea_encrypt(reversed("secret_key"), reversed("IPU_key"))).

The result of this manipulation is a brand-new key used to signed commands to iSmartAlarm’s cube.The app sends command as follows to proceed with the authentication:

App: ISAT\x03\x00*3\x01\x00*3\x10\x00*3 + “new key”

Cube: ISAT\x04\x00*3\x01\x00*3\x01\x00*3\x01

This leads to second and third vulnerability on the iSmartAlarm Cube;

• Incorrect Access Control and Authentication Bypass (CVE-2017-7728,CVE-2017-7729)

With the newly created key, we can now send whatever command we want to the cube – disarm, arm or panic.

DISARM ISATP\x00*3\x01\x00*3\x03\x00*3\x01\x002

ARM ISATP\x00*3\x01\x00*3\x03\x00*3\x01\x000

PANIC ISATP\x00*3\x01\x00*3\x03\x00*3\x01\x003

So now that I have an attack vector of a fully working exploitation method, how do I get all these iSmartAlarm’s cube out there?

I decided to research the app in depth, hoping I might come up with something. Lucky me, I found this:

Looks like it is a login to some sort of an internal iSmartAlarm website. That was quite disturbing so I tried it and…

I was in!. Can you find my ticket there :)?

Now all you need is an imagination. What would a black hat burglar be able to do with such exploits? He can gain full control of any iSmartAlarm cube and also retrieve all of their customers’ private data, including their home address – creating a perfect scenario for cyber assisted crime.

Disclosure Timeline

Jan 30, 2017: Initial contact to vendor

Feb 1, 2017: Vendor replied, requesting details

Feb 2, 2017: Disclosure to vendor

Apr 12, 2017: After vendor didn’t replied, I’ve approached CERT

Apr 13, 2017: Confirmed receipt by CERT and assignment of CVE Identifiers

July 05, 2017: Public disclosure

Ilia Shnaidman

Tweet Share