Defeating bad security in RFID access cards

Introduction

RFID access cards have become the norm in many applications such as public transport, customer loyalty programs, public events, and many more. Sadly, while manufacturers strive to provide more and more secure solutions to the variety of potential use-cases for these cards, many vendors and third-party integrators fail to properly implement secure systems due to either a lack of understanding of the underlying technologies, simple negligence, or more commonly, a combination of both that results in the assumption that nobody would dare to look under the hood.

Well...let's do just that.

Context

"Les Grandes Fêtes Telus" is an annual music festival in Rimouski (Canada) that brings together tens of thousands of visitors. In order to prevent sharing of access passes, the organizers implemented an RFID solution where visitors have to register their passes online before the event and provide personal information that allows the staff at the gate to recognize them, such as hair/eye color, birth date, etc. 

One evening, my girlfriends and I had to wait for over an hour in order to get into the site. While the gate traffic stalled into a halt, we wer able to witness the gate staff struggle with their iPads to identify attendees. In the following days, and due to major disgruntlement from the attendees, the local news, fed by the event's PR staff, described these issues as being limited to people who didn't buy a pass. Knowing a PR circus when I see one and since we both owned a pass, I knew that digging into their RFID access-control passes would yield a shitshow...

And thus began my journey into reverse-engineering one of the worse card systems I have ever seen.

I have tried to reach the organizers multiple times to inform them of these findings. to no avail. In the spirit of responsible disclosure, I have waited until the event was over to give them about a year to fix their flaws.

Summary

The security flaws found are mostly related to poor technological choices, negligent implementation, and overall lack of good security practices.

• Obsolete card technology known to be insecure since 2011 (MIFARE Ultralight)
• Unencrypted data memory
• Vulnerable to long-range signal interception
• Often used because of its lower cost compared to secure alternatives
• Unsecured access codes
• Lack of protection against card cloning
• Negligent use of the MIFARE Ultralight technology
• Identification data placed in read/write memory
• The entire access-control process relies on data placed in read/write memory

Impact

The impacst of the flaws include, but are not limited to:

- Blocking access to the event for legitimate pass owners

- Unacceptable delays at the gate resulting from staff having to deal with bad software

- Long-range interception of the card's radio signal

- Card cloning

- Remote access-code mass-harvesting

- Illegitimate activation by cloning

- Personal information leaks through the activation process

Tools

The tools used to attack these flaws are extremely low-cost and are available to the general public:

• NFC reader/writer. We used a 40$ PN532 circuit easily found online. I chose this one because it is extremely simple to add a radio amplifier to it to test collecting card data from a distance.
• Open-source NFC library LibNFC 
• Any MCU/computer with a 3.3V supply and one of UART, I2C or SPI interfaces. I used a Raspberry Pi 2

My simple test-bench

Accessing the fun stuff

The MIFARE Ultralight technology allows reading and writing data from/to a card using a dedicated reader/writer circuit. While some technologies such as the MIFARE DESFire series take into consideration the safety of the data stored by encrypting it, the Ultralight series does not.  The data is stored according to the following schema, provided in the datasheets on the manufacturer's website:

It is trivial to dump memory using LibNFC's tools. We'll dump data from our pass in a file called gft.mfd:

pi@omnibuslab $ nfc-mfultralight r -O gft.mfd

NFC device: pn532_uart:/dev/ttyAMA0 opened

Found MIFARE Ultralight card with UID: 04ac3c6ac03480 

Reading 16 pages |................|

Done, 16 of 16 pages read. 

Writing data to file: -O ... Done.

We can then examine the card's memory by looking into our file:

pi@omnibuslab $ hexdump -C gft.mfd

00000000 04 ac 3c 1c 6a c0 34 80 1e 48 00 00 e1 10 12 00 |..<.j.4..H......|

00000010 01 03 a0 10 44 03 0d d1 01 09 54 02 65 6e 57 43 |....D.....T.enWC| 

00000020 45 37 54 44 fe 00 00 00 00 00 00 00 00 00 00 00 |E7TD............| 

00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|

Cross-referencing from the manufacturer's datasheet, we can readily find :

Serial number : 04 ac 3c 1c 6a c0 34 80

Checksum : 1e 48 

Lock-bytes (used to limit re-writing) : 00 00 (Remember this!!)

OTP (one-time programmable data) : e1 10 12 00 

User-readable/writable data : 01 03 a0 10 44 03 0d d1 01 09 54 02 65 6e 57 43 45 37 54 44 fe 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Some things stand out from this dump:

• Data protection is DISABLED (!!)
• My activation code (WCE7TD) is stored in read/write memory (!!)
• There's some interesting patterns in the user-stored data..namely epoch timestamps (!!)

From this we can deduce the following:

• Staff with card readers use the in-memory access code to identify individuals
• Access-control information, such as timestamps, are stored directly on the card
• The access-control software then uses the information on the card to determine access

This begs the question: could one fudge the entire access-control system by taking advantage of the implementor's negligence and simply rewriting the data on the card?

Take a wild guess...

