Implementing Cyber Security during the Development of a Capstone Project

T. Dottie, J. Lindstrom, A. McQueen, S. Orozco, and T. Walls (students) Department of Computing and Technology, Cameron University, Lawton Oklahoma, USA

Abstract – During the spring 2015 IT 4444 Capstone course at Cameron University, students experienced firsthand what was to be expected of members of a software development team. The Capstone project gave students the opportunity to build a system for a real-world client, Comanche County Memorial Hospital’s Information Technology (IT) department. The team built an inventory control system that would initially be used exclusively for the IT department; however, the system would be scalable for future use by the entire organization. The authors of this study assumed the roles of security specialists and had the responsibility of ensuring the security and integrity of the system during all phases of the project. The responsibilities included identifying the security vulnerabilities associated with the system, testing the integrity of the data fields in the database, and attacking the PHP code with industry standard testing protocols. This study chronicles the processes and methods used to successfully ensure the security and integrity of the Capstone project.

Keywords: Capstone, Security, Vulnerability Testing, Penetration Testing.

1 IntroductionCameron University’s spring 2015 Capstone IT 4444

course utilized approximately seventy students from various degree fields and concentrations and integrated them into three separate teams. Each team developed a complete, secure application to be utilized by a real-world client. The Comanche County Memorial Hospital’s IT department, a part of Comanche County Hospital Authority (CCHA), was the client. Teams were created through blind resumes and cover letters. This procedure resulted in three separate teams with groups inside each team based upon a student’s major or concentration. The majors/concentrations represented in this project included computer science, multimedia, database, cyber security, and technical writing. Each team consisted of a project leader, the leader’s deputy, a lead tech writer from the English department, and leads for database, computer science, multimedia, and cyber security. The focus of this study concentrates on the development and testing of the information assurance and security protocols used by the cyber security specialists of two of the three teams.

1.1 Initial Interview

To ascertain what was necessary to create the application software and determine the security requirements of the system, the teams conducted a meeting with the client. During the meeting team members asked questions pertaining to the project. From this interview, the team was able to determine the best course of action for the project. The first task of the Cyber security team was to determine the purpose and scope of their portion of the project.

1.2 Purpose

The purpose of this study was to provide a scientific methodology for the accurate characterization of operational security through examination and correlation of test results in a consistent and reliable manner. The commitment to the client consisted of ensuring confidentiality, integrity, and availability.

1.3 Scope of Project

The activities within the scope of cyber security testing included the following: (a) information gathering, (b) penetration testing of the system, including the database, middleware, and user interface, (c) configuration gathering, (d) data validation, (e) vulnerability testing, and (f) assessment of system components.

1.4 Not in Scope of Project

The activities not within the scope of the cyber security testing included the following: (a) social engineering to acquire sensitive information, (b) testing disaster recovery, (c) business continuity, and (d) emergency response plan.

2 Identifying Vulnerabilities It was determined by the cyber security team that identifying the possible vulnerabilities was the first priority in developing their security strategies. The website owasp.org [1] included the OWASP top ten list of vulnerabilities, which are included in Figure 1.

OWASP Top 10 – 2013A1 – Injection A2 – Broken Authentication and Session Management A3 – Cross-Site Scripting (XSS) A4 – Insecure Direct Object References A5 – Security Misconfiguration A6 – Sensitive Data Exposure A7 – Missing Function Level Access Control A8 – Cross-Site Request Forgery (CSRF) A9 – Using Known Vulnerable Components A10 – Unvalidated Redirects and Forwards

Figure 1. The OWASO Top 10 List

3 Testing Tools

The tools used for testing were an important part of the research and development of the project. Access to Cameron University computers was restricted, and permission had to be granted by the university’s IT department. The cyber security groups were allowed limited administrative privileges utilizing computers that were part of an isolated network that provided a controlled environment. In this controlled environment, a sandbox was created to administer the testing.

3.1 Sandbox

