After The Equifax Hack We Examined the Latest Apache Struts Code

In light of the recent news that the Equifax hack was a result of an old version of Apache Struts being exploited, we analyzed the latest code from Apache Struts with SourceClear. The code we analyzed can be found at https://github.com/apache/struts. At the time of analysis the code was last updated on Sept 6th at 11:28 am in this commit, updating the pom.xml file to upgrade the Log4J library.

We scanned the code using the latest version of the SourceClear agent (2.10.29) on a Macbook using the simple command

./srcclr scan --url https://github.com/apache/struts

The results show that project declares 75 direct libraries in its source code but adds an additional 117 libraries when it is built, making a total of 151 libraries being used when the code is built. This is less than the typical 1 in 4 ratio we see for Java projects. The screenshot below is a sunburst chart of the dependencies which is simpler than most Java applications we see and radically simpler than many JavaScript applications.

Of those 75 libraries declared by the developers, 40 of them are not using the latest version of those libraries (as defined by semver) and of the 151 libraries used by the project after being built 100 are not using the latest version (as defined by semver).

95.3% of the code comes from open-source libraries that the Struts framework itself is using. Despite the project specifying the Apache license, the open source libraries themselves use 12 different types of open-source licenses.

11 of the libraries have 43 vulnerabilities reported in the versions currently being used. Of those 43 vulnerabilities there are 2 High Risk CVE’s, 31 Medium Risk vulnerabilities with CVE’s and 3 Low Risk Vulnerabilities with CVE’s. There are also 3 High Risk vulnerabilities with Reserved CVE’s where information is not widely known as well as 3 Medium Risk and 1 Low Risk vulnerability with no CVE.

This is where is gets interesting. At SourceClear we build a complete dependency graph and a call-graph so we can trace a project's use of the vulnerable methods in vulnerable libraries whether declared in the source-code or in a library pulled in at build time. We know from experience that if you simply grep through build files you typically miss between 75% and 90% of the open-source libraries being used and that 90% of vulnerable libraries are not actually used in a vulnerable way. Analyzing code at build time using both a dependency graph and call-graph is the only way to do an accurate assessment and determine correct results.

In this particular case that analysis shows that the JasperReports library (that itself has been subject of several CVE’s) pulls in the Jackson-databind library 2.1.4 that is currently subject to a high risk reserved CVE. While there are no details available on the National Vulnerability Data, our researchers run technology that parses upstream commit logs and other public sources and we know that this is a remote code execution vulnerability. That data is actually public at RedHat who are a CVE numbering authority. In this particular case we have examined the call chain and don’t believe that this is exploitable.

We were interested to see how many other libraries use the vulnerable version of Jackson-databind so used our recently announced SGL technology.

vulnerability(identity: "2017-7525") has_version_range has_library union(dependent_on*, embedded_in*)

Using the query above we see that 10,566 other versions of other libraries are directly and indirectly affected by this vulnerability.

Summary

The current version of Struts at the time of analysis uses 11 libraries that have 43 vulnerabilities. One of those libraries jackson-databind was itself not specified by the developers but was added outside of their control by a library they did chose to use. That library has a remote code execution issue. This issue has been reported but is currently marked as a reserved CVE with limited information available. SGL shows that over 10,000 other versions of other libraries also use the vulnerable jackson-databind library. This type of analysis can be done by performing build-time analysis and identifying the vulnerable version of the Jackson-databind library would have been missed by simple tools that only parse code in Git repos and match results against CVE’s.