My Backdoors in your AWS infrastructure – Part 2: IAM

Continuing the series about AWS backdoors, I am now stepping into the complex landscape of Identity and Access Management (IAM) in AWS. This set of backdoors revolves around IAM services, where a lack of proper security settings or simple mistakes can lead to security holes perfect for unauthorized access.

Keep in mind, AWS IAM is a powerful tool that offers detailed access control. However, this control means that a misconfiguration can create accidental openings for unauthorized access.

From my experience as AWS Ambassador and Cloud Security Architect, I've found a startling number of resources like public EC2 or exposed EKS clusters hosting common tools that were assigned IAM Roles with unnecessarily broad access to IAM-related actions. This is a classic example of why the principle of least privilege is not just a cybersecurity myth, but a fundamental doctrine to follow. The proper implementation of this principle plays a pivotal role in safeguarding your environment.

Take, for instance, if your server only needs to access specific Amazon S3 objects, with a prefix or suffix, in a single bucket - it is crucial to apply granular permissions that only allow actions and resources necessary to complete the task. It's tempting to allow more access "just in case", but this could inadvertently open a door for me. potential intruders.

Moreover, while IAM User credentials might seem a convenient option, they pose a significant security issue when used instead of IAM Roles for your resources. In fact, this is considered a bad practice in the field of AWS security.

And let's not forget about human users. They should absolutely steer clear of using IAM Users. Instead, make use of the AWS Identity Center with its Single Sign-On capabilities. It's more than just staying up-to-date, it's a critical move to enhance security and make things run smoother. Btw – if you don’t have AWS SSO configured for your AWS Organization, wait for one of my next posts to see how I can enable it for you as my backdoor!

If you've already had the opportunity to watch my presentation "Cloud Hacking Scenarios", you're well aware of how easily I can gain access to your accounts with administrator-level permissions, theoretically giving me unrestricted maneuverability. Those unfamiliar with the presentation, I invite you to YouTube - there are recordings from many conferences. But keep in mind, the presentation evolves over time, so aim for the most recent recordings.

Enough of this lengthy introduction, let's dive into my backdoor scenarios in your AWS accounts. Who knows? Maybe this post will end up saving someone's environment, and by extension, a few dollars. Enjoy!

?

Creating a New IAM User

The first step into the IAM backdoors is simply creating a new IAM user. By using IAM actions such as 'iam:CreateUser', 'iam:CreateAccessKey', 'iam:PutUserPolicy', 'iam:AttachUserPolicy', and optionally 'iam:ListUsers', I can make a user with a username similar to existing ones. This helps the backdoor blend in. Then I need to add an access key to the user and assign policies directly or add the user to a group with policies already attached. This extends the reach of this unauthorized access.

To protect against the unauthorized creation of IAM users, you can implement a Service Control Policy (SCP) that prevents regular users or roles from performing the 'iam:CreateUser' action. Add a Deny statement to this policy, but make sure to include a condition allowing a privileged role to perform this action (using something like 'Deny if principal arn not like arn:aws:iam::*:role/PrivilegedRole'). This conditional denial can be utilized in all other SCPs mentioned in this article as well, helping prevent unauthorized access while maintaining necessary privileges for your operations.

?

Generating a Second Access Key

The next strategy needs permissions to create Access/Secret keys and the knowledge of an IAM User username. Using 'iam:ListUsers' and 'iam:CreateAccessKey' IAM actions, I find an existing IAM User and create a second access key. This method is sneaky, as it allows unauthorized actions without affecting the original user's operations.

Similar to previous case, you can secure your environment against additional access key creation by creating a Service Control Policy that prevents regular users or roles from performing the 'iam:CreateAccessKey' action. This protective measure ensures that only authorized individuals can generate access keys, preserving the integrity of your IAM users (which ideally should not exist, btw!).

?

Modifying IAM Role Trust Relationship

Now, let's assume I have an external AWS account at my disposal and permissions to update the 'Assume Role' policy on your account. In that case, I can set up a backdoor by adjusting the Trust policy of a new or existing IAM Role. This change allows the rogue external account to assume the role, providing a disguised entry point.

While there's no perfect SCP solution to prevent modifications of IAM Role Trust Policies, adhering to the Principle of Least Privilege can help. Limiting access to the 'iam:CreateRole' action to a PrivilegedRole is a good start. However, consider deploying a detection mechanism. For instance, AWS Config coupled with AWS Lambda can be used to check each role's trust policy, flagging those with external trust as non-compliant. Such a system offers proactive detection of potential security issues.

?

Setting Up an Identity Provider

For this scenario, prerequisites include an external identity store, permissions to create an AWS Identity Provider, and permissions to update the role trust policy. In this strategy, I create a new identity provider in AWS IAM and configure it to use SAML with an external identity store, such as Okta, Azure AD or a local AD FS. Then, by modifying the trust policy of an existing role or creating a new one, it can work in conjunction with the new identity provider. This setup establishes an indirect access route via an authorized external service, potentially eluding detection.

To protect against unauthorized creation of Identity Providers, implement an SCP that prevents regular users and roles from performing the 'iam:CreateSAMLProvider' and 'iam:CreateOIDCProvider' actions. This preventive step ensures that only authorized individuals can manipulate your Identity Providers, thereby protecting against my backdoors.

?

Wrapping It Up, But the Journey's Not Over

The goal of this series isn't just to highlight potential security risks but also to encourage the use of security best practices. My hope is that by understanding these threats, you'll work to establish proactive defenses and stay true to the Principle of Least Privilege. Stay tuned for the next part of this series, where I'll dive deeper into networking related backdoors.

If you'd like to discuss your cloud infrastructure without any obligation, don't hesitate to reach out. Send me an NDA, suggest a convenient time, and I'd be more than happy to share my experience with you. Plus, if you're interested in the Service Control Policies mentioned above, all you need to do is ask. I'd be more than happy to share them with you!