Who Would Ever Want to be a CIO: The Largest Data Hack Ever?

Prof Bill Buchanan OBE FRSE
5 min readJun 2, 2024

The minute you off-shore your data and processing to a third-party provider you are relying on others to protect your data. So why, in the 2020s, are we still not properly encrypting and protecting customer data? So, even when an intruder manages to get around access control, they would be faced with encrypted data and layers of encryption. For databases, this must include processing within secure enclaves, and in the usage of columnar encryption.

And, who would carry-the-can when something goes wrong? Well, that is likely to be the CIO (Chief Information Officer), and which must be one of the most stressful jobs in cybersecurity, especially when things go wrong. I do feel sorry for CIOs, as most companies must balance their cybersecurity budgets against risk. Along with this, the CIO might have to take responsbility for mistakes by developers and administrators.

Snowflakes

So, this week, we could see the largest data hack ever, linked to Snowflake — a cloud storage and analytics company. This includes breaches against Ticketmaster and Santander. At the core seems to be the Shiny Hunters group and which are malware creators.

Details of the hack appeared on BreachForums on 27 May, and which asked for a ransom of $500,000 and claimed to have 1.3 TB of Ticketmaster data, This includes more than 560 million customer data records, including names, addresses, email addresses, phone numbers, partial credit card details, ticket sales, order details, and more. They asked for $500,000 for the database. A few days later, ShinyHunters claimed they had over 30 million customer details and staff information from Santander, and with a $2 million ransom demand. The FBI had actually taken down BreachForums on 15 May, but it has since reappeared. Some think the announcement of these data breaches is a way to announce that the Web site is still up and running.

As Snowflake runs cloud systems for other companies, these hacks may be just the tip of the iceberg [here]:

There is evidence that over 400 companies have had their data scraped. Brad Jones, the CIO at Snowflake, has acknowledged the possible breach [here] and told customers about how they should protect their accounts:

We can see the statement of:

“we did find evidence that a threat actor obtained personal credentials to and accessed demo accounts belonging to a former Snowflake employee. It did not contain sensitive data. Demo accounts are not connected to Snowflake’s production or corporate systems. The access was possible because the demo account was not behind Okta or Multi-Factor Authentication (MFA), unlike Snowflake’s corporate and production systems.”

Overall, Snowflake detected malicious traffic from “rapeflake” from another client called “DBeaver_DBeaverUltimate. A range of possibly malicious IP addresses have been identified [here]:

And customers can check for the usage of rapeflake with:

SELECT
*
FROM
snowflake.account_usage.sessions
WHERE
PARSE_JSON(CLIENT_ENVIRONMENT):APPLICATION = 'rapeflake'
OR
(
PARSE_JSON(CLIENT_ENVIRONMENT):APPLICATION = 'DBeaver_DBeaverUltimate'
AND
PARSE_JSON(CLIENT_ENVIRONMENT):OS = 'Windows Server 2022'
)
ORDER BY CREATED_ON;

A Python program to detect these rules is given here. The possibilities from the hack are outlined in this article [here]:

The recommendation from the Snowflake highlights the need to implement MFA on accounts and resetting credentials:

  1. Enforce Multi-Factor Authentication on all accounts;
  2. Set up Network Policy Rules to only allow authorized users or only allow traffic from trusted locations (VPN, Cloud workload NAT, etc.); and
  3. Impacted organizations should reset and rotate Snowflake credentials.

It can be seen that there is evidence of a demo account being used. This is a common practice with developers, and they normally keep an account for testing, which has high privileges. The company, at the current time, do not think that the data leak was caused by any vulnerability, misconfiguration, or breach of Snowflake’s product. But, major questions remain unanswered, and where there should have been encryption applied to records, and strong access control on each record.

At the current time, SnowFlake says that Crowdstrike has investigated their systems and that the problem is not on their site, and they have since pin-pointed their customers for not following their recommended security guidelines.

Some cybersecurity organisations around the world have already identified the hack as high risk [here]:

and the statement from Sandandar is [here]:

Conclusions

Watch this space. This is going to be big!

So, who should you blame for a data breach, the cloud provider (eg AWS), the cloud platform (eg SnowFlake), or the user of the platform? Overall, it is not the cloud provider that will be to blame, as this environment tends to be highly trusted. So, this week will show who is really to blame for his data breach, and the scope of the breach.

Finally, I repeat again, why, in the 2020s, are we still not encrypting citizen data?

--

--

Prof Bill Buchanan OBE FRSE
Prof Bill Buchanan OBE FRSE

Written by Prof Bill Buchanan OBE FRSE

Professor of Cryptography. Serial innovator. Believer in fairness, justice & freedom. Based in Edinburgh. Old World Breaker. New World Creator. Building trust.

Responses (6)