A sandbox is used to create an environment for experimentation and testing of software code and web applications. The testing environment isolates the tested materials and testing tools from the actual network and production environment. This precaution prevented any unwanted changes or unauthorized access to the university’s network. The Cameron University IT department supplied desktop computers with administrator privileges with which to work in the sandbox. The cyber security group used phpMyAdmin [2] as the sandbox for testing the MySQL database and PHP code. With phpMyAdmin, group members used dummy data created by the database groups to test the following: logon and logout procedures, password security, user privileges, and inventory request and management [3].

The security team also utilized its own computers to perform some of the tests. The team used the Localhost on their laptops and were able to perform various tests with tools available. Localhost is the default name describing the local computer address, also known as the loopback address. When setting up a web server or software on a web server, 127.0.0.1 is used to point the software to the local machine. After loading the web application on its computers the team was able to test it using the Localhost IP address.

3.2 Virtual Machine

Oracle Virtual Box [4] was the core component of the sandbox. It provided a stable and controlled environment within the computer system itself. This system was the best choice for Cameron University’s IT department. The virtual environment prevented potentially hazardous code from being executed on its systems and was also capable of using many different operating systems. Figure 2 shows a screenshot of the Oracle VM management page.

Figure 2. Oracle VM Manager

3.1 Kali

Kali [5] is an open source operating system that was used for testing the system. It is Linux-based and compatible with many of the software testing tools available for penetration testing.

3.2 Nessus

Nessus [6] is a security and compliance auditing tool that monitors configurations, patches, and web applications for errors and vulnerabilities [7]. The team used Nessus to perform five separate scans that included the following:• Host Discovery scan• Bash Shellshock Detection• Web Application Test• Basic Network Scan• Advanced Scan

The team ran Nessus in Kali Linux. To do so, Nessus was launched from the command line in Kali with the command /etc/init.d/nessusd start. Once Nessus was running as a service, Ice Weasel was opened and the local host at 127.0.0.1:8834 was launched which opened the Nessus tool itself. From this point each separate scan was configured and launched.

3.3 Owasp/ZAP

The OWASP Zed Attack Proxy Tool (ZAP) [8] is an open source tool used for web application penetration testing. Its main function is to scan web applications for possible vulnerabilities with its passive scanning feature. The other important features of ZAP are as follows: use of spiders to find all the possible web pages; scanning for vulnerabilities and confirming them with active scanners; and using intercepting proxies to track and possibly change requests that go from the host computer to the web application. The team used the ZAP tool within the Kali Linux virtual machine to test the database and website of the inventory tracking system for possible general vulnerabilities. The team also used the spider feature to find any possible hidden or overlooked webpages. ZAP was used to back up the findings the team found with Nessus [8, 9]. Figure 3 shows a typical Owasp/ZAP screen.

Figure 3. Owasp/Zap

3.4 SQLMap

SQLMap [10] is an open source tool that uses the command line features on Windows and Kali Linux to detect possible SQL injection vulnerabilities in a web application’s database server. The tool scans the database server and provides information that includes the following: usernames, passwords, password hashes, and the database structure. The tool supports multiple databases: MySQL, Oracle, Microsoft Access, and so on. The team used SQLMap to scan the MySQL database of the inventory tracking system to find any possible sql injection vulnerabilities. The team used this tool on a Windows 7 virtual machine, scanned the database, and found vulnerabilities that could be used to exploit the database to find usernames and inventory information [11]. Figure 4 shows a typical SQLMap screen.

Figure 4. SQLMap

3.5 Hydra

Hydra [12] was written as a proof of concept code. Its intended use was to be a tool for showing that it is easy to bypass passwords and gain entry to a system from a remote location. This password-cracking tool supports multiple protocols and multiple attack forms. It is also designed to compile on multiple operating systems. This tool was used for testing user authentication during the testing phase of the project. Hydra utilizes a simple graphical user interface with tabbed pages. Each page sets up a different part of the targeting process. The initial target is designated by entering an IP address either for a single target or a group of targets and a port number, if needed, as well as the protocol used, as shown in Figure 5. Once a target has been entered, the password tab can be used to define specific parameters to be used by Hydra. Figure 6 shows an examples of this step. Figure 7 shows the start/output page. Once a target has been entered and parameters have been set, the start button is clicked, and all data generated by Hydra for that attempt is displayed in the output window.

