Most denizens of corporate America are pretty familiar with building security, and the requirement to swipe a badge to enter a building or an office suite; and as a result, most workers likely go about their day feeling secure that their stuff is physically secure from outsiders. Unfortunately, it turns out that multiple zero-day vulnerabilities in the PremiSys access control system mean that any sense of security may be a false one.
PremiSys, a building security system developed by IDenticard, has been found to rely on hard-coded and difficult-to-change default credentials for key administrative functions. Not only does this threaten the integrity of door controls and access restrictions, but the system also collects detailed facility data and integrates with video monitoring systems. That in turn opens up a data exfiltration/reconnaissance vector as well as a physical security concern.
The vendor has remained mum on the vulnerability – Tenable, who discovered the flaws, pointed out that it has made multiple attempts to engage IDenticard, to no avail. The 90-day disclosure period ended on Jan. 3, so the research team has gone public with the unpatched issues. It also notified the Computer Emergency Response Team (CERT). As of this writing, the vendor still hasn’t responded, Tenable told us.
The vulnerabilities are confirmed in versions 3.1.190 of PremiSys IDenticard, and may be present in the latest version – the vendor didn’t respond to a request for a test copy, Tenable said, so its security profile is unknown for now.
Malicious Access Control
The most concerning flaw that Tenable found is CVE-2019-3906, which has to do with hardcoded credentials that provide remote administrator access to the entire shebang.
The system uses something called the PremiSys Windows Communication Foundation (WCF) Service, which allows customers to create custom ID cards for personnel, manage access levels for specific rooms or regions of a building, and interface with other systems and remotely manage ID readers and similar devices.
“Users are not permitted to change these credentials,” Tenable explained in an advisory. “These credentials can be used by an attacker to dump contents of the badge system database, modify contents or other various tasks with unfettered access.”
In a real-world scenario, according to Jimi Sebree, senior research engineer at Tenable, this allows attackers to make use of what is essentially a hardcoded backdoor. This “allows attackers to add new users to the badge system, modify existing users, delete users, assign permission and pretty much any other administrative function,” he said in a blog on CVE-2019-3906.
Speaking to Threatpost, he elaborated: “If an attacker wanted physical access to a building, they could create a new badge for themselves in order to get past security. They could also disable locks on demand or give themselves entry rights to areas of the building they normally wouldn’t have access to.”
Fortunately, the credentials can’t be found online, Sebree told us – but once an attacker does uncover them, they can be used at any organization with this system in place.
Other Flaws
The other flaws are slightly less severe, but nonetheless concerning. CVE-2019-3908 for instance has to do with a different hardcoded password, for backups.
“Identicard backups are stored in an idbak format, which appears to simply be a password-protected zip file,” according to the report. “The password to unzip the contents is hardcoded into the application (‘ID3nt1card’).”
An attacker could use this information to clone an existing badge for building access.
A third flaw, CVE-2019-3907, arises from the fact that user credentials and other sensitive information are stored with a known-weak encryption method (Base64 encoded MD5 hashes – salt + password), which could open the door to data exfiltration and the ability to move laterally through the network to, say, access the video surveillance system or other information.
And finally, CVE-2019-3909 has to do with the use of hard-to-change default database credentials, which could give full access to the service’s databases. Users can’t change this password without sending custom passwords to the vendor directly in order to receive an encrypted variant to use in their configurations. Worse, it’s well-known what the defaults are.
“Only some of the hardcoded credentials can be found online,” Sebree told Threatpost. “The WCF credentials could not be found online, but the default database credentials can be found in vendor documentation.”
The default database username and password combo of “PremisysUsr/ID3nt1card” (and there are also instructions for meeting longer password standards by using “ID3nt1cardID3nt1card”) can be used by attackers to access the sensitive contents of the databases, such as building survey data or entrance logs. Malefactors could also modify or delete the database’s contents (so, someone could for instance erase evidence that a certain door was accessed at a certain time).
According to its website, IDenticard has tens of thousands of customers around the world, including Fortune 500 companies, K-12 schools, universities, medical centers and government agencies. But in the absence of a vendor patch, mitigation is a blunt instrument, according to Sebree.
“First, end users should confirm that these systems are not connected to the internet,” he told us. “They should also segment their network to ensure systems like PremiSys are isolated from internal and external threats as much as possible.”
Unfortunately, these types of security oversights are far from rare.
“Hardcoded and default credentials still occur with some frequency,” Sebree said. “News breaks pretty regularly about the use of hardcoded credentials. But while it’s not uncommon to find the use of hardcoded credentials, it’s certainly not a security best practice.”
Threatpost reached out to IDenticard and will update this post with any response.