Automated Security Analysis AWS Clouds

* Cloud security assessment
* Most common vulnerabilities in AWS accounts, and how to prevent them:
* Open S3 buckets
* Secrets in EC2 user-data
* IAM privilege escalation
* Security Groups: Least Privilege
* Open source tools
* Closing thoughts

Transcript

1. Automated Security Analysis
   AWS Clouds
   AppSec BA
   Buenos Aires, Argentina
   Diciembre 2018
   

   View Slide

2. /me
   ● Application and cloud security expert
   ● developer
   ● Open source evangelist
   ● w3af project leader
   ● Independent security consultant
   

   View Slide

3. Agenda
   ● Cloud security assessment
   ● Most common vulnerabilities in AWS accounts, and how to
   prevent them:
   ○ Open S3 buckets
   ○ Secrets in EC2 user-data
   ○ IAM privilege escalation
   ○ Security Groups: Least Privilege
   ● Open source tools
   ● Closing thoughts
   

   View Slide

4. Cloud Security Assessment
   Definition and experience
   

   View Slide

5. Cloud Security Assessment: Query the APIs
   Since this terminology is new for most professionals, let's take a
   minute to define what a cloud security assessment is:
   Identify vulnerabilities and bad practices by
   querying the AWS API
   Keep in mind that these assessments won't identify vulnerabilities
   at the application level (e.g. SQL injections), or vulnerabilities at
   the infrastructure level (e.g. root user with guessable credentials).
   

   View Slide

6. Scan using open source tools
   Most cloud security assessments are performed using manual
   configuration review and open source tools such as:
   ● https://github.com/nccgroup/Scout2
   ● https://github.com/duo-labs/cloudmapper
   ● https://github.com/RhinoSecurityLabs/pacu
   ● https://github.com/toniblyx/prowler
   ● https://github.com/cloudsploit/scans
   And custom scripts, usually written in Python with the boto library, to
   extract information related with AWS services not supported by those
   tools.
   

   View Slide

7. Massive AWS cloud!
   A few months ago I was hired to perform a cloud security
   assessment on a massive AWS account:
   ● 500k USD / month billing
   ● 2500 EC2 instances
   ● 200 RDS instances
   ● 2000 IAM users and roles
   ● 250 IAM groups
   ● 500 security groups
   And a really long list of experiments with almost all AWS services.
   

   View Slide

8. Automate, automate, automate
   ● In most assessments I manually review each resource,
   configuration, policy and source code line. In this case,
   because of the large number or resources and the limited
   time, it was impossible to do that.
   ● Automated the assessment as much as possible
   ● But… what was I looking for?
   

   View Slide

9. AWS cloud vulnerabilities
   Most common and high risk
   

   View Slide

10. 4 out of 400
    There are ~400 known vulnerabilities which can affect an
    AWS account, this talk only covers 4 of them.
    

    View Slide

11. FedEx data leak via open S3 bucket
    

    View Slide

12. Medical Records leaked via S3 bucket
    

    View Slide

13. Open bucket with sensitive information
    S3 is one of the most commonly used and misconfigured services.
    The vulnerability is simple to understand: the developer
    configures an S3 bucket to be accessible by any anonymous
    user, and then uses it to store sensitive information.
    An attacker will eventually find this bucket and access all the
    sensitive information.
    Note: In some cases, such as storing public JS and CSS files for
    your site, it is fine to have open S3 buckets.
    

    View Slide

14. Secrets in EC2 user-data
    EC2 user-data is run when the instance starts and is commonly
    used to configure the server with a bash script.
    This script might contain credentials to connect to other services,
    such as RDS databases, S3 buckets or REST APIs provided by
    third-parties.
    aws ec2 run-instances --image-id ami-abcd1234
    --user-data file://script.sh
    ...
    

    View Slide

15. Secrets in EC2 user-data
    An attacker with access to AWS account credentials with
    permissions to run ec2:DescribeInstanceAttribute will be able to
    retrieve the user-data scripts.
    After downloading all the scripts the attacker extracts the
    hard-coded credentials and uses them to pivot and escalate
    privileges in the target AWS account.
    

    View Slide

