When a company is publicly shamed for poor practices that result in compromised customer information, the best-practice solution is to apologize and do anything and everything you can to prevent it from happening again and compensate customers accordingly. The “I’m going to shoot myself in the foot” practice, as I like to call it, is to blame the open source software community for your lack of updating and patching.
By now, it’s likely you’ve heard mention of the Equifax security breach. Millions of Americans relied on Equifax to protect their identity and credit from being stolen and used fraudulently by criminals. The news broke back in September shortly after a well-known Apache Struts vulnerability, CVE-2017-9805 was reported. Equifax came out and blamed this vulnerability for the breach in the hopes that it would convince customers that the vulnerability was a zero-day attack and that Equifax had little to no time to properly respond.
What happened after the report
But what Equifax underestimated was the amount of curiosity and free time that the cybersecurity community had. It was noted to the media that an earlier Apache Struts vulnerability, CVE-2017-5638, from March of 2017 that had the same CVSS score of 10 was far more likely the culprit. Equifax let slip in an interview that the hackers had been inside of the system as early as May of 2017, eliminating the September CVE from being the cause. Equifax was now caught in a lie to the public, and the public was rightfully outraged.
The drama didn’t stop there though. Instead of beginning the path to recovery, Equifax made the terrible decision to blame the Apache Foundation and the entire open source community for the vulnerabilities. To quote one of my favorite cyber security researchers, @SwiftOnSecurity, “Pretty much 99.99% of computer security incidents are oversights of SOLVED PROBLEMS.” The hardworking developers on the Apache Struts team are well aware of this fact, and responded to the community with the following post:
“The development team puts enormous efforts in securing and hardening the software we produce, and fixing problems whenever they come to our attention. In alignment with the Apache security policies, once we get notified of a possible security issue, we privately work with the reporting entity to reproduce and fix the problem and roll out a new release hardened against the found vulnerability. We then publicly announce the problem description and how to fix it. Even if exploit code is known to us, we try to hold back this information for several weeks to give Struts Framework users as much time as possible to patch their software products before exploits will pop up in the wild. However, since vulnerability detection and exploitation has become a professional business, it is and always will be likely that attacks will occur even before we fully disclose the attack vectors, by reverse engineering the code that fixes the vulnerability in question or by scanning for yet unknown vulnerabilities.” (from the Apache Software Foundation Blog)
I highly encourage reading the rest of the post as it’s both informative and insightful.
The vulnerability that affects Equifax affects many other businesses, as it affects versions of Struts going back as far as 2008. The cherry on top to this disaster of a public relations story, is there are now claims that several Equifax executives sold thousands of shares after the breach was discovered but before it was disclosed to the public with the shares selling for roughly $146 a share, according to the LA Times.
And once again, the biggest take away from this story is one I have echoed many a time, and it surely won’t be the last: Update your packages.
To get proactive notifications of security updates, patches, and hotfixes for the top open source packages, sign up for the OpenUpdate bi-weekly newsletter.