practical steps to hack proofing aws

AWS Government, Education, and Nonprofit Symposium Washington, DC I June 25-26, 2015


Practical Steps to Hack Proofing AWS

Aaron Newman

CTO - CloudCheckr

©2015, Amazon Web Services, Inc. or its affiliates. All rights reserved.


Changing Your Perspective• How do I secure my business applications in AWS?

• Moving to the cloud = Rethinking your perimeter security

• Rethinking how you perform most security tasks:

– Network-based IPS/IDS

– Network scanning

– Penetration tests

– Vulnerability assessments


In the Data Center• Setting Up Perimeter Security:

• Set up your infrastructure• Set up access points to the internet• Configure firewall, IDS, IPS, etc., at the access points

• Auditing Your Perimeter Security:

• Gather set of IP address blocks to poke at• Do a port scan (using tools such as Nmap) • Determine which ports are open on the target • Try various exploits on the open ports• Sniff lots of packets• Dig around to make sure there are no back doors into the network

• Wireless access points, secondary T1 lines, DSL connections• VPN access from some other network


AWS: What’s Different?• Physical assets secured

– At the AWS Availability Zone (AZ)

• But we still need to guard the AWS API– AWS Identity and Access Management (IAM) is your new

physical securityThe idea of physical security morphs as infrastructure becomes

virtualized by AWS APIs. In a new world of ephemeral, auto-scaling infrastructure, you need to adapt your security architecture

to meet both compliance and security threats.


Minimizing Attack Vectors• Principles don’t change

• Reduce your surface area!• Defense-in-depth

• Some attack vectors don’t change• Application level (user privilege escalation, web app vulnerabilities, XSS)• Operating system vulnerabilities• Database vulnerabilities

• Some attack vectors change• Homogeneous environment• Polymorphic targets/mapping• Reduced network sniffing


Perimeter Assessments in the Cloud

• How do I assess the perimeter of my cloud?

• Old world – Nmap, port scans, ping sweeps, etc., …• Give me your network block

• New world – let me see your configuration• List of publicly accessible resources• Security groups (EC2-Classic, EC2-VPC, Amazon Redshift, Amazon RDS, etc., …)• Routing tables, network ACL• Amazon VPC, subnets • S3 buckets and permissions• AWS Identity and Access Management (IAM) policies


Rules For Running Pen Tests on AWS

http://aws.amazon.com/security/penetration-testing/• “…complete and submit the AWS Vulnerability/Penetration Testing Request Form to request authorization for

penetration testing or scanning of your resources”

• CaveatsAt this time, our policy does not permit testing m1.small or t1.micro instance types. This is to prevent potential adverse performance impacts on the resources you may be sharing with other customers in a multi-tenant environment.

• Demo https://portal.aws.amazon.com/gp/aws/html-forms-controller/contactus/AWSSecurityPenTestRequest

• Need to know– IP addresses to be scanned (destination)– Instance IDs– Scanning IP addresses (source)

http://aws.amazon.com/security/penetration-testing/


What Else Do We Need to Cover?• Amazon EC2 is not our only attack surface

• AWS is a robust, complex platform with many moving parts

• Over 30 different services• Many have unique access control systems

• Some companies have hundreds of AWS accounts

• We need a complete inventory• All publicly accessible endpoints and resources

Hackers find the single weak link


Amazon EC2-Classic• EC2-Classic is available only in old accounts

• Prevalent for early adopters, pre-VPC era

• Each EC2 instance• Has a public IP address and a public DNS name• Has a private IP address and a private DNS name• Can have an Elastic IP address

• Only security is EC2-Classic security groups

• Treat each as a target with its own security risk


Amazon EC2-VPC• Default VPC is created in every region

• VPCs are wide open by default• VPC is composed of:

• Internet and VPN gateways • Connect to the rest of the world

• 1+ subnet(s)• Routing tables – how to move traffic around the VPC• Network ACLs – a firewall, but stateless• Security groups – host-based firewall, stateful• Resources – EC2, RDS, Amazon Redshift, Amazon ElastiCache


Amazon S3 • Up to 100 buckets in an account

• Unlimited number of objects (billions is not uncommon)

• Location• Within a region, across multiple AZs, not housed in a VPC• Can’t sit between client and storage

• Security• Access control thru IAM policies, bucket policies, ACLs, and query string authentication• Server-side encryption, HTTPS support• Server-access logs (does not integrate with AWS CloudTrail)

• Don’t grant FULL_CONTROL, WRITE_ACP, WRITE permissions to Everyone EVER!!!

• Inventory your sensitive data


Amazon RDS• Location

• Within a VPC or not, multi-AZ or not

• Security options• DB security groups (if not in a VPC) or EC2-VPC security groups• Select a non-default database port

• Publicly Accessible option • Not a good idea, but if you do this:

• Make sure you use security groups to restrict source IP address• Make sure you have latest patches applied

• Secure your database snapshots• Keys to the kingdom if someone can get a copy• Brute-force passwords, restore to their own account


Amazon SQS • Where does Amazon SQS live?

• Within a region, not within a VPC• Uses a URL such as https://sqs.us-east-1.amazonaws.com/123456789012/MySQS

• Security based on policy documents:{

"Version": "2008-10-17",

"Id": "arn:aws:sqs:us-east-1:123456789012:MySQS/SQSDefaultPolicy",

"Statement": [

{

"Sid": "Sid1415217272568",

"Effect": "Allow", "Principal": { "AWS": "*" },

"Action": [

"SQS:ReceiveMessage", "SQS:SendMessage"

],

"Resource": "arn:aws:sqs:us-east-1:123456789012:MySQS"

},


Amazon SNS• Amazon SNS does not live inside your VPC• Permissions based on topic policies:


Internal vs. External Threats• Understanding who the threat is

• Internal threats• Disgruntled or malicious DevOps

• External threats• Hacker groups, script kiddies• E.g., Anonymous

Each requires different controls and monitoring


Using AWS CloudTrail• An AWS service that records each time the AWS API is called

• Currently supports 20+ AWS services • http://docs.aws.amazon.com/awscloudtrail/latest/userguide/dochistory.html

• Everything in AWS goes through the API• Even actions in the AWS Management Console go through the API

• CloudTrail writes files into an S3 bucket• Near real time (every five minutes)• Files are in JSON format

Get started at http://aws.amazon.com/cloudtrail/


Example: Code Spaces• How not to end up like Code Spaces

• This is their website now

• Code Spaces hacked• No disaster recovery• No “offsite” backups

• “Code Spaces: A Lesson In Cloud Backup”Source: http://www.networkcomputing.com/cloud-infrastructure/code-spaces-a-lesson-in-cloud-backup/a/d-id/1279116


Tools for Securing AWS• Generic tools fall short• Purpose-built, not cloud-washed

• Make sure tools don’t fall over in the cloud• Tools have to understand dynamic, ephemeral IPs

• Need a deep understanding of AWS• What does this mean?• Context is important• Actionable intelligence


Questions?• AWS security• CloudCheckr


For More Information About CloudCheckr

Sign up today for free evaluationat http://cloudcheckr.com

Aaron Newman is the Founder and CTO of CloudCheckr (www.cloudcheckr.com)

Please contact me with additional questions at:[email protected]

http://www.cloudcheckr.com/

mailto:[email protected]


Thank You.This presentation will be loaded to SlideShare the week following the Symposium.

http://www.slideshare.net/AmazonWebServices


practical steps to hack proofing aws

Technology

aws government

aws api aws identity

aws http

aws apis

nonprofit symposium

permissions aws identity

aws availability zone

perimeter security rethinking