X
October 29, 2013
This is the story of a minor XSS vulnerability in Contrast's website hosted at HubSpot. To be clear at the outset, HubSpot has fixed the problem, this is a "brochureware" website, *no* Contrast client information was ever at risk, and this has nothing to do with the Contrast TeamServer. And now that we have that out of the way, here's the story of how somebody tried to hack us.
Over the past 11 years we have found tens of thousands of vulnerabilities in critical web applications and web services. Some were in large financial applications using custom Java frameworks designed back in the early days of Java EE. Others were in super modern web applications using Spring, REST, and jQuery.
So when we designed Contrast, we built our TeamServer with strong protections against XSS. We use strong architectural patterns, enforce coding guidelines, and a proven validation and encoding library -- the Enterprise Security API from OWASP (which we created). We also test like crazy and run Contrast Assess on itself to make sure we don't have problems. You can read more about our defenses in our security story. We believe in transparency and encourage everyone to publish their approach to application security.
We host the Contrast public website using HubSpot. They make it easier for us to market our product, track leads, and produce interesting content. We've been very happy with the service and are expanding our use.
A side benefit of using HubSpot is that our public website is completely separate from the Contrast infrastructure. So even a serious security vulnerability in the website would not expose any Contrast customer data. Nevertheless, before selecting HubSpot, we did some security analysis and specifically tested for XSS in blog comments (something obviously changed).
So we were surprised on Tuesday morning when we received a comment on a recent blog posting that contained a trivial XSS attack. The attack was very simple.
"><img src=x onerror=confirm(1)>
Putting this in a blog comment causes the script to run in the webpage. This script simply pops up an alert box and simply proves the vulnerability. A real attacker could have used this vulnerability to modify the content of this page, insert phishing attacks, redirect users to malware, or trick users' browsers into submitting forms.
Even worse, the script also ran when viewed in the HubSpot administrative console. Here, an attacker could cause much more damage by essentially taking control of our website. Fortunately, we detected the attack, deleted the offending comment, and disabled comments in less than 5 minutes.
There is no security@hubspot.com type of obvious security reporting interface, so we worked through our customer rep. We couldn't get much traction. Because we had deleted the comment with the attack in it, there was considerable skepticism that the vulnerability was real. Repeated attempts to explain that all they need to do is put a few special characters in a blog comment were unsuccessful.
Since I was unwilling to re-enable blog comments until the problem is fixed, I asked for some other HubSpot blog that we could demonstrate the problem on. They provided a test blog and in minutes we had a POC. The POC was simple to create. It worked on the very first try. I sent it to the HubSpot team with a screenshot and some advice, to see if that would spur action. Here's part of the message I sent...
I really don't like the fact that we had to produce a POC to get traction. But right away we got confirmation that developers were working on the problem. Sigh.
Received a call indicating that HubSpot had fixed the problem. Performed some tests on the demo site that confirmed that the original vector had been fixed. Performed some more tests and confirmed that they had not followed our advice, but were deleting the < character and any tags. The > sign was not removed. Tried a battery of tests designed to exploit possible weaknesses in their scheme, including testing nested script tags <scr<script>ipt> and so on. The conclusion? While not the ideal solution, their fix does mitigate the vulnerability in this particular instance.
I mentioned to our representative that we are committed to security transparency and have a duty to post about this experience. They followed up with three separate calls from their CSO, CIO, and a member of their incident response team. I took the opportunity to find out what I could about their application security program.
I started by reviewing HubSpot's security story and scanning approach. From these, there's no way to know about their secure coding practices, since they only talk about SSL and WAF at the application level. So what are HubSpot's protections against the OWASP Top Ten? What does their application security program look like?
Unfortunately, I couldn't get a clear answer. This doesn't mean that they don't have a strong application security program, just that they're not willing to share it with me. Here's what I was able to figure out.
I have my concerns here and I wish they were more transparent, but I applaud HubSpot for being able to respond to the XSS problem in 24 hours. That's an impressive turnaround time. All in all, I'm glad that HubSpot is managing this part of our infrastructure. They took the problem seriously and deployed a fix quickly.
.jpg)
Jeff brings more than 20 years of security leadership experience as co-founder and Chief Technology Officer of Contrast Security. He recently authored the DZone DevSecOps, IAST, and RASP refcards and speaks frequently at conferences including JavaOne (Java Rockstar), BlackHat, QCon, RSA, OWASP, Velocity, and PivotalOne. Jeff is also a founder and major contributor to OWASP, where he served as Global Chairman for 9 years, and created the OWASP Top 10, OWASP Enterprise Security API, OWASP Application Security Verification Standard, XSS Prevention Cheat Sheet, and many more popular open source projects. Jeff has a BA from Virginia, an MA from George Mason, and a JD from Georgetown.
