Submitted via IRC for takyon
A Google engineer found that he was able to hack the supposedly secure doors at the search giant's Sunnyvale offices. He was able to unlock doors without the RFID key, and even lock out employees who did have their key ...
Forbes reports that David Tomaschik found what turned out to be a completely inexcusable vulnerability in the Software House devices used to secure the 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 [...] And he could prevent legitimate Google employees from opening doors.
Worse, the hack left no trace in the security logs, so there would be no evidence of whether or not the exploit had ever been used.
The same Software House tech is widely used by other companies, meaning that any number of businesses could be left vulnerable.
Source: https://9to5google.com/2018/09/03/google-doors-hacked/
(Score: 5, Interesting) by anubi on Monday September 10 2018, @05:42AM
What's the problem? They bought "boardroom security". With backdoors. And the "open-sesame" is now out.
Isn't this the exact same thing that government has been trying to foist on all of us?
"Boardroom security" is for the executive-based control factions, like the bathroom lock is for the family home. Dad may want to see what son is taking so long in the bathroom for.
So, how is this different from the backdoors deliberately coded at the behest of a control faction? In all cases, if you know the "open sesame", or have a hairpin for the bathroom lock, you are in.
Business-grade security.
This is one area that I firmly believe that if you want it done right, do it yourself.
"Prove all things; hold fast that which is good." [KJV: I Thessalonians 5:21]
(Score: 3, Interesting) by VLM on Monday September 10 2018, @11:56AM (2 children)
One big happy VLAN, huh? There are non-security related issues with "everything on one LAN" such as accidental DDOS attacks.
Kinda like how 20 years ago people started putting IP phones on their own VLAN, I would guess people will start putting thermostats and door locks on separate VLANs.
Same "problem" with IP security cameras, if they're on a public VLAN (or, gasp, a DMZ) then just DDOS them.
Its is funny that in 2018 (well, in xxxx whenever they wrote the lock firmware...) there are still people trying to roll their own crypto and thus generating replay attacks by not including salt.
(Score: 3, Funny) by DannyB on Monday September 10 2018, @02:22PM
Get advice from a good security insultant.
If you are using a VLAN to keep things secure, but find that it is not secure, put the VLANs on a VLAN. If that VLAN isn't secure, then put those VLANed VLANs on a VLAN. Then if . . . oh, you get the idea.
Keep the VLAN or DMZ secure by not telling anyone that you are using one. Or don't enable any traffic in or out of a DMZ. Oh, wait . . . that might have unintended consequences.
If you're going to use a hardcoded crypto key, then at least keep it a secret by printing it on the inside of the company T-shirts.
If you're going to roll your own crypto, then keep it secure by rolling your own pseudo random number generator. And use an extra secure seed value that is hardcoded into your devices.
Log everything. But keep the format very simple. Don't divide things into complicated multiple columns which would make it possible to query and filter the log by time, or event type, or severity or other things. Generate plenty of log entry noise to obscure the interesting log entries from the bad guys. Don't make it possible to look for unusual patterns in the log. Unfilterable noise should be the only pattern.
If you eat an entire cake without cutting it, you technically only had one piece.
(Score: 2) by darkfeline on Tuesday September 11 2018, @03:33AM
Google famously started moving off of trusted networks after the Snowden revelations. Surprise, Google didn't take too kindly to having their wires tapped.
https://cloud.google.com/beyondcorp/ [google.com] (see the research papers)
Encryption and authentication is handled per endpoint. It doesn't matter if the network is compromised, since it's designed to allow employees to work securely even through Swiss cheese public Wi-Fi ...At least, poorly audited third party hardware notwithstanding.
Join the SDF Public Access UNIX System today!
(Score: 5, Funny) by MichaelDavidCrawford on Monday September 10 2018, @02:43PM (2 children)
Have you ever been in the Google lunchrooms?
Every lunchroom serves a different kind of cuisine; last time I was there we had Spanish Tapas.
And there's no cash registers!
Yes I Have No Bananas. [gofundme.com]
(Score: 0) by Anonymous Coward on Monday September 10 2018, @03:45PM (1 child)
Are all Google employees absolutely supposed to use their RFID keys or are they allowed to hold doors open for others? How about visitors? What's the procedure for determining whether an alleged visitor should be allowed in or not?
(Score: 2) by MichaelDavidCrawford on Monday September 10 2018, @05:32PM
While my memory is hazy, what I actually recall is that no one ever used them.
This because The Googleplex has bazillions of employees so there was always someone holding the door open for others.
Yes I Have No Bananas. [gofundme.com]
(Score: 1) by zzarko on Tuesday September 11 2018, @05:15AM
From Software House site: "... the iSTAR controller suite is among the industry’s most reliable and secure enterprise-wide access control devices.". If this is the "most reliable and secure", what would less reliable be? I do not trust ANY electronic lock that could be remotely operated.
C64 BASIC: 1 a=rnd(-52028):fori=1to8:a=rnd(1):next:fori=1to5:?chr$(rnd(1)*26+65);:next