Denial of service via interface modes

HCIsec is an emerging field that combines HCI with security. Basically, it is the science of figuring out how an interface influences the security of a system.

To give you a taste of what this is about, I will explain the concept of denial of service via interface modes.

I will focus on organizing a denial of service attack against a biometric lock that I happened to find nearby.

The system has a fingerprint scanner with a keypad, here's a very simplified view of how it works, many states and transitions were omitted:

1. The system is idle
2. Press * and do nothing - the system reverts to a default state after a timeout of about 15 seconds
3. Press * and scan an unknown finger - the system indicates that the fingerprint is not recognized and reverts to a default state
4. Press * and scan the finger - if the fingerprint is accepted, access is granted.

If you read the manual, you'll learn there's an admin mode which lets you do things such as enroll new users, change the admin PIN or delete the database of all fingerprint records. To enter admin mode, press 99# and enter the correct PIN.

The state machine above is what the designers had in mind, but that is not exactly the case. If I try to enter admin mode and then type a digit, the system enters another state - let's call it "waiting for PIN". The timeout setting does not apply to this state (the dashed red line below is not present in the actual implementation).

The implication is that an attacker can:

1. Press 99#
2. Type a random digit
3. Walk away

As a result, the system is going to continue waiting for the remaining digits of the admin PIN to be entered. If a person wants to use the system, they press * and swipe their finger... and nothing happens; the system is in another state (not idle) and it is waiting for a special type of input.

I must emphasize that the attacker doesn't need to know the real admin PIN. All they need to know is the magic sequence for entering admin mode - 99#, which is not secret and is given in the manual.

To get out of this state:

• Type ### to go to the previous state. A typical user is not aware of this.
• Type some other random digits to let the system read an incorrect PIN and go back to the default state. This is not good either, because a typical user will see that the scanner doesn't work and most likely choose not to do anything in order not to make things worse. Think of your grandma - do you predict that if an appliance doesn't work she will begin to press buttons randomly?
• Power-cycle the device - this is not possible, because in a properly designed system the power source and the power cord are hidden and unaccessible. Otherwise it would be easy to disable the system.

Effectively, a person is unable to use the system - that's why such attacks are known as "denial of service".

Recommendations that keep your system protected from such types of attacks.

• Remove command mode - no command mode, no problem. If you want to troubleshoot or configure the system, you'll need to bring some special hardware and connect it to a special interface, which is not accessible to anyone else, being physically isolated. It is tempting to have a command mode, because it facilitates debugging (no need to bring special tools); but it also creates another attack vector.
• Enforce a timeout for every state - ensure that the timeout rule is active for every state of the system, no exceptions.

The principle can be applied against terminals of any kind, as long as their designers were not careful about the transitions from one state to another. Such flaws become visible if you represent the system graphically, as a state machine. If all is in order - there must be a "timeout" arrow going back to the "idle" state from every other state. If there is one state that doesn't revert to the idle state after a timeout - it is a potential problem.

Comments