Just say the ‘magic password’: Boffins turn up potential backdoor in SQL Server 2012, 2014

October 22, 2019 TH Author

Security researchers at ESET have published details of a backdoor into Microsoft’s SQL Server via hooks and the splendidly named “magic passwords”.

The backdoor, which targets SQL Server 2012 and 2014, has the ability to leave a miscreant with stealthy access to a compromised server and forms part of the arsenal of a malware group dubbed “Winnti” by researchers.

The Register spoke with ESET malware bod Mathieu Tartare about the research and the risk posed by backdoor.

Before any administrators get too panicked, it is important to note that actually getting the backdoor running on a server requires administrative-level privileges. If that’s a risk in your organisation, you arguably have quite a bit more to worry about than someone blowing a hole in SQL Server authentication.

However, assuming the nefarious code somehow finds its way into the directories of a SQL Server, it has the potential to leave a handy backdoor silently swinging in the breeze for bad guys to sneak in, copy, modify or delete data. This is assuming SQL authentication is being used and they know a username with sufficient privileges.

You did remember to do something about that default admin account, didn’t you?

Oh, and the technique does away with phishing for passwords, so long as the attacker knows the “magic password” embedded into the malware. Unsurprisingly, ESET has redacted that particular nugget.

Dubbed “skip-2.0”, the malware relies on being injected into a running process, in this case the venerable sqlserver.exe from where it grabs a handle to sqllang.dll and hooks multiple functions, principally those linked to authentication and event logging.

One function hijacked is CPwdPolicyManager::ValidatePwdForLogin, which validates the password for a given SQL user.

You can probably guess where this is going.

If the user enters the “magic password”, the original function is not called and the user is connected. Worse, a global flag is set for the other hooked functions to pick up to silence event logging and auditing.

It’s all a bit horrid and means that if you know the username of a SQL account, you can connect no matter how strong the admin thinks the password might be.

Of course, the approach does not work for Windows Authentication and, Tartare told us, will not work for disabled accounts.

There is some good news: as well as the level of privilege required to actually get the code required for this technique running on the server, it is also pretty easy to detect (for something that goes to such lengths to cover its tracks in SQL Server).

The success of the attempt to install the hook is written in cleartext to a logfile, hardcoded to C:\Windows\Temp\TS_2CE1.tmp\.

It seems a bit of an oversight on the part of the attackers. Tartare agreed, saying that it was “quite surprising” of the miscreants to leave the log file, but added that it was “usual to see some debug information in the malware – at the end of the day they are developers…”

We could think of an alternative name or two for the ne’er-do-wells.

Tartare told us that the exploit had been tried on other versions of SQL Server without success. He also added that if detected (by spotting that logfile or through an antivirus application) once the injection code was removed, a restart would clear the backdoor.

Unlike recent SSH backdoors (PDF), skip-2.0 is installed in-memory rather than needing an .exe modified prior to execution.

All told, it’s a nasty and stealthy password bypass backdoor. However, to make it work administrative privileges are needed to actually install the thing and, of course, the attacker needs to know a valid SQL username. So a victim really would have all kinds of other security hygiene problems on their hands.

We asked Microsoft for its thoughts on the bypass, and a mouthpiece said: “This technique will only work on SQL servers that have already been compromised. We advise customers to ensure their systems have the latest security updates installed, to use strong passwords and to only expose MSSQL servers to the internet if necessary.” ®