Figure 5. Hydra Target setup tab

Figure 6. Hydra Password tab

Figure 7. Hydra Start tab and Output panel

4 Testing Results

The team used the tools described previously to find possible vulnerabilities that could be present in the CCHA inventory tracking system. The initial tests did find some vulnerabilities in the application. Working with the computer science students and the database developers, the vulnerabilities were addressed, and the security team was able to run tests that did not show significant issues. The results of the tests are described in the following paragraphs.

4.1 Owasp/ZAP

Zap was a very user friendly application used to test the software. Initial tests showed fifty-two vulnerabilities possible within the application, however, most of them were redundant. There were only eight individual vulnerabilities identified with this test. One was considered a significant, or high threat, five were considered a medium threat, and two were considered a low threat. The Owasp/ZAP software identified the vulnerabilities and then gave feedback on how to mitigate them. The team shared this information with the development team and they were able to utilize this information to correct the problem. Figure 9 shows the summary of the ZAP scan. Figure 10 shows some of the suggestions ZAP made for mitigation of the vulnerabilities.

Figure 8. Owasp/ ZAP Scanning Report

Figure 9. Owasp/ZAP Solution

4.2 SQLMap

SQLMap proved to be insignificant in our testing procedures. The Owasp/ZAP software was able to identify the problems associated with the application, and SQLMap was not able to identify any unique vulnerabilities.

4.3 Hydra

The team used hydra to perform brute force attacks upon the sandbox. The method of attacking was to brute force with a username and password list. Using username and password lists, the first hydra brute force testing used a username list called usernames.txt and a password list called passwords.txt. The two lists contained commonly used username and passwords, and the account usernames for the MySQL database and CCHA inventory tracking system. The students began the testing by attacking the IP address 127.0.0.1 over port 80 and using the usernames.txt and passwords.txt files. The results yielded all the possible usernames found in the usernames.txt file and matched them with the passwords from the passwords.txt file. Hydra found that the usernames were compatible with sixteen of the passwords. All of the passwords for MySQL and the CCHA inventory system were chosen, so there were matches with the account usernames and passwords. Figure 10 show the results of the test.

Figure 10. Using username.txt and passwords.txt Files

The second part of this test used the inventory system’s administrator account name xxx.xxxx and the database administrator account spargota instead of the usernames.txt file. Hydra found possible matches with

sixteen passwords for each account. Figure 11 shows those matches.

Figure 11. Using spagota as the Username

4.4 Nessus

All of the test result information in this section was taken from the test reports generated by the Nessus scans.

The host discovery scan gave this result: this plugin attempts to determine if the remote host is alive using one or more ping types:- An ARP ping, provided the host is on the local subnet and Nessus is running over Ethernet.- An ICMP ping.- A TCP ping, in which the plugin sends to the remote host a packet with the flag SYN, and the host will reply with a RST or a SYN/ACK.- A UDP ping (DNS, RPC, NTP, etc).

The host discovery scan did not reveal any threats, it simply provided information that indicated the status of the local host.

The bash shellshock detection scan gave this result: this plugin runs 'netstat' on the remote machine to enumerate open ports. The following ports were found open:Port 68/udp was found to be open. Port 68 / udp Hosts 127.0.0.1 Port 2734/udp was found to be open. Port 2734 / udp Hosts 127.0.0.1Port 8834/tcp was found to be open. Port 8834 / tcp / www Hosts 127.0.0.1Port 11005/udp was found to be open. Port 11005 / udp Hosts 127.0.0.1

The web application test ran the same netstat scan as the bash shellshock detection scan. The result of both tests were the same.

The basic network scan produce many more results and included: the server's X.509 certificate does not have a signature from a known public certificate authority. This situation can occur in three different ways, each of which results in a break in the chain below which certificates cannot be trusted.

