HN's Daeken will expose security flaw in 4m hotel room keycard locks • Hacker News Board

Re: HN's Daeken will expose security flaw in 4m hotel room keycard locks

#81

Post by wheelerwj » Mon, Jul 23, 2012, 7:43 PM UTC

daeken wrote: post #73

wheelerwj wrote: post #70

so reverse engineering seems cool. What skills do you find most useful/versatile/neat/groovy or otherwise necessary for your reverse engineering projects?

I can't really narrow it down to a single specific skill. When I'm reversing, my steps are generally: figure out how I would design the system, come up with a set of assumptions based on that, check the assumptions as quickly as possible, then refactor your model of the system based on what you find. It's really all about making educated guesses and then checking those; as you gain experience, you start making better…

okay very cool. the scientific method, rinse, repeat. how long have you been reversing?

Re: HN's Daeken will expose security flaw in 4m hotel room keycard locks

#82

Post by thornofmight » Mon, Jul 23, 2012, 7:43 PM UTC

How did you practice this and discover it? I can't imagine just wondering around hotel rooms playing around with the doors...

Re: HN's Daeken will expose security flaw in 4m hotel room keycard locks

#83

Post by st3fan » Mon, Jul 23, 2012, 7:44 PM UTC

daeken wrote: post #12

screwt wrote: post #11

Could you explain a little more why you didn't go for responsible disclosure to Onity? In the article you suggest that you don't think they could fix it. Maybe true but shouldn't you (a) give them the oppurtunity to try (just cos you can't spot the fix doesn't mean it's impossible), and (b) give them the chance to say "yep, it's broken - give us 3 months to ship out new locks to all our customers" (yes, highly unlike…

Given the simplicity of the vulnerabilities (as mentioned in the article, you have full and unauthenticated memory access) and the length of time -- over a decade -- that these locks have been on the market, there is absolutely no doubt that they knew about this. Given that, I felt that they would delay, delay, delay, and delay some more before finally going silent, at which point I would be forced to do this anyway.…

You are acting on assumptions. If you actually talk to them first you will find out what will really happen.

They might actually have a way to deal with this. Maybe the only thing they need is some time.

Re: HN's Daeken will expose security flaw in 4m hotel room keycard locks

#84

Post by daeken » Mon, Jul 23, 2012, 7:45 PM UTC

javajosh wrote: post #80

daeken wrote: post #44

Earlier quoted context omitted.

The locks are programmed by the front desk, but then the data is transferred to the Portable Programmer which then is used to update the doors. The doors themselves are not connected to power, but are rather completely battery-driven. The likelihood of anything impacting the front desk equipment is effectively nil. (Note: This is all specific to Onity locks)

I'm surprised that's how they are designed. How often do the batteries need replacement? (I realize that this isn't exactly related to your hack, but I'm finding myself fascinated by the economics of maintaining lots of locks. It reminds me of the problem of early computers having to replace vacuum tubes at a certain rate, limiting the size of the machine). Also, is it the housekeeping staff that reprograms the lock…

The battery lifetime depends on how much traffic the door gets, but generally I believe it's 4-6 months, which is pretty impressive for 4 AAs.

As for reprogramming the doors, that only happens very rarely. The cards have an expiration date and a code that cycles, meaning that when a new card is introduced, the old ones won't work anymore. So really it only needs to be reprogrammed when the clock gets out of sync or the batteries die (there's no non-volatile storage, just RAM).

Re: HN's Daeken will expose security flaw in 4m hotel room keycard locks

#85

Post by bradfa » Mon, Jul 23, 2012, 7:45 PM UTC

javajosh wrote: post #41

I was always curious about elock systems, particularly about how they are reprogrammed. Presumably they are reprogrammed by the front desk, centrally, but how does the signal reach the lock? Presumably there must be wires attached (at least for power). So why is there an external port on the lock at all? Also, what is the possibility that a lock exploit could affect the central reprogramming system? Edit: just read b…

how does a hotel not go bankrupt replacing thousands of batteries all the time?

A microcontroller in sleep state (or similar) draws extremely low power, micro or nano Amps. It only wakes up when it sees data on the card reader, reads the card reader data, and decides if it should open the lock. The motor that unlocks the door only runs for less than a second. Then the whole thing goes back into sleep state.

Hotel doors are only opened 10s of times per day, at most. A pair of couple Amp-hour batteries will last quite a while. Maybe replace them once a year. Tech with an electric screw driver maybe takes 1 minute per door, even a 600 room hotel only costs 2 days of labor once per year (max 1 week, if the tech is slow). That's not that expensive. And the tech's time is 10x the cost of the batteries, coin cells in bulk are dirt cheap.

Re: HN's Daeken will expose security flaw in 4m hotel room keycard locks

#86

Post by daeken » Mon, Jul 23, 2012, 7:47 PM UTC

thornofmight wrote: post #82

How did you practice this and discover it? I can't imagine just wondering around hotel rooms playing around with the doors...

I was working on a replacement of the Onity front-desk system at the time, and I suspected it existed for a while. In another comment I detail how I reversed everything, but everything was done on my own hardware, not just random hotels.

