Attackers could unlock doors in office buildings, factories and other corporate buildings at will, thanks to a flaw in a popular gate controller discovered by a Google security researcher.
David Tomaschik, who works as a senior security engineer and chief technology officer at Google, discovered the flaw in the devices created by Software House, a Johnson Controls company. Forbes It informs that it carried out its investigation on the own system of control of doors of Google.
Tomaschik, who described his project at a talk in August at the IoT Village of DEF CON, explored two devices. The first was iStar Ultra, a Linux-based gate controller that supports both wired and wireless locks. The second was the IP-ACM Ethernet Gate Module, a gate controller that communicates with iStar.
When a user presents an RFID credential, the door controller sends the information to the iStar device, which verifies if the user is authorized. He then returns an instruction to the door controller, telling him to unlock the door or deny access.
The Software House website still promotes the original version of its IP-ACM as a "highly secure option for managing its security". But judging from Tomaschik's research, that's a bit broad.
The devices used encryption to protect the communication of their network. However, when investigating the traffic of his network, Tomaschik discovered that Software House apparently had implemented its own encryption instead of relying on proven and proven solutions.
The devices sent encoded encryption keys through the network and used a fixed initialization vector, which is an input to the cryptographic function that creates the key. In addition, the devices did not include any signature of messages, which means that an impostor could easily send messages that pretended to come from a legitimate device and that the recipient would not see them.
This key opened the kingdom, so to speak. It allowed him to pass himself off as Software House devices on the network, doing everything he could. This included the power to unlock doors, or prevent other people from unlocking them.
To design such an attack, all an intruder would need is access to the same IP network used by the House of Software devices. If a company has not segmented and carefully blocked its network and allows these devices to communicate through a general office network, and if the attacker can access that, then it presents a possible point of intrusion.
We asked Software House for a statement on this, and a spokesperson said:
This problem was publicly reported at the end of December 2017. At the beginning of January 2018, we notified our customers of the problem and our plans to solve it with a new version of the product. We launched that new version that addresses the problem at the beginning of February 2018.
Tomaschik blogged about it Last December, and on December 30 of last year, a CVE error related to this problem was published. He discovered the problem in July of 2017 and told Software House the same month. The company acknowledged the failure and proposed a solution.
The solution involved a change in the encryption system to an algorithm based on TLS encryption that does not constantly send the same keys through a public network. On its product page, the company says about the Ethernet door module v2:
IP-ACM v2 now supports the 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 the original IP-ACM units of the Software House systems did not have enough memory to cope with the installation of a new firmware.
Software House admitted the inability to update the firmware of the existing devices in a declaration by email to Naked Security:
We notified customers that v1 of the product did not have enough physical memory to upgrade to TLS.
It was reported that Google took measures to protect its offices by segmenting its network, but it is likely that there are many pre-version 2 units installed in nature that can not be updated to solve the problem of the encryption key, and many companies that do not solve this problem. Ethernet-based door unlocks do not have a fast update cycle, after all.
The situation also highlights the difference between conventional products and IoT products, said Tomaschik when blogging about his DEF CON talk (the blog also contains slides):
It is not supposed to be a shameful session of the seller. It is intended to be a discussion of the difficulty of obtaining physical access control systems that have the correct IP communication functions. It is designed to show that the designs we use to build a secure system when it has a classic user interface do not work the same way in the IoT world.
Until a company replaces its door controllers with the new hardware, anyone who has the code to execute an attack could, in theory, access their facilities. Tomaschik has not published his proof of concept code, but that does not mean that someone else can not design it.