16. Preventing secrets in user-data
    AWS' Secrets Manager can be used to store and retrieve application secrets. In order to consume the
    secrets manager service, EC2 instances must have an attached IAM role with permissions to read their
    secrets:
    $ aws secretsmanager get-secret-value --secret-id talks/AndresSecret ...
    {
    "ARN": "arn:aws:...",
    "Name": "talks/AndresSecret",
    "SecretString": "i-love-empanadas",
    ...
    }
    ProTip: For increased security use a resource based policy to limit the source VPC which can access
    each secret. This will prevent leaked credentials from being used to read secrets.
    

    View Slide

17. IAM privilege escalation
    AWS users, roles and groups have
    associated IAM policies which
    describe which AWS APIs can be
    consumed.
    This example policy allows the
    associated principal to start and stop
    instances which are tagged with his
    username.
    {
    "Version": "2012-10-17",
    "Statement": [
    {
    "Effect": "Allow",
    "Action": [
    "ec2:StartInstances",
    "ec2:StopInstances"
    ],
    "Resource": "arn:aws:ec2:*:*:instance/*",
    "Condition": {
    "StringEquals": {
    "ec2:ResourceTag/Owner": "${aws:username}"
    }
    }
    }
    ]
    }
    

    View Slide

18. IAM privilege escalation
    An attacker with access to AWS
    account credentials with permissions
    to run the iam:PassRole and
    ec2:RunInstances actions can create a
    new EC2 instance and associate an
    arbitrary role with high privileges to it.
    The attacker then connects to the new
    instance using SSH and requests the
    AWS access keys from the EC2
    instance metadata.
    {
    "Version": "2012-10-17",
    "Statement": [
    {
    "Effect": "Allow",
    "Action": [
    "iam:PassRole",
    "ec2:RunInstances"
    ],
    "Resource": "*"
    }
    ]
    }
    

    View Slide

19. IAM privilege escalation
    There are around 20 known IAM privilege escalation techniques,
    most of them allow a user with the right privileges to gain full AWS
    account access, others allow the user to escalate privileges to
    specific roles.
    Other privilege escalation techniques worth mentioning:
    ● Passing a role to a new Lambda function, then invoking it
    ● Updating the code of an existing Lambda function that runs
    with a privileged role
    

    View Slide

20. Preventing IAM privilege escalation
    Preventing IAM privilege escalation is simple in theory but complex to
    do at scale:
    1. Use the least privilege principle for all users, roles and groups
    2. Review the policies to make sure no role can escalate privileges
    using known techniques (fancy name for a set of IAM privileges)
    3. Prevent exploitation by reducing user's permissions. For example,
    if a user requires iam:PassRole restrict the action to be allowed
    only on specific roles.
    Use tools such as Scout2 and CloudMapper to identify potential issues
    and manually confirm them.
    

    View Slide

21. Open Security Groups
    Security groups protect EC2, RDS and other important
    services at the network level: think "cloud firewall". They
    are used to configure which source IP addresses can
    connect to a service.
    Open security groups allow an attacker that gained
    access to an EC2 instance to pivot inside the company
    VPC.
    Open security groups generate poorly or non-segmented
    networks.
    

    View Slide

22. Feel the pain
    Source Action
    10.1.2.3/32 Allow
    10.1.5.42/32 Allow
    10.1.1.25/32 Allow
    10.1.0.0/16 Allow
    When performing a security assessment I try to
    understand why things are done in a particular way. Can
    you guess what happen with this DB security group?
    

    View Slide

23. Open Security Groups
    Recommendations to prevent open security groups:
    ● Always use security groups as source in SG rules
    ● Never use IP address ranges (public or private) as
    source
    Source Action
    the-app-sg Allow
    

    View Slide

24. Open Source tools
    Features and pain points
    

    View Slide

25. Open S3 buckets
    Secrets in EC2 user-data
    IAM privilege escalation
    Open Security Groups
    Scout2: The good
    ● Focus on automated cloud security scanning
    ● Queries the AWS account and downloads all the
    necessary information to a JSON file. Then
    applies rules to the local database to identify
    vulnerabilities.
    ● Generates HTML report
    ● Good vulnerability coverage
    

    View Slide

