A Google Engineer Discovered a Vulnerability Letting Him Take Control of Keycard-Controlled Doors

Illustration for article titled A Google Engineer Discovered a Vulnerability Letting Him Take Control of Keycard-Controlled Doors
Photo: Leon Neal (Getty Images)

A Google engineer discovered a vulnerability in the third-party system controlling access to doors across its campus in Sunnyvale, California, and took the opportunity to prove that he could bypass any RFID keycard-operated lock in the facility, Forbes reported on Monday.


According to Forbes, employee David Tomaschik discovered that Software House devices connected to Google’s network used an unsecure, hardcoded encryption key, and launched the attack to prove the consequences that could arise:

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 was also able to use his knowledge of the vulnerability to impede other Google staffers’ access to parts of the building. Worst of all, he could do all of this without leaving any trace:

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.

Google told Forbes they had no evidence that any malicious hackers had exploited the vulnerability previously to its discovery by Tomaschik. The Software House devices’ design has since been updated to increase security, though the original devices cannot be updated by any method short of a hardware replacement due to memory restrictions, Forbes added.

It’s easy to see why this is a particularly glaring issue—in addition to the safety of Google staff, the company’s owner Alphabet is one of the tech companies racing to be worth a trillion dollars. So its facilities are not exactly the kind of places it would be great to have randos freewheeling around. And as Forbes noted, Tomaschik is concerned that there are only a few manufacturers of RFID keycard security systems, meaning that the Software House vulnerability is likely present in an alarming percentage of those already installed across the country.



"... An upperclassman who had been researching terrorist groups online." - Washington Post


I’d say the main concern isn’t the readers themselves - they’re probably standard wiegand style card readers in most places. They use a four-wire connector (telephone style) to communicate to a security relay panel. I’d wager the networked wireless/wired ones are a standard reader with a microcontroller popped in the frame. Now you don’t need that fancy of a reader - what you could do is take something like a pi-zero or even a little arduino and wire it up to the reader, which would then put that reader on the network. So if you cook up some code to replace the botched security encryption and then transmit a hash of the card number, DTS, pad-code, and door number through the encryption, you can then use that same hash as the key for the return code making it a one-off. Then you wire up a solenoid to the arduino/pi to trigger the lock access. You could also wire up a local motion sensor on either side of the door and of course the magnetic open/close switch. The card info isn’t big, so what you can also do is have some cards stored encrypted on the device, so that if your central server goes down, security can still access areas, and you can still have local logs of who comes and goes via the door on swipe. So if someone had a deactivated card but killed the central server before the update could be sent to the remote devices - at least you *know* who popped in for dinner. As long as the local device’s wireless/wired user isn’t “user” and the password isn’t “12345" I think you’ll be fine.