As we’ve seen in a previous post here, RFID is a technology widely used in our lives, from our building access badges, to payment facilities, or even our gates’ remotes. We know some of them are utilizing little to no security mechanisms, like MIFARE, and today we will start working on a really basic series of hacks.
What you will need
What’s covered can be done with a simple RFID card reader found on Amazon for ~30€ (~35$). Mine was the ACS ACR122U simply because it was the most mentioned one on a few forums and blog posts I had read at the time and thougt it would make things easier for support.
In a previous post, we saw that tags have a specific block of memory reserved to the manufacturer, including an UID (Unique IDentifier).
If you want to try and clone a tag, you will need to be able to spoof this UID, so I also ordered a few tags (blank cards and key-fobs) with an UID rewritable.
Any UNIX/LINUX distribution will do the trick (Windows too eventually), but after a few trials and errors I figured out working on RFID and NFC works better with security oriented distributions like Kali or ParrotSec, as they already include all the tools and libraries we will need.
I also found out that working in VMs can sometimes be a pain as the guest host always keep a bit of control over the USB ports (via probes) and our card reader needs a full access to those ports at any time, or time-outs during read/write operations will occur and can permanentaly damage a tag.
NB: For those of you getting an error when trying to run any NFC related operations on an ACR122, note the following command sudo rmmod pn533_usb
This will remove the USB module of your OS and “reset” the USB port so your reader can freely access it.
The best combination (aka the one I struggled the less with) was, for me, the following:
- ParrotSec 4.19 (as a guest OS)
- Super user rights (most NFC commands will require it, just saving you some time here)
- The latest libusb (just a C library to handle generic USB peripherals, should be present on any decent distribution anyway)
- The latest libcrypto (belongs to the OpenSSL package, but can be used for various cryptographic operations, like cracking keys *wink wink*)
Let’s start with nfc-list which will try to connect to the reader and read any tags in range:
The device is detected and active, interface is opened, and there is an ISO/IEC 14443A compliant tag in range (which is a barbaric term for a MIFARE card). Our first relevant information, this MIFARE tag’s UID is 7BE88C21.
MFOC – MiFare classic Offline Cracker
The easiest and most basic tool to use against MIFARE tags is MFOC. Once MFOC detects a tag, it tries to authenticate with different keys and if one of the key is correct the tool can “guess” the other keys and dump the memory of the tag.
On the image above, I have launched a MFOC attack, asking the tool to dump the memory of the tag into a file via -O option.
Just like nfc-list, MFOC will detect the tag on the reader as a MIFARE Classic 1K, give us the UID, and then start trying the keys from his own dictionnary against every sector of the tag.
The output of MFOC is quite simple:
– the key FFFFFFFFFFFF is not used by any sector
– the key A0A1A2A3A4A5 is used as a key A onto all sectors from 0 to 15
– the key B0B1B2B3B4B5 is used as a key B onto sectors 0 to 11
We now have the keys A & B for 12 sectors, the keys A for the last 4 sectors, and we are missing 4 keys to be able to fully read our tag.
Enter MFOC’s phase 2:
As mentioned on the image above, MFOC is using the sector 0 as an exploit sector simply because he knows both A & B keys for this one (hence any sector from 0 to 11 could be used as an exploit sector). He is then sending probes onto the “uncracked” sectors and, just like a time-based blind SQL injection, will compare the answer’s delay with a positive one onto sector 0.
Once the last 4 uncracked sectors have unveiled their B keys, MFOC is able to authenticate with both A & B keys and therefore dump the memory of the entire tag in a file.
We can read and edit said file with a simple hexadecimal tool like hexeditor :
The red area is actually a whole sector as we detailed them in the first article, and on line 2B0 you can see the A key A0A1A2A3A4A5 and B key B0B1B2B3B4B5, separated by the 8 access bits 78778869 of the concerned sector.
The tag I worked on is a simple building access tag, the one from my own appartment. All sectors were using a default key, therefore the dump took me only about ~20-25 seconds. From here I tried to copy my badge to see if my building’s scanner would see any difference between the original tag and a perfect clone, UID included.
This brings us to nfc-mfclassic, a tool that will allow us to write dump files on the new tag. This tool is quite simple to use, a look at the man page is enough and will tell us all we need to know: we can write dumps on a new tag with a w options, but a W (notice the uppercase) will not only write the whole dump’s data but will also rewrite the UID.
Let’s try to write the dump we just created with mfoc onto the new tag ordered on Amazon, using the A keys stored in the dump file itself:
NB: Before you can write on your virgin tag, you will need to know its own keys. To do that you will need to use MFOC once on it, and store the keys on a file to reuse them for your rewriting/cloning.
As we write to the tag, it tells us the previous UID of the tag was 949E0139, and that 64 blocks of data have been written on it. Using nfc-list again to read a tag will show us the UID of the new tag has been changed and is now identical to my original building’s tag.
In this post we have learned how to use the basic NFC and MIFARE commands to read a tag directly from a generic NFC reader, and eventually dump the content of the tag’s memory if it was using default keys (which is – trust me on this – more than 75% of the tags I have tried so far).
You are now capable of cloning different MIFARE classic tags, but …
– What if no default keys are used ?
– What if you want to edit the content of the data and give you access somewhere you shouldn’t be ?
That, my friends, will be for the next article of this RFID serie 😉