So...you can hack a server with XSS?

It's been awhile since I've updated you, dear reader, regarding matters concerning McAfee Secure.
You may recall I met with Joe Pierini and Kirk Lawrence of McAfee Secure in August, and received an update regarding the still pending "McAfee Secure Standard" in October.
Sadly, both Joe and Kirk have left McAfee, in pursuit of better opportunities, leaving our McAfee Secure crusade in lurch. I'll be updating you on the Standard (allegedly, now being released in January), and other proposed improvements to the McAfee Secure offering in days to come. I have been informed that there are people at McAfee willing to carry on the work that Joe and Kirk started.

Now, that said, an update from Joe Pierini. You may recall the numerous times I, and many others, have heckled Joe for his Pwnie award winning statement "Cross-site scripting can't be used to hack a server."
Joe has surprised me at more than one interval; first, attending the Pwnie Awards ceremony at BlackHat 2008, and later, agreeing to fly to Seattle to meet with me and discuss considering significant changes and improvements in the McAfee Secure program.
What I've learned of Joe is that he is technically capable, a worthy web application security assessor and pen tester in his own right, and someone who prefers "breaking things" in the trenches, as opposed to promoting brands as an SE.
Having had numerous conversations with Joe since August, I believe this: the debate sparked by his now infamous "can't hack a server with XSS" statement came down to semantics and context. To be fair, the act of dropping javascript strings behind a vulnerable GET parameter is not a server hack per se, particularly if not utilized in a hybrid attack.
But enough from me; Joe explains just such a hybrid approach quite elegantly in a letter I recently received from him. It is reprinted here with his permission, and I appreciate the opportunity to share it.

Russ,

As you know, I left McAfee Secure in early December to join a security firm in San Jose as a Security Consultant. We provide PCI assurance services related to Merchants, Financial Institutions, Processors and Service Providers. As soon as I complete the PCI Security Standards Council's Qualified Security Assessor (QSA) training course, I will be assuming the responsibilities as a QSA but in the mean time I am performing penetration tests for clients needing to meet the PCI 11.3 requirements.

In one of my first engagements, I came upon a situation where there were no critical vulnerabilities and a few minor issues including XSS and a couple of Exchange mail servers with an open relay misconfiguration. These findings are sufficient with which to take a merchant out of PCI compliance but they lack the drama and urgency of more serious vulnerabilities like SQL Injection. My infamous, award winning catch phrase, “You can’t hack a server with it”, came back to haunt me. While you and I have agreed this is technically true, the the 11.3 penetration tests I was conducting are intended to exploit vulnerabilities. What I needed was an attack scenario that would get their attention and demonstrate the risk of having XSS in the web site.

The mail servers would only allow mail relaying to email addresses within the domain. They would provide the perfect delivery mechanism for the attack. A remote web server could be configured to host the attack pages for XSS Shell. This application ( http://labs.portcullis.co.uk/application/xssshell/) makes use of concepts first presented by XSS Proxy over 3 years ago: persistent, bi-directional communication with a client machine using XSS. The XSS Shell makes it possible to log keystrokes, steal the clipboard, execute arbitrary javascript and more. I don't need to hack the server with it, I could attack the entire company.

First, I could craft an email pretending to be from the web development team asking for help in testing a new piece of functionality in the website. I could then embed an HTML link in the page directing them to their own website, albeit with an attack exploiting the XSS weakness in their web site appended to it. Because the company users would receive an email with all the right headers from their own mail server and directing them to a site they own and inherently trusted, the click through rate would be extremely high and I could collect the session and clip board content from dozens of users. If my instinct was correct, I wouldn't need to upload arbitrary javascript because I would have enough to prove my point: XSS is dangerous and poses an immediate risk.

It’s not just about the servers or the clients, XSS can leave the entire company vulnerable to attack.

Best Regards,
--
Joseph Pierini | CISSP, CISM

Best regards indeed. Thank you, Joe.

del.icio.us | digg | Submit to Slashdot