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:
I touch on issues surrounding migration mode at time marker 34:50.
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!