Update (Jan. 15, 2019): Identicard has responded to BleepingComputer stating that updates are in progress — https://pbs.twimg.com/media/Dw_IV-DX0AAFEa4.jpg.

Update (March 6, 2019): Identicard has notified Tenable that patches for the discovered issues have been released.

A few months ago, I decided to take a look at PremiSys IDenticard, an identification and building access management system. This software allows customers to create custom ID cards for personnel, manage access levels for specific rooms or regions of a building, and remotely manage ID readers and similar devices. At the time of this research, the version of the software I had permission to access was 3.1.190. I did not have access to any physical badge equipment or other components, so this research was fairly limited in scope. That being said, my efforts were not fruitless.

After finding a handful of flaws, some serious and others not-so-serious, Tenable Research attempted a coordinated disclosure with the vendor. After 45 days and several unsuccessful attempts to contact the vendor, Tenable Research disclosed its findings to CERT/CC, which made further attempts to contact the vendor. After 90 days, Tenable Research released its findings publicly. The following text details the discovery of a single hardcoded backdoor that gives administrative access to the badge system.

Threat Model Overview

As expected, the attack surface for such a feature-rich access control system is quite large. Creating a reasonable threat model for the entire badge system, badge printers, authentication mechanisms, locks, badges, etc. would have been impractical for the limited amount of time I had. Fortunately, since I didn’t have access to most of these components in the first place, simply targeting and mapping the attack surface of the hosting service was much simpler. After playing with the application for a little while to understand intended usage, pilfering vendor documentation, and peeking at the resources used by the service, I came up with the following:

The above image is missing quite a bit of content due to a drastically narrowed scope, but is suitable enough to give a frame of reference during the research process.

That’s an Interesting Function Name

PremiSys is a .Net based application. Fortunately, there is a myriad of tools available for reversing .Net applications. My preference for this scenario was Jetbrain’s dotPeek, a .Net decompiler. In my experience, this tool is relatively quick and accurate. It also has an interface that allows easy navigation, search, and the ability to bounce between references to code or related content.

From the threat model, there are five distinct endpoints available to investigate. This means that when browsing the decompiled codebase, I should focus on functionality related directly to those endpoints — ideally with special attention paid to functionality influenced by user input. To keep this post brief, I’m going to gloss over the poking and prodding of the source and skip straight to the good bits.

There is a module in the codebase called PremiSysWCFService. From documentation and an end-user’s perspective, it would seem that this service is designed to act as a dashboard for the primary application server and as an internal WCF endpoint for other client devices and services. WCF (Windows Communication Foundation) is a framework for building service-oriented applications. It’s similar to SOAP or REST in that data is exchanged between endpoints, but different in that it requires special implementations in order to interact with it. On the surface, it looks like this endpoint mostly exists to serve summary information about the service and connected devices (badged-in users, problematic doors, etc.), but after digging deeper, it turns out to be able to do so much more.

In the PremiSysWCFService module, we found code referencing what looks to be your standard, run-of-the-mill authentication routine. Take a closer look at that routine:

namespace IDenticard.Common.Security

{

...

public static class ApiSecurity

{

private static readonly IDMembershipProvider UserManager = (IDMembershipProvider) Membership.Provider;

private const string AdminShortCircuit = "IISAdminUsr";

private const string PasswordShortCircuit = "Badge1";



[Localizable(false)]

public static void AuthenticateLogin(string username, string password)

{

if (!ApiSecurity.IgnoreAuthentication(username, password) && !ApiSecurity.UserManager.ValidateUser(username, password))

throw new Exception("Login Failed, unable to proceed.");

}



private static bool IgnoreAuthentication(string username, string password)

{

if (username == "IISAdminUsr")

return password == "Badge1";

return false;

}

}

...

}

Yes, IgnoreAuthentication() does exactly what you think it does so long as the user-provided credentials match the hardcoded values. While a more dedicated attacker would likely develop a custom WCF client to interact with this service endpoint, I decided to take a shortcut and use WCF Storm LITE, a free testing application for WCF services. It does all the magic of enumerating available methods and input parameters for you, while also providing an interface that allows you to manipulate and submit requests on-the-fly.

As it turns out, this hardcoded backdoor allows attackers to add new users to the badge system, modify existing users, delete users, assign permission, and pretty much any other administrative function.

Misplaced Priorities

Most people don’t realize that many companies rely on third parties to install and maintain their badge systems. It isn’t uncommon for these third parties to install the systems with default settings and leave, only to come back months later to apply updates for a fee. This is where priorities become skewed. The access control vendor makes software that a third party installs for a customer. The customer uses what they need while leaving many features unused but still enabled. This leads to unnecessary cyber exposure of critical physical security infrastructure, and a possible entrypoint into the digital infrastructure.

While badge systems should be isolated from the rest of the network, we all know that not everyone is going to follow best practices. Additionally, it’s likely most people administering these applications aren’t even aware of all the extra features and doodads that come built-in. In a production deployment, the attack surface of this single service would be absolutely massive. If a company is depending on it for physical security, simple and critical software errors like these have to be taken seriously.