Web Application Penetration Testing

Gilles LAMI

Security Expert

Introduction
Web application penetration testing has become particularly important nowadays. Web applications, if
not well secured, can offer attackers numerous ways to penetrate into the systems and networks, or
ways to steal sensitive data, even without getting a shell (command line) on the system.

With the evolution of technologies, Web applications became more and more complex, using more
and more components (the age of only using basic HTML is over), so the attack’s surface is greater
and ways to attack these systems are numerous, with the impacts we can read in the news, when a
web application has been compromised, personal or sensitive data has been stolen and this
information been made public.

In this article we will see a chain of exploits used against a vulnerable web server application and the
web server system itself.

Ready? So let’s begin.

Usually there are several phases during a penetration testing. I will briefly describe the classical
phases, as it is not the core subject of this article, and then launch and describe the chain of exploits.

The classical five phases of a penetration test

1°) Reconnaissance
The goal of this phase is to gather a lot of information about the target, usually using “white”
information sources (i.e. information publically available). But we never get directly in touch with the
target in this phase. For instance, the DNS are used, social networks, etc.

The main goal of this step is to collect a lot of information that could be used in the further phases of
the test. It can be emails address, employee names, job offers, etc. The information gathered can lead
to possible guessable logins, software names and versions used inside the company, even
architectures in place.

2°) Scanning

In this step the target is solicited. Packets are sent to it and also received from it. In this phase
vulnerabilities can be detected.

3°) Gaining access

This phase speaks by itself. The target or network devices are penetrated by the use of one or several
vulnerabilities. Gaining access can also mean stealing information and data by circumventing a
database access by the mean of a SQL injection flaws for instance. In this case we don’t strictly speak
about gaining access directly on the server, but gaining access to the data.

4°) Maintaining access

The goal of this phase is to demonstrate if it is possible to have a way of persistently have access to
the target(s) and then also be able to have time to bounce deeply inside the tested networks.

5°) Covering tracks

During this phase, the pentester will try to take appropriate measures to erase all his tracks (reset
logs, remove installed tools, etc.) that could prove that the systems have been compromised.

In the present article, the phases 2 and 3 of the pentest will be presented. The test has been made in
a lab, so the phase one is out of context and wouldn’t give useful results. At the end of the test, the
“root” account of the server will be compromised, covering tracks with a root account is quiet easy,
administration skills and tools knowledge are usually sufficient. And if system logs are sent on-the-fly
remotely to another server, then covering tracks of the attack can be much more difficult to achieve
and could be the purpose of another article.

The chain of exploits

In this lab, a vulnerable web server specifically built for pentesting purposes has been used:
Hackademic.RTB1.

Figure 1 - Vulnerable server used

The platform used to conduct the pentest is the famous Kali Linux distribution.

The chain of exploits that has been used is the following:

1°) Finding an SQL injection flow and exploit it.

2°) Finding a Wordpress access on the server and use it to upload a reverse back-shell.

3°) Use the back-shell to have a command line access get the Linux version and kernel version.
4°) Use of this information and the Wordpress server to upload an escalation privilege program.

5°) Use the back-shell and a C compiler present on the server to compile the escalation program.

6°) Finaly get “root” and then access to sensitive data on the server.

The description of the attacks

SQL Injection
A SQL Injection vulnerability is a vulnerability located at the application level (layer 7 of the OSI
model.)

Finding the SQL Injection vulnerability

These attacks bypass classical firewalls, even if these security devices are well configured. The most
efficient counter-measure to block SQL Injection attacks are Web Application Firewalls (WAF.) In our
example, in our lab, there is no WAF.

By browsing the web server, we can detect an SQL injection flow by simply adding a special character
inside the URL. See in the picture below the apostrophe inside the URL and also the result, showing
that there is a SQL error and also that a Wordpress is used.

Figure 2 - SQL Injection detected

Exploiting the flaw with SQLMAP

We then use the sqlmap tool in order to get backend database information.
Below the command launched:
 Figure 3 - Sqlmap exploitation 1

Figure 4 - Sqlmap exploitation 2

As we can see, there are three databases we can try to exploit. We will choose the wordpress
database. Again with sqlmap:
# sqlmap –u http://192.168.0.35/Hackademic_RTB1/?cat=1 –D wordpress --tables

The results:

Figure 5 - Sqlmap exploitation 3

# sqlmap –u http://192.168.0.35/Hackademic_RTB1/?cat=1 –T wp_users –columns

