TiDB Breach Exposes Flawed Cloud Security Assumptions

Cloud providers may be storing sensitive customer data, without either party knowing it. But when a provider is breached, the data comes home to roost.

A breach of an open source database provider may have inadvertently highlighted a serious gap in the way companies think about their cloud security.

On Oct. 19, software maker PingCAP, which sells an SQL database program called TiDB, disclosed that it had been breached. According to PingCAP’s website, it serves major American corporations like Atlassian, Square, and Pinterest, as well as major players in China’s artificial intelligence (AI) space, including Manus, Kimi, and more.

The perpetrator — the somewhat deceptively named “Fulcrum Security,” or FulcrumSec, for short — is a relatively new extortionist group whose leak site already includes major organizations like LexisNexis, Novo Nordisk, and the Manchester Airports Group (MAG). Earlier this fall, FulcrumSec appears to have compromised PingCAP, enjoying something shy of unfettered access to all of its cloud management, financial, analytics, storage, and other systems for a month or more.

The even bigger issue is whether the breach exposed downstream customers’ sensitive data. Investigators are still working out the details, but early evidence suggests that customers may in fact be at some risk. Though their actual databases weren’t breached, the information their vendor stored about them may have been enough to cause serious issues.

Dark Reading reached out to PingCAP for comment but the company did not respond at press time.

Vendor Breach Puts TiDB Customers at Risk

In a security notification published 12 days after first having discovered the incident, PingCAP acknowledged that hackers had access to its systems from Sept. 9 to Oct. 7. Using stolen service account credentials, the company wrote, the unauthorized party accessed internal company systems and then copied data and source code.

PingCAP’s own third-party-assisted investigation found no evidence that attackers ran malicious commands or maintained persistent access in their systems, nor did they access any customers’ databases. Instead, it said, the threat actors accessed customers’ billing and other business data, such as contract terms and pricing, as well as various information pertaining to cloud accounts and product usage — email addresses, SQL editor text and errors, etc. They also exported a table with encrypted API keys, though investigators said the encryption protected the keys from actually being used maliciously.

FulcrumSec, however, painted a bleaker picture.

In a name-and-shame post to its leak site, the hackers claimed to be in possession of all of PingCAP’s service management records, its financial records, its files stored within Google Cloud, Jira support tickets, customer relationship management (CRM) data, analytics data, source code, plus a four-year-long log of every connection every one of its customers ever made to the TiDB Cloud service.

Crucially, the hackers did not claim to have stolen any TiDB databases straight up. Instead, they indirectly obtained a wealth of potentially exploitable user data like those aforementioned API keys and other secrets, and potentially sensitive internal data exposed by cloud database commands.

The attackers fingered individual enterprises caught in the crossfire: brand name US companies like AirBnB and Booking.com, Asian corporate giants like Baidu and Fujitsu, and a few of the world’s biggest video game companies, including Capcom, Konami, and Square Enix. Asia represented the biggest slice of the pie, with nearly 2,000 affected organizations in Japan, China, and Hong Kong, with another 500 from India.

Additionally, FulcrumSec said its unauthorized access lasted for nearly two months, not just one. It was so comprehensive and unthreatened that, in the meantime, they were able to stand up a mirror of PingCAP’s own service management system. Instead of having to manually exfiltrate data, their replication feed automatically pulled fresh copies of the company’s internal database every six hours, for 22 days.

Claims made by threat actors must always be met with a degree of skepticism, and Dark Reading did not independently confirm FulcrumSec’s. Still, the group does have some record of reliability.

Last summer, for example, the group breached Manchester Airports Group (MAG), claiming to have stolen 86GB of data. That data turned out to contain far more genuine personally identifiable information (PII) than MAG copped to, according to reporting by BleepingComputer. And whereas some hackers exaggerate their winnings, this case was something of the opposite: that initial 86GB claim in fact represented compressed data. The hackers clarified that the actual, uncompressed total stolen was actually 640GB.

Orgs: Be More Critical of Your Service Providers

Even if one were to completely ignore the hackers’ account, and take PingCAP’s more limited assessment as the truth, it would still represent a potentially serious risk to customers.

Arguably the most acute dangers — more than the broad customer data, or the API keys if they are in fact protected — lie in the less obvious exfiltrated data. This includes Jira tickets, SQL histories, and places where organizations unthinkingly leak internal data. For instance, when customers use their cloud-managed database services, they send commands to the vendors’ servers, obviously. Those interactions can often carry corporate secrets, or sensitive data of many other sorts.

“Vendors don’t typically set out to store secrets. However, customers often pass them over to use features built for convenience, and the data can settle in places few people think of as credential stores,” Crystal Morin, senior cybersecurity strategist at Sysdig, explains.

PingCAP’s SQL editor text and errors as an example, she says. “That’s query history and error output, which is where secrets can accumulate when someone pastes a connection string to debug something on the fly,” Morin adds. In FulcrumSec’s name-and-shame post, for example, it highlighted exfiltrated SQL statements that listed in full view one medical clinic’s roster of patients, and another’s list of medical professionals.

Keeper Security chief information security officer (CISO) Shane Barney seconds Morin’s point. “The PingCAP incident illustrates a daily reality in enterprise security: attackers do not need to compromise a customer’s primary database directly if they can systematically harvest upstream credentials,” he says. “In modern software-as-a-service (SaaS) ecosystems, customer metadata, API keys and diagnostic query logs routinely seep into vendor environments through everyday operational telemetry. When service account credentials or administrative API tokens are stolen from a provider, that aggregated operational data transforms into a road map for exploitation.”

Barney emphasizes the importance of cloud security hygiene — such as rotating vendor-facing API keys, and eliminating hardcoded and long-lived secrets in developer workflows — and vetting one’s managed service providers by demanding continuous third-party risk assessments and independent certifications and attestations such as SOC 2 Type II and ISO 27001.

Morin urges organizations to ask a few specific questions when vetting cloud providers. “Teams should seek to understand what customer-provided data the vendor retains and what its retention policy is. They should also ask whether they scan for secrets at ingest and redact what they find,” she says. “Teams may also want to understand how service account credentials are handled, whether they’re short-lived, how they’re scoped, how often they rotate, and what detections fire on anomalous credential or account use.”

And, she says, don’t forget: “Inquire about breach notification, specifically the timeline and what triggers it.”