CSE543 Computer and Network Security Module: Cloud Computing

(1)

3YSTEMS )NFRASTRUCTURE

I

.ETWORK

$EPARTMENT 0ENNSYLVANIA

Systems and Internet Infrastructure Security Laboratory (SIIS) Page

CSE543 Computer and Network Security

Module: Cloud Computing

Professor Trent Jaeger

1

(2)

Systems and Internet Infrastructure Security (SIIS) Laboratory Page

Cloud Computing Is Here

2

(3)

Cloud Computing Is Here

2

(4)

Cloud Computing Is Here

2

(5)

Cloud Computing Is Here

2

(6)

Cloud Computing Is Here

2

(7)

Cloud Computing Is Here

2

(8)

Cloud Computing Is Here

2

(9)

Cloud Computing Is Here

2

(10)

Cloud Computing Is Here

2

(11)

Cloud Computing Is Here

2

(12)

Cloud Computing Is Here

2

Why not use it?

(13)

What’s Happening in There?

3

(14)

From Data Center to Cloud

4

(15)

From Data Center to Cloud

4

(16)

From Data Center to Cloud

4

(17)

Reasons to Doubt

• History has shown they are vulnerable to attack

‣ SLAs, audits, and armed guards offer few guarantees

‣ Insiders can subvert even hardened systems

5

‘06 ‘07 ‘08 ‘09 ‘10 ‘11

903 695 678

986 770

641 Data Loss Incidents

External 54%

Unknown 7%

Insider 16%

Accidental 23%

Incident Attack Vector

Credit: The Open Security Foundation datalossdb.org

(18)

What is Cloud Computing?

• Cloud vendor provides computing resources for rent by customers

• What do you want to rent?

‣ Hosts (Infrastructure as a Service)

• Rent cycles: Amazon EC2, Rackspace Cloud Servers

‣ Environment (Platform as a Service)

• Rent instances: Microsoft Azure, Google App Engine

‣ Programs (Software as a Service)

• Rent services: Salesforce, Google Docs

• Other variations can be rented

6

(19)

What is Cloud Computing?

7

(20)

IaaS Cloud Example

8

Client

Scheduler Network

Controller Cloud Database

Message Queue

Volume Store Image

Store

Cloud API

Cloud

Customer

Cloud Node

Instances

(21)

Multiple Stakeholders

9

Cloud Node Cloud

Instance (VM) Client Data

Clients

Service Providers

Cloud Administrators

Is my platform secure?

Are my services running correctly?

Are my data protected?

(22)

Cloud Complexity

• Cloud environment challenges

‣ Opaque, Complex, Dynamic

‣ Insiders, Instances, Co-hosting

10

Client

^Service

(23)

Cloud Complexity

• Cloud environment challenges

‣ Opaque, Complex, Dynamic

‣ Insiders, Instances, Co-hosting

10

Client

Cloud Node

Cloud Node Cloud

Node

Cloud

Cloud Node

Platform

(24)

Cloud Complexity

• Cloud environment challenges

‣ Opaque, Complex, Dynamic

‣ Insiders, Instances, Co-hosting

10

Client

Cloud Node

Cloud Node Cloud

Node

Cloud

Node

(25)

Cloud Complexity

• Cloud environment challenges

‣ Opaque, Complex, Dynamic

‣ Insiders, Instances, Co-hosting

10

Client

Cloud Node

Cloud Node Cloud

Node

Cloud Node

VM

(26)

Cloud Complexity

• Cloud environment challenges

‣ Opaque, Complex, Dynamic

‣ Insiders, Instances, Co-hosting

10

Client

Cloud Node

Cloud Node Cloud

Node

Cloud Node

VM

(27)

VM

Cloud Complexity

• Cloud environment challenges

‣ Opaque, Complex, Dynamic

‣ Insiders, Instances, Co-hosting

10

Client

Cloud Node

Cloud Node Cloud

Node

Cloud Node

VM

(28)

VM

Cloud Complexity

• Cloud environment challenges

‣ Opaque, Complex, Dynamic

‣ Insiders, Instances, Co-hosting

