[Originally posted at ImplicitDeny]
Having been in this industry for a while, I’ve come to loathe vendors, especially those in highly vertical markets. In most of these markets, the hardware and software peddled by these vendors is rarely tested for security. Not only are there just not enough security professionals to go around, often enough these vendors actively avoid any kind of security review.
I’ve been in meetings where the vendor, when asked about encrypted PII (personally identifiable information), points at an obfuscated password field as proof of encrypted data – a critical misunderstanding of information security.
Frequently, I make it a personal mission to find the most obscure hardware and software I can, and find blatantly insecure practices. Practices that ultimately put their clients at risk. Clients who sometimes have little to no recourse once the vendor is paid.
A popular casino application was one of those pieces of software. Watching the vendor install the software made it apparent that something wasn’t right, and prompted me to dig deeper. Upon investigation, it was apparent they were using hardcoded passwords in their application. This is a problem due to the nature of data their system is designed to hold. Personally identifiable information of all kinds, including names, social security numbers, addresses, date of birth, and more are stored in this system.
Frustratingly, when contacted, the vendor first ignored the notice, then would only talk to me on the phone or in person. The last conversation I had, in person I might add, was that they had no plans to fix the vulnerability because the software was nearing the end of its life and that all clients should plan for the upgrade.
Product Overview
Published and supported by one of the largest casino gaming vendors in the world. They provide gaming terminals (slot machines) and other gaming technology. The software is used to track player incentive points, and player data.
Vulnerability Details
Known vulnerable: Version 10.0sp3
Build Version: 10.08.0301
Vulnerability Summary
A weakness in the client application would allow a local attacker to decrypt the database connection settings. These settings include an administrator-level username and password for connecting to the SQL database.
Impact
Using the information in the settings file, an attacker could connect to the SQL database and create, read, update and/or delete any records at the highest levels of access. The information in the database includes personally identifiable information, including SSNs. Automating this attack would be simple with free and readily available tools online. Furthermore, the attack would theoretically work at every gaming property running the same version of this software (more likely that many versions of this software are vulnerable).
Vulnerability Class
Software Weakness: Use of Hardcoded Credentials
The software contains hard-coded credentials, such as a password or cryptographic key, which it uses for its own inbound authentication, outbound communication to external components, or encryption of internal data.
Further Details
This software application is used to track players, their activities (loyalty programs), points, and personal information for tax and marketing purposes. Software is written in Microsoft .NET a “just-in-time” compilation. This means that the Common Language Runtime (CLR) converts the IL (intermediary language) code into machine instructions only when needed. .NET is trivial to disassemble using free and common tools. Using one of these tools (ILSpy), I was able to view the code for the connection manager and the Desktop application. Within both of these applications, the static string used to encrypt the database connection information was available in .cctor() or the static constructor. The key is stored as “ConnectionManager.Key”.
With these credentials, I wrote a simple Python script to decrypt the encrypted XML connection strings.
Conclusion
Any amount of application surface area that the client will have access to, has to be assumed as compromised. In other words, your vendors can’t rely on the integrity of a workstation to protect your data. Furthermore, a healthy dose of skepticism and “trust but verify” goes a long way in vertical industries that don’t yet have a strong security awareness culture. Ask the tough questions, and demand thorough answers from your vendors. Its better to know what skeletons they’re trying to put in your environment now, then to have a malicious actor find them for you.
bneg 