There is a lack of tools for testing the security of Cloud deployments; the Cumulus Toolkit is an attack framework for exploiting the Cloud's weak points.
The Cloud enables software projects to speed up development because it allows developers to provision infrastructure and make configuration changes to their networks without much friction. This ease of deployment was but a dream in the age of the traditional datacenter. However, the Cloud also brings new attack surface which needs further exploration. Cloud Identity and Access Management (IAM) services (such as Amazon's) are primary targets for attackers, as these typically control access to hundreds of API calls over many services.
Over the years there have been various discussions around cloud security, e.g., Pivoting in Amazon Clouds (2013), and few tools have been developed to enable testing the security of Cloud deployments. These tools are standalone, have not attained wide adoption, and/or have not made it into widely adopted toolkits. To fill this void, we have developed the Cumulus Toolkit. The Cumulus Toolkit is a Cloud exploitation toolkit based on the Metasploit Framework. We chose Metasploit because of its wide adoption and its wealth of existing features.
The Cumulus toolkit is a set of modules that can be used perform privilege escalation, account takeover, and to launch unauthorized workloads. To illustrate security concerns resulting from lax IAM policies, we present the Create IAM User module which can be used to create a user with administrative privileges. To perform complete account takeover, an attack that we've seen in the wild, we present the User Locker module which is used to lock out all legitimate users out of the account. Finally, we present the Launch Instances module which can be used to launch Cloud hosts on demand.
Transaction Management in Database Management System
Blackhat Arsenal 2017 - The Cumulus Toolkit
1. CUMULUS - A CLOUD EXPLOITATION
TOOLKIT
Javier Godinez
2. CUMULUS
2
A Cloud Exploitation Toolkit
• Collection of Metasploit modules
• Creating IAM users
• Launching workloads
• Locking users out
• Techniques for getting a foothold and pivoting in the Cloud
• Currently only supports AWS
5. CREATE IAM USER MODULE
5
• Allows for the creation of a user
with Admin Privileges to the AWS
account
• Needs access to AWS Access Keys
or Instance Role with:
• iam:CreateUser
• iam:CreateGroup
• iam:PutGroupPolicy
• iam:AddUserToGroup
• iam:CreateAccessKey
6. LAUNCH INSTANCES MODULE
6
• Auto detects configuration for
launching EC2 instances
• Can launch one or multiple
instances
• Can execute setup scripts
7. LOCKOUT USERS MODULE
7
• Requires an IAM admin role (created
by previous module)
• Enumerates all users and access keys
• Accepts a user to keep
• Locks out all other accounts
8. DISCLAIMER
8
• This is not an Amazon Web Services issue
• This is a DevOps education issue
• It is the user’s responsibility to understand the technology being used
• With power user privileges comes great responsibilities
15. REFERENCES
15
• Cumulus - A Cloud Exploitation Toolkit
https://drive.google.com/file/d/0B2Ka7F_6TetSNFdfbkI1cnJHUTQ
• See cumulus branch: https://github.com/godinezj/metasploit-framework
16. HOW APPLY THIS KNOWLEDGE
16
• Read the AWS IAM Best Practices Documents:
• http://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html
• Monitor IAM actions using AWS CloudTrail
• Audit your AWS Account IAM Policies and Roles
• Red Team your applications and instances: https://www.metasploit.com
• Think to yourself: “How would an attacker use this against me?”
• Use repeatable secure patterns: https://github.com/devsecops
• Help build awareness through community: http://www.devsecops.org
19. UNDERSTANDING THE TECHNOLOGY YOU
USE
19
• How fast can I move while still staying safe?
• Always develop in separate account (Blast Radius Containment)
• Read the docs for everything and make conscious choices
• Attackers will try to leverage everything against you
• Bleeding edge does not mean stable and secure. However, it can be with enough
testing
20. INSTANCE
20
• Virtual host
• Virtual environment on Xen hypervisor
• Feels very much like a host running on bare metal
21. METADATA SERVICE
21
• Internal HTTP service that provides Instances information about its environemt
• Available from host at http://169.254.169.254/
• Also provides temporary credentials to host
22. INSTANCE PROFILE
22
• AWS construct that maps a
role to an instance
• Instance may or may not
have a profile associated with
it Instance
28. EC2 INSTANCE METADATA
28
• Retrieves information from
metadata service
• Includes API credentials
• Account information
• Regional information
Hinweis der Redaktion
Work for Intuit and presenting under devsecops.org where I am a founding member.
The Cumulus toolkit is the culmination of some of my research and actual events l’ve seen during the last couple years while operating in the public Cloud.
It is my attempt at automating and helping the RedTeam at Intuit move faster.
The cumulus toolkit is not only a set of Metasploit modules, but also a set of techniques that we use to get a foothold in the Cloud.
When it comes to penetrating and escalating privileges the Cloud, the first thing you need is a foothold.
There are many ways to do this and we will go through several techniques during the demo.
The first module we will be going through is the CIAMU module, it is a post exploitation module which can be used to create IAM users in an account where you have a foothold.
Given that the instance you are attacking has an over privileged role attached to it.
The Launch instances module as the name implies can be used to launch instances.
At times we have limited privileges, but have the capability to launch instances with higher privileges that we currently posses.
So we can use this module to perform privilege escalation as well as to launch unauthorized workloads in the Cloud.
The lockout users module is by far the most evil module.
It can be used to lock other users out of an account.
Because at times we may need to prove that we have complete control over an account.
As a disclaimer, this is not an AWS issue it is a devops education issue because AWS and other Cloud providers give you all the necessary controls to protect your infrastructure.
Having a technical grasp of how the technologies you leverage is imperative.
Jumping in with both feet and no plan is not a good move to make
Reading the API documents and best practices documents can get you on the right path
We got to where we are now by really digging in and looking at how AWS Identity and Access Management policies work and how they can be abused through the lens of an attacker
This is a very quick overview of AWS IAM.
Our intention is not to show you the best practices but give you enough information to understand the rest of the story
AWS IAM can be extremely complicated if not understood in context and set up with clear and crisp plans
Allows for very granular control over access to specific parts of the AWS API
These are essentially the keys to the kingdom and can be both used and abused
Users can be added and removed from an account
Users can be added to groups
Roles can be assigned to groups, users and roles
Policies can be attached to groups
From our perspective there are three types of IAM policies: