Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Automated Security Analysis AWS Clouds

andresriancho
November 15, 2018

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

andresriancho

November 15, 2018
Tweet

More Decks by andresriancho

Other Decks in Programming

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