attack and defense in the public cloud by robert wood
TRANSCRIPT
A"ack and Defense in the Public Cloud
Robert Wood | @robertwood50
Agenda
• Introduc@ons • Shared responsibility considera@ons • A"ack and defend scenarios – Denial of service – Host takeover and pivo@ng – Data exfiltra@on – Creden@al theH
• Concluding remarks
Whoami
• Technical Manager @Cigital • Background in red teaming, forensics, pentes@ng, code reviews, and design reviews
• Heavily involved in assessing and helping design applica@ons built on public and private clouds
SHARED RESPONSIBILITY Considera@ons for a"ackers and defenders
Public Cloud Service Models
• Customers oHen@mes assume that opera@ng environment provided is secure
• Depending on the service model, this might dras@cally change
• Customers hand off and assume responsibility as they move from IaaS, to PaaS, to SaaS
Public Cloud Service Models
What Does This Mean?
A0ack • During a pentest we need
to understand where the limits are
• The service model dras@cally impacts the threat model and the types of relevant a"acks
• Might need addi@onal contracts and approvals in place
Defend • Understand where you fall
and what layers you need to manage and appropriately configure
• Map the service model back to any compliance requirements to make sure you’re not choosing the wrong model
DENIAL OF SERVICE
A"ack Descrip@on
• Tradi@onal a"ack leveraging system or network resource exhaus@on
• Bugs in underlying soHware or un-‐scalable architectures
Defender’s Perspec@ve
• Place controls at the DNS level and protect IP addresses – rotate if exposed (e.g. Cloudflare)
• Leverage the scalable features of the cloud – But configure appropriately to avoid unnecessary scaling causing addi@onal issues
– Layer scale detec@on • Make sure that other controls don’t add to the DoS problem (like ModSecurity WAF)
HOST TAKEOVER AND PIVOTING
A"ack Pa"ern
• Port scan • Fingerprint system • Iden@fy poten@al vulnerabili@es • Leverage tradi@onal exploit techniques • Steal creden@als and any other sensi@ve data • A"empt to pivot by repea@ng this process, looking for new visibility based on IAM roles and security groups for the host
A"acker’s Perspec@ve
• Look for vulnerabili@es in public images: – Dockerhub images – AMI backdoors – Default creden@als – Outdated soHware
• Exploit using known, exis@ng tools (e.g. Metasploit, Core, etc.)
Defender’s Perspec@ve
• Stay away from marketplace images or audit them heavily
• Harden all base images according to best prac@ces
• Apply roles that adhere to the principles of least privilege
• Consider layering with containers (e.g. Docker) – But remember to harden those too
• Use automated configura@on/infrastructure management to avoid driH and outliers
DATA EXFILTRATION
A"ack Pa"ern
• Iden@fy data stores – World accessible S3 buckets, Internet exposed database servers, etc.
• Compromise applica@on or host that has access to data store
• Connect to data store • Exfiltrate for the win
Defender’s Perspec@ve
• Restrict access to data stores via security groups and IAM
• Completely isolate data stores based on customers (e.g. different RDS or database servers) – Go further and segregate hosts from data storage zones
• Log all access and set up alerts
CREDENTIAL THEFT
A"ack Pa"ern
A"ack a system or phish a resource
Compromise creden@al
Authen@cate to system/service
Compromise local assets Pivot
SUBTITLE/BY LINE
Most Common AWS Creden@als
Type Usage Purpose
Sign-‐in creden@als Enter email address and password to access secure pages
Access AWS console.
User User AWS IAM API or creden@al
Authen@ca@on and authoriza@on for AWS management console and AWS creden@als
Access keys • Access key ID • Secret key ID
Access key ID iden@fies your AWS account Secret key ID is used to digitally sign the request
AWS SOAP and REST API requests
Key Pairs • Key pair name • Private key • Public key
The key pair name is specified when an instance is launched. The public-‐private key is used for SSH root access
Admin access to the running instance
What’s a Creden@al Here?
• What is a creden@al in the cloud? – API keys – Username and password – MFA tokens – SSH keys – Oauth/SSO tokens
• What do they protect? – Infrastructure management accounts – Systems and services – User accounts – Deployment processes
A"acker’s Perspec@ve
• Creden@als can be stolen in the old fashioned ways (some@mes…): – Phishing – Client-‐side takeover to get keys – Cross-‐site scrip@ng
Defender’s Perspec@ve
• Leverage two-‐factor authen@ca@on wherever possible
• Use layered accounts that follow the principles of least privilege (e.g. IAM)
• Refrain from using administra@ve accounts • Apply these principles to both cloud infrastructure management and applica@on components
• Log and alert on suspicious ac@vity (e.g. logging in from different countries)
CONCLUDING REMARKS
As an A"acker
• Many tradi@onal a"acks will s@ll work given the underlying infrastructure
• New a"ack surface creates new spins on old a"acks or some new a"acks en@rely
• Can leverage cloud services yourself for scalable, distributed a"acks
As a Defender
• Threat model early and oHen to understand your system’s design and applicable a"ack surface
• Embrace plaform provided security controls (e.g. IAM, S3 SSE, KMS, etc.)
• There are many third party services that provide seamless integra@on, evaluate the threat model and consider them – Controls in as many different loca@ons as possible
• Integra@on will depend on whether your app/infrastructure is grass fields or a migra@on
Understand Your Doomsday
• Repriori@zed by cloud – Malicious insider – Data in transit protec@on
– Management interface compromise
– Creden@al compromise – Infrastructure supply chain stability
– DDoS – against you or related clients
• Unique to cloud – Service provider termina@on
– Changes in jurisdic@on – Subpoena and e-‐discovery of another tenant
– Mul@-‐tenant isola@on of isola@on
