Skip-2 is the name of a software package that lets what appears to be state sponsored hackers attack your SQL Server data and download, change or delete data without the auditing that you have configured being triggered. I won’t go in to the details of how skip-2 works, as the folks at ESET have done a great job with that writeup. 
What I want to talk about is how they are able to make this happen.
The first thing to note is that this does not exploit a bug in SQL Server 2012 or SQL Server 2014 (the two versions that this targets).
In this exploit a new dll is injected into SQL Server, much in the same way an anti-virus can injected their DLL into SQL Server. This injected DLL intercepts the call to functions like CPwdPolicyManager::ValidatePwdForLogin. It first checks to see if the hard coded password of the attacker has been used. If it does then it sets a flag that the other intercepted function calls will check for, and it’s exists without sending the authentication request to the normal function that processed authentication requests. If you aren’t using their hardcoded password, then it sends your authentication requests over to the authentiation function just like normal.
The other functions that are being intercepted are the functions that handle things like reporting authntication success (they wouldn’t want that to trigger as you’d then know when they were logging into your server) as well as the functions around auditing, transaction success reporting, etc. (they are all in the ESET writeup).
How they do this is pretty ingenous, they have written their own DLL and they are attaching it to SQL Server and loading that DLL higher in the process higherarchy then the DLL that normally hosts those functions (it’s more complex than this, this this is basically what’s being done). This allows them to intercept the needed functions and inject their own code that causes these functions to be skipped if needed (their code in their functions before calling the real functions).
The question that has come up already today, why does this only target SQL 2012 and SQL 2014. My assumption (and keep in mind I haven’t seen the attackers code, and I sure don’t have access to the SQL Server Code) is that this was origionally a targeted attack that they attackers decided could be used to get other useful data as well. Why it only works against SQL 2012 and SQL 2014? I assume that either the functions are in different places, or there are other parameters that are needed for SQL 2016+ (or both of these) which makes this sort of attack not work.
Is this something that you have to worry about, hopefully not. It only effects older versions of SQL Server, and in order to deploy this the attacker would need to be able to successfull breach your operating system so that the code can be loaded onto the SQL Server. This means that in order to do this they would already have to have breached your network and gotten a foothold on a server somehow. If they’ve gotten far enough into your network to install this, you’ve got some big problems that you need to address, quickly.
The question becomes why isn’t this is a SQL Server bug? Because they aren’t exploiting a bug in SQL Server to make this happen. The injecting a DLL in SQL Server is a supported, documented process. Attaching a DLL to another DLL, that’s a problem in Windows, and the attacker is getting into the Windows OS to deploy this.
Upgrading to SQL 2016+ is going to be a great way to get around this, as SQL 2016+ isn’t impacted by Skip-2. <sales hat>We can help with that</sales hat>.
Denny
The post What is skip-2? What is means to you? And what is compromised to make this happen? appeared first on SQL Server with Mr. Denny.
