SQL Injection like most attacks can be detected via logs, packets or once again from the user’s browser cache as well as other sources.
Once again, let’s get down to detecting this.
Since we already know that this attack is leveraging the “username” parameter, let’s target our detection on this parameter so as to make best use of our time.
“cat --number sqlInjection.log | grep "\&username\=.*?" --colour=always --only-matching | cut --fields 2 --delimiter "=" | cut --fields 1 --delimiter "&" | sort | uniq -c | sort --numeric --reverse | more”
While the above shows shows the SQL injections, it does not really say whether these were successful. This is due primarily for the fact that these events are stored in Apache’s “access.log” and uses the HTTP “GET” method. Considering we enabled Apache’s “mod_dumpio” in the post on Command Injection , we can now leverage Apache’s “error.log” to validate whether these were successful or not.
Let’s use the following one liner “cat --number sqlInjectionError.log | grep --perl-regexp "admin\'.*?\s+\-\-|\;\.[0-9]*\s+.*?\.|or\s+1\=1\s+\-\-|\s+ReflectedXSSExecutionPoint\=\"1\"\>.*?\<" --colour=always | more” against our logs to identify whether or not any data was returned.Basically this will be used for the entire analysis.
The above shows that the SQL “’ or 1=1 – ” was successful. In this case 24 records were returned and we can see a snapshot of some of these above.
The image below shows the query and results for the current database version.
The image below shows a snapshot of the dump of all the tables and columns.
The following table shows the result returned showing the “current_user” of the database.
The following shows the “database” which the application is accessing.
And last but not least before we wrap this up, a look at the results from the attempt to access “CorpSecrets.txt”
That’s it for detecting SQL injection. See you in the next post for Session Hijacking.