Snooping a MF classic exchange

holiman · 2013-08-28 09:02:44

I'm wondering a bit about the consequences of snooping a mf exchange. Scenario:
1. A transport system uses mf classic
2. When a passenger uses his card, after the initial crypto-exchange, the reader reads some of the data on the card. This data is application-specific, and the format not known
3. The reader then writes some data, indicating that a trip has been made. This is encrypted and signed, unknown format.

Let's say the keys are known, since the system uses the same keys for all cards. If an attacker was to snoop such an exchange, that would mean that the attacker would be able to figure out the following:
* The content of the sectors that the reader read
* The content of the sectors that the reader wrote to

How would I go about in order to snoop that and dump that known sector-data onto another card? Is there any way to say "snoop this, and btw, the keys used for the different sectors are X,Y and Z"?

What I'm trying to figure out is if it is feasible to snoop a transport-card at the reader and make a partial (but sufficient) on-the-fly copy.

iceman · 2013-08-28 11:06:43

The one system I been looking into uses a hash with a "private key" which is used to sign the sector data and the uid of the card. So even if you snoop the trafic, you might only clone the sector to a magic card.. You can however not make new trips without know the private key for the hash-algo.

holiman · 2013-08-28 12:04:16

Could you elaborate a bit?

As I imagine it would work... and please correct me:
Since the native crypto is br0kken, and we know the keys, the mf-card is basically a ledger. When someone uses his card, the reader would check that the ledger is correct (verify signature/hash) and then write something in this ledger, e.g. a timestamp and an updated checksum/hash. The attacker does not know how this hash is calculated. The reader also stores the current 'state' or 'hash' of the ledger in a backend db, in order to detect discrepancies, e.g. if someone is using a cloned card, or resetting his card to a previous state.

As the attack would work:
The attacker listens and records. He can obtain everything that the reader requests (the content of the ledger as it was when the victim used it), and also the last entry that the reader wrote to the card.By using a magic card, or pm3, he emulates this, presenting a card that looks just like the victim's card would look at by now (at least the sectors that the reader is interested in). The reader would again write a new entry to the card, which the pm3 would gladly acknowledge. A nasty side-effect would probably be that the next time the victim tries to use his card, it will look like he has reset his card, since his card lacks the last transaction.

I don't understand how knowing the private key would be required?

iceman · 2013-08-28 13:26:44

I agree with the first part.

The attack could be seen as a replay-attack, where-as you sniff a legit card transaction and replay it for the reader with a PM3. However why would the reader write a new entry to the card? If the sniffed transaction is still valid, the reader don't have to write anything ie you have a valid busticket.

The side-affects are possible and most likely to be true. However, I guess that it is not a question of "fooling" the reader, but it is a question of trying to fool a conductor on the bus who are physically checking the tickets, ie the card. Try showing a PM3 at that momemt and you get caught and fined.
I suggest that you make the replay-attack a bit better with a pm3 to sniff, a magic-card and a thermo-plastic idcard writer.

On the system I checked, the UID of the card was printed on the card. So you need to copy that aswell, not that hard. In the end you can travel free for a while. I suppose the backend db will eventually see the trends in your travels and the repeated uid in there. This I guess will take some time.

iceman · 2013-08-28 13:30:09

And to answer the question with the private key, is that you can make your own tickets and change the uid aswell. So the transport system will have a hell of a time finding you. ie the system will break if you figure out the private master key. In the system I checked, there are 64 master keys...

I suspect that they can update and change the master keys in the readers centrally. So even if you break them, they could change when ever they want. That will however inflict on every card sold for that system so it is not feasable to do it.

holiman · 2013-08-28 13:51:13

I am only trying to figure out the consequences of such an attack. As the mifare is known to be cracked, these companies have been forced to security in an additional layer within the data sectors. That's fine and dandy - if the card is of the type "X travels" or "X money", and the attacker clones the card, and later reset the card between travels, he will get busted, or at least the card will be blacklisted (and wiped). So the protection they have built works there.

But this is another type of attack, and I'm trying to figure out of they would be able to stop this attack. The goal is to get past the reader, an attacker caught without a valid ticket is fined, but not heavily. I'm not directly interested in actually copying cards, but performing this via pm3 would be fun - seeing that it can be done, but not actually using it to avoid the ticket fare.

iceman wrote:

I agree with the first part.
The attack could be seen as a replay-attack, where-as you sniff a legit card transaction and replay it for the reader with a PM3. However why would the reader write a new entry to the card? If the sniffed transaction is still valid, the reader don't have to write anything ie you have a valid busticket.

I suspect that the reader writes to the card, in order to countdown the number of remaining travels/credits. It is not connected in real-time to the backend db - they fetch blacklists via batch jobs, and, I suspect, coordinate the 'state' for all cards. Even if the card is not credit-based, but "valid during october", it may write to it just to be able to stop an attack where a user has duplicated it and ten different persons are using the 'same card'.

iceman · 2013-08-28 14:39:13

