PingCap TiDB Leaks

Posted by swyx 1 day ago

Counter360Comment59OpenOriginal

Comments

Comment by 47 seconds ago

Comment by 2 minutes ago

Comment by llama052 10 hours ago

https://www.pingcap.com/trust-hub/security/security-update-o...

I find it really baffling how much they are downplaying this incident on their statement.

”An external incident response firm reviewed PingCAP’s production systems and found no evidence that the attacker ran commands or maintained persistent access in the systems reviewed”

That does not appear to be true.

Comment by bombcar 9 hours ago

Certainly there was no evidence; they likely have no logging anyway!

Comment by zergrush 9 hours ago

since they pasted customer creds in jira tickets they most likely are very liable hence the downplaying

im not an expert but if I was an investor I'd try to find a buyer for my shares and run

Comment by hobofan 12 minutes ago

Also time to audit the auditors!

Comment by alright2565 7 hours ago

> in the systems reviewed

is load bearing I expect.

Comment by albert_e 2 hours ago

Also

> production systems

Wonder if they just reclassified all operational systems as pre-production, post-production, quasi-production etc.

Comment by dherls 1 day ago

If true, this is next level incompetence from PingCap. Apparently the attackers set up a replication pipeline for a month?!

> We even stood up a replication feed of their own control-plane database using credentials committed in their own repositories — GCP service-account keys and an Azure service principal — and let their infrastructure deliver it to us. Every six hours, for the last twenty-two days of the campaign, from 8 September to 30 September, that pipeline faithfully re-exported every table of the operational heart of TiDB Cloud — tenants, users, API keys, cluster credentials, changefeeds, migrations — and pushed it out.

Comment by autoexec 5 hours ago

If we were living in a sane world this would end this company. They would lose every customer they have and be buried in lawsuits that bankrupt them into the ground. I hope for sanity, but I wouldn't be surprised if they stay operating even after all this.

Comment by alfiedotwtf 4 hours ago

On the bright side, FulcrumSec could possibly moonlight as database consultants given they managed to setup a large fault-tolerant replication feed without falling over for a month

Comment by aliasxneo 10 hours ago

> PingCAP's engineers paste customers' production credentials into Jira tickets.

Holy hell, I've heard of this happening, but I've never personally seen it in my 10 years as an SRE. That's absolutely wild.

Comment by adamparsons 10 hours ago

It sounds like their jira instance was truly the keys to the kingdom, given the creds _and_ tickets describing all the flaws needing fixing. A golden README.MD to escalate to their hearts content

Comment by xKingfisher 1 day ago

Coming this close on the heels of the security audit by NCC [1] is pretty embarassing for all parties.

[1]https://www.pingcap.com/press-release/tidb-ncc-group-securit...

Comment by kobieps 18 hours ago

From personal experience having worked with multiple "enterprise-grade" pentest vendors (including NCC), I think the entire pentest industry is overdue for a big shake-up.

Comment by jascha_eng 39 minutes ago

yeh running some automatic scripts against public urls to check if https is enabled and scanning if there are public s3 buckets is barely any better than a security linter.

There are some teams that are better than this, but they are rare.

Comment by tgv 6 minutes ago

The press release speaks of "a rigorous source-code security assessment by NCC Group." That suggests more than a bit of url scanning. Somebody is lying, that much is certain.

Comment by hintymad 17 hours ago

> TiDB, the open-source distributed SQL database powered by PingCAP, today published the results of a rigorous source-code security assessment by NCC Group, one of the world’s leading cybersecurity consultancies.

It looks like you can assess the hell out of your source code, but your system can still leak if you don't secure your operations.

Comment by somat 8 hours ago

There was a quote from back in early web days that has stuck with me, Still relevant today.

"good opsec will save you from bad crypto. but the converse is not true, good crypto will not save you from bad opsec"

Comment by jacquesm 10 hours ago

No particular opinion on NCC but a lot of that stuff is pay-to-play.

Comment by mogwire 6 hours ago

I don’t think people truly understand how bad it is.

15 years ago I helped do a PCI/SOX compliance evaluation for a company looking to go public.

They had PWC in there with kids fresh out of college, no computer experience, and they would sit at the desk with the admins and say, “show me your Active Directory password policy”. Ok, looks good. CHECK

Why don’t you have this configured? I’d hear an alarming bullshit reason. Ok, we can exempt that. CHECK

I could go on and on and on with how bad it was.

And they bragged to potential investors. We are PCI/SOX complaint.

Comment by jacquesm 2 hours ago

The big four are by far the worst.

Comment by xKingfisher 5 hours ago

I would have considered "the system" to also include password reset policies.

Comment by jacquesm 2 hours ago

This comes up regularly, even today.

Comment by arpinum 1 day ago

AWS private rates gives PingCAP ~47% off list price. Wonder which services got the biggest discounts? Unsurprisingly for a db company the cross-az traffic is 15% of their bill.

Comment by driverdan 8 hours ago

Sounds about right. The more you use the deeper the discount they'll give you.

Comment by perpetualpear 9 hours ago

You can get some sweet deals on s3, assuming you store 10-100s of PB

Comment by robertclaus 6 hours ago

Eh, the math implies <10% off their total bill. Unclear what LLM wrote this page up from their actual report, but it wasn't very good at math.

Comment by arpinum 2 hours ago

Oh, maybe they combined savings plan discounts and private pricing?

Comment by gooseai 1 day ago

[dead]

Comment by neya 9 hours ago

Pingcap's statement:

    With support from outside counsel and third-party forensic specialists, there is no evidence that data stored in TiDB was impacted. We keep on investigating and will provide updates on any new findings.

