3

I'm working with a piece of software that handles all permissions in a Windows client binary on the user's computer. The software connects to a backend database using the sa account. The sa password is stored encrypted in a config file on the client, but the client obviously must decrypt it before authenticating with the database.

I've been able to recover the sa password in various ways including using a debugger, searching a memory dump, and searching memory directly with WinHex. I'm curious if there are tools or malware out there that would make this vulnerability even more easily exploitable. The password is stored in memory as a MSSQL connection string the entire time the client process is active.

Is there malware that is known to search memory for connection strings in order to exploit this sort of vulnerability? Are there tools that a user could download that would do this automatically, or is there a decent amount of technical knowledge required in order to exploit this?

jncraton
  • 143
  • 5

4 Answers4

3

You have demonstrated one of the downsides of using SQL Server Authentication as opposed to Windows Authentication. This is why Microsoft recommends using Windows Authentication unless you have a good reason not to. Here is a description of the pros and cons of each. Notably:

The encrypted SQL Server Authentication login password, must be passed over the network at the time of the connection. Some applications that connect automatically will store the password at the client. These are additional attack points.

Here is another Microsoft article which talks about how to secure SQL Server connection strings for Entity Framework, but the same rules apply even if you aren't using EF. This statement reiterates why they recommend always using Windows Authentication:

Be aware that logon information and passwords may be visible in a memory dump.

When data source logon and password information is supplied in the connection string, this information is maintained in memory until garbage collection reclaims the resources. This makes it impossible to determine when a password string is no longer in memory. If an application crashes, a memory dump file may contain sensitive security information, and the user running the application and any user with administrative access to the computer can view the memory dump file. Use Windows Authentication for connections to Microsoft SQL Server.

As for whether or not any existing malware applications take advantage of this? Certainly we know that they can exist, and you have proven this yourself. All that is required is for an application to be run with enough permissions to view the memory of another application that stores passwords in memory. The tricky part is it's likely that you would need to know how the memory is laid out in order to take advantage of this. In other words you would probably need to know how the application works first, and then build your memory sniffer around it. Perhaps there are general keywords you could search for, but that would require quite a bit of luck. Kind of like searching the ocean floor for lost ships that might still have some treasures in them; at some point the cost/reward just doesn't make it worth it.

That being said, if you knew that a particular (popular) application had this sort of security flaw in it, you could attempt to design malware that is tailored to that application, and then target that application's users to try to convince them to install your malware on the same machine.

Community
  • 1
TTT
  • 9,122
  • 4
  • 19
  • 31
1

Memory sniffing malware is in common use by attackers for scraping account numbers from POS systems. Most RAM scrapers are driven by a configurable regexp, where the attackers search another process's memory for the pattern of an account number.

The pattern being searched for is fully configurable by the attacker. There would be nothing stopping such software from being reconfigured to search another app's memory for strings like "Provider=", "UID=", "PWD=", or other data that might be present in a database configuration string.

Whether or not any attackers have done so in real life is a question for the forensic investigators (or the attackers.)

John Deters
  • 33,650
  • 3
  • 57
  • 110
1

The provided answers were all helpful, but none actually pointed me to a tool that does this quickly and automatically. I've written one myself that quickly scans a Windows process's memory using configurable settings. Here's the project on Github if it's useful to anyone else:

memvulnscan

jncraton
  • 143
  • 5
0

I think the more likely path for an attacker would be to simply sniff the wire for the password. If an attacker has low level enough access to sniff memory, they should also have enough access to run a packet sniffer and just look for SQL Server connection strings on the unencrypted wire. (SQL Server generally has an unencrypted connection).

You'd then have the added advantage of being able to sniff any other unencrypted connections, which for business applications are many. With the right sniffer architecture, it'd be trivial to be able to add new and interesting things to sniff for, including SQL Server connections.

Whether this malware exists I don't know, but it's be far more general purpose than something that specifically targets SQL Server authentication.

Steve Sether
  • 21,480
  • 8
  • 50
  • 76