Pierluigi Paganini
October 16, 2019
The affected vendor did not answer to my responsible disclosure request, so I’m here to disclose this “hack” without revealing the name of the vendor itself.
The target vending machine uses an insecure NFC Card, MIFARE Classic 1k, that has been affected by multiple vulnerabilities so should not be used in important application.
Furthermore, the user’s credit was stored on the card enabling different attack scenarios, from double spending to potential data tamper storing an arbitrary credit.
EEPROM: 1 kB is organized in 16 sectors of 4 blocks. One block contains 16 bytes.
The last block of each sector is called “trailer”, which contains two secret keys and programmable access conditions for each block in this sector.
In this post I did not show you how to crack the MIFARE Classic Keys needed to read/write the card, ’cause someone else has already disclosed it some time ago, so google is your friend.
At last, please, use this post to skill yourself about the fascinating world of reverse engineering, and not for stealing stuffs.
In order to start the analysis I need some dump to compare.
The requirements of this task are nfc-mfclassic tool included in libnfc, a NFC hardware interface like ACR122U, and a binary compare (aka binarydiff) tool like dhex.
Dumps:
Blurred bytes are the MIFARE keys A and B, except for the 32 bytes at 0xE0 offset of which I don’t know their purpose.
The 4 bytes between the keys are Access Condition and denotes which key must be used for read and write operation (A or B key) and the block type (“read/write block” or “value block”).
The tool mfdread is useful to decode the Access Condition bytes rapidly, and, in general, to display MIFARE Classic data divided by sectors and blocks:
Note: from now on I will refer to the offsets with a [square parenthesis] and a value with no parenthesis.
If there is credit stored on the card, it was encoded at blocks 8 and 9, and the number of bytes involved between small credit difference (for example between 0.00€ and 0.10€) could indicate that some cryptographic function is involved.
At this time, a double spending attack could confirm if the credit is really stored on the card.
So, after spending all the credit, I have rewritten a previous dump on the card and I went to test it at the vending machine. The card was fully functional with the previous credit stored in that dump. Now, I’m certain that the credit is encoded (and probably encrypted) in the blocks 8 and 9.
Even if the encoding format of the credit is still unknown, a double spending attack was possible.
This means that the vendor’s effort to obfuscate the credit is nullified 
Adding some unique token on the card that are invalidated into back-end after each transaction, means that this token needs to be shared between all the vending machines of the vendor, but, if we add internet connection to the vending machine, there is no longer reason to store the credit on the card.
So, after all, the only remediation action that makes sense is: DO NOT STORE THE CREDIT ON THE CARD! And, more generally: DO NOT TRUST THE CLIENT!
Spending 1€ infinite times isn’t the scope of that hack. The only real scope is FUN!
To continue this analysis I need to collect a large number of dumps to advance some hypothesis so, when I have other material I will make another post.
Some vendor has more easier approach by using the MIFARE “Value block” to store the credit without obfuscation or encryption.
The above screenshot made with “MIFARE Classic Tool” on Android smartphone, represents a Value Block used to store the credit:
0x00000CE4 = 3300 is the value in Euro thousandths (3.30€).
This particular vendor do not use key A and the Key B is a default key 0xFFFFFFFFFFFFFFFF, so the attacker doesn’t need to crack anything.
Reverse engineering and cracking of a Vending Machine is always funny.
The original post was published here
About the author: Pasquale Fiorillo
I’m a Security Auditor of ISGroup and an independent Security Researcher. As Security Auditor, my job is to perform security activities like Penetration Test and Vulnerability Assessment on networks and web applications in order to identify security issues that may be exploited by an attacker to perform malicious actions on your assets.
When I was a teenager I have co-founded an underground e-zine called Italian Hard Phreaking with some friends on IRC, writing lots of papers related to hack and reverse engineering stuffs in the telecommunication world. Later, I’ve started a new adventure as a Security Researcher, discovering vulnerabilities in a commonly used software, web applications, and web sites, in collaboration with other fabulous people of U.S.H.
| [adrotate banner=”9″] | [adrotate banner=”12″] |
(
[adrotate banner=”5″]
[adrotate banner=”13″]
