Locating obfuscated SQL injection attempts

Locating obfuscated SQL injection attempts

In terms of security there is a large list of approaches that can be exploited. Over time it is highly probable that someone will target your site and the attacker is keen on using every possibility to breach your security. Some ways of doing so are more apparent than others coming from full scale DoS attacks to small and unknown zero day exploits and memory corruption on hardware levels.

Today let’s go back to basics and discuss the SQL injection (SQLi).

This attack pattern had already seen its most glorious days some time ago. Therefore I am sure you are familiar with it. You may ask, why talk about something you already know? The fact, that SQLi is already known, does not mean that all sites are protected against it and that it is not used.

Currently the world of cyber security is no longer human controlled world with all hackers sitting behind their machines trying to hack a single server. It is rather part of a larger concept. Yes, some hackers are still there, manually trying to break into most recent software and hardware. But there are large networks of automated tools and out of the box attack kits. Lately I had seen ransomware as a service and another ransomware with its own support line(!) where you could ask for payment details and how to decrypt your data.

These tools look for all possible vectors and actively try all of known techniques. If your site is online on the web sooner or later it may be targeted by these tools. Some of these tools will try to inject spam content into your site, usually to achieve higher page rank of other sites. However there are more sophisticated tools that are more subtle and could be leveraged to do almost everything. Example of fake content is string such as:

SQLi had evolved from its humble beginning with simple apostrophe escaping. Various covert actions are used to bypass filters and other countermeasures. Let’s take a look how you can identify a SQLi attempt from IIS logs.

IIS logging can be configured directly on IIS management panel:

By default, logs are stored at following location:

You can find more information about logs here:

https://www.iis.net/learn/manage/provisioning-and-managing-iis/configure-logging-in-iis

These logs contain records of every single request that was made to the server. Although SQLi is targeting database server, the entry point to the environment it is the application server which processes attacker’s HTTP requests.

Example of a log record:

Looking at logs of Kentico website, you see a lot of requests being routed to /CMSPages/PortalTemplate.aspxThis is a Portal Engine base page that handles all requests. They are rewritten and directed to respective pages inside the application itself rather than on the server. Targeted page is identified by an is aliaspath such as =/Company/About-Us.

I had mentioned before, that most of SQLi attacks are more evolved and most likely you won’t see an attack like '1=2. Eg:

 These days the injections are more sophisticated, well hidden, injected as parameters and obfuscated to error direct blacklists. Take a look at following example of an actual attack(Since this is too long I will rather use an ordered list):

As you can see category ID parameter is leveraged. The whole injection is covered. It is hidden in declaration of varchar which is set and executed as a procedure. Most relevant and important part of the query is encoded in hexadecimal, so that it is not readable to humans and to disable keywords filters or firewalls that could catch words like insert or update. However this encoding is not a problem in terms of query execution on SQL server. When you decode this text you will see:

As you can see, this is a complex query.

Another attempt was less subtle, because it was not even encoded:

Few key commands are not hidden due to the nature of the attack. It is essential to keep looking for exec words in the logs as this keyword may execute any SQL procedure and it does not have common place inside of HTTP requests.