Software House iSTAR Ultra firmware verification and web application (tested through 6.9.2): The controller verifies

Impact

The controller verifies its firmware at boot, but the verification skips portions of the image - so an attacker who can push firmware gets persistent, boot-surviving code on the door controller that the device's own integrity check will happily bless. The companion issue is an authenticated OS command injection in the web application that escalates to root, which is a plausible way to reach the firmware write in the first place. This is the persistence problem in its purest form: you can re-image the panel, but if the attacker's implant is in the unverified region and you restore from a backup taken after compromise, it comes back. For a GPU operator the practical meaning is that door control - the boundary protecting drives, console ports and the OOB switch inside the cage - can be silently and durably owned, and no amount of log review will show it because the implant controls the logs. This is also a tenant-handoff failure: a panel compromised during one customer's tenancy stays compromised for the next one, since nobody re-flashes access-control hardware between tenants.

Who can reach it

The command-injection path requires an authenticated session to the iSTAR web application, so realistically credential theft, a default or shared integrator account, or chaining from one of the unauthenticated iSTAR issues. The firmware verification gap is then exercised by an attacker who already has that access. All of it lives on the physical-security VLAN.

What to do

Move to firmware later than 6.9.2 per Johnson Controls' guidance and confirm with the vendor that the verification gap is closed in the version you land on - the disclosure notes later firmware may also be affected, so a version number alone is not evidence. Because the flaw defeats integrity verification, patching is not sufficient for a panel you believe was reachable while vulnerable: replace it or have the vendor perform a full low-level reflash, and rebuild its configuration from a known-good source rather than a device backup. Operationally, rotate every credential on the access-control system, audit the account list for integrator and service accounts, and require MFA on any path to the iSTAR web application.

References