Jump to content

Server execute PHP code through a txt file..


pierre
 Share

Recommended Posts

Hello,

I was wondering how could my server execute PHP code through a txt file !

Here is the flowgraph:

flowgraphTest.png.ae47795ca272248b075108b1b88af11b.png

Because when I make a request directly on the server with http://192.168.1.1/echo.txt , it prompts:

<?php

echo "test";

?>

But with a RFI it works !

Do you know why ??

Edited by pierre
Link to comment
Share on other sites

The reason your server (192.168.1.1) won't execute it is because it doesn't know to pass .txt through the php engine, assign that extension and it will.

It will break your RFI example though as you will server out just the word test rather than the full source.

Link to comment
Share on other sites

PHP normally only executes files with the .php extension. Saving as text, should render the file as text as expected. An RFI attack executes the text as PHP, if the RFI enabled script on the server is not filtering for file type and blanket runs whatever is sent to it, which is not good.

The source code of the site running the vulnerable RFI script is more than likely calling whatever is fed as an include and running it as php. If it doesn't filter for remote files(or even local ones probably if it allows RFI) in theory it should work both as RFI and LFI when pointed at the right file to read in. Viewing the file itself will only run as PHP if the system with PHP on it has a mime type set to run text files as PHP, which depends how the web server is configured. This can be done by adding a few lines in an htaccess file on apache for example and would allow running txt files as executable php.

Edited by digip
Link to comment
Share on other sites

The RFI is a vulnerability that exist in a index.php file.

 

the php code in your vulnerable php File is executing the code from your echo.txt file.

 

The vuln.php file is using Include_once(echo.txt)

 

the most common exploit of this technique might be log poisoning. If you can write php code to any log file then you could execute your own php code. with the url inclusion method 

vuln.php?PAGE=../etc/log/FTP_error.log%00

Edited by i8igmac
Link to comment
Share on other sites

2 hours ago, i8igmac said:

the most common exploit of this technique might be log poisoning. If you can write php code to any log file then you could execute your own php code. with the url inclusion method 

vuln.php?PAGE=../etc/log/FTP_error.log%00

Yes, this would then turn it into an LFI if the script has access to read local log files like an apache access log. This is often done with the use of a malicious user-agent string to load the info to the logs. In the right circumstances you can even take advantage of pages that echo back the visitor user-agent string without sanitation, similar to shellshock against vulnerable cgi-bin files, PHP that echos back the user-agent could be abused as well.

Link to comment
Share on other sites

What you could do is get the PHP server to create a temporary file, copying the contents of the text file and turning the temp file into a .php and then sending that one across..This way you could have multiple files being one file (if you catch my drift). The client asks for one file but the PHP server has pre-determined what file is going to be the file they requested. Basically the client asks for the file as a name, and the PHP server has renamed one of it's text files to that name.

Sounds more complicated than it is.

Link to comment
Share on other sites

16 hours ago, digininja said:

The reason your server (192.168.1.1) won't execute it is because it doesn't know to pass .txt through the php engine, assign that extension and it will.

It will break your RFI example though as you will server out just the word test rather than the full source.

Whap means "server out" ?

 

15 hours ago, digip said:

PHP normally only executes files with the .php extension. Saving as text, should render the file as text as expected. An RFI attack executes the text as PHP, if the RFI enabled script on the server is not filtering for file type and blanket runs whatever is sent to it, which is not good.

The source code of the site running the vulnerable RFI script is more than likely calling whatever is fed as an include and running it as php. If it doesn't filter for remote files(or even local ones probably if it allows RFI) in theory it should work both as RFI and LFI when pointed at the right file to read in. Viewing the file itself will only run as PHP if the system with PHP on it has a mime type set to run text files as PHP, which depends how the web server is configured. This can be done by adding a few lines in an htaccess file on apache for example and would allow running txt files as executable php.

The txt file with PHP code stored on the server don't execute PHP but display the PHP code

Only the RFI permits execute PHP code in a txt file

No special entry add in .htaccess appart "php flag magic quotes gpc"

13 hours ago, i8igmac said:

The RFI is a vulnerability that exist in a index.php file.

 

the php code in your vulnerable php File is executing the code from your echo.txt file.

 

The vuln.php file is using Include_once(echo.txt)

 

the most common exploit of this technique might be log poisoning. If you can write php code to any log file then you could execute your own php code. with the url inclusion method 

vuln.php?PAGE=../etc/log/FTP_error.log%00

The PHP code in the txt file (in RFI case) is executed because the txt file is include with include function in index.php ? Is that so ?

Link to comment
Share on other sites

3 hours ago, pierre said:

 

The txt file with PHP code stored on the server don't execute PHP but display the PHP code

Only the RFI permits execute PHP code in a txt file

No special entry add in .htaccess appart "php flag magic quotes gpc"

The PHP code in the txt file (in RFI case) is executed because the txt file is include with include function in index.php ? Is that so ?

 

Correct. You should look at the file /lfi/index.php. you should find include($_GET exist or something close.

 

Topically, RFI is not a practical method. LFI is more common. you have to discover local files that could allow you a way to view your header request. Then place php snippets in your header.

 

/lfi/?page=/proc/self/environ

This request above will execute php code directly from your user agent. You can use a web browser plugin to tamper with your user agent string.

 

lfi/?page=/var/log/apache2/access.log

If you can find the web server log file. You might see This log file shows request information coming from your web browser which should show a referer: string or user-agent string.

 

Run a dir brute force scan. Try to discover config files and log files.

 

You should learn small php snippets, how to find a writable directory and how to write your php code to this writable directory. 

 

I assume this is a vulnerable linux VM?

Link to comment
Share on other sites

Yes it is a vulnerable VM :)