First, the top of the certificate chain sent by the server might not be descended from a known public certificate authority, this can occur either when the top of the chain is an unrecognized, self-signed certificate or when intermediate certificates are missing that would connect the top of the certificate chain to a known public certificate authority. Second, the certificate chain may contain a certificate that is not valid at the time of the scan, this can occur either when the scan occurs before one of the certificate's 'notBefore' dates or after one of the certificate's 'notAfter' dates.

Third, the certificate chain may contain a signature that either didn't match the certificate's information, or could not be verified. Bad signatures can be fixed by getting the certificate with the bad signature to be re-signed by its issuer. Signatures that could not be verified are the result of the certificate's issuer using a signing algorithm that Nessus either does not support or does not recognize.

If the remote host is a public host in production, any break in the chain makes it more difficult for users to verify the authenticity and identity of the web server, this could make it easier to carry out man-in-the-middle attacks against the remote host. The solution would be to purchase or generate a proper certificate for this service.

The advanced scan provided the same results as the

basic network scan so the authors chose not to include those results.

From all of the scan results only one vulnerability was identified which was the certificate not being from a known authority. All of the remaining issues were providing information about the system, this information was not relevant to the testing. Figure 12 shows a screenshot of setting up a target for scanning.

Figure 12. Target Scan

5 Recommendations

The security team researched best practices throughout the semester and utilized knowledge obtained from their previous studies. The team recommended two key security elements for CCHA in regards to the finished application. The first recommendation was for CCHA to conduct their own security testing of the product. Security is an ongoing dynamic process and should be integrated into a routine on a regular basis. Because the application was intended to be scalable for use in other areas of the hospital and the application was accessible from outside their intranet by remote web services, the second recommendation was a layered approach for storage purposes. The team suggested that the program be stored on a virtual server in order to mitigate easy access from outside sources. By utilizing a virtual server not only would there be an additional layer of protection but this layer would have a firewall available that could be used for more added security.

6 Summary

The spring 2015 IT 4444 Capstone course gave students the opportunity to apply their abilities in a real-world environment. The cyber security team experienced first-hand how cyber security testing is conducted in a business environment. The team used their knowledge and skills to test the newly developed CCHA inventory tracking system. By utilizing testing tools available to them the security team attempted to ensure a stable and secure application. The tests which were conducted helped identify vulnerabilities that were present in the system and worked with the development team to mitigate the risks. The testing procedures taught valuable hands on skills and processes that could only be experienced in this type of learning environment.

[1] References

Owasp.org,. 'Category:OWASP Top Ten Project - OWASP'. N.p., 2015. Web. 17 Apr. 2015.

[2] PhpMyAdmin. (n.d.). Retrieved April 17, 2015.

[3] Network Penetration Testing and Research, Brandon F. Murphy, NASA John F. Kennedy Space Center, July 2013

[4] VirtualBox, Oracle, N.p. Web. April 1, 2015.

[5] Our Most Advanced Penetration Testing Distribution, Ever. (n.d.). Retrieved April 17, 2015, from https://www.kali.org/

[6] Nessus Vulnerability Scanner. (2012, December 18). Retrieved April 17, 2015.

[7] Web Penetration Testing Using Nessus and Metasploit Tool, Indraneel Mukhopadhyay, Shilpam Goswami, Eshita Manda, ISOR Journal of Computer Engineering, Volume 16 Issue 3, May-June 2014

[8] OWASP Zed Attack Proxy Project, OWASP. N.p. Web. April 1, 2015.

[9] The Basics of Hacking and Penetration Testing: Ethical Hacking and Penetration Testing Made Easy, Second Edition, Patrick Engebretson, page 160-163, Syngress Publishing, 2013

[10] SQLMap Project, SQLMap. N.p. Web. April 1, 2015.

[11] Heuristic-Based Approach for Detecting SQL-Injection Vulnerabilities in Web Applications, Ciampa, Visaggio, Di Penta, SESS ’10 Proceedings of the 2010 ICSE Workshop on Software Engineering for Secure Systems, pages 43-49, 2010

[12] THC-HYDRA - fast and flexible network login hacker. (n.d.). Retrieved April 17, 2015.