'Devastating' bug pops secure doors at airports, hospitals
theregister.co.uk
theregister.co.uk
Let's see.
- IIRC, many (most? half? not really sure) HID devices use no crypto whatsoever. The tags simply tell the reader their serial number.
- A bunch that do use crypto use a homebrewed algorithm that's entirely broken. (See, for example, http://www.openpcd.org/HID_iClass_demystified).
- AFAICT, HID doesn't like to talk about their actual protocols. That rules them out for serious use in my book.
IMO the right way to do keyless entry is to use SIA OSDP Transparent Mode [1] readers and some very simple software to authenticate something like a Yubikey NEO or a Mifare DESfire at the other end. (The high-end DESfire devices are cheap and use real crypto.)
(Of course, big customers still use HID and RSA, because no one ever got fired for using an expensive product from a well-known big-name supplier.)
[1] A fancy name for an open protocol that lets you gasp exchange plain ol' APDUs with a card via a reader that speaks the protocol. Of course, this is so amazingly brilliant that HID's parent company claims to have patented it. Someone should file for ex parte review. (The patents are, AFAICT, https://www.google.com/patents/US6575360 and https://www.google.com/patents/US7853789. These are IMO about as obvious as patents get.)
1) HID Prox is quite old, and while still in common use it shouldn't be used in any new installations for a number of years now.
2) The situation was the same for other digital lock systems of the period, such as the now largely forgotten Marlok and the Secur-a-key. HID Prox basically just predates a challenge-response scheme being technologically feasible. Unfortunately, the intersection of Prox with later RFID technology makes it easier to duplicate Prox keys than these other types (the other types would just require specialized jigs to duplicate)
Today, HID sells a number of systems using different protocols. However, they have both DESFire and SIA compliant products - in fact, as you hint at, HID was one of the original developers of the OSDP protocol and (along with their collaborators) assigned it to SIA.
I'm not necessarily defending HID, as the company has made a huge number of missteps over the years and it looks like that's not stopping now. However, most of the old complaints about HID products are no longer true and they sometimes get an unfairly hard rap - for example, HID's decision not to change the physical case design of their keys over the years (which is useful to their customers who have invested in tooling) has lead a lot of people to believe that all HID systems are Prox systems, which is not true. Of course, I would argue that selling new Prox systems at all at this point is a huge mistake - and you can still buy new Prox systems from HID, although I'm sure they'll try to upsell you to their OSDP-compliant iCLASS system.
EDIT: As a further note in HID's defense, one of the big problems with HID products is that their catalog line-up is really, really confusing to interact with from a security perspective. If you buy an iCLASS system, for example, there's still a half-dozen different actual protocols that could be used to do the card authentication. It can get very frustrating very quickly. There are two big reasons for this, though. The first is that HID tries very hard, perhaps too hard, to allow customers to upgrade without having to replace all of their equipment at once, so most HID systems are designed to interoperate with many older systems. The bigger reason though is that many HID systems are designed to very specific requirements from the federal government and other parties, and these requirements are often confusing and contradictory. That's a problem you'll see a lot in the enterprise security space: systems that are really confusing because they are exactly FISMA, FICAM, F-whatever compliant.
> "A command injection vulnerability exists in this function due to a lack of any sanitisation on the user-supplied input that is fed to the system() call," Lawshae says.
This looks like the latest in "internet of things" idiocy. Things that were once simple, but which now inexplicably run Linux.
This is how you get critical security failures from an "LED blinking lights service" or a home thermostat that bricks itself one morning after an auto update.
Its also how you get cars that can be crashed by a 4chan troll 1000 miles away, over the network, because of a bug in the entertainment system.
http://www.wired.com/2015/07/hackers-remotely-kill-jeep-high...
Just Say No to needless complexity. Just because you can give your fridge an IP address doesnt mean you should.
The clutch serves as a wonderful dead man's switch.
I never learned to drive manual. I'm ready to play on my iPhone while my Auto drives me to/from work daily.
Just for reference I own an automatic and I'm quite happy with it.
Is that because they have any technical comprehension of it or because they want everyone else to swoon?
I'm not sure that a different OS would necessarily prevent stupid errors like this one - the exploit would just be less obvious.
I may be oversimplifying things. Or maybe I've just reinvented old-fashioned embedded circuits, which still work fine but are out of fashion because devs want to work with their familiar tools.
The paperclip creates enough of a gap to weaken the magnetic hold such that if you put your shoulder into it, you can pop the door open.
This backdoor is virtually undetectable, because the door still operates normally, and no one thinks to look directly at the magnet (except for me, which is how I discovered this trick).
People did this so they don't have to get their friends by going from their room to the elevator or stairs.
Even a tiny piece of paper would keep the LED from going green. Same with a slightly misaligned plate on the door. Pain in the ass since our controllers would not show the door secure until it was perfect.
As opposed to paying a pickpocket $50 to swipe a HID card from any of a thousand employees. Or, I dunno, using a passive reader to clone any of them from across the parking lot. Both of which are less traceable than, say, a spear-phishing malware attack.
http://qz.com/649996/one-in-five-employees-would-sell-their-...
All those IPs are on networks behind doors.
The door refused to open. It said, "Five cents, please."
He searched his pockets. No more coins; nothing. "I'll pay you tomorrow," he told the door. Again it remained locked tight. "What I pay you," he informed it, "is in the nature of a gratuity; I don't have to pay you."
"I think otherwise," the door said. "Look in the purchase contract you signed when you bought this conapt."
...he found the contract. Sure enough; payment to his door for opening and shutting constituted a mandatory fee. Not a tip.
"You discover I'm right," the door said. It sounded smug.