Mert, Brian, nice reporting!

HID should do better in responding and dealing with this. For example, here is how they market Signo:

At the same time, Signo's "standard profile" is to enable cracked 125 kHz, which, for at least the last year, also allows "secure" SE / Seos credentials to be copied and exploited by this downgrade attack.

So it's only multi-technology credentials on a multi-technology enabled reader? Cloning a prox credential isn't really new.

This potential security issue is present in a lot of multi class card readers. We have begun working with the manufactures to disable all unused formats in the field to safeguard against this. We have noted that HID will not allow you to field disable the Bluetooth component in the field and quite a few high security installations will not allow any type of Bluetooth or NFC to be present at the card reader, not just disabled, but physically present.

There is nothing revolutionary here. This has been a known issue. HID has always told us to turn off unused technologies to decrease the attack area.

Um, duh... I wouldn't even call this an attack. I am more shocked that you are presenting this as "new," and isn't common knowledge. This has been an issue or a vulnerability since 13.56 was introduced. I wouldn't even blame HID since they tell you to turn off what you aren't using. I agree they should turn it off by default, but I am sure they don't want the million tech support phone calls. I would blame the integrator for being too lazy and always selecting a multiclass reader because it's convenient and the techs and engineers for not knowing or being taught.

Are Seos Elite Keys vulnerable like Seos standard keys for this?

That's why we use SEOS only readers. And why HID has SEOS class readers. Old news.

I completely disagree with the commentary that HID is "defaulting" to enabling legacy technologies.

For people who pay attention, HID literally sells SEOS-only or high-frequency-only readers for less money than they sell the LF-enabled readers. Their online configurator shows this, and they specify the SEOS-only readers as "best-in-class security and privacy protection." They've also made it substantially easier to properly select only the technologies that are needed with Reader Manager on the Signo readers.

There is only so much they can do to lead people to where they should go.

If you knew the bit structure of any credential format and the data, you could write it to the D1 and D0 using something like an Arduino/PI if using weigand. You could use an Arduino/pi and make a skimmer installed behind the reader or any place you could get access to the wiring skimming the DO, D1. All you would need to do is pop the reader off the wall and about 1 minute of time. This was added to the Social Engineering Toolkit as early as 2010 called teensy hid. We still haven't gotten everyone including integrators to OSDP, this is like trying to blame HID if you still use Wiegand. Or not telling you what could happen if you didn't use the tamper

Thanks for the feedback on Kevin Mitnick and other information about the history of this attack.

We've added the following section up top to contextualize the attack better:

Risks Significantly Rising

While this attack has been known amongst some hackers and cybersecurity specialists for many years, this has significantly increased as a practical problem, in the past 18 months, as the attack has essentially become productized, with the Flipper Zero using the Seader App, the iCopy-X using an ICS decoder, and an online/mail order service, MrKeyFob, making this easy to do even for non-technical users.

Despite this, HID's self-described "standard profile" defaults to allowing this attack to be executed even against SE and Seos credentials.

Why are manufacturers still supporting 125kHz Prox?

It should have been EoL DECADES AGO.

If the big players stop supporting it, we may be able to move on from a tech that was hacked in the 80s.

8-Track = Dead

VCR = Dead

Mullets = Comeback?

But not Vinyl LOL Sorry I could not resist.

Something that the industry needs to really pay attention when it comes to using 125kHz and unsecured 13.56MHz CSN card readers is the Flipper Zero device.

This device can not only read and store UIDs from several card technologies, it can replay them to a reader mimicking a valid credential.

We were able in our lab to successfully copy and replay all 125kHz formats we could get our hands on like HID Prox, AWID, Indala.

in addition, we were able to read and replay MIFARE Classic CSN, Desfire CSN and other 13.56MHz ISO/IEC 15693 credentials out of the box. We were not able to read SIO secure sectors on those cards. We were not able to read iClass or SEOS CSN or SIOs either.

