DNA analysis company demonstrates what not to do before and after a data breach

In early October 2023, a leading DNA analysis provider fell victim to a classic credential-stuffing attack. You may recall that a credential stuffing attack occurs when a threat actor attempts to log in to a system using credential sets that have been compromised in another attack. This type of attack has been around for a long time because it keeps working. Every person who uses the same password for multiple accounts potentially contributes to this type of attack.

The attack in question was said to have breached roughly 14,000 user accounts. Through these 14,000 accounts, the attackers gained sensitive information on about 6.9 million people who used the platform’s optional sharing features. This number represents nearly half of the company’s customer base. The data exposed in the breach included names, birthdates, relationships and DNA percentages with others, ancestry information, and location.

There appear to have been at least two attacks on the company, starting in August 2023 when a hacker advertised 300 terabytes of data for sale on a cybercrime forum. The threat actor ‘Golem’ took credit for the October attack and posted multiple sets of data on a separate forum. TechCrunch investigated both sets of data and found matching records.

Corporate response

Step one: Company comes first.

People have been reusing passwords forever because remembering tens, dozens, or hundreds of passwords is a pain in the neck. Many companies have fallen victim to these attacks, including PayPal, Chick-fil-A, Norton, and Disney+. Last week, Telco giant Orange Spain lost control of 50% of its traffic when a threat actor gained access to the regional internet registry that manages its IP addresses. The registry, RIPE, is a frequent target of credential stuffing attacks because there’s very little password security in place. Credential stuffing attacks are common, and they’ll continue to be common until everyone has a defense against them, or we solve the password problem.

What is uncommon is that the first response from the DNA company was to change their terms of service (ToS) around the mandatory arbitration clause. In short, the company modified the ToS from mandatory arbitration to mandatory INDIVIDUAL arbitration. This is intended to prevent individual victims from collaborating against the company. From the revised ToS:

“… if you are represented by counsel, your counsel may participate in the conference, but you will also participate in the conference. The conference shall be individualized such that a separate conference must be held each time either party initiates a Dispute, even if the same law firm or group of law firms represents multiple users in similar cases, unless all parties agree; multiple individuals initiating a Dispute cannot participate in the same conference unless all parties agree.”

(emphasis mine)

A breach event is painful enough for the individual victims whose data was exposed. All companies engage in damage control post-attack, but most will demonstrate some empathy for the individual victims. In contrast, this company just made things more difficult, tedious, and uncomfortable for the victims. This is a blatant attempt to suppress the number of claims against the company, and it just makes everything more painful for the people hurt by the breach. Regardless of the intent, it has done nothing to stop the flurry of suits that have been filed against the company.

Step two: Blame the victims.

The more interesting and somewhat mean-spirited step taken by the company is to directly blame their customers for the company breach.  

“…users used the same usernames and passwords that had been subject to prior security breaches, and users negligently recycled and failed to update their passwords following these past security incidents.”

This was taken from a written response to a class-action lawsuit filed by the individual victims. It’s not unusual for a company to protect itself, but it is unusual to point a finger directly at the victims in such a specific way. You can read the letter here and the blog post here. Both of these documents tell the victims, “You shouldn’t have done that, so it’s not our fault.” Victim blaming at its finest.

Everyone who uses a password knows that people reuse their passwords. This is why there is a market for companies like Keeper, Dashlane, and Have I Been Pwned (HIBP). This is why identity management is a multi-billion dollar business. There’s simply no excuse for a company worth hundreds of millions of dollars to NOT mitigate one of the most basic issues in IT security.

The shared security model that we've talked about over the last many years when it comes to AWS and Azure doesn't only apply to public cloud providers. All companies have the responsibility to include adequate security measures in their authentication processes. This could be as something as simple as adding multi factor authentication (MFA), using one-time passwords, or sending secret links (magic links) to an email owned by the user. To illustrate the secret link method, let’s look at the Slack communication platform. When a user attempts to log in to Slack, the user receives a verification link (magic link) in the registered email. The user doesn’t need a password for Slack if he has access to his own registered email account. This protects the Slack account from credential-stuffing attacks and makes it much easier for a user who is suffering from password fatigue.

There was no additional protection for the customers of this company. Even a simple integration with HIBP or a similar vendor could have alerted a user when they were creating the account or logging in later, saying “Your password has been breached. Please don't reuse this password” Particularly egregious given the kind of sensitive data that they have.

"The decision to blame the victims has fueled negative press, dodged responsibility, and failed to express any compassion towards those impacted. While this is probably heavily driven by the company's legal department, the letter's tone will likely anger customers and fuel backlash. Ultimately, in many cases, the average person may not know that their password has been compromised elsewhere. It is up to an organization to make sure that its security measures are robust enough to mitigate any end-user risk. Publicly downplaying the risk and deflecting blame is undoubtedly poor PR." ~ Yvonne Eskenzi as quoted in The Register

Step three: Other dumb things

The company took yet another jab at the victims by saying no harm could be had from the stolen data. This is DNA data, which makes this statement both ridiculous and personally offensive. Shortly after the initial breach, the threat actor offered to sell “1 million data points exclusively about Ashkenazi Jews,” data around people of Chinese descent, and other data that identifies users as “broadly European” or “broadly Arabian.” This data can certainly be weaponized by hate groups, and it’s irresponsible to say that no harm can come from the leak.

There are other issues here as well, including the fact that user activity was not tracked. Application security uses metrics like user login metadata, user behavior, pages visited, and so on. This data allows security tools and teams to understand normal vs anomalous behavior. In this case, only 14,000 accounts out of a few million were compromised, but the anomalies probably would have alerted on a possible attack. Catching the attack early would have reduced the number of individual victims because the attacker wouldn’t have the time to steal as much data.  Everything must be monitored and understood so that security teams can build detection techniques and prevent these attacks.  

How to prevent these attacks

Credential stuffing attacks have been going on forever and they're going to get worse as newer and larger database dumps are made available to threat actors.  People will keep reusing passwords, and one of the better ways to prevent this is to have an integration with a third party like HIBP or the protection of Barracuda Application Protection, which can identify and block the creation of accounts with compromised passwords.

There also need to be other mechanisms in place, especially when you have multiple services talking to each other. In this breach, the 14000 breached accounts were a pathway to the data of several million users.  This type of system needs a zero trust or other protective relationship where access to data is controlled, tracked, and blocked when anomalous behaviors are detected.

Barracuda Application Protection includes Privileged Account Protection, which monitors and learns the patterns of incoming account logins and account changes.  This capability alerts security teams when anomalous behaviors are detected. Teams can then review these behaviors and investigate the cause. This is how you identify and block the low and slow attacks like this credential stuffing breach.

Attackers are not stupid. They’re not going to attack with a single bot or a single user running through a password dump and attacking from a single IP address. These attacks are automated, operating through tens of thousands of devices across tens of thousands of IP addresses. You need robust protection against credential stuffing and other application attacks.

Protecting your users is always very critical for any business, and probably more important than anything else. If user data is breached through your company, you can face heavy fines and other regulatory penalties. You may face costly lawsuits that drag on for many years. Your brand reputation and future business are at risk after a data breach. You probably already know this. That DNA company knew it too.

Protecting user logins is a shared responsibility. The company's share of this responsibility is to reduce the breach attack surface as much as possible. This means enforcing MFA, monitoring for anomalies, and deploying a mechanism that defends accounts from compromised credentials at the time of creation and during all login attempts thereafter. These are just a few of the many steps you can take to protect your customers and your business. This is the company’s responsibility. Under no circumstances should a company ignore best practices and then punish the victims when the company is breached.