Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Google Security Technology

Google's Doors Hacked Wide Open By Own Employee (forbes.com) 112

Last July, in Google's Sunnyvale offices, a hacker found a way to trick doors into opening without the requisite RFID keycard, Forbes reported Monday. Luckily for Google, it was David Tomaschik, an employee at the tech giant, who only had good intentions. From the report: When he sent his malicious code across the Google network, he saw the lights turn from red to green on the door to his office. Then came the satisfying thunk as the lock opened. It was the culmination of work in which Tomaschik had uncovered vulnerabilities in technology made by Software House, the creator of the office controllers managing the physical security of the California site.

Last summer, when Tomaschik looked at the encrypted messages the Software House devices (called iStar Ultra and IP-ACM) were sending across the Google network, he discovered they were non-random; encrypted messages should always look random if they're properly protected. He was intrigued and digging deeper discovered a "hardcoded" encryption key was used by all Software House devices. That meant he could effectively replicate the key and forge commands, such as those asking a door to unlock. Or he could simply replay legitimate unlocking commands, which had much the same effect. Tomaschik also discovered he could do all this without any record of his actions. And he could prevent legitimate Google employees from opening doors. "Once I had my findings it became a priority. It was pretty bad," he told Forbes. Google then moved quickly to prevent attacks on its offices, according to Tomaschik.

This discussion has been archived. No new comments can be posted.

Google's Doors Hacked Wide Open By Own Employee