Understanding they are scenarios where the customer faces a huge lift trying to replace legacy card technologies, it is my humble opinion that security integrators have the responsibility and is in their best interest to let customers know the risks associated with using these legacy technologies.

MrKeyFob claimed to IPVM that they do not downgrade the card to 125 kHz, therefore allowing the exploit to work with only 13.56 MHz enabled SE / Seos readers. However, we believe, the MrKeyFob is mistaken or deceptive since no known technique for copying SE / Seos cards exists

If MrKeyFob has the HID encoder, which I suspect they do if they're claiming they don't downgrade credentials, they can easily make duplicate SE/Seos credentials, as long as the site is not using an Elite key.

This would have been good to mention in the article - this is not just a problem with downgrading to 125 kHz. For sure, downgrading to 125 kHz is the easiest method for script kiddies who are just doing this with a tutorial online - so disabling 125 kHz on your readers is a good idea to lock those people out.

But disabling 125 kHz on your reader, or buying readers without 125 kHz, does not make your site immune to credential duplication, even with SE/Seos. Regardless of how high security your credential technology is, your site will NEVER be resistant to credential duplication without an Elite/private key.

Interesting question:

What's stopping someone with ill intent from using the copied cred and pulling the HID Ghz reader off the wall and hooking up a 125mhz reader as a bypass? This assuming Wiegand is being used (which is still the dominant protocol in use even with 13.56Mhz readers) Yes, granted it's more work but in the scheme of things fairly easy. The false sense of security with high end locks on such doors is thought provoking...

Report from IPVM last month

Researchers Sensationalize OSDP "Badge of Shame" Risks

Researchers showed that OSDP's encryption could be defeated by (1) physically getting to the wires connecting the reader, (2) installing a device onto reader wires, (3) triggering a new handshake / installation mode allowing the attacker to intercept the key and finally (4) creating a credential based on the intercepted key to open the door of the facility that you are already inside.

However, the exploitation overestimates the risk. To take advantage of the vulnerabilities, additional devices must be installed, which will generate reader tamper warnings, and discovering/removing this when following up on these warnings would stop the exploit. The technical skill required to install and use the resulting data gained is relatively high and specialized and not typical of someone seeking to gain unauthorized entry.

Note, I've updated the title to include 13.56 MHz.

The commenters here certainly understand the distinction between a 125 kHz only attack / cloning and what we are discussing here but I think some others are conflating it so I want us to be clearer about the relationship of the 2 frequencies involved here.

Hello Brian and Mert!

I’m so happy to see more people in the industry talking about subjects I feel very passionate about. I know how much you folks have been striving to move the needle in the industry for what it’s worth, thank you!

I shared some thoughts on this already on LinkedIn but for the benefit of those who don’t time to look everywhere, I hope you’ll forgive me sharing it here as well.

As some others in the comments have pointed out, this is not a new issue, and many others before me have raised this as an issue.

I have been speaking about this issue publicly and privately with manufacturers, integrators, customers, and other professional hackers for about 10 years now. I would love to share some insights I have learned over the years to add to what you’ve shared and help close some gaps:

1. This is NOT an “HID problem.” It’s an EVERYONE problem.

Not only is this challenge not specific to HID, I feel it is disingenuous to label it as such.

It is the ugly combination of backwards compatibility, interoperability, and the cultural inertia of the Wiegand-based credential.

This is an industry problem, it’s an integrator problem, it’s a customer problem, it’s a culture problem, and above all else, it’s a business problem. Let me elaborate.

For about 40 years the security industry and its customers have been building a vast, sprawling catalog of security infrastructure built on top of John Wiegand’s very innovative but very limited foundation. Even when Wiegand swipe cards came out in the 80’s, they weren’t “secure” in any technical sense. They were simply convenient. Anyone who wanted to “clone” a Wiegand card could simply dissolve an existing card in acetone and tape the wires onto a piece of cardboard to make a clone of a card.

When 125kHz proximity-based technologies hit the scene, an important question was asked by each and every customer. A question that has been asked since the dawn of currency:

