Knock, knock: Digital key flaw unlocks door control systems

Attackers could be able to unlock doors in office buildings, factories and other corporate buildings at will, thanks to a flaw in a popular door controller, discovered by a Google security researcher.
David Tomaschik, who works as senior security engineer and tech lead at Google, uncovered the flaw in devices made by Software House, a Johnson Controls company. Forbes reports that he conducted his research on Google’s own door control system.
Tomaschik, who described his project at a talk in August at DEF CON’s IoT Village, explored two devices. The first was iStar Ultra, a Linux-based door controller that supports hardwired and wireless locks. The second was the IP-ACM Ethernet Door Module, a door controller that communicates with iStar.
When a user presents an RFID badge, the door controller sends the information to the iStar device, which checks to see if the user is authorised. It then returns an instruction to the door controller, telling it to either unlock the door or to deny access.
Software House’s website still promotes the original version of its IP-ACM as a “highly secure option to manage their security”. But judging from Tomaschik’s research, that’s a bit wide of the mark.
The devices were using encryption to protect their network communication – however, digging through their network traffic, Tomaschik found that Software House had apparently been rolling its own crypto rather than relying on tried and tested solutions.
The devices were sending hardcoded encryption keys over the network, and were using a fixed initialization vector, which is an input to the cryptographic function that creates the key. Moreover, the devices didn’t include any message signing, meaning that an imposter could easily send messages pretending to be from a legitimate device, and the recipient wouldn’t check.
This key unlocked the kingdom, so to speak. It enabled him to impersonate Software House devices on the network, doing anything that they could. This included the power to unlock doors, or stop others from unlocking them.
To engineer such an attack, all an intruder would need is access to the same IP network used by the Software House devices. If a company hasn’t carefully segmented and locked down its network and lets these devices communicate over a general office network, and if the attacker can gain access to that, then it presents a potential intrusion point.

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.

Tomaschik blogged about it last December, and a CVE bug relating to this issue was published on 30 December last year. He discovered the issue in July 2017, telling Software House about it in the same month. The company acknowledged the flaw and proposed a fix.
The fix involved a change in the encryption system to an algorithm based on TLS encryption that doesn’t consistently send the same keys across a public network. On its product page, the company says of the v2 Ethernet Door Module:

IP-ACM v2 now supports 801.1X and TLS 1.2 secure network protocols for added protection against the threat of cyber attacks.

However, Tomaschik has argued that this alone might not be enough, because Software House systems’ original IP-ACM units didn’t have enough memory to cope with installing new firmware.
Software House admitted the inability to update the firmware for existing devices in an emailed statement to Naked Security:

We did notify customers that v1 of the product did not have enough physical memory to upgrade to TLS.

Google reportedly took steps to protect its offices by segmenting its network, but there are likely to be many pre-version 2 units installed in the wild that cannot be updated to fix the encryption key problem, and many companies that do not fix this issue. Ethernet-based door unlockers don’t have a speedy refresh cycle, after all.
The situation also highlights the difference between conventional and IoT products, Tomaschik said when blogging about his DEF CON talk (blog also contains slides):

It’s not meant to be a vendor-shaming session. It’s meant to be a discussion of the difficulty of getting physical access control systems that have IP communications features right. It’s meant to show that the designs we use to build a secure system when you have a classic user interface don’t work the same way in the IoT world.

Until a company replaces its door controllers with the new hardware, anyone with the code to execute an attack could theoretically gain access to its facilities. Tomaschik hasn’t released his proof of concept code, but that doesn’t mean someone else couldn’t engineer it.