Then the replay-attack will work with a magic card or pm3 as you stated. Sniff the traffic, replay with pm3 or copy to a magic card and the reader will happily accept it. The cloning (with the mifare keys) is the same as the replay attack (without keys?). But now I am curious in what kind of attack you have in mind. Or are you thinking of an attack where there is no need for the mifare-keys... Like the pm3 to respond correctly, and when getting a write cmd, it answers that it wrote it correct. Keeping the reader happy. I guess that will work but is migated with the blacklists.

holiman · 2013-08-29 07:55:20

I have now looked a bit more about how to operate in snoop mode, using this video :http://www.youtube.com/watch?v=kTvb7tjbSTI .
A few takeaways :
- When snooping mifare, you can obtain the keys, even if you didn't have them before
- If someone was to rewrite the snooper in lua, it would be easy to automatically extract the keys, instead of running through an external program using cut'n'paste.

So, back to the attack. Some background; I am curious about passive sniffing. NFC technology is aimed at coils causing induction in each others, and snooping with a coil antenna is, perhaps, not optimal (I am not a radio technician though ). I will obtain a HackRF (http://www.kickstarter.com/projects/mossmann/hackrf-an-open-source-sdr-platform) when it's released, and want to experiment with picking up high frequency exchanges (mifare), and see what kind of snooping distance I can achieve with other types of antennas. It seems to me that most work in passive rfid-snooping or long-distance reading has been aimed at LF-gear (Chris Paget / proxclone / Francis Brown).

With that in mind, I thought about what kinds of attacks can be made. Such as the one above.

I guess that will work but is migated with the blacklists.

Is it really? As I see it, the blacklist system will strike at the wrong person, and not affect the attacker... The next time the attacker wanted to travel, he would just snoop a new card before going through the turnstile.

asper · 2013-08-29 08:19:42

Hackrf range will be from 30MHz to 6GHz, i don't think it will be good for 13.56MHz. Jawbreaker (hackrf prototype) was from 20MHz to 6GHz maybe it works good also at 13.56MHz.

holiman · 2013-08-29 09:01:24

I am a 310$-backer, which includes a ham-it-up converter, so effectively 30kHz - 6 GHz. And regarding the jawbreaker, (which the same range, not 20 but 30 MHz), Ossman still managed to capture som 13.56MHz rfid communications (http://ossmann.blogspot.se/2013/06/hackrf-lego-car.html)

The recordings were quite clean even though 27 MHz is below Jawbreaker's official operating range (30 MHz to 6000 MHz). In fact, I had captured some apparently good recordings of NFC transactions at 13.56 MHz just the day before. The major drop-off in performance I've observed on Jawbreakers I've tested has been just below 10 MHz.

asper · 2013-08-29 12:05:33

What software do you think you will use to interact with hackrf? Gnuradio is not so easy to use... i am not backing only because of that...

holiman · 2013-08-29 12:34:56

I'll start with gnuradio, to get a feeling for what distances can be used - perhaps it doesn't even work well enough to be of any practical difference . I don't expect too much difficulties there (I've started to become acquainted with grc, if not proficient). For the whole snoop -> decode -> crack -> decrypt -> emulate process, I dont know, one step at a time..

holiman · 2013-08-29 12:40:12

Although, I expect that grc will be involved for handling some sampling and filtering, then baudline to get binary data, then some kind of existing nfc-libraries and crapto for decoding, and somehow chucking that all into a format that the pm3 can use for emulation.

asper · 2013-08-29 13:42:20

Well if you will have one probably i will pledge too

Edit:
Can i contact you with a private mail holiman ?

Last edited by asper (2013-08-29 15:40:28)

holiman · 2013-08-29 20:02:34

Sounds good - you can never have too many gadgets

Sure, you can reach me at martin on the domain swende.se.

Proxmark3 community

Announcement

#1 2013-08-28 09:02:44

Snooping a MF classic exchange

#2 2013-08-28 11:06:43

Re: Snooping a MF classic exchange

#3 2013-08-28 12:04:16

Re: Snooping a MF classic exchange

#4 2013-08-28 13:26:44

Re: Snooping a MF classic exchange

#5 2013-08-28 13:30:09

Re: Snooping a MF classic exchange

#6 2013-08-28 13:51:13

Re: Snooping a MF classic exchange

#7 2013-08-28 14:39:13

Re: Snooping a MF classic exchange

#8 2013-08-29 07:55:20

Re: Snooping a MF classic exchange

#9 2013-08-29 08:19:42

Re: Snooping a MF classic exchange

#10 2013-08-29 09:01:24

Re: Snooping a MF classic exchange

#11 2013-08-29 12:05:33

Re: Snooping a MF classic exchange

#12 2013-08-29 12:34:56

Re: Snooping a MF classic exchange

#13 2013-08-29 12:40:12

Re: Snooping a MF classic exchange

#14 2013-08-29 13:42:20

Re: Snooping a MF classic exchange

#15 2013-08-29 20:02:34

Re: Snooping a MF classic exchange

Board footer