Hotel-room hacks: Picking the lock • Hacker News Board

Re: Hotel-room hacks: Picking the lock

#31

Post by samstave » Fri, Sep 14, 2012, 2:49 AM UTC

daeken wrote: post #9

tzs wrote: post #2

> The hacker did not explain the flaw to the company in advance of revealing it to the public, a decision he told Forbes was because he saw "no path to mitigate this from Onity's side." To fix the problem, the locks' entire circuitboard has to be replaced—and on millions of locks, that's a process that could take a long time. That seems like rather an asshole move on his part. I understand the argument for disclosing…

I've covered this a number of times. Simply put, I felt that the best route for hotel owners and customers (who I care about, unlike J. Random Vendor) was to make them aware of the vulnerability and make them aware that they've had a horribly insecure product on their doors for nearly 20 years. Given how ridiculously simple the vulnerabilities are, I'd put money on many others having discovered them in the past, almo…

Just out of curiosity, how much more secure would a lock be if the hotel asked the patron to have a smartphone app instaled and to enter a personal PIN upon checkin.

When you get to your room, swipe your NFC enabled phone over the lock, then it asks for your pin (on the phone) to unlock the door.

The activity would need to allow you to swipe the NFC over the lock, which will auto-launch the app and prompt for pin to be a smooth user experience.

If you have to find the app and launch it and maybe make another click, to get to the PIN prompt, it would be too cumbersome to users to be a good experience.

Re: Hotel-room hacks: Picking the lock

#32

Post by daeken » Fri, Sep 14, 2012, 2:52 AM UTC

samstave wrote: post #31

daeken wrote: post #9

Earlier quoted context omitted.

I've covered this a number of times. Simply put, I felt that the best route for hotel owners and customers (who I care about, unlike J. Random Vendor) was to make them aware of the vulnerability and make them aware that they've had a horribly insecure product on their doors for nearly 20 years. Given how ridiculously simple the vulnerabilities are, I'd put money on many others having discovered them in the past, almo…

Just out of curiosity, how much more secure would a lock be if the hotel asked the patron to have a smartphone app instaled and to enter a personal PIN upon checkin. When you get to your room, swipe your NFC enabled phone over the lock, then it asks for your pin (on the phone) to unlock the door. The activity would need to allow you to swipe the NFC over the lock, which will auto-launch the app and prompt for pin to…

It really depends on the implementation. There are a lot of ways this can all be done securely (from magstripes -- ignoring the ease of copying -- to chip cards or NFC with smartphones or ...), but at the end of the day, it comes down to the implementation. With some slightly different choices, Onity's system could've been rock solid, but they dropped the ball.

Re: Hotel-room hacks: Picking the lock

#33

Post by jrockway » Fri, Sep 14, 2012, 2:53 AM UTC

sopooneo wrote: post #23

jrockway wrote: post #6

Earlier quoted context omitted.

Don't shoot the messenger. The security hole was there for everyone to independently observe. Not telling the public just meant that the public couldn't take their own countermeasures. Blaming security researchers for finding holes is a very strange anti-pattern. We should be blaming vendors for shipping insecure products!

It's going to happen. Even with full care and diligence there will still be some products shipped with security flaws. It is not ethical to give the company no heads up, not even anonymously.

You're assuming that the security researcher is the first person to discover the issue. That's rarely the case. Keeping quiet just gives users a false sense of security and ensures that they can't mitigate the security impact on their own (without the help of the vendor).

Knowledge is power. We shouldn't censor ourselves because someone somewhere can be evil with some information. They have other ways of getting the information anyway.

Re: Hotel-room hacks: Picking the lock

#34

Post by samstave » Fri, Sep 14, 2012, 3:02 AM UTC

daeken wrote: post #32

samstave wrote: post #31

Earlier quoted context omitted.

Just out of curiosity, how much more secure would a lock be if the hotel asked the patron to have a smartphone app instaled and to enter a personal PIN upon checkin. When you get to your room, swipe your NFC enabled phone over the lock, then it asks for your pin (on the phone) to unlock the door. The activity would need to allow you to swipe the NFC over the lock, which will auto-launch the app and prompt for pin to…

It really depends on the implementation. There are a lot of ways this can all be done securely (from magstripes -- ignoring the ease of copying -- to chip cards or NFC with smartphones or ...), but at the end of the day, it comes down to the implementation. With some slightly different choices, Onity's system could've been rock solid, but they dropped the ball.

can you expand on what would have made it rock solid?

Re: Hotel-room hacks: Picking the lock

#35

Post by daeken » Fri, Sep 14, 2012, 3:09 AM UTC

samstave wrote: post #34

daeken wrote: post #32

Earlier quoted context omitted.

It really depends on the implementation. There are a lot of ways this can all be done securely (from magstripes -- ignoring the ease of copying -- to chip cards or NFC with smartphones or ...), but at the end of the day, it comes down to the implementation. With some slightly different choices, Onity's system could've been rock solid, but they dropped the ball.

can you expand on what would have made it rock solid?

Well, from what I know of its failures:

- Use an industry-standard (for the time) crypto algorithm for cards, and use the biggest key size possible. As it stands, they use a (horrible) proprietary algorithm and 32-bit keys.

- Make the lock know which door it's actually for and encode a list of acceptable lists along with the code key values on the card. This prevents a card from one door from opening another door. Not a huge security issue, but it happens more often than you'd think.

- Use secure, authenticated protocols for programming the lock. This is really the critical part; unauthenticated, raw memory reads/writes are just not OK.

Re: Hotel-room hacks: Picking the lock

#36

Post by huggah » Fri, Sep 14, 2012, 3:22 AM UTC

sopooneo wrote: post #23

jrockway wrote: post #6

Earlier quoted context omitted.

