Design AWS API Access with Care – Case Onelogin

The recent Onelogin breach, shown here in their official blog post highlighted to us that account access permissions can be devastating if not done right.

From Kerbsonsecurity:

“Our review has shown that a threat actor obtained access to a set of AWS keys and used them to access the AWS API from an intermediate host with another, smaller service provider in the US. Evidence shows the attack started on May 31, 2017 around 2 am PST. Through the AWS API, the actor created several instances in our infrastructure to do reconnaissance. OneLogin staff was alerted of unusual database activity around 9 am PST and within minutes shut down the affected instance as well as the AWS keys that were used to create it.”

There are several ways to minimize the risk of a breach like this:

• EC2 role-based access instead of API keys for services
• SAML Identity and Access permissions for users
• CLI IAM roles with Multi-factor authentication enforced for developers

The simplest way of minimising the risks is to avoid creating API keys for any application or user if possible. In AWS, you can create roles which can be applied to most services, such as EC2 instances and Lambda functions. The role-based permission model lets you specify least privilege with conditions. For example, all API calls have to originate from specified AWS accounts only. The access keys used for these API calls are temporary and only valid for a certain time. The nice thing for an AWS user is that this is transparent and you don’t have to manage the key rotation at all.

If your organisation currently has a user directory service then you can use SAML based federation for the users within your organisation. They will login to your organisation's internal portal and will end up at the AWS Management Console without ever having to supply any AWS credentials. There are also third-party SAML solution providers which can be used to enable this.

Sometimes it might make more sense to manage the users within AWS. Make then sure that you delegate access across AWS accounts using IAM roles with Multi-factor authentication enforced in the access policy document. Multi-factor authentication (or two-factor authentication) is a simple best practice that adds an extra layer of protection on top of your username and password. With MFA enabled, when a user signs in or wants to use an API key, they will need to provide their access key and secret key (the first factor: what they know), as well as for an authentication code from their MFA device (the second factor: what they have). Taken together, these multiple factors provide increased security for your AWS resources.

With MFA enabled you will need to specify an AWS CLI configuration with the information about your MFA device. See this simple example for inspiration:

[profile loginaccount]

region = eu-west-1

source_profile = loginaccount

[profile dev]

region = eu-west-1

source_profile = loginaccount

role_arn = arn:aws:iam::xxxxx:role/Developer

mfa_serial = arn:aws:iam::xxxxx:mfa/foo@bar.com

[profile prod]

region = eu-west-1

source_profile = loginaccount

role_arn = arn:aws:iam::xxxxx:role/Developer

mfa_serial = arn:aws:iam::xxxxx:mfa/foo@bar.com

Then in the credentials file you have:

[loginaccount]

aws_access_key_id = AKXXXXXXXXXX

aws_secret_access_key = SUPERSECRETKEY

The only user within the organization is the one in the login account. To switch to another account, change the profile using the AWS CLI as such:

$ aws ec2 describe-instances --profile dev

or export the profile as an environment variable if you always want to use a specific account:

$ export AWS_DEFAULT_PROFILE=dev

Limes is an application that creates an easy workflow with MFA protected roles, temporary credentials and access to multiple roles/accounts.

Have a look if you have a lot of accounts or roles to manage.

It can be really hard to discover a breach. Onelogin were lucky that they saw the unusual database activity as fast as they did their own tests that have shown it takes between 2-15 minutes before someone starts using AWS API keys pushed to a GitHub repository. AWS themselves do look for published API keys in GitHub, but it might take up to 24 hours before they notify you of their finds.

An audit and security account is one solution to this problem. The audit account should have access to all cloud trail logs and constantly monitor for any unusual activity such as the creation of IAM users.

Need help securing your cloud? Nordcloud can help you with all of the points above as well as doing security audits and workshops. With your cloud trail logs monitored 24/7 by Nordcloud Managed Services Monitoring we can react with 30 minutes if an unauthorised API call is made.