More Messing with SQLi (POST Requests, Selection Fields and Reverse Shells)

In my first post about SQLi attacks, I focused mostly on vulnerabilities we can find in GET requests. It is important, however, to check POST requests and headers, too, as these can be vulnerable to SQLi attacks.


When we see an input bar for us to use, such as search bars, we can try to inject SQL commands. In the example below, I use a Boolean method to ascertain whether or not the search bar is vulnerable to SQLi. This works because if the statement is True, we see one result on the web-page, but if it evaluates to False, we see a different response. This can be achieved with the simple syntax of ' and 1=1; -- - followed by ' and 1=2; -- -





In the above example, I input the SQL commands directly into the search bar. Another way we can inject SQL when working with POST requests if by intercepting our request with a proxy server such as Burpsuite or OWASP Zap. We can then send the request to a repeater tool and try different injections against different POST parameters.





We can also use SQLMap once we have ascertained that a web-application is vulnerable to SQLi attacks via POST requests and which parameter to use. One way to do this is to use the --data switch which will inject our commands into the body of our requests sqlmap -u http://buggy.site/login.php --data 'user=a&pass=b' -p user --technique=B --banner In this example, I have specified with the --technique flag that SQLMap should use Boolean based attacks rather than UNION ones.

Another way is to save our request in Burpsuite as a .req file and then pass this file to SQLMap using the -r flag.





One more thing we can use SQLMap for is to try to gain a reverse shell via an SQLi vulnerability. We can attempt this via GET or POST parameters and when using UNION or Boolean attacks. The flag to use is --os-shell





We can, of course, gain reverse shells manually via SQLi vulnerabilities. In the following example, I exploit a vulnerable GET parameter to achieve remote code execution via a UNION attack. I specify the default web root for Linux systems /var/www/html I am essentially using the SQL INTO OUTFILE command to place a PHP command into the web root of the server. I then check if this attack has been successful by navigating to where the file has hopefully been saved and pass a simple Linux command as the cmd parameter specified in the malicious PHP code.




In this example, the attack has worked, so I next write a simple reverse shell and URL encode it before passing it as the cmd parameter. We need to start a netcat listener on the port specified in the malicious cmd before we navigate to the already uploaded PHP file. In this example, the attack works. Sometimes, we will find that commands such as bash have been blacklisted so the attack as it is will not work. One way around this is to use /bin/bash instead of bash. Another way is to use back-slashes \ in front of characters which are not escape characters - for example b\ash







Another situation we may encounter is a selection bar which could be vulnerable to SQLi attacks. In the next example, this is the case and we can see the selection made in the URL bar as a GET request. It is clear that each film has been given a numerical ID. To start with, I check for the existence of an SQLi vulnerability using a Boolean method.





Once the vulnerability was detected, I tried to see more data using ' or 1=1; -- - but this did not work. In order to get around this problem, I used the SQL LIMIT condition. By changing this, I was able to work through each of the films.







We will sometimes run into select bars which use POST requests instead of GET requests. In this case, we need to intercept a request using a proxy server and from there tamper with the data in the body of the POST request.






I found this technique useful when hacking the Validation machine on hackthebox. There were two parameters - username and country. We could input data directly into the username field, so the developer had sanitised it. They had neglected to sanitise the data passed from the country parameter, however, as from a regular user's point of view, it would not be possible to tamper with this. Of course, using Burpsuite I was able to tamper with it! The discovery of this vulnerability allowed me to enumerate the backend database using commands already covered, but nothing of any real interest was found except for the fact that the cookies were merely hashes of the username. I therefore exploited the vulnerability to gain a reverse shell and take control of the server and find the user flag!
































I hope this post has been of use in helping you understand more about SQLi attacks using POST as well as GET requests. I think it is useful to know that we can use proxy servers such as Burpsuite and OWASP Zap to tamper with http requests and attempt to find and exploit SQLi vulnerabilities. It is also, I feel, important to know how we can leverage SQLi vulnerabilities in order to take control of remote servers via reverse shells.

 

Thanks for reading - puzz00

 

Popular posts from this blog

Hacking Year of the Owl (thm)

Hacking Reset (thm)

Simple CTF (tryhackme)