Hardcoded Credentials in Kiosk Software Allowed Remote Attackers to Compromise API
Uniguest provides kiosks to the hospitality, senior living, specialty retail, education and corporate sectors. The kiosks typically run a locked down version of Windows, and are managed by Uniguest rather than, for example, the hotel customers. With so many kiosks in so many different locations, that management inevitably involves the cloud — and when the cloud is involved there are often security lapses.
Founded in 1986, the company claims to have managed service contracts for 32,000 kiosks across 15,000 client locations.
Starting with nothing more than a Google search, researchers from Trustwave SpiderLabs found a Uniguest website (ucrew.uniguest.com) that had been publicly exposed on the internet. This website appeared to contain all the tools that technicians would need to deploy or manage a kiosk on location. From this simple observation, the researchers were able to develop a train that would ultimately enable them, in their own words, to “dump all the data in the Uniguest cloud database, which includes admin, router and BIOS passwords, product keys and various other sensitive information, for what looked like all of Uniguest’s customers.”
The first problem is that there was no required authentication for access to the ucrew.uniguest.com website. The researchers noted and were interested in one particular application: SystemSleuth. SystemSleuth is written in C# and easily decompiled with something like dnSpy. Its purpose is to collect asset information, such as product keys, asset tags, passwords and various other data, and send it to a Salesforce API.
Here was the second problem — the Salesforce API credentials were hardcoded into SystemSleuth and obligingly labeled sfUserName and sfPassword. “The Salesforce API is accessible via the SOAP protocol and we can use the open source SoapUI tool to run some test queries,” note the researchers.” By using the hardcoded credentials, the researchers were able to obtain a session key that they could use in subsequent requests.
With the information that was then available, “adversaries could deploy keyloggers, remote access trojans and various other forms of malware, attacking hotel guests or business patrons just passing through.” This would put anything done at risk — booking and paying for a flight, renting a car, checking emails or general browsing.
SpiderLabs disclosed their findings to Uniguest, who rapidly placed ucrew.uniguest.com behind an authentication portal. SystemSleuth will remain on the individual kiosk systems until such time as Uniguest is able to reimage them all, and this remains a problem. Locking down the individual Windows boxes against someone who has access to the system is hard.
“Restrictions imposed by Active Directory Group Policy Objects (AD GPOs) or custom Explorer shells are often trivial to bypass, giving attackers access to the whole system,” say the researchers. They demonstrated a successful sandbox escape on one of the kiosks, “revealing SystemSleuth.exe on the disk, ready to be exfiltrated and analyzed.”
The disclosure process was easier and more rewarding than with some vendors. “All software has vulnerabilities to a greater or lesser degree. A good judge of the security posture of any vendor is not if vulnerabilities are found in their products, but how quickly and seriously the vendor addresses those vulnerabilities.” Uniguest were a pleasure to work with. “They took the reports seriously, worked hard to address the issues on legacy products and had have taken steps like incorporating application and physical penetration testing to their product development lifecycle.”
The only SpiderLabs recommendation rejected by Uniguest involved an open ‘connect’ API that could be used via an unauthenticated GET request to obtain a range of information. Uniguest does not believe this is a vulnerability, telling SpiderLabs, “The information returned by this API is publicly available information that does not contain any PII data.”
SpiderLabs has several recommendations for companies in a similar position. First and foremost, they say, “If you’re thinking about using a SystemSleuth-like application in your deployments, don’t.” If you have to, use a write-only API-key, deploy per customer databases, and do not reuses API keys or credentials between customer deployments. And, of course, do not hardcode credentials into an application — especially one that is easily accessible by adversaries.
“Some companies use obfuscation to hide credentials in their software,” Ed Williams told SecurityWeek. But that’s just a short-term approach. It might slow down an attacker, but will rarely defeat a determined adversary. “You need to get away from hardcoded credentials altogether,” he said.