Slashdot Mirror
Google's Doors Hacked Wide Open By Own Employee (forbes.com)
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.
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.
So totes haxx0red da syst3m!!!1! HAXXXXXX!!!!!!!eleventy!
amirite?
If they protect their own facilities like this imagine our own data :S
What you need security doors for google? To stop others from stealing employees or what?
News at eleven.
Your fired!
They spend too much time doing their own shit rather than helping paying customers
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.
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...
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.
.
Landfill Mining Co.
Managing the (Un)natural Resources of Tomorrow
Surprised he wasnâ(TM)t fired and arrested for his efforts. Guess he might still be sued by Software House. Good deeds rarely go unpunished if they embarass wealthy corporations.
Particularly if you are Turing testing a hot looking android named Ava.
Have gnu, will travel.
This means that they will be dealing with the legal side, and will have ensured that there are no issues. One of the advantages of being an employee.
when he said this...
I'll h4ve offended
Damn.
As a reward for being such a trouble maker.
Google should live by their own standards and disclose the hack is soon as itâ(TM)s found. Letâ(TM)s see what happens then.
Is it actually possible to build a secure, computer based door locking system?
I've watched several DEFCON / Blackhat presentations of pen-testers finding all sorts of vulnerabilities in computer based door locking systems that i cant help wonder if it's actually possible to do it right. Those same pen testers often finished their presentations by claiming to have been unable to find such a lock that they were unable to circumvent, and the 3rd party that provided google with this system is no exception.
I have to assume that while developing their product the 3rd party company did at least try to make it secure. The product design specification for such a product must surely have had security as it's number one selling point (if it's not secure, then no customers would want to buy it) and yet they completely failed to achieve that goal.
This feels like a major failing of the product development team. How could they allow a defective security product into the market place? Didn't they have any pen-testers of their own, or at lease a rock-solid set of design criteria and security principles to follow to prevent such a failing. I'm no IT expert but judging by the comments of fellow slashdotters, it seems the use of static encryption is well recognised as a bad idea, and yet they did it anyway.
So I find myself having to ask the question: Is a secure computer based door locking system just too complex to get right, and therefore impossible?
Wow. Sounds like the doors at some of the @CaesarsEnt hotels. . .
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.
When I want to hack a door open, I use an axe.
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 to do this?
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 TLS session, or offline using USB sticks or whatever. It's easy enough to automate either process, although the USB version would require someone to physically plug something in.
Another way to increase the security of the process is to require a reboot before any system files can actually be updated. It's more disruptive, but presumably if you have any sort of proper monitoring setup, an unplanned reboot shouldn't be missed.
The party of stupid and the party of evil get together and do something both stupid and evil, then call it bipartisan.
A sudo rule to run a program that will verify that an update bundle is GPG signed by the intended author then execute it. The non-privileged user just needs to place the GPG signed update bundle in the expected location and run the expected sudo command to check and run the update bundle. The author of the update bundle, you needs to GPG sign the bundle you provide to the end user.
In the 1970s I used to break into my high school to use the computer after hours . But I only needed a piece of plastic. Or screwdriver.
(eventually the math teacher just loaned my friend and me his key...)
What is the mission of the security system at Google?
What I figure it is for at Google and many other tech companies is to satisfy a legal requirement, for I.P. protection and especially to satisfy the U.S. Patent Office.
If you make a public disclosure, it sets a clock ticking for a U.S. Patent and it may prevent issuance of a patent in other countries. If you make a confidential disclosure, you are protected against tripping that clock, but how do you guarantee that when you are talking to other Google employees you are making a confidential disclosure? It appears that two conditions establish a "safe harbor" on legal confidential disclosure -- that the employees you are talking to have all signed the corporate patent agreement and that there are locks on the doors and guards at the entrance to the facility.
So Google doesn't need Minuteman Missile Base level of security, it only needs to go through the motions of security to satisfy the lawyers. However hackable their door locks were, they were satisfying the legal requirement, that is, until Genius Google Employee hacked them. Now that this vulnerability has been disclosed, Google has to rework their door locks as does every other fine user of that particular door system.
Great job, Genius Google Employee!
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
This only works due to him having pre-authorized access to the network, an outsider would not be able to do this. Simple fix is to put the security/door/facilities equipment on a restricted VLAN. Sounds like Google outsourced their networking to India rather than hire full-time IT staff to manage their network infrastructure. That's what you get for outsourcing anything involving IT other than the person that answers the phone for the Help Desk.
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. However it's not hard. All you need is a cron job that updates every day. Set up a reboot schedule so kernels will get updated. That's very simple. The bitch is when you upgrade remotely and something goes wrong. One time I had to get on a plane to fix that. Machine was many miles away.