HubSpot Vulnerability Fixed - Cross-Site Scripting (XSS) In The Cloud

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.

XSS Defenses? Check!

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 Like HubSpot

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).

Tuesday 11:42 AM - The Attack

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.

Tuesday 11:50 to 3:15 - Reporting the Vulnerability

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.

Tuesday 3:40 PM - The Proof of Concept

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.

Wednesday 11:26 AM - The Fix!

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.

Thoughts on HubSpot's Security Program

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.

• They have performed an analysis to see if this vulnerability was exploited
• They don't think this vulnerability was actually exploited, based on some sort of content scan
• They believe they have no legal requirement to disclose and won't be saying anything publicly about it
• They claim to use several tools and several highly regarded vendors
• They can't say how such a simple XSS was able to get through their program
• They won't share what security controls are in place or what their security roadmap includes.
• They don't know when SSL might be added

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.