Cloud Security Vulnerabilities

Download as pdf or txt
Download as pdf or txt
You are on page 1of 7

1

Security improvements in virtualized environments


Irina Mihai, Raluca Voinescu
Automatic Control and Computers Faculty
POLITEHNICA University of Bucharest
Email: [email protected], [email protected]
Abstract
In the last years the Cloud environment has become a major attraction not only for developers, but even for ordinary users.
Not worrying about where to keep your data or where to run your applications most definitely describes an ideal context in the
digital world of today. If we add scalability, flexibility and low costs to that we could just say Evrika and enjoy using the Cloud.
A thing that should not be forgotten is that such massive and popular services have always become main targets for cybercriminals
who plan attacks not necessarily for money or fame, but sometimes out of pure curiosity.
The Cloud is the largest virtualized environment known until now, used on such a great scale that is basically impossible to
determine the number of its users. Given these, security becomes a real problem and providing solutions for the still-evolving
Cloud has become a hot topic. The scope of this paper is to describe the Cloud virtualized structure, to analyze and validate its
main vulnerabilities, together with a number of attacks that exploit these vulnerabilities. For building our case and studying this
problem, we have chosen OpenStack as a Cloud solution.

I. I NTRODUCTION
There is a very real phenomenon that people are not aware what the software they use is doing behind its nice interface.
Sometimes people dont know if and how a software is using the Internet, furthermore the Cloud [17]. Another phenomenon
just as real is that other people are very much aware that others have no idea that they are using the Cloud. With the continuous
growth of this new type of environment, who could really keep track of everything?
The Cloud impresses not only with its novelty status, but mostly with what is wants and has to offer: flexibility, redundancy,
fast data transfers, practically unlimited pool of resources, everything on demand and not at a high price. There hasnt been yet
found a complete definition for this new emerged paradigm, but until now it has been worldwide agreed that the Cloud comes
with three types of services - Infrastructure as a Service, Platform as a Service, Software as a Service - and four deployment
models - Private Cloud, Public Cloud, Hybrid Cloud, Community Cloud.
This popularity has its advantages and disadvantages. While the advantages have been mentioned earlier, one of the main issues
is that such a popular service draws the attention of attackers. The bigger and complex a system is, the higher the probability
of finding a breach, exploiting it and getting away with it. This is why studying the security of virtualized environments is
a must: to develop the tools for detecting malicious behavior and to try and suggest improvements for avoiding data loss or
tampering and confidentiality violation.
This paper will focus on general security issues of the virtualized environments and several attacks that have happened along
the time. As an example of virtualized environment, we will use OpenStack, not only for studying its vulnerabilities, but also
to implement some of those attacks and try to propose security improvements. We have chosen OpenStack not only because its
an opensource software, but mainly because its a mature framework, extremely popular, and with a considerable community
contributing to its progress. It also comes with a development solution, DevStack[2], which provides the OpenStack central
services and creates an environment destined for development and testing. We have chosen two attack directions: one on non
OpenStack specific components - the virtualization solutions used (Zen/KVM) and one on specific OpenStack components
(Keystone, Nova, Swift, Glance, Cinder).
II. S ECURITY ISSUES IN VIRTUALIZED ENVIRONMENTS
In this section we will focus on specific problems for different kind of attacks in virtualized environments: Denial of Service
attack, Malware-Injection attack, Side Channel attack, and Man-In-The-Middle Cryptographic attacks.
A. Denial-of-Service attack
In a cloud infrastructure, services and resources such as RAM, CPU, network, disk storage are shared between users. If these
resources are extensively used, services performance will be low. Denial-of-service (DoS) attack is one of the most common
and damaging attacks on the cloud. The purpose of the DoS attack is to prevent users from using computing resources. An
attacker will attempt to overload the network with connection requests, in order to reduce users bandwidth, prevent access to
services and disrupt services. If a cloud service is overloaded, it will try to cope with the workload. Therefore, in order to
meet the requirements, the system will provide more computational power, thus actually helping the attacker in rendering a
service unavailable.

B. Distributed Denial-of-Service attack


