Attacking a NF&A2P certified alarm system

Introduction

We had seen many and many papers about attacking alarm systems. Most of the targets had been cheap, insecure and easily breakable.

At the beginning of this year (2019), we decided to look at something more robust. Thus, we purchased a better and quite expensive alarm, granted with a certification from the French standard, level 2 (NF&A2P**).

The NF&A2P certification (Norme Française Alarme Prévention Protection, sometimes spelled NF A2P or NFA2P) designates a French standard that assesses the level of efficiency and resistance of alarm systems. The two stars indicate one of the most secure level against burglars (NF&A2P Referential).

But how does it stand against digital attacks?

The alarm system

Our test setup was based on the basic equipment of the alarm system:

• Siren/central system;
• Keypad/badge reader;
• Door/window contact sensors;
• Motion sensors;
• Remote control;
• Internet-connected box.

Attacking the Internet controlled box

After setting up the alarm, we decided to attack the most exposed component : the Internet connected box.

This equipment costs about 250€. Inside, there is a single STM32F207 ARM processor, a RJ45 connector and a basic RF transceiver. It is used to remotely arm and disarm the alarm, using an iOS/Android application.

During our testing, we analyzed the network communications of the box and discovered a proprietary protocol.

The box connected to a remote server (located outside of France), using the TCP port 6000. No SSL/TLS was involved, but, somehow, the communications seemed to be encrypted.

TL;DR : they rolled their own crypto.

After powering on the box, we could observe that:

• The client sent an 11 bytes (random ?) packet after connecting (HELLO packet);
• No block cipher seemed to be used, because packets size varies and are not aligned to any particular even block size.

After a few hours of research, we found that XOR-based encryption was being used.

We came up with the following Python code:

def keystream(clientid):
    index = 0
    while True:
        if (index % 10) < 5:
            j = index % 10
        else:
            j = (index % 10)+1

        index += 1

        yield clientid[5] ^ clientid[j % len(clientid)]


def alarm_xor(clientid, encdata):
    return ''.join(chr(c ^ k) for c, k in zip(encdata, keystream(clientid)))

The encryption mechanism was generating a keystream based on the 6th byte of the client HELLO packet XORed with the rest (bytes 1 to 5 and 7 to 11) of the HELLO packet.

Then, another XOR was performed between the data and the keystream (we purposely omitted some parts of the cryptographic algorithm).

After discovering the algorithm, we set up a MITM attack and decrypted every network packet of the alarm:

