Google's Doors Hacked Wide Open by Own Employee

Many years ago at Georgia Tech, a student noticed that the network controlling the magnetic ID card-controlled doors was trivially controllable. He scheduled a talk about it at a local hacker conference, and what followed was the company that installed the system, Blackboard Inc, filed cease and desists and a lawsuit alleging violations of the DMCA, theft of trade secrets, violations the Espionage and Sedition Act, and presumably maritime piracy.

> Tomaschik also discovered he could do all this without any record of his actions.

> A Google spokesperson said there was no evidence the doors had been exploited by any malicious hackers.

Hmmm...

‪“Tomaschik also discovered he could do all this without any record of his actions.” ... “A Google spokesperson said there was no evidence the doors had been exploited by any malicious hackers.” ‬

In my (tbh quite limited) experience, I have found that physical security devices are some of the worst offenders when it comes to connecting to anything more complex than a simple RFID-tag. I wonder why there are no (or few?) companies that get their devices properly audited before release. I personally would pay much more for devices that have an independent audit published.

As the article says, it's a much broader problem. Maybe the title ought to be "Software House security devices compromised by Google employee".

> Tomaschik also discovered he could do all this without any record of his actions.

... three lines later ...

> A Google spokesperson said there was no evidence the doors had been exploited by any malicious hackers.

Yeah no shit.

IMO this is very bad to release as a news article.

> ...he could simply replay legitimate unlocking commands, which had much the same effect. ... And he could prevent legitimate Google employees from opening doors.

This is script-kiddie material. You don't even need the mental chops to reverse the encryption being used, you can just quietly sniff the corporate LAN and you're done.

> Tomaschik also discovered he could do all this without any record of his actions.

The obvious interpretation of this is that, if there's any logging at all, it's being done at a higher level. But I realized this might also mean that the locks communicate via UDP broadcast packets, which explains why this person was able to do this research in situ.

> ... problems likely remain for others using the vulnerable Software House tech. Tomaschik said Software House had come up with solutions to fix the problem, though to switch to TLS, it’d require a change of hardware at the customer site. That’s because the Software House systems didn’t have enough memory to cope with the installation of new firmware, Tomaschik said.

The reason I think this is bad to discuss is that infrastructure like this is generally installed and expected to work for years. Obviously a bunch of sites have quietly upgraded to the v2 boards that now do TLS (yay, capitalism...?), but many many more won't. Indeed, as of the time the article was printed, even Google hadn't yet!! See:

> Meanwhile, Google has segmented its network in order to provide protection for the vulnerable systems still in its properties, the spokesperson added.

I expect they'll be upgraded soon enough, and that VLANing building infra was something netops could just do immediately.

But what about all the sites that aren't told? They'll surely all be high-value targets, if I presume that Google are going to use systems appropriate for high-value enterprises.

I guess my (unanswerable?) question now is what kind of contract wording is used to stipulate security updates and full disclosure to clients.

It seems that Google employees have nothing to do so they just play around trying to hack stuff around the office. Obviously it took a lot of time to research this.

It's disturbing to think how much they get paid to do nothing.