- Oxford: +44 (0)1865 877830
- Manchester: +44 (0)161 713 0176
- Edinburgh: +44 (0)131 541 0118
- New York: +1 646-781-7580
- Minneapolis: +1 612-324-7410
- Bucharest: +40 316 301 707
This is a case study of an external network penetration test that Dionach performed on one office of a large UK organisation. Some of the information has been changed or omitted to maintain confidentiality.
The client had most of their web servers at a single office and wished to understand their current level of external risk. They commissioned Dionach to carry out an external penetration test and supplied Dionach with the external IP address range to be tested.
Dionach then proceeded with the four stages of the penetration test:
Dionach first verified that the IP address range supplied was assigned to the organisation by querying the RIPE Whois Database. This also starts the information gathering process, as emails, telephone numbers and addresses are available from RIPE. DNS servers were then queried for more information such as registration details and mail servers.
Internet, forum and newsgroup searches on key individuals did not reveal much information that would be useful in penetrating the network, for example any information about the technology that the organisation has used, or the skills of individuals.
An internally developed tool was used on search engines to find DNS names with IP addresses within the IP range. This turned up 19 different web sites on 5 different IP addresses. It was assumed that there were other web sites hosted by the organisation that hadn't been indexed by search engines.
Note that this information is all publicly available, and was discovered without any or very little direct contact with the organisation's network.
The external IP range was then scanned for common TCP and UDP services, such as FTP, Mail, DNS, web, and remote control services. More in-depth scans were also carried out three times over the course of the week of the test. These scans were carried out using two different tools and undertaken slowly to both keep scanning traffic at near zero, and evade any intrusion detection or prevention systems that may be in place.
The TCP port scanning revealed that no hosts replied to ICMP pings. There were several hosts web servers on port 80 and 443. There were SMTP mail gateways, a DNS server, FTP servers and a host with port 264 open that indicated a Checkpoint firewall.
The services banners showed that the web and FTP services were all Microsoft IIS based, with a mixture of IIS 4.0 (Windows NT) and IIS 5.0 (Windows 2000). Four of the service banners disclosed internal computer names or private IP addresses.
Mail relay variants were attempted on the mail servers with no success. Downloading the Checkpoint firewall topology was unsuccessful; this may have revealed internal network information. A DNS zone transfer on the DNS server was also unsuccessful, which may have also revealed internal network information.
A commercial web server vulnerability scanning tool and an open source vulnerability scanning tool were used to check for potential vulnerabilities on the relevant host services. These identified that one of the FTP servers allowed anonymous access, and that some of the web servers had not been locked down and had services that may be vulnerable to remote command execution.
The automated scans can reveal vulnerabilities, but a manual check usually reveals more information. One host allowed remote command execution. Dionach at this point informed the organisation that they had a critically compromised host.
Credentials were then retrieved for administrator level users. The surrounding network was enumerated, showing that the host was in a DMZ with access to other hosts.
Dionach then looked at the web sites identified in the information gathering exercise, and also the port scanning. Some of these were dynamic sites, with some using CGI applications with .exe extensions, and others using ASP pages.
Using open source scripts and tools, as well as in-house developed tools and a manual process, the dynamic web sites were checked for web application vulnerabilities.
Common problems were discovered, the most serious of which was that some of the pages on the web sites were vulnerable to SQL injection that allowed arbitrary SQL statements to be executed and also commands on the server itself, giving full control of the server.
The proxy server identified in the port scan appeared to allow access to an intranet, although limited internal information was available.
The issues listed above and other issues not mentioned were compiled and put into the final report. The report noted the dates the test was carried out on, and the IP address range. The issues were graded into the following risk levels: critical, high, medium, low and informational.
The executive summary specified that the overall security represented critical risk, and highlighted that although firewall configuration was well maintained, application and operating system security allowed remote intruders to gain access and control to a number of servers.
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.
There then followed the technical part of the report, which detailed:
Dionach then presented the report to the organisation face to face, which ensured that the organisation got the most value out of the report and a good understanding of the issues.
Following this, the organisation rebuilt the previously compromised web server, reviewed the web applications, and then requested Dionach to carry out a follow-up penetration test.
© Copyright 2018 Dionach