New breach, same lessons
The story of recent breaches at the credit-rating agency Equifax, which may have involved the personal details of nearly 150 million people, has probably just begun, given the confusion that still surrounds events. But it’s brought the security of open source software to the fore yet again, and highlighted the ongoing struggle organizations still have with cybersecurity.
So far there’s no indication of how many U.S. government organizations may have been affected by the software bug that apparently led to the Equifax mess. However, it’s already been compared to some of the most damaging breaches in recent years, such as those at Sony and Target and at the Office of Personnel Management in 2015 that could have leaked sensitive details of over 20 million U.S. government employees.
It also brings up elements of the debate that resulted from the 2014 Heartbleed bug that was related to a vulnerability in OpenSSL software. That discovery launched a back-and-forth argument about the inherent security of open source software and how much responsibility organizations should bear for the security of applications that used it.
The Equifax breach was blamed on a vulnerability in the Apache Software Foundation’s Struts version 2, an open source framework for building Java web applications. There have been a number of announcements of Struts vulnerabilities over the past few months, the most recent issued by the Center for Internet Security on Sept. 15.
Depending on the privileges associated with the application, according to CIS, an attacker could “install programs; view, change, or delete data; or create new accounts with full user rights.” It put the risk for medium and large government enterprises at high.
It was an earlier vulnerability, publicly announced Sept. 4, that’s thought to have been the one that attackers exploited. However, the Apache Foundation itself said that, given that the security breach at Equifax was already detected on July 5, it’s more likely that an even older earlier announced vulnerability on an unpatched Equifax server, or a zero-day exploit of an at-the-time unknown vulnerability, was the culprit.
The timelines on this are confusing. There were detailed stories of attacks using a Struts 2 vulnerability as far back as March 2017, with attackers carrying out a series of probing acts and injecting malware into systems.
Back in the Heartbleed days, detractors claimed that open-source software was inherently insecure because developers just didn’t keep as close an eye on security issues and weren’t as systematic in finding potential holes in code as proprietary developers were. Proponents, on the other, said that open source was, in fact, inherently at least as secure as other software and that it was safe for government agencies to use.
It’s not an academic issue. Sonatype, for example, claims that some 80-90 percent of modern applications contain open source components and issued a recent report that said an “insatiable appetite for innovation” was fueling both the supply and demand of open source components.
The Apache Foundation made the case that its developers put a huge effort into both hardening its products and fixing problems as they become known. However, it said, since vulnerability detection and exploitation is now a professional business, “it is and always will be likely that attacks will occur even before we fully disclose the attack vectors.”
In other words, it’s up to organizations that use Struts, or any other open source product for that matter, to treat security just as they would for a proprietary product: assume there are flaws in the software, put security layers in place and look for any unusual access to public-facing web pages. It's critical that organizations look for security patch releases and software updates and act on them immediately.
Sound advice for everyone. If only everyone followed it.
Posted by Brian Robinson on Sep 26, 2017 at 12:34 PM