DDoS attacks are amongst the classical forms of attack hackers can inflict upon web servers. Unlike data breaches, DDoS
attacks do not steal anything, but they do cause downtime for the network [16]. Sonys PlayStation Network and Entertainment
Network were victims in August 2014 in this type of attack, when they were rendered inaccessible and offline for almost 1
whole day. Unfortunately for Sony, the last DDoS attack they experienced back in 2011 led to a major data breach which
exposed more than 100 million accounts of their customers. Typically, hackers can rent so-called botnets (networks of infected
computers controlled by cyber criminals) in order to initiate such acts. Ironically, it gets even worse nowadays, when they can
simply just rent greater computing power from cloud services to complete their malicious intent. Statistics from Verizon report
that the bandwidth used by DDoS attacks nearly doubled since 2011, ranging from 4.7 Gbps to 10.1 Gbps in 2014[6].
C. Malware-Injection attack
Malware injection attack is one category of web-based attacks, in which hackers exploit web application for vulnerabilities
and embed malicious codes into them, effectively changing the course of their normal expected execution. Similar to web-based
applications, cloud systems are also prone to malware injection attacks. Hackers can either craft a malicious application, a
program or a virtual machine and inject them into target cloud service models. Among the most used form of malware injection
attacks are SQL injection and XSS (cross site scripting) [19]. A well-known security blog reported that a type of SQL injection
attack had compromised Sony PlayStation. The attack had successfully planted unauthorized code to more than 200 web pages
promoting Sonys videogames [10]. Computer security experts interest should be triggered by XSS attacks as they represent
the most dangerous and malicious form of malware injection attack. A group of researchers from Germany demonstrated a
XSS attack against Amazon by hijacking a current cloud service session, further allowing them access to customer data such
as authentication data, tokens and even plain text passwords [20].
D. Side Channel attack
Side Channel attack involves two stages: Virtual Machine Co-Residence and Placement and Virtual Machine Extraction. The
first stage implies the attacker to place a malicious virtual machine on the same physical machine as a target instance. After
successfully completing the first stage, the malicious instance will use side channels to learn information about coresident
instances.[22]
E. Data breaches
A data breach relates to the unauthorized release of sensitive data from targeted systems or networks which may result in data
loss, including financial, personal and health information. The authors from [25] managed to extract private cryptographic keys
through side-channel timing information. Even if this required a great deal of work, a malicious hacker would not have to go
to such extent have the same results. Should a multitenant cloud service system have even one flaw, all of the clients data may
get into the wrong hands. For example, hackers managed to gain access to the Targets cloud network through the monitoring
store climate systems. Furthermore, they uploaded a grabber program to mirror all payment data to an unused Target server.
This went by unnoticed for two months and resulted in having the CIO and CEO lose their jobs, a $400 million worth of
holiday shoppers information and most important, the loss of their customers trust. Another example is LinkedIn, the largest
professional networking website boasting 175 million users, which reported that their password database was compromised
due to data breach. Approximately 200.000 hashed passwords were cracked from a total of 6.5 million, after being posted on
a Russian web forum[9].
F. Data loss
Data loss, also known as data leakage, is another major issue cloud computing users could face. Deletion of records without
a backup of the original content is an obvious example of ways to compromise data. If data loss may occur when a disk drive
deteriorates, it certainly occurs when one owner of encrypted data loses the encryption key. The architectural and operational
characteristics of the cloud environment could threaten the integrity of stored data. Amazon Web Service customers suffered
an involuntary loss of data when their proprietary Elastic Compute Cloud experienced a re-mirroring storm in 2011 (large
number of nodes trying to replicate themselves on an incorrectly upgraded primary network capacity) caused by human operator
error[12]. On the other hand, Mat Honan, a writer for Wired magazine, lost all his personal pictures when his Gmail, Twitter
and Apple accounts had been compromised by an intruder intentionally.

G. Man-In-The-Middle Cryptographic attacks