How much will this cost me?

Well, let’s see. First, we have the reader costs, the credential costs, the door controller or Access Control Unit (ACU) costs, the software licensing, the installation, post-migration reconfiguration, tech support…it goes on and on. Even if there was no additional cost to more “secure” parts, any iota of additional logistical complication will result additional business costs being borne by the customer.

More secure solutions have always been available, and always will be. However, until someone is willing and able to make a suitable product that ticks all the usability, interoperability, functionality, and financial tick boxes for a price and performance that customers are willing to pay for, this problem will remain.

Case in point: How many folks reading this right now know that locks can be picked, and that those ubiquitous 4-pin “Master Lock” brand locks offer somewhat limited security? My guess is that save for a minor rounding error, that’s going to be 100%. I’ve demonstrated my fair share of sub-1-second opens on stage a number of times over the years. What about the average lay-person on the street? I wager over 90% have heard of these locks being picked easily or watched it on YouTube. Has there been a massive recall or a huge scandal? Has Master Lock’s business tanked as a result?

Of course not. Those locks are selling like hotcakes at nearly every hardware outlet online and in-store. Not only that, but there are also even cheaper variants with even worse performance.

So let’s bring it back to the issue at hand. What does this have to do with PACS readers and migration modes?

Most businesses don’t exist for the sole purpose of building variants of Fort Knox. They exist to make money. To the select few vendors selling security equipment, security is a profit center. To almost everyone else in the world, security is a cost center. The business doesn’t exist to serve security. Security exits to serve the business.

As long as it costs more money in parts, labor, logistics, and upkeep to be “more secure”, we’re going to see customers choose “secure enough” time and time again. And why not? Why would anyone spend more than can be justified?

As HID Global President and Chief Executive Officer Björn Lidefelt famously never said, “It’s all about the Benjamins, baby!”

2. The HID SE and Seos credential containers are not being compromised here.

Within the scope of the topic being discussed here, the problem has nothing to do with iCLASS SE and Seos credentials. This problem exists with literally EVERY SINGLE READER that supports a migration mode of any kind. Credential technology is simply a container. This technology is simply a very small, sometimes very poor quality, memory device and container.

What are we storing inside those containers? 100% pure, uncut premium Wiegand, baby. As long as the ACU-side authentication is tied to the humble static binary string that is a Wiegand bit format, facility code, and card number, the problem will remain. Nearly every new technology we’ve seen gain traction thus far simply adds additional layers of tape and/or paint on top of that Wiegand data..

3. Migration readers and credentials employing “customer-specific” or private keys remain vulnerable.

Yes, that can include “Elite” keyed readers. Remember, this is NOT an attack against iCLASS SE or Seos specifically. This is an attack against the mere presence of migration mode. Even if you have a super-special-Secret-Squirrel authentication key for your credentials, in most cases that key has to be stored and used by every other reader in the system. So what’s preventing Johnny No-good from smashing a reader off an exterior wall with a hammer and using that to read Wiegand data off customer cards?

What about a more elegant attack? What if I replace a private-keyed reader with a stock one? How many VARs can honestly say they would actually inspect the reader to see if it had been swapped? How many VARs would quite reasonably assume the reader failed and simply replace it without a thought?

Once the Wiegand data is identified, the game is mostly over. All that remains is finding a way to re-encode that data into a fresh credential. Sometimes this can be done directly by the attacker. Other times it may be done by ordering matching credentials from the manufacturer.

4. The downgrade problem has nothing to do with 125kHz credentials.

The problem is what migration mode itself is. If your 13.56MHz-only reader reads any kind of credential technology that can be arbitrarily encoded by a third party for any reason, you are at risk. Simple as that.

It just so happens that 125kHz credentials are some of the oldest, fastest, cheapest, and most popular credentials out there.

5. There are well more than only 3 ways to exploit.

