Dan Borgogno nos compartió en el #DragonJARCON 2020 una charla titulada "Free rides! SUBE, REDBUS, SATBUS and others" cuya descripción es: ¿Te has preguntado alguna vez cómo funcionan las tarjetas MIFARE? En esta charla mostraremos 3 implementaciones diferentes detrás de los sistemas de transporte público, y cómo explotar cada una de ellas para viajar gratis en 3 ciudades principales de Argentina: Buenos Aires, Córdoba y Río Cuarto. "," Descripción ":" Las tarjetas Mifare son una tecnología bien conocida y se utilizan ampliamente en casi todos los transportes públicos de Argentina. Esta charla brindará una introducción de la tecnología detrás de las tarjetas Mifare con sus vulnerabilidades conocidas para hacer un análisis profundo de cómo cada sistema de transporte implementa el saldo en esas tarjetas y cómo explotarlo. Aprenderá a descifrar tarjetas, aplicar ingeniería inversa a los datos almacenados en la memoria, desarrollar una aplicación sencilla para cambiar datos y aplicar ingeniería inversa a un APK para recopilar información útil relacionada con el equilibrio de los plásticos. Les mostraré casos reales sobre argentina, dirigidos a SUBE, REDBUS y SATSRC entre otros. "," Notas ":" Primer caso: SATBUS Como estudiante, estudié en Río Cuarto, Córdoba. En esa ciudad existe SATBUS con una implementación personalizada de la moneda. Para recopilar la información dentro de la tarjeta, traté de comparar los sectores de memoria con las contraseñas predeterminadas, lo que nos dice que algunos sectores comparten la misma contraseña: ffffffffffff. Así que suponemos que el \ "dinero \" se almacena en uno de los sectores protegidos. Como estamos ante una tarjeta clásica de Mifare, lo primero que intentamos es realizar un ataque anidado contra la tarjeta (MFOC) con un lector de coche. Esta charla mostrará un volcado de la información de la tarjeta. Ahora, con las nuevas claves, podemos leer la información de la tarjeta. La tarjeta en este caso, tenía $ 10, o 1000 centavos, en hexadecimal: 03 e8. Esta información se encuentra en la memoria y luego se edita como PoC. Cambiar este valor le permitirá moverse libremente en Río Cuarto. ----------------------------------------------------------------------------------------------- Youtube: DragonJARtv (http://bit.ly/DragonJARtv) Facebook: La.Comunidad.DragonJAR (http://bit.ly/DragonJARfb) Twitter: @DragonJAR (http://bit.ly/DragonJARt) Instagram: Dragon.JAR (http://bit.ly/DragonJARig) Discord: https://invite.gg/DragonJAR Blog: Comunidad DragonJAR (http://bit.ly/DragonJAR) -----------------------------------------------------------------------------------------------

1. FREE RIDES!SUBE, REDBUS, SATBUS and others.

2. WHOAMI
Dan Borgogno
Security engineer @Naranja. Security researcher & Backend developer.
@cbahackerspace
@DBorgogno
Córdoba, Argentina.
danborgogno@gmail.com

3. MIFARE CLASSIC 1K
● Storage devices, they use NFC to transfer and store information
● They have a set of memory cells, each one protected by a pair of keys and
access bits.
○ Key: needed to allow operations that are restricted by
○ Acces bits: which operations are allowed by each key
● They have a Operative System running, that handles the authentication and
communication with the reader

4. MIFARE CLASSIC 1K
Concepts:
● UID: Unique Identifier. Unchangeable, unique.
● Sector 0: first sector of the card, containing the UID and 2 data storage
sectors, protected by keys.
● Data is stored in hex, and each memory sector can have 2 types:
○ Storage blocks
○ Value blocks
● Chinese mifare cards
● Proxmark
● How to hack? Get keys, read data, profit!... profit?

5. MIFARE CLASSIC 1K

6. SAT BUS
Long story short, I was in college, Rio cuarto.
Sat Bus implements proximity cards on the public transport system
So, I used my friend’s phone (with NFC) to check what type of card they were
using.

7. SAT BUS
Attack used: standard keys dictionary.
Protected sectors: I gathered a ACR122U, installed some libraries (libnfc) and
downloaded a “older” version of MFCUK.
Run
● /mfoc$ mfoc -O card_dump

