AWS Security

Staying on Top of the Cloud

Intro

• Kurtis Miller, a Principal Security Consultant for

• Previously:
• Global Security Engineering Manager for

• Senior Security Consultant for

• First Security Engineer for

• An IT Manager, IT Consultant, and security hobbyist.
• I am noperand on Twitter, GitHub, Freenode, and elsewhere.
Agenda

• Some AWS Fundamentals

• Tools, Code, and a Demo
• A Tale About Alice and Bob
Amazon Web Services (AWS)
• AWS or Amazon Web Services is a group of several
different cloud-based services designed for solving a variety
of problems.
• EC2 or Elastic Compute Cloud
• IAM or Identity and Access Management
• S3 or Simple Storage Service
• There are many other AWS services, much more functionality
and much, much more complexity, but this simple list covers
enough common fails.
Amazon Elastic Compute Cloud (EC2)
• Provides virtual environments to host your
applications.
• Provides a slew of templates or Amazon Machine
Images (AMIs) you can choose from or build and
your own.
• Flexible storage options.
• Can be public or private, leveraging public IP
addresses or a Virtual Private Cloud (VPC).
• Firewall support through Security Groups.
Amazon Simple Storage Service (S3)

• Create buckets to organize your data.

• Throw objects (files) into the buckets.
• Assign permissions to buckets and/or individual
objects (can be tricky).
• All available through a RESTful API.
• Supports features like versioning and Reduced
Redundancy Storage (RRS).
Amazon Identity and Access Management (IAM)

• Centrally create users and issue key pairs for

API-level access.
• Configure policy and access control for all AWS
services.
• Enable Multi-Factor Authentication (MFA).
• Offers an API, just like all other services.
• Also offers an interactive console.
Approach for … Most?
• “Move fast and break things.”
• Developers get access and are let loose to “innovate”!
• This often includes agitating the security team, if you have one.
• Secrets and credential management? Relatively nil if done at all.
• In many cases, it comes down to "What's the bill this month?" and
proceeds from there.
• Many organizations centralize their cloud infrastructure in AWS to
consolidate billing (and risk).
• There be dragons.
There has to be a better way!
• Utopian case? Observe best practice, establish some kind of policy
and enforce it.
• Leverage tools/automation to tell you when things aren't right and
deal with it.
• Assess on a regular schedule to identify security relevant changes.
• Visualize what is going on for quicker response.
• Improve overall situational awareness around use of AWS.
Tools

• truffleHog
• https://github.com/dxa4481/truffleHog
• AWS-Recipes
• https://github.com/nccgroup/AWS-recipes
• Scout2
• https://github.com/nccgroup/Scout2
• ...and custom code!
truffleHog
• Goal is to find high-entropy strings that might be used for
authentication or crypto.
• Helps to locate things that developers should not be putting
into version control.
• Goes through Git repositories including all commits and
branches to find high entropy strings.
• Great for finding AWS secret keys and finding some other
interesting strings.
• Enables covering a lot of ground very quickly.
• Mostly false positives, unfortunately.
• Absolutely requires a human to operate, every time.
• Your mileage may vary.
truffleHog Examples
AWS-Recipes

• Provides a number of IAM policies and Python-based

tools to help with management and maintenance of an
AWS environment.
• Automates and abstracts user deletion, MFA
enablement, and key rotation, among other things.
• Single dependency on opinel, a core Python module
that is also used by Scout2.
AWS-Recipes
Scout2

• Configure a read-only IAM profile. This can be found in the