<0,SUCCESS>
<0,OpenSession>(1234)
<1,GetDeviceInfos>
<2,GetBlock>([REDACTED])
<1,SUCCESS>
<3,SendCommand>(#201##)
<4,SendCommand>(#23##)

The OpenSession part of the communication contains the alarm PIN code, which can be used to disarm the alarm (1234).

We also successfully injected packets into the TCP stream, that remotely disabled the alarm.

Attacking the firmware update mechanism

The connected box also enables the user to update the firmware of all other alarm components.

Using the mobile application, we requested an update on one of our components.

Like the remote control protocol of the box, the server performed a TCP connection towards a server located abroad (outside of France).

After analyzing the packets, we discovered a lot of similar packets, with repetitive patterns.

This time, no fancy cryptography was involved. We used a known (guessed!)-plaintext attack, and managed to recover the encryption key used.

Once decrypted (XOR), we discovered that the remote server was sending a HEX (Intel) file that looked like this:

:10184000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFA8
:10185000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF98
:10186000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF88
:10187000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF78
:107000000000000000000000000000000000000080
:107010000000000000000000000000000000000070
:107020000000000000000000000000000000000060

Using the technique, an attacker may be able to gain access to the firmware, without having to perform any hardware attack.

We did not attempt to alter the update as it could have bricked our device. Anyway, the updates could be signed (16 bytes were not decrypted at the beginning of the conversation).

Attacking the badges

We decided to take a look at the badges which are used to lock/unlock the alarm system.

Using the Proxmark RDV 3 tool, we quickly identified the technology used by the badges:

proxmark3> lf search
NOTE: some demods output possible binary
  if it finds something that looks like a tag          
False Positives ARE possible


Checking for known tags:

EM410x pattern found:           

EM TAG ID      : 0419C.....          

Possible de-scramble patterns          
Unique TAG ID  : 2098......          

[SNIP]

Valid EM410x ID Found!          

EM410x cards can be easily cloned or simulated. They clearly do not provide any security.

Using the Proxmark3, we managed to simulate an alarm badge:

proxmark3> lf em 410xsim 0419c.....
Starting simulating UID 0419C.....  clock: 64          
Press pm3-button to abort simulation          
Sending [4096 bytes]          
........
Starting to simulate

After some research, we found that only the last 24 bits of the badge were checked.

However, brute-forcing attacks are not possible, as the alarms locks itself after the submission of a few unauthorized badge IDs.

Attacking the remote control and the RF protocol

Radio Analysis

We started analyzing the RF protocol using a HackRF and quickly discovered which frequency ranges were used by the alarm system : 434 and 868 Mhz (they are also indicated in the alarm documentation).

We first played with Inspectrum, to determine which kind of modulation were used, and the bitrate.

In the previous picture, we can clearly see that ASK/OOK is used (On/Off patterns).

Then, the Universal Radio Hacker tool helped us to decode the radio signals:

We analyzed several lock/unlock packets coming from the remote.

However, even if we found some similarities between the packets, we did not manage to discover how the packets are encoded.

Based on several tests, we discovered that:

• Rolling codes are likely to be used;
• No challenge response or synchronization between the remote / central are used;
• Replay attacks are possible (but due to rolling codes, limited);
• No brute-force protection is implemented;
• Entropy is very low.

Packet prediction

Using statistical analysis (after intercepting a few samples), we managed to predict future packets that allowed us to unlock of the alarm.

First, we found that the last 4 bytes of the packets had some strange behavior. If we calculate the XOR value of the 4 last bytes, we can obtain the same result every two packets.

(First packet) last[0] ^ last[1] ^ last[2] ^ last[3] = 0
(Second packet) last[0] ^ last[1] ^ last[2] ^ last[3] = 203
(Third packet) last[0] ^ last[1] ^ last[2] ^ last[3] = 0
(Fourth packet) last[0] ^ last[1] ^ last[2] ^ last[3] = 203

Based on this behavior, and because of the very low entropy, we managed to find all the possible combinations that match this condition.

After a few tests, we managed to unlock the alarm, using a predicted packet.

For confidentiality and security reasons, we will not release the exploit script.

After trying to break the encryption of radio packets, we gave up and started the hardware analysis of the remote control.

Hardware attacks

We decided to open the remote in order to analyze its hardware components.

A single PIC16 chip is used, a very low power (nanowatt) micro-controller with many I/O pins.

Five debug ports are available on the board, which can be accessed without opening the case.

In the first picture, you can see five holes above the batteries : we mapped each one on the micro-controller PINs and discovered their use : MCLR, VDD, VSS, PGD and PGC.

These debug ports can be used to flash the micro-controller and, unless it was locked by the manufacturer, read the flash content.

We used a PICkit3 to connect to the board and see if we can dump the firmware, and (surprise!) the Code and Data section were not protected.

Using the MPLAB Integrated Programming Environment (IPE), we easily dumped the entire program memory and ROM content.

Analyzing the firmware

A lot of debugging and programming ports were exposed on the board, as you can see in this picture:

As these ports were not properly secure (code and data locked), dumping the firmware was quite an easy task. We just needed to map the debug ports to the correct pins of the micro-controllers.

Thanks to IDA Pro, reading the firmware file was easy. MPLAB IPE outputs a HEX (Intel) file, and IDA Pro has support for the PIC16 architecture.

The disassembled code is quite hard to read: even if the micro-controller program is small, they are a lot of instructions to make sense of.

We have not managed to break the encryption algorithm yet, but we suspect that XOR encryption is used.

We compared two different remote controllers, and found only a few differences in the EEPROM section. Meaning that creating a « Spoofed/Golden Badge » may be possible.

To Do

We have still a lot of work to do: reversing the encryption protocol could be time consuming.

Also, more kinds of attacks must be attempted :

• spoofing alarm equipment;
• checking for backdoor commands or buffer overflows;
• taking over the equipment using a fake firmware update;
• analyzing firmware of other components;
• bypassing physical security measures.

Conclusion

Having a NF&A2P** alarm system does not mean that it is secure against electronic attacks. The NF&A2P evaluation rather concerns the resistance against tampering, destruction or jamming.

Based on the vulnerabilities we discovered, attackers may be able to remotely disarm the alarm, clone badges or remotely intercept the PIN code.

Fixing these vulnerabilities would require a substantial software update, but also a new hardware design as some of them cannot be patched by software.

Below are a few, non exhaustive mitigation that may be taken:

• Removing any home-made cryptography and replacing it with trusted, peer-reviewed encryption algorithms, with mutual authentication between devices;
• On the chip level, (hardware) lock read access to the firmware after flashing the component;
• Using RFID tags that provide communication encryption and shared-key authentication (like Mifare DESFIRE).

Credits

• Nicolas Chatelain <n.chatelain -at- sysdream.com>

Thanks

• Jean-Christophe Baptiste, the head of R&D, for reviewing this writeup and allowing this research.
• Jean-Baptiste Parmentier, for solving the cryptographic algorithm used by the Internet control box.
• Mickael Karatekin, for his help on reversing the update protocol.