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<[email protected]> 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<[email protected]> 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
[email protected]
https://lists.immunityinc.com/mailman/listinfo/dailydave
_______________________________________________
Dailydave mailing list
[email protected]
https://lists.immunityinc.com/mailman/listinfo/dailydave
_______________________________________________
Dailydave mailing list
[email protected]
https://lists.immunityinc.com/mailman/listinfo/dailydave
