Technical Insight

What can you do today to prevent a breach?

As the news unfolds on Equifax and the latest and greatest of the Apache Struts hacks, a co-worker and I were talking about it amongst ourselves. “Why would someone leave a critical vulnerability unpatched for months?”, my co-worker asked in puzzled tones.

That’s a long and sad story, I had to say. But it’s not different than the reason organizations may still be on XP for laptops. It’s a story entirely about budget and risk, and helping the people who own responsibility for the former to better understand the latter.

For every major breach, somewhere, there was likely a DevOps guy or IT Security manager who felt:

Back in December, Ryan O’Leary observed in his security predictions blog that 50% of the websites we assess have a Cross-site Scripting (XSS) vulnerability present. With a third of the malicious attacks against companies coming through web applications (thanks for the info, Verizon), and with 50% of websites estimated as being vulnerable, the odds are in favor of web applications being the most insidious attack vector for the foreseeable future.

With over a billion websites out there, do you want to take a guess at how many are proactively scanning for vulnerabilities? Hint: It’s much closer to the tens of thousands. And that’s a generous estimate, based on my own rough guess at the number handled by WhiteHat and our fellow Gartner Magic Quadrant leaders.

But then came the Equifax news

I’m sure there are executives who still don’t understand how an application can cause a data breach. Have you been wondering what to tell yours?

In simple terms, web applications are the gateways to databases. Through APIs, a compromised web application can read and write information back and forth to a back-end database. Every system, database, or network that an application is an extended part of can be reached once the application is breached, through exploits with the qualities of Escalations of Privilege, Remote Access attacks, or other methodologies used to launch and spread breaches through an organization.

I drew a primer’s picture below:

How was Equifax breached and does WhiteHat scan for that vulnerability?

Equifax was breached due to a third-party library vulnerability in their code – Apache Struts. (Apache Struts is an open-source MVC framework for Java.) Apache Struts helps developers build complex applications by reusing components for certain tasks. WhiteHat started scanning for the Apache Struts vulnerability back in March when it was announced via CVE-2017-5638 and this month for the new CVE-2017-9805 and CVE-2017-12611.

For SAST, the vulnerability class is Unpatched Library – this has a critical rating.

For DAST, the vulnerability class is Application Code Execution for the new CVEs with scores of 10/10 for both impact and likelihood.  Vulnerability tags can be used to filter for findings related to these CVEs: “OGNL_injection” and “expression_language_injection” for CVE-2017-12611, and “CVE-2017-9805” and “S2-052” for CVE-2017-9805.

Although this means that a customer knows they have a vulnerability, it doesn’t mean they’re fully aware of the ramifications of not remediating it right away. We’ve attempted to help bridge that gap by reaching out to every current vulnerable customer, letting them know in no uncertain terms that they have the same vulnerability and really ought to do something about it.

I wanted to add a brief shout-out for Apache Software Foundation for their blog response as well. We are all in a constant war, trying to secure products and customers against hackers. Sometimes flaws exist without exploits being created for them. Sometimes exploits exist in secret (zero-days) which companies are not informed about. Patch early, patch often.

Now You Ask – Is This My Problem?

How do you find out if you have this vulnerability in your own web application? Check in Sentinel:


  1. Open up Sentinel
  2. Navigate to either the Findings or Assets tabs.
    1. If Assets – scan down to look for Cross Site Scripting listings.
    2. If Findings, click on the Vuln ID with the Class Application Code Execution
  3. Clicking on Vector Detail teaches you how to reproduce the problem
  4. Clicking on Description & Solution lets you know how you should change your code
  5. Ask a Question will get expert advice, as much as you need to help you get the code fixed.
  6. When your web team says they updated Apache Struts, you can re-test that vulnerability – just to be sure.

The same basic method works (searching on Application Code Execution, as mentioned) if you have Sentinel Source.

What can I do until then?

For those of you who do not have the developer resources to update the above, or are reliant on long sprints/backlogs, or third-party software you didn’t create – let’s talk virtual patching. Do you have a Web Application Firewall? (F5, Imperva, and Fortinet are all very fine products. I was following the F5 Blog on this issue.) Any of these can take data from your Dynamic scan results to create virtual patches.

At the very least, consider importing your application scan results into your SIEM, Vulnerability Management system, or GRC system if you have one. Someone with the ability to decide about budget and priorities needs to see the application issues marked in red, and persistently present.

In the end, virtual patching is not as effective as fixing the problem. But it’s a heck of a lot better than being a sitting duck. And maybe the size of this latest breach will be a huge warning flag to everyone else in the finance space – not to mention the security ecosystem as a whole.

It’s not just about perimeter security, people. You have to patch your web application code.