DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’»

DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’» is a community of 966,155 amazing developers

We're a place where coders share, stay up-to-date and grow their careers.

Create account Log in
Cover image for Is your AWS Account vulnerable to the newest attack presented at Black Hat 2021?
Johannes SpΓ€th for AWS Community Builders

Posted on • Updated on • Originally published at codeshield.io

Is your AWS Account vulnerable to the newest attack presented at Black Hat 2021?

Running confused deputy attacks exploiting the AWS Serverless Application Repository

Confused deputy attack on AWS

Early this month at Black Hat USA 2021, researchers from Wiz.io presented a new confused deputy attack that allows an attacker to access data within your AWS account. Using to coarsely set IAM permissions when publishing an application within the AWS Serverless Application Repository (SAR), an attacker can acquire arbitrary data from the S3 bucket that is used for hosting the application's artifacts. In this article, we explain the vulnerability, showcase an actual exploit and explain how to fix the vulnerability in your account. If you are publishing an application using SAR, we recommend double-checking your permissions.

SAR is a platform that allows developers to publish and share SAM applications across AWS accounts. These applications can then be deployed standalone or easily be integrated into existing SAM applications.

Publishing an application to SAR is straightforward. As an author, one has to pack the underlying application code, templates, license, and readme files in a S3 bucket, create an entry in the SAR and attach a policy to the bucket that grants SAR access to the bucket.

The S3 policy allows SAR to read all objects stored in the specified S3 bucket. In their documentation, AWS initially proposed to attach the following IAM policy to the bucket:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service":  "serverlessrepo.amazonaws.com"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::<your-bucket-name>/*",
        }
    ]
}
Enter fullscreen mode Exit fullscreen mode

What's the problem with this policy? It does not restrict the account on which's behalf SAR is allowed to access the bucket! While no account other than the owner of the SAR application can actually change the application's setup in SAR, every account can exploit SAR to query objects and data from an S3 bucket with such a BucketPolicy.

This allows attackers to extract sensitive data like source code, hardcoded credentials, or configuration files that were never meant to be accessible by others. Even worse, if the bucket is used for more than hosting the packed SAR application, which, by the way, is an antipattern itself, attackers can acquire this data too!


Exploiting the Vulnerability

To showcase the exploit, we prepared a SAR application setup of our Serverless-Goat-Java implementation. Serverless-Goat was originally developed in JavaScript by OWASP and is an intentionally vulnerable serverless application. We published Serverless-Goat-Java into the AWS SAR for security training purposes.

With the following template, we deploy an AWS CloudFormation stack with the required bucket and policy to host a SAR app:

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31

Resources:
  ServerlessGoatPackages:
      Type: AWS::S3::Bucket
      Properties:
        BucketName: "serverless-goat-packages"

  ServerlessGoatPackagesPolicy:
    Type: 'AWS::S3::BucketPolicy'
    Properties:
      Bucket: !Ref ServerlessGoatPackages
      PolicyDocument:
        Version: 2012-10-17
        Statement:
          - Sid: ServerlessRepoAccess
            Action:
              - 's3:GetObject'
            Effect: Allow
            Resource: !Sub "arn:aws:s3:::${ServerlessGoatPackages}/*"
            Principal: 
              Service: "serverlessrepo.amazonaws.com"

Enter fullscreen mode Exit fullscreen mode

Afterward, we pack our Serverless-Goat-Java application, upload it into the newly created bucket, and create a new SAR application in the SAR.

AWS Serverless Goat

As you can see, the application is bound to the account 028938425188 and can only be modified by it. Let's call the account hosting the vulnerable app Alice.

To test our exploit, we need another SAR application in a different account on which's behalf we can query objects from our ill-configured bucket. Let's call it account Eve. For the sake of ease, we just deployed Serverless-Goat-Java again, but to account Eve:

Serverless Goat Java deployed on Eve's Account

Let’s see how we can exploit it!

Now that our setup is complete, we can try to use SAR to query data from account Alice's bucket and set it as a configuration for account Eve's SAR app.

Therefore, we instruct SAR to set the Readme file of account Eve's app to an arbitrary file from account Alice:

Accessing an unintended file

Looking again at the app in the SAR, SAR displays the following Readme in account Eve's app:

The app shows the wrong file as Readme

Phew, we are evil! 😈 We just stole the authors license file! Let's try another one:

Console command to access sensitive data from S3

This time around, the acquired information is much more interesting:

Sensitive information leaded from S3 bucket

Of course, this is only dummy information for the sake of this demonstration. 😊

As you saw, the exploit is very easy once you know about it. The application's ID is public, only the bucket and file names have to be guessed by an attacker. This might sound hard to do!? Well, as we all know, security by obscurity doesn't work too well, so let's strive for a proper fix!


Fixing the Vulnerability

The fix is even more straightforward than the exploit! We need to make sure that our bucket used for hosting the SAR app is only accessible by the account that actually publishes the app.

Therefore, we have to modify our BucketPolicy to contain a condition that checks the AWS account which tries to instruct SAR to access the bucket:

  SampleBucketPolicy:
    Type: 'AWS::S3::BucketPolicy'
    Properties:
      Bucket: !Ref ServerlessGoatPackages
      PolicyDocument:
        Version: 2012-10-17
        Statement:
          - Sid: ServerlessRepoAccess
            Action:
              - 's3:GetObject'
            Effect: Allow
            Resource: !Sub "arn:aws:s3:::${ServerlessGoatPackages}/*"
            Principal:
              Service: "serverlessrepo.amazonaws.com"
            Condition:
              StringEquals:
                "aws:SourceAccount": "AWS::AccountId"

Enter fullscreen mode Exit fullscreen mode

Indeed, AWS added the new condition expression right after the vulnerability was disclosed to them and updated their documentation accordingly. However, owners of the SAR applications need to update their S3 bucket policies, otherwise the respective AWS accounts remaining vulnerable.

After re-deploying our stack with the fixed policy, we observe the following when trying the exploit again:

Fixing the vulnerability

Awesome! Now SAR can only modify account Alice's app on the behalf of account Alice! πŸ›‘

Note: We changed the policy back after showcasing the fix, so you can try the exploit yourself easily with our SAR application!


Fixing the vulnerability is one thing. But how to find it in the first place?

We develop CodeShield to help developers and security teams finding and
fixing vulnerabilities in cloud-native applications. CodeShield can also help you to find Buckets that are vulnerable to the depicted confused deputy attack in your CloudFormation stacks and template files. Check it out and try CodeShield yourself!

CodeShield's dashboard

Stay tuned if you are using Terraform or haven't set up your SAR buckets via a CloudFormation stack. We are currently extending CodeShield to be able to scan whole AWS accounts independently of stacks or templates. If you want to get notified when whole account scanning is ready, drop us a mail!


About the Authors

Manuel Benz is co-founder of CodeShield, a novel context-aware cloud security tool focusing on in-depth program analysis of microservice architectures. Prior to the start-up, Manuel worked as a researcher on combinations of static and dynamic program analysis for vulnerability detection at the Secure Software Engineering group at Paderborn University. Manuel is still actively maintaining the Soot static program analysis framework for Java.

Johannes SpΓ€th is an AWS Community Builder and a co-founder of CodeShield. Johannes completed his Ph.D. in static program analysis. In his dissertation, he invented a new algorithm for data-flow analysis which allows automated detection of security vulnerabilities.

Top comments (0)

🌚 Browsing with dark mode makes you a better developer by a factor of exactly 40.

It's a scientific fact.