This attack implies the adversary to place himself between two valid entities with the aim to intercept or modify communications. An example of MITM attack is the Impersonating attack in which the adversary pretends being a valid user or server
and deceives a valid entity to disclose his credentials in order to use them to gain unauthorised access to the system.[14]
As technology evolves to meet the needs of users, security threats are constantly evolving and adapting as well. Cloud Computing
offers benefits such as mobility or flexibility, but it also provides malicious users new ways of breaching security. Perhaps
the most devastating threats for both organizations and individual users are data loss and data breaches. Companies fear that
important information not reach the hands of competitors, while individual users are afraid of abuses.
III. O PEN S TACK SECURITY ISSUES
A. OpenStack overview
This Private Cloud model can also be considered internal cloud or enterprise cloud[13]. The infrastructure of the Cloud
is specifically designed to provide services for a single organization which usually owns the location of the site. Multiple
solutions for setting up a private Cloud are used by organizations: VMWare, VirtualBox, OpenStack.
The OpenStack Project, initially developed by NASA[18] offers an IaaS model which not so long ago had only seven
components[5], but now has developed three more. The OpenStack architecture contains [3]:
Dashboard (Horizon) comes with a Web GUI for the others OpenStack services.
Compute (Nova) offers the necessary software for working with virtual machines. It is similar to Amazon EC2, assuring
scalability and redundancy.
Network (Neutron) ensures connectivity between machines running OpenStack software.
Object Store (Swift) offers the software for managing the storage of data to the order of petabytes for long periods of
time.
Block Storage (Cinder) offers, as the name suggests, block storages for guest only virtual machines.
Image Service (Glance) provides services for virtual disk images.
Identity (Keystone) manages the security for the OpenStack services.
Telemetry (Ceilometer) is responsible for billing, metering, rating, autoscaling.
Orchestration (Heat) conducts the interactions between different Cloud applications.
Database Service (Trove) offers support for relational and non-relational databases.
The interaction of the components presented above are illustrated in Figure 1.

Figure 1: OpenStack architecture [5].


If an user wants to use OpenStack he will do that either through the Dashboard service, either through the APIs every
service provides. The Identity services ensures the authentication and after that, all the other services are accessible.
The project was developed in Python and runs with an Apache2 license. The provided GUI offers the user the liberty to

create not only virtual machines with default values of CPU and RAM, but to set those numbers [21]. Given the fact that the
OpenStack Project aims to be able to support a considerable large infrastructure, it uses more hypervisors for creating and
running the virtual machines: Xen, KVM, HyperV, Qemu[15].
B. Security threats
Several security issues of OpenStack architecture are presented in [24]:
1) Identity access and user management: In OpenStack Object Storage (Swift), authentication and authorization are provided
through two mechanisms: tempAuth and swAuth [4]. The two methods have different approaches in keeping the users
data: tempAuth keeps users data in clear, using configuration files, while swAuth uses encoded JSON files. In both cases,
authentication is made through username and password and once the user has been granted, the user receives a token that
identifies him for 24 hours, after which it expires. A problem here is that OpenStack has no password requirements and
no dictionary verification, meaning that any password, no matter how simple, is accepted as valid. Since tempAuth uses
configuration files for keeping the data, including the usernames and passwords, even those of the super user, a normal user
could find the passwords of other users. To avoid this situation, special permissions should be set for that configuration file
during the site bringup.
SwAuth for the other hand, uses clear permissions rights for the file containing the username and password, but in that file, the
data is kept in clear-text. Hashing the passwords or encrypting them should definitely be a thing to consider for OpenStack.
2) Data management: One of the main concerns in the virtualized environment is maintaining the isolation and keeping the
users data integrity and confidentiality. OpenStack isolates the data using path hashing, which is highly insecure, as seen in
[24]. There have been several attacks studies on OpenStack isolation: preimage attack, collision attack and it has been shown
that in these cases, OpenStack is not flawed, offering mechanisms for preventing this kind of attacks.
Another problem in OpenStack is that backup and recovery are not supported in the case of a file with a name which already
exists. Although the server process, replicator, copies the data to other cluster sites, uploading a file which does not have a
unique name overwrites the other files and makes them irretrievable.
IV. A RCHITECTURE
As presented in Section 2, there are so many threats against a systems, that studying its vulnerabilities becomes a major
priority. The steps towards improving a system is to reproduce the issue, find its cause and only then to propose a solution. In
this paper, we are trying to develop at least one of the attacks presented in the second section: man in the middle attack and
then to give solutions for preventing this type of attack in the virtualized environment. For doing these, we chose to use the
following elements:
DevStack - is a script that quickly builds an OpenStack development environment. Its primary purpose is to provide
the necessary tools and services of OpenStack, approprite not only for development actions, but also for operational and
security testing. It also provides the needeed documentation for confuguring, running anf maintaining the OpenStack
services. Although DevStacks purpose was not to become a replacement for OpenStack, it has evolved into an interesting
alternative that offers many options for configurating all the services on a large number of platforms.
Host machine - a machine on which DevStack will be installed. We have chosen an Oracle Linux Server release 6.5,
Red Hat Enterprise Linux Server release 6.5 (Santiago) with the following configuration:
MemTotal :
MemFree :
Buffers :
Cached :
Active :
Inactive :
A c t i v e ( anon ) :
I n a c t i v e ( anon ) :
Active ( f i l e ) :
Inactive ( file ):
Unevictable :
AnonPages :
Mapped :
Shmem :

