Hackers who broke into Equifax exploited a flaw in open-source server software
qz.com
qz.com
"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."
> Correction: An earlier version of this article said the vulnerability exploited by the hackers who broke into Equifax was the one disclosed on Sep. 4. It’s possible that the vulnerability that was targeted was one disclosed in March. We will update this post when we’ve confirmed which vulnerability it was.
Given the magnitude of this hack, it is entirely possible they embargoed it for a while.
[1] https://baird.bluematrix.com/docs/pdf/dbf801ef-f20e-4d6f-91c...
If it was a zero-day then they legitimately may not be at fault.
In either case, it's a very small amount of evidence anyway, but in that respect at least, hoping it wasn't a zero-day makes sense.
Working in the security industry quickly cures you of this illusion. It is unavoidably vulnerable in most cases. If someone wants to pop your network, they can usually find a way. The most clever code won't prevent someone from strolling in and plugging a raspi onto your network. Nobody notices an inconspicuous black box amid a pile of cables.
If they stayed old-school and had their computers inaccessible except to their own people, you'd have to make phone calls, fax, and mail to do anything with them. That would be less efficient - more costly - but it would prevent the possibility of a remote attack compromising huge amounts of data.
If we move up in abstraction, if these companies didn't exist and collect all the data the danger would be completely eliminated. OTOH the banks and lenders who use their services would have to find other ways to estimate credit-worthiness and that would again... cost more.
Most devs have creds littered throughout their system. Some subset of the creds will get me access to your network. If you let me rifle through your box for a few hours I'd likely find a way to pivot somewhere else.
If you're dressed as one of them, you can go wherever you want and people rarely ask questions. Another approach is to pose as an interviewee. That's how you get into the building, but beyond that you never actually talk to anyone so nobody is suspicious. People generally don't care when someone is walking around the halls dressed up in a suit.
One of my coworkers was involved in dozens of red teams and he got caught a grand total of one time. Every other time he was able to acquire an IP address, take a picture of himself sitting in the exec's chair, swipe a file out of the server room, or whatever the customer wanted.
Particularly if they behave accordingly.
A classic (just to show that there is nothing new under the sun):
https://en.wikisource.org/wiki/The_Innocence_of_Father_Brown...
>If you meet a member of that select club, "The Twelve True Fishermen," entering the Vernon Hotel for the annual club dinner, you will observe, as he takes off his overcoat, that his evening coat is green and not black. If (supposing that you have the star-defying audacity to address such a being) you ask him why, he will probably answer that he does it to avoid being mistaken for a waiter. You will then retire crushed. But you will leave behind you a mystery as yet unsolved and a tale worth telling. ...
These gigs are highly paid and secretive. The coworker I mentioned went on dozens of assignments like this. Admittedly he was legendary, but only because he was so experienced. If you were motivated and malicious, you could do many of the same things to attack a target network. People rarely do that, but it's the ultimate proof that none of us are secure against motivated adversaries.
Side note, that sounds like something one of my old bosses would do on his red team excursions (he also told me to get my teeth pulled without anesthetics at all, so... yea).
Regardless of this specific situation, we already live in this world. We all just need to get used to it.
Like, some random website: "we just got hacked, all you pii was taken, but don't worry nothing thats not already available in that public database"
other than new credit card #'s it'd be basically pointless right?
Everybody on that list will change their CC and life carries on until the next breach.
Was this database typically accessed with broad-sweeping queries that could snarf large amounts of it at once, or was it the sort of thing where a few specific keys were used to identify a single client record? My thinking is that it was probably the latter, and if that's the case then another layer of security should have been in place there. Stored procedures can be used to require very specific queries to access very specific records--this falls under the "prevention" category. Next, monitors should be deployed so that someone gets notified right away if some session makes a large number of successive queries to get around the restriction--this goes under the heading of "detection". These two things would have been able to prevent attackers getting the goods with just one exploit.
...yet companies regularly fail to take these kinds of simple and rational steps seriously, and then act like it was all just too hard for anyone to possibly defend against.
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.
> 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.
I completely agree.
BCrypt with lots of rounds would be best.
The problems all come from using it for authentication.
With this disclosure, much of what banks and others use to authenticate my identity is now out in the open.
Licensing model directly affects the availability of source code, and this technically facilitates exploit discovery.
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.
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 (Apache Struts Jakarta Multipart Parser file upload vulnerability for RCE)
Why was such sensitive data "retained" at the edge?
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?
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".
This is the same as reading a file in, getting data though a http call, through user input...
Of course you must marshall what you get before using it further - but that does not depend on the source once it is not secure /trusted
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.
[0] https://github.com/mazen160/struts-pwn_CVE-2017-9805/blob/ma...
It contains Java bytecode and when de-serialized it will use some ClassLoader to construct the Class instance. While doing that the static intializer of that class will be executed.
This probably is not what is going on here but is a possibility.
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.
Why cant tech 'journalists' get someone who knows what they're talking about to proofread their articles?
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.
The problem is Java, not Open Source.
Nothing about Java or it's community makes it any more prone than most other languages to exposing deserialisation into arbitrary objects.
[0] https://github.com/mazen160/struts-pwn_CVE-2017-9805/blob/ma... [1] https://blog.nelhage.com/2011/03/exploiting-pickle/