Capital One Data Breach Spurs More Lawsuits

phenomlab

Looks as though GitHub are in the firing line for failing to take down a dump of data from the Capital One breach

More lawsuits have been filed in the wake of the Capital One breach that exposed the data of more than 100 million individuals. GitHub is also a target of one of those lawsuits, which alleges the code-sharing site failed to promptly remove breached data.

A Vancouver-based law firm filed a class action lawsuit against Capital One on Friday on behalf of affected customers who live in Canada. A case filed in a federal court in California Thursday looks to hold both Capital One and GitHub responsible for exposing customer data.

When the FBI arrested Page A. Thompson, 33, on July 29 and charged her with hacking into Capital One and allegedly exposing the customer data, court papers related to the case indicated that she posted some information about the intrusion on GitHub (see: Woman Arrested in Massive Capital One Data Breach).

“As a result of GitHub’s failure to monitor, remove or otherwise recognize and act upon obviously hacked data that was displayed, disclosed and used on and by GitHub and its website, the personal information sat on GitHub.com,” according to the California lawsuit. It claims that GitHub promoted hacking activities and that it violated data privacy norms, including the U.S. Federal Trade Commission Act, the federal Wiretap Act and California’s civil code.

A spokesperson for GitHub tells Information Security Media Group that it investigates suspected illegal content brought to its attention and removes it if it violates the company’s terms of service.

Source - https://www.inforisktoday.in/capital-one-data-breach-spurs-more-lawsuits-a-12873?rf=2019-08-06_ENEWS_SUB_IR__Slot1_ART12873&mkt_tok=eyJpIjoiTjJFME16Y3lOalppT0dGaCIsInQiOiJjWHpBd3NtVjM1MnFBNEpmVE5HeDVrQnVFZEFpYThTMjkrMHBmSm93bklicVVsWGFpaFFFTVBWQjlqSHFVYk9UVSszaFBhY2RkSG0xM3dXVU4xQXNWcTlMMVU4ZFgweHp2T0pFc0ZWZlpRM0NKTnBVT1BrSDJXWHZxWllCVW5IXC8ifQ%3D%3D

Dave_Howe

phenomlab going after GitHub is an overreach; they should have “common carrier” protected status provided they respond promptly to complaints, and there is no evidence they didn’t (there isn’t a duty to do other people’s work for them anywhere in law)

phenomlab

Dave_Howe Agreed - there have been similar cases with Cloudflare in the past from recollection.

Dave_Howe

phenomlab they are probably hoping the usual thing for the USA - because it can be expensive to win a meritless court case in states that don’t have anti-SLAPP laws, the owners of github will pay them to go away. Prenda Law is alive, well, and looking at github….

phenomlab

Dave_Howe And in this case, it would be meritless. If anything did come of the GitHub fracas, then sites such as PasteBin would be directly in the firing line for exactly the same thing.

Dave_Howe

phenomlab PasteBin doesn’t have microsoft’s deep pockets behind them…. Ambulance chasers look to potential payout, not merit.

phenomlab

Dave_Howe Another good point. However, most previous breaches were prompted dumped on PasteBin, so it’d be interesting to gain an idea of how their oversight and governance works. At present, it pretty much seems like the wild west.

Dave_Howe

Main problem with a github lawsuit is that it is literally impossible for github to magically know that a prospect database is stolen goods; heck, for all we know, CapOne themselves literally bought it from a company like Equifax, and have no direct IP rights in the data.

phenomlab

Interesting article this morning entitled “Capital One’s Breach May Be a Server Side Request Forgery” - synopsis below

Capital One’s enormous data breach is the subject of intense scrutiny as well as fear among companies. It’s likely months before a definitive post mortem will appear.

But enough detail has been released so far to give security professionals enough to ponder about how one of the biggest breaches possibly occurred.

The criminal complaint against Paige A. Thompson, the accused intruder, alleges she bypassed a misconfigured Capital One firewall and obtained administrative credentials for an account, which is described as “*****-WAF-ROLE.” That account had enough privileges to view and copy data behind the firewall, resulting in the breach (see: Capital One: Where Did the Bank Fail on Defense?).