4048544
3308024
49116
438548
430504
180308
125044
3948
305460
176360
1716
124920
42528
4132

kB
kB
kB
kB
kB
kB
kB
kB
kB
kB
kB
kB
kB
kB

Slab :
SReclaimable :
SUnreclaim :
KernelStack :
PageTables :
CommitLimit :
Committed AS :
VmallocTotal :
VmallocUsed :
VmallocChunk :
Hugepagesize :
DirectMap4k :
DirectMap2M :

80396 kB
35920 kB
44476 kB
1696 kB
12780 kB
2024272 kB
427148 kB
34359738367 kB
7580 kB
34359730671 kB
2048 kB
10232 kB
4184064 kB

Figure 2: Man-In-The-Middle.
The idea of the project is to install DevStack on the host machine and, in the beginning, to create two users - tenants, Alice
and Mallroy 2. Each one of the users will create at least one virtual machine. The second step would be to explore how the
data associated to these users is kept, where, the encryption mechanisms and the way authentication and authorization are
made, what vulnerabilities could be exploited and if, indeed, the security issues presented in the Security threats subsection
are valid. The scenario is for Alice to perform basic actions - authentication, logout, virtual machine creation and for Mallroy
to try and obtain vital information from the former user, such as the password or its token.
The first step in succeeding this is for Mallroy to perform a sniffing action and to act as a passive attacker who just collects
information about the system and about Alice. Based on that information, we can create a script that automatically obtains the
necessary data from the system, processes it and completes the MITM1 attack.
V. I MPLEMENTATION AND R ESULTS
Since OpenStack - and in consequence, also DevStack - uses KVM 2 and Qemu 3 , we will validate our attack first on two
machines[1] with the roles previously presented, but created not directly from the DevStack environmenet, but from Qemu.
A. Setting up the environment
The first step in doing this is to install the necessary tools.
Firstly, check if the processor of the host machine supports virtualisation:
e g r e p c ( vmx | svm ) / p r o c / c p u i n f o

If the result of the previous command is 0 (zero), than the CPU does not support hardware virtualisation. If the result is 1
(one) or higher, than the CPU supports hardware virtualisation, but this has to be enabled from BIOS.
The following step is to install the necessary packages:
s u d o a p t g e t i n s t a l l qemukvm l i b v i r t b i n u b u n t uvmb u i l d e r b r i d g e u t i l s
1 Man-In-The-Middle
2 Kernel-based
3 Open

Virtual Machine - virtualization infrastructure for the Linux kernel that turns it into a hypervisor[8]
source machine emulator and virtualizer

libvirt-bin comes with the libvirtd daemon which uses libvirt to manage the qemu and kvm instances.
qemu-kvm represents the backend of the whole virtualized architecture.
bridge-utils manages a bridge from the virtual machine to the local network.
virtual manager its a desktop user interface application whose purpose is to manage virtual machines through libvirt. It
primarily targets KVM VMs, but it can also manage Xen and LXC (linux containers). [11]
In the Virtual Manager, Alices and Mallroys machines will be created. As seen in 3, Alice will have a machine hosting
an Ubuntu 14.04, while Mallroys will use Kali, a Linux distribution specialised for Penetration Testing, Ethical Hacking and
network security assessments[7].

Figure 3: Allices and Mallroys machines.


B. Designing the attack
While Alice is enjoying her Ubuntu experience, Mallroy will put his Kali to work.
1) Attack tools: The first step in developing the MITM attack, is to have Arpspoof and SSLStrip installed. Since Kali is a
distribution specialised for these kind of actions, these tools should be already installed.
2) IP Forwarding: IP forwarding needs to be installed so that traffic could flow through Mallroys machine.
echo 1 > / proc / sys / n e t / ipv4 / i p f o r w a r d

3) Redirect traffic to SSLStrip using IPTables: An IPTables rule which will take the traffic originated from the victim,
destined for port 80 (HTTP), and redirect it to the port on which SSLStrip will be running (8080).
i p t a b l e s t n a t A PREROUTING p t c p d e s t i n a t i o n p o r t 80 j REDIRECT t op o r t 8080

4) IP Addresses: For this to perfectly work, we need to find out the identity of the target 4 and the IP Address of the
Gateway 5. This information is necessary for constructing the ARP Spoofing and can be easily found out using nmap.

Figure 4: Get Target IP