AWS-Recipies GitHub repo.
• https://github.com/nccgroup/AWS-
recipes/blob/master/IAM-Policies/Scout2-Default.json
• Pulls configuration of all AWS services and evaluates the
configuration using rules and a rule engine implemented
Python.
• Produces JavaScript that assigns the results to a JSON
object.
• Front-end code represents these results in some colorful
ways.
Scout2
Scout2
What We Often See
• Lack of Multi-Factor Authentication (MFA).
• Security Groups allowing all inbound traffic to EC2
instances.
• IAM policies allowing free assumption and passing of roles
facilitating elevation of privilege.
• Lack of access key rotation.
• Poor password policies configured in IAM.
• S3 buckets that are accessible by all authenticated AWS
users (even outside your organization).
Expanding Upon Scout2
• Scout2 gathers up your AWS configuration information and
provides an attack surface report.
• This is represented by the EC2 instances that you currently
have deployed and your configured Security Groups.
• What if we produced host and service discovery shell scripts
based on this information? It would certainly prevent us from
scanning things we shouldn’t, from an IP address and port
standpoint.
Expanding Upon Scout2
Expanding Upon Scout2
Expanding Upon Scout2
• Scout2 only represents data from a single AWS account.
• What if you have multiple AWS contexts or products hosted
in Scout2?
• What methods are available to represent additional contexts,
in the same view, to quickly identify areas that need
attention?

• What about carving up the data from Scout2, merging it and

using D3.js to visually represent it?
Expanding Upon Scout2

DEMO
Yeah! Everything is Great!

• You frequently assess and monitor your AWS

configurations.
• You enforce corporate policies within AWS and
hold resource owners accountable.
• You regularly pentest the applications you have
exposed in AWS.
• You regularly hunt for secrets being persisted in
version control.
Yeah! Everything is Great!

All of this is still not enough.

It’s time for a story.

An AWS Horror Story
• Some suspicious activity was identified in logs.
• We investigate, establish confirmed IOCs, burn all creds in
assessed scope of compromise, and rotate access keys.
• Patient zero was derived simply from our timeline (being first) with
no strong links to the others that were compromised.
• Rip apart laptops for malware, interview multiple users, etc.
• We start incrementally creeping back to BAU.
• Continue the hunt for malicious activity with available IOCs.

All was calm, until...

An AWS Horror Story

• More hits on some glaring IOCs, after scorched creds.

• The attacker is taunting us. We haven't found their way in yet.
• After several more hours of staring at data and a whiteboard, we
trace events and creds to a common thread.
The Tale of Alice and Bob

• Bob's keys got burned as part of our response.

• Bob needs to get new keys from Alice.
• Alice generates a new key pair for Bob.

Can I get
new keys?

Sure thing!
The Tale of Alice and Bob
• Alice sends the new keys to Bob as a Secure Message,
using Solution.
• According to Solution, only Alice and Bob have
permission to view the Secure Message.
• Alice views the Secure Message once, after submission.

Confirmed.
All set!
The Tale of Alice and Bob

• Bob never views the Secure Message.

• Eve uses Bob's new keys.
Eve is Sly

• Compromised endpoints/users? No signs of

malware or other access.
• Various users, no indicators of an insider making
moves.
• Majority of compromised credentials were shared
the same way, through Solution.
Bob's Your Uncle!!! No, wait...

• Turns out, Maker was logging all API interactions in

Solution, including the content of Secure Messages.
• Third-party logging provider used by Maker made their
logs accessible directly over the Internet through a nice
web UI.
• Third-party logging web interface account was
compromised through a common password (a la
password DB leaks; think LinkedIn, RockYou, etc).
• All initial points of compromise could be traced to
Secret Messages in Maker Solution.
 Bob's Your Uncle!!! No, wait...

The initial (and persistent) compromise was

completely outside of our environment and
thus,

OUTSIDE OF OUR CONTROL.

We still managed to work with Maker to improve Solution and

get a good handle on the situation.
Ugh, Is There a Moral Here?!
• While you strive to do right you will be wronged.
• Stay on top of your infrastructure, holding vendors and third-
parties accountable.
• Go through the exercise of asking for detailed logs from
vendors.
• Especially for communication systems your users trust.
• What you may, or may not find, might astound you.

• Leverage the tools and techniques we’ve described to stay

on top of how AWS is being used in your environment.
• Extend your corporate policies to AWS usage and enforce
those policies.
Questions?
North America Europe Australia
Atlanta Manchester - Head Office Sydney
Austin Amsterdam

Chicago Cheltenham
Copenhagen
New York
Edinburgh
San Francisco
Glasgow
Seattle
Leatherhead
Sunnyvale
London
Luxembourg
Milton Keynes
Munich
Zurich