
Hackers who broke into Equifax exploited a flaw in open-source server software - uptown
https://qz.com/1073221/the-hackers-who-broke-into-equifax-exploited-a-nine-year-old-security-flaw/
======
valbaca
To give nuance to the clickbait:

"The vulnerability in Struts was just recently discovered by security
researchers, who announced it earlier this week on Sept. 4. According to the
researchers, the bug has existed since 2008."

~~~
cpncrunch
Equifax discovered the hack on July 29, more than a month before this
vulnerability was discovered.

~~~
ihattendorf
A month before this vulnerability was discovered _by these specific security
researchers_.

~~~
AdamJacobMuller
A month before it was _disclosed_ by these researchers.

Given the magnitude of this hack, it is entirely possible they embargoed it
for a while.

------
ekimekim
Take this with a grain of salt: They claim that the Struts vulnerability in
question is specifically CVE-2017-9805, and cite a William Baird & Co. report
[1]. However, the report in question says nothing about a specific CVE, only
that it was "the Apache Struts flaw". Struts has had multiple vulnerabilities
recently, such as one back in February (CVE-2017-5638). It's possible it was
one of these that they failed to patch.

[1]
[https://baird.bluematrix.com/docs/pdf/dbf801ef-f20e-4d6f-91c...](https://baird.bluematrix.com/docs/pdf/dbf801ef-f20e-4d6f-91c1-88e55503ecb0.pdf)

~~~
phkahler
I just hope the EFX breach used an older exploit and not a zero-day. That may
have some influence on their perceived liability.

~~~
bodz
Why do you hope that? Do you _want_ them to be liable?

If it was a zero-day then they legitimately may not be at fault.

~~~
bluejekyll
Forget about the zero-day for a minute.

They should be liable for poor storage practices around sensitive PII. Take
for example SSN. With SHA2, there is no good reason for them to be stored in
plaintext.

If you don't need it, don't store it. For SSN, you just need a function
(SHA256+Salt) that would give you a one way mechanism of Creating an
identifier that masks the original in an irreversible way.

The prevalence and misuse of SSN as an identifier for people is so out of date
at this point and weak. We need something different.

~~~
bga
If you're just hashing with SHA2 and a salt, an attacker with a run-of-the-
mill GPU could crack any given hashing quite quickly. It might still take
quite a bit of time to get all 143 million, but that's fine. Sell off the
score in blocks of 10,000 and let the customer know they have to reverse the
hashes themselves.

BCrypt with lots of rounds would be best.

~~~
bluejekyll
Yes. You're correct of course. We should be treating these like passwords,
except that they can't be rotated...

------
ajarmst
I find the title irritating, as it seems to impugn open source software as a
category. Why is the licensing model even relevant? A better phrasing would be
something like "...flaw in a popular web framework" or "...flaw in Apache
Struts."

~~~
znpy
> Why is the licensing model even relevant?

Licensing model directly affects the availability of source code, and this
technically facilitates exploit discovery.

~~~
throwawaykf09
Also, many open source proponents claim that open source software is more
secure because the “many eyes” theory will lead to bugs and vulnerabilities
being discovered sooner. This and other high profile exploits like heartbleed
show how well this theory applies in practice is questionable.

~~~
lillesvin
I find that conclusion presumptuous. Unless you can say how many bugs would
have been discovered had the source been closed, then it doesn't make sense to
claim the opposite.

Also, do we know that e.g. this and Heartbleed were discovered by reading the
source? If they weren't then the availability of the source code is
inconsequential IMO.

------
fencepost
This is based on a report from Baird Equity Research.

Some key items from that report:

* "Our understanding is data retained by EFX primarily generated through consumer interactions was breached via the Apache Struts flaw (i.e., core databases not believed to have been breached)."

* "Key EFX databases are not known to have been breached as part of the incident, including the consumer credit file, TWN, NCTUE, IXI, or its commercial credit database. Our understanding is that data entered (and retained) through consumer portals/interactions (consumers inquiring about their credit reports, disputes, etc.) and data around it was breached via the Apache Struts flaw."

* "the breach is believed to have occurred from mid-May through July" and was discovered on July 29.

It's not clear whether this is referring to the Struts problem just announced
or if it's the Struts problem earlier in the year, but if it's the just-
announced one then it means that someone was actively exploiting it in the
wild since at least May of this year. The timeframe would fit better for the
early-2017 vulnerability [1] which was apparently also being exploited in the
wild in March.

Obviously if they had enough access to the system it would be possible to
connect through to the databases being accessed, but if this was all scraping
of data passing through rather than at-rest then it may also indicate a lot
more sophistication in the attack - unless there's a small number of points
where the attackers could copy out data, this likely required a fair amount of
analysis of Equifax's code to shim things in and grab data without breaking
things.

The other interesting question is more along the lines of "If you haven't
interacted with Equifax and haven't applied for anything involving credit,
does that lessen the risk that you're impacted?"

[1] [https://cve.mitre.org/cgi-
bin/cvename.cgi?name=CVE-2017-5638](https://cve.mitre.org/cgi-
bin/cvename.cgi?name=CVE-2017-5638) (Apache Struts Jakarta Multipart Parser
file upload vulnerability for RCE)

~~~
marksellers
I find it curious how one can implant code like this into existing codebases.
It takes us a while to code review and deploy, and when we deploy we overwrite
what's already on production

------
runeks
Regarding CVE-2017-9805, I’m genuinely in awe over how remote code execution
in Java is even possible. Why should it even be possible to deserialize data
on the wire into executable code?

Also, can someone shed light on the technical side of this? E.g., how does the
JVM compile Java code it receives on the wire into Java byte code? Does the
JVM runtime have a built-in Java compiler that outputs Java byte code that it
itself can execute?

[https://lgtm.com/blog/apache_struts_CVE-2017-9805](https://lgtm.com/blog/apache_struts_CVE-2017-9805)

~~~
technion
I had shock and awe when I learnt how to exploit PHP's unserialize()
vulnerabilities, shock when I learnt Python had the same thing with unpickle,
and then somewhat lost the plot reading about a previous Rails vulnerability
which looks very much like this struts vulnerability.

It's unsurprising someone, somehow, built the same thing for Java, but I wish
we'd move from "don't unserialize unless it's safe" to "this language should
not have this feature".

~~~
needusername
Well, the intended goal of the plugin in question is to enable Rails-like
functionality [1]. So if they took inspiration from there it's not that
surprising if they end up with the same vulnerabilities.

[1] [http://struts.apache.org/docs/rest-
plugin.html](http://struts.apache.org/docs/rest-plugin.html)

~~~
runeks
In my humble opinion, when a remote code execution vulnerability appears in an
application written in a memory safe language, you know you’ve chosen the
wrong way to model a problem.

The art of writing code is defining the problem space, which is avoided
completely when you allow the consumer of your interface to execute arbitrary
code. The whole point of interfaces is to restrict the possible actions of a
consumer of it — i.e. the inverse of arbitrary remote code execution — which
is the hard part of software design.

------
Nomentatus
(Also posted in the discussion for an article re the lawsuits being filed vs
Equifax for the leak)

Credit card companies could provide other businesses such as Equifax distinct
mere-reference numbers which the customer doesn't see and which can't be used
for purchases - just to absolutely identify which card, for all parties. These
could be added to the magnetic stripe or chip in the card, for example. (It
might be gilding the Lilly, but many such reference numbers could be used for
a given card, re privacy issues or otherwise. But then those numbers couldn't
be usefully passed between companies for all purposes.) There's no need for
anyone but the customer and Credit Card company itself to retain the actual
credit-obtaining-number (other than to allow future purchases with permission,
which is the rarer case, often needs to be prevented not facilitated, and
doesn't excuse Equifax having more than a reference number.) Yet the credit
card companies don't do this. Why not? 'Cause humans are idiots, all of us,
that's why. PS - run to the patent office and you might be able to make a ton
of money patenting this, since patents are now given to whoever shows up at
the patent office with the appropriate fees first. Precedence doesn't matter.
You would be implying that you thought the idea up independently, of course,
but you're smart, right? That's totally the sort of thing you could think of
independently. Then when you're rich, you too can help choose what the patent
laws look like, and whether rich people should pay taxes.

------
norikki
> a popular plugin called REST

Why cant tech 'journalists' get someone who knows what they're talking about
to proofread their articles?

~~~
godzillabrennus
Remember this the next time you read anything in the news about an industry
you don't understand.

~~~
sundarurfriend
The Gell Mann amnesia effect - [https://seekerblog.com/2006/01/31/the-murray-
gell-mann-amnes...](https://seekerblog.com/2006/01/31/the-murray-gell-mann-
amnesia-effect/)

------
aewnjfksd
Hah! Surely a memory-safe language cannot have security vulnerabilities. /s

I find it telling that in this case it was NOT a C program being responsible
for the hack, even though the affected machine was likely running many orders
of magnitude more C than Java code.

I've always said it and I will repeat it here again; higher level languages
fail in ways that are much more surprising, complicated and hidden than your
typical "insecure" C program.

------
IronWolve
Humm, just got an apache struts security update from Redhat, and confluence
doesn't have an update for it. Interesting...

~~~
spydum
I believe the more recent vulnerability doesn't apply to the atlassian tools
(I'd love to know if I was mislead). My understanding was the latest struts
vuln requires you to be using a specific REST plugin.

------
campuscodi
On what proof?

------
unquietcode
TIL people are still using Struts in their crazy old enterprise applications.
Jesus...

------
lngnmn
Wrong emphasis. It must be read "flaw in open source _Java_ software.

The problem is Java, not Open Source.

~~~
ajarmst
I'd leave it out of the title altogether as irrelevant. The fact that Struts
is distributed with a particular license is no more important in this case
than the fact that the foundation that distributes it is incorporated in
Delaware.