8. SAT BUS
Try to authenticate to all sectors with default keys...
[Key: ffffffffffff] -> [xx..xxxxxxx....x]
[Key: a0a1a2a3a4a5] -> [xx..xxxxxxx....x]
[Key: d3f7d3f7d3f7] -> [xx..xxxxxxx....x]
[Key: 000000000000] -> [xx..xxxxxxx....x]
[Key: b0b1b2b3b4b5] -> [xx..xxxxxxx....x]
…
[Key: 8fd0a4f256e9] -> [xx..xxxxxxx....x]

9. SAT BUS
Using sector 00 as an exploit sector
Sector: 2, type A, probe 0, distance 64 .....
Found Key: A [062456######]
Data read with Key A revealed Key B: [062456######] - checking Auth: OK
Sector: 3, type A, probe 0, distance 64 .....
Found Key: A [a3783b######]
Data read with Key A revealed Key B: [000000000000] - checking Auth:
Failed!
Sector: 11, type A
Data read with Key A revealed Key B: [062456######] - checking Auth: OK
Found Key: A [062456######]

11. SAT BUS
My plastic, at the time, had $10 (ARS), or 1000 cents:
● This value, expressed in HEX: 0x03e8
● This value was found in sector 11, block 0
● Modifying this value, an attacker could increase the balance of the card, with
a simple android app called mifare classic tool and a NFC compatible phone.

12. LEP BUS & INTERCORDOBA
Buses LEP and Intercordoba are two bus systems that use the same card.
They are vulnerable to the same attack, and they seem to be implemented by the
same provider.
Example LEP:

13. LEP BUS & INTERCORDOBA
In the previous case, I had $125 (ARS), or 12500 cents (0x30d4):
● This value was found on sector 2, block 0.
● To double check if the value was, I performed a diff check after I used the
card and found:
● We can still change the value or, create a snapshot and restore it on each
ride.

14. REDBUS
Then, I moved to Cordoba.
In this city there was another public
transport system, called REDBUS,
and it uses mifare cards for the same purpose.
So, i tried the same attack and,
to my surprise, there was no default key.
No panic, there’s another attack: MFCUK
● ./mfcuk -C -R 0:A -v 2

15. REDBUS
To my surprise, the attack was not successful. After some research, I found out
the card I had was a mifare plus card:
● Fixed CRYPTO1 algorithm.
● Increased security measures.
I started to give up when I saw
an old lady using this:

16. REDBUS
I managed to get a sample of those “old” cards, and then I tried the same attack:
● ./mfcuk -C -R 0:A -v 2
The attack was successful, and it gave a single key on sector 0. This key was
then used to perform mfoc on the same card.
When I gathered all keys, I saved all of them on a file and used this dictionary to
check on the new cards and… they were all the same keys!

17. REDBUS

18. REDBUS

19. REDBUS
Then I decided to make a APK, just as a proof of concept

20. REDBUS

21. REDBUS

22. SUBE
I traveled a few times to Buenos Aires, and I used the SUBE card multiple times.
My card was a new challenge, the first thing it came to my mind is to get the keys
from an old card:
● The old sube card has been hacked a long time ago because it is vulnerable
to all the mifare attacks: mfoc, mfcuk, sniffing.
● The attackers, used this vulnerabilities to build snapshots of the card and
restore them on each ride.
● The attackers used a pn532 reader with USB to UART, and libnfc on linux.

23. SUBE

24. SUBE
Once I hacked a old card, I tried to read the memory of the new SUBE card, but
to my surprise, there was no common key between them.
So, there was a dead end because I had no way way to get the keys.
Months pass by, SUBE publishes a USB writer/reader, so I’m one of the first guys
to get one.
I downloaded the app, and started the tests on the apk. I charged some credit,
watched the transactions between the backend and the app, and started to build
a knowledge base on the information that was passing by.

25. SUBE

26. SUBE
I built a lab to understand the information that was passing by, and try to catch
the keys, either on a transaction, or in a firmware update:
● Triggered a firmware update to reverse engineer it.
● Edited the APK, to allow rooted phones to run it.
● Edited the APK to log all output
○ Originally, it had a log method, but it was empty. I added the smali code to log the
information.
● And then… SUBE published another APK: CARGA SUBE

27. SUBE
CARGA SUBE is a new app for SUBE that:
● Uses the NFC from the phone to perform transactions
● It doesn’t require any additional hardware
So, my first idea was to reverse engineer it, so I did it. I put
the app in debug mode, and started looking at the source
code, since every APK is a zipped smali container.
● APKTool
● Smali for IDEA
(https://github.com/JesusFreke/smali/wiki/smalidea)

28. SUBE
To my surprise, the code was obfuscated, but:
● Android only allows mifare connections through native methods.
● Android native code cannot communicate through nfc with a mifare card.
All I had to do is find the calls to the native methods and intercept the calls.
● authenticateSectorWithKeyA(int, byte[])
● authenticateSectorWithKeyB(int, byte[])

29. SUBE

30. SUBE
Once I had the keys, I used a new mfoc method, called hardnested attack.
The sube card (mifare plus), in security mode 2, allows an attacker to guess the
keys of all the rest of the sectors using any known key.
For this attack, I used a proxmark3 in macOS.
So, in a few hours, I had all the keys for the card.
The next thing to do was to read the information, and see if we can increase the
money in the card.

31. SUBE
Analyzing the data I get a few conclusions:
● The balance is encrypted in the card
● The encryption takes 3 elements:
○ The UID
○ The current balance
○ The counters on block 0, sector 1 and 2
○ A private key
● Since I don’t know the key, there’s no way to
alter the balance without breaking the card
● Value blocks on sector 0 are decremental only
● Each card has its own keys, generated by the
algorithm.

32. SUBE
What does that mean?:
● The balance is encrypted
● There are common keys and unique keys
● You cannot increment the counter
● Basically you can’t restore a snapshot
● You can’t alter the credit

33. SUBE
Is the card vulnerable?
The first attack i tried was to use a chinese mifare card, with UID changeable.
● Since the card can be copied identically with the same UID and wiped out
with backdoored commands, you can emulate a old dump
● This attack was not successful, the reader can tell when a card is a
backdoored one.
● Also, the mifare plus cards have an additional “auth” method to check (with a
private, very long key) that my chinese card could not emulate

34. SUBE
So, no chinese card then.
Emulation is also not possible since I cannot guess (yet) the private key of the
mifare plus.
Looking at the card internal memory, there’s 3 attacks that can be performed to
gain various benefits:
● Relay Attack
● Hacking the SUBE Apk
● DOS attack

35. SUBE
Relay attack
Running a script from
proxmark, I tried to
perform a proximity check

36. SUBE
The script kept failing.
The version of the mifare plus is S has no proximity check implemented.
This means, you can build a proxy between two pn532 and a microcontroller
blocking the decrement operation on each transaction with the reader, and then
restoring an old snapshot on the card to have always the same balance.
In my case, I used a raspberry, with two pn532 on SPI, one in target mode and
libnfc. (nfc-relay-picc)
Nfc-relay-picc.c modified to detect and block the decremental operation

37. SUBE

38. SUBE
Create
snapshot
Use relay with
card on reader
Block decrement
operation and respond
Restore old
snapshot

39. SUBE
Hacking the APK:
● You can block, editing the apk of the application, the method that
decrements the counter each time you legally change the credit of you card.
● This way, to have 1 free ride you must:
○ Create a snapshot of the card before charge (1)
○ Charge credit, blocking the decrement counter
○ Create another snapshot (2)
○ Restore old snapshot (1)
○ Have a nice ride
○ Restore old snapshot (2)

40. SUBE
Create
snapshot
Charge money,
create snapshot,
Block decrem
+$50
$100 snapshot,
consistent with
decrem:9
$50 snapshot,
consistent with
decrem:10
Card
Decrem:10
Money:$50
Card
Decrem:10
Money:$100
Restore $50
snapshot
Card
Decrem:10
Money:$50
Free Ride!
Card
Decrem:9
Money:$40
Restore $100
snapshot
Card
Decrem:9
Money:$100
THIS RIDE
NEVER
EXISTED!

41. SUBE

42. SUBE
DOS Attack
Since all the information in the card has a fixed “state”, if you alter the counter,
you will make the card inconsistent.
The cards have a single set of keys that belongs only to them, but they also have
shared keys, that allows the reader to get the information to generate their private
keys.
Also, mifare only allows decrement to 0, so you can build a simple “card
invalidator” apk that, reads the counter with the public key and decrements to 0
the counter, leaving the card useless.

43. SUBE
TODO:
● Smaller relay
● Data encryption analysis
● Play with the backend
● Traffic analysis
● Libsube.so reverse engineering

44. FINAL WORDS
Even if the attacks are valid, there’s still a problem with the abuse of the system:
● Eventually, the system database will detect the anomaly and the card will be
blocked.
● In argentina, using the cards to ride freely can be seen as fraud.
● The amount of money and technology needed to perform the attacks on
SUBE is not worth the risk.

45. TWITTER
@DBorgogno