FingerTec Unauthenticated Remote Enrollment and Disclosure Vulnerability

    Type

  • Remote Enrollment, Information Disclosure

    • Severity

  • High

    • Affected products

  • AC900, M2, R2 have been tested

    • CVE Reference

  • None
Timeline
07/07/2016Vulnerability discovered
08/07/2016FingerTec contacted
20/07/2016Advisory updated with additional authentication information
02/08/2016ZKTeco contacted
28/08/2016Fix released to FingerTec engineers (unverified)
10/01/2017Advisory published

Description

FingerTec access control devices allow remote unauthenticated enrollment by any malicious user who has network access to the device. Additionally, the devices disclose the user IDs, PINs, RFID numbers, and names of any enrolled users without authentication.

Impact

An attacker with network can grant themselves the ability to bypass the physical security implemented by the FingerTec systems.

Cause

While the device can use authentication, it is disabled by default, and relatively weak. The device does not use any sort of encryption. Additionally, the user manual for the AC900s and R2/M2 readers located at:
http://www.fingertec.com/customer/download/postsales/HUM-AC900R2-E.pdf

Explicitly recommend setting the COMM Key to 0. The documentation for Ingress located at: 

http://www.fingertec.com/customer/download/postsales/SUM-Ingress-E.pdf

Recommends setting a weak key (5 character).

Interim Workaround

The devices should be either disconnected from the network, or segregated so that nothing may access them except for the Ingress Server. The devices should also have the COMM Key set to a 6 digit number. This in and of itself is not sufficient to protect the device though. For an AC900, the entire keyspace can be brute forced in under 3 days.

Solution

While there is authentication available for the device, there are no countermeasures in place to prevent brute force attacks, and the key space is relatively small (only 999,999 entries). Ideally, when the device is activated with either an Ingress server or a TCMS server, the server should set a random 24-bit password. This would still work with the current password hashing scheme in use by the API. The device should provide some sort of brute force protection, such as stepping off the response times after X number of failed authentication attempts, or locking out an IP for a certain amount of time after a set number of failed authentication attempts. Additionally, the devices should use strong encryption when communicating with the server.

Technical details

 See attached advisory PDF for technical details.