A former contractor used a shared cloud admin key (2018) and what it shows about shared admin logins

An online education company kept user data in Amazon Web Services (AWS) cloud storage. It let employees and outside contractors share one access key with full administrative rights over that data. Around April 2018, a contractor whose work had ended used the key to take a database with personal information on about 40 million users. This summary follows an FTC complaint issued January 25, 2023. The facts below are what the FTC alleged.

What happened

The company sells educational products and services to students. It stored user files in AWS’s Simple Storage Service (S3), which keeps data in containers called buckets. The files included names, passwords, dates of birth and answers from a scholarship search tool.

According to the complaint, the company didn’t give each person a key of their own. It let employees and contractors use “a single AWS access key” with full administrative privileges over all the data in those databases. The FTC calls these keys the AWS Root Credentials. An access key is not the password you type on a sign-in page. Programs and command-line tools use it to reach AWS directly.

Around April 2018, someone whose contract had ended used one of those root credentials to get into an S3 database. The complaint says the company had shared the credentials “among its employees and even outside contractors.” The former contractor took a database with personal information on about 40 million users.

The database held email addresses, names and passwords. For some users it also held scholarship data: religion, heritage, birth date, the parents’ income range, sexual orientation and any disabilities. Only the passwords were hashed, and the rest was stored in plain text. The hash method was MD5, which the complaint says experts had deprecated for years before 2018.

In September 2018, a threat intelligence vendor told the company that a file with some of the stolen data was available on an online forum. When the company reviewed it, about 25 million of the passwords in it had been cracked. The company required about 40 million users to reset their passwords.

The cause the record states

The complaint lists four access failures that lasted until October 2018 at the earliest. The company:

• let employees and contractors share one key instead of requiring distinct keys
• didn’t limit access based on each person’s job
• didn’t require multi-factor authentication (MFA), a second check beyond the key or password, to reach the databases
• didn’t rotate the keys

The shared key let a former contractor in. Because the key belonged to no one person, ending one contractor’s work didn’t end it, and because the company didn’t rotate its keys, it kept working. The FTC’s business guide, Start with Security, sums up the case the same way: the company didn’t terminate or update the credentials “when a contractor left.”

The complaint also says that with reasonable access controls and monitoring, the company “would have likely detected and/or stopped the attack more quickly.”

Corrective steps

After the breach, the company rotated its credentials. It also created credentials whose permissions matched each employee’s job. The FTC says other failures continued, including storing personal information in plain text.

Controls usually expected after incidents like this

AWS’s own guidance on the root user addresses the same points. It says the root user has complete access to the account. AWS strongly recommends not using it unless a task requires it, and creating an administrative user for everyday work instead. It says not to share the root password, MFA, or access keys with anyone without a strict business need. It strongly recommends not creating access keys for the root user, and it recommends alerts whenever root credentials are used.

The FTC brought this case under Section 5 of the FTC Act. Financial institutions covered by the FTC Safeguards Rule have written requirements on the same points. The rule requires access controls that let in only authorized users and limit each one to the customer information their duties need (16 CFR 314.4(c)(1)). It requires MFA “for any individual accessing any information system” (314.4(c)(5)). It also requires monitoring and logging of what authorized users do (314.4(c)(8)).

The same gap shows up with shared admin logins to web consoles. When several people, contractors among them, know one admin password, the password has to change each time any of them leaves. How to set up admin access for a team is covered in Managing the AWS root user and admin access for a team. What to collect at the end of a vendor contract is in Checklist for taking back access when a vendor contract ends.

Questions to ask about your own setup