Rewriting the cards

With that knowledge in mind, let's try modifying our memory dump and re-writing the card. For example, lets change my access code to BANANA:

pi@omnibuslab $ sed -i -e "s/WCE7TD/BANANA/" gft.mfd

pi@omnibuslab $ ./rewrite_mfd_crc.py gft.mfd

As noted in the previous section, the cards have a CRC checksum. I'm not sure if the access-control software cares, but for good measure, I have made a small python script to recompute the checksum. For the sake of not providing a quick and easy way for ill-intentioned kids with no skills to fradulently make new cards, I won't provide it here (RTFM).

We can then proceed to write our file to the card's memory

pi@omnibuslab $ nfc-mfultralight w gft.mfd 

NFC device: pn532_uart:/dev/ttyAMA0 opened 

Found MIFARE Ultralight card with UID: 04ac3c6ac03480 

Write OTP bytes ? [yN] 

Write Lock bytes ? [yN] 

Write UID bytes (only for special writeable UID cards) ? [yN]

Writing 16 pages |ssss............| 

Done, 12 of 16 pages written (4 pages skipped).

Yay! It worked. Let's double-check by dumping the card's memory again and looking for our access code....

pi@omnibuslab $ nfc-mfultralight r -O gft_modifiee.mfd

NFC device: pn532_uart:/dev/ttyAMA0 opened 

Found MIFARE Ultralight card with UID: 04ac3c6ac03480 

Reading 16 pages |................| 

Done, 16 of 16 pages read. 

Writing data to file: gft_modifiee.mfd ... Done.

Reading back...

pi@omnibuslab $ hexdump -C gft_modifiee.mfd 

00000000 04 ac 3c 1c 6a c0 34 80 1e 48 00 00 e1 10 12 00 |..<.j.4..H......| 

00000010 01 03 a0 10 44 03 0d d1 01 09 54 02 65 6e 42 41 |....D.....T.enBA| 

00000020 4e 41 4e 41 fe 00 00 00 00 00 00 00 00 00 00 00 |NANA............| 

00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|

Our access code is now indeed BANANA.

The web interface

There's not much to say here, as I do not wish to audit their machines without their permission and be woken up by the police (again). One interesting piece of the puzzle is the complete lack of automation prevention on the activation page where attendees are required to register their passes once bought. This allows one to write a simple bot to interact with the activation process to make it process an arbitrary amount of requests. This knowledge will become useful in the next section...

Potential attacks

Summing up what we learned in the previous sections, we can design the following attack scenarios:

1) Long-range interception

Using a simple radio amplifier tuned to 13.56MHz, it is possible for a malicious individual to read and write card data from unsuspecting card carriers or points-of-sale

2) Card cloning

Due to the lack of data protection on the card, any malicious individual can read/write any access code they want to any MIFARE Ultralight card to get a working clone.

3) Mass collection of activation codes

Combining attacks #1 and #2, it is possible for a malicious individual to scan around locations where passes are sold in order to gather large quantities of access-codes 

4) Mass production of cloned cards

Combining #1,#2 and #3, it is possible for a malicious individual to harvest large quantities of access codes and then rewrite them into working clone cards.

5) Identity theft, personal information leaks and social engineering

Since the only piece of identification used is the user-modifiable access code stored on the card, a malicious individual can grab access codes using attack #1 or #3 and impersonate another person. 

Furthermore, since the access-control process at the gate relies on this code to fetch the pre-registered personal information in order to "reliably" identify the person at the gate, a malicious individual could use other access codes stored on cloned cards (attack #2) in order to gain sensitive information about others by social-engineering the gate staff.

6) Shut down the entire event

No, we are not kidding: by combining #3 with the lack of automation of the web-based activation process, a malicious individual could shut down access to the event to many if not all attendees. By harvesting a large amount of access codes using attack #3, a malicious individual could then write a simple bot to massively activate these codes on the activation website, therefore blocking legitimate pass owners from registering their pass and entering the event.

Recommendations

All of these security flaws originate from a mix of security by obscurity, negligence and/or lack of understanding of the underlying technologies used to implement the access control system. 

The following fixes should be applied to avoid exposing the public to useless risks:

• Conduct third-party security audits on technologies that handle personal information.
• Avoiding obsolete technologies with known security vulnerabilities.
• Avoid low-cost solutions and conduct due-diligence checks on technological choices made by vendors who claim to be able to save you money. There's no such thing as a free lunch. It's cheaper for a reason.
• Avoid security by obscurity. In 2016, hiding flaws hoping that they won't be discovered is downright negligence.
• Use "security by design" paradigms, such as avoiding linking personal information to user-modifiable data stored on insecure cards.
• Make use of the security features provided by vendors, such as using lock-bytes in the MIFARE Ultralight cards to avoid data tampering.
• Encrypt data stored on mobile mediums such as RFID cards
• Protect web-based processes from automation by using CAPTCHAs or any other from the hundreds of similar technologies on the market.
• Don't spread lies in the news to cover up your mistakes, unless you want to tempt someone to prove you wrong.