The single sign-on (SSO) management company OneLogin Inc. suffered a data breach earlier this year that affected...
all of their U.S. customers. An attacker managed to access an Amazon Web Services API and may have been able to decrypt customer data. How did the attack method leverage APIs, and what does the breach mean for other SSOs?
After the OneLogin data breach, the company reported that "a threat actor used one of our Amazon Web Services (AWS) keys to gain access to our AWS platform via [an] API from an intermediate host." This was not a compromise of AWS, but of OneLogin's AWS accounts.
The attacker was able to execute an AWS API to create a new server under his control inside the OneLogin domain in order to attack the company's internal AWS environment -- meaning the attack took place inside OneLogin's firewall or AWS perimeter. The Amazon Web Service API has a command API named create-server that could have been used to set up the server that was used to attack the internal environment, but it is not publicly known if this is how the attacker got access to the internal environment.
However, it is thought that this could make it even easier to attack an internal system, as the newly created server may not be monitored like standard servers are -- meaning it may take even longer to detect a compromised server in your internal environment.
The SSO company didn't report how the attacker compromised the AWS key during the OneLogin data breach, what kind of access the AWS key had -- such as if it had root access -- or how the attacker accessed OneLogin's AWS environment. Furthermore, standard security recommendations focused heavily on protecting the AWS keys and network access to the AWS accounts.
After knowledge of the data breach was made public, OneLogin recommended that their customers generate new API keys and OAuth tokens; create new security certificates and credentials; recycle any secrets stored in the Secure Notes feature, which enabled users to store information such as passwords and license keys; and have end users update their passwords.
Since so many areas of the company were exposed, and a significant number of their customers were impacted, the way that OneLogin handled this breach could have had an industry-wide impact on how people think about security and cloud services.
Overall, the OneLogin data breach could mean that enterprises need to pay more attention to liability and indemnification in cloud contracts or require more details on how a cloud provider secures their environment -- for example, OneLogin had a SOC 2 report at the time and the data breach still occurred. Enterprises may also want to develop a plan in case their cloud provider is compromised or if they're potentially unavailable to ensure the continuity of the enterprise's business.
Ask the expert:
Have a question about enterprise threats? Send it via email today. (All questions are anonymous.)
Dig Deeper on Single-sign on (SSO) and federated identity
Related Q&A from Nick Lewis
Cloud penetration testing presents new challenges for information security teams. Here's how a playbook from the Cloud Security Alliance can help ... Continue Reading
Many cloud providers are tight-lipped about internal security control details. Learn how to evaluate cloud security providers with certifications and... Continue Reading
Enterprises new to the cloud can write new security policies from scratch, but others with broad cloud usage may need an update. Consider these ... Continue Reading