This is certainly a fine nit to pick, but I feel that the phrasing in the article seems to imply that there are primarily three ways to exploit this phenomenon. To me it feels not unlike saying there are three ways to drink water: Go to your nearest Aquafina vending machine, melt some ice, or for the easiest experience, order it on Amazon. Sounds silly, doesn’t it?

The tool to read the Wiegand data is ANY READER THAT READS THAT CARD. No third-party service, special tool, or knowledge is required. Hook it up to an Arduino, an ESPKey, or favorite PACS ACU and look at the data log. It doesn’t matter.

It’s really important to underscore here that none of the tools or materials needed to do this are new.

6. Mr. KeyFob is being deceptive, but not about HF vs. LF credentials.

Anyone who purchases an official HID CP1000D encoder can create their own SE, Seos, or DESFire credentials with no secret sauce required. I’ve got a bunch of these encoders here in our office, and so do a number of our clients. Even where an OEM encoder doesn’t exist, there is little stopping someone from just ordering a pack of 50 or 100 cards that contains the card numbers in question. The best one can hope for is that the vendor honors their promise not to sell your super-special-extra-corpratey-10000000 format to another client.

7. The “ICS Decoder” is a plain, no-frills HID R10 SE mullion style reader.

There are no modifications to the reader itself. The purple board you see on the back just takes the Wiegand output from D0/D1 and pipes it over to the iCopy-X. It doesn’t do anything you couldn’t already do with a keyboard wedge from RFIdeas. No magic.

8. I agree with HID’s response.

Those who know me or who have come to any of my trainings at Red Team Alliance or Black Hat know that I don’t pull punches when it comes to any vendor’s complacency. That includes HID Global.

These are legacy technologies. They sell them because customers want them and buy them, plain and simple. The why has already been belabored in point 1 above.

I want to be clear, I disagree with a great deal of the engineering, marketing, and business choices HID Global has made over the years. However, in this case it’s important not to conflate technical details and fact.

9. The “legacy technologies” are only default-enabled on specific SKU’s.

Vendors will always sell what people are willing to buy. As HID’s How-to-Order Guide has detailed for years, any Value-Added Reseller (VAR) or customer can simply order a part number that doesn’t have these technologies pre-enabled.

Why do most VARs still stock the catch-all SKU? In my own opinion the answers are obvious, but I’ll let folks respond in the comments.

I’ve been working as a professional researcher and technical adviser for years, and I’ve lost track of the number of times I’ve received pushback from an end-user’s VAR when I’ve specified non-standard SKU’s.

As such, I don’t find it fair or reasonable to put so much blame on HID, regardless of how big and easy of a target they may seem.

10. Disabling legacy credentials is not enough.

I know, I know…this last one sucks. It sucks especially hard because there is little you can do about it for most existing installations.

Why is disabling legacy not enough? Because I can use the same mechanism to re-enable it.

I too, can defeat tamper-detection mechanisms. I too, can power cycle-a reader to allow it to accept a configuration card. I too, can use a configuration card or app to re-enable those legacy technologies.

Heck, if the ACU isn’t running a well-configured iteration of OSDP v2 with SCP, I can also just swap in any reader of my choosing and roll with my own credentials. Beginning to see the problem?

For those who have some time to burn, here is an example of an old talk where I touch on this topic:

YouTube

I touch on issues surrounding migration mode at time marker 34:50.

Bonus point:

11. The solution is true challenge-response based technologies such as PIV.

I know that last point is going to raise some eyebrows and ruffle some feathers, but I am confident I can make a believer out of you as well. I won’t take up more valuable screen space here, but come find me at ISC and we’ll chat. Solutions to a lot of your pain points are in the works.

Finally, if anyone has any specific questions, concerns, or comments, please don’t hesitate to reach out on LinkedIn.

Thank you again to the IPVM team for joining us in shedding light on this issue!

We have updated the title to reflect better that HID's Standard Profile make credentials vulnerable to the downgrade attack.

HID Standard Profile Makes 13.56 MHz SE / Seos As Vulnerable As Cracked 125 kHz For Downgrade Attack