Google Found Software House Vulnerability Allows Inside Attacker To Open Doors

Published Sep 04, 2018 12:47 PM

A vulnerability in Software House IP-ACM modules allows an attacker to potentially unlock doors, or perform other actions, on affected systems. Many affected systems are unable to fixed with a software patch, requiring hardware replacement instead.

IPVM spoke with Software House executives to get more details on this exploit, in this report we provide an assessment of the risk in vulnerable systems, and what Software House recommends for affected users.

[Note: this post was first published in January 2018 but was updated in September 2018 when it was disclosed that a Google employee discovered the vulnerability, making it mainstream news.]

Vulnerability ******** - *** *********** *********

****** *** *** ****** *** ************* ** in *** ***** ***** ******, ******** House ****** **** ****** ****** ** not ***** *** ************* ****. *******, the **-*** ******** **** ****** ** *** ****** ********* ********. 

***** ** *** *** ******* ********** between *** **-*** **** ****** *** the ***** ***** ******* ********** ** handled, ** ******** *** ***** ****** to *** ******* ******* *** ******* could ******* ******* ******* ** * specific ******* (**** ** * **** open *******), *** **** ***** ****** those ******* ** *** ******* ** cause *** **** ** **** ** will. 

*** *** ******* **** ************* ***** these ******* ****** ****** **** *** network **** *** **-*** ** ***** Ultra ************** ** *** ********** ** potential *********. *** *******, ****** ***** on ******** ******** **** ******* ****** be ********, *** **** ******** ******** such ** *** ******* ******* ****** be *****.

*** ********* ******* ***** *** * typical ******* ***** ** ***** ***** and **-*** **** ******* ***** ** architected:

Replay ****** ******

** * ****** ******, ** ******** captures ******* **** * ******* ******** for ******* ********** (*.*.: *********), *** **** ******* ***** **** packets ** *** *******, **** *** result ***** ******* ********* ********* **** or ********, *** ****** ** **** as ** **** **** **** ** the ******** ******. ****** ******* *** occur **** **** ************** *** *********, because *** ******** **** *** **** to **** *** ******** **** ********* in *** *******, **** *** ******** outcome ** *** ****** ********* **** (e.g.: * ****** ** ******* **** says "**** **** ****", ** "***** this ****'* ********").

****** ******* *** ** ********* ** using *** **** ******* **********, *** also * ****** *** ** ******* ID *** **** ******* ********. *********, if ** ******** ******* * ******** with ** **/*** **** *** ******* been ****, *** ******** **** **** to ****** **. *******, ***** **** reduces *** ******* ** *** ****** attacks, ** ***** ******** **** ********* and ***** ************ ********* (**** ** those ******* * **** ********** *** an ****** ******* ******) **** *******. 

Current **-**** *** ***********

****** **** ************* ******** ******** ************ that *** **-*** ** ****** *******, due ** **** ** ****** *** processing *********. *** ** ** *** process ** ********* ** **-*** ** module **** ********* ********* ** *********** patched ********. ********* **** **** ** swap *** ** **-*** ***** *** V2 ***** ** **** **** ** remove **** *************. *** ****** ********* wishing ** ****** *** ***** *********** should ******* ***** ********** *** ******** House ******* ********* *** ********** ******* and ***********.

Low **** / ******** **********

************ ********** **** ************* ******** ****** to *** ******** ******* ******* *** IP-ACM *** ***** ***** ** ******* packets ** ** ******** *****. **** would ********* ******* ****** ****** ** a ********** **** ** *** ******, an **-**** ***, ** ***** ****** that ******** **** **** **** * PC ** *** **** *******, *** would ** ************* ********** ** ******* remotely *** * *** ** ****-********** setup. **** ******* *** ******* ** exploit *******, *** ****** ** ** more ** ** ******* ******. 

******* *** ****** ****** ** ****** to ******* ******* **** *** *******, the ******* **** ** ******* ** low. ***** **** **** *** **** that ******** ******* ****** ** *******, it **** ****** *** ****** ******* and **** ** ********* ********* ************ enough **** ********* ****** *** ****** their ***** **** ***** ***** ******** unlocked ** *******. 

Comments (8)
UI
Undisclosed Integrator #1
Jan 17, 2018

most IP-based POE controllers utilize 128 or 256 bit encryption between IP door controllers and the host software/master controller.  Is this article saying that Software House does not have 128/256 bit encryption built into their communication protocol? The controller to master communication is most likely a proprietary protocol (which makes it somewhat less prone to a hack agreed), but to not have even an optional setting where an encryption key can be set in the IP door controllers is not so good.

How is this supposed to meet specifications like the NIST spec for access control devices used on government facilities?

(2)
Avatar
Brian Karas
Jan 17, 2018
IPVM

Yes, the connection between the devices is encrypted.

Encrypted communications do not prevent replay attacks, they just prevent the attacker from knowing the specific protocol. You need to do additional things like adding session ID's to the commands to prevent replay attacks. I tried to cover this in the "Replay Attack Basics" section, without getting too deep into the details.

Think of it like this, I can teach you to ask "Where is the bathroom" in Japanese. You would not understand the specific words (analogous to a simple form of encryption), but you would know that making the "sounds" of asking "Where is the bathroom" to a Japanese person would cause them to point you to the bathroom. You do not fully understand the protocol (language), but you can repeat phrases to get a desired outcome. 

Expanding on the above example, if you wanted to prevent someone from using a "replay" of words like this, you would add additional information to the phrase, like "Where is the bathroom. This is request #1". The person you asked would then determine if somebody else had already made request #1, and if so they would refuse to answer your query, knowing that it was most likely a fake or duplicate. Adding the unique session ID prevents you from making an unauthorized request and getting a response.

 

(2)
(13)
Avatar
Michael Gonzalez
Jan 17, 2018
Confidential

Alternatively, you can also wait for the 2nd or 3rd generation of a new product before jumping on the upgrade bandwagon. That's generally how I sidestep these inevitable new problems. Glad I made that choice now... 

(6)
UE
Undisclosed End User #4
Sep 04, 2018

This illustrates a big frustration.  Integrators and End Users are often underpaid beta testers, we pay them (manufacturers) for the privilege of being such...

(5)
(1)
RL
Randy Lines
Jan 18, 2018

Time to reset my assumptions and up my crypto game! I have assumed their would be a session ID or time stamp to their encrypted packets. One thing that remains the same is that it is the implementation of encryption not the math where the bulk of vulnerabilities live. 

Great article!

 

(3)
U
Undisclosed #2
Sep 03, 2018

This made Forbes:  https://www.forbes.com/sites/thomasbrewster/2018/09/03/googles-doors-hacked-wide-open-by-own-employee

but the story doesn't mention that some devices have to be replaced.

 

 

(2)
U
Undisclosed #3
Sep 04, 2018

From the Forbes story:

"Tomaschik said Software House had come up with solutions to fix the problem, though to switch to TLS, it’d require a change of hardware at the customer site. That’s because the Software House systems didn’t have enough memory to cope with the installation of new firmware, Tomaschik said."

(1)
U
Undisclosed #2
Sep 04, 2018

Oops

(1)