DEV Community

Cover image for Hacking My Own AWS Account: A Tale of Legacy Systems and Modern Solutions
Pedro Kiefer
Pedro Kiefer

Posted on

3

Hacking My Own AWS Account: A Tale of Legacy Systems and Modern Solutions

In the shadowy world of cloud security, sometimes you have to break things to fix them. That's exactly what happened when our enterprise-grade AWS infrastructure hit a critical authentication wall. The culprit? A legacy SAML provider that was holding our KMS keys hostage.

The company I work for has navigated the turbulent waters of AWS for nearly a decade. Over the years, we've transitioned from AWS user accounts (a security faux pas) to a sleek SSO solution, which was later migrated and integrated with a new identity provider and SSO solution. The journey wasn't without its challenges, and our engineering and security teams worked tirelessly to remove all user accounts — a story for another day. This week, however, we faced a new conundrum: a team discovered they couldn't use a KMS key critical to some of our data systems.

Despite the hiccup, our systems continued to hum along, thanks to a role that still had access to kms:GenerateDataKey, kms:Decrypt, and kms:Encrypt. No data was lost, and we could decrypt and use the data. However, the role lacked permission to update the key policy (kms:PutKeyPolicy), effectively locking us out from assigning other roles to the key.

In a stroke of luck, we found another role from our previous SSO solution with full permissions on the KMS key. This revelation came only after opening a support ticket with AWS. The role was created by AWS IAM Identity Center, and that comes with the down side that the trust policy cannot be updated. AWS IAM Identity role have the following format: arn:aws:iam::123456789012:role/aws-reserved/sso.amazonaws.com/AWSReservedSSO_profilename_somehexdigest and the trust policy looks like this:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::123456789012:saml-provider/AWSSSO_somehexrandomnumbers_DO_NOT_DELETE"
            },
            "Action": "sts:AssumeRoleWithSAML",
            "Condition": {
                "StringEquals": {
                    "SAML:aud": "https://signin.aws.amazon.com/saml"
                }
            }
        }
    ]
}
Enter fullscreen mode Exit fullscreen mode

Here's where it got interesting. The SAML provider was still there, pointing to a digital ghost — a server that no longer existed. Can we update that to another server that we can control? And the answer is yes, we can! We will hijack our own infrastructure by spinning up a new SAML provider. This is exactly the same technique used by black-hat hackers for gaining AWS persistence access on an account. You just need an IAM Role and a SAML Provider.

After a quick dive into the depths of the internet, we stumbled upon some straightforward, step-by-step guides on leveraging Keycloak, an open-source Identity and Access Management solution. This tool, running locally, would become the SAML provider we desperately needed.

This post laid out all the necessary steps for setting it up. We opted to run Keycloak inside a container, eliminating the need for extensive installation and configuration.

docker run -p 8080:8080 -e KC_BOOTSTRAP_ADMIN_USERNAME=admin -e KC_BOOTSTRAP_ADMIN_PASSWORD=admin quay.io/keycloak/keycloak:26.0.7 start-dev
Enter fullscreen mode Exit fullscreen mode

To log in to AWS, you need two specific SAML attributes, and it's crucial not to include any extraneous attributes that AWS can't process:

  • Session Name: This can be any random value, such as the username. The attribute name is https://aws.amazon.com/SAML/Attributes/RoleSessionName
  • Session Role: a list of roles that the user can assume. The attribute name is https://aws.amazon.com/SAML/Attributes/Role

The role must follow this format:

arn:aws:iam::<account-number>:role/<role-name>,arn:aws:iam::<account-number>:saml-provider/<provider-name>
Enter fullscreen mode Exit fullscreen mode

Once Keycloak was set up, the next step was updating the IAM Identity Provider to use the generated metadata file. The new Issuer URL was something like http://localhost:8080/realms/aws, and the SSO Service location was updated to http://localhost:8080/realms/aws/protocol/saml. Running inside Docker in development mode meant no SSL was configured, which was acceptable for initializing the SAML flow.

By accessing http://localhost:8080/realms/aws/protocol/saml/clients/keycloak-sso and authenticating with the user we had previously created, we were seamlessly redirected to the AWS console, assuming the role we had lost access to. With the regained access, it was a straightforward task to update the KMS Key policy, add the new principal, and remove outdated role references from the policy.

Key takeaways from this experience:

  • Maintain a concise list of IAM Identity Providers, including only the necessary SAML providers.
  • Restrict access to updating and creating new Identity Providers.
  • Monitor changes to SAML providers.

The team gained invaluable insights from the experience, understanding the tactics hackers employ and the simplicity of executing certain maneuvers. We are eager to explore further opportunities to ethically test our systems for deeper learning.

Image of Docusign

🛠️ Bring your solution into Docusign. Reach over 1.6M customers.

Docusign is now extensible. Overcome challenges with disconnected products and inaccessible data by bringing your solutions into Docusign and publishing to 1.6M customers in the App Center.

Learn more

Top comments (0)

Some comments may only be visible to logged-in visitors. Sign in to view all comments.

AWS Security LIVE!

Tune in for AWS Security LIVE!

Join AWS Security LIVE! for expert insights and actionable tips to protect your organization and keep security teams prepared.

Learn More

👋 Kindness is contagious

Discover a treasure trove of wisdom within this insightful piece, highly respected in the nurturing DEV Community enviroment. Developers, whether novice or expert, are encouraged to participate and add to our shared knowledge basin.

A simple "thank you" can illuminate someone's day. Express your appreciation in the comments section!

On DEV, sharing ideas smoothens our journey and strengthens our community ties. Learn something useful? Offering a quick thanks to the author is deeply appreciated.

Okay