26. Open S3 buckets
    Secrets in EC2 user-data
    IAM privilege escalation
    Open Security Groups
    Scout2: The bad
    ● Only identifies a subset of the potential IAM
    privilege escalation vulnerabilities. As with other
    fields, running multiple tools will improve
    coverage and yield better results.
    ● Takes considerable time to run (~3 hours for
    large AWS accounts)
    ● Provides no description for the identified
    vulnerabilities
    

    View Slide

27. Open S3 buckets
    Secrets in EC2 user-data
    IAM privilege escalation
    Open Security Groups
    Scout2: The ugly
    ● JSON file can be large (600mb). This file is loaded
    into the browser memory to show the HTML
    report, which made all browsers crash.
    Had to run the tool again, limiting the services to
    check in order to generate smaller reports which
    would fit in browser's memory.
    ● Found important improvements in the first 10
    minutes
    

    View Slide

28. Open S3 buckets
    Secrets in EC2 user-data
    IAM privilege escalation
    Open Security Groups
    Prowler: The good
    ● Focus on automated cloud security scanning
    ● Good vulnerability coverage
    ● Identifies a different vulnerability set than
    Scout2 (with considerable overlap). ProTip: Run
    both tools and merge results to get higher
    vulnerability coverage.
    

    View Slide

29. Open S3 buckets
    Secrets in EC2 user-data
    IAM privilege escalation
    Open Security Groups
    Prowler: The bad
    ● Output is written to text file or console. Difficult
    to extract the information in a programmatic
    way.
    ● Written in bash, took 12h to run on the target
    AWS account.
    ● Provides no description for the identified
    vulnerabilities
    ● Found crash in the first 5 minutes
    ● Found important improvements in the first 10
    minutes
    

    View Slide

30. Open S3 buckets
    Secrets in EC2 user-data
    IAM privilege escalation
    Open Security Groups
    Pacu: The good
    ● Focus on cloud exploitation
    ● The user selects and runs specific modules to
    exploit vulnerabilities.
    ● There are modules for downloading the
    user-data for all instances and for identifying
    privilege escalation issues.
    

    View Slide

31. Open S3 buckets
    Secrets in EC2 user-data
    IAM privilege escalation
    Open Security Groups
    Pacu: The bad
    ● The security expert needs to manually review
    the user-data scripts to identify any hard-coded
    credentials
    

    View Slide

32. Open S3 buckets
    Secrets in EC2 user-data
    IAM privilege escalation
    Open Security Groups
    CloudMapper: The good
    ● Focus on manual cloud security analysis
    ● The user runs specific commands to extract
    AWS account information and identify
    vulnerabilities.
    ● Implements wot (web of trust) command which
    enumerates all the permissions granted to other
    AWS accounts.
    

    View Slide

33. Open S3 buckets
    Secrets in EC2 user-data
    IAM privilege escalation
    Open Security Groups
    CloudMapper: The bad
    ● Very poor vulnerability coverage: 10 / 400
    

    View Slide

34. Closing thoughts
    

    View Slide

35. Expert required
    ● Cloud security scanners are giving their first steps, they don't have
    full vulnerability coverage, it is common to crash the scanner, and
    require considerable time to run.
    ● Severity ratings associated with some vulnerabilities are
    completely incorrect and might lead to incorrect prioritization by
    AWS admins.
    ● The scanner output often includes only the vulnerability title,
    affected resources, and nothing else.
    ● Multiple tools and custom scripts need to be run to extract and
    merge all the vulnerability information.
    

    View Slide

36. Attackers are coming
    ● Your AWS account will be attacked, it is just a matter of time. It will
    happen in the next 2 minutes, days or years… but eventually… it
    will happen.
    ● Perform periodic cloud security assessments to identify
    vulnerabilities and reduce risk.
    

    View Slide

37. Call to action
    Do this now
    

    View Slide

38. Run Trusted Advisor
    ● Trusted advisor is a free AWS service which allows users to identify
    security vulnerabilities in AWS accounts.
    ● The vulnerability coverage is very low, but it's a good first step
    towards improving the security of your AWS account.
    

    View Slide

39. Thanks!
    

    View Slide

40. For hire
    Does your company or startup need these services?
    ● Application Penetration Test
    ● Secure Coding Training for Developers
    ● Source Code Review
    ● Cloud Security Assessment
    Let me know, I can help you deliver secure web applications.
    

    View Slide