In this video we start off by using “wget” to clone the site we are attacking so when users are redirected to our site they are less suspicious as any differences are subtle, and wont generally be noticed by normal users. Then we load the cloned pages on our webserver.
For the purpose of the demo we have left the IP address showing in the address bar so you can see the difference. The original site is on .105 and our clone is on .104 (Poisoning the host file or typo-squatting is a whole tutorial by itself).
Back to the hack. We have enough access that if we wanted to we could upload our own pages and replace the existing ones, but for the purpose of this we are going to change where the login URL points to so it sends users to our clone site rather then the correct login page.
We could obviously do this with every link on the site. We could also just upload some further malicious code to the server so that every visitor to the site will have their browser injected with malicious code.
Today we are going to show how an attacker can leverage SQL Injection to redirect users to their own site/webpage for whatever malicious activity they choose.
This will be in two parts. The first will show how using a tool called sqlmap we can carry out successful SLQ Injection, and very quickly dump usernames and passwords. The “php?id=1” part of the URL is injectable, and this is what sqlmap will exploit.
Then once we have access to the admin section, we upload our php shell, but the site has some basic filtering so we change the filename and extension from “b374k-2.8.php” to “b374k-2.8 (copy).jpg.phtml” which gets us past the filtering controls. It also shows why even in password protected areas of your site you still need rubust upload controls. It means if someone manages to access the area they will still have to work to be able to upload a shell. Always think security in depth. Always add layers.
This video ends with us logging into the uploaded webshell and accessing the www directory.
Here we have another example of simple Sql Injection. In the previous example we bypassed the authentication controls, in this example we dump the User table which contains all usernames and passwords on the Webpage. This webpage is a simple account search page. We are being asked for our username and password in order to view and edit our account details, and again we can use a simple Sql Injection which will equal true (‘OR 1=1 — ). As the input is not filtered the whole User table can be dumped into the wepage. Again this is a basic example but it shows that you need to carefully consider the security of any table that users can query, as once we have dumped the table we can login as any user! (Again we are using Mutillidae to demonstrate this vulnerability)
Another quick video showing how SQL Injection can be used to bypass a login page. This is a very basic example, but it clearly shows that if you aren’t filtering input your site is as risk. Here we use a simple SQL statement ‘OR 1=1 — to bypass the login authentication control. the ‘ at the start escapes the intended statement which should run when you click the login button and then the SQL statement OR 1=1 will run (This will equal true). For eample a simplified login statement would be “IF Username & Password = true, Login = yes. (This is not a real statement it is written here in simplified form to make it easier to understand). Our Injection statement equals true so therefore even though we have not used a username and password our statement still equals true so we get logged in! The — at the end simply comments out any code which comes after our injection which allows our statement to run without any extra code running afterwards. The site we are using in this demonstration is Mutillidae which is maintained by @webpwnized, and is great for learning how to secure webapps, check it out.