I'm planning on doing a Reddit AMA for reversing in general -- as well as this work -- in the next hour or two, but if anyone has any questions I'll do my best to answer here. All I ask is no protocol details (paper and full code will be out tomorrow immediately following my talk) and no legal questions. Go wild.
Edit: Since this thread has blown up a bit, we may as well just do it here for real. If you have any reversing questions or background questions or whatnot, feel free.
Was it necessary to wear a t-shirt that reads "It's fun to use learning for evil!" in the photo shoot for a Forbes spread? This doesn't help the negative perception of the word "hacker". :-/
All due respect to the work you're doing – I'm a former member of the security industry myself (worked on the IPS engine at TippingPoint).
Counterpoint: I love that you wore it, I think the content of the article makes it hard to come to a negative conclusion (especially the comments about stopping development), and most anything that supports dieselsweeties.com is a good thing!
It's fairly easy to change a T-shirt. Whether or not anyone agrees with his appearance or not being relevant, he wasn't photographed in the audience at the conference or up on stage.
He posed for a photograph in a hotel.
Even if he didn't have a spare shirt, the gift shop in a hotel generally does. That's if he had thought of that issue. No problem with telling the photographer you had to change. Even if they noted that in the story it's the picture that's worth 1000 words.
I had a story done a number of years ago and they sent a photographer to the office. I took several hours to arrange everything to get a good setup for the photo. It paid off. The photo was good and the photo editor liked and made it the centerpoint of a story where many people were quoted. It ran all over in syndication. My point is simply it's important to think ahead when the media comes knocking. (Along those lines hmm, maybe he did the right thing with that t-shirt publicity wise).
In any case people can now learn from the "nitpick" and decide for themselves if they are ever in the spotlight what they want to do.
Forgive me if I'm just naive but I don't get the 'scary' part. Locks have always been 'advisory' and people who have wanted to circumvent them for both good and evil rate them by their 'time to disable'.
Hotel locks with hard keys had their issues as well, and were pretty trivially picked with simple tools. But the key is always that you need to bring the 'simple tools' which is to say that they aren't vulnerable in a way that someone who decides on the spur of the moment to enter the room can easily duplicate. They need the plug that fits the power cord, they need the software which does the JTAG wiggler etc etc.
So if it is 'scary' that people who are not affiliated with the hotel either as guests or as staff can, with pre-meditation, open a hotel room door without damage. Then you need to re-define scary. This has always been true, and will probably always be true by the nature of hotels and motels.
It should be noted that [some] hotel doors with electronic key cards also have physical key holes (as a backup) that are hidden, but are still susceptible to being picked.
This just supports your point that hotel doors are not 100% secure for anyone who really wants to get through.
Edit: Replaced all with some. The doors at the hotels I worked had backup physical keys in case the battery failed. It's cool that Onity locks can be powered externally if the battery fails. Thanks for the correction.
That's not really the case. While some of these do exist, Onity's locks themselves do not contain any physical keyhole and I've never seen them installed in such a configuration. Other vendors may be different.
The most important thing was that you gave it thought in advance! That is good. You had your reason for wearing the shirt it might not be the same decisions others would have made but the decision is yours to make based on what you were trying to achieve.
I mean the vulnerabilities. While my exploit has issues (which, as far as I can tell, are issues with timing when reading data from the lock; I lose the first bit of every byte) it's only a matter of time before someone fixes that and has these rolling off the assembly line. All you need is a microcontroller, a resistor, and a connector; that scares me.
Fair enough, and that's why I attempted to tone down the message with my statement of respect. I've followed Cody's work with interest for years.
I do stand by my general point, though. I think it's worth thinking about how we represent ourselves to the general public. The word "Hacker" has an unfortunate negative reputation, and I don't think messages like this help. It really jumped out at me when I opened the article (otherwise I would have kept this nit to myself).
It's pretty obviously tongue-in-cheek. He doesn't look at all evil (sorry Daeken, you look kind of... Jolly) and any real evil people don't let Forbes take their picture.
Random question: His former employer [..], sold the intellectual property behind Brocious’s hack to the locksmith training company the Locksmith Institute (LSI) for $20,000 last year.
Are these guys "buying up" security flaws in locks similar to others who sell these kinds of things for software?
Don't know what they're doing, quite honestly. Though I should mention that they didn't buy it from us, they got a non-exclusive license to use the technology. Just wanted to clarify.
It's the Locksmith Institute. Locksmiths are who you call to get into a door to something own, but to which you lost the key. So presumably there's situations where a hotel can't get their keys working, and they'd like to have locksmiths in their city who are trained in this. Don't think it's any more complicated than that...
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 paranoid side.
Little hard to lock the door with door chains while you're not in the room.
Hotel occupancy is a lot lower on the weekend. I'm sure many people living in hotel rooms with more belonging than can fit in the safe will appreciated this information being released on a weekend.
That seems like an implementation problem. (warning: anecdote ahead:) All sliding chain locks I've used are up at eye level, which would make this much more complicated, if not impossible. That, or they have the hard-bar-over-ball lock, also at eye-level.
Plus, my large hands wouldn't have been able to do that trick. :/
Now I wonder, how big is this then? 4M hotels in the US, what slice of the pie is that compared to the whole number of hotels in the US? And how many in Europe/Australia/Asia, do they use completely different locks?
Also, just because you leaked the details today (yesterday?), how realistic is his worry that evil parties might copy the tech before the weekend? :)
And indeed, doesn't every hotel room have a small safe, I don't just keep my passport there, but also my laptop, camera and phone if I don't take them with me.
And indeed indeed, I never even considered whether the door to my hotel room would be "secure", if maintenance and cleaning have a universal key, it's mostly a privacy measure, rating somewhat above a bathroom stall lock. It might be different if they wouldn't all have a small safe, though.
Now I do wonder how secure those safes are, in general :) Any idea? (edit: whoops I should've read the thread further, this has already been discussed--great discussion though, keep it up!)
> But on three Onity locks installed on real hotel doors he and I tested at well-known independent and franchise hotels in New York, results were much more mixed
This is a long shot, but I was in a chain hotel in midtown recently and heard someone tampering with the lock, and found the door ajar in the morning. I realize you probably can't name specific hotels, but was one by any chance a chain hotel in midtown around the 11th?
I think the primary threat in this situation is burglary of an unoccupied hotel room.
Security chains are fairly easy to defeat; a bent clothes hanger will do. Deadbolts are probably pretty hard if there's no external key hole. Someone intending harm to the occupants of a hotel room might just break a window.
My university uses Onity locks for universal access with ID cards. This means our campus (and residences) are vulnerable, too, right? Are you aware of many universities that use similar systems?
So, those locks are the CT (commercial, Integra) locks. I strongly suspect that they're vulnerable to roughly the same thing, but I haven't tested them to see for sure. There are two reasons I believe this to be the case: the only difference between the PP20 (portable programmer used in the Onity HT system for hotels) and the CT PP is a swapped out EPROM. Given the similarity of the systems from a high-level perspective and the PP differences, I'd be very surprised if they weren't similarly vulnerable.
At some point I'd love to test the CT side, but 1) the hardware is tough to get hold of, and 2) it's not a very popular system, so it's not that interesting. I think it'd be pretty straightforward, though.
Everything I'm releasing is specific to Onity. I can't speak to the security of any of the others, as I haven't looked at them yet, but I'm planning on doing so in the near future. Next up is most likely Ving, though Timelox is a really clever system, so that could be fun.
I can't speak to the actual security, but I know that it requires a contact card inside the slot to actually program the lock. That's not something you can likely build for a couple bucks in parts at Radioshack, so at least the barrier to entry is higher.
At least, higher. If you were in the business of robbing hotel rooms, I'm sure a onetime fee wouldn't be much of a barrier. Keep the small-time thieves at bay though.
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 unlikely I know!).
Given that you sat on this for a year before publishing, there was ample oppurtunity to inform Onity before you publish.
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. Simply put, I have zero confidence in their ability to mitigate this properly, and I believe that the only proper course of action is to make this public and let the hotels make themselves secure by whatever means possible.
I know that's a bit of a strange answer, but this is a strange situation; it's taken me a while to figure out the correct course of action, and I feel that this really is the best way for the safety of the public.
Edit: Toned down some of the wording; unnecessary.
I agree that it's probably futile, but the white-hat thing to do is give them notice. If they say they will not fix it, or ignore you, then you release the info.
If they say they're working on it, you give them a reasonable timeframe for that, and then release it.
That way, you've done everything 'properly', and nobody can say otherwise. With the path you're on, everyone is going to blame you instead of them, even though they're at fault.
Please consider doing this the proper way, even though we both know it's most likely futile.
While, yeah, I'm in the security industry, I agree that the "whitehat way" isn't always the "proper" way.
That said, there is an easy way to compromise on this one, and is the way I generally go about disclosure:
1.) Email security contact with vulnerability, announce that you will be releasing information in 30 days.
2.) 30 days later, release the information.
If a month isn't enough time to apply a fix (I do 60 days if it's a particularly complex issue), then the organization pretty much doesn't care.
I don't support responsible disclosure because it's "whitehat approved," nor do I do it because I particularly care about the vendors themselves.
I'm a proponent of giving the vendor a chance because of all the sysadmins that would suddenly have an 0day on their hands and be forced into the difficult position of either:
(1) shutting down the effected service
(2) hoping they just don't get targeted, which is unlikely
(3) trying to release a patch themselves.
That is a shitty position to put people, in my opinion.
Daeken, I've chatted with you in #startups once or twice (as 'dshaw'), and I think you're a genuinely cool guy. This research is awesome, but I still think you should give vendors a chance. Assuming that they already know about the vulnerability might actually be giving them too much credit... they did create the issue, after all.
That's a completly bogus excuse. The question wasn't why you're releasing it publicly, but why you haven't made any attempt to contact the company beforehand, which you seem to have had a year to do.
Edit: The only reasons I can think of are laziness or just plain not giving a shit about responsible disclosure.
In order so that they could do ... what, exactly? It doesn't sound like there's any mitigation that they could perform. At the very least, the guts of every lock has to be replaced. Given that, the rational, profit-maximizing thing for them to do is to stonewall, misdirect, bring out the lawyers, shoot the messenger, and generally continue to sell as many flawed locks as possible. We've all seen vendors do that in the past when faced with intractable, deep-seated defects in a product, so it wouldn't be unexpected or unreasonable to assume.
All the notification would be is a courtesy, allowing them time to start designing and marketing a new product, instead of having the market get handed to their competitors when hotels suddenly have to start replacing their locks with less-flawed ones. And I'm not sure a company that produced a flawed products deserves that.
> In order so that they could do ... what, exactly?
They can either say "Thanks for telling us. We're fixing the locks. There a X thousand locks, and we expect it to take Y weeks to fix them Please consider delaying release of this informtion until after then" - in which case he's done the responsible thing and can chose what to do.
Or they can say "We know, there's nothing we can do, don't tell anyone" in which case he's done the responsible thing and can decide what to do.
"Someone might sue me for doing the right thing" is a pretty thin excuse. There's a reason it's called "doing the right thing" instead of "doing what's easiest for you."
Say I'm a lawyer, and I find out that in order to help a client of mine I have to present evidence that's extremely embarrassing to a close friend of mine. I'm am professionally and ethically obligated to present that evidence.
Now, security professionals don't have, and probably shouldn't have, fiduciary responsibilities like that. However, industries set up codes of ethics for their members precisely because there's a difference between "what's best for me right now" and "what's the right thing to do."
If the idea is to embarrass the industry into fixing these problems, an article in Forbes does a pretty good job of that.
So, that's more than a million dollars more than NYSE:UTX's gross profits for the last quarter, and ~1/4 of their gross revenue over the same quarter. No, I don't think they were going to do that.
Financial reports are typically in 1000s of dollars - UTX's net reported in 03/2012 were $330 million USD.
edit: source is http://finance.yahoo.com/q/is?s=UTX ('All numbers in thousands' in upper right of the statement). Easy mistake! I just happened to be passingly familiar with United Technologies, which is a large diversified industrial conglomerate that includes Carrier (A/C systems), Sikorsky (helicopters), and Pratt & Whitney (aircraft engines) among other subsidiaries.
It's way more than a dollar. How many locks could one technician replace/fix in an hour, and what's their hourly rate?
"Me of all people"? Am I a spokesperson for "Responsible disclosure" now?
I would have notified the vendor ASAP, and I might not have put the vendor name into the talk at all. But that's me, and I am super conservative about this stuff. Lots of very reputable security people would do exactly what Cody did.
...so that Fortune could publish an article saying he followed industry-standard guidelines of responsible disclosure, so that non-techies wouldn't get further ammo to say "there ought to be a law against this."
He hasn't even gone to the point of no return yet. The vendor's competitors -- assuming they aren't similarly vulnerable -- can point this news article out in their marketing literature.
The company can probably come up with a solution faster than a brand new third party can generate all of this guy's work.
> the rational, profit-maximizing thing for them to do is to stonewall, misdirect, bring out the lawyers, shoot the messenger, and generally continue to sell as many flawed locks as possible
While that may be "profit-maximizing", it's not necessarily "rational". I'd sooner call it "short-sighted", "single-minded" or "primitive".
It might be "rational" from the pov of such a corporation as a single organism but it's not from the view of the humans that make up its arms, legs and eyes. And they live in the same society as the hotel owners and hotel guests, unless they choose not to, but it's getting harder and harder to make that choice thanks to people like Daeken.
And about the corporate organism? In its own competitive environment, it's got a primitive predatory intelligence, roughly comparable to that of a big spider (its products may be clever and complex, but its behaviour is not). If that's "rationality", we should probably consider setting the bar a bit higher for ourselves.
There may be lots of things the vendor could do. They could contact their customers so the hotels have a chance to consider their options. There is a good chance the vendor knows the protocol better than the guy who reverse engineered it; maybe there is a kill-code that they could give their hotels.
when hotels suddenly have to start replacing their locks with less-flawed ones. And I'm not sure a company that produced a flawed products deserves that.
You don't know that other products are better. In fact, he's said that there are other products he hasn't tested but still have the port. Maybe they are even easier to hack.
The company is going to have to deal with bad publicity regardless. It's just that know hotel managers are going to be in panic mode because of this guy is giving out all the directions so anyone can make their own skeleton key.
But imagine, if he had told them a year ago, perhaps the locks would be mostly replaced with a fixed version by now! I think it's unbelievable that he wouldn't disclose this information because he "just knows" they wouldn't do anything. He's not a damn mind reader. Hell, he might even be right, but you've still got to give the company the chance.
May I suggest you read up on some more stories about disclosure in the security industry. There have been many, many people before him that wanted to give them that chance and they've been sorely disappointed, time and time again. Hell you don't even know if Daeken maybe gone through this route from, you know, his own experience?
Fool me once, shame on me, fool me twice, and I'm supposed to be a damn mind reader?!
There is the possibility of being dragged through a lawsuit, and/or the company one works through being dragged through a lawsuit. I don't know if that is applicable here, but I have been involved in a responsible disclosure where I gave the information to a colleague, who then disclosed to the company, and the company then sent a letter threatening a lawsuit, whereas my colleague nearly got fired (the fact that he didn't was the one time I can remember the union stepping up to do something useful by defending him). Whether or not such lawsuits would hold merit, they'd be expensive for all involved, and lots of listed companies are more than happy to put the lawyers on you for invalid reasons.
People do use the legal system for suppression of free speech, to chill censors. There are also lawyers who will take issues like that pro bono. Google up the Popehat Symbol for some examples.
Not cool, dude. Not cool at all. The company might be lazy and ignorant, but it doesn't mean they won't move when faced with a lingering public disclosure. You must give them a chance. What you are planning to do is egoistic, it serves your own interests, and it does that at the expense of people staying in the hotels. How is this even remotely ethical?
Since everyone else replying is telling you what a lazy horrible person you are, I'll go ahead and let you know that I agree. Theres nothing they can really do at this point. And because of that the companies only real option is to just stonewall you for as long as possible.
EDIT: And if it weren't for the long history of large companies suing security researchers for blackmail/etc when they try responsible disclosure I'd have probably sided with everyone above.
It won't be a surprise to learn that these types of locks are vulnerable, but I'll be fascinated to learn the details especially since it sounds like you can get access to an internal bus easily.
"A readout of activity that took place on the hotel room's electronic door lock indicated that an attempt was made to reprogram al-Mabhouh’s electronic door lock at this time. The investigators believe that the electronic lock on al-Mabhouh’s door may have been reprogrammed and that the killers gained entry to his room this way. The locks in question, VingCard Locklink brand (Dubai police video, 21:42), can be accessed and reprogrammed directly at the hotel room door."
How did you hone your skills for years? Have you been working with other lock providers? Or other methods, or just the process of reverse-engineering the software that hardware interacts with?
I haven't been working on other lock hardware, but reversing the whole Onity system from the ground up has been quite an undertaking. I described a rough version of the whole process in another comment. I've also worked on a couple other devices, e.g. the Emotiv EPOC EEG.
Interesting, but it's not as if hotels in general have been high security installations.
Very easy experiment: Just go to the front desk an thell them that you sadly seem to have lost your room card. 90% of the time they will just ask for your room number without requiring any kind of proof that it's actually your room.
Or there's those hotels where you have to leave the keys at the front desk. Each time you come back you say your room number and they give you the key.
Yeah, that was our hostel in NYC. I asked about that, and they kind of looked at me funny, as if I was paranoid or something. If figured the best way would be to semi-jokingly show her my ID regardless and be friendly and chatty in the hopes she'd remember my face with the room number.
In hindsight I might have tried asking for a different room number's key to see if she was paying attention and then quickly correct myself "No, just kidding, my room's 208 not 210. I just wanted to see if you'd give people any room key they ask for". Maybe that would've made them see the issue.
Instead, I took the easy route and made sure to never leave my netbook, passport, tickets, etc in the room (all the rest was replaceable and we were travelling light).
I would have probably done differently if I wasn't in a foreign country on a different continent and still getting used to the cultural uncanny valley of NYC being "almost, but not quite like Europe", so I opted for the safe choice of not being a bother to these obviously hard-working people.
duh? I'm sorry but low security systems like hotel rooms of course have wide vulnerabilities. The front desk will just give out keys based on trust since you don't have to register everyone staying in the room; they don't even have an audit trail if they wanted to use it.
Keyless entry cars are mostly crackable ... garage door systems are trivial, you can bump pin tumbler locks, many home security systems have no backup power. rfid skimmers are cheap and easy-to-use. almost every elock I've seen has the bus readily exposed on the outside (secured by a single screw at best).
There's at most 6 things I can think of that actually do not have trivial security issues.
If I knew I would become famous by informing the press that, for instance, a car model only has a handful of key patterns for millions of cars, I would have done it a long time ago, but I thought such things were just stupefyingly obvious.
> a car model only has a handful of key patterns for millions of cars
This reminds me of growing up in Eastern Europe. Story time: Under the Romanian communist regime, there was only one car factory (Dacia[1]) making cars for personal use. Their main model was essentially the same from the '70s until 2004. For the first 10 years or so after the '89 revolution, Dacia dominated the local car market (because their cars were cheap and really easy to fix).
Now that we have the oh-so-important context, your comment reminded me that when I was a kid, my parents bought a Dacia. What confused me at a time was that random people would periodically ask to borrow the key.
It turns out that for 30-something years, Dacia only used a few models of keys. In fact there were so few that if you locked your keys inside (doors were unlocked by key and they locked automatically) it was feasible to try keys from random cars until one worked.
To be fair, the engine key was different from the door key, and it didn't have this problem. But, getting back to your comment, if you're talking about a recent card model then that's just crazy.
Also, I would have thought that keyless entry systems use correctly implemented public key cryptography. Is that not the case?
Just to be perfectly clear, what you have is a synchronized incrementing number usually using some in-house block-cipher with a 2^16 period. When the car receives a PRN from the RKE, it checks the locality of its current sequence (usually about 2^8) and then if the PRN matches one of them, you are in. So if you have the 2^16 sequence, just skip over every 2^8 and see if it unlocks. That's 2^8 tries; under a second.
If you don't have that, with a few sequences you can deduce the key pretty easily; each PRN is 32 bits; providing you up to 32 bits of information.
Since the payload is an incrementing 16 bit number you have probably 3 bits of entropy on the 32 bits (8 PKE commands between your sniffing). Anyway, assume you have 29 bits from the 32. You also have to toss the 16 bit sequence on the 64 bit source key calculations since it is effectively a salt.
Therefore, you can conservatively get the magic 64-bit key in 6 transmissions assuming there are no sequence collisions of that length. And even if there are, the solution space of the collisions would be quite modest.
Since each transmission has a plaintext serial associated with it (usually a subset of the VIN ... available on the windshield and all), you are not at a loss as to which transmission is which car.
So install your sniffer in an office-building parking structure on Monday, assume codes before 1100 are locks, after 1400 are unlocks, and you are in the car of your choosing by Thursday.
Pretend you don't have this. Pretend you want to do brute force on the 32 bit key-space. There's something called guard time. The idea is that there's a backoff period before another code can be tried. That's usually about a millisecond or two; if at all.
The transmission of the payload is on the order of tens of microseconds.
So generally speaking you can presume that you can do about 1.5m keys an hour.
Now let's say you are a car thief and you go to a lot of new cars ... there's 64 of them (2^6) just to make our lives easy. You have a wonderful consequence of the birthday-problem.
A 2^32 key space with a 2^8 tolerance over 2^6 vehicles ... means (32 - 8 - 6) = 2^18 keys until you should have a match.
Now let's see, you can generate about 2^21 keys per hour ... oopsie daisy. Look what we just did ... Your mean time to unlock one of the cars passes a 50% threshold in all of 4 minutes.
And that's the naive approach, without doing any predictive plaintext attack.
Now let's assume you use both methods together. We aren't talking about much waiting time here.
So I mean yes, the rolling code means you can't just do a replay. Ok, fine ... right ... you have to do a napkin full of math and a little programming. It's not real security.
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 below that these things are battery powered, which raises two questions, first, ok, how are they reprogrammed, and second, how does a hotel not go bankrupt replacing thousands of batteries all the time?
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.
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.
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 after they clean the room? It seems like it would be very inefficient to send a special person around to reprogram the lock after every check out.
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).
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).
>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.
How interesting. Does that mean that you could theoretically have access to an empty room if there's no new occupant? It seems like you need some sort of expiry to prevent that from happening, but I can't imagine how that would work without some signal passing between the front desk and the lock.
There is an expiration date on the card (the lock keeps time). However, with the crypto vulnerabilities I'm going to be announcing, it's possible to manipulate cards to change the expiration date or increment the code key value (which is what gets cycles); this would allow you to continue using a card indefinitely.
You can't make cards out of nothing, though, so that helps mitigate it.
Thanks for your (patient) answering of my questions. It's funny how just asking how things work sort of naturally leads to thinking about vulnerabilities, eh? :)
So they set the card to expire when you plan to check out. But I've extended my stay (and done late check out) and I didn't have to get a new card. Why did my room lock let me back in without getting a new or rewritten card?
I don't know about other systems, but with Onity systems you have to get a new card to extend the expiration date. Of course, it's possible they gave you a card with the incorrect expiration in the first place; happens all the time.
let's do this AMA thing right here, because my questions might get lost in the reddit noise. You seem like the prototype hacker to me - what's your personal stack? like OS, text editor, the computer you use daily?
My stack now is a Lenovo W520 running Ubuntu and KDE, and Sublime Text as my editor. Over the years when I did this, I was running everything from a cheapo, hacked-together box to a 13" Macbook Pro, all running Windows Vista/7.
Do you use Backtrack at all, or do you simply craft/download/build-from-source your own tools as you need them?
Also, did you switch from Windows to Linux because of the available tools and development environment, or because the Linux desktop had matured enough you could get sh*t done without worrying about driver compatibility issues or other common complaints about Linux [lap|desk]tops?
I don't use Backtrack or similar tools; the only tools I use that I didn't write myself are IDA Pro and Burp Proxy (if I'm doing websec work).
As for switching OSes, the primary reason I did so is that my work for my day job all requires Linux. In terms of reversing, Windows is really the only way to fly; the tools just aren't there otherwise.
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' very poor. I have no doubt that this technique is known to locksmiths and law enforcement and maybe a smaller group of criminals. But making this public and exposing it to the world will allow any criminal with a soldering iron and an Arduino to start exploiting this.
Daeken, you have done an awesome job making this known. Maybe that it enough to get the ball rolling. Or do you just want to do damage for fame and profit?
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.
I'm not saying he should not publish this at all. I just think it will be more responsible to try to work with the vendor. Right now he has not even made that effort.
And he hasn't released the source code and hardware specs yet. So, although I think he should have contacted the vendor (even if that could have been inconvenient for him) before going public, he still hasn't made it trivial for a third party to go around robbing unattended hotel rooms. It's his choice but I would appeal to him to not do that.
Full disclosure is a lot of fun, and it increases the status of geeks like us, so it's really to approve of it. I did when I was in college.
I'm not certain, but in the picture from the Forbes article the lock looks exactly like the kind used on many doors in my university - the shape is exactly the same, and ours had the same type of electrical connector in the same place at the bottom of the lock. I remember because I considered attacking this interface before noticing the torx security screw next to the connector; removing this screw allows the panel covering the bottom part of the lock to be removed (the edge of this panel is visible in the Forbes photo), exposing the bolt mechanism of the lock. Turning this mechanism one way opened the lock, turning it the other double-locked it so it couldn't be opened with the proper keycard.
I wonder if any HN readers have access to an Onity lock to check whether this method works on them?
I'm looking at my test lock (which doesn't have panels on it) and it looks to me that there's no way you could access the lock mechanism from the battery panel. With the HT locks I've played with, the locking mechanism sits inside the door, between the lock itself (with the circuit board, card reader, batteries, etc) and the back plate containing the deadbolt and such. Don't think it's vulnerable to what you're describing. However, it should be noted that if it's used in the university, it's almost definitely the Integra/CT line from Onity, which is different.
Probably because if the system glitches out and they can't into the room anymore (even with maintenance keys) then they wouldn't ever be able to fix it?
Well, you can always drill the lock cylinder out, but that's a destructive process. It is possible to do this sort of thing in the right way, they just didn't.
Once the batteries go out (they're not powered on guest room doors), the lock won't open to keycards anymore. The batteries, though, are on the front of the door just below the handle (see the panel at the bottom, in the story photo) and can be replaced from the outside. Otherwise, it's possible to use the portable programmer's open function to open the lock, if the batteries in the PP are full enough; that's really iffy and has a tendency to not work, though.
What tools do you use for reversing hardware? Did you have to open up the lock and tap into it with something like a logic analyzer? Or was it as simple as creating a DC port adapter so you could read the data from the portable programmer?
So, reversing it was sort of all over the place. I first had to reverse the front desk system and all that; that was primarily done by sitting between the equipment with a serial proxy and working from there. Once I had a good bit of data captured, I'd write software to emulate being one side or the other. Everything is RS232 and RS485, pretty straightforward.
In terms of reversing the actual lock protocol, that was a bit more tricky. First step was tapping the line between the portable programmer and lock with an o-scope (a 70s-era HP scope; only thing I could afford at the time, haha) to figure out the voltage levels involved and the basic properties of the communication. From there, I hit it with the Saleae Logic to see what the communication actually looked like.
From there, I wrote some Python scripts to walk over the data from the logic analyzer and attempt to decode the data. With some tweaking, I managed to finally see some data that I knew, specifically the site code (which I knew from other parts of the system).
After I knew all that, it was a matter of figuring out the actual hardware level. Given that I have effectively no experience with this level of things, this was a lot of asking questions, googling, and experimenting. I knew that it was a one-wire protocol, so by reading up on other one-wire protocols I managed to figure out a lot. Once that was done, everything just fell into place; making the opening device work initially took maybe a day given all the info I had.
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.
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 guesses.
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.
EDIT: Actually, this kid of thing needs to get a lot more attention and awareness. I could suggest a certification of some kind, but there's often a reaction against that. But a certification that just indicated:
- No passwords in plaintext
- Not vulnerable to replay attacks
- No "toy" encryption
Edit: Since this thread has blown up a bit, we may as well just do it here for real. If you have any reversing questions or background questions or whatnot, feel free.