2 points :

1- I can't view /var/log/apache2/error.log

osboxes@osboxes:/var/log/apache2$ ls -l error.log
-rw-r----- 1 root adm 18735 Jul 24 10:21 error.log

Even if I change to chmod 777 eorr.log, it still can't be displayed..

But I can display /etc/passwd through my LFI with these right associated:

osboxes@osboxes:/var/log/apache2$ ls -l /etc/passwd
-rw-r--r-- 1 root root 1978 Dec  7  2016 /etc/passwd

So I don't know why I can display error.log..

2-I don't find your metasploit module

msf > use multi/http/lfi_scan_include
[-] Failed to load module: multi/http/lfi_scan_include
msf > search lfi_scan
[!] Module database cache not built yet, using slow search

msf > use multi/http/lfi_scan_include
[-] Failed to load module: multi/http/lfi_scan_include

Do I need any particular installation to get it ?

Link to comment
Share on other sites

I have the metasploit module some where on a hard drive. You will be better off learning the basics.

 

First run a scan and try to discover as many files. then post results here... 

 

burp suite can be used to discover files with intruder tab. You will need a list of known files... I think kali or metasploit has a file-list for this kind of scan...

Link to comment
Share on other sites

5 hours ago, pierre said:

Yes it is a vulnerable VM :)

2 points :

1- I can't view /var/log/apache2/error.log

osboxes@osboxes:/var/log/apache2$ ls -l error.log
-rw-r----- 1 root adm 18735 Jul 24 10:21 error.log

Even if I change to chmod 777 eorr.log, it still can't be displayed..

But I can display /etc/passwd through my LFI with these right associated:

osboxes@osboxes:/var/log/apache2$ ls -l /etc/passwd
-rw-r--r-- 1 root root 1978 Dec  7  2016 /etc/passwd

So I don't know why I can display error.log..

2-I don't find your metasploit module

msf > use multi/http/lfi_scan_include
[-] Failed to load module: multi/http/lfi_scan_include
msf > search lfi_scan
[!] Module database cache not built yet, using slow search

msf > use multi/http/lfi_scan_include
[-] Failed to load module: multi/http/lfi_scan_include

Do I need any particular installation to get it ?

#1

Do an ID or whoami for me, what are your user name and rights to access? If it's www-data or such, then you shouldn't be able to touch what is in /apache2 for the logs unless you are part of the same user group.

rw-r----- means read/write(root), read(group) and no access for normal users(---). Needs to be rw-r-r to see it. /etc/passwd is readable permissions even when owned by root, since it's rw-r-r where the user bit is set to readable. This is basic linux/unix file permissions, something you should read up on a bit. If it were 0777, you SHOULD in theory be able to read it, but what is the permissions of the apache2 folder? If it's not readable, you shouldn't be able to reach the error.log to access the file, nor should you be able to change it's perms unless you are the file owner, or root on the system. If you are root already, then what are you worried about logs for? Also, access.log(s) are generally where you would plant some code to execute on the system, like in your user-agent. Error logs usually only show error specific things, and often no user-agent at all on them, only the IP and error of a blocked access(like 403 forbidden) or some mod_sec rule block or php error in a script or such.

#2 Didn't he write his own?

Quote

for fun, I made a metasploit module to exploit this process.

So your system wouldn't have this file, although there are probably some other kinds of LFI attacks in Metapsloit Framework, your search might need to be adjusted a bit to check.

Link to comment
Share on other sites

Yes I am under www-data user and www-data is not in the adm user group as well so it is logical if I can't see apache file.

Here is apache2 right:

osboxes@osboxes:/var/log/apache2$ ls -l /var/log/
drwxr-x--- 2 root              adm    4096 Jul 25 09:48 apache2

So because /var/log/apache2 is not readlable to all, so file inside are not as well even if there pointed as chmod 777 ?

Oops I thought that your module was implemented in metasploit :)

 

Link to comment
Share on other sites

4 hours ago, pierre said:

Yes I am under www-data user and www-data is not in the adm user group as well so it is logical if I can't see apache file.

Here is apache2 right:

osboxes@osboxes:/var/log/apache2$ ls -l /var/log/
drwxr-x--- 2 root              adm    4096 Jul 25 09:48 apache2

So because /var/log/apache2 is not readlable to all, so file inside are not as well even if there pointed as chmod 777 ?

Oops I thought that your module was implemented in metasploit :)

 

You don't have permissions to chmod the file, since you are not root, or in the adm group.

Link to comment
Share on other sites

You need to discover more files that you can view... ftp logs, sql logs, ssh logs, configuration files. Anything... 

https://highon.coffee/blog/lfi-cheat-sheet/

 

Follow this tutorial and find more tutorials. There or lots of different methods you need to learn. 

 

Here is a lfi log file list. https://github.com/tennc/fuzzdb/tree/master/dict/BURP-PayLoad/LFI
 
Did you try /proc/self/environ ?
Link to comment
Share on other sites

6 hours ago, pierre said:

Yes but rights are limited as well:

osboxes@osboxes:~$ ls -l /proc/self/environ
-r-------- 1 osboxes osboxes 0 Jul 31 10:20 /proc/self/environ

When done right, /proc is usually mounted read only by root with no SUID and can't be changed or remounted(easily). I wouldn't expect to see too many attacks with /proc in the path. Can look for /proc/self/cwd/ which lets you append any path after it for LFI, but that also requires misconfiguration or already vulnerable system that someone setup to use it.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...