In early 2009 a client contacted me for a penetration test to fulfill their PCI obligation. In the past, pentests with this organization were limited in scope to the web application. Thanks to a previous round of pentests, plus a clued-in developer/admin/security staffer, all of the typical low-hanging fruit for a web app assessment was not found. Minor issues were found in the past, but they were pretty much useless to lead to an actual penetration, even in conjunction with other issues. Such issues were only useful in padding the report. (the world will certainly end due to the high-severity "traceroute to host" for instance)

Still, the web application was critical to test New development existed, fresh attack surface. Every type of XSS test that I tried, even using the newest known evasions, was met with failure. The same was true of any type of SQL injection attempt. Other types of injections such as XPATH and LDAP injection were not going to be fruitful, given the dynamics of the system that I had previously learned. In addition, all of the encoding tricks didn't seem to matter as the developer was able to shim a security check into the system at a very low level that was checked after the encoding was decoded, resulting in an annoying (but effective against a typical scan) host-based firewall shun (iptables DROP). This was easy to circumvent with the use of TOR but did slow down the assessment. After hours of trying various scanning tools such as w3af, BURP Scanner Professional (very nice tool), and manual attempts, I gave up on this angle of attack. The web application was the most obvious route into the clients cardholder data environment, and it had been hardened a great deal. Many other webapp and webserver tricks were tried, and all of them failed, leaving the noisy brute-force methodology. This was also setup on a shun after a certain threshold was reached, and there was no easy way to determine the username or password formats at this stage of the game.

Expanding the Scope - a wider look through the telescope and microscope

Thankfully, this time around I was able to talk the client into allowing client-side and social engineering testing to be within scope. I learned later that this allowance was in part due to a special social engineering process on the part of the client's technical person who wanted the test to be representative of what a real-world targeted attack would be like. This person realized that banging one's head against a hardened webserver and a network firewall and declaring things secure while other attack surface is untouched is a recipe for FAIL.

Armed with an expanded scope, I began anew with some typical google queries and maltego information gathering tricks. I first learned of Maltego from AttackResearch's own Chris Gates (CG). This led to some support forum posts from company users and company e-mail addresses. A techie was having a problem with a specific web application and kindly posted the private URL paths to the public forum. These URL's were not restricted to the world like they should have been, especially one that by it's name was intended for internal company use. Keeping the shunning capabilities in mind, a manual assessment with Burp Professional's proxy was undertaken. Attempts at an oldschool-yet-still-useful directory traversal exposed an internal link. Following this internal link presented me with a special cookie that gave me some type of guest login credentials. With this, I was able to browse the internal company site and found the motherlode - a large amount of documentation describing their network, security procedures, host tables and much more in great detail. I knew this would be very useful and began pilfering documents relevant to the target at hand. Later, I analyzed the cookie and determined that by careful editing, I could pose as any authenticated user and post documents as that person. This was a somewhat lame, but effective 0day bug in this particular web app implementation and I won't mention further details until I'm certain that this particular client has taken care of the issue.

From ravaging their internal documentation, I discovered their particular antivirus vendor and other security measures in place. This would save a lot of time. I whipped out metasploit and used msfencode to encode a meterpreter payload with Shikata_ga_nai, and promptly tested against an online antivirus scanning service. The resulting binary passed through most antivirus apps with flying colors. This issue is well known among pentesters as well as the malware writing underground. I setup a multi-handler listener in preparation for the 0wnage that was to come.

Next, a faked internal document was written that included the Meterpreter binary. The binary was attached to a page that was specially crafted using the writing style of the staffer that would have legitimately offered such a thing to the internal users. The binary was posited as a fake windows security patch designed to implement a more robust ASLR to Windows XP, which several of the organizations users were running (easily determined through the up-to-date documentation that was found).

Thanks to a lot of googling, it was easy to copy the clients e-mail signature and writing style, and it was determined that the clients main security staffer often used a mail account from a large free e-mail provider and that a strict distinction between "work use" and "personal use" was not maintained at this organization. The creation of a new account that was very similar (transposing two letters in the last name) and the inclusion of the signature created the right platform to abuse trust. A carefully crafted mail message was sent to the targets, mimicking the time that this user might actually be sending such a message. ("look, he's working from home again, what a guy").

The next morning, a meterpreter session opened, bringing me that much closer to the penetration test target - card data. Unfortunately, the meterpreter script that I tried to use that had been recently published and presented at BlackHat and Defcon - PhishScrape.rb - didn't work in this case for unknown reasons, as I found out later. Various amounts of pilfering were done on this workstation including the instantiation of the meterpreter keylogger and the downloading of various resources of interest (see "tactical exploitation" presentations from HD Moore and ValSmith from a few years ago for more ideas on this). I ran into some technical problems that prevented me from pivoting through the box as I had hoped, but what I had was enough for now.

Turns out that the card data itself was extremely well protected. The client went well above PCI requirements and created a very tough nut to crack. With more time, that may have been possible but I think it would have increased the time of the pentest by at least double due to all the requirements that would have to be met. However, getting into one sensitive internal workstation was enough to raise serious alarms at the organization. Even though card data was not immediately at risk, thankfully the organizations management realized that the level of access obtained was critical and could have offered a malicious attacker many opportunities for serious damage. As a result of this, additional attention was given to the security suggestions offered forth in the report and I suspect that the client won't be as easily tricked again, making the next penetration test that much more difficult. But that's OK. I'll rise to the challenge. In the meanwhile, they gain valuable experience into a targeted attack and have more understanding how the desktop and the user is often the weakest link in the security chain. Hopefully this knowledge will help them to avoid real targeted attacks.

Pentesting is fun and is a great service to the client. Let's hope, for the sake of security, that more clients consider opening up the scope to client-side and social engineering, for without them, the modern attack surface is missed. In the near future I suspect that we'll need to make sure that mobile devices are in-scope.

The opportunity to think creatively and leverage everything at your disposal (within scope, of course) really gets the brain working. Paid to implement 0wnage. Fun times.

Timelord