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.