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.
If they protect their own facilities like this imagine our own data :S
News at eleven.
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.
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.
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
Americas nuclear arsenal is an offline system that relies on humans to receive a message, validate its authenticity, and then choose to act. There are decided differences between what is effectively a mechanical turk and an internet of shit device.
Thirty four characters live here.
I heard they have free food, and that it is really good.
I am surprised the door locks were on the same network as workstations. Actual traffic isolation would have prevented someone from finding this flaw unless they start tearing holes in their walls.
Thirty four characters live here.
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.
I am surprised the door locks were on the same network as workstations. Actual traffic isolation would have prevented someone from finding this flaw unless they start tearing holes in their walls.
Is it clear that it was on the same network as workstations? I left Google in 2017, and for many years the internal networks had been heavily segmented. I'd be very surprised if any random RFID node or printer could have communicated directly with my workstation. In fact, I don't think my machines could talk to each other from physically adjacent Ethernet ports without requesting a network change.
It's called a Lauer lock
when he said this...
Can the officers in the silo even reprogram the missiles or launch independently? That sounds like a monumentally bad idea. What would stop them from declaring the Free State of Silo 16 and threaten to nuke Washington if their demands for beer, beef and pre ban AR15 weren’t met?
If construction was anything like programming, an incorrectly fitted lock would bring down the entire building...
As a reward for being such a trouble maker.
In theory? No. In practice? That is a very good question. These are, generally, skilled officers, educated well enough to manage a tremendous responsibility correctly and reliably. One or more of them might be clever enough to outsmart flawed security.
Oh, my. It's very easy to ask why someone else did not spend several times the amount of money in capital costs and support costs for an infrastructure change. What is the return on investment?
At what point did vlan tagging become DLC?
Thirty four characters live here.
Ideally, the doors would be on a physically distinct network with its own switches, not a VLAN tagged distinct network. That means physically distinct wiring all the way back to the wiring closets, and no plain repeaters or shared switches all the way back to any central switch for the door controller system. In practice, a few facilities bother to set up tagged VLAN's on shared switches. But unless the switches are also programmed to only communicate with specific MAC addresses on specific ports, anyone can plug in a device on such port and access any of the relevant devices on any of the VLAN's, simply by network programming of the client device, even with an appropriately tagged virtual IP address. It's possible to do that kind of restriction of access: but developers in most networks will _despise_ the security people for doing this, because it tends to cause far more failures for the developers than it prevents. Even simple wiring practices such as "the red socket is for internal security, and non-registered devices plugged into it will make us turn off the port" will upset people.
The "internally open" network, including the infrastructure devices, is very common. Indeed, it is part of the core design of the "Internet of Things" approach to network design were all devices should be accessible at all times. Without testing, I'd not insist that Google does this. But the approach of "don't worry about the internal network, just leave it open" is very commonplace.
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.
Ideally, they wouldn't be on any network at all if you fixate only on theoretical security threats... but in the real world both your suggestion and this was have passed well beyond the point where the inconvenience exceeds to the additional security benefit. If you can compromise VLAN security to the extent that you could directly access and exploit an access control unit you could almost certainly do the same thing to access and compromise far more valuable things.
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.
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!
Unlike the door, it would be hard to try the nuke over and over to reverse engineer what message was being sent.
"First they came for the slanderers and i said nothing."
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
That's one way to let the whole world know you have never worked at a tech company in your life I guess.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
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.