You might have taken all the right steps to secure a corporate Windows workstation: your users are not running as local admins, endpoint protection is in place, service ACLs and file permissions are locked down, etc. Yet there is still a frequently overlooked enterprise software weakness that could let an attacker escalate their privileges on the domain.

Oftentimes, there are enterprise-grade (large, bulky, expensive, of the do-not-fix-it-if-it-ain’t-broken kind) applications that are deployed in a rather insecure fashion.

In the past couple of internal engagements, we have run into thick client applications — usually financial reporting suites or accounting programs — that would connect to some kind of a centralized system (usually a database), but present the UI locally.

While these thick client apps might have “per user” login functionality, there would be an additional high-privileged database account on top of “per-user” login functionality, such that it would be used for “backhaul” communications with the server using an ODBC connection. One of the basic security principles is that client-side security can’t be relied on. If the account is used on the client — no matter if its password is encrypted within a configuration file, obfuscated, hardcoded in the executable — one way or another, a motivated user will be able to get to it.

If the password is pulled from an encrypted configuration file, the attackers might also be able to get access to the decryption key, which a lot of times, is static. And that, in turn, will give the bad guys the ability to decrypt configuration files elsewhere on the network, which may result in them getting more and more passwords as they expand their access.

This can be done by the malicious user (or a malicious agent acting on user’s behalf) reverse engineering the program executable and figuring out where the password is coming from and how the program decrypts it. Or better yet, they can just dump the process memory and attempt to fish the password out. If the thick client touches the password, it will be tough to make it even reasonably secure.

Equipped with the password, the attacker will pivot and likely gain access to the application’s database, which at least can get them access to the data they should not see. And at worst, they will be able to take over the database and escalate their privileges on a server and go on their merry way compromising the rest of the network. Keep in mind that passwords are frequently re-used, and compromise of one password may mean the compromise of more than a single system.

So consider taking a close look at the software installed on a standard employee workstation and asking yourself how it is architected and whether it might be using privileged accounts to connect to some important network database. If it is, here are a few things you can consider as a risk mitigation:

  • check if it is possible to connect to a remote system with the identity of the user as opposed to a privileged account
  • check if the access of the “backhaul” account can be restricted to mitigate the potential compromise of that account
  • if nothing else seems feasible, check if it’s possible to limit the distribution of the vulnerable software and its configuration files to only the users that need the software as opposed to making it part of the standard system configuration

Don’t be shy of asking the software vendors that question too. They might very well have some recommendations on how to mitigate the risk.