10

Client

Cloud Node

Cloud Node Cloud

Node

Cloud Node

VM

(29)

VM

Cloud Complexity

• Cloud environment challenges

‣ Opaque, Complex, Dynamic

‣ Insiders, Instances, Co-hosting

10

Client

Cloud Node

Cloud Node Cloud

Node

Cloud Node

VM VM

VM

(30)

VM

Cloud Complexity

• Cloud environment challenges

‣ Opaque, Complex, Dynamic

‣ Insiders, Instances, Co-hosting

10

Client

Cloud Node

Cloud Node Cloud

Node

Cloud Node

VM VM

VM

(31)

Insider Threats

• May trust the cloud vendor company

‣ But, do you trust all its employees?

• Insiders can control platform

‣ Determine what software runs consumers’ code

• Insiders can monitor execution

‣ Log instance operation from remote

• Insiders may have physical access

‣ Can monitor hardware, access physical memory, and tamper secure co-processors

11

(32)

Insider’s Physical Access

12

(33)

Cloud Nodes

13

Server

(34)

Cloud Nodes

• Clouds manages node provisioning

‣ Administers PKI for machine identities

‣ Network installs a master disk image and customizes

13

Server

(35)

Cloud Nodes

• Clouds manages node provisioning

‣ Administers PKI for machine identities

‣ Network installs a master disk image and customizes

13

Server

PKI

(36)

Cloud Nodes

• Clouds manages node provisioning

‣ Administers PKI for machine identities

‣ Network installs a master disk image and customizes

13

Server

PKI

(37)

Cloud Nodes

• Clouds manages node provisioning

‣ Administers PKI for machine identities

‣ Network installs a master disk image and customizes

13

Server

(38)

Cloud Nodes

• Clouds manages node provisioning

‣ Administers PKI for machine identities

‣ Network installs a master disk image and customizes

13

Server

(39)

Cloud Nodes

• Clouds manages node provisioning

‣ Administers PKI for machine identities

‣ Network installs a master disk image and customizes

13

Server

(40)

Cloud Nodes

• Clouds manages node provisioning

‣ Administers PKI for machine identities

‣ Network installs a master disk image and customizes

13

Server Cloud

Node

(41)

Cloud Nodes

• Clouds manages node provisioning

‣ Administers PKI for machine identities

‣ Network installs a master disk image and customizes

• Node is essentially a static hosting utility

‣ Should not require persistent changes at runtime

‣ Should only allow inputs to well protected interfaces

13

Server Cloud

Node

(42)

Root of Trust for Installation

• Root of Trust for Installation ( ROTI ) [ ^ACSAC 2007 ]

‣ Binds the filesystem to a known installer (origin)

‣ Prevent persistent changes across reboots

‣ Detect system reboot and reverify

14

(43)

Root of Trust for Installation

• Root of Trust for Installation ( ROTI ) [ ^ACSAC 2007 ]

‣ Binds the filesystem to a known installer (origin)

‣ Prevent persistent changes across reboots

‣ Detect system reboot and reverify

14

(44)

Root of Trust for Installation

• Root of Trust for Installation ( ROTI ) [ ^ACSAC 2007 ]

‣ Binds the filesystem to a known installer (origin)

‣ Prevent persistent changes across reboots

‣ Detect system reboot and reverify

14

(45)

Root of Trust for Installation

• Root of Trust for Installation ( ROTI ) [ ^ACSAC 2007 ]

‣ Binds the filesystem to a known installer (origin)

‣ Prevent persistent changes across reboots

‣ Detect system reboot and reverify

14

(46)

Root of Trust for Installation

• Root of Trust for Installation ( ROTI ) [ ^ACSAC 2007 ]

‣ Binds the filesystem to a known installer (origin)

‣ Prevent persistent changes across reboots

‣ Detect system reboot and reverify

14

Quote (Installer,Image, FS,AIK )

(47)

Root of Trust for Installation

• Root of Trust for Installation ( ROTI ) [ ^ACSAC 2007 ]

‣ Binds the filesystem to a known installer (origin)