That has led to theories that the intruder may have leveraged a server side request forgery, a type of web application vulnerability that security blogger Brian Krebs wrote about on Friday. Meanwhile, other security companies and experts concur an SSRF flaw is indeed a strong candidate, but one that has yet to be confirmed.

Source https://www.bankinfosecurity.com/capital-ones-breach-may-be-server-side-request-forgery-a-12871

Dave_Howe

phenomlab Yup, the modsecurity/ssrf connection has been established for a fair while now - see krebs for example

phenomlab

And this

https://www.bloomberg.com/news/videos/2019-08-02/capital-one-hack-highlights-common-cloud-vulnerability-darktrace-ceo-says-video

phenomlab

Dave_Howe Yup, the modsecurity/ssrf connection has been established for a fair while now - see krebs for example

From that same article

In AWS, exactly what those credentials can be used for hinges on the permissions assigned to the resource that is requesting them. In Capital One’s case, the misconfigured WAF for whatever reason was assigned too many permissions, i.e. it was allowed to list all of the files in any buckets of data, and to read the contents of each of those files.

This is “misconfiguration” at it’s worst - accessed by an account that has too many permissions for the job it actually needs to complete. Doesn’t anyone ever audit this stuff ??

Dave_Howe

phenomlab Short answer is, we don’t know. (longer answer is remarkably similar)

We are reading between the lines a LOT here - little is actually known, and while I am seeing a lot of reports on modsecurity, the role IAM permissions, and ssrf, I have yet to see any actual, validated sources for this.
Was modsecurity used alone (difficult to do), with a reverse proxy such as nginx (most probable configuration, particularly given some deployment models, such as kube, will spin up such a thing for ingress NLB) or was it actually a modsecurity module installed to an actual webserver?

We have no real reason to presume the FBI meant “NLB” when they said “Firewall”; they may have HEARD “WAF” and extrapolated, but WAF on a webserver is still WAF (and doesn’t break some models such as client certs that use of an inline appliance WAF would break). If the instance really WAS a webserver, then it may have been correct that it had access to buckets containing data (because it needed to serve that data, which is the point of a webserver, really)

Without knowing quite a bit more (and we don’t even know what ssrf was allegedly exploited in modsecurity) we don’t know if there was an actual misconfiguration, an architecture choice that in retrospect wasn’t the best (such as not using a separate WAF) or an undocumented bug that is going to be announced once a patch is ready….

phenomlab

Dave_Howe I’m leaning more towards inadequately secured S3 buckets myself…Not the first time.

Dave_Howe

phenomlab sure, but evidence is that they secured the buckets properly, except that a role had the appropriate IAM permissions assigned to read from it.

phenomlab

Dave_Howe The question is, were any of those buckets public ? From what I’ve read, the answer would be no - it was an inside attack.

Dave_Howe

phenomlab the current speculation (mostly, any relationship to actual facts is by assertion, of course) is that the buckets were properly secured and “private” (assertion by CapOne) but that the attacker used the amazon API and a role called “ISRM-WAF-Role” to perform a “Sync” of the contents (that is well enough documented, given the attacker actually left their attack script in the git repo).

The FBI agent assigned claimed that there was a “misconfigured firewall” (that they claimed this is a fact, that they misunderstood or were simplifying for the court the fact that a WAF instance was the source of the compromise is surmise) and the nature of the role (pretty obviously a WAF instance role, not an API account per se) calls out that the attacker accessed the meta-data endpoint (assertion, given we don’t have any proof of this) by exploiting modsecurity (again, assertion, and most assertions reference published assertions by another researcher) with a ssrf (… yeah, assertion again)

As usual, I am skeptical about assertions without a credible source, and this story is rife with such unsupported assertions, but where it touches actual facts, it seems to match up.

phenomlab

Dave_Howe Good points. Have you ever though about being a lawyer ? 🙂

Dave_Howe

phenomlab tsk, resorting to personal insults now? 😉

phenomlab

Dave_Howe tsk, resorting to personal insults now?

Just kidding 🙂