Re: HN's Daeken will expose security flaw in 4m hotel room keycard locks

#87

Post by daeken » Mon, Jul 23, 2012, 7:48 PM UTC

wheelerwj wrote: post #81

daeken wrote: post #73

Earlier quoted context omitted.

I can't really narrow it down to a single specific skill. When I'm reversing, my steps are generally: figure out how I would design the system, come up with a set of assumptions based on that, check the assumptions as quickly as possible, then refactor your model of the system based on what you find. It's really all about making educated guesses and then checking those; as you gain experience, you start making better…

okay very cool. the scientific method, rinse, repeat. how long have you been reversing?

About a decade now, probably. Started with MMOs, specifically Everquest, then moved on to DRM (which, oddly enough, is what I was in Forbes for last time), then on to locks and other hardware.

Re: HN's Daeken will expose security flaw in 4m hotel room keycard locks

#88

Post by m0nastic » Mon, Jul 23, 2012, 7:49 PM UTC

st3fan wrote: post #69

I think that making this public is not a very good example of responsible disclosure and I hope there will be a lawsuit before the presentation to prevent the details from being exposed. I am all about exposing vulnerabilities but I honestly think there needs to be a dialog with the vendor first. Specially for exploits like this where there is a lot at stake. I find the excuse of 'there is nothing they can do anyway'…

This argument has been going around for as long as I can remember, and I think it's incredibly harmful to researchers (whether they be security or other).

Upon discovering the vulnerability, the only real action he could take which would be universally considered unacceptable would be to use that research to go around breaking into hotel rooms (which is illegal).

If he decided to go into business selling devices to bypass hotel room locks, there would also probably be a majority opinion that that isn't really "above-board". Even that isn't necessarily universally agreed on though (as there are a lot of people who argue that providing access to tools isn't criminal)

But he didn't do that either.

He decided that this was a pretty severe vulnerability (made worse by the fact that remediating it isn't trivial), and that he wanted people to know about it.

Hoping that the vendor will sue him to prevent that information from being disseminated is about the worst possible outcome from research of any kind; ignoring the fact that you don't seem to posit any rationale for what exactly they'd be suing about (protected trade secrets? violation of a license agreement?)

The thing about "responsible disclosure" is that it isn't something that exists by fiat. It's an intentional reframing of disclosure policies by vendors to attempt to steer the research community towards doing what's in the vendors best interests.

I understand their desire to reframe that policy, but that doesn't make it "the only ethically responsible way to conduct vulnerability disclosures".

Recently, there's been a lot of news about BMW's being able to be stolen trivially through access to the OBD port on certain models. There's an OSVDB entry for it and everything‡.

That's another example where providing information to the public was considered to be very important (like the issue Cody discovered, it's also not something that can be easily fixed. It's also been ignored by the vendor).

In virtually all other regards, making research public is considered the responsible thing to do.

While I'm not a card-carrying member of the full-disclosure sentiment, I strongly disagree that releasing research publicly is boolean irresponsible.

‡ http://osvdb.org/83707

Re: HN's Daeken will expose security flaw in 4m hotel room keycard locks

#89

Post by mrb » Mon, Jul 23, 2012, 7:59 PM UTC

daeken wrote: post #9

shimon_e wrote: post #7

Earlier quoted context omitted.

Do you kindly mind only leaking the information on Friday? Thanks from all us who spend our weekdays living in hotels.

Regardless of which hotel you're in and what locks they use, always use the physical security mechanisms provides, e.g. door chains. Deadbolts are engaged by the lock mechanism and will be retracted by, say, maintenance key cards. While this definitely opens up new bad things, the message is the same: don't trust the software, trust the physical. Then again, after doing this for a few years, I may be a bit on the par…

"always use the physical security mechanisms provides, e.g. door chains"

Sliding chain locks which can be defeated with a rubber band... :-) http://www.youtube.com/watch?v=7INIRLe7x0Y&t=60s

Re: HN's Daeken will expose security flaw in 4m hotel room keycard locks

#90

Post by mr1976 » Mon, Jul 23, 2012, 8:04 PM UTC

daeken wrote: post #84

javajosh wrote: post #80

Earlier quoted context omitted.

I'm surprised that's how they are designed. How often do the batteries need replacement? (I realize that this isn't exactly related to your hack, but I'm finding myself fascinated by the economics of maintaining lots of locks. It reminds me of the problem of early computers having to replace vacuum tubes at a certain rate, limiting the size of the machine). Also, is it the housekeeping staff that reprograms the lock…

The battery lifetime depends on how much traffic the door gets, but generally I believe it's 4-6 months, which is pretty impressive for 4 AAs. As for reprogramming the doors, that only happens very rarely. The cards have an expiration date and a code that cycles, meaning that when a new card is introduced, the old ones won't work anymore. So really it only needs to be reprogrammed when the clock gets out of sync or t…

hotel IT here: they last for between a year and 18 months and are generally replaced as part of a fixed maintenance cycle (floor by floor over a period of 2 or three months).