|Pentest shocks : SC Magazine : Blog : Home|
First Published: SC Magazine
Although I believe that a professionally delivered security assessment knocks the socks off a classic penetration test (pentest) for value and cost effectiveness, there are times when a pentest is more than adequate for the client immediate needs. This is commonly the case when they require a quick “attackers” evaluation of a semi-independent website – only partially or indirectly affiliated with their organisation.
From the clients perspective, this type of pentest represents a low cost investment in deciding whether the website requires a more detailed security review in the future. A stratagem obviously related to the “compelling event” security budget release program.
In this type of engagement, the number of involved parties is typically four or more, and includes: the paying client, their hosting provider, the custom application developer and the security consultancy carrying out the pentest. Depending upon who the client is, and how much weight they carry with the other parties, getting appropriate permissions to carry out the security work can either be very easy or a long tedious task.
Consider a pentest I worked on recently. In that engagement the client wished to verify that a division of their organisation who dealt with several highly sensitive financial documents, but subcontracted the application development and hosting to different companies, had secured the data to a sufficient level.
Given the size of the organisation requesting the work, and the small size of the other service providers, it was easy to get all the necessary consents to carryout 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 only supplied with a web URL and told that the site was a virtual website on a shared host. Permission to test the shared platform was authorised by the hosting provider, although all other virtual websites were beyond scope.
The day came to start the work, however the host was unavailable initially due to routing problems that had been caused with the hosting providers ISP dynamically responding to a series of malicious attacks from the evening before. Once this was corrected, work quickly begun on port scanning, service enumeration and vulnerability identification. Over all the findings were above average (almost good); indicating that the firewalls were correctly configured, default files had been removed and that the host was correctly patched against current vulnerabilities.
It was then time to focus upon the security of the custom developed application. Unfortunately for those concerned, 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 just about every data field that a site visitor could fill in was vulnerable to SQL Insertion or Cross-site Scripting attacks.
Now, normally this would be bad enough, but it actually got worse. The application allowed any authorised user to upload documents to the site (for later retrieval at a designated time by authorised personnel). Unfortunately two security failures in this part of the application lead to a complete host compromise. Firstly, 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. The second flaw was due to incorrect directory permissions of the installed web server software (in this case Microsoft IIS) which 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 would be bad enough for any website, but the fact that this host also supported many other virtual websites meant that they too would be compromised through the security faults of this website.
You would think that a complete host compromise with so little effort would be as bad as it gets. Unfortunately for the client (and the hosting provider) things actually got worse. While establishing the bounds and permissions of the successful host compromise, we discovered two interesting things. Firstly, there were a lot of connections to the host on unexpected ports that should have been blocked by a well configured firewall. Secondly, 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.
Upon updating the client of the findings, they agreed that the hosting provider should be alerted to this compromise and inform their other clients. We were then authorised to communicate the relevant findings to the hosting provider and provide advice on securing the platform. I believe they were very busy for the next few days.
Lessons to be Learned
(1) If you have confidential content or business critical services running on virtual websites or hosted on shared systems, a compromise in any other site will probably lead to a compromise of yours.
(2) It doesn’t matter how good your firewall is, a faulty custom application will lead to your downfall.
(3) Always ensure that the host and the services it runs have been secured using an up-to-date hardening strategy.
(4) Use local network management tools to monitor critical hosts for unusual directories, unauthorised applications and unexpected connections at regular intervals.