This document discusses attack and defense considerations in the public cloud. It begins with an introduction of the speaker and an overview of shared responsibility models in the cloud. It then explores specific attack scenarios like denial of service attacks, host takeovers, data exfiltration, and credential theft. For each attack, it describes the attacker's perspective and techniques as well as recommendations for defenders. The goal is to help both attackers and defenders understand security challenges in the public cloud.

1. A"ack
and
Defense
in
the
Public
Cloud
Robert
Wood
|
@robertwood50

2. 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

3. 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

5. SHARED
RESPONSIBILITY
Considera@ons
for
a"ackers
and
defenders

6. 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

7. Public
Cloud
Service
Models

8. 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

9. DENIAL
OF
SERVICE

10. A"ack
Descrip@on
• Tradi@onal
a"ack
leveraging
system
or
network
resource
exhaus@on
• Bugs
in
underlying
soHware
or
un-­‐scalable
architectures

11. 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)

12. HOST
TAKEOVER
AND
PIVOTING

13. 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

14. 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.)

15. 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

16. DATA
EXFILTRATION

17. 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

18. 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

19. CREDENTIAL
THEFT

20. 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

21. 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

22. 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

23. 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

24. 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)

25. CONCLUDING
REMARKS

26. 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

27. 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

28. 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

29. Ques@ons?
Robert
Wood
|
@robertwood50
rwood@cigital.com