‣ Prevent persistent changes across reboots

‣ Detect system reboot and reverify

14

ROTI Proof

(48)

net ROTI [IEEE S&P 2011]

15

• Need to measure entire installation process

‣ Network installation receives untrusted inputs

‣ Bootstrap installation from a measured launch environment

(49)

net ROTI [IEEE S&P 2011]

15

Preinstall Phase

Configure boot options

Initialize RTM

Gather Phase

Gather installer client

Initialize installer environment

Measure installer

Download disk image

Measure disk image Bootstrap

Phase

Download Phase

Configure Phase

Customize disk image

Measure filesystem

Proof Phase

Generate ROTI Proof

netROTI Proof: Sig( MLE, Installer, Image, FS, AIK )

• Need to measure entire installation process

‣ Network installation receives untrusted inputs

‣ Bootstrap installation from a measured launch environment

(50)

net ROTI [IEEE S&P 2011]

15

• Need to measure entire installation process

‣ Network installation receives untrusted inputs

‣ Bootstrap installation from a measured launch environment

(51)

Evaluation

• netROTI installed 10 Eucalyptus node controllers

16

(52)

Evaluation

• netROTI installed 10 Eucalyptus node controllers

16

(53)

Evaluation

• netROTI installed 10 Eucalyptus node controllers

16

(54)

Evaluation

• netROTI installed 10 Eucalyptus node controllers

16

(55)

Evaluation

• netROTI installed 10 Eucalyptus node controllers

16

(56)

Instance Threats

• Publisher of a pre-configured instance (AMI) may be malicious or error-prone

• Publishers determine the software

‣ Instance could contain malware

• Publishers may configure security policies

‣ Could be insufficient to block adversaries

• Publishers may run scans to detect problems

‣ Malware detection may not find all malware, presuming they are used correctly

17

(57)

Instance Initialization

18

!"#$%&'()

!"#$"%&'(' )*+,-,./'012"/'!"34567!

,6%&869"-,.!

*+,) :;5$<'*22'=&5>"'

-!.) ,/)

?@=' A5;$B"':521'*+,-,.'

*C'?@=-D89E"<! 0C'=F-D89E"<!

G"D',6&">H89"'

*+,-,.'

=F'=&5>83"'

,6%&869"-,._*+,-,.'

Figure 2: VM instantiation in Amazon AWS. The Consumer chooses the image (AMI-ID), resources (Type), and availability zone (Region) for her VM on the Web Interface of the AWS Cloud App Store. Depending on the type of the AMI, the VM is instantiated (Instance-ID_AMI-ID) either as (A) EBS-backed or (B) S3-backed.

directly by Amazon or by third party publishers. Users can take these public AMIs to create their own AMIs which are either kept for themselves (private AMIs), made accessible to a group of users (shared AMIs), or made publicly available for every user of EC2 (public AMIs) as shown in Fig. 1.

AMIs are further distinguished by the storage type they are based on – either S3 or EBS – as described next.

S3-backed AMIs. S3-backed AMIs are stored on the highly available Simple Storage Service (S3) [7]. As shown in Fig. 2, S3-backed AMIs are instantiated by first copying the image onto the hard drive of a physical EC2 node which then boots the image. A new S3-backed AMI can be created from within a running S3-backed instance by a process called bundling, which stores the current state of the instance’s file system on S3 and registers this state with the Cloud App Store as new AMI. The data in an S3-backed instance is only persistent for the life of the instance and lost upon instance termination or failure. This resembles the usage model of a live CD.

EBS-backed AMIs. EBS-backed AMIs reside on the Elastic Block Storage (EBS) [4]. EBS o↵ers persistent, at- tachable block devices, called volumes, which can hold an arbitrary file system. When a user instantiates an EBS- backed AMI, a bitwise copy of the image is created on EBS and the VM is started from this new image as shown in Fig. 2. Storing the instance’s data persistently on an EBS volume enables the user to stop the execution of an EBS- backed VM. He then has only ongoing costs for the storage occupied by the block device. New EBS-backed AMIs are created by storing a bitwise copy of the current state of a volume, called snapshot, on EBS and registering this snapshot with the Cloud App Store as new AMI. EBS volumes cannot only be used to hold bootable AMIs, but are also a general way to store persistent data. They can be attached on-the-fly to running instances (comparable to a USB flash drive in the cloud).

