I've been traveling for five consecutive weeks now, which is the longest stretch so far during my time at this current job. As such it leaves little time for other projects, but I promise to post a guide to setting up GoPhish on Windows Server 2012 sometime next week.
As a substitute, here's a short blurb about SQL Injection.
In my time doing manual verification of scanner results, I found 1 certain SQL injection vulnerability and maybe 2 potential others. When doing manual web application assessments I found none (the cool stuff had already been picked out by previous testing).
I wonder if hitherto unchecked internal environments are more likely to have SQL injection vulnerabilities. As an example, let's look at this site:
example.com/dir/default.asp?page=profile&action=lookup&option=Name&StrSearch=
We're looking up user profiles, testing each parameter for generic XSS and SQL with something like<>"'%^&*()[] or some other banging of the keyboard. And what do we see when we put a single tick in the StrSearch parameter?
Let's pull out SQLMap and direct it at the StrSearch parameter, making sure to include the right cookies. Voila, it works!
A shell and all the database content our heart desires.
A second example. This one came courtesy of Nessus which flagged it as a potential Blind SQL injection, using a time-based injection. I wouldn't have found it otherwise, as this was a pentest where the only IP information given was a list of IPs to exclude. The rest was up to me to find. I found 2100 live hosts, and was told there are about 2500 total. Just the 2100 was enough for me.
Here's the query string (some parameters removed):
example.com/index.asp?tbUserName=&tbPassword=&search=&a=verify&t=66
The potentially vulnerable parameter was "t". After verifying that the time-based injection worked (ala ;WAITFOR DELAY '0:0:5'--) by sending various commands that request for a response after a certain number of seconds, I fed it to SQLmap.
Payload: 66 UNION ALL SELECT NULL,CHAR(113) etc etc
And oh hey, look, all the database tables of this company. Users, passwords in clear text (from some tables), PII (which I didn't dare touch), all your greedy little heart desires. The passwords looked like they came from a time before minimum password restrictions, because "1v10" isn't terribly secure.
So in conclusion: SQL injection is super rare but when you find it you get the keys to the kingdom.
As a substitute, here's a short blurb about SQL Injection.
In my time doing manual verification of scanner results, I found 1 certain SQL injection vulnerability and maybe 2 potential others. When doing manual web application assessments I found none (the cool stuff had already been picked out by previous testing).
I wonder if hitherto unchecked internal environments are more likely to have SQL injection vulnerabilities. As an example, let's look at this site:
example.com/dir/default.asp?page=profile&action=lookup&option=Name&StrSearch=
We're looking up user profiles, testing each parameter for generic XSS and SQL with something like
A shell and all the database content our heart desires.
A second example. This one came courtesy of Nessus which flagged it as a potential Blind SQL injection, using a time-based injection. I wouldn't have found it otherwise, as this was a pentest where the only IP information given was a list of IPs to exclude. The rest was up to me to find. I found 2100 live hosts, and was told there are about 2500 total. Just the 2100 was enough for me.
Here's the query string (some parameters removed):
example.com/index.asp?tbUserName=&tbPassword=&search=&a=verify&t=66
The potentially vulnerable parameter was "t". After verifying that the time-based injection worked (ala ;WAITFOR DELAY '0:0:5'--) by sending various commands that request for a response after a certain number of seconds, I fed it to SQLmap.
Payload: 66 UNION ALL SELECT NULL,CHAR(113) etc etc
And oh hey, look, all the database tables of this company. Users, passwords in clear text (from some tables), PII (which I didn't dare touch), all your greedy little heart desires. The passwords looked like they came from a time before minimum password restrictions, because "1v10" isn't terribly secure.
So in conclusion: SQL injection is super rare but when you find it you get the keys to the kingdom.
