Imagine a place a potential attacker would be highly motivated to enter. The back area of a bank branch, a datacenter, a medical research facility, a corporate office full of sensitive documents, Scrooge McDuck’s famous Money Bin. Imagine they all had rock solid locks on their doors. I could try dynamite, or a sledgehammer, or an straightened out paper clip, and none of those things could get a door to open no matter how hard I tried. Looks like a pretty good security control, right? But then I notice that underneath the doormat there’s a spare copy of the physical key that unlocks the door. Ha! The bypass method is so simple! Now imagine the digital version of what I just described.
Google senior security engineer David Tomaschik doesn’t have to imagine it. He’s seen it himself.
The vulnerability he discovered pertains to the iStar Ultra and IP-ACM Ethernet Door Module door controllers from Software House. They’re both IoT (internet of things.) He initially discovered the vulnerability by testing the doors at Google’s Sunnyvale offices.
“The communications between the IP-ACM and the iStar Ultra is encrypted using a fixed AES key and IV. Each message is encrypted in CBC mode and restarts with the fixed IV, leading to replay attacks of entire messages. There is no authentication of messages beyond the use of the fixed AES key, so message forgery is also possible. A working proof of concept has been demonstrated that allows an attacker with access to the IP network used by the IP-ACM and iStar Ultra to unlock doors connected to the IP-ACM. (This PoC will not be disclosed at this time, due to the issue remaining unfixed.)”
I see some of the problems right away. Fixed AES keys means that there are only a certain number of them that these devices use. The keys are more likely to be reused, and a cyber attacker could acquire a key from one device and possibly use it to decrypt another, or even to decrypt communications with the same device. Why can’t the keys be dynamically generated? Replay attacks of entire messages are possible... exactly! Message forgery is possible because the devices that try to unlock through the door controllers don’t have to be device or message signed. A cyber attacker doesn’t even have to bother spoofing a legitimate door unlocking device. Any similar RFID device could do. Tomaschik made a proof of concept and it worked, but he responsibly refrained from publishing it so a cyber attacker wouldn’t benefit from what he learned.
“Once I had my findings it became a priority. It was pretty bad,” Tomaschik said. He could even lock legitimate Google employees out!
A cyber attacker could start his or her exploit simply by finding the IP network that’s being used by the iStar Ultra and IP-ACM Ethernet Door Module devices. Just a little bit of war driving could find the entry point if the organization’s network isn’t properly locked down and segmented, which is a frequent occurrence. There’s the doormat, and lifting it from the ground reveals the spare key.
Tomaschik reported the vulnerability to Software House on July 19th, 2017. On August 29th, Software House told him that currently deployed devices couldn’t be patched, but future devices would be hardened against the vulnerability. By December 18th of last year, Tomaschik disclosed publicly.
“This issue was publicly reported at the end of December 2017. In early January 2018, we notified our customers of the issue and our plans to address it with a new version of the product. We released that new version addressing the issue in early February 2018.”
If you think our story ends here, hold on to your seats.
Software House< said IP-ACM v2 supports 801.1X and TLS 1.2 secure network protocols. Unfortunately Tomaschik noticed that the original IP-ACM units didn’t have enough memory for new firmware.
Very few vendors make IoT door locks for the enterprise market. According to Tomaschik, that means there are still lots and lots of vulnerable Software House controlled doors out there. Oops.