How was my first Web Application Penetration Test
A while ago a client of mine asked for a WAPT (Web Application Penetration Test) for his company; the web application was built in Microsoft environment, so with all the ASP.NET and .NET framework stuffs that Linux boys always pass: this was the first real WAPT I have ever done.
Why I say that this was the first real WAPT in my life? Well, I had no information about the web application or the systems behind. This made it a bit challenging and more exciting than ever. The only information I had was the version of the web server, the language of the source code and an admin account to test internal part of the web application.
The web app I had to break was on a pre-production environment but I noticed that also the production environment was on the same IP address, this made me desist from doing a DoS network attack because it could impact also production (what a pity!).
First move: Recon
Since I had no idea of what kind of application I was analyzing I had to start from the basics: reconnaissance and information gathering.
DNS Lookup
This is quite often my first recon move when I have a web application to analyze. DNS lookup could give you a lot of information regarding the target infrastructure, but this time I was not so lucky: the nameserver was managed by GoDaddy (which was surely out of scope) and I can not retrieve any other information.
NMAP Scan
Perform a NMAP scan is always a good point to start, even if it is a Web Application Penetration Test, it could give you information about services running on the target, ports open (or not) and firewall/ids in front of the server.
# Nmap 7.80 scan initiated Tue Aug 3 15:11:12 2021 as: nmap -sC -sV -p- -v -oN nmap-1-65535-sV-sC.txt ---OMISSIS---.com
Nmap scan report for ---OMISSIS---.com (xxx.xxx.xxx.xxx)
Host is up (0.042s latency).
Not shown: 65533 filtered ports
PORT STATE SERVICE VERSION
80/tcp open http Microsoft IIS httpd 10.0
|_http-favicon: Unknown favicon MD5: 0F7EXXXXXXXXXXXXXXXXXXXXXXXX2C16
| http-methods:
|_ Supported Methods: GET HEAD POST OPTIONS
|_http-server-header: Microsoft-IIS/10.0
| http-title: ---OMISSIS---
|_Requested resource was http://---OMISSIS---.com/
443/tcp open ssl/http Microsoft IIS httpd 10.0
| http-methods:
|_ Supported Methods: GET HEAD POST OPTIONS
|_http-server-header: Microsoft-IIS/10.0
|_http-title: Did not follow redirect to http://---OMISSIS---.com/
| ssl-cert: Subject: commonName=---OMISSIS---.com/organizationName=---OMISSIS---./countryName=IE
| Subject Alternative Name: DNS:---OMISSIS---.com
| Issuer: commonName=GeoTrust EV RSA CA 2018/organizationName=DigiCert Inc/countryName=US
| Public Key type: rsa
| Public Key bits: 4096
| Signature Algorithm: sha256WithRSAEncryption
| Not valid before: 2021-05-26T00:00:00
| Not valid after: 2022-06-14T23:59:59
| MD5: 7bf5 XXXX XXXX XXXX XXXX XXXX XXXX 1149
|_SHA-1: bb2c XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX ce6c
|_ssl-date: 2021-08-03T13:13:37+00:00; 0s from scanner time.
| tls-alpn:
| h2
|_ http/1.1
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windowsRead data files from: /usr/bin/../share/nmap
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Tue Aug 3 15:13:38 2021 -- 1 IP address (1 host up) scanned in 145.48 seconds
As you can see in the code above, once again we didn’t get any relevant information, so go ahead with recon!
SSL Scan
After the NMAP scan I performed a scan with sslscan to see which cipher suites were in use:
sslscan ---OMISSIS---.com 1 ⨯
Version: 2.0.7-static
OpenSSL 1.1.1j-dev xx XXX xxxxConnected to xxx.xxx.xxx.xxxTesting SSL server ---OMISSIS---.com on port 443 using SNI name ---OMISSIS---.comSSL/TLS Protocols:
SSLv2 disabled
SSLv3 enabled
TLSv1.0 enabled
TLSv1.1 enabled
TLSv1.2 enabled
TLSv1.3 disabledTLS Fallback SCSV:
Server does not support TLS Fallback SCSVTLS renegotiation:
Secure session renegotiation supportedTLS Compression:
Compression disabledHeartbleed:
TLSv1.2 not vulnerable to heartbleed
TLSv1.1 not vulnerable to heartbleed
TLSv1.0 not vulnerable to heartbleedSupported Server Cipher(s):
Preferred TLSv1.2 256 bits ECDHE-RSA-AES256-GCM-SHA384 Curve 25519 DHE 253
Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-GCM-SHA256 Curve 25519 DHE 253
Accepted TLSv1.2 256 bits DHE-RSA-AES256-GCM-SHA384 DHE 2048 bits
Accepted TLSv1.2 128 bits DHE-RSA-AES128-GCM-SHA256 DHE 2048 bits
Accepted TLSv1.2 128 bits RC4-SHA
Accepted TLSv1.2 128 bits RC4-MD5
Preferred TLSv1.1 128 bits RC4-SHA
Accepted TLSv1.1 128 bits RC4-MD5
Preferred TLSv1.0 128 bits RC4-SHA
Accepted TLSv1.0 128 bits RC4-MD5SSL Certificate:
Signature Algorithm: sha256WithRSAEncryption
RSA Key Strength: 4096Subject: ---OMISSIS---.com
Altnames: DNS:---OMISSIS---.com
Issuer: GeoTrust EV RSA CA 2018Not valid before: May 26 00:00:00 2021 GMT
Not valid after: Jun 14 23:59:59 2022 GMT
This was the first relevant result I had: SSLv3 and TLSv1.0 enabled (which are not secure anymore!). Moreover the cipher suites for TLSv1.2 were using RC4 and MD5 that are not recommended because they are considered weak.
Attack phase
Once the reconnaissance was over I moved to do some magics on that web application!
Static Code Analysis
Obviously I didn’t have the source code of the application, but I had the HTML generated: this means a lot of Javascript scripts, libraries, external resource and (if you’re lucky) some useful comment in the code.
I started looking at the HTML and noticed a lot of libraries were used, and some of them were vulnerable or no longer maintained.
This analysis helped me in the next steps.
Login form and Session Management
The first analysis on the login page was on the cookies. The web application I tested does not refresh Session ID after login and neither if the page is refreshed (when the user is not authenticated), moreover there were some cookies that were still valid after logout.
Secondly the password input was not managed correctly, the type of this input was “text” and not “password”: the obfuscation was made by special font applied to this input.
Furthermore this input can’t handle correctly the single quote ( ‘ ) character, in fact if inserted it caused the crash of the system of login that remained in wait, beyond to the fact to make to disappear the obfuscation of the field. The cause was that the password was sent back to the client (from the server) into a Javascript function that was using single quote to pass the argument (the password).
XSS
After a little bit of work I discovered some fields which can be filled with free text. I tried with a simple XSS:
<script>alert(1)</script>Unexpectedly, the application crashed. Even if the framework became aware of the potential attack, our XSS generated an unhandled exception revealing the framework version and the stack trace.
Once I got the version used to build the web application I googled a bit an found a way to bypass this crash: using Unicode encoding.
I built the new XSS with Unicode angle brackets and finally I got a stored XSS!
Reporting phase
This phase is the most important and you should start it when you start the Penetration Test. In Kali you’ll find some specific tools for pt reporting, but you can use even VI if you want.
The report I wrote was divided into 5 sections and 2 appendix:
- Activity Overview — This paragraph describes the activity, the rules of engagement, the methodology, the team, and the tools used.
- Findings —Usually contains only evidence of the vulnerabilities found by the scanner or vulnerable software.
- Attack Narrative — This section describes the attack phase: how the attack was made, how specific vulnerability was exploited and how to remediate.
- Remediation Plan — Remediation section contains all the remediations suggested (vulnerabilities and PT remediation).
- Conclusions — This is the final section which contains a sum up of the report.
Remember to describe all the steps very clearly for your client, write your contacts if they have any doubts.
Useful resources
International Security Guidelines
- NIST 800–100 “Information Security Handbook” -
https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-100.pdf - NIST 800–95 “Guide to Secure Web Services” -
https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-95.pdf - NIST 800–53 “Security and Privacy Controls for
Information Systems and Organizations” -
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf - OWASP Web Security Testing Guide -
https://owasp.org/www-project-web-security-testing-guide/stable/ - OSSTMM — https://www.isecom.org/OSSTMM.3.pdf
Secure Cipher Suites
Supplementary links:
Conclusions
The web application I analyzed was quite secure, but there were still some technical measures to implement to improve the overall security. Disabling SSL v3 and TLS 1.0/1.1 and using secure cipher suites increases the security of HTTPS connections by preventing certain types of man-in-the-middle attacks. Separating development and production environments (and using different IP addresses) is necessary to avoid DoS network attacks.
Proper Session Management dramatically decreases the risk of Session Hijacking attacks and CSRF (Cross-Site Request Forgery) attacks. The password input in the login form must be managed correctly and it needs some additional server-side checks. XSS can be avoided by doing deeper checks by using the development framework properly, implementing proper encoding, and exception handling.
Limiting information disclosed (web server version, framework version and stack trace) could put the attacker in difficulty.
Make sure to handle correctly all the exceptions that could be thrown to avoid unforeseen situations.
Always follow the best practices: NIST, OWASP, ISECOM and the whole Security community will be your best friends.
The only advice I can give you is try, try and try again, because every application or system is different: no application is 100% secure, even if you’re a n00b.
