[BreachExchange] Equifax Breach: Updated Timeline, Phishing, Regulation, and a Roundup

[Inga Goddijn]

https://www.riskbasedsecurity.com/2017/09/equifax-breach-updated-timeline-phishing-regulation-and-a-roundup/

This is the eighth blog in the running series on the Equifax data breach.

Equif*@#$d: Equifax Breach Response Off To A Rough Start
Equifax Breach: Legal, Vulnerability Blame Game, and the Big Technical
Debacle
Equifax Breach: EULAs, Size Doesn’t Matter, and Where’s The Data?
Equifax Breach: The Bigger Picture, Identity, Impact, and Advice
Equifax Breach: Ambulance Chasing, FireEye, and a News Roundup
Equifax Breach: Timeline, International, Patching, Gender, PCI, oh my!
Equifax Breach: Cyber Insurance To The Rescue?!
Equifax Breach: Updated Timeline, Phishing, Regulation, and a Roundup

________________________________

There continues to be fallout after the Equifax breach reported on
September 7th. Here are some of the highlights and focused topics.

Running Timeline (Updated)

As the events continue to unfold, people are taking an increased interest
in the amount of days that passed between two events, such as the days
between when the vulnerability exploited by attackers was disclosed and the
date the weakness was fixed. Known as the “time to patch”, this metric
centers around how long it takes for the organization to determine, at
least in their minds, the company was diligent in addressing the
vulnerability. To help everyone with this, we’ll be maintaining a running
timeline of the events with references. This is our first update to the
timeline with additional dates and events.

2017-02-14 – Apache notified of the vulnerability (ref: email between RBS /
Apache)
2017-02-18 – Apache assigns a CVE ID (ref: email between RBS / Apache)
2017-03-06 – Apache announced and released upgrade to resolve vulnerability
(ref)
2017-03-07 – Vulnerability published in VulnDB (ref)
2017-03-07 – Exploit published (ref)
2017-03-10 – MITRE opens up CVE ID with description and 7 references (ref)
2017-03-10 – NVD adds to their database via CVE. No updates since (ref)
2017-03-10 – Alleged Equifax breach occurred according to recent reporting
(ref)
2017-03-14 – CERT releases advisory on vulnerability (ref)
2017-03-14 – Equifax says they are aware of the vulnerability (ref)
2017-05-13 – Equifax breach occurred, per statement from the company (ref)
2017-07-29 – Equifax detected breach (ref)
2017-07-30 – Equifax patched the vulnerability (ref)
2017-08-01 – Equifax CFO and President of US Information Solutions sold
stock shares (ref)
2017-08-02 – Equifax President of Workforce Solutions sold stock shares
(ref)
2017-08-02 – Equifax contacted Mandiant to help with incident response (ref)
2017-08-10 – Equifax acquires ID Watchdog, an identity theft protection
service provider (ref)
2017-09-07 – Equifax notified public of breach (ref)
2017-09-07 – First class-action lawsuit filed against Equifax (ref)
2017-09-15 – Equifax CSO & CIO ‘retire’ (ref)
2017-09-19 – Massachusetts AG files lawsuit against Equifax (ref)
2017-09-20 – Equifax names interim CSO & CIO (ref)

Equifax Specific Metrics

Equifax time to patch: 138 Days
Equifax time to notice compromise: 78 Days
Equifax time to notify public: 117 Days

Apache Struts Software Vulnerability Metrics

As more information become available about the Struts vulnerability we also
continue to track detailed timelines in our VulnDB service. Risk Based
Security created a framework called Vulnerability Timeline and Exposure
Metrics (VTEM) that defines and provides guidance for vulnerability
timeline tracking and metric calculations to assist in the evaluation of
vendors and products to better understand an organization’s exposure.

We know that that ‘Struts-Shock’ vulnerability had the following key
metrics:

Vendor Response Time – To demonstrate the vendor’s response time from being
informed about an issue to responding to a researcher. This is only the
initial response, but not an automated response.

Unknown (Apache did not include that in the timeline they sent us.)

Time to Patch – To demonstrate the vendors response time from being
informed of a vulnerability until to having a working fix published for
customers.

20 days

Time to Exploit – To demonstrate the amount of time from when vendor
provided the solution until an exploit became publicly available.

1 day

Overall, we have tracked a total of 75 vulnerabilities in Apache Struts,
with eight vulnerabilities not having a CVE ID assignment.


We looked at the overall VTEM Metrics for Struts and wanted to call
attention to two specific metrics. The first is Vendor Response Time; while
we don’t have the dates to calculate it for the Struts-Shock vulnerability,
we can see that the Apache Foundation on the whole is very responsive to
researchers that contact them. While the sample size is low, only seven
vulnerabilities out of the 75 can we calculate a metric, we see that on
average it takes them just one day to respond. That is great to see! We can
also see that the Struts-Shock was fixed much quicker (20 days) than it
typically takes since their average is 92 days.

