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.
News at eleven.
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.
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?
> 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.