Zigfrid – A Passive RFID Fuzzer | Hacker News Reader

Zigfrid – A Passive RFID Fuzzer

z4ziggy.wordpress.com

128 pointswolframio29 comments

Somehow this post skips an explanation of what it actually does. It's a passive RFID tag that sends 40 bits of data (5 bytes). The bits are changed in sequence. More of a brute force attack than a fuzzer.

From the comments in the source, the code needs 20 clock cycles to send a new tag, it's running at 125kHz and each tag is 40 bits long. How can this device bruteforce the tag at this rate? Won't it be extremely slow compared to the number of possible tags?

Well let's do the math

125 kHz 2 bits/cycle = 250 bits /sec

A 2^40 bit string has 1099511627776 combinations, and would require 1099511627776 40 = 43980465111040 bits to besent to try all of them. That would take 43980465111040/250 seconds or about 5575 years

And that's under ideal "spherical object in a vacuum" conditions.

So yeah your right, unless they get lucky.

Bruteforcing is totally doable because in practice the unique identifiers broadcasted by these tags are allocated sequentially. I built an AVRFID a few years ago to bruteforce the HID ProxCard II RFIDs at work (45 bits of data: 20-bit mfg ID, 8-bit facility ID, 16-bit tag ID, 1 odd parity bit). Starting from my ID, and incrementing it one by one, it only took seconds to find many other valid IDs that were unlocking doors of various restricted areas. Imagine a disgruntled employee who has his legit RFID and is looking to access other restricted areas to which he normally doesn't have access... bruteforcing works perfectly fine for him.

I believe your math is off by a factor of 1000.

125kHz = 125,000 cycles/sec * 2 bits/cycle = 250,000 bits/sec

250,000 bits/sec / 40 bits/code = 6250 codes/sec

2^40 = 1,099,511,627,776 possible codes / 6250 codes/sec ~= 175,921,860 sec ~= 5.578 years

While this is still an extremely long time for the worst case, by the looks of other comments, as well as the author's video, it appears extremely doubtful that most RFID readers have anywhere near 40 bits of security - and it takes about 10 seconds (65536/6250) for the fuzzer to brute force all codes 16 bits or less.

Shoot you're right, it's kHz not Hz haha I'll update my comment.

Darn I don't think HN is letting me update my comment.

It will be and most software on the other end likely isn't prepared to even read tags at that speed. Fun hack though.

125kHz is the transmission frequency. It's one of the unregulated frequencies for RFID tags, but sort of an industry standard value commonly used in retail products and goats. Most other cattle use tags at 134kHz. NFC is mostly just RFID at 13.56mHz.

RAIN rfid uses 900mhz and can be read from 30+ feet away

Wouldn't the readers be designed against this sort of attack?

One would hope.

The small amount of IT security work I've done has taught me that such hopes are quickly and frequently dashed. Even products specifically designed for security applications have silly glaring vulnerabilities.

20 years ago I laughed myself silly when I realised our new big radiocontrolled doors to the factory had 8 dipswitches to set the security code for the remote. Last month I was looking for some home-alarm system for the club house. I wasnt terribly surprised to see only 4 bit security code in some of them...

The high-end MIFARE-based systems would be - there's actual crypto happening between the reader and card, no way to bruteforce that.

However most keycard systems in the real world use a dumb unencrypted card that broadcasts an ID. This is vulnerable to sniffing, cloning as well as bruteforce (as this project demonstrates).

Those interested can read more https://security.stackexchange.com/questions/158167/mifare-d... here.

Modern fare systems (Vancouver Compass for example) use the DESfire EV1 and it's as secure as it gets.

Assuming they're using it properly. I remember cracking a Mifare Ultralight based bus fare system. It seemed sound as the Ultralight had write-once blocks or blocks that you could decrement depending on the card's configuration, so you could make it that a block has the number of trips remaining on the card, each time you validate the card it decrements it and there was no way to increment it.

The issue in their case was that 1) they didn't set the configuration of the card properly, so the blocks they were using weren't actually configured to be decrement only, and 2) the validation machines checked whether a card had enough trips and then decremented the block without checking whether the decrement was successful. I was able to make the remaining fares block read-only while the card was full, essentially making an infinite card.