Networking.

All instances are executed in an environment which provides logging, monitoring, and security capabilities such as a simple firewall for inbound traffic (cf. [20]). On startup,

the instance is assigned an external IPv4 address for Inter- net connectivity and an internal address for communication with other EC2 instances. The user is only charged for data traffic with the Internet over the external address.

3.2 Authentication in AWS

AWS uses di↵erent authentication mechanisms to provide authenticated access to the AWS account and to running instances as described next.

Authentication to the AWS Account. During the initial account creation and verification, an AWS Customer associates her email address with an AWS account, selects a password, and provides credit card and personal information for the monthly billing. After successful verification by Amazon she obtains a password to log into a web management system where she can inspect log files and the current account activity, change personal information, and manage instances. In this web management system, the Customer can register credentials for an Application Programming In- terface (API) to control the life cycle of an instance by means of tools provided by 3^rd parties or Amazon [34]. We refer to those credentials as API keys.³ The API keys can be used for example to start or terminate instances, create EBS volumes, or to register public images. Moreover, API keys are required within an S3-backed instance during the bundling of the same instances in order to access the S3 storage. How- ever, API keys do not provide direct access to personal or credit card information.

Authentication to Instances. After an instance has been started, the control needs to be securely transferred to the Customer by providing her with a secure and authenticated login channel. For this, Linux/Unix-based instances commonly use Secure Shell (SSH) [51]. Here, a customer generates an SSH key pair (pk, sk) and registers the public key pk with AWS. Upon instantiation of an AMI, this key is automatically made available to and imported by the SSH server running in the newly created instance and can be used for secure logins of the user who holds the corresponding secret key sk.

3Technically, API keys provide authorized access to a SOAP, Query, or REST-based web service.

392

Friday, November 30, 12

(58)

SSH Study

19

• Publisher left an SSH user authentication key in their AMI

• Fortunately, Amazon agreed that this is a violation

‣ Unfortunately, it was not an isolated problem

• 30% of 1100 AMIs checked contained such a key

‣ Also, pre-configured AMIs had SSH public host keys

• Thus, all instances use the same host key pair

• Implications?

(59)

Co-Hosting Threats

• An instance co-hosted on the same physical

platform could launch attacks against your instance

• Co-hosted instances share resources

‣ Computer

• CPU, Cache, Memory, Network, etc.

• Shared resources may be used as side channels to learn information about resource or impact its

behavior

20

(60)

Side Channels

• Watch use of shared resource to learn secret value

‣ Common case is the processor caches

• Approach

‣ Adversary tries to evict victim’s instructions/data from the cache

• To learn which instructions/data victim is using

• Adversary has some means to observe a delay in the victim’s processing

• This works surprisingly well

‣ Power usage is another useful side channel

21

(61)

Resource Freeing Attacks

• Setup

• Victims

‣ One or more VMs with public interface

• Beneficiary

‣ VM whose performance we want to improve (contend over target resource)

• Helper

‣ Mounts attack using interface

22

Helper

&

VM#

Vic&m#

Beneﬁciary#

(62)

Resource Freeing Attacks

• Side Channel is Cache

‣ Suppose victim hosts static and dynamic web pages

• Attack: shift resource usage via public interface

‣ Normally, victim is scheduled and pollutes the cache

‣ Approach lower scheduling priority

• Make more CPU-bound

23 RFA$intensi*es$–$*me$in$ms$per&second&

196%$slowdown$

86%$slowdown$

Performance$60%$

Improvement$

(63)

Take Away

• Cloud computing is established

‣ In several manifestations -- IaaS, PaaS, SaaS, ...

• Running your jobs in a cloud

introduces some security challenges

‣ Beware of insiders

‣ Beware of pre-configured instances

‣ Beware of co-hosted instances

• We are just beginning to understand the issues

24