Figure 5: Get Gateway IP


5) ARP Spoofing: Since ARP maps the IP addresses to MAC addresses, the ARP spoofing attack sends erronated data to
Alices machine telling it that the IP address of the gateway has changed to the address of Mallroys machine. Now, Alice
thinks that the gateway is Mallroy and will send all its data there. The actual gateway also needs to be spoofed to think that
Mallroys machine is actually Alices machine. This way, Mallroy has become the Man in the middle.
6) SSLStrip: What SSLStrip does 6 is to send to Alice an unencrypted HTTP page, even if she requieres an HTTPS one.
Now, since Alice is sending unencrypted data, Mallroy can easily inspect it and get all her credentials if she logs into her
Facebook, Gmail, Yahoo or any other account.

Figure 6: SSLStrip command


VI. C ONCLUSION
As it could be seen, deploying a man in the middle attack on a virtualized environment is not so difficult, especially for a
person using the same physical machine. All you need is the right tools. In the Cloud the situation is even much more tragic,
since there are many people sharing the same machine and thus, the consequences of such an attack would be way vast and
the chances for the attacker to get undepicted just as high.
For future development, the same attack, with the same scenario, will be developed in an OpenStack environment.
R EFERENCES
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
[17]
[18]
[19]
[20]
[21]
[22]
[23]
[24]
[25]
[26]

attack. http://robospatula.blogspot.ro/2013/12/man-in-the-middle-attack-arpspoof-sslstrip.html.
DevStack. https://wiki.openstack.org/wiki/DevStack.
http://docs.openstack.org/admin-guide-cloud/content/ch getting-started-with-openstack.html. Technical report.
http://docs.openstack.org/developer/swift/overview auth.html. Technical report.
http://ken.pepple.info/. Technical report.
http://www.bloomberg.com/bw/articles/2014-08-26/ddos-attacks-are-soaring. Technical report.
Kali. https://www.kali.org/.
KVM. http://en.wikipedia.org/wiki/Kernel-based Virtual Machine.
Linkedin. http://blog.linkedin.com/2012/06/06/linkedin-member-passwords-compromised/.
Sopho. http://www.sophos.com/en-us/press-office/press-releases/2008/07/playstation.aspx.
Virtual Manager. https://virt-manager.org.
When Amazons cloud turned on itself. http://www.informationweek.com/cloud/infrastructure-as-a-service/post-mortem-when-amazons-cloud-turned-onitself/d/d-id/1097465 .
Networks Aerohive. Public or private cloud: The choice is yours.
M.Misbahuddin B.Sumitra, C.R. Pethuru. A survey of cloud authentication attacks and solution approaches.
Srivatsan Jagannathan. Comparison and evaluation of open-source cloud management software. 2012.
Bansidhar Joshi, A Santhana Vijayan, and Bineet Kumar Joshi. Securing cloud computing environment against ddos attacks. In Computer Communication
and Informatics (ICCCI), 2012 International Conference on, pages 15. IEEE, 2012.
Peter Mell and Tim Grance. The nist definition of cloud computing. 2011.
Ken Pepple. Deploying openstack. OReilly Media, Inc., 2011.
Niels Provos, Moheeb Abu Rajab, and Panayiotis Mavrommatis. Cybercrime 2.0: when the cloud turns dark. Communications of the ACM, 52(4):4247,
2009.
Thomas Roth. Breaking encryptions using gpu accelerated cloud instances. In BlackHat Conference, Conf, 2011.
Omar Sefraoui, Mohammed Aissaoui, and Mohsine Eleuldj. Openstack: toward an open-source solution for cloud computing. International Journal of
Computer Applications, 55(3):3842, 2012.
Bhrugu Sevak. Security against side channel attack in cloud computing. International Journal of Engineering and Advanced Technology (IJEAT),
2(2):183, 2013.
Ajey Singh and Maneesh Shrivastava. Overview of attacks on cloud computing. International Journal of Engineering and Innovative Technology (IJEIT),
1(4), 2012.
Rostyslav Slipetskyy. Security issues in openstack. Masters thesis, Norwegian University of Science and Technology, 2011.
Yinqian Zhang, Ari Juels, Michael K Reiter, and Thomas Ristenpart. Cross-vm side channels and their use to extract private keys. In Proceedings of
the 2012 ACM conference on Computer and communications security, pages 305316. ACM, 2012.
Kazi Zunnurhain and S Vrbsky. Security attacks and solutions in clouds. Citeseer.

You might also like