Password management company OneLogin announced last week that an unknown actor compromised secure databases by obtaining a set of AWS keys. This occurrence is especially concerning to security communities who have recommended password managers as a safe alternative to memorized passwords, which are frequently reused and easy to guess.
OneLogin CISO Alvaro Hoyos posted Wednesday:

“[OneLogin is] working with an independent security firm to determine how the unauthorized access happened and verify the extent of the impact of this incident.”

Later, Hoyos confirmed that the attacker had used compromised AWS keys to “access the AWS API from an intermediate host.”

The attackers infiltrated the system at 2 AM and weren’t shut out until 9 AM, indicating that OneLogin may not have had robust incident detection in place to alert them to anomalies on the network as they were happening. Rhino Security Labs has previously published research regarding compromising AWS instances similar to the same vulnerabilities that the OneLogin attackers exploited.

AWS Resource access is delegated to a 3rd party through unique API keys. These keys are unique to the AWS user and permission specific meaning that the keys are only valid for your resources and access is specified during the key creation process.

When a cloud-based company such as OneLogin grants permission to an internal or external service provider, it must generate a new set of credentials for that service provider. There are many levels of credentials used to access an AWS API. Currently, it is unclear what type of credentials were compromised in the OneLogin breach.

Generally, AWS API keys allow the owner of the key to complete a limited number of actions at a secured API endpoint. However, developers commonly troubleshoot API integration issues by granting very broad permissions to one set of keys. Often this troubleshooting step goes unnoticed, and overly broad key permissions persist long after they are needed.

Additionally, AWS keys are generally stored in the same versioning repository as general source code. This sometimes results in AWS keys being inadvertently disclosed by developers who check in a chunk of source code publicly without realizing that private keys have been included in their check in. GitHub in particular has been a gold mine for hackers searching for accidentally disclosed private keys.

The OneLogin breach was particularly significant because of the number – and type – of passwords they store.  Many sites store passwords for their users, but those passwords are often hashed, requiring the attacker to crack the passwords – often with mixed success.

OneLogin is different. Because it must provide its users with passwords on demand, it cannot hash those passwords. It can only encrypt them. Unlike hashing, which is a one-way cryptographic function, encryption is a two-way function. If an attacker has access to the proper keys, that attacker can decrypt the data and have access to the original cleartext password.

We know that the OneLogin attacker got unauthorized access to API keys.

This could have occurred in three different ways:

Phishing/Malware

Phishing techniques are extremely effective, and all users are susceptible to such attacks. It would have been trivial for the attacker to phish a user at the service provider being used by OneLogin, install malware on their computer, and monitor user behavior while they were accessing the relevant API keys.

Accidental Exposure

A developer may have pushed an update to a source code repository without realizing that the keys were included in the update. Likewise, the permissions on the AWS account may have been intended to expose the keys only to a small number of users but may have been inadvertently configured to expose them publicly.

Malicious Insider

The compromised keys belonged to a OneLogin service provider. That service provider may not have had a robust privileged access management system allowing only those who needed them to obtain the keys. If this was the case, any number of low-level employees might have had access to these high-value keys and may have intentionally compromised them.

OneLogin has contacted customers whose data was disclosed and provided them with instructions to reset the relevant passwords. If those customers neglect to reset the passwords, however, an attacker may have ongoing access to their accounts and may be able to use those accounts to access other services that were not stored on OneLogin.

The biggest threat to OneLogin customers is overreacting and reverting to former, unadvised password management techniques. If consumers go back to repeating passwords across services rather than generating long random unique passwords for every account, everyone is less secure.

For cloud/SaaS companies, the biggest risk is around misconfiguration of complex cloud architecture. AWS and other providers have become complex technology stacks of their own, and fewer individuals understand them compared to traditional, in-house network architecture. Proper configuration review and penetration testing against these services are critical to highlighting any cloud-specific vulnerabilities.

Hackers aren’t magic, and breaches aren’t inevitable. Many common mistakes could have allowed this to happen:

Misconfigured Identity and Access Management (IAM) Settings

AWS has very complicated IAM settings, and it’s easy to get them wrong. Make sure that you audit your AWS IAM settings on a regular basis to make sure that permissions are not misallocated. Engage Identity – a strategic partner of Rhino Security, offers cloud security audits as a service.

Lack of Regular Penetration Testing and Security Assessments

Your company should have a holistic security assessment approach to discover vulnerabilities throughout your infrastructure. In addition, you should have regular external penetration tests of all of your critical systems.

Failure to Manage the Risks Associated with Cloud Infrastructure

A cloud-based company can’t hide all of its most valuable assets behind a firewall. Permissions have to be carefully configured since many cloud endpoints are publicly available. The risks associated with a cloud-based infrastructure are fundamentally different and depend heavily on proper key management and protection.

We are certain to learn more about the OneLogin breach as details are revealed in the coming weeks, however, we can reflect on the lessons learned. Password managers will help you and your employees create long random unique passwords, and you should continue using them even after this breach.

Also, verify the configuration of your AWS infrastructure. AWS has a very secure infrastructure, but information leakage and misconfiguration can alter the security of the instance. Make sure your AWS keys are properly secured, and that your AWS permissions are well-structured and frequently audited.