Attack Surfaces:A Taxonomy for Attacks on Cloud Services

Nils GruschkaNEC Europe Ltd.

Heidelberg, Germanygruschka@nw.neclab.eu

Meiko JensenHorst Gortz Institute for IT-SecurityRuhr University Bochum, Germany

Meiko.Jensen@rub.de

Abstract

The new paradigm of cloud computing poses severesecurity risks to its adopters. In order to cope withthese risks, appropriate taxonomies and classificationcriteria for attacks on cloud computing are required.In this work-in-progress paper we present one suchtaxonomy based on the notion of attack surfaces ofthe cloud computing scenario participants.

1. Introduction

Cloud computing is currently one the most hypedIT innovations. Most IT companies annouce to plan or(suddenly) already have IT products according to thecloud computing paradigm. Though cloud computingitself is still not yet mature enough, it is already evidentthat its most critical flaw—according to public consent(cf. [1], [2])—is security.

In the nearest future, we can expect to see a lot ofnew security exploitation events around cloud comput-ing providers and users, which will shape the cloudcomputing security research directions for the nextdecade. Hence, we have seen a rapid evolution ofa cloud computing security discipline, with ongoingefforts to cope with the idiosyncratic requirements andcapabilities regarding privacy and security issues thatthis new paradigm rises.

In line with these developments, the authors closelywatch cloud computing security on a very techni-cal level, focussing primarily on attacks and hackingattempts related to cloud computing providers andsystems. Here, as Lowis and Accorsi pointed out lately[3], the specific security threats and vulnerabilities ofservices and service-oriented architectures require newtaxonomies and classification criteria, so do attacks oncloud computing scenarios.

In this work-in-progress paper, we try to anticipatethe classes of vulnerabilities that will arise from thecloud computing paradigm, and we give a preliminaryattack taxonomy for these, based on the notion ofattack surfaces. The next Section defines this classifica-tion approach for arbitrary cloud computing scenarios.Then, Section 3 illustrates the use of the attack surfacestaxonomy by applying it to four common types ofattacks on cloud computing scenarios. The paper con-cludes with a summary and future work in Section 4.

2. An Attack Taxonomy for Cloud Com-puting

A cloud computing scenario can be modelled usingthree different classes of participants: service users,service instances (or just services), and the cloudprovider (cf. Figure 1).

Every interaction in a cloud computing scenario canbe addressed to two entities of these participant classes(e.g. a user requesting a service or a service instanceinquiring more CPU power from the infrastructuresystem). In the same way, every attack attempt in thecloud computing scenario can be detailed into a setof interactions within this 3-class model. For instance,between a user and a service instance one has thevery same set of attack vectors that exist outside thecloud computing scenario (e.g. SQL injection, floodingattacks, ...). Hence, talking about cloud computingsecurity means talking about attacks with the cloudprovider among the list of participants. This does notrequire the cloud provider to be malicious himself, itmay also just play an intermediate role in an ongoingcombined attack (see below).

To be more precise, each of the three participantroles provides a specific kind of interface to eachother participant class. For instance, the cloud systemprovides every service instance with a specific interface

2010 IEEE 3rd International Conference on Cloud Computing

978-0-7695-4130-3/10 $26.00 © 2010 IEEE

DOI 10.1109/CLOUD.2010.23

276

managecloudinvo

ke

servi

ce

use cloud

User

Service Cloud

(a)

(b)

(c)(d)

(e)

(f)

(a) service-to-user(b) user-to-service(c) cloud-to-service(d) service-to-cloud(e) cloud-to-user(f) user-to-cloud

Figure 1. The cloud computing triangle and the six attack surfaces

(API depending on the service model type, IaaS, PaaS,or SaaS) that the service instance can use (i.e. run on).In the same way, a service instance provides its serviceto a user with a dedicated interface (e.g. website, SSHconnection, Web Service, ...). Thus, with 3 participants,there are 6 such interfaces to consider (as shown inFigure 1). For the remainder of this paper, we willrefer to these interfaces as being the attack surfaces.

2.1. Attack Surfaces

The first and most prominent attack surface is that ofa service instance towards a user (a). This is nothingelse than the common server-to-client interface, thusenabling (and being vulnerable to) all kinds of attacksthat are possible in common client-server-architecturesas well. This involves things like buffer overflowattacks, SQL injection, or privilege escalation.

