What Does a Security Company Do with Responsibly Disclosed Vulnerabilities?

Security Innovation has built a fun and engaging vulnerability hunting training ground we call CMD+CTRL. We’ve designed 5 separate vulnerable websites and an insecure Android mobile app of differing levels of difficulty to help players learn how hackers hack. Each vulnerable site connects to a centralized scoreboard website that automatically tracks and scores each vulnerability that players find in real time. It’s been exciting and fulfilling to build and to get into player’s hands.

We knew going into this that creating purposefully vulnerable web sites and applications that are also resilient to any unintended vulnerabilities was going to be difficult.

We were right.

We recently collaborated with the Portland ISSA to host a CMD+CTRL event where we invited anybody who’d like to play to experience the CMD+CTRL hackathon. Overall the event was a great success.

We were very appreciative when we heard from Alex Ivkin and Alexei Kojenov that they wanted to responsibly disclose the exploitation of an unintended security vulnerability in one of our vulnerable sites.

Not only did Alex and Alexei win the event with the most issues found they also discovered that our vulnerable site, ShadowBank, was running a vulnerable version of Apache Struts, which could lead to Remote Code Execution or RCE. RCE is the gold standard of security vulnerabilities. Depending on some factors on the exploited system it could lead to a complete compromise of the server.

Luckily, we did already know about this issue and were in the process of rolling out updates to Struts to the AMIs that spawn the vulnerable websites, so this vulnerability was known about and in the process of being remediated. It was exciting to hear from the two and get their exceptionally well written vulnerability report. As a security company that helps our customers design disclosure and bug bounty programs it was interesting to be on the other side of the disclosure.

First and foremost, I’d like to thank Alex and Alexei for responsibly disclosing the issue to us. Next, I’d like to take a moment to walk through the timeline of disclosure and how we handled the discussion internally and externally.

As security experts, we tend to bump into a lot of security issues in our day to day use of software, and while we always follow responsible disclosure with our customers it is lovely to work with a company who appreciates responsible disclosure and communicates well.

The primary tenets of good communication with security researchers are:

• Timeliness
• Open Communication
• Respect
• Follow through and Closure

Let’s look at each of these in turn.

Timeliness
Security Researchers are going out of their way to disclose an issue to you. They want to know that their concerns are heard and understood. This means responding quickly to the initial line of communication.

We first received Alexei and Alex’s write-up in PDF form at 12:48 AM. This kicked off an internal discussion at 12:50 AM that morning. We responded to them letting them know that we’ll discuss internally immediately (1:01 AM), I guess it’s good that the main point of contact, our VP of Sales never sleeps! 

Open Communication
It’s important to be open to communication in any medium that it may come in. If you expect a security researcher to call you on the phone during business hours, you’re going to have a bad time. A lot of security issues get initially disclosed on Twitter, many also get handled over email. Make this really, really easy for the researcher. They’re giving you free security testing! Make sure you publicize a security@yourcompany.com email address, and consider signing up for a bug bounty program like Bugcrowd or HackerOne.

We were happy to receive the initial line of communication to our VP of Sales, Jeff Berry jberry@securityinnovation.com. He knew just what to do and how to handle the issue.

Respect
We all want to be treated with respect, but a Security Researcher has already earned my respect when they contact me to responsibly disclose a security issue. They deserve to be listened to, understood and given the benefit of the doubt. Treating them like an “evil hacker” will only distance them. Thank the researcher for their time and effort.

Follow through and Closure
Ultimately the Security Researcher wants to know that the security issue will be appropriately addressed. If you choose not to fix an issue, make sure the researcher understands your thinking and your plan for handling it.

We had some internal discussions on how to respond and how to patch the issue, which took some time. Then, the CMD+CTRL team responded to them at around 4:00 PM the next day to let them know we were working on a patch and thanking them for the disclosure. Ultimately, we had a verified fix into the system a couple of days later. After it was patched, we followed up with them to close the loop. 

Conclusion
Security Researchers, particularly people who responsibly disclose issues, should be considered partners and allies not adversaries. We hear from both sides that there’s a big hurdle in disclosure. Vendors can think of researchers as criminals looking for a payout and researchers can think of vendors as unwilling to fix security issues. In reality, researchers want to help the vendor to improve the security of the software they use or that affects end user’s security, privacy or safety. Vendors, too, want to want to build the most secure software they can and protect their user’s data, but often have a wide range of competing pressures when building software. Remember security researchers are here to help your software to become better. They deserve your attention, time, and respect even if a fix isn’t possible immediately.

Of course nobody likes hearing about flaws in your software or deployment, but it’s so much better to hear about it from a researcher so you can mitigate the threat than to discover you’ve had a resident hacker on your network for some unknown amount of time!