Equifax Breach Earlier Than Initially Stated?

The Wall Street Journal published an article based on a leaked preliminary
report by Mandiant, who was brought in to determine the scope and method of
the Equifax breach. The report, summarized in the article, alleges several
new aspects of the breach that are interesting:

Mandiant says the first evidence of hacker “interaction” occurred on March
10th, considerably earlier than May 29thas Equifax originally stated.
Between May 13th and late July, the intruders accessed sensitive
information “stored in databases in an Equifax legacy environment”.
The intruders also compromised two systems that support Equifax’s online
dispute application.
The attackers set up “about 30 web shells” (a method of keeping persistent
access to a compromised host) that were accessed from around 35 “distinct
public IP addresses”.
According to Mandiant, the attackers methods and tools do not match any
“threat actor group” it tracks, and does not “overlap with those seen in
previous investigations by the firm”.

It is difficult to say why there is such a large discrepancy between
compromise dates given by Equifax and Mandiant. One possibility is that
Equifax’s internal teams found evidence going back to May 29th, while
Mandiant’s team who has more experience investigating breaches found
evidence going back to March 10th. Another possibility is that the first
intrusion into the system took place in March but the data itself was not
compromised until May, prompting Equifax to report the date of data
compromise instead of the first occurrence date. Regardless, with this type
of compromise and presence of that many web shell backdoors, it is making
more people wonder exactly what FireEye’s security products were supposed
to protect them from if not 0-day vulnerabilities (Struts-Shock) and the
web shells.

Perhaps the most confusing part of this recent development is Equifax’s
lack of clarity around the March event. They have been adamant in claiming
that these were two separate breaches. Indeed, an Equifax subsidiary,
Equifax Workforce Solutions also known as TALX, was breached earlier this
year in March. The attackers were able to guess at – and reset – account
administrators PINs, and by doing so gain access to W2 details on thousands
of individuals. If in fact this is the March event Equifax is referring to,
then there is reason to believe it is unrelated to the May intrusion.

However, According to Bloomberg, Equifax said the “March breach was not
related to the hack that exposed the personal and financial data on 143
million U.S. consumers, but one of the people said the breaches involve the
same intruders.” This statement simply does not make sense. Looking back at
the timeline, they confirmed the method of compromise and the dates show
that a single attacking group/person could have kept access and
consistently gained access to more servers and information. If the March
intrusion is not the TALX event, then nothing published so far explains how
this would be “two separate breaches” and why that claim is justified if
the same actor(s) were involved the entire time.

Equifax Recommends Phishing Site to Victims

On the day Equifax announced the breach, they set up a website (
equifaxsecurity2017.com) to help inform customers of what happened and
provide resources. As we mentioned in a previous blog, it is a given that
criminals would set up similar domains to carry out phishing attacks and
other scams (here’s a handy list). What no one expected is that Equifax,
via its Twitter account, started directing people to one of the bogus sites
(securityequifax2017.com). Fortunately for Equifax, that particular scam
site was set up by security researcher Nick Sweeting to help prove the
point of using such websites after a breach. Even worse, Equifax has been
directing people to the bogus site since September 11th and just removed
those Tweets on the 19th. ArsTechnica wrote more about this dreadful
mistake, as did CNN.

Bob McMillan points out that the actual domain Equifax set up is hard to
find. If you Google for a common term that an ordinary person might search
for, that site doesn’t appear on the first page. Even as Equifax learns
their lessons with the Tweets, they are still sending out emails with
multiple domains which “continues to train people to fall for phishing
scams” according to Brian Krebs.

Data for Sale Again? Tracking the Alleged Criminals.

The first claim from criminals purporting to sell stolen Equifax data
turned out to be false. In recent days, a second claim has appeared on the
Dark Web (equihxbdrjn5czx2.onion). Like the first, someone claims to have
the Equifax data and will crowdsource the money they want to publicly
release the data. Security researcher ‘Krypt3ia’ posted about this
development along with his doubts (note: that link is safe despite Chrome’s
warning). Steve Ragan also expressed his doubts, saying the sample data had
been previously released, suggesting it came from a prior breach.

Someone who goes by ‘AKM’, or @037 on Twitter, posted a blog titled “How
Equifax got Hacked” which claims to give further information about the
hack, supports the new claim of Equifax data being sold, and offers a
variety of screenshots as evidence. This blog is based on their
conversation with the alleged hackers, where AKM was able to ask questions
and share the answers. However, Brian Krebs points out that the screenshots
mentioned are likely from an Equifax partner, not Equifax itself. Zack
Whittaker posted a thread on Twitter reminding everyone of accepting such
claims without verification and more digging.