They have the fucking data in a tarball and Pingcap claims no data was impacted. This sounds like the bad blood story part 2 all over again.

Comment by swyx 3 hours ago

well technically they didn't LOSE data, in fact, now they have free global replicas of the data!

Comment by throwaway2037 2 hours ago

"technically": For once, somebody used it correctly!

Comment by alfiedotwtf 4 hours ago

Counsel isn’t there to help them technically

Comment by kami23 6 hours ago

Whoever is doing these infiltration are still out there and nothing is really changing with how these are responded to, these guys aren't going to be the only ones. The cat is out of the bag, you gave people the access to unlimited automation, and it turns out people know how to use it for both 'good' and 'bad' for your various definitions of the two.

Defense as we see it today seems fundamentally broken. The answer is to fight it with more AI? That doesn't seem right. Can software reliably self evolve and keep patching itself? What certification is going to protect you from an intruder with their legion of minions, none of them, you don't have perfect visibility to your systems, your systems emit too many signals to ingest 100% of actions, so does software need to get fundamentally simpler?

Today has me wondering how many datacenters exist out there just for organized crime? Are the big kingpins of the world going all in AI as well?

Lots of questions popping into my head today, I'm trying to think how you would slow or stop this and I can't help but think we just need everyone to go outside and touch some grass and remember we're all stuck on the same rock.

Comment by ozgrakkurt 1 hour ago

It is exceptionally easy to make things secure if you are developing conservatively.

Kind of like how permissions model of deno. If you make everything closed by default and selectively open it is very easy.

Not putting credentials to everything in jira isn’t related to using of ai for hacking imo

Comment by TheCynosure 29 minutes ago

Can someone help me understand this part:

> The billing engine that trusts unverified X-ACCOUNT-USER-ID headers. The account service where admin is a tenant ID and impersonation bypasses org checks with owner role.

What is the issue with the billing engine trusting an “unverified” header here? Is the assumption that it’s not auth-ing the request? Is the billing engine internal? What does “unverified” even mean in this context.

What’s the problem with Admin being a tenant ID? How would impersonation even cause bypassing an org check?

Comment by hobofan 6 minutes ago

That whole paragraph reads to be AI written.

Depending on how the billing engine is deployed, and whether there are adequate controls that it's being deployed correctly, there is nothing wrong with accepting a header like this from an upstream service that produces it or verifies it in the correct manner. It only becomes an issue if the service is directly exposed to potential attackers that could use it for impersonation, e.g. a service directly exposed to the internet.

Comment by nemothekid 1 day ago

Man I recently executed a migration from Aurora to Planetscale. I seriously considered PingCap but decided against it because I thought they cloud pricing was too complex. I wonder if my personal information is in the leak.

Comment by redwood 50 minutes ago

What makes you confident Planetscale opsec is elite, out of curiosity? I have a great respect for the team and would like it to be true. But is there evidence?

Comment by wannabe44 1 day ago

> Summary: "The root password of the cluster can be reset unconditionally"

But what matters is that it was all memory safe and had no data races.

Comment by boorbat 22 hours ago

You realize it's written in Go right?

Comment by wannabe44 20 hours ago

Not even data race safe then. NGMI.

Comment by dangoodmanUT 1 day ago

what is happening today

and how are people not talking about this more

Comment by dilyevsky 1 day ago

only the beginning. next year or two are going to be wild on this front so buckle up...

Comment by thenthenthen 10 hours ago

Why is Baidu among their clients

Comment by autoexec 5 hours ago

Because they give them money. That's all they care about.

Comment by esafak 1 day ago

Comment by autoexec 5 hours ago

PingCap is not the victim here. This level of apathy and incompetence makes them an accomplice.

Comment by rvz 1 day ago

First the Google Cloud outage [0], then the CA private key leak [1]...

...and now this...

> Today we are making the PingCAP breach public. We possess the complete TiDB Cloud control plane, its billing and finance estate, its GCP storage estate and its AWS cost and billing estate, its Jira, its CRM, its analytics, its source code, and a four-year log of every connection every customer ever made to its product, from the IP addresses of their application servers.

This is an entire leak of ALL PingCap TiDB's customers AND data.

All of this in a single day. It is over.

[0] https://news.ycombinator.com/item?id=50163961

[1] https://news.ycombinator.com/item?id=50166579

Comment by gregwebs 1 day ago

I am reading this as a leak of every possible piece of metadata but not an actual leak of customer data. They have SQL logs which do contain customer data and there is a mention of some snapshots/imports.

Comment by berenddeboer 14 hours ago

they leaked full connection strings for customer databases with users and passwords.

Comment by hdjdnxjzhzhs 1 day ago

How the fuck is 10.6TB metadata?

Comment by gregwebs 1 day ago

TiDB is for large scale data. You generally wouldn't use it unless you have at least 1TB of data. 10TB is a single small customer database for them.

Comment by fock 19 hours ago

(POV when storing 1PB in Oracle) when I saw the 10 TB in another post, I was like "wait, isn't this sold to scale out, we have 100 times the data here".

Comment by binsquare 1 day ago

Easily at scale

Size is not a good indicator for content quality

Comment by qingcharles 1 day ago

Don't forget the PHP megabomb dropping in a few hours too.

Comment by swyx 3 hours ago

... how did you know?

Comment by gooseai 1 day ago

[dead]

Comment by jedisct1 1 day ago

It's written in Rust, so it's safe.

Comment by boorbat 22 hours ago

https://github.com/pingcap/tidb reports as 95% Go with no Rust at all?

Comment by squirrellous 22 hours ago

That confused me too since I remember reading they are Rust proponents. Apparently their storage engine TiKV is written in Rust, and TiDB is the database built on top.

Comment by bbkane 7 hours ago