Cloud Penetration Testing
Cloud Penetration Testing
Cloud Penetration Testing
6, December 2012
ABSTRACT
This paper presents the results of a series of penetration tests performed on the OpenStack Essex Cloud Management Software. Several different types of penetration tests were performed including network protocol and command line fuzzing, session hijacking and credential theft. Using these techniques exploitable vulnerabilities were discovered that could enable an attacker to gain access to restricted information contained on the OpenStack server, or to gain full administrative privileges on the server. Key recommendations to address these vulnerabilities are to use a secure protocol, such as HTTPS, for communications between a cloud user and the OpenStack Horizon Dashboard, to encrypt all files that store user or administrative login credentials, and to correct a software bug found in the OpenStack Cinder typedelete command.
KEYWORDS
Cloud, Fuzzing, OpenStack, Penetration Testing, Vulnerability Detection
1. INTRODUCTION
This paper discusses penetration testing of the OpenStack Essex Cloud Management Software package. The paper is organized into nine sections including (I) Introduction, (II) OpenStack Cloud Management Software, (III) Selection of Penetration Testing Software, (IV) Design & Implementation of the Test Cloud, (V) Design & Implementation of the Penetration Test Environment, (VI) Description of the Penetration Tests Performed (VII) Test Results, (VII) Summary and Conclusions, and (IX) References.
DOI : 10.5121/ijccsa.2012.2604
43
International Journal on Cloud Computing: Services and Architecture (IJCCSA),Vol.2, No.6, December 2012
44
International Journal on Cloud Computing: Services and Architecture (IJCCSA),Vol.2, No.6, December 2012
2.3. OpenStack Networking (Quantum) OpenStack Networking is an API-driven system for managing cloud networks and IP addresses. A partial list of OpenStack Networking features includes: Manages IP addresses, allowing for static, DHCP or floating IP addresses Several networking models including flat networks or VLANs Allows users to create and manage their own networks Support for software-defined networking technology (i.e. OpenFlow) Network framework allows for a variety of devices to be integrated into the cloud including intrusion detection systems, load balancers, firewalls, etc.
3.1. Fuzzing
Fuzzing is used in computer security to describe a number of tools and techniques used to discover vulnerabilities by subjecting a program to a wide variety of inputs. Computer programmers, and testers have used fuzzing techniques since the early 1970s. [1] The term
45
International Journal on Cloud Computing: Services and Architecture (IJCCSA),Vol.2, No.6, December 2012
fuzzer was first used in 1988 by Barton Miller, a professor at the University of Wisconsin Madison (UW-M). Miller, his associates, and students from his Computer Science classes at UW-M developed a series of fuzzers to test the reliability of UNIX system routines and application programs. [2] Another milestone in the history of fuzzing was the initial release of SPIKE in 2001, and its subsequent presentation at Black Hat 2002 by Dave Aitel of Immunity, Inc. [3] SPIKE is a fuzzing framework that allows a tester to define the structure of a programs input as a series of layered blocks. Understanding the structure of the input stream allows fuzzing to be more efficient than simply generating random input data and providing it to a program under test. For example if a programs input includes a checksum, generating completely random input data to fuzz the program would be extremely inefficient since the random input data would likely not include a valid checksum, and would thus be rejected by the program. Grammar based fuzzing is a combination of random fuzzing techniques with block-based fuzzing techniques. A minimal definition of the protocol to be fuzzed is created to automatically generate inputs to the program under test that partially complies with the protocol specification. Critical protocol parameters, such as checksums, can be completely specified, while less important parameters can be randomized. An example of a grammar-based fuzzer is the PROTOS project developed at the University of Oulu in Finland. [4] Since 2002 the popularity of fuzzing has grown, as has the sophistication and number of opensource and commercial fuzzing tools. Today, fuzzing is widely recognized as a valid computer security test method, and is being used by many commercial software development companies. Microsoft uses white-box fuzzing as part of their quality assurance process. Dr. Patrice Godefroid of Microsoft defines white-box fuzzing as a new approach to fuzzing pioneered at Microsoft in the SAGE tool and based on symbolic execution and constraint solving techniques. [5] According to Godefroid a Windows 7 test team found 50% more bugs using a white-box fuzzer (SAGE) than all other traditional fuzzers combined. 3.1.1. Comparison of Fuzzing Tools While there are dozens of fuzzing tools available, the authors have chosen to select between a subset of open-source tools for this project. Open-source tools that will be considered include BED, SFUZZ, SICKFUZZ, and SPIKE. BED, also known as Bruteforce Exploit Detector, is a protocol fuzzer developed by Martin Muench & Eric Sesterhenn that detects common vulnerabilities including buffer overflows, format string bugs, and integer overflows. [6] BED supports fuzzing the FINGER, FTP, HTTP, IMAP, IRC, LPD, PJL, POP, SMTP, SOCKS4 and SOCKS5 protocols. BED is an open-source Linux based fuzzing tool that is relatively easy to use. BED does not offer any options to perform command line fuzzing. SFUZZ, also known as Simple Fuzzer, is a block-based fuzzer that includes a number of predefined scripts for popular protocols including HTTP, POP3, RTSP, SMTP and Twitter. [7] SFUZZ can also be used to perform command line fuzzing. SFUZZ is an open-source Linux based fuzzing tool that is very easy to use for the predefined protocol scripts, and moderately easy to use for fuzzing command lines. SICKFUZZ is a Python front-end for the SPIKE fuzzing tool. SICKFUZZ is designed to fuzz the HTTP protocol, and includes six predefined test cases for HTTP functions (HEAD, GET, POST, etc.). [8] SICKFUZZ is an open-source Linux based fuzzing tool that is relatively easy to use,
46
International Journal on Cloud Computing: Services and Architecture (IJCCSA),Vol.2, No.6, December 2012
although it generated a large number of run-time errors when the authors attempted to use it to fuzz the OpenStack Horizon HTTP interface. SPIKE is a block-based fuzzer developed by David Aitel of Immunity, Inc. [9] SPIKE is an opensource Linux based fuzzing tool that is relatively hard to use since it requires a strong knowledge of the C programming language, as well as detailed knowledge of the protocols that are fuzzed. SPIKE is probably the most powerful open-source block-based fuzzer available today. Based on analysis of how each fuzzing product met the specific requirements for this research effort, as well as hands-on testing or live product demonstrations of each product, the authors chose to use BED and SFUZZ for the test phase of this research effort. BED will be used to fuzz the OpenStack Horizon user interface via a network protocol (HTTP) interface. SFUZZ will be used to fuzz the OpenStack Horizon user interface via a network protocol (HTTP) interface. SFUZZ will also be used to fuzz the OpenStack command line interfaces.
As shown in Figure 2, the user initiates an HTTP session with a server over a network connection. The users web browser sends a session request to the server, which responds with a session key. The session key will be used in subsequent communication as an alternative to the users login credentials. The attacker gains access to the session key by packet sniffing on the network the user and server use to communicate. Once the session key has been sniffed, the attacker can use a web browser to access restricted web pages on the server using the stolen session key. Penetration testing tools developed by Robert David Graham of Errata Security called Ferret and Hamster will be used to perform the session sidejacking tests on the OpenStack cloud. [10] Ferret sniffs and captures session keys transmitted over a network connection. Ferret stores the URLs of web pages along with the session keys associated with those pages in a text file. Hamster reads
47
International Journal on Cloud Computing: Services and Architecture (IJCCSA),Vol.2, No.6, December 2012
data from a Ferret text file, opens a standard web browser, and provides an easy to use graphical interface where an attacker can click on any of the captured URLs and navigate the browser directly to restricted web pages using the captured session keys.
International Journal on Cloud Computing: Services and Architecture (IJCCSA),Vol.2, No.6, December 2012
The OpenStack software was downloaded from the DEVSTACK web site, which offers shell scripts to automatically install OpenStack on a variety of target platforms. [13] The DEVSTACK All-in-one shell script was used to install OpenStack on the target server. Using the shell script from DEVSTACK reduced the OpenStack installation process to the following three steps: 1. Install Ubuntu 12.04 LTS on the target server 2. Clone the DEVSTACK installation software from Github 3. Deploy the OpenStack cloud software by executing the DEVSTACK shell script The OpenStack installation process using the DEVSTACK shell script took approximately two hours. A few additional configuration steps were required after the installation process had been completed, such as editing configuration files to include the correct network addresses. Additional configuration steps included downloading virtual machine images for use in the OpenStack cloud, creating test user accounts, creating virtual machine instances, creating volumes, and associating volumes with specific virtual machine images. Most of the cloud configuration steps can be performed from a remote workstation using the OpenStack Horizon Dashboard, or they can be performed from the command line on the OpenStack server. While the primary purpose of this research effort was to detect vulnerabilities in the OpenStack cloud management software, it was desirable to configure the OpenStack test system so that it was fully operational, with multiple user accounts, multiple virtual machine images, and multiple volumes. CentOS, Fedora, RedHat, ttylinux and Ubuntu virtual images in the QCOW2 format were downloaded and installed on the OpenStack server. These OpenStack compliant virtual machine images are available for download from Rackspace Cloud Builders. [14]
International Journal on Cloud Computing: Services and Architecture (IJCCSA),Vol.2, No.6, December 2012
Port 80 HTTP Port 3260 Glance API Port 3306 MySQL Port 3333 Nova API Port 4369 - EPMD Port 5000 Keystone API
Port 5672 AMQP Port 5800 X11VNC Port 5900 VNC Port 8773 EC2 API Port 8774 EC2 API Port 8775 Nova API
Port 8776 Nova API Port 9191 Glance API Port 9292 Glance API Port 35357 Keystone API
Once the network ports used by OpenStack were identified, a series of tests were run to characterize the network packet structures used for each port. These were fairly simple tests that involved monitoring the network using Wireshark while using the Horizon Dashboard to configure different aspects of OpenStack.
50
International Journal on Cloud Computing: Services and Architecture (IJCCSA),Vol.2, No.6, December 2012
For penetration testing of the OpenStack Horizon Dashboard HTTP service sfuzz will be invoked from the Backtrack 5 R3 command line as follows: ./sfuzz T f scripts/basic.http S 192.168.1.10 p 80 This command instructs the SFUZZ program to fuzz the HTTP service listening on 192.168.1.10:80 using the basic.http fuzzing configuration file located in the scripts directory. This configuration file instructs the SFUZZ program to generate a series of fuzzed HTTP GET, HEAD and POST commands with a fuzzed string length between 1 and 10,024 characters.
International Journal on Cloud Computing: Services and Architecture (IJCCSA),Vol.2, No.6, December 2012
nova --os_username admin --os_password adminpassword --os_tenant_name "admin" --os_auth_url http://192.168.1.10:5000/v2.0 add-fixed-ip FUZZ FUZZ -This test case generates a series of nova add-fixed-ip commands which each requires two parameters. Each parameter will be fuzzed to create a series of valid nova add-fixed-ip commands with what are most likely invalid parameters. Each configuration file is processed by the SFUZZ program to create a series of fuzzed commands that are stored in a shell script file. An exemplar shell script line from the nova.sh file is shown below. # Nova Test Case 03 # Fuzz nova add-fixed-ip (two arguments) nova --os_username admin --os_password adminpassword --os_tenant_name "admin" --os_auth_url http://192.168.1.10:5000/v2.0 add-fixed-ip AAAA AAAA This shell script command includes two parameters that the SFUZZ program has filled in with a series of four A characters. The length of the fuzzed p arameter strings generated by the SFUZZ program is controlled by the configuration file. For the OpenStack Cinder, Glance, Keystone, Nova, Quantum and Swift testing efforts the maximum string length of a fuzzed parameter was set to 1025 characters. Table 2 shows the total number of unique fuzzed shell script commands created to test each of the OpenStack services.
Table 2: OpenStack Command Line Fuzzing Tests
Each SFUZZ configuration file also specifies the characters used to build the fuzzed parameters. These include the following ASCII characters: !, /, 0, 9, :, @, A, Z, [, ', a, z, {, and ~. Each of these characters are used to form test strings between 1 and 1025 characters in length, which are then inserted as parameters of the fuzzed OpenStack commands. Some OpenStack services include a rate-limiting option that limits the number of commands that can be executed over a specific period of time. During the fuzzed command line testing of the nova service the rate-limit feature was disabled to ensure that all of the commands were processed by the nova service. Disabling the nova rate-limit feature is done by editing the etc/nova/apipaste.ini file. [18]
52
International Journal on Cloud Computing: Services and Architecture (IJCCSA),Vol.2, No.6, December 2012
It should be noted that while the number of unique commands that will be fuzzed during these tests is very large, it is possible to perform a much more comprehensive fuzzing of the OpenStack command lines. Only required parameters are being fuzzed during this research effort. In addition to required parameters most OpenStack commands can also contain optional parameters. Also the command line fuzzing performed during this research effort generated fuzzed parameters using only 10 different ASCII characters, and limited the parameter length to 1025 characters. A more comprehensive OpenStack command line fuzzing test could be designed to use all the required and optional parameters, use all 256 valid ASCII characters, and create longer fuzzed parameters. Going to this extreme would likely increase the total number of fuzzing tests to well over 50,000,000. 6.3. Session Hijacking During this portion of the OpenStack penetration test effort an attempt will be made to hijack an HTTP session using a stolen session cookie. The Ferret program will be used to monitor the network connection between an OpenStack user and the OpenStack server. When the OpenStack user connects to the OpenStack server via the Horizon Dashboard, Ferret will capture the session cookie provided by the server to the users browser. Ferret stores the stolen session cookie in a text file, along with URL data associated with web pages that were visited by the user during their session. The Hamster program retrieves the stolen session cookie and URL information from the text file created by Ferret, and allows an unauthorized user to hijack the OpenStack users HTTP session, and gain access to restricted Horizon Dashboard web pages. The Ferret and Hamster programs were run on a Windows XP system that has a promiscuous mode network interface card, as shown in Figure 3. A Windows 7 laptop was used to login to the OpenStack server using the Test_User_1 account. There is a known session hijacking vulnerability in OpenStack Essex and Folsom as described in the National Vulnerability Database CVE-2012-2144. [19] The overview for CVE-2012-2144 states Session fixation vulnerability in OpenStack Dashb oard (Horizon) folsom-1 and 2012.1 allows remote attackers to hijack web sessions via the sessionid cookie. A patch to fix this vulnerability was released by OpenStack in May 2012. [20] The patch rotates session cookies after a user logs out, and properly clears sessions. [21] This patch revised the following six python scripts used in portions of the Horizon login process: horizon/exceptions.py, horizon/middleware.py, horizon/tests/auth_tests.py, horizon/users.py, horizon/views/auth.py, horizon/views/auth_forms.py
The penetration tests will attempt to verify that session cookies are reset after an OpenStack user logs out, and will also attempt to hijack a users session before they logout.
International Journal on Cloud Computing: Services and Architecture (IJCCSA),Vol.2, No.6, December 2012
The Wireshark program will be used to monitor the network connection between an OpenStack user and the OpenStack server. When the OpenStack user connects to the OpenStack server via the Horizon Dashboard, Wireshark will attempt to capture the users login credentials. During this penetration test a Windows 7 computer will be used to login to the OpenStack Horizon Dashboard using Test_User_1s login credentials. In addition to attempting to steal user credentials transmitted over the network connection, the OpenStack server will be analyzed to determine if any user login credentials are stored in files on the server. No special penetration test programs are required for this analysis. Standard Linux programs like gedit can be used to analyze OpenStack files to determine if user credentials may be stored in them. The OpenStack server directories that will be analyzed include the devstack, etc, and var directories. Each of these directories includes a number of OpenStack configuration files, program files and script files.
7. TEST RESULTS
This section will present the results of the penetration tests performed on the OpenStack cloud management software.
54
International Journal on Cloud Computing: Services and Architecture (IJCCSA),Vol.2, No.6, December 2012
The OpenStack Horizon Dashboard was used to delete the volume types created during the cinder fuzz testing. Ten of the volume types could not be deleted. Figure 7 shows a screen grab of the OpenStack Horizon Dashboard showing the ten volume types that could not be deleted after the cinder fuzz tests. The green box on the right side of Figure 7 is a dialog box confirming that all ten volume types were successfully deleted, however as can be seen in the center of Figure 7 all ten volume types are still present in the volume type data base. Interestingly each of the ten volume types has a name of exactly 255 characters in length. The cinder type-create fuzz test created volume types with name lengths between 1 and 1025 characters. Volume types with name lengths between 1 and 254 as well as between 256 and 1025 characters were properly deleted using the OpenStack Horizon Dashboard.
55
International Journal on Cloud Computing: Services and Architecture (IJCCSA),Vol.2, No.6, December 2012
In addition to using the OpenStack Horizon Dashboard to attempt to delete these ten volume types, the OpenStack cinder type-delete command was used to attempt to manually delete the ten image types. OpenStack cinder accepted, and appeared to execute each of the ten type-delete commands, however all ten image types were still in the database after the execution of the cinder type-delete commands. There appears to be a problem in OpenStack Essex that prevents the deletion of a volume type with a name length of exactly 255 characters. To test this theory another volume type was created manually using the following cinder command: cinder --os_username admin --os_password adminpassword --os_tenant_name "admin" --os_auth_url http://192.168.1.10:5000/v2.0 Type-create TestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTes tTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTe stTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestT estTes When executed this command created a new volume type and assigned it a volume type number of 9527. The following cinder command was then used to delete the newly created volume: cinder --os_username admin --os_password adminpassword --os_tenant_name "admin" --os_auth_url http://192.168.1.10:5000/v2.0 type-delete 9527 This command was executed with no errors. To verify that the volume type was deleted the following cinder command was executed: cinder --os_username admin --os_password adminpassword --os_tenant_name "admin" --os_auth_url http://192.168.1.10:5000/v2.0 type-list The new volume type did not show up in the list of volume types, so the cinder type-delete command appeared to work properly, even on a volume type with a name length of 255 characters. Based on these manual tests it appears that the problem is more complicated than not being able to delete a volume type with a name of exactly 255 characters. The cinder file cinder/volume/volume_types.py contains the python code to delete a volume type. [22] The portion of volume_types.py that implements the type-delete command is shown below. def destroy(context, name): """Marks volume types as deleted.""" if name is None: msg = _("name cannot be None")
56
International Journal on Cloud Computing: Services and Architecture (IJCCSA),Vol.2, No.6, December 2012
raise exception.InvalidVolumeType(reason=msg) else: db.volume_type_destroy(context, name) The python code for db.volume_type_destroy is located in the cinder/db/api.py file. [23] The portion of api.py that implements the type-delete command is shown below. def volume_type_destroy(context, name): """Delete a volume type.""" return IMPL.volume_type_destroy(context, name) A cursory analysis of the python code does not show any obvious bugs that could cause a volume type name of 255 characters in length to fail the delete process. The problem could be in the OpenStack MySQL database, or in other python code that is executed during the image-delete process. This problem has been submitted to the OpenStack Foundation as bug # 1085192. The bug submission has been accepted, assigned a high priority, and is planned to be resolved in the Grizzly-2 release early in 2013. The proposed solution is to use UUID based image type names rather than ASCII character based image type names. 7.2.2 Glance Command Line Fuzzing Test Results Figure 8 shows a screen grab taken while the glance command line fuzzing test was running. The left side of the screen shows a Linux terminal executing the glance fuzz test shell script, while the right side of the screen shows the Ubuntu System Monitor program, which was used to monitor the CPU, Memory and Network utilization rates during the test. As shown in Figure 8, the average CPU utilization rate was less than 50% during this test. The OpenStack glance service did not crash, or exhibit any unexpected behaviours during the command line fuzz testing.
7.2.3 Keystone Command Line Fuzzing Test Results Figure 9 shows a screen grab taken while the keystone command line fuzzing test was running. The left side of the screen shows a Linux terminal executing the keystone fuzz test shell script, while the right side of the screen shows the Ubuntu System Monitor program, which was used to monitor the CPU, Memory and Network utilization rates during the test. As shown in Figure 9, the average CPU utilization rate was less than 50% during this test, although there were some bursts of utilization higher than 75%. The OpenStack keystone service did not crash, or exhibit any unexpected behaviours during the command line fuzz testing.
57
International Journal on Cloud Computing: Services and Architecture (IJCCSA),Vol.2, No.6, December 2012
7.2.5 Quantum Command Line Fuzzing Test Results Figure 11 shows a screen grab taken while the quantum command line fuzzing test was running. The left side of the screen shows a Linux terminal executing the quantum fuzz test shell script, while the right side of the screen shows the Ubuntu System Monitor program that was used to monitor the CPU, Memory and Network utilization rates during the test. As shown in Figure 11, the average CPU utilization rate was less than 50% during this test, although there were bursts of CPU utilization above 75%. The OpenStack quantum service did not crash, or exhibit any unexpected behaviors during the command line fuzz testing. 7.2.6 Swift Command Line Fuzzing Test Results Figure 12 shows a screen grab taken while the swift command line fuzzing test was running. The left side of the screen shows a Linux terminal executing the swift fuzz test shell script, while the right side of the screen shows the Ubuntu System Monitor program, which was used to monitor the CPU, Memory and Network utilization rates during the test. As shown in Figure 12, the average CPU utilization rate was less than 50% during this test. The OpenStack swift service did not crash, or exhibit any unexpected behaviors during the command line fuzz testing.
58
International Journal on Cloud Computing: Services and Architecture (IJCCSA),Vol.2, No.6, December 2012
As discussed previously OpenStack released a patch to six Horizon python scripts to address a session hijacking vulnerability. The session hijacking penetration tests verified that these patches were installed on the OpenStack server, and that they properly prevented session hijacking after the user logged out. During penetration tests these patches did not prevent session hijacking performed while an OpenStack user was still logged in. As long as the user was still logged in the Ferret and Hamster programs were able to hijack the user session. Once the session was hijacked an unauthorized user was able to access any of the restricted Horizon web pages associated with that user account. Access to these restricted web pages allowed an unauthorized user to add or delete cloud resources to any of the users projects, to create snapshots of the users instances or volumes, and to exfiltrate the users instance or volume data. This issue has been submitted to the OpenStack Foundation as bug # 1085198. The OpenStack Foundation is currently considering several options to address this issue. The most likely solution is to change the OpenStack documentation to make it clear that using a secure network protocol, like HTTPS, for communication between a cloud user and the Horizon Dashboard is strongly recommended. Horizon currently supports the HTTPS protocol, however in some cases it is not enabled during the OpenStack installation process.
59
International Journal on Cloud Computing: Services and Architecture (IJCCSA),Vol.2, No.6, December 2012
Unlike the session hijacking vulnerability discussed above, this credential theft vulnerability can be exploited even after the user has logged out of their Horizon session. In fact this vulnerability can be exploited at any time of an attackers choosing provided the user has not changed their password. More importantly a patient attacker who has the ability to sniff the OpenStack server network connection could collect user login credentials for the OpenStack system administrator, and thus gain unauthorized access to all of the user data stored within the OpenStack server including images, instances, volumes, snapshots, and project data. Figure 16 shows a Wireshark capture of the OpenStack administrators login credentials transmitted as unencrypted data over the network connection. Analysis of the devstack, etc and var directories on the OpenStack server found several files where unencrypted administrative login credentials can be found. These files include: /devstack/localrc /etc/nova/api-paste.ini /etc/cinder/api-paste.ini /var/cache/cinder/cacert.pem /var/cache/cinder/signing_cert.pem /var/cache/glance/registry/cacert.pem /var/cache/glance/registry/signing_cert.pem
Since all of the files listed above are stored as unencrypted data it would be relatively easy for an insider threat to obtain access to these files and thus be able to steal OpenStack administrative credentials. It would be a bit more difficult for an outsider threat to access these files, but since OpenStack enables SSH access to the server a patient hacker could eventually crack the SSH password and then gain access to these files.
International Journal on Cloud Computing: Services and Architecture (IJCCSA),Vol.2, No.6, December 2012
to address this vulnerability, a session hijacking attack is still possible under certain circumstances (i.e. the user whose session cookie was hijacked is still logged in to the OpenStack Horizon Dashboard). Two different types of credential theft attacks were successful in allowing an attacker to learn a cloud users or cloud administrators login credentials, as well as to gain access to administrative certificates. Login credentials were acquired over an unencrypted network connection using the freely available Wireshark program. Administrative login credentials and certificates were acquired by locating unencrypted files on the OpenStack server that contained this sensitive information. All of the vulnerabilities discovered during this research effort can be eliminated through the use of encryption. The session hijacking attack can be prevented by using HTTPS instead of HTTP for communications between cloud users and the cloud management software. The credential theft attacks can be prevented by encrypting any OpenStack files that contain sensitive information. The programming error related to deleting volume types with long file names has been reported to the OpenStack foundation (bug # 1085192), been assigned a high priority, and is scheduled to be resolved in the Grizzly-2 release during early 2013. The session hijacking issue has also been reported to the OpenStack Foundation (bug # 1085198). The most likely solution is to change the OpenStack documentation to strongly recommend the use of a secure protocol like HTTPS for network communications between cloud users and the Horizon Dashboard. OpenStack currently supports the HTTPS protocol, although it is not required for all installations. It is important to continue to perform penetration tests on the OpenStack Cloud Management Software. OpenStack is being used by many large companies for their private, as well as public clouds. Improving the overall security posture of OpenStack through penetration testing is a worthy effort since many OpenStack users are moving more of their applications and data into the cloud
9. REFERENCES
[1] [2] Hanford, K. (1970) Automatic generation of test cases, IBM Systems Journal 9(4), 242 257 Miller, B., Fredriksen, L. & So, B. (1990) An empirical study of the reliability of unix utilities, Communications of the ACM 33(12), 3244. [3] Aitel, D. (2002) http://www.blackhat.com/presentations/bh-usa-02/bh-us-02-aitel-spike.ppt, December 2012 [4] Roning, J., Laakso, M., Takanen, A. & Kaksonen, R. (2002) Protos- systematic approach to eliminate software vulnerabilities, https://www.ee.oulu.fi/research/ouspg/, December 2012 [5] Godefroid, P., Molnar, D., (2010) Fuzzing in The Cloud (Position Statement), http://research.microsoft.com/pubs/121494/paper.pdf, December 2012 [6] BED (Bruteforce Exploit Detector), available from http://www.codito.de, December 2012 [7] SFUZZ (Simple Fuzzer), available from http://SFUZZ.git.sourceforge.net/git/gitweb.cgi?p=SFUZZ, December 2012 [8] SICKFUZZ, available from http://sickness.tor.hu/?p=334, December 2012 [9] SPIKE, Dave Aitel, Immunity, Inc., available from http://www.immunitysec.com/resourcesfreesoftware.shtml, December 2012 [10] Graham, R. D., Ferret & Hamster Sidejacking Tools, available from http://www.erratasec.com/sidejacking.zip, December 2012 61
International Journal on Cloud Computing: Services and Architecture (IJCCSA),Vol.2, No.6, December 2012
[11] NERSC Cyber Security Tutorial, Full text can be found at http://www.nersc.gov/users/training/onlinetutorials/cybersecurity-tutorial/, December 2012, page 4 [12] Wireshark is available from http://www.Wireshark.org/, December 2012 [13] Quick Start All-in-One OpenStack Shell Script, available from http://devstack.org/, December 2012 [14] OpenStack Virtual Machine Images are available from https://github.com/rackerjoe/oz-image-build, December 2012 [15] Backtrack 5 (R3) is available from http://www.backtrack-linux.org/, December 2012 [16] Zenmap and nmap are available from http://nmap.org/, December 2012 [17] OpenStack Documentation is available from http://docs.openstack.org/, December 2012 [18] Detailed information on the OpenStack Compute API rate limit parameters can be found at http://docs.openstack.org/api/openstack-compute/2/content/, December 2012 [19] National Vulnerability Database CVE-2012-2144, http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-2144, December 2012 [20] OpenStack /Horizon session fixation security fix, https://github.com/openstack/horizon/commit/041b1c44c7d6cf5429505067c32f8f35166a8bab, December 2012 [21] OpenStack Bug # 978896, Session Fixation Vulnerability, https://bugs.launchpad.net/horizon/+bug/978896, December 2012 [22] cinder/volume/volume_types.py can be downloaded from https://github.com/openstack/cinder/blob/master/cinder/volume/volume_types.py, December 2012 [23] cinder/db/pi.py can be downloaded from https://github.com/openstack/cinder/blob/master/cinder/db/api.py, December 2012
62