Cloud Security Vulnerabilities
Cloud Security Vulnerabilities
Cloud Security Vulnerabilities
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.
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].
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.
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.