As far as I am aware there's nothing on the Compass cards, just an id so it's impossible to do much about it. If you lose it, you can get a new one with balance intact which is telling.

Seems it would be better to use a pseudorandom number generator to just test a random selection of tags

I found the following interesting.

Using a curtain capacitors combo might initiate a DoS attack on the reader which will prevent legitimate tags from being read correctly after placing it against a reader only once. A hard reset to the reader will be required to resume work. Just FYI.

Seems like a cute way to create a diversionary scene or frustrate physical security personnel in physical pen testing.

Why bruteforce when you can just passively listen for a working code (once someone else uses their card)?

40 bits of bruteforce at 125khz, with every code being 40 bits long, results in 3125 codes/sec at best, thus it will take roughly 11 years.

They include a video of a parking garage being opened after just a few iterations. The code used in commercial applications could often be lower bits given criminal prosecution is a larger deterrent than code security. Although, OP may have set a specific range for that demo.

Wonder if there's some sort of low-power hardware-easy problem you could use to reduce the request rate for individuals, instead of just shutting the device down when it detects a brute-force attempt. Seems to me that having hardware that breaks inconspicuously means you can't leave it as unmanned as you'd want to.

With these kind of systems (like a parking meter) you could add a 2-3 second delay between each attempt. Most people wouldn't notice the slowdown, but it would make brute forcing so slow that it would be useless in the field. This also works for things like logins on websites where the time taken to authenticate can be a second or two without annoying the user (vs loading a page which should be instant).

There is absolutely no reason why anything RFID controlled, like a door mechanism, should allow key entries at full speed (3k keys/sec someone posted).

It's usually easier and faster to get the sniff of the communication between MCU and the reader(UART,I2C,SPI,USB) in some cases you've to dump MCU's flash or EEPROM to get an idea about the keying scheme used in particular product range.

This made me wonder if iOS 11's CoreNFC API can be used in similar ways. It would be cool to consolidate my tags (building and office) if they speak NFC.

You can do this with some cards/tags with rooted Android phone(some tweaks are needed in the NFC subsystem) with certain NFC chipsets. It needs to be card with broken crypto (Mifare) so you can obtain the password and then copy complete card's content. The door reader shouldn't rely on the card's UID (unique serial number) as this can't be spoofed, the chipsets doesn't allow this.

I don't waste time with closed systems, so I can't comment directly on iOS capabilities, but I would guess, that it's going to be almost impossible to make it working in such locked down iOS world.

What Android versions/handsets/tweaks/etc do you recommend for NFC work?

I haven't seen any word on that yet, but it would likely require iOS 11 to be jailbroken. I only know of one jailbreak project that supports NFC on iOS, and only on iOS 10.

http://cydia.saurik.com/package/net.limneos.nfcwriter/

Description Supports iOS 10.0 to 10.2

NFCWriter for iOS!

$3.99

Use your iPhone's NFC Chip to its maximum!

As pre-seen in 9to5mac

Features:

-Read most common tag types

-Write tags

-Host Emulation Mode with limitations for now

-Manage and save your tags in one place.

-Perform actions based on your tag's contents.

-Read/Write NDEF messages

-Display information about your tags like Manufacturer, Tag Type, Serial Number, ATQA, SAK, Memory Size etc.

-Supported tag types are ISO 14443, Mifare , ISO 15693 , iCode SLIX, all of the NTAG series.

-Supported protocols are ISO 14443 and Mifare.

-Host Emulation Mode currently only allows you to set a custom Serial Number to your device and emulate a tag's serial number, no tag content emulation yet.

This new achievement enables you to use the NFC chip beyond iOS's limitations.

A professional must-have tool for IoT experts, NFC researchers, hobbyists and all of you that make good use of NFC technology.

Research for more Tag types and protocols is constant.

This is the first time that NFC chip on iPhone is used to this extent.

Check the screenshots and... Enjoy!

Limitations: - Supported devices are iPhone 6S, iPhone 6S Plus, iPhone SE, iPhone 7, iPhone 7 Plus. - iPhone 6 is under testing and not yet supported. - iOS 10 only for now, still working on iOS 9 compatibility.

CoreNFC only allows for reading, not writing.

Reply on news.ycombinator.com