justinbentley.net - pentest
Kali Linux
Kali Linux;

Penetration Testing



Target: justinbentley.net/social/vlog

Approach: SQL Injection

Tool: Kali Linux / sqlmap, max risk/level, whitebox

Bonus: Stress Test


In my skillset section ( justinbentley.net/skillset#SQL Security, also below) I made some bold claims.

Among other things I said my database was wholeheartedly immune to SQL Injection, so I decided to test that out.

SQL Map I

While at University of Canberra which was not so long ago I remember people used to talk about "Kali Linux" a lot and the reasons why. Now that I have made my own Database and spent a lot of time learning about how and why it can be vulnerable I thought it prudent to put my skills to the test. Put it to the test I did, and very much so.

Sqlmap (seen above) ended up subjecting my website and database to a relentless six hour battery of hacking attempts.

SQL Map II

Oh, look at that, it's reporting that its found a way in (above, the lighter green entry).

SQL Map III

Though after a little while it would seem that it has found a 'false positive'.

SQL Map IV

Though despite that try and try again it did.

SQL Map V

SQL Map VI

SQL Map VII

And finally, its exhausted (and the site was not penetrated).

So how many attempts (database writes and attempted writes) did it try in total?

Well as you can see in the above picture there was 3200 attempts that were rejected by the website. But how many got though? as you can see from the previous images the program was successfully making writes to the database though how many were there?

SQL I

This is the Primary Key of the last entry before the attack.

SQL II

This is the Primary Key of the final entry of the attack.

SQL III

And this was how many were in the first hour.

And for anyone thinking 'oh my what a mess' below is how you clean it all up.

SQL IV

Although a significantly more advanced "example" would be;

SQL V

Which would completely return the database to normal, retain valid entries created after and during the attack, stacks records sequentially and resets the primary key.

And there are safeguards that can be implemented that would severely hamper or halt this potentially annoying barrage of writes. For instance a cooldown of a minute or so between writes linked to a session and/or ip, perhaps even a heuristic although another good idea (which can be used in combination) is to integrate with Google reCaptcha which is designed specifically for this purpose.

Remeber that 'are you a robot' thing where you have to select all pictures of a traffic light?, this is why.

I do have another site actually (arcaneww.com/contact) which is a bit less personal and I have implemented ReCaptcha there and thanks to my efforts here its 100% secure and completely top grade, I also have a Youtube video about I implemented ReCaptcha too here.

So in conclusion what was learned? Well definitely my Amazon host handled it no problem at all. Half of the interest behind the exercise was also to stress test my website and as the attack was occurring I was monitoring the Amazon host and to be honest it was hardly phased and its good to know that the Visitor Log page can display 4.5 thousand entries with a rather minimal time penalty, so triple success 😄.

SQL VIII

SQL IX

But now that has all been done and tested, we couldn't just leave it like that now could we?

Remember;
Don't do this to people who would not consider it a friendly act. Kali Linux and especially sqlmap is a very powerful tool and very potent at what it is designed to do and by no means using this against the wrong person is not hacking. If I had made a mistake in the creation of the Database (which is incredibly easy to do) then untold amounts of damage could of been performed and the point of this exercise was really to prevent that "from the outside world".