Introduction ------------ Vulnerabilities were identified in the iStar Ultra & IP-ACM boards offered by Software House. This system is used to control physical access to resources based on RFID-based badge readers. Badge readers interface with the IP-ACM board, which uses TCP/IP to communicate with the iStar Ultra controller. These were discovered during a black box assessment and therefore the vulnerability list should not be considered exhaustive; observations suggest that it is likely that further vulnerabilities exist. It is strongly recommended that Software House undertake a full whitebox security assessment of this application. Additionally, it is our suggestion that all communications be conducted over TLS. While alternatives are suggested below, cryptography is very difficult even for experts, and so using a well-understood cryptosystem like TLS is preferable to home-grown solutions. The version under test was indicated as: 6.5.2.20569. As of the time of disclosure, the issues remain unfixed. Issues Found ------------ 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.) Impact & Workaround ------------------- An attacker with access to the network can unlock doors without generating any log entry of the door unlock. An attacker can also prevent legitimate unlock attempts. Organizations using these devices should ensure that the network used for IP-ACM to iStar Ultra communications is not accessible to potential attackers. Timeline -------- * 2017/07/01-2017/07/14 - Issues discovered * 2017/07/19 - Issues disclosed to Software House * 2017/08/29 - Issues acknowledged & proposed fixes discussed. Informed that current hardware could not be fixed and fixes would only apply to new products. * 2017/10/19 - 90 day window elapsed in accordance with disclosure policy. * 2017/12/18 - Public disclosure. Credit ------ These issues were discovered by David Tomaschik of the Google Security Team. -- David Tomaschik Security Engineer ISA Assessments Team Google, Inc.