Last year, I created an app template to detect whether your users went to a phishing web site where you would supply the app the sourcetype name of your proxy logs and the URL destination field where they went. You can still download this Phishing app template from Splunkbase. In the same manner, I have created an app template called SQL Injection Search that you can download from Splunkbase.
Install the app and provide either of the two form search dashboards the name of your sourcetype representing your web logs (e.g., access_combined) and the name of the field in the sourcetype that represents the URI query string (e.g., uri_query). One form search uses patterns to detect if possible SQL injection attacks have happened and other uses a statistical pattern of the URI query string field’s average length to find outliers. See below for an example screen output as I provide a sample log file in the logs directory for you to try out before you try it with your your own data. Simply enable the input in inputs.conf and restart Spunk.
Sample Pattern Search
The reason there are two different ways to detect SQL Injection is because it’s not a trivial problem to just use patterns. I have provided a regular expression that may cover 50% to 75% of possible attacks, but that won’t cover everything as there are many patterns that could be used based on the proprietary syntax of the database in question. This is just a starting point. What you would want to do in the macro that defines the pattern search regex is change it to add the possible commands that are pertinent to your database. The idea is that you are very interested in people attacking your particular database as the commands may succeed, but not as interested in attacks that target a database you do not use.
A quick way to search for SQL injection is to use statistical analysis. The idea is to first find the average length of all URI query strings and then find any URI query strings that are N times the standard deviation plus the average length. The thought process is that unusually long query strings may indicate an attack. For the macro in the statistics form search dashboard, I chose to find any URI query string that is 2.5 times the standard deviation plus the average length. This was suggested to me by fellow Splunker, Monzy Merza. You may change the multiplier in the included macro for what you think is appropriate for your website. Now, the issue with using statistics is that someone could easily embed an apostrophe at the end of a presumed innocent query string and it would go unnoticed or they could create a very short query string that only has SQL injection commands. That’s why using patterns is suggested as well as using statistics to narrow down possible attacks. You may end up getting false positives and some false negatives, but the idea is to see the pattern of attack rather than just seeing one particular SQL command being used. You can always adjust the regular expression or the statistic to tune your search. In fact, I would suggest you create Splunk alerts using the supplied macros so that you don’t have to manually search for possible attacks using the form search dashboards.
In the dashboards, I also list the clientip field that comes from the web logs so that you know what client is injecting SQL commands. (Change the two dashboards to use whatever field name represents your clientip field.) Certain attacks may be very slow and patient coming with only one command a day to not be detected by an IDS that uses count thresholds per hour to trigger an alarm, but with Splunk you could go back in time as far as your data would take you and you would see the slow pattern the client ip has been sending.
Keep in mind that this is the tip of the iceberg. To do a thorough analysis, you would want to also ingest your firewall, application server, and database logs at the same time to see how far the commands got and where they were potentially stopped or were not stopped.
Finally, the best way to defend against SQL injection is to place some defensive measures in your infrastructure, such as validating input, using parametrized queries, using stored procedures, giving least privileged access to your database, and inspecting code to make sure it is not vulnerable. I hope this app template would be a starting point to at least detect the problem.
