[Dailydave] Equitablefax

Fri Sep 29 16:15:27 UTC 2017

Thank you for this timeline because honestly I haven't been paying that 
close attention.

Based on this it looks like Equifax did actually patch, just not fast 
enough, and by the time they got around to it the bad guys where already 
inside. Based on this list the delta from patch release to install was 
<91 days. Am I reading this correctly?

If so then the absolute shit ton of criticism heaped on Equifax for not 
patching is IMO unwarranted. While a 91 day patch cycle for a huge 
enterprise isn't great it's a hell of a lot better than most other orgs.

Granted your points about bad network design and inability to detect a 
breach are well made but based on this list the communities criticism on 
Equifax's inability to patch is inappropriate.

- SR

the grugq wrote:
> I’m not going to address any of the points in the excellent post by Katie but rather put some facts together in a timeline so people can see the Equihax event better. The “if only bug bounty” claptrap is, as Katie points out (much more politely), complete bullshit.
>
>
> Timeline of events:
>
>
> 2017-03-06: Apache announces struts bug
> 2017-03-07: PoC exploit released to public
>
> 2017-03-10: Equihax compromised via struts exploit. Genius hackers use super elite hacker command “whoami” during their sophisticated hacking session. [0]
>
> 2017-03-13: Equihax genius elite hackers install 30 webshells to allow traversing all the different compromised hosts to pass data out of the company
>
> 2017-04-xx: Oracle releases quarterly bundle of patches, including the Struts patch. (They actually crow about this while blasting Equihax for being slow to apply the patch) [1]
>
> 2017-06-30: Equihax patches their struts installs, no longer vulnerable to the struts exploit. They patch the boxes that got popped and almost certainly had webshells installed but notice nothing. [2]
>
> 2017-07-29: Equihax discovers they have been compromised by super elite awesome hackers using one webshell for every day of the month (spares in Feb.)
> 2017-07-30: Equihax evicts the elite hackers and their 30 webshells from their systems
>
> 2017-08-01: Equihax CFO sells $1mm stock, US President of Information sells $600k stock, President of Workforce Solutions sells $250k stock [3]
>
> 2017-09-05: FireEye registers the Equihax domain name as part of a broader PR damage control move, which Equihax will do everything it can to sabotage
>
> 2017-09-07: Equihax mentions that maybe there might have been some sort of hack or something but definitely not a big deal unless you're an American adult with a credit record.
>
> 2017-09-08: Equihax offers an opportunity to sign away your right to sue Equihax in exchange for waiting a week and getting yet another year of free credit reporting. (If you don’t already have 3-5 years of free credit reporting by now, are you even using the Internet??) [4]
>
> 2017-09-11: FireEye (owner of Mandiant, who did the IR + PR for Equihax) quietly pulls the case study white paper about how FireEye 0day protection technology is keeping Equihax safe from unknown threats and "up to 29 webshells”
>
>
> What this looks like to me is a bunch of web app hackers who used a fresh PoC exploit to mass hack everything they could find. Then, while going through their hacked logs, they discover they have an interesting victim. They turn their attention to it and start working on getting deeper into the environment (this is around the 13th, so a couple days after they popped a shell). I’m guessing that what happened was they went on a bit of a rampage inside the DMZ area popping all the shells they could. Then assembled some Rube Goldberg webshell machine to exfil data from the various databases, including, apparently, legacy databases.
>
> I’m calling this mostly a problem with Equihax architecture. This isn’t about a struts bug, this is about a terrible network design that allows random kiddies to scrape the data store clean via a single shell (well, 30, but still). That Equihax was focussing on buying boxes to protect against 0day, and (from stories I’ve read circa 2015) working on ensuring employee phones are compartmented for BYOD. Well, they were clearly spending money out of the security budget. And it wasn’t trivial sums either, FireEye boxes aren’t exactly free. But from the looks of it, the problem wasn’t that they got compromised, the problem was that they couldn’t detect a compromise and prevent it from becoming a breach (seriously: 30 webshells exfiltrating data on 143 million people would have left some pretty hefty “access.log” files).
>
> This is not a “bug” issue, it is an architecture issue. You know, if they threw a canary.io tool into that DMZ and configured it to look like a database, they’d have known about the hack during that first week. If they monitored their logs for unusual activity, such as the installation of 30 webshells, and gigabytes of data going the wrong way. If they had an architecture that prevented a compromise of a web server enabling access to sensitive company data. If they had asset management and decommissioned legacy databases, rather than leaving them in the DMZ.
>
> There are a lot of things here which would have prevented this compromise from becoming a disastrous breach, but spending money on a bug bounty program or FireEye silver bullet boxes, or mobile device management systems — none of those would, or did, help.
>
>
> The important things are always simple. The simple things are always hard. The easy way is always mined.
>        — Murphy’s Laws of Enterprise Information Security.
>
>
> —gq
>
> [0]: https://arstechnica.com/information-technology/2017/09/massive-equifax-hack-reportedly-started-4-months-before-it-was-detected/
> [1]: https://threatpost.com/oracle-patches-apache-struts-reminds-users-to-update-equifax-bug/128151/
> [2]: a cron job running `find` for new files, AIDE (or Tripwire), would trivially notice the modifications to the file system and alert.
> [3]: https://www.bloomberg.com/news/articles/2017-09-07/three-equifax-executives-sold-stock-before-revealing-cyber-hack
> [4]: https://www.cnbc.com/2017/09/08/were-you-affected-by-the-equifax-data-breach-one-click-could-cost-you-your-rights-in-court.html
>
>
>
>> On 28 Sep 2017, at 02:38, Katie M<k8ek8e at gmail.com>  wrote:
>>
>> Having a bug bounty program wouldn't have helped Equifax. Only Equifax could have helped Equifax. The root cause of the problem wasn't that they didn't know about the bug, it was that they face the same patch prioritization risk vs resource balance that all orgs gamble with. They lost that gamble, which is what every breach represents: a lost bet on the tradeoffs. Simply knowing about a bug, via a bug bounty or otherwise, is just that. And knowing is at best half the battle.
>>
>> But to return to Dave's assertion about the bug bounty ecosystem itself and what it currently is good for and what it's used for - I have many thoughts. And even more songs.
>>
>> "In a sense, the entire bug bounty market is a breeding ground for a species that can collect extremely low impact web vulnerabilities into a life sustaining nutrient cycle, like the crabs on volcanic plumes in the depths of the Pacific."
>>
>> https://en.m.wikipedia.org/wiki/Mariana_Trench
>>
>> Agreed that the bug bounty market has evolved in this *particular stage of it's growth* through its own complex system, the dynamics of which are heavily influenced by factors like:
>>
>> 1. the types of organizations who have been adopting these incentives so far (mostly tech companies),
>> 2. the typical targets (mostly web sites), and
>> 3. the types of vulnerabilities they tend to use bug bounties to find (mostly low hanging fruit that could have been found using common free tools&  techniques).
>>
>> Also a factor in this ecosystem is the geolocation and socioeconomic status of the script kiddie bug hunting masses, who, unlike the early professional penetration testers like us, don't have to adapt their techniques to find more interesting, higher quality bugs to continue to be paid relatively small amounts that are worth much more to them in their part of the world.
>>
>> That's good for those bug hunters who are in this category. That's actually bad for the evolution of the bug bounty ecosystem, and is accurate in Dave's characterization of what's happening *right now*.
>>
>> The upside effect though is that the bug hunter masses can now access a safe marketplace for their skills regardless of those facts of where they are and whether they could ever become a "security consultant". That's generally good, but the *dominant* "species" of bug hunter, as Dave accurately points out about them now will remain relatively unskilled if we don't act with higher-order outcomes in mind.
>>
>> It will be like an attempt at brewing beer that gets taken over and soured by undesirable flora before the brewers yeast kicks in and creates the desired effect. And I've been brewing the defensive market for vulnerabilities far too long to watch idly and let the batch sour.
>>
>> We ideally want to create an upward trend in bug hunter population skills, as well as move the bug hunter targets themselves, towards more sophisticated bugs. We are not raising the tide, and we are not causing all ships to rise with it. Just by slapping a bug bounty or vuln disclosure program on something, we are missing the point.
>>
>> One of the papers that we produced out of the MIT Sloan School visiting scholar systems modeling I worked on will come out sometime this fall (2017) as a chapter in an MIT Press book. That paper looks specifically at bug bounty participant data at a specific point in the development of this economy. Bet you're curious about that supply side snapshot of the bug bounty Mariana Trench. :) Look for that book with our research paper when it's out.
>>
>> Bug bounties as they have mostly manifested *right now, at this specific stage in that ecosystem's development,* are a cheap, shiny thing to do, with few exceptions.
>>
>> And no, the exceptional bug bounties are not the ones that pay the most more on that later. The presence of a bug bounty program is being currently used by organizations to virtue signal that they take security seriously by paying for web bugs, but often missing or ignoring aggregate threats, and ignoring their internal failing processes to fix bugs.
>>
>> It matters very much what's on the inside, versus the superficial, shiny, bug bounty exterior.
>>
>> Shiny (but still very insecure):
>>
>> https://www.youtube.com/watch?v=93lrosBEW-Q
>>
>> The alliterative buzz word "bug bounty", deceptively simple and so very misunderstood, needs to evolve as an accepted concept into the more accurate, more strategic "incentives".
>>
>> Straight cash as the only lever for bringing all the (good) bugs to the yard is short-sighted&  pollutes the entire defensive reward ocean in this evolution of the vulnerability and exploit markets. Cash is only one lever in this system, and it isn't the most effective one if you're buying bugs for defense purposes, as I've been saying for several years.
>>
>> Perhaps if a strapping demigod of security would just repeat this for me, it would replace the econ 101 BS that has plagued the emerging bug bounty market. Of course, I'm sure they'd happily forget where they heard it first.
>>
>> https://www.youtube.com/watch?v=79DijItQXMM
>>
>> Just kidding, I'll speak for myself, as always:
>>
>> https://www.rsaconference.com/writable/presentations/file_upload/ht-t08-the-wolves-of-vuln-street-the-1st-dynamic-systems-model-of-the-0day-market_final.pdf
>>
>> Better-than-a-bug-bounty incentives that are much more effective for improving defense may not be direct cash, may not be rewards at all. Instead they might be a much harder deep introspective process, to examine what drives the heart of an organization, what they are doing to defend what's important to them, and whether the security choices, tradeoffs, resources, and budgets are actually working for them. What incentives can they use to tease out real risk, rather than being lazy and trendy and calling it a success.
>>
>> No, a bug bounty would not have helped Equifax prevent what happened, and we need to seriously stop the VC-backed tsunami of propaganda that says that it would. That stupid marketing trick employed by at least one of the bug bounty platform vendors should be beneath the critically-thinking readers of this list to entertain in terms of its obvious oversimplicity of a non-trivial problem.
>>
>> I'm not even going to address the cyber insurance idea on this, and by now in this long operetta of a post, it should be obvious as to why.
>>
>> Bug bounties and cyber insurance are not a remedy for a fundamentally unscalable remediation model that most orgs and governments face today. That's precisely why 94% of the Forbes Global 2000 in 2015 didn't even have a front door to report a vulnerability, let alone a bug bounty, and it's not much better now.
>>
>> They struggle to fix the bugs they already know about, and the bottlenecks in that *internal* process are what need work. Putting up a front door to receive bug reports, even without a bug bounty, when there's nothing operationally sufficient inside that org to address what comes through the door, is not the chaos an org needs in the midst of drowning in technical debt.
>>
>> It's time to return the heart of the bug bounty ocean to stop the spread of this intellectual and ecosystem-poisoning darkness. I've been staring at the edge of the water, long as I can remember...
>>
>> https://www.youtube.com/watch?v=GeIHvhnQbbI
>>
>> - k8eM0ana
>>
>> https://www.youtube.com/watch?v=Lg_cweoJXyo
>>
>>
>> 🏝️👩‍💻🐞🌋🌺 @k8em0 @lutasecurity @k8eM0ana 🏝️👩‍💻🐞🌋🌺
>>
>>
>>
>> On Wed, Sep 27, 2017 at 9:30 AM, Kristian Erik Hermansen<kristian.hermansen at gmail.com>  wrote:
>> If Equifax had a public bug bounty program, someone would have reported the Java RCE in March 2017 and picked up $10K or more for it. But no, Equifax did not have a public bug bounty program. Say what you will about the pros and cons of a bug bounty program, especially for financial institutions which "know better than the public how to protect themselves", but at least in this case a known issue would have been well documented much earlier. We should encourage other credit and financial companies to consider public or at the very least private bug bounty programs. It's a mess to operate them, but not patching a known critical web flaw ASAP that allows RCE is precisely the legal definition of negligence. Equifax should pay dearly for it.
>>
>> Perhaps it's time to consider federal Cyber Security Insurance laws for such companies which forces them to pay fees to operate on the Internet just like everyone that drives a car on the road? If you crash your car every time you get on the highway, or you damaged 140 million cars while driving, you would lose your license for some time. Why hasn't Equifax lost their license to operate on the internet for some time? How about a 2 year hiatus on their annual revenue to punish them? Just a thought. Maybe Halvar can chime in on why Cyber Security Insurance regulation like that is OR is not the answer. He has been working on that lately...
>>
>> _______________________________________________
>> Dailydave mailing list
>> Dailydave at lists.immunityinc.com
>> https://lists.immunityinc.com/mailman/listinfo/dailydave
>>
>>
>> _______________________________________________
>> Dailydave mailing list
>> Dailydave at lists.immunityinc.com
>> https://lists.immunityinc.com/mailman/listinfo/dailydave
>
> _______________________________________________
> Dailydave mailing list
> Dailydave at lists.immunityinc.com
> https://lists.immunityinc.com/mailman/listinfo/dailydave