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.
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.
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.
I am Slashdot. Are you Slashdot as well?
There is a risk to fully automatic organizations like that.
https://idiallo.com/blog/when-...
Can be pretty scary when there are no checks and balances to the automation.
Why aren't you encrypting your e-mail?
> 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.
when he said this...
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.
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.