Don’t ignore pentests

By on
Don’t ignore pentests

Gunter Ollmann explains what an investigative penetration test can reveal to the client and, maybe, the host.

I believe a professionally delivered security assessment knocks the socks off a classic penetration test (pentest) for value and cost effectiveness. But there are times when a pentest is more than adequate for a client's immediate needs. This is commonly the case when the client requires a quick "attacker's" evaluation of a semi-independent website – one partially or indirectly affiliated with their organization.

From the client's perspective, this type of pentest represents an economic way to evaluate if the website requires a more detailed security review in the future. It's a stratagem obviously related to the "compelling event" security-budget release program.

In this type of engagement, there are normally four involved parties or more: the paying client; their hosting provider; the custom application developer; and the security consultancy executing the pentest. Depending on the client, and how much weight it carries with the other parties, getting appropriate permissions to execute the security work can be an easy or very tedious task.

Consider a pentest I worked on recently. With this engagement, the client wished to verify that a division of its organization that dealt with several highly sensitive financial documents, but which subcontracted the application development and hosting to different companies, had sufficiently secured the data.

Given the size of the organization requesting the work, and the small size of the service providers, it was easy to get all the necessary consents to perform the pentest. Any findings and reports generated as part of the pentest would only go to the paying client, who would then decide what (if any) information would flow to the service providers.

In this limited knowledge engagement, we were told that the site was a virtual website on a shared host and we were only given a web URL. Permission to test the shared platform was authorized by the hosting provider, but all other virtual websites were beyond scope.

The day we started working, the host was initially unavailable due to routing problems that had been caused with the hosting provider's ISP dynamically responding to a series of malicious attacks from the evening before. When corrected, work quickly began on port scanning, service enumeration and vulnerability identification. The findings were above average (almost good); indicating the firewalls were correctly configured, default files had been removed, and the host was correctly patched against current vulnerabilities.

We then focused upon the security of the custom developed application. Unfortunately, it only took a few minutes of manual testing to identify a critical flaw in the login page. By submitting a user name of a' or 'a' = 'a, it was possible to bypass all authentication processes and access the application data as an administrator. In fact, almost every data field that a site visitor could complete was vulnerable to SQL insertion or cross-site scripting attacks.

This was bad, but it got worse. The application allowed any authorized user to upload documents to the site, for later retrieval at a designated time by authorized personnel.

Two security failures in this part of the application lead to a complete host compromise. First, the application did not check or restrict the types of file that could be uploaded. This allowed us to upload our own web page containing server-executable code. Second, incorrect directory permissions of the installed web server software allowed "execute" permissions on files uploaded. Thus, we were able to upload our own page that allowed us to run Windows 2000 command-line instructions and view the results. This is bad for any website, but the fact that this host supports other virtual websites meant that they would also be compromised through the security faults of this site.

A complete host compromise with so little effort is terrible, but unfortunately for the client – and the hosting provider – things got worse. While establishing the bounds and permissions of the successful host compromise, we discovered two things. First, there were a lot of connections to the host on unexpected ports that should have been blocked by a well-configured firewall. Second, there was a directory called "Movies" at the root of one of the hard drives containing illegal software (often referred to as 'warez') and illegal rips of current movies. We were able to conclude that the host had been compromised at an earlier date and was still in use as an active warez repository.

When we told the client what we'd found, it agreed the hosting provider should be alerted to this compromise and inform its other clients. So we passed on the relevant findings to the hosting provider and supplied advice on securing the platform. This pentest proved to be potent, and worthwhile. 

Copyright © SC Magazine, US edition

Most Read Articles

Log In

|  Forgot your password?