In the same way, the attack surface the service userprovides towards the service (b) is nothing else thanthe common environment a client program providesto a server, e.g. browser-based attacks for an HTML-based service like SSL certificate spoofing [4], attackson browser caches, or Phishing attacks on mail clients.

The interface between a service instance and a cloudsystem (c) is a little bit more complex. Here, theseparation of service instance and cloud provider canbe tricky, but in general the cloud system’s attacksurface to the service instance covers all attacks thata service instance can run against its hosting cloudsystem. An example would be resource exhaustion

attacks, triggering the cloud provider to provide moreresources or end up in a Denial-of-Service, or attackson the cloud system hypervisor (see Section 3.2).

The other way around, the attack surface of a serviceinstance against the cloud system (d) is a very sensi-tive one. It incorporates all kinds of attacks a cloudprovider can perform against a service running on it.This may start with availability reductions (i.e. shutdown service instances), but may also cover privacy-related attacks (scanning a service instance’s data inprocess) or even malicious interference (e.g. tamperingdata in process, injecting additional operations to ser-vice instance executions; everything a rootkit [5] cando). To the author’s consideration, this is by far themost critical kind of attack surface, as its exploitation israther easy (once being the cloud provider) and attackimpacts are tremendous.

The fifth attack surface of interest is that of thecloud system towards the user (e). This is a littlebit hard to define since both usually do not have areal touching point; in common scenarios there alwaysexists a service in between. However, the cloud systemhas to provide an interface for controlling its services.That interface, which we call cloud control, providescloud customers with the ability to add new services,require more service instances, delete service instancesetc. As this is not a service instance in the senseof Figure 1, it is discussed here as a separate attacksurface, with attack threats being merely similar to theones a common cloud service has to face from a user.

The last attack surface is the one provided by

277

a user towards the cloud provider (f). Considerableattacks may involve phishing-like attempts to triggera user into manipulating its cloud-provided services,e.g. presenting the user a faked usage bill of thecloud provider. In general, this involves every kind ofattack that targets a user and originates (or spoofs tooriginate) at the cloud system.

2.2. Combined Attacks

Attacks do not always have to restrict themselves toexploit only one of the attack surfaces stated above.Especially in the cloud computing scenario, they mayincorporate using several attack surfaces in combi-nation for achieving the intended attack effects. Forinstance, attacks on the cloud-to-user interface thatresult in the attacker impersonating a legitimate usertowards the cloud system can be misused to mali-ciously modify service instances (using the service-to-cloud attack surface).

3. Attacks on Cloud Systems

Using real-world examples from recent publications,this section intends to illustrate the described classifi-cation approach.

3.1. The Amazon EC2 Hack

The Amazon Elastic Cloud Computing (EC2) is onethe most known commercial and publicly availablecloud computing service. EC2 is a so-called Infras-tructure as a Service, offering virtual servers allowinga user to deploy its own Linux, Solaris or Windowsbased virtual machines. In order to control the de-ployed machines, EC2 offers a SOAP interface for e.g.starting new instances of a machine, terminating aninstances etc.

In 2008 a weakness was found in this controlservice [6]. Using a form of a Signature WrappingAttack [7] it was possible to modify an eavesdroppedmessage despite of the digital signed operation. Thus,an attacker was able to execute arbitrary own machinecommands on behalf of a legitimate cloud user andthis way e.g. perform a Denial-of-Service on the usersservices or create a botnet charging the EC2 costs onthe user’s bill.

This attack incident can be reduced to two separateactions: attacking the cloud control interface (i.e. thecloud-to-user attack surface) to get control of the cloudsystem, then attacking the service instances using theservice-to-cloud attack surface.

3.2. Hey, You, Get Off My Cloud

Attacking the very same Amazon EC2 cloud system,the authors of [8] illustrated the steps necessary to gainconfidential information from (or even compromise)running service instances. Therefor, they managed tosetup attacker-initiated services that are scheduled tothe very same hardware server with the victim ser-vice, then exploiting that position for hypervisor-basedattacks.

This attack scheme can be reduced to the followingsteps. First, manipulate the cloud-to-user surface forsetting up a service instance on the same hardwarewith the victim’s service instance. Then, using thatservice instance, attack the cloud-to-service interface togain hypervisor- and hardware-related information (i.e.breaking privacy) or go further attacking the service-to-cloud interface of the victim’s service instance inorder to perform “service-to-service‘” attacks.

3.3. Cloud Malware Injection

