Hackers “strut” in again at Equifax… What stopped the patch?


It remains an intriguing question.  What prevented Equifax from acting on the patch for the recent Apache Struts breach?  And even more interesting, what would have been averted with a proactive approach? 

Criminals, who potentially gained access to the personal data of up to 145 million Equifax costumers, exploited an Apache Struts CVE-2017-5638 vulnerability.  The stolen data may include Social Security numbers, birth dates, driver’s licenses, addresses and 209,000 credit card numbers – all of which may now be putting these folks at identity theft risk for the rest of their lives. Apache Struts is a widely used open source software (OSS) component used by companies in commercial and in-house systems to take in and serve up data.   

Patch Not Applied for Months, It’s Common 

The suspected vulnerability was disclosed on March 7 along with a patch to address the vulnerability.  It’s typical for patches to be provided when a vulnerability is disclosed.  For example, patches were available when announced for 81 percent of the vulnerabilities in 2016 (Flexera Vulnerability Review 2017).   

But Equifax didn’t apply the patch immediately.  The company also didn’t discover the hack and act on it until July.  For many companies, this delay is quite common for two reasons.    

Two Big OSS Gaps—No Tracking of Use, No Proactive Prevention 

The average software product includes up to at least 50 percent of OSS, but little tracking exists for these components.  Research also shows that a company’s true list of OSS is on average 20 times larger than their current disclosure.  For example, most companies cannot produce a Bill of Materials (BOM) or list of the open source they are using.  Even during due diligence for a merger & acquisition (M&A), it’s often difficult to disclose even a single open source project they depend on.  It’s difficult to apply patches without tracking use. 

In addition, patching OSS is complicated so monitoring in advance becomes critical.  As my friend and colleague said, “Patching this type of vulnerability is certainly not as simple as patching a desktop application,” said Kasper Lindgaard, Senior Director of Secunia Research at Flexera. “It involves the software supply chain, so it’s important to align software design and engineering, operational and security requirements. This isn’t an easy task and you can see it in the Equifax timeframes—up to two months before the first reported unauthorised access and the further delay of the actual detection of the breach on July 29.  Companies need greater urgency and a preventive process that connects the dots.” 

Because of these gaps, organisations continue to leave a wide-open window of opportunity for hackers and that window is now open for Apache Struts. 

Expect More and Prepare—Long Tail of Breaches 

And that leads to the important point which now should receive more attention than the Equifax breach in the headlines.  Equifax has already identified the breach and responded, but they are probably just the first known victim. There will be more.   

Once a case like this hits the news, it ignites the fire in the cybercrime community and hackers start poking around for new opportunities. We should expect a long tail of incidents and breaches in the months – and potentially years – to come.  We still see attacks targeting Heartbleed, a vulnerability that is more than three years old. Which means it’s urgent for business leaders to radically rethink the organisation’s vision of cybersecurity, especially for OSS. The lack of basic security best practices and poor integration of security policies into operational processes makes it easy for hackers to be successful in their attacks – and makes it hard for security professionals to stop the attacks. 

Rethink OSS Cybersecurity—4 Steps 

It’s time for companies to build an infrastructure for OSS management that uncovers vulnerabilities and risks as well as manages the basics of licensing and compliance.  These 4 steps offer a solid start. 

Step 1: Start with education: The basics of compliance and OSS management need to be taught at all levels of the organisation.  Senior management must understand the investment needed to protect the company.  Development teams need to balance the speed of using OSS with a process for managing its use.  And development, legal, IT and management must all be aligned on the approach. 

Step 2: Create an Open Source Review Board (OSRB): This small team of subject-matter experts often includes technical, legal, IT and management.  It sets policies, responds to compliance and security events and provides training and knowledge to the rest of the company on open source.    

Step 3: Develop an application security strategy: A process for development teams to use for OSS should be created through the OSRB or even a team of security, development and IT, including: 

  • Checking internally developed code through pre-deployment, code-level security reviews and penetration tests   
  • Requiring code-level audits be performed by outsourced development and business partners 
  • Identifying and tracking all third-party code for security flaws and updated version information 
  • Creating adequate checkpoints and detailed audit trails for protecting applications   

Step 4: Use technology for faster action: Software Composition Analysis (SCA) solutions provide scanning technology that uncovers, manages and monitors the OSS being used. These tools also automate the process of vulnerability alerts and answer these questions: 

  • Which open source libraries are being used in my product? 
  • What other third-party libraries are being pulled in by default and are potentially introducing additional risk? 
  • What percentage of my proprietary code contains “stolen” or “copied” code from other third-party open source libraries without proper attribution? 

OSS Smart—The Signs of Cybersecurity Change 

Companies that make these changes should see the following results: 

  • OSS management becomes part of annual strategy discussions and budgets 
  • A written policy exists that spells out a process, accountability and roles 
  • Regular scans by an SCA solution provide ongoing status reports on usage, compliance and potential issues 
  • A bill-of-materials can be produced for each software release that follows the license obligations 
  • Patches can be proactively applied fast, even to products being shipped 

When companies take these steps, the result is a proactive process that protects the company, its reputation and, most importantly, its clients.    

Jeff Luszcz, VP of Product Management at Flexera 

Image Credit: Den Rise / Shutterstock