As a Java programmer, it frightens me how much companies depend on pulling hundreds of third party jars into their Java projects to speed up development. It’s pretty much a guarantee that at any given time a dozen of them have serious security flaws…
And if anyone thinks only Equifax has such lax and incompetent security, they’re crazy. The state of computer security in 2017 is astonishingly bad.
The solution to this is having scripts that continually go through your projects and show you outdated jars. It should be part of the CI. Trouble is you don’t often know if a jar update is security related or not like with traditional package management. But still on production projects, you really shouldn’t let your dependencies rot either.
I mean, the alternative is to write the code and security holes yourself. You’ll have the same security issues either way :P
The problem is that bundling dependencies prevents them from being updated in a timely fasion (ie, as part of system updates). Nobody’s saying third-party code is bad.
Is this accurate? Some of those screens were up on HN a few days ago (specifically the json data) and people had some legit concerns that the data wasn’t the real leaked data.
Is the actual leaked information up anywhere? I’m surprised at how little information there is on exactly how they even knew about the data breach.
And the author of the posts says Equifax blamed Apache, but actually it was Apache Struts, a specific Java web framework (which I myself used at one point and haven’t touched since 2009).
So what really happened and how did people find out about the actual hack. Those are still questions I haven’t seen a reliable answer to anywhere. This page has a lot of screens that may explain it (although I thought the admin/admin thing was a totally separate issue in Argentina?)
The odds-on favorite is a Struts bug discovered and tagged as CVE-2017-5638 in March of this year.
Originally some thought it was this Struts issue but the Equifax breach was discovered in July. If it was CVE-2017-9805, then it would have been a zero-day.
And depending on when Equifax was first breach, the use of CVE-2017-5638 might have been a zero day at the time. And to be mildly fair to Equifax, fixing CVE-2017-5638 is non-trivial because it can require rebuilding numerous packages.
Still, from what we’ve seen in their handling of the breach, Equifax don’t appear to have a mature security culture. There may have been more than one door in.
Update: I originally wrote that CVE-2017-5638 had been around for 9 years (unknown). It was actually CVE-2017-5638 that had been around for 9 years (unknown).