Comments Filter:
  • Unsure about this (Score:4, Interesting)

    by proibido ( 2470696 ) on Monday September 03, 2018 @09:47AM (#57245796)
    If they protect their own facilities like this imagine our own data :S
    • by Anonymous Coward

      How a third party handles its own product doesn't seem like it could represent how Google develops their own services.

      • Re: (Score:3, Insightful)

        A lot of third parties do much better than Google. Google dabbles in a lot of directions, at the whim of their loose and often undirected management.

        • by Anonymous Coward

          Oh sure, I just think it's a bad comparison. Google bought a product that it turns out has a security flaw. How some other company operates and sells their products can't really represent Google's own development practices.

          • Re:Unsure about this (Score:5, Interesting)

            by arth1 ( 260657 ) on Monday September 03, 2018 @11:01AM (#57246088) Homepage Journal

            How some other company operates and sells their products can't really represent Google's own development practices.

            No, but it shows that they use and rely on 3rd party unverified and ill designed programs, giving it access to their networks. That does taint their own products, even if everything they themselves did were safe and secure - to misuse a metaphor, it's fruit from a poisonous tree.

            • How some other company operates and sells their products can't really represent Google's own development practices.

              No, but it shows that they use and rely on 3rd party unverified and ill designed programs

              So does every company. So does yours. But how many others do this sort of investigation? Software House has thousands of clients, but it was Google that found the problem -- and published it.

  • by Anonymous Coward

    News at eleven.

  • They spend too much time doing their own shit rather than helping paying customers

    • Like finding a solution to why our emails sent through gmail servers go to spam folders of our customers on gmail and whom we have been communicating with via email for years.

      Trying to get a support case escalated when the support muppet can't give you an answer is nearly impossible unless you start yelling at the support muppet. Then you get a manager muppet and have to go through the whole process again.

  • He blew it. The proper thing to do would be to have designed and introduced a trojan/worm into the security system. When it reached critical mass, it would be triggered to open all the doors, continue to reopen the doors, and defend itself against removal.

    • just cut the power or set off the fire alarm and that will open a lot of the doors and it's part of the fire code.

  • Why put your door locks in an accessible network?

    My office doors weren't RFID. You had to actually insert a card into the standalone locks which needed to be programmed for access. The locks also kept a record of who/what accessed them. I like old school.

    The only downside was the magnetic strip would wear out after a few years...

    • Re:Kinda weird (Score:5, Insightful)

      by OzPeter ( 195038 ) on Monday September 03, 2018 @10:36AM (#57245996)

      Why put your door locks in an accessible network?

      At some point having a centralized control increases flexibility and security over and above the effort needed to implement it.

      In your old school scenario if you were fired then Fred down at IT would have to schedule someone to physically come to your office and and re-program your door lock to stop you gaining access to not only your office but all those other sensitive places that you previously frequented. That would take time and manpower to do.

      In a connected world, run one script and *poof* you are instantly persona non grata in the entire organization. Of course the connected world scenario does require security to be correctly implemented. But that is what pen testing is all about. It is akin to the software corollary that untested software should be considered broken.

      • by Asgard ( 60200 )

        >accessible network

        I think the suggestion was that the locks should be on a separate network than is accessible to anyone other than building management.

        • by OzPeter ( 195038 )

          >accessible network

          I think the suggestion was that the locks should be on a separate network than is accessible to anyone other than building management.

          I was replying to the OP was reminiscing about how good disconnected locks were.

      • Re:Kinda weird (Score:4, Interesting)

        by mystik ( 38627 ) on Monday September 03, 2018 @11:03AM (#57246104) Homepage Journal

        There is a risk to fully automatic organizations like that.

        https://idiallo.com/blog/when-... [idiallo.com]

        Can be pretty scary when there are no checks and balances to the automation.

        • by OzPeter ( 195038 )

          There is a risk to fully automatic organizations like that.

          https://idiallo.com/blog/when-... [idiallo.com]

          Can be pretty scary when there are no checks and balances to the automation.

          I've seen that story before and its a bit disingenious. The machine didn't fire him, the non-renewal of a contract by a person fired him. The system did its job correctly.

          • by Calydor ( 739835 )

            And the system apparently had permissions somewhere up around CEO level seeing as NO ONE was able to stop what it was doing.

            I'm curious what would have happened if they'd told the machine the CEO had been fired.

      • Why put your door locks in an accessible network?

        At some point having a centralized control increases flexibility and security over and above the effort needed to implement it.

        In your old school scenario if you were fired then Fred down at IT would have to schedule someone to physically come to your office and and re-program your door lock to stop you gaining access to not only your office but all those other sensitive places that you previously frequented. That would take time and manpower to do.

        In a connected world, run one script and *poof* you are instantly persona non grata in the entire organization. Of course the connected world scenario does require security to be correctly implemented. But that is what pen testing is all about. It is akin to the software corollary that untested software should be considered broken.

        Nah, the parking lots, security fence entry and building entry were on RFID which was on a separate network. Easy to revoke if needed.

      • by rea1l1 ( 903073 )

        >In your old school scenario if you were fired then Fred down at IT would have to schedule someone to physically come to your office and and re-program your door lock to stop you gaining access to not only your office but all those other sensitive places that you previously frequented. That would take time and manpower to do.

        This could very well be considered a feature in terms of checks and balances.

        >In a connected world, run one script and *poof* you are instantly persona non grata in the entire org

      • Not for most systems I have seen-- they work kindof like a certificate authority with a revocation list. No control communication over the IP network, just RS-485.

    • Re:Kinda weird (Score:5, Insightful)

      by decep ( 137319 ) on Monday September 03, 2018 @11:36AM (#57246242)

      > Why put your door locks in an accessible network?

      This one is easy. One of the purposes of encryption is allowing trusted communication over untrusted networks. If the communication is properly authenticated and encrypted, who cares who can see it. The key word being "properly".

      Getting encryption and authentication right on a mass-produced, IoT product is extraordinarily difficult. Making it [reasonably] future-proof, even more so.

      • by sjames ( 1099 )

        That's exactly why for the sake of belt and suspenders you should at least use a vlan to isolate the security traffic if not a physically separated network.

        • That's exactly why for the sake of belt and suspenders you should at least use a vlan to isolate the security traffic if not a physically separated network.

          The Google network is heavily segmented, though Google has shifted to consider that more of a management feature than a security feature. Google relies primarily on the BeyondCorp zero trust model to provide security, because network segmentation really doesn't. Segmentation isn't useless, but it provides no protection against adversaries who get access to the wires.

          I'm sure the badge readers were on a separate VLAN. But Google doesn't trust network segmentation and obviously chose to investigate potentia

          • by sjames ( 1099 )

            According to TFA, they segmented the network in response to the hack. And yes, VLAN isn't perfect. That's why you want belt AND suspenders, not belt OR suspenders.

            • According to TFA, they segmented the network in response to the hack.

              Okay.

              And yes, VLAN isn't perfect. That's why you want belt AND suspenders, not belt OR suspenders.

              Except that VLANs are more like wearing suspenders made of a few, thin threads. It's almost nothing. Proper cryptographic security is the right solution here, and once you have that, a VLAN provides nothing -- other than traffic management, which is what it's really good for. VLANs were never intended to be used as a security measure, and shouldn't be applied with any expectation that they're adding significant security.

        • by ebvwfbw ( 864834 )

          For a door lock? Ever set some of this "IOT" which is really "ICT" or Internet Connected Technology? Some of the crap requires windows and explorer for the controls. Vlan, they barely meet minimum requirements as it is.

          If you want to keep people out, use a good old commercial door lock. That'll keep almost all the lock picks out. They an also put spools, other things in to make it a lot harder.

          • by sjames ( 1099 )

            There are many reasons you might want centrally controlled access control with cards. For example, if 1000 people have legitimate access, how long do you suppose it will be before a copy of THE key goes missing somewhere?

            • by ebvwfbw ( 864834 )

              There are many reasons you might want centrally controlled access control with cards. For example, if 1000 people have legitimate access, how long do you suppose it will be before a copy of THE key goes missing somewhere?

              I run into this all the time. That's not what the problem is. The problem was his office. For central places it's not nearly as much of a concern. There is usually a guard there, CCTV, other people. They can also piggy back in. Then they filter people down by floor, then often by other key card access areas. Most of these places today if you have an actual office, whatever you do is worth protecting. Otherwise you're usually out in a bull pen at a half desk.

              I remember even over 20 years ago I had to use a c

    • by swb ( 14022 )

      I have to deal with building security systems sometimes and nearly always the RFID locks (which encompasses the RFID reader, secondary keypad if there is one, and electromechanical lock mechanism) aren't ethernet enabled.

      The "locks" are hardwired to controllers which can be networked but are programmed by some software application which in turn places each keycard into whatever access groups its supposed to have. The controllers are then updated with add/deletes of card profiles. I see about half the cont

  • by Slashdot Junky ( 265039 ) on Monday September 03, 2018 @10:23AM (#57245950)

    Clearly, the door access/lock system has or had design problems and needs these properly addressed. It's presence was made worse by poor network security. It should have been on a dedicated network and certainly not on the general LAN/VLAN. This guy had access to the network and shouldn't have unless the poking around was blessed.

    • by ledow ( 319597 )

      Agreed.

      VLAN. With RADIUS. Or the very least MAC-based RADIUS and blocking any unknown devices.

    • Clearly, the door access/lock system has or had design problems and needs these properly addressed. It's presence was made worse by poor network security. It should have been on a dedicated network and certainly not on the general LAN/VLAN. This guy had access to the network and shouldn't have unless the poking around was blessed.

      Physically securing wires is a fools errand. You can't protect wires that go everywhere.

      Every dime spent on a fools errand is a dime not spent securing what is attached to those wires.

      • Physically securing wires is a fools errand

        Correct. Wires are pretty easy to sufficiently protect through physical barriers that aren't easily breached without noise and adherence to smart policy. Like most things in need of securing, network and network attached devices require a multi prong approach. And similarly to all security implementations, the one that Google may have employed along this with door lock/access management solution would have been defeated by those sufficiently motivated even wit

    • Google don't have dedicated networks full of systems that blindly trust everything, as they're on "trusted networks".
      They have one massive network, with devices that are supposed to be secure.

    • This guy had access to the network and shouldn't have unless the poking around was blessed.

      "The guy" is a member of Google's Red Team, which is the group tasked with finding internal security problems. He was "blessed".

  • Particularly if you are Turing testing a hot looking android named Ava.

  • As a reward for being such a trouble maker.
  • by FeelGood314 ( 2516288 ) on Monday September 03, 2018 @03:35PM (#57247184)
    You need to be able to review and understand the commands being sent on a network. Often just a one hour review will reveal that there is no real security. There are 3 levels of lack of security:

    1)Static keys, no replay attack prevention, sending the session key with a static key are all things that happen all the time.

    2)Authorization: The next level of security fuck-up for many small devices like these is a complete lack of authorization. Any device that is in radio range or has access to the LAN during the joining window can join the network. (think of WiFi or Blue Tooth as an example).

    3)Identification: Most devices have no means to prove they really are who they say they are. Thus an attacker who takes one device apart and extracts its keys can impersonate almost any other device. Many networks don't even care what device joins, as long as it has a static piece of information and they have no defense against man-in-the-middle attacks. This is also the case where a single device connecting to a network can see everything. When you log into a website and pull up your information and then change the query string to another user's ID and see their information, that isn't a hack. The site is performing as designed.

    I call these lack of security, they aren't bugs or vulnerabilities, the system was simply was never designed to be secure. You aren't hacking a system that didn't have security*.

    *Disclaimer: If you live in a certain country where pointing out something has no security embarrasses people with money you are likely to get charged with unauthorized use of a computer, lose all financial resources, be threatened with 10^20 years in prison and have to take a plea deal. Don't ever do security research in that country.
  • Security automation measures such as RFID scanners, card insert readers, IP Security cameras, etc should always been kept on its on closed-loop network and redundant power source as a best practice. Opening security systems for buildings on a main network can, and will always result in major flaws to the physical security of an infrastructure of a housed facility, and will almost always result in vulnerability points whether it's from a localized or external source.

  • Let's say that you have built a Linux-based "appliance" and it's deployed in numerous places around the world. Let's also say that you need to make some changes to system libraries for new versions. AFAIK, the only way to do this is to have root access. So how would you build some sort of updating software that a user with no Linux experience could run that would allow for installation of new system components? If you have to have root/superuser access, how do you keep it secure? Is there another way t

    • You don't need the end user to have root access, you just need to have an update process running which can acquire root access, or at least access to the files which need to be updated.

      So you give each appliance a private/public keypair and the public key of your update server. The process which has access to update would then only accept encrypted updates both designated for that appliance's specific key and signed using the update server's private key. Mutual authentication.

      You can do that online via a TL

    • by ebvwfbw ( 864834 )

      As long as it can get out to the internet that's not a problem. I used to do this two decades ago with Linux firewalls I used to set up in Washington. Lot of NPOs. As long as they kept up their payment it would keep updating the machine. Sometimes I'd have to hoof it out there and do an in person upgrade. The bitch ran into it when they had no trouble so they'd cut the support contract. Then call me about a year or so later because someone broke in.

      I don't do any of that anymore. Sold that business off. How

  • How could he even see the traffic unless he was mirroring a switchport and sniffing traffic he shouldnt be doing in the first place? He obviously had access to the door swipe VLAN and access to the network switch

A morsel of genuine history is a thing so rare as to be always valuable. -- Thomas Jefferson

Working...