Today I would like to speak with you about NFCulT, what is it, how it has been created and why.
The whole thing started in Jenuary 2013 when here in Turin ( Italy ) the local transport company started deploying NFC based ticketing solution.
This was divided into two different chips and standards:
The first one for cheap and disposable tickets ( like, multiple/single ride tickets ). The second one instead is used for yearly subscription. As first though we, me and a friend of mine, would like to study against Calypso cards, but we notice that Calypso standard is closed, and costs around 10'000€ to gain access to some documenation.
We then focus our attention on Ultralight chips, of which you can find datasheet here.
Example of NFC Mifare UL chip used as multiple-rides ticket
The NXP Mifare Ultralight chips is a 64 bytes NFC chips, with some interesting features:
UID - There is a 7 byte UID programmed by the NXP
Checksum - There is a 2 byte checksum calculated XORing UID bytes.
OTP - A for 4 byte sector which bits are One-Time-Programmable.
Lock - In this sector each of its 16 bits set in Read-Only one page.
Data - Widest sector, usually used to store timestamp, stop ID, etc
The first idea was to increase the number of rides, but this can't be done, since most of companies use OTP to store the number of rides.
0000 0000 0111 1111 - In this case you still have 9 rides left
OTP sector changes its value using the OR operation, which means that bits, once turned to 1, cannot be turned to back 0.
The hack become keeping the same number of rides and have a valid ticket, and this will remain our purpouse for all attacks.
To exploit this we need two different unharmful vulnerabilities, one in Mifare Ultralight protocol and one in most of the implementations found so far.
The WRITE command has no feedback.
The implemenations doesn't implement the feedback via software.
Using the Lock sector we can set the OTP page in Read-Only, and since there is no feedback the stamping machine will set a proper timestamp but it cannot remove one rides from the ticket, giving us an infinite ticket.
This exploit is based on the assumption that, once stamped, your ticket will have a defined amount of minutes of availability. Let's say 100 minutes. Since your ticket its a multiple ride one, it must be able to store the timestamp of the actual stamp multiple times, and 80% of implementations doesn't implement software encryption for data stored on the ticket.
Which means that you can pretty easily decode how the timestamp is written and where, then forge a valid timestamp, write it on the correct page without removing a ride from OTP. In the end you will have a ticket, valid for 100 minutes with the same number of ride of before, and once the minutes are expired you can do it again..over and over.
Lets says that you found timestamp stored on page 10, so you just need to decode it:
Page 0x0A --> 45 98 7B 00
Converting it to int gives us:
0x45987b00 = 1167620864
which clearly is too little to be an Unix EPOCH timestamp.
After a couple of more stamps, we can see that the last byte, 00, doesn't change. Trying again without it gives us:
0x45987b = 4561019
Since we also know that ticket is valid for a fixed amount of minutes and not seconds, we can suppose that this number rapresents how many minutes has been passed from a fixed date, which I will call 0-time.
With easy calculation, knowing the exact minute in which we stamped the ticket, we can find that 4561019 means 1st Jan 2005 as 0-time.
Now, calculating the number of minutes from 1st Jan 2005 to now we can forge a valid timestamp and write it on the correct page.
This is an interesting vulnerability when you encounter some sort of encryption on the ticket's data. Let's suppose for example we got an AES256 encrypted timestamp with a very strong key. Bruteforcing it is not feasible. In several implementations we found, this encrypted timestamp is not salted with some unique ID, like for example UID of the ticket. We can then stamp one ticket, and copy the encrypted timestamp onto an other ticket to have a legit and valid timestamp. And we can do it over and over again, with a theorical unlimited number of ticket.
There are a few implementations which use UID as IV for the encryption of some sort of data. How to bypass this?
We are required to buy chinese-clone UL chip, which let you edit any page ( UID/OTP included ). In this way we can create a perfect clone of your real ticket.
Basically steps here are:
Clone a legit ticket onto the clone.
Add one ride on the OTP sector of your clone ticket.
Copy back on the legit ticket all data.
Note: After you stamp your clone ticket it will be totally identical to your real one, OTP included.
And here it comes NFCulT, what is it?
It is an Android application which implements the vulnerabilities of above and will help researchers and exploiters to invistigate NFC UL implementations around the world.
The application is opensource, you can find source code on github, or you can download the apk from Google Play.
There is also a custom edit section, in which you can edit each bit of each page, which is usefull to find out which is the 0-time and the correct page for the time attack, for example.
Note: A new version of NFCulT will be released on BlackHat Europe Arsenal. I'll have a booth there both 16 and 17 October from 10AM to 12.30AM. At this very moment these are all vulnerabilities found so far in Mifare UL implementations, I invite you to explore, hack and found new stuff, maybe using NFCulT app on your Android smartphone.