The last few weeks were full of mixed emotions for me. Reliable reports of hotel break-ins seemingly utilizing the vulnerability I disclosed at BlackHat are coming out, and I'm both horrified and vindicated.

As I explained in my paper, the decision to release this information in the way I did was not an easy one. I've been full of doubt ever since I first made the call, and while I was inclined to think I did the right thing, I really couldn't tell for sure. But now, my doubt is gone.

Ever since the first story broke about these issues, I've taken significant flak from the security community and others for my lack of adherence to Responsible Disclosure. Hopefully this post will show that that's not always the responsible approach.

Background

When I set out to reverse-engineer the Onity HT system, my goal wasn't to examine or undermine its security at all. Rather, the goal was to understand how it works and create a replacement for the Onity front desk system (primarily the encoder that makes the keycards). In the course of developing that, I found the vulnerabilities but didn't think much about them for a while.

In 2010, we (the startup I was running with friends at the time, UPM) decided to license the opening technology to a locksmithing company for law enforcement purposes. Quite honestly, I don't know what I can or can't say beyond that, due to contracts; at some point I'll be able to talk more openly about it.

Going Public

In 2012, we decided that it was time to make these vulnerabilities public, but we were unsure how.

Concerns

These were the characteristics of the vulnerability that were considered when weighing the release:

Severity and Impact

The vulnerability itself, in a vacuum, is quite severe. Any Onity HT lock can be opened in less than a second with a piece of hardware costing effectively nothing. The hardware can be built by someone with no special skills for only a few dollars and utilized with no real 'training'.