Don't shoot the messenger. The security hole was there for everyone to independently observe. Not telling the public just meant that the public couldn't take their own countermeasures. Blaming security researchers for finding holes is a very strange anti-pattern. We should be blaming vendors for shipping insecure products!

It's going to happen. Even with full care and diligence there will still be some products shipped with security flaws. It is not ethical to give the company no heads up, not even anonymously.

What purpose does this serve? In general, I agree with you, because most vulnerabilities can be fixed by the vendor in some reasonable (This is not such a case; the vendor had no reasonable way of fixing this. Others had probably already discovered (and used) this vulnerability, and in the long term fixing this vulnerability quickly requires motivating the company to do so. Disclosing it privately wouldn't have held much benefit, and might have been detrimental (the company may have tried to use legal means to prevent or penalize the public disclosure).

Re: Hotel-room hacks: Picking the lock

#37

Post by larrys » Fri, Sep 14, 2012, 4:08 AM UTC

jaggederest wrote: post #18

daeken wrote: post #9

Earlier quoted context omitted.

I've covered this a number of times. Simply put, I felt that the best route for hotel owners and customers (who I care about, unlike J. Random Vendor) was to make them aware of the vulnerability and make them aware that they've had a horribly insecure product on their doors for nearly 20 years. Given how ridiculously simple the vulnerabilities are, I'd put money on many others having discovered them in the past, almo…

I appreciate your appearance here. One of the wonderful things about HN is that we often get the facts from the first party source. I also agree about disclosure - it might have been nice to drop them a note beforehand, but what could they honestly do about it? Nothing more than they are already doing.

Well for one thing less people would know about the flaw and potentially be able to take advantage of it.

Re: Hotel-room hacks: Picking the lock

#38

Post by snogglethorpe » Fri, Sep 14, 2012, 4:13 AM UTC

samstave wrote: post #31

daeken wrote: post #9

Earlier quoted context omitted.

I've covered this a number of times. Simply put, I felt that the best route for hotel owners and customers (who I care about, unlike J. Random Vendor) was to make them aware of the vulnerability and make them aware that they've had a horribly insecure product on their doors for nearly 20 years. Given how ridiculously simple the vulnerabilities are, I'd put money on many others having discovered them in the past, almo…

Just out of curiosity, how much more secure would a lock be if the hotel asked the patron to have a smartphone app instaled and to enter a personal PIN upon checkin. When you get to your room, swipe your NFC enabled phone over the lock, then it asks for your pin (on the phone) to unlock the door. The activity would need to allow you to swipe the NFC over the lock, which will auto-launch the app and prompt for pin to…

Er, any system that requires customers to have a particular brand of smartphone, with NFC capability, is never going to happen. Even if it were an option, basing security on this would mean that the 75% of their customers without the required model of smartphone would then be more likely to have their room broken into. Hotels may be kind of clueless, but they're not stupid enough to reject or screw over 75% of their potential customers...

[This is why the frequent suggestions you hear "oh, why can't we replace with a smartphone app!" are so stupid. Optional smartphone support for convenience features = nice plus; mandatory smartphone = idiotic.]

Re: Hotel-room hacks: Picking the lock

#39

Post by K2h » Fri, Sep 14, 2012, 4:18 AM UTC

gvb wrote: post #15

K2h wrote: post #4

Real engineered solution - without new hardware: If this thing is not reprogrammable, and only has an EPROM - do some real enginerering and calculate the ADDITION of bits to set to disable the exploit. Thats the one I would be working on if I worked for Onity. alternativly, take a mechanical approach to the problem - if you can live without the connector for servicing the lock. 1) De-solder the connector on the board…

[D]o some real enginerering and calculate the ADDITION of bits to set to disable the exploit. That is very unlikely to be possible. The ROM may be a masked ROM, in which case it is not re-programmable at all. Quite likely it is a one-time programmable (OTP) ROM. For a OTP, at best you can flip "1" bits to "0", but you cannot change "0" bits to "1". It would take a large amount of luck to be able to patch "1"s to "0"s…

Your comments on the most likely one time programmable ROM are exactly what I was thinking but didn't take the time to write with the clarity you did. We are on exactly the same page there. My train of thought was that if it was possible to patch the boards using only software that would be an awfully nice gesture to the hotel managers to send a technician out for a day and just fix everything at once [although, if you have to rip the lock apart to pull the board to reprogram it, you might as well just drop a new boad in]. My background is in board level manufacturing so the whole special test fixtures to interface and board probing was the easy part to me - solving the problem of hacking a jump instruction to jump to unused memory and then patching the problem there, then jumping back seemed like a really elegant and fun problem to work on.

I didn't look at the exploit in detail, but as daeken reminded us there are problems with more than just the program in the door lock - so even if a patch to the ROM chip could fix the problem, it probably doesn't fix all the problem so it isn't a real solution.

You are right, everything else 1-3 are really just obscurity solutions and not real solutions - thanks for calling me out on that.

Re: Hotel-room hacks: Picking the lock

#40

Post by saturdayplace » Fri, Sep 14, 2012, 4:52 AM UTC

larrys wrote: post #37

jaggederest wrote: post #18

Earlier quoted context omitted.

I appreciate your appearance here. One of the wonderful things about HN is that we often get the facts from the first party source. I also agree about disclosure - it might have been nice to drop them a note beforehand, but what could they honestly do about it? Nothing more than they are already doing.

Well for one thing less people would know about the flaw and potentially be able to take advantage of it.

That's called "security through obscurity," which isn't really security at all. It didn't prevent daeken from discovering the vulnerability, which means it's likely others with more malicious intent also know about it and are keeping the fact quiet. When the problem goes unpublished, unsuspecting customers will continue to trust the locks on their rooms. When published, customers can make more informed decisions about where to stay.