Web Application Penetration Test Case Study
This is a case study of an external web application penetration test that Dionach performed for a large UK organisation on a new web site. Some of the information has been changed or omitted to maintain confidentiality.
Background
The client had produced a large scale web site in a project lasting over six months, and commissioned Dionach to check the new site for any security vulnerabilities prior to launch. The organisation supplied Dionach with the web site URL and the IP address range of the servers based at the hosting facility. The test was carried out in two phases: the first without access to the site's source code, and the second phase with a copy of the source code.
Dionach then proceeded with the four stages of the penetration test:
- Information gathering
- Scanning for external services
- Identifying vulnerabilities on external services and exploiting them
- Producing a detailed report of issues and recommendations
Information Gathering
The domain name and IP addresses were first verified with Nominet UK and the RIPE Whois Database. Internet, forum and newsgroup searches on key individuals did not reveal much information that would be useful.
The penetration testing team familiarised themselves with how the site worked, and to get a feel for the technologies used. This site used a customised off-the-shelf ASP-based package.
Network Scanning
Port scans were carried out three times over the course of the week that the test took place in. The scans revealed that 8 Internet Protocol (IP) addresses responded to Internet Control Message Protocol (ICMP) pings, and there was one service available: a web server on port 80 on one of the IP addresses.
The web server IP address corresponded to the URL domain name that the organisation provided, and was exposed to be Microsoft IIS 5.0, which runs on Windows 2000.
Vulnerability Identification
The web server software, as opposed to the web application, was then scanned for vulnerabilities using commercial and non-commercial vulnerability scanning tools. No vulnerabilities were discovered.
The web application was then tested using a mixture of open source scripts, a commercial tool and an in-house developed tool. These tools spidered the site and checked for application vulnerabilities. A manual process was also followed, as experience has shown that vulnerabilities can be found in similar areas as those encountered in previous tests.
Several pages were identified as being vulnerable to SQL injection that allowed an attacker to run SQL statements on the database. The database server was identified to be SQL Server 2000 running on a Windows 2000 Server. The web application was not using an administrator level account to connect to the database, and the SQL Server was patched and had other security in place so privilege escalation was not possible in the time available. However, full read/write access was possible on the database, which means an attacker would have been able to retrieve usernames and passwords and deface the site.
Several pages were identified as being vulnerable to cross-site scripting, which may have allowed limited site defacement and session hijacking.
Access to the source code revealed that there were many pages where effective user input validation and data type validation were not being carried out. Extensive use of string concatenation to built SQL statements meant that just one web page query string, form field or cookie where validation didn't occur could lead to compromise of the database.
Each potential web page was tested for SQL injection and other vulnerabilities.
Examination of the source code revealed a number of back up and test web pages which also had vulnerabilities.
Reporting
A report was compiled with a non-technical executive summary, and a detailed technical section.
The executive summary reported that the firewall and operating systems were well configured and patched, however the security of the web application represented high risk, and that external attackers could compromise the system.
The number of issues identified at each risk level (critical, high, medium, low and informational) was presented graphically and key issues starting with the most critical were listed with recommendations given for resolution of each.
The technical section following this showed the information gathered, the network scan, and the results of the web server scan.
The largest section of the report was the application test, which showed pages vulnerable to issues such as SQL injection and cross-site scripting, and how they were exploited.
The final section showed technical issues and recommendations, with the most critical first.
Presentation
The report was then presented to the client face-to-face to ensure that the client gained the most benefit from the test and the report.
Following this test, the client was able to secure the most critical issues in time for the launch. The client commissioned Dionach to carry out a follow up test to check that the security enhancements were successful, and planned to request further tests on a regular basis or when there was a major change to the application.