Combine this with the fact that there are 4-10 million of these locks (Onity's own estimates -- my guess is that this is locks in use versus locks shipped) in use protecting people for 20 years now, and you have the perfect storm.

Mitigation

Since the locks are not flashable, the only real way to fix them is to either prevent access to the jack (a non-solution) or replace the circuit boards in the locks. Either way, you're talking tens of millions of dollars to fix all the locks. Neither the individual hotels -- primarily independently owned with very low margins -- nor Onity can afford this.

Ease of Discovery

The major vulnerability (the memory read) is trivial to discover -- it's used as part of the normal operations of the lock. That combined with the time these locks have been on the market gave me a strong feeling that I was not the first to discover it. In fact, it's blindingly obvious to anyone looking at the way the lock's communication functions that this vulnerability would be present; how did Onity not know of it?

I've since heard from various people that someone inside of Onity may have built an opening device themselves at one point, but I can't confirm that, let alone that it operated on the same principles as mine.

Release Scenarios

Contact Onity

The standard 'Responsible Disclosure' approach would be to notify Onity and give them X months to deal with the issue before taking it public. While this is tried and true, there are several issues with this approach.

Onity, after 20 years and 4-10M locks, has a vested interest in this information not getting out, as it makes them look bad and costs them a significant amount of money. As such, it's likely that without public pressure -- which we've seen in the form of unrelenting press coverage -- they would have attempted to cover this up. Cases of security researchers being sued by vendors are well known in the industry and not uncommon.

Due to the difficulty in mitigating the issue, it's entirely possible that only a tiny fraction of hotels would've been fixed by the publication deadline, and without such a deadline applying pressure, there's no reason for Onity to continue to make strides to fix the issue.

Don't Release

This was a genuine option for a long while. While it's likely that it's been discovered and exploited long before I even looked at these locks, it was not a well-known attack.

However, I decided that the long-term benefits of this being fixed outweighed the problems certain to be faced in the short term while the flaws were being mitigated.

Full Public Disclosure

The last approach is to simply release all information to the public in the most visible way possible. This dramatically increases the odds that someone will use the attack for malicious purposes, which is why it was always a big concern for me.

However, by making it as visible as possible, it puts significant pressure on Onity and the hospitality industry as a whole to fix the issues and get hotel guests back to a safe position. At the end of the day, this seemed like the approach most likely to get a swift response to the problem.

Priorities

The key problem with Responsible Disclosure -- aside from the implication that any other means of disclosing vulnerabilities is irresponsible -- is that it puts the focus on security researchers' responsibility to vendors rather than customers. In most cases, the vendor of a vulnerable product is not the victim of attacks against that product, which makes this focus misguided in many cases.

In the case of the Onity vulnerabilities, the vendor (Onity) is not the victim, and neither are the hotel owners (Onity's customers). In this case, the hotel's customers are the true victims. While hotels or Onity could be liable in certain cases as a result of these vulnerabilities, hotel guests are the ones with their property and lives on the line.

Putting the focus on responsibility to the vendor, as nice a situation as it may be for vendors in many cases, can leave the true victims in a dangerous spot.

The focus for security researchers should always be on the customers, not the vendor; this is what Responsible Disclosure gets wrong. While it's true that in the majority of cases -- especially when dealing with software -- the quickest way to make customers safe is to work with the vendor to fix the issue, Responsible Disclosure advocates tend to ignore the edge cases in favor of a dogmatic adherence to this method.

When Is Responsible Disclosure Irresponsible?

This is a hard one, as Responsible Disclosure is usually the best approach and knowing when it falls short is tough. In general, I'd say that if the majority of the conditions below are met, Responsible Disclosure might not be the best way to minimize customer risk:

• The product is widespread (note: in-house software almost always immediately merits Responsible Disclosure)
• A fix for the vulnerability/vulnerabilities is costly or difficult to implement
• The risk to customers is severe
  • This must not simply be the vulnerability's rating, but the risk rating weighted with the impact to customers and the payoff for malicious actors
• The likelihood of independent discovery is high
• Replication of the attack requires little skill relative to the payoff of exploitation
• The vendor is likely to have severe damage to their reputation or customer base as a result of the vulnerability becoming public knowledge

In cases where all or most of these are met, Responsible Disclosure may not be a responsible approach and may lead to customers remaining insecure and unsafe for years to come.

Response

The response to the Onity HT vulnerabilities has been bigger than I ever thought it would be. The press has been unrelenting for months -- it was even featured on the Today Show this morning (December 6th, 2012), more than 4 months since the original release.

Onity has been vague on how and when they're fixing the issue. In August they published a plan for mitigating the flaws, which I responded to; Forbes picked up on this and Onity subsequently removed all trace of this plan from their site. They are now stating that they are paying for/heavily subsidizing their fix, only after months of battering from the press.

This would never have happened without public pressure; hotel guests would have remained vulnerable for a long time, rather than a few months. When all is said and done, disclosing this fully and publicly will have lead to increased safety for hotel guests the world over.

Takeaway

Cases like this are never easy. In fact, it downright sucks to have to go through this with a vulnerability that could cause severe harm to customers. But at the end of the day, you have to decide one thing: is the customer more important than the vendor? In most cases, I'd say that they are.

The world is not black and white, and a dogmatic adherence to Responsible Disclosure makes us less secure and less safe as a whole. I urge all security researchers to think long and hard about how to disclose vulnerabilities, for the sake of everyone impacted, not just the vendor.

Happy Hacking,
- Cody Brocious (Daeken)

Introduction

In 2011, CCBill ran a bug bounty program. While they didn't pay much per-bug, there were enough low-hanging fruit available to make it fairly lucrative; you could find a couple bugs in an hour and make some quick money. So for a month or two, I'd dedicate one or two nights a week to hunting down bugs and reporting them. As you can see from the rewards page that worked out pretty well. However, one of the most interesting bugs I found isn't on there. This is the story of that bug.

Interest

Early on in the bug bounty, one of my friends (Neal Poole, also testing CCBill at the time) pointed me in the direction of the 'Forgot Password' function and thought I might be able to find something there, specifically a padding oracle type attack. When I requested a password reset for my account, I'd receive a long link in my email, e.g.:

https://admin.ccbill.com/updatePassword2.cgi?enc=c8d2d3
d66ac13a865d64276623d8260352616e646f6d49566e31e063163e5
bd501fbca5d6f1c71998148a12edb637a2cf36492b646d8ad9ab811
9c6214432afe27c3c3030c2e6b43a2a8e9452923ad18298f9255578
d639c07afe41c1e82935d1cdba3709bec565e3eefb08ad27f33127a
d3daeb51d88d16209c706de526fc1c63f9e760e39da6fecbc9b5734
a8bb8a8348a07c2aac7645a799586a0f4cac7fa075862f4cac6dc17
137ad3840d43ea1d7a04d324cff6aab1917b4ac3779a98f3fdb8476
f25f350ae9bc4863fa1e11b4eacfba44b4dded55e6589568b576758
90635da75c13e22234

Now, when I see a blob like that, my first step is to take it from hex back to an ASCII representation. In the header of that blob, I saw RandomIV. A quick Googling of that string told me that it was generated by Perl's Crypt::CBC. Outside of an irrelevant old vulnerability report about the usefulness of the IVs (here), it looked solid. CBC mode, HMACed properly (seemingly), etc. So tampering with the blob wasn't much use.

I gave up after trying a couple different attack routes on it, as it seemed outside my cryptographical expertise.

Obsession

Of course, giving up and forgetting about something are two very different things, especially for me. Something about those blobs didn't seem right, and I started seeing them in other places. For instance, requesting reports about your account would lead you to a viewer that took another -- much larger -- encrypted blob, presumably containing either a query for the report data or the data itself.

So one night I found myself laying in bed and thinking about this issue, and whether I had missed something. I'd tried everything I could think of to break the blobs themselves, but there was some idea in the back of my mind.

Source confusion

They use the same blobs in many places. What if they're using the same key in each place? If they are, then a blob from one place will decrypt properly in another. If you could control what goes into the blob, you could compromise the other components. He who controls the source, controls the universe.

I immediately got up and took one of my report tokens and put it into the forgot password page. Up popped up a password reset dialog.

Of course, I had no control yet -- I had no idea what was in the blob, how it was constructed, or how any of the pages actually used the data in the blob -- but that proved to me that they used the same key in each place, making this very likely exploitable.

Gaining control

There was one place I could control the data going into the blob: report generation. While I couldn't ever tell just how much control I had over the final blob, I was able to put some arbitrary content into it, and that was good enough.

However, another interesting problem popped up soon after I discovered that: they were compressing the data going into the blob. If I put in a string of 'A's, I would only add a byte or two to the total size. That makes it harder to gain total control, but if you can put in any data you want, you could poison the compression enough to put it into a bad state -- one where effectively nothing compresses properly, and you end up with your own data completely in the clear.

The compression also could be used to figure out what else is in the blob other than your data. I didn't go down that rabbit hole, but this isn't unprecedented; in fact, it's the same way CRIME works.

Impact

Through trial and error, you can determine what impact your data has on the page where you're using the blob. This is an odd one in that depending on what's done with the bug, it could be anywhere from useless to super critical. In this case, it was determined by CCBill's security staff that it was worth two high bugs, or $1000. I never did find out what exactly could have been done with this bug, but I do know that you could compromise the forgot password form, and cause some query failures with the reporting facility.

Conclusion

If I were an attacker, this could've been a big, big win; in theory, this could've given me the keys to the castle. However, as a bounty participant it was worthless outside of scratching my own itch, as I took probably 5 or 6 hours to find that $1000 bug, rather than spending that same time to find ten $300 bugs. That said, it was definitely a more interesting result than the others.

Advice for developers/security folks

These days it's well known how to get encrypted blobs right (even if most people don't): use sane crypto in a good mode with a random IV, HMAC appropriately to prevent tampering, and don't leak information to enable oracles. However, even if your blobs are perfectly sound, using them in multiple places with the same key makes it possible for attackers to use a blob from page A on page B instead. If the attacker can control the data inside the blobs at all, you're likely to be compromised. The solution is to use different keys for each page that uses a different blob, or to put a 'blob type' flag at the beginning of the plaintext data.

In most cases this will not be a good way to attack a site -- there's generally something juicier and easier -- but they're really easy to miss and can be critical.

Advice for bug bounty admins

When determining pricing for bugs, make sure you aren't creating perverse incentives. A SQL injection vulnerability could cost you far more than a CSRF bug in a random user-facing page -- price accordingly. CCBill priced theirs at $300 for low, $400 for medium, and $500 for high bugs, though both Neal and I received one or two 2*high payouts. If you can find three or four low bugs ($900-1200) in the time it takes you to find a single high bug ($500), it absolutely makes sense to focus on those low-hanging fruit; the pricing is simply broken in that case. Not that I mind.

Happy Hacking,
- Cody Brocious (Daeken)

P.S.

Want me to find bugs like this in your own products? Check out my portfolio and contact me about my consulting services.

Onity responds

On August 13th, 2012, Onity released their plan to mitigate the vulnerabilities in the Onity HT hotel lock line that I released at BlackHat this year. My previous post on the subject is available at .

Their statement is available at and is reproduced below in case future edits are made:

August 13, 2012 - This is an update to Onity's previous communications regarding the hacking of certain models of Onity hotel locks. We want to assure you that Onity is working on providing you with a solution that will address any potential risks related to the alleged vulnerability of these locks.

Onity is going to implement a two tiered approach. The first approach will include providing a mechanical cap, free of charge, to our customers, who have the Onity HT series locks. This mechanical cap will be inserted into the portable programmer plug of the HT series locks. With the existing battery cover in place the mechanical cap will not be removable without partial disassembly of the lock. This will prevent a device emulating a portable programmer from hacking the lock. To further enhance the security of this fix, we will also supply a security TORX screw with each mechanical cap to further secure the battery cover in the lock. This solution is currently going to production, and should be ready for deployment starting the end of August. The second solution Onity will offer to our customers, if they choose to use this option, is to upgrade the firmware of the HT and ADVANCE series locks. The firmware is currently complete for the HT24 lock, and by early next week should be complete for the entire HT series of locks. By the end of August we should have the firmware complete for the ADVANCE lock as well. The deployment of this second solution, for HT series locks, will involve replacement of the control board in the lock. For locks that have upgradable control boards, there may be a nominal fee. Shipping, handling and labor costs to install these boards will be the responsibility of the property owner. For locks that do not have upgradable control boards, special pricing programs have been put in place to help reduce the impact to upgrade the older model locks. If you are interested in pursuing this solution, have additional questions or require further information, please contact Onity at 1-800-924-1442. Thank you again for your business and your trust in Onity over the past many years of our relationship.

July 25, 2012 - At the Black Hat conference on Tuesday July 24, a hacker presented alleged vulnerabilities of certain models of Onity hotel locks.

The hacker showed an open-source hardware device that he built, which mimics a portable programming device. He claimed that by using this device a plug can be inserted into the locks’ DC port, which may result in opening the lock.

Onity understands the hacking methods to be unreliable, and complex to implement. However to alleviate any concerns, we are developing a firmware upgrade for the affected lock-type. The upgrade will be made available after thorough testing to address any potential security concerns that you may have.

Onity places the highest priority on the safety and security provided by its products.

For additional questions or for further information, please contact our office. See below for your nearest location.

Thank you for your continued business!

Before going further, I want to say this: Onity should get credit for responding to these issues and taking steps to mitigate them. This situation is not a simple one, and taking steps to secure their hardware could not have been easy.

However, I feel I must throw in my two cents on the mitigation plan as it stands, as I do have serious concerns.

Physical security

Onity plans to provide a mechanical solution to the problem to all customers, in the form of a mechanical cover on the inside of the battery compartment. This cover will be mounted inside the battery compartment, covering the portable programmer port, and they plan to switch the screw on the battery panel with a TORX screw for added protection.

This -- as much as it is security-through-obscurity -- is actually a great temporary fix. Don't get me wrong, it will not take long at all to open the panel and use an opening device to pop the lock open, but it will raise the bar and make it more likely that the attacker is caught in the process.

However, I wonder how they're going to do this for the ADVANCE series locks; I don't have one handy, but as far as I can recall, the portable programmer port stands on its own and could not be covered up in this way -- they even say the HT locks are the only ones the cover is for. This seems to leave the ADVANCE lock owners (who are admittedly few) in the rain.

"Firmware update"

In addition to the port cover, Onity is working on what they are calling a "firmware update" for the locks. This is where things get hairy.

Not a firmware update

This is not really a security issue, but it is a credibility and honesty issue. I feel it's very deceptive to say to customers "we are preparing a firmware update" when you really mean that you're preparing a hardware update. They may be changing the firmware on the lock, but to make use of this, customers are required to replace the whole main circuit board.

This is equivalent to Apple telling customers "we're releasing a software solution for this issue" and then going on to say that they're doing it by replacing your laptop's motherboard.

Issue mitigation

I have not seen nor tested the updated locks in any way, shape, or form; what follows here is speculation based on my knowledge of their system and the vulnerabilities in question, and what they announced in their statement above.

At BlackHat, I announced two vulnerabilities: an arbitrary memory read and initial work into their flawed cryptography for key cards. The important thing to keep in mind is that neither of these sit in isolation; the arbitrary memory read happens as part of the protocol between the portable programmer and the lock, and the crypto is flawed between the encoder and the lock.

As such, I cannot imagine a fix for both of these issues which does not consist of replacing not only the lock circuit boards, but that of the portable programmer and the encoder.

If the protocol on the lock is changed in any substantial way -- as would be needed to fix the arbitrary memory read -- then the portable programmer would no longer communicate with the lock, causing the system as a whole to fail to function. Likewise, the cryptography cannot be changed on the lock side without also changing it on the encoder side.

I would absolutely love to be wrong about the lock protocol issue; if they can fix this at the lock level alone, and fix it well, then the impact on customers will be lower and the chances of the issue being fixed are higher. However, I find this highly doubtful. It seems far more likely to me that they have mitigated this issue at the lock level simply by shifting data around in memory or something along those lines, which would serve to break existing opening devices but not hold up to even the slightest scrutiny.

Responsibility

While it's great that Onity seems to be taking these issues seriously, the fact remains that such blatant vulnerabilities existed in their massively distributed product line for nearly a decade. As such, I believe that Onity has a greater responsibility to their customers than they are currently taking on.

Fix cost

Onity plans to distribute the mechanical caps free of charge to HT customers, but the cost of fixing the actual vulnerabilities will fall to the customers. Even if this were to cost only $5 per lock (between the hardware itself, shipping, and installation), at 4-10 million locks in the wild that means a cost of $20-50MM to the hotel industry as a whole; this will not be insignificant, given that the majority of hotels are small and independently owned and operated. Given that it won't be a low cost endeavour, it's not hard to imagine that many hotels will choose not to properly fix the issues, leaving customers in danger; this is on top of those that will simply not have heard of the fix, if Onity does not contact all of their customers directly -- I do not know if they plan to do this or not.

If such a significant issue were to exist in a car, customers would likely expect a complete recall at the expense of the manufacturer. I can't help but feel that Onity has the same responsibility to their customers, and to customers staying in hotels protected by Onity locks. Whether they have such a responsibility from a legal point of view or not, I can't say; but from an ethical point of view I believe they do.

Auditing

Releasing a fix for such a serious vulnerability without having the complete system (fix and all) audited by independent security professionals is merely asking for the issue to persist, or even new issues to come up. For the safety of hotel guests everywhere, Onity must have an audit performed; it's simply the only way to know that they aren't releasing another horribly vulnerable product onto the market.

This isn't a panacea -- things can and do slip by security audits every day -- but it's the best solution we have right now to at least catch the low hanging fruit, which I would very much consider the vulnerabilities announced to be.

Closing

The plan announced is not perfect, but it's absolutely a step in the right direction. I look forward to seeing it put into action and hope that the issues I raised in this post will be addressed.

As always, Happy Hacking,
- Cody Brocious (Daeken)

Well, my talk for Blackhat (My Arduino can beat up your hotel room lock) is over.  Things could've gone better in terms of execution -- went through it too quickly and ended up using 30 minutes of my 60 minute slot.  But people really enjoyed it and I spent a good hour or so answering questions.

Now it's time to release everything. There's still work to be done on the paper, but that will happen in time.

Paper: http://demoseen.com/bhpaper.html
Slides: http://demoseen.com/bhtalk2.pdf

I'll write more on all this in the near future, but now it's time for sleep and all that.

Happy hacking,
- Cody Brocious (Daeken)

Edit #1: I've created an IRC channel for the ongoing research in this stuff.  It's #lockresearch on irc.freenode.net.  Feel free to join if you want to keep track of the work, or participate hands on.

Well, been a while since I've written anything here. Things have changed quite a bit lately: new year, new job, tons of random projects, etc. Figure it's time to write about it.

New Year

Holy shit, it's 2012. Last year was pretty insane:

• Finally found an awesome girlfriend
• Met a lot of amazing people
• Traveled at least once a month
• Released a few cool projects
  • Kivlad -- Android decompiler I wrote at Matasano
  • Windowpane and the associated article Superpacking JS Demos
• Completely and utterly dominated the CCBill bug bounty program. That was freaking fun. List of rewards here.

But honestly, I feel like I missed the mark last year. I want to release a good bit of fun stuff this year.

New Job

As of the beginning of the month, I'm working for Mozilla Corporation as a hacker on Boot2Gecko. While I love the people at Matasano and will miss working with them, it was just time to do something new, so I'm initially working on graphics optimizations in Gecko. I'm also doing some fun stuff in terms of demos to exercise new features, and I'm now a member of Khronos and will be submitting various extension specs to WebGL.

While I'll be working out of the various offices from time to time, I'm primarily working remotely from Manhattan still, which is really nice. Finally turning my apartment into a Real Adult Home (TM), with the help of my girlfriend. There's even real art on the walls for once!

Projects

I'm working on a couple things for this year, and hopefully they don't fail quite so hard as a number of the projects I started last year (e.g. my completely stillborn hardware project, Gotham Eyewear).

• QuestCompanions -- Real-time market for temp labor in MMORPGs. Launching publicly shortly.
• Webgl-inspector -- An attempt to make WebGL canvases transparent, so you can investigate textures, shaders, etc and perform modifications in real time. Very early, but should be releasing a beta build in the next couple weeks.
• Browser.js -- A complete browser written in Javascript. Note that this isn't intended to be a real browser, but rather one for experimentation and learning. Now that I'm working on the lower levels of Gecko, I really just want to learn how all the parts of the browser works, so I figure I'll write a simple browser to learn it over time. It should be an interesting experiment.
• GenShaders -- Genetic algorithms applied to shader generation. Very much a work in progress, but I'm writing a series of articles on it for Displayhack, which will be linked/reposted here.

Goals

Above all else, my goal this year is to travel outside the country more. The girlfriend and I are planning on going to Greece and Turkey around July, which I'm looking forward to in particular.

This ought to be a good year; I'm hopeful that I'll learn a lot and have a lot of fun.

Happy hacking,
- Cody Brocious (Daeken)