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"
                }
            }
        }
    ]
}

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

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>

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.

Comments

[Kurt Cheng]

FOR CRYPTOCURRENCY RECOVERY, CONTACT TSUTOMU SHIMOMURA

This is the best crypto recovery company I've come across, and I'm here to tell you about it. TSUTOMU SHIMOMURA HACKER was able to 5:15 PM 30/10/2024 REGHWGHBHH recover my crypto cash from my crypto investment platform's locked account. TSUTOMU SHIMOMURA HACKER just needed 24HRS to restore the $620,000 I had lost in cryptocurrencies. I sincerely appreciate their assistance and competent service. TSUTOMU SHIMOMURA HACKER may be relied on since they are dependable and trustworthy. you can also contact them via Email: [e-mail] or WhatsApp via: [phone], or Telegram @TsutomuShimomurahacker, and I’m sure you will be happy you did.