Is Government Regulation the Answer?

After a large computer breach a question that comes up with increasing
frequency is that of government regulation. If companies operated under
security regulations set forth by the government, would this prevent
breaches? Security blogger Bruce Schneier wrote on this topic, concluding
“if you want to prevent this kind of thing from happening again, your only
solution is government regulation”. Over the entire blog however, he
doesn’t offer any compelling argument supporting this statement other than
the age-old “raise the cost” through fines. As mentioned in a previous blog
of ours, the General Data Protection Regulation (GDPR) shows promise to put
a financial burden on companies that may change their tolerance of
breaches. With that going into effect in 2018, the talk of government
regulation is a no-brainer, more so than the last decade it has been
brought up.

More interesting is that Anna Slomovic, the Equifax Chief Privacy Officer
(CPO) for three years until January, 2014, agrees. In a blog post, she says
“given the nature of credit reporting, only action by the Congress and
diligent regulatory oversight will lead to a better balance for consumers
in the long term.” This statement is more telling coming from an Equifax
insider who had to face the fallout of their security practices for three
years. Even the National Retail Federation says that a uniform data breach
law must be enacted; while that would certainly be helpful, that only helps
after a breach has happened as conforming to a unified law is considerably
easier than adhering to more than 50 separate state laws. But note, in
2017, the U.S. government hasn’t even standardized breach notification, let
alone put forth more strict regulations.

That said, it is difficult for some of us at RBS to really understand this
logic in the bigger picture. First, the security and payment card industry
has tried to self-regulate via the Payment Card Industry Data Security
Standard (PCI-DSS)standards which mandate a certain level of security.
While many in the industry feel it is essentially the “no child left
behind” of security standards, it is exactly the kind of regulations the
U.S. government might put forth.

Second, the industry is already drowning in security regulations, many put
forth by the U.S. government. In addition to PCI-DSS, depending on your
business and industry, you may fall under the Health Insurance Portability
and Accountability Act (HIPAA), Sarbanes Oxley Act (SOX), Federal
Information Security Management Act of 2002 (FISMA), Electronic Fund
Transfer Act Regulation E (EFTA), the Health Information Technology for
Economic and Clinical Health Act (HITECH), and more. Have any of these
regulations or standards, or a combination of them, truly made an
organization safe? With so much government regulation already in place, it
is difficult to understand how generic statements of “we need government
regulation” have any merit without proposing something more specific.

Third, and finally, how has government regulation worked for other
industries? Specifically, think about big banks and Wall Street that
routinely breaks laws or regulations, as the fines and ‘punishment’ they
face are part of their bottom line and expected. Think about the energy
industry and the massive oil spills that still do irrevocable harm to our
environment and the ‘punishment’ they receive. Years after these companies
flagrantly break rules and regulations, and sometimes the law, we see
summaries like this; “None of the charges against individuals resulted in
any prison time, and no charges were levied against upper level executives.”

With the credit bureaus having incredible financial resources, does anyone
think that they don’t already have an incredible lobby? We’ve previously
covered Equifax spending upwards of $500,000 in a year lobbying Congress to
change the law in their favor. If more regulations appear that would impact
them, we can also expect to see them increase their lobbying budget. So, do
we feel that government regulation would have prevented the Equifax breach,
or most other breaches? Do we think that such regulation, if enacted, would
stop breaches from happening?

Update Roundup

As in previous updates, we’d like to share some of the other bits and new
developments in a more succinct manner:

The New York Times published a piece saying that the Equifax hack will
“lead to little, if any, punishment”. Based on historical incidents, it’s
hard to argue this.
Brian Krebs points out that Equifax still appears to be in the dark ages
regarding user web browser requirements when visiting their site. They may
want to consider that no modern user runs Netscape.
Maura Healey, Massachusetts Attorney General, filed a lawsuit against
Equifax for failing to “develop, implement, or maintain a [comprehensive
information security program] that met the minimum requirements of the
state’s Data Security Regulations”.
After the Equifax CSO and CIO “retired” following the breach, the company
has named an interim CIO (Mark Rohrwasser) and CSO (Russ Ayres). Following
the now ‘retired’ CSO and CIO, Equifax’s CEO, Richard Smith, has also
announced he is ‘retiring’ which some call an ‘appeasement’ for regulators.
In the running theme of Equifax having poor security, researchers have
pointed out that their servers have a variety of problems related to
security headers. Additionally, their credit report monitoring website is
also said to be vulnerable to hacking.
In the irony department, The Reg dug up material produced by Equifax
showing that a survey they conducted revealed 74% asked thinks that a
breach notification should come within hours or the same day.
For those impacted by the breach, many are reporting problems while trying
to set up credit freezes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riskbasedsecurity.com/pipermail/breachexchange/attachments/20170928/7f1f6bd4/attachment.html>