"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."
There is now a correction at the beginning of the article:
> 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.
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.
I despise the existence of the credit reporting bureaus and would love to see one of them caught with their pants down for a breach that was entirely preventable (well, at least through the vector that was used). If they failed to patch a known vulnerability, and that caused the breach, likely they'll be on the hook for a larger payout once settlement time comes.
This is exactly what I meant. These companies compile large amounts of personal financial data without peoples consent. They use SSNs for non-tac purposes, which I think is/was illegal. This ultimate cause of the breach has nothing to do with the exploit used, but rather the fact that this company and its practices exist at all. They put peoples info on a computer connected to the internet for no reason other than efficiency - profit.
If it was not a zero-day, it means the attack was preventable, which points away from a world where a hundred million people's private information is unavoidably vulnerable.
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.
If it was not a zero-day, it means the attack was preventable, which points away from a world where a hundred million people's private information is unavoidably vulnerable.
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.
Let's not confuse physical access to getting it over the internet.
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.
The network isn't necessarily the target. Developer machines are prime candidates for pivots. Most devs don't bother installing security updates, and many laptops are badly configured or running tools like Jenkins which in certain cases gets you remote code access. Equally promising is to set up a honeypot wifi AP and then wait for someone to accidentally connect to it.
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.
Yeah, I know and I agree. That's where the "very small amount of evidence" comes into play. A slightly better point is how this acts as evidence for how unavoidably vulnerable we are.
Unfortunately ~nobody does. The effectiveness of red teams was one of the most surprising aspects of working in security. The most common way to break into someplace was to pose as a construction worker: http://i.imgur.com/ZjnGmZ5.png
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.
>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. ...
So, every time, he took a pic in the exec's chair, stole a file from the server room, and also did whatever he wanted? What is the 'N' factor here, because it sounds like your friend is a bold high schooler who achieved N=1,2,3(tops). Pretty boring security stuff.
To clarify, the companies he penetrated were the ones that hired him in the first place. Red teaming is when a company hires you to perform physical pentesting. You're legally allowed to break into their company within a set of defined rules. Usually the rules are straightforward: no breaking stuff (though sometimes there are exceptions), achieve the objective, carry a "get out of jail" envelope with two emergency contacts from inside the target company who will verify they paid you to break in if anything goes wrong. Other than that, you're free to be as creative as you want in achieving whatever the customer asked for. Think Ocean's Eleven.
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.
I mean GP that you're replying to literally said N~=dozens, meaning probably 25+
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).
The fact that the pii existed is more systemic. We use social security numbers to verify identity and have a unique way of identify people across systems. If our current system of doing this (i.e. SSNs) are no longer reliable we will have to come up with something to replace it. If what we use to replace it is as brittle of a solution we will run into a similar problem down the road.
well ya thats the point, credit card breaches may still happen but those are easy to cancel, but all the PII would be permanently in the public domain.
No, they'll still be at fault because if you have a massive pile of highly sensitive data online, and all it takes is one vulnerability to get at it all, then your security model was awful.
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.
There's no evidence so far (that I've seen) that points to Equifax storing SSNs in plaintext. The initial reports so far indicate that the exploit scraped the SSNs while it was in use by other systems, and not at rest in a database. Encryption (whether they do it or not) wouldn't have saved the day here.
> 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.
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.
I find their behaviour overall rather abhorrent and against people in general. Justice should be served, but I hope it goes very poorly for them. Sorta like one might hope something bad happens to Oracle.
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."
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.
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.
Ah. Yes, I suppose. As it is easier to find exploits in service of closing them as well as in using them (security researchers seem to mostly come down on the side that this averages out as more secure). If that's what you meant, I apologise for the misinterpretation. This particular article doesn't make that point, though, so I remain with the feeling that mentioning the license model in the title is irrelevant and a bit misleading.
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?"
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
I would guess that you have any sort of credit history or digital financial trail, companies are sending it to Equifax. Could be something as simple as a cell phone service.
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?
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".
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.
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.
I am not sure about this exploit but what can be done is you can send a Class type over the wire.
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.
(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.
If that's the plugin that was affected, then I think the author did nothing wrong. What would be the point to explain what REST - as a concept - is, in a non technical article.
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.
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.
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.
"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."