The results :

Figure 6 - Sqlmap exploitation 4

We then dump the content of the tables wp_users, user_level, user_login and user_pass:
# sqlmap –u http://192.168.0.35/Hackademic_RTB1/?cat=1 –T wp_users \

–C user_level,user_login,user_pass --dump

Figure 7 - Sqlmap exploitation 5

Sqlmap automatically found passwords hashes and proposed to perform a dictionary attack. We
indicate a password dictionary file (file with a list of passwords. Easily downloadable from the
Internet) and launch the attack.
 Figure 8 - Sqlmap exploitation 6
We found several accounts and the account “GeorgeMiller” with a level of 10.
This level means administrator rights in Wordpress.

We know that the web application hosts wordpress, and we have an administrator account and
password. We will now find where is the Wordpress login page. We could try different ways, but in
this article we will use “dirbuster”. This tool, also part of the Kali Linux distribution, is a powerfull tool
to brute force web server’s directories or filemanes.
 Figure 9 – Dirbuster

We succeed into getting the Wordpress login page. See below.

 Figure 10 - Dirbuster - wordpress login page

With the Wordpress login page identified and with a cracked user account we are now able to
connect inside Wordpress.

Figure 11 - Wordpress cracked account used

Inside the Wordpress administration portal, we configure Wordpress to allow upload of “c” and
“php” files:

Figure 12- Wordpress admin configuration

We are not able to upload files. We will upload a “reverse php webshell” to penetrate inside the Web
server and to have a command line.

Figure 13 - Wordpress upload

 Figure 14 - Upload of a php reverse shell
The PHP reverse shell is configured to connect back to the pentester attack machine on the TCP port
443 (see figure below.)

This port is usually allowed by FireWalls, from the Internet to the web server, but also sometimes
(quiet often) from the web server or the internal networks to the Internet. The reason is because the
TCP port 443 is the default HTTPS port.

Figure 15 - php reverse shell configuration

On the attacker’s machine, we start a listener on the TCP port 443 in order to be able to accept the
reverse connection. To achieve this with a simple way, we use the “netcat” (“nc”) tool:

Figure 16 – Netcat

Then we click on the upload button in the Wordpress administration page (see above.)

Figure 17- Uploaded file

The file is uploaded and we also see where it is located on the web server:
“/Hackademic_RTB1/wp-content/phpreverseshell.php”
We can now in the browser enter the URL :
http://192.168.0.35/ Hackademic_RTB1/wp-content/phpreverseshell.php
And we have a shell on the remote machine:

Figure 18- Shell on the web server

A simple command “id” tells us that we are logged as “apache”. This user has usually very few rights
so we have to escalate our privileges. The banner shows us that the victim machine runs under a
Linux 2.6.31.
Inside our Kali machine, we search for an exploit to escalate our privileges.

Figure 19- searchsploit - privilege escalation

We find a progam, written in the C language, able to escalate our privilege on the machine. With
Wordpress we upload it inside the victim’s machine. We now return to our command line shell inside
the web server, and then perform a “cat /etc/passwd” to retrieve the location of the web server’s
root directory:

Figure 20- Web server root directory

We go into /var/www and then to the location of our “15285.c” program (same sub-location than
our php reverse shell.)
We then compile it:

Figure 21- Escalation privileges – compiled

We now run it and finally get the root account:

Figure 22- Root

Conclusion
We used several vulnerabilities and misconfigurations to achieve all this:
• SQL Injection: an application level vulnerability.
• Wordpress admin account not very hardened (password guessed by brute forcing)
• Wordpress accessible from the Internet (allowing files upload from the outside.)
• Linux kernel vulnerability (for the privilege escalation.)
• TCP port 443 allowed from the inside to the outside (Internet) from the Web Server.
• A C compiler installed on the server (it is a good security practice to always uninstall unused
software on servers.)
If some of this point had been considered, for instance if the Linux server system had been correctly
patched. If the web application been audited (following the OWASP methodology for instance), if the
wordpress admin password had been hardened, if the Wodrpress software was not reachable from
the outside. And finally if the TCP port 443 not allowed from the web server to the internet, then the
exploit should have been much more difficult to achieve.
We could also think that if the first entry point (SQL injection) was not possible then all the exploit
would have rapidly failed. However, one of the goal of this article was to show a chain of exploits,
and show why it is important to have good security habits and fix the most security flaws you can as
possible.