Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Bug Networking Security Wireless Networking

Hundreds Of Smart Locks Get Bricked By A Buggy Firmware Update (bleepingcomputer.com) 119

An anonymous reader quotes BleepingComputer: On Tuesday, August 8, smart locks manufacturer LockState botched an over-the-air firmware update for its WiFi enabled [RemoteLock 6i] smart locks, causing the devices to lose connectivity to the vendor's servers and the ability to open doors for its users... The device costs $469 and is sold mainly to Airbnb hosts via an official partnership LockState has signed with the company. Hosts use the smart locks to configure custom access codes for each Airbnb renter without needing to give out a physical key to each one. The botched firmware bricked the device's smart code access mode. Physical keys continued to work. The botched firmware was a nuisance for private home owners, but it was a disaster for Airbnb hosts, who had to scramble to get customers physical keys so they could enter their rents.
The post includes tweets from angry lock owners, one complaining about a two-week wait for a replacement. The company is also offering to fix the defective units within "5-7 days," promising that "Every employee and resource at LockState is focused on resolving this for you as quickly as possible."
This discussion has been archived. No new comments can be posted.

Hundreds Of Smart Locks Get Bricked By A Buggy Firmware Update

Comments Filter:
  • Inside Job... (Score:5, Insightful)

    by js290 ( 697670 ) on Sunday August 13, 2017 @11:27AM (#55003101)
    Yet another data point demonstrating outages are better caused by admins than by hackers.
    • Re: Inside Job... (Score:1, Interesting)

      by Anonymous Coward

      Mark another in the "win" column for the DevOps model: traditional development release cycles could never have bricked so many devices so quickly.

  • Cloud equivalent (Score:5, Interesting)

    by CaptainOfSpray ( 1229754 ) on Sunday August 13, 2017 @11:33AM (#55003127)
    Yet another data point to underpin the motto "Never allow any data or access or service that you value to be controlled by Somebody Else's Computer"
    • Re:Cloud equivalent (Score:4, Interesting)

      by Kergan ( 780543 ) on Sunday August 13, 2017 @11:49AM (#55003203)

      However big a QA screwup this is, at least give this company credit for actually trying to upgrade their firmware.

      • by arth1 ( 260657 ) on Sunday August 13, 2017 @12:08PM (#55003263) Homepage Journal

        However big a QA screwup this is, at least give this company credit for actually trying to upgrade their firmware.

        Um, no. Allowing a firmware change mechanism is the flaw here, and should not be commended.
        The time to harden a lock isn't after it's sold.

        • by msauve ( 701917 )
          Allowing unapproved updates is the issue - if owners simply got a notice asking them to approve an update when they signed onto the website (along with an accurate changelog, so they could determine its importance), it wouldn't have spread as quickly, and would have given the vendor more time to withdraw it before it spread so widely.

          Also, beta testing.
          • Yup, the lock is owned by the customers, the customers should be told that there's an upgrade and then they apply it themselves.

            Also, there must always be a rollback mechanism, or a reset to factory settings.

          • users don't patch without prodding. And that's just software. Firmware isnt something users have even heard of.
        • "The time to harden a lock isn't after it's sold."

          A physical key is still allowed. At that point, you can't harden the lock through firmware updates. A physical key will always be a vulnerability.

          • by Calydor ( 739835 )

            A hammer and chisel, crowbar etc. will always be a vulnerability.

            Remember, no lock is stronger than the door in which it sits.

        • by AmiMoJo ( 196126 ) on Sunday August 13, 2017 @02:36PM (#55003919) Homepage Journal

          Their mistake was trying to build an impossible product: an internet connected, secure lock that people can rely on.

          • by arth1 ( 260657 )

            Their mistake was trying to build an impossible product: an internet connected, secure lock that people can rely on.

            I'm an atheist, but amen.
            I can't upmod you because I've posted, but if anyone here have points to spare, look one up.

            • The issue here isn't security...it wasn't compromised by attackers. The issue is redundancy in firmware upgrades and no ability to roll back. I get that it's likely massively expensive but remotely upgrading something that can go wrong requires proven backup measures for when things do go wrong.
          • Their mistake was trying to build an impossible product: an internet connected, secure lock that people can rely on.

            Don't worry. They'll get it correct when they build a self-driving car that cannot be remotely hacked.

          • You're assuming security is black and white. Most locks aren't very secure and can easily be bypassed with a few seconds of lock picking. The goal is not to make something secure, but rather to make something secure enough.

            In a case where you need to hand over keys to strangers, an internet connection is by far not the biggest problem in the scenario.

            Now would I want an internet connected remotely unlockable safe for all my wealth? No.

        • by tlhIngan ( 30335 )

          Um, no. Allowing a firmware change mechanism is the flaw here, and should not be commended.
          The time to harden a lock isn't after it's sold.

          So tell me what internet-connected device, accessible from the internet, will be secure always?

          The reason this lock is there is because it can be accessed over the Internet. Presumably, the instant AirBnB, the owner and the customer agree, the lock will be auto-provisioned with a new access code, and the code activated for the duration of the stay. Once the stay is over,

      • by TWX ( 665546 )

        Why? They did more harm than if they'd left the firmware well enough alone. The aphorism, "the road the hell is paved with good intentions," comes to mind. The results dwarf any intentions.

        • Because they probably got the PWM code for the blue lock LED strobe just that much smoother and so a better user experience?
      • No. If you're making something like locks, you need to make a huge effort to write solid code in the first place. People are depending on your code to keep things secure, and you need to follow either formal logic design, or the DJB school of programming. You don't release things and fix them later, your lock needs to have pretty close to zero bugs.

        This is just a sign that they have lousy procedures, and the code is just as bad.
        • by Hylandr ( 813770 )

          Can't wait for car manufacturers to start updating firmware / car computers over night or while I am at the store and bricking my car.

      • by ctilsie242 ( 4841247 ) on Sunday August 13, 2017 @03:13PM (#55004041)

        A lock is a relatively simple device, where the states are obviously known. Devices like this should ship and not need firmware upgrades from the factory. There are many embedded subsystems that cannot or will not be upgraded, so the people who made them did it right the first time, and didn't follow the philosophy of "it builds, ship it."

        A lock isn't rocket science. It also is the last thing you need fetching OTA updates. Instead, updates should be delivered via some physical means, if only to ensure someone is on site to test and verify functionality.

        Making sure a device doesn't brick itself is not impossible. I have an older Nook tablet that, if it doesn't boot after eight times, it automatically reloads itself from its original firmware, just so the device is usable in some degree. With a deadbolt, you might want a more secure way of failing, so having multiple areas where ROMs are stored, so if it fails to boot, it goes back to a previous ROM. That way, it might grab some bad code and brick a few times, but once the failed update is off the servers, it would fetch a correct one and be fine.

        Lesson learned from this... find a lock maker that treats their offerings as a security item, and not some throwaway IoT device.

        • A lock isn't rocket science.

          No but everything else on the device is computer science and bugs happen. A firmware update sounds preferable to having to send it back to vendor every time there's a problem. A firmware update sounds preferable to a major security flaw having been discovered.

          The problem is you're generalising. Maybe this firmware update was to change the LED to blink when unlocking. Maybe it was for something far more critical like an identified bug that makes it open by itself randomly that wasn't caught in testing.

      • by rtb61 ( 674572 )

        Does not matter. Imagine if that company was global with tens of millions of locks all shut down. A fuzted door lock used to mean just you and a lock smith, now they can shut down entire business and even countries. There need to be some regulations and penalties for widespread computer bugs going forward.

    • by Shoten ( 260439 )

      Yet another data point to underpin the motto "Never allow any data or access or service that you value to be controlled by Somebody Else's Computer"

      The problem here isn't that the data or access or service was controlled by someone else's computer...that's true of all software updates. It's that the process behind the update was controlled by someone else's business model. IoT is much like SCADA, in that there are physical consequences to cyber actions. As such, it's very important to maintain control of your own systems. This played out with Nest thermostats that pulled down updates without notice or warning...some of which bricked them. You had

    • Yet another data point to underpin the motto "Never allow any data or access or service that you value to be controlled by Somebody Else's Computer"

      Unless they are better at controlling it by you. Quite frankly if history has proven anything it's that "your own computer" is by far the worst place for the data of the majority of people and even many major companies.

  • Whenever you adopt this kind of new technology (or a novel application of older technology, for that matter), you have to be prepared for screw-ups. It goes with the territory. This was definitely a one of those, but if LockState is telling the truth, they're putting everything they have into fixing the problem. I would bet they'll also take steps to make sure this situation doesn't come up again.

    I'm a lot less tolerant of situations where large, well-established software/hardware manufacturers cause maj

    • by arth1 ( 260657 )

      but if LockState is telling the truth, they're putting everything they have into fixing the problem

      Nothing less should be expected, but that does not in any way diminish what happened. It is also likely not out of a desire to do what's right, but to reduce the number of lawsuits.

      • by Shoten ( 260439 )

        but if LockState is telling the truth, they're putting everything they have into fixing the problem

        Nothing less should be expected, but that does not in any way diminish what happened. It is also likely not out of a desire to do what's right, but to reduce the number of lawsuits.

        Indeed. And they should have put everything they have into not causing the problem in the first place. Not only has this sullied their name, it's impacted AirBnB as well. I doubt that AirBnB (who selected them as an official choice to recommend) will ever forget this.

    • Fundamental problems exist though, and they have fixes. First, allow the device to rollback to previous firmware, or allow a reset to original firmware/configuration. That's almost mandatory for serious companies selling to serious customers, but it's often treated as unnecessary by silly companies selling to the consumer market.

      Second, put the customer in charge of when upgrades happen. The device belongs to the customer unless you're merely leasing it. Again, this is mandatory for serious companies sellin

  • by Anonymous Coward on Sunday August 13, 2017 @11:37AM (#55003157)

    Way to Go Software "Engineers". I can't wait for the self driving cars to roll out.

    We are sorry that your self driving car veered off the road and killed all its passengers. We have isolated the bug to the periphery scanning routine. Please accept 1 Mo of free self-driving car time, or 1 Mo of free Uber/Lyft service, and this complimentary condolence ham. Remember, our liability is limited to the price of the software, please accept this 1499.99 as full compensation for the death of your relatives.

    Your insurance is fully liable for the remaining costs, re: the 4 pedestrians that were killed. Our liability ends here, have a great day!

    • Why is this marked as a troll. Does the mod actually believe self driving car software is simpler than lock software? Does the mod actually believe the lock company was any less careful than the self drive company?

    • by Megane ( 129182 ) on Sunday August 13, 2017 @12:27PM (#55003329)

      Way to Go Software "Engineers".

      But they were the finest Millennials that stock options could buy!

    • Why does it have to be self driving cars? There is at least one car company, Tesla, doing over the air software updates now and it has the possibility to brick your car any time. Why you "buy" your car you agree for these to happen without your knowledge.

      Imagine the damage done to Tesla if they did an over the air update that did brick their cars. In a way I would like to see it, not because I hate Tesla, but it would bring attention to the masses. A door lock isn't going to do it. And it would be better fo

  • by Anonymous Coward

    What could possibly go wrong?

  • QA testing.... (Score:5, Insightful)

    by Minupla ( 62455 ) <minupla@gmail.PASCALcom minus language> on Sunday August 13, 2017 @11:45AM (#55003187) Homepage Journal

    I've seen it increasingly over the last few years, shortcuts on testing in order to get an update/new product out the door. This is short sighted. In a year, noone is going to remember it took you a week longer to get it out the door. People WILL remember if you brick all your devices.

    • Re:QA testing.... (Score:5, Informative)

      by Maximum Prophet ( 716608 ) on Sunday August 13, 2017 @12:42PM (#55003381)
      If you are late delivering the product, you *will* be fired. If you send the product prematurely, you *might* brick the device, and have to stay up late fixing it. You decide.
      • by AmiMoJo ( 196126 )

        Even under the best of circumstances a firmware update will brick some percentage of devices. Some will have bad flash memory, some will have failed hardware (oscillators, RAM, peripherals, voltage regulators, capacitors etc.) such that the failure only becomes apparent when the update is applied.

        Thus you mus accept that every time you push out firmware remotely, you will get some customers who need urgent support to replace their safety and business critical hardware.

        Software vendors are so bad at this tha

      • Re:QA testing.... (Score:5, Interesting)

        by Minupla ( 62455 ) <minupla@gmail.PASCALcom minus language> on Sunday August 13, 2017 @03:47PM (#55004185) Homepage Journal

        In most companies I've worked in, *you* don't decide. You raise the risk to your risk management team, who breaks the bad news to the people who get paid to make the 'hot seat' decisions.

        So failure analysis suggests one of the following happened, all of which fall under the "QA" side of the business processes::

        1) QA was not thorough enough to detect that this firmware update would have enough of a worse failure rate to raise business risks to an unacceptable level.
        2) Risk management wasn't doing their job
        or
        3) Management made a poor business call on letting this go out, and didn't plan for the risk coming to pass (e.g. with pre-staged replacement devices, prepared messaging, etc)

        • You raise the risk to your risk management team

          Which one of the 3 people in my IoT startup is that?

          • by Minupla ( 62455 )

            I realize that was probably a rhetorical question, but I'm gonna be that guy and answer it seriously anyways.

            In a way, that's the tough one. You NEED someone to be the 'risk champion' just like someone in the 3 of you needs to ensure the bills get paid. And maybe Mr AC is right and it should be you as you've at least shown the interest to get involved in my conversation. In a small company, your ability to recover from a risk event is very limited, but your chief asset is the ability to take risks, so yo

            • Yeah it was rhetorical and while you're right what you have is a lot of this thing that a lot of companies lack called "experience".

              This is just one very small part that is missing from the groups of people who think they can change the world for the better. It's one of the reasons so many small businesses fail, they underestimate just how complicated running a business can be. If lack of risk management doesn't kill them, then lack of policy, procedures, consistency, or any of that other boring non-agile s

      • If you are late delivering the product, you *will* be fired.

        I've seen many late products (in one case, an entire year late), but I've never seen anyone fired because of it.

    • by antdude ( 79039 )

      Ha. Or worse, no QA like MS. It is quite frustrating! :(

  • THE BRICK! (Score:3, Insightful)

    by Templer421 ( 4988421 ) on Sunday August 13, 2017 @12:11PM (#55003275)

    Is the backup unlocking device.

  • by Kaenneth ( 82978 ) on Sunday August 13, 2017 @12:46PM (#55003393) Journal

    "Oh fuck, oh fuck, we're fucking fucked!"

  • by Opportunist ( 166417 ) on Sunday August 13, 2017 @01:06PM (#55003469)

    Can I hear that again?

    [...]causing the devices to lose connectivity to the vendor's servers[...]

    So, lemme get this straight: These things, that lock my home doors, have a connection to their vendor, reacting to this vendor's command to unlock or lock my home. Did I get that right?

    What sane person would WANT that in the first place???

    • by Anonymous Coward

      As it said in the article; people that put their homes up for rent on AirBnB.

      • As it said in the article; people that put their homes up for rent on AirBnB.

        They won't need this it if it was there home. And you can't have more than one home. If they are renting out multiple apartments they are landlords or hotel managers, and if they are doing it on airbnb, illegal ones at that.

    • by Anonymous Coward

      *All* locks can be opened by the vendor, always. This was true in ancient Egypt, and has never changed.

      • by Anonymous Coward

        *All* locks can be opened by the vendor, always. This was true in ancient Egypt, and has never changed.

        This is mindbogglingly untrue. How did this get a modpoint? Go talk to any locksmith.

        That statement was true long ago for a couple thousand years. All locks within a city were made by the same locksmith-apprenticeship line and behaved the same. Skeleton keys did truly exist that were locksmith specific and would unlock anything they made.

        Today the only lock manufacturers (they don't "vend" their products like software companies) that can unlock what people install are ones that keep records of locks with se

      • Even if that is true, the average maker of old fashion locks does not know which of his locks is used in what door. This vendor very obviously must know just that.

    • Connecting to the vendor's server is the whole point of the lock. That's how I can send you a virtual key that you can put on your phone. When you get near the lock you transfer it to the lock via BlueTooth. The lock needs to know about the key so there are two options. Either the lock can ask the vendor to validate the key or the vendor has sent a list of keys along with a set of restrictions (times, dates, days of week, etc) to the lock.

      Yes you could do it yourself but then you would need to have your own

    • Re: (Score:3, Insightful)

      by Carewolf ( 581105 )

      Can I hear that again?

      [...]causing the devices to lose connectivity to the vendor's servers[...]

      So, lemme get this straight: These things, that lock my home doors, have a connection to their vendor, reacting to this vendor's command to unlock or lock my home. Did I get that right?

      What sane person would WANT that in the first place???

      Apparently people running illegal hotel services, and need a hotel key system for their "non-hotel" on airbnb.

    • Corporate and proprietary software sycophants will no doubt claim to want that. Posters like you find right here on /.. But this is another situation where software freedom and fully-free software driven hardware could have saved people from experiencing the problems described. Users could be notified of an update, download the complete corresponding source code to that update (and the software already installed in their locks) and then do due diligence for their own locks: inspecting the complete correspon

    • by Anonymous Coward

      Fortunately, the vendors are always the good guys, right?

    • by thegarbz ( 1787294 ) on Monday August 14, 2017 @04:25AM (#55006661)

      What sane person would WANT that in the first place???

      You think the only application for locks is one where you are in complete control. That isn't remotely true. Who would want this? Anyone who's main course of business relies on handing a stranger a key. The ability to control temporary locks digitally is far more security than a fixed easily copyable mechanism that can't be easily changed and is given to random strangers.

      Based on airbnb's stats alone I see 50 million applications.

  • by sjames ( 1099 ) on Sunday August 13, 2017 @02:14PM (#55003787) Homepage Journal

    And the real lesson is that if you're going to do firmware updates like that, you need to ALSO have a backup in ROM that is at least good enough to get connected and re-flash the primary firmware, and a mechanism to boot into it.

    Other useful precautions include only doing upgrades when explicitly permitted (so, not just before the owner takes his dream vacation when a screw up would ruin his week). Perhaps best of all, get it right the first time or at least try hard enough that you feel comfortable making updates a very rare manually initiated end-user procedure.

    Does anyone even know what the update was supposed to actually fix? It seems the users weren't complaining before the update went out.

As you will see, I told them, in no uncertain terms, to see Figure one. -- Dave "First Strike" Pare

Working...