The main idea of the Cloud Malware Injection attack[9] is that an attacker uploads a manipulated copyof a victim’s service instance so that some servicerequests to the victim service are processed within thatmalicious instance. In order to achieve this, the attackerhas to gain control over the victim’s data in the cloudsystem (e.g. using one of the attacks described above).

In terms of classification, this attack is the majorrepresentative of exploiting the service-to-cloud attacksurface. The attacker—controlling the cloud—exploitsits privileged access capabilites to the service instancesin order to attack that service instance’s security do-mains.

3.4. Cloud Wars

The promise of cloud computing includes high avail-ability of computational resources for the cloud-hostedservices. Nevertheless, flooding attacks that aim at re-source exhaustion can still impact the cloud, especiallysince the attacker may use a cloud for sending hisflooding messages as well (cf. [9]). Thus, both clouds(the attacker’s one and the victim’s one) provide moreand more resources for sending respectively receiv-ing attack messages until one of both cloud systemseventually reaches its maximum capacities (cf. [10]).As a side-effect, if the attacker uses a hijacked cloudservice for attack message generation, he can triggerhuge usage bills for cloud-provided services that thereal user never ordered.

278

This attack involves two (not necessarily disjunct)cloud systems, hence there are several attack surfacesused. At first, sending attack messages to the victim’sservice is a typical service-to-user surface attack (asin non-cloud scenarios). As the services on both at-tacker’s and victim’s side additionally consume cloudresources, the cloud-to-service interface of both cloudsis attacked as well. Further, as other services hosted onthe same hardware within a cloud may be affected bythe resource exhaustion as well, this implies a cloud-to-service surface invlovement, and finally the usagebill of the hijacked service misused for attack messagegeneration is a representative of exploiting the user-to-cloud surface of the legitimate cloud user that has topay for the resource usage during the attack.

4. A Summary To-Date

As cloud computing is on the rise, and especiallydue to its enormous attraction to organized criminals,we can expect to see a lot of security incidents and newkinds of vulnerabilities around it within the decades tocome. This paper gives a first step towards classifyingthem, thus making them more concrete and improvingtheir analysis. Using the notion of attack surfaces, weillustrated the deverloped classification taxonomy bymeans of four up-to-date attack incidents of cloudcomputing scenarios.

Being a work-in-progress, we will continue with thecollection and classification of cloud-based attacks andvulnerabilities in order to prove or refute our attacktaxonomy’s applicability and appropriateness.

References

[1] J. Heiser and M. Nicolett, “Assessing the security risksof cloud computing,” Gartner Report, 2009. [Online].Available: http://www.gartner.com/DisplayDocument?id=685308

[2] P. Mell, “Nist presentation on effectively and securelyusing the cloud computing paradigm v26,” Oct2009. [Online]. Available: http://csrc.nist.gov/groups/SNS/cloud-computing/index.html

[3] L. Lowis and R. Accorsi, “On a classification approachfor soa vulnerabilities,” in COMPSAC (2), 2009, pp.439–444.

[4] M. Marlinspike, “Null prefix attacks against ssl/tlscertificates,” Thoughtcrime.org White Paper, 2009.

[5] D. Brumley, “invisible intruders: rootkits in practice,”USENIX, 1999.

[6] N. Gruschka and L. Lo Iacono, “Vulnerable Cloud:SOAP Message Security Validation Revisited,” in ICWS’09: Proceedings of the IEEE International Conferenceon Web Services. Los Angeles, USA: IEEE, 2009.

[7] M. McIntosh and P. Austel, “XML signature elementwrapping attacks and countermeasures,” in SWS ’05:Proceedings of the 2005 workshop on Secure webservices. New York, NY, USA: ACM Press, 2005,pp. 20–27.

[8] T. Ristenpart, E. Tromer, H. Shacham, and S. Savage,“Hey, you, get off of my cloud: exploring informationleakage in third-party compute clouds,” in CCS ’09:Proceedings of the 16th ACM conference on Computerand communications security. New York, NY, USA:ACM, 2009, pp. 199–212.

[9] M. Jensen, J. Schwenk, N. Gruschka, and L. Lo Iacono,“On technical security issues in cloud computing,” inProceedings of the IEEE International Conference onCloud Computing (CLOUD-II), 2009.

[10] M. Jensen, N. Gruschka, and N. Luttenberger, “The Im-pact of Flooding Attacks on Network-based Services,”in Proceedings of the IEEE International Conferenceon Availability, Reliability and Security, 2008.

279