Black Box Penetration Testing For DATIM
20
Black Box Penetration Testing For DATIM v3.2 April 15, 2018 Authors (Team Members): Zach Christensen Jared Porter Kyle Steib 1
Transcript of Black Box Penetration Testing For DATIM
Black Box Penetration Testing
For DATIM v3.2
April 15, 2018
Authors (Team Members): Zach Christensen
Jared Porter
Kyle Steib
1
INTRODUCTION This is the Penetration Testing report in relation to the Capstone Project. This Penetration Test was performed during the spring semester of 2018 for a client (Jim Pollard ), a Research
1
Fellow, who is part of collaboration team of FIA and SUU.. The detailed report about each task and our findings are described below. The purpose of this penetration test is to determine security vulnerabilities in the server configurations and web applications running on the servers specified as part of the scope, in addition to assisting client in developing a training and awareness program. All tests are carried out assuming the identity of a malicious actor or a user with malicious intent.
3.1 EXECUTIVE SUMMARY Our team conducted a penetration test on the DATIM web server. The assessment was conducted from a black box perspective, where our team was only supplied information about the address of the web server and a list of employees. Our team received no additional information, and no other assumptions were made prior to the initiation of this assessment.
3.2 SCOPE The client associated with this penetration test is the Forest Inventory and Analysis (FIA) Program of the U.S. Forest Service. The client has proprietary resources hosted on a web server called DATIM (Design and Analysis Toolkit for Inventory and Monitoring). According to Kesar (2017) defining DATIM as:
DATIM is a collaborative effort between the National Forest System (NFS) and Forest Service (FS) Research and Development (R&D), Forest Inventory and Analysis (FIA), and Ecosystem Management Coordination (EMC) staff. The DATIM core team comprises both R&D and NFS staff from resource inventory and forest planning programs. The DATIM project has four modules:
1. Design Tool for Inventory and Monitoring (DTIM) assists national forests and grasslands and other users in determining objectives, questions, and metrics for monitoring plans.
2. Analysis Tool for Inventory and Monitoring (ATIM) enables users to analyze vegetation data to derive estimates of current conditions and trends on the Forest and surrounding landscapes.
3. Spatial Intersection Tool (SIT) enables users to add spatial attributes to DATIM datasets for use in ATIM.
4. DATIM Compilation System (DCS) enables users to add supplemental Forest Vegetation Simulator (FVS) attributes to DATIM datasets for use in ATIM.
1 Jim Pollard, Research Fellow at SUU.
2
3.3 REPORT CLASSIFICATION In our assessment the team obtained some permission from the client to conduct a portion of the initial deliverables (Phishing and Physical Security) for his SUU Forest Service DATIM team, which comprises of eight undergraduate students working as research assistants. The team lead, Dr. Kesar also met with SUU IT department(Mark Walton) to inform them that capstone students will be using SUU resources to meet the objectives. The planning of this project started in the Fall semester of 2017.
3.4 ASSUMPTION During the writing of this report and the conducting of the penetration test, our team assumes that the address given from client, is a public address accessible by anyone. A NDA and rules of engagement was not signed or documented due to the lack of authority from client. Therefore, the team is bound to the Southern Utah University Policy #11.2 defined as Student Conduct Code (see reference below). 2
3.5 TIMELINE This project’s duration is 15 weeks with the intent to continue the penetration testing with another client. See Appendix B for the detailed timeline of this project.
3.6 SUMMARY OF FINDINGS
Significance Number of Risks
High 2
Medium 2
Low 3
The overall assessment of the DATIM web server appear to be secured. The areas in which the client focus in context of minimizing security vulnerabilities are in the area of physical security and social engineering (Phishing).
2 https://help.suu.edu/uploads/attachments/PP112Student.pdf
3
During the physical security testing, our team was given direct access to employee resources (laptop, printer, and docking station) by the client (for details of access, see weekly reports in Appendix #). The employee laptop contains high to critical risks due to access to:
● Folder traversal from all local users and administrators ● Network credentials in plaintext ● Online usernames and passwords contained in web browser ● All HID ports that were unlocked ● Direct access to create malicious payloads, backdoors, privileged accounts, etc. ● Most critical, the ability to pull all data including information that is confidential in
nature relating to the DATIM project and personal Our team performed a target phishing campaign on employees, and were successful in obtaining valid credentials from one of the eight. In addition, all of the employees clicked and opened the email.
3.7 SUMMARY OF RECOMMENDATIONS Adopt a training and awareness program where the employees are given relevant information
pertaining to each employee role and responsibility, and depending on type of access.
Physical security is
Our team recommends the topics of discussion for training and awareness should include:
● Mismatched name and address in the From field
● Errors such as a misspelling, incorrect grammar, or odd spacing
● Encouragement to take immediate action
● Mismatch between link text and the link address displayed when hovering the mouse
over it
● Intuition or an overall feeling that something isn’t right (for example, you weren’t
expecting it)
4. Methodology The methodology followed by our team is shown in the Figure 1 below.
4
Figure 1 Penetration Testing Methodology
4.1 PLANNING During Planning / Scoping, our team attempts to gather information from open-source tools and public resources in order to learn more about the client (target). Possible information resources include social media, company website, forums, blogs, etc. The following questions were kept in mind:
● What will be tested, and how it will be tested ● Are there any conditions that must be applied while the testing is in progress ● Define limitations while testing is being conducted ● Identify the time period of testing ● Identify objectives that are desired to achieve
Our team performed the penetration test using the black box approach: Black-Box Testing (external)
5
This type of testing is done off site remotely, where the penetration tester uses common “real world” techniques in order to find possible vulnerabilities on a network. This type of testing generally is most effective when performed in conjunction or prior to white-box testing. 3
4.2 NETWORK RANGES TESTED AND THOSE EXCLUDED
Figure: 2 Network Topology Example The above Figure 1, displays an example network topology of DATIM. It is important to understand the network range to be tested and those that are to be excluded. Due to the nature of a penetration test, which involves testing procedures that may disrupt connectivity potentially leading to legal and ethical issues, adverse effects to client systems. The DATIM web server, located at www.fs.fed.us would be tested. All other nodes, both incoming and exiting the DATIM Web Application server are to be excluded.
4.2 EXPLOITATION Utilizing the information that was gathered during the information gathering and data collection phase, the team began looking for vulnerabilities and specific targets to attack. These targets were used in the phishing campaign.
4.3 REPORTING The team’s risk rating is as follows:
Risk = Impact * Probability
3 THREE DIFFERENT SHADES OF ETHICAL HACKING: BLACK, WHITE AND GRAY. (2018). Sans.org. Retrieved 12 April 2018, from https://www.sans.org/reading-room/whitepapers/hackers/shades-ethical-hacking-black-white-gray-1390
6
● Low probability = Would hardly ever happen.
● Medium probability = Could happen.
● High probability = Will most likely happen.
● Low impact = One day’s worth of work with no client impact.
● Medium impact = A week’s worth of work with two out 100 clients impacted.
● High impact = An ongoing effort to remediate an issue across all clients.
Impact High = 3 Medium High High
Medium = 2 Low Medium High
Low = 1 Low Low Medium
Low Medium High
Probability
Table 4.1 Risk Analysis
5. Detail Findings
5.1 PORT INFORMATION The server was found to have no vulnerable ports open. Linux Server (nmap -A www.fs.fed.us)
Open Ports
Port # Protocol Service Name
80 TCP HTTP
443 TCP HTTPS
Table 5.1 Ports
7
5.2 VULNERABILITY ANALYSIS
Secure Pages Include Mixed Content Description The page includes mixed content, that is content accessed via HTTP instead of HTTPS. Probability Low Impact Medium Risk Rating Medium Recommendation A page that is available over SSL/TLS must be comprised completely of content which is transmitted over SSL/TLS. The page must not contain any content that is transmitted over unencrypted HTTP. This includes content from third party sites. Reference https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet
X-Frame-Options Header Not Set
Description X-Frame-Options header is not included in the HTTP response to protect against 'ClickJacking' attacks. Probability
8
Low Impact Medium Risk Rating Medium Recommendation Most modern Web browsers support the X-Frame-Options HTTP header. Ensure it's set on all web pages returned by your site (if you expect the page to be framed only by pages on your server (e.g. it's part of a FRAMESET) then you'll want to use SAMEORIGIN, otherwise if you never expect the page to be framed, you should use DENY. ALLOW-FROM allows specific websites to frame the web page in supported web browsers). Reference http://blogs.msdn.com/b/ieinternals/archive/2010/03/30/combating-clickjacking-with-x-frame-options.aspx
Cross-Domain JavaScript Source File Inclusion Description Pages include one or more script files from a third-party domain. Probability Low Impact Low Risk Rating Low Recommendation Ensure JavaScript source files are loaded from only trusted sources, and the sources can't be controlled by end users of the application.
Web Browser XSS Protection Not Enabled
Description Web Browser XSS Protection is not enabled, or is disabled by the configuration of the 'X-XSS-Protection' HTTP response header on the web server Probability
9
Low Impact Low Risk Rating Low Recommendation Ensure that the web browser's XSS filter is enabled, by setting the X-XSS-Protection HTTP response header to '1'. Reference https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet https://blog.veracode.com/2014/03/guidelines-for-setting-security-headers/
Private IP Disclosure Description A private IP (such as 10.x.x.x, 172.x.x.x, 192.168.x.x) or an Amazon EC2 private hostname (for example, ip-10-0-56-78) has been found in the HTTP response body. This information might be helpful for further attacks targeting internal systems. Probability Low Impact Low Risk Rating Low Recommendation Remove the private IP address from the HTTP response body. For comments, use JSP/ASP/PHP comment instead of HTML/JavaScript comment which can be seen by client browsers. Reference https://tools.ietf.org/html/rfc1918
10
Phishing Campaign Description Phishing techniques included the use of open-source resources. Several templates were drafted and then used in an attempt to gather information and credentials (see Appendix A). The list of emails included:
● [email protected] ● [email protected] ● [email protected] ● [email protected] ● [email protected] ● [email protected] ● [email protected] ● [email protected]
Probability High Impact High Risk Rating High Recommendation Develop a training and awareness program to incorporate techniques in identifying possible phishing attacks. Reference IEEESecurityPrivacy-SpearPhishing-Jan-Feb2014.pdf. (2014, January 10). Retrieved from https://www.computer.org/cms/Computer.org/ComputingNow/pdfs/IEEESecurityPrivacy-SpearPhishing-Jan-Feb2014.pdf
Physical Security Test Description “Physical” in this context means that a maliciou actor has physical access to a machine. If a threat actor has physical access to a machine, it negates all other security measures. Probability Low
11
Impact Severe Risk Rating High Recommendation Keep doors locked when a trusted member is not in the room. Implement proper policies for access control to ensure proper security. Do not allow untrusted peripherals to be connected to any machine on the network. Follow a checklist to ensure proper security implementation. (See reference below) Reference https://www.sans.org/reading-room/whitepapers/awareness/data-center-physical-security-checklist-416
Appendices
Appendix A Detailed Technical Findings – Forest Service
12
SSL Certificate Certificate:
Data: Version: 3 (0x2) Serial Number: 0e:84:c3:bb:f2:10:85:42:fe:8e:f2:22:f9:9c:61:e5
Signature Algorithm: ecdsa-with-SHA256 Issuer: C=US, O=DigiCert Inc, CN=DigiCert ECC Secure Server CA Validity Not Before: Mar 1 00:00:00 2018 GMT Not After : Feb 15 12:00:00 2019 GMT Subject: C=US, ST=District Of Columbia, L=Washington, O=U.S. Department of Agriculture, CN=www.fs.fed.us Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) pub: 04:9b:7f:99:93:9e:ce:6f:b7:66:3f:63:74:cc:41:
13
c4:54:28:fa:de:7e:f2:ff:d6:9f:25:e5:ac:2f:c4: 96:38:12:3f:95:83:65:0e:bb:ef:c9:c0:f9:66:d7: c4:b4:40:a6:89:7d:d3:af:1a:94:48:20:f2:0b:ba: c0:dc:34:be:ec ASN1 OID: prime256v1 X509v3 extensions: X509v3 Authority Key Identifier: keyid:A3:9D:E6:1F:F9:DA:39:4F:C0:6E:E8:91:CB:95:A5:DA:31:E2:0A:9F X509v3 Subject Key Identifier: 62:98:86:DD:29:80:9B:EA:BD:CF:7C:9B:A3:EB:14:69:32:93:40:6D X509v3 Subject Alternative Name:
DNS:www.fs.fed.us, DNS:www.treesearch.fs.fed.us, DNS:www.fia.fs.fed.us, DNS:fhm.fs.fed.us, DNS:www.ncrs.fs.fed.us, DNS:fia.fs.fed.us, DNS:www.fhm.fs.fed.us, DNS:treesearch.fs.fed.us, DNS:ncrs.fs.fed.us, DNS:www.fs.usda.gov, DNS:nrs.fs.fed.us, DNS:www.roadless.fs.fed.us, DNS:roadless.fs.fed.us, DNS:fpl.fs.fed.us, DNS:www.nrs.fs.fed.us, DNS:www.fpl.fs.fed.us
X509v3 Key Usage: critical Digital Signature X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication X509v3 CRL Distribution Points: Full Name: URI:http://crl3.digicert.com/ssca-ecc-g1.crl Full Name: URI:http://crl4.digicert.com/ssca-ecc-g1.crl X509v3 Certificate Policies: Policy: 2.16.840.1.114412.1.1 CPS: https://www.digicert.com/CPS Policy: 2.23.140.1.2.2 Authority Information Access: OCSP - URI:http://ocsp.digicert.com CA Issuers - URI:http://cacerts.digicert.com/DigiCertECCSecureServerCA.crt X509v3 Basic Constraints: CA:FALSE 1.3.6.1.4.1.11129.2.4.2:
......u..K..u.`..Bi....f..~_.r....{.z......a...u.....F0D. Pm4..}.k}...Ks,.........[......]. &.....y;....T......u./.........}.w..u..Y|..C._..n.V.GV6.J.`....^......a.........H0F.!...7Q....D..#[email protected]..!..[...^.......F.'|..F.W.1..3.w^.. Signature Algorithm: ecdsa-with-SHA256
30:64:02:30:56:87:aa:a3:03:41:ea:49:20:68:0b:f4:9c:12: 7d:e4:fe:4d:9c:bb:ae:13:4b:1d:f5:b7:c6:f7:e4:2e:51:9c: 4f:ab:62:2f:9d:a9:4c:a2:bd:48:ae:e0:66:51:b2:83:02:30: 1c:28:ba:16:c1:5a:16:5d:b0:00:8f:ef:c2:a5:26:24:70:33: 61:b8:a1:5c:46:36:c7:96:5e:10:13:91:66:0c:50:58:da:fa: fa:2f:e9:cb:15:28:62:dc:82:04:1d:4b
14
15
16
17
Appendix B - Timeline of Project January 11, 2018 – February 15, 2018
● Planning and information gathering stages. February 1, 2018
● Input from the client on the project timeline and information gathered. February 18, 2018 – March 8, 2018
● Data gathering with client, such as names to test in phishing attempts. ● Researching SANS reports and other examples of penetration testing and how we can
implement that into our process. March 12, 2018 – March 29, 2018
● Present updates to the client. ● Physical security tests the client’s laptop to see what information could be found.
o Test done on March 29 from 3:00-4:00 PM. ● Send a phishing email to a list of names provided by the client.
April 5, 2018 – April 12, 2018 ● Finish up any social engineering attempts during this period. ● Share further progress with the client and recommend further practices.
April 12, 2018 – April, 26, 2018 ● Update this document as well as tie up any other loose ends discovered through the
process. ● Prepare for a final presentation on April 26 with client and Capstone course.
Appendix C - Glossary Target Discovery and Vulnerability Scanning: This stage provides information to the penetration tester about possible operating systems, network topology, technologies being used, running services, open ports, and other possible weaknesses that may be exploited. Social Engineering: The ‘human element’ or the weakest link in most cases, will be put to test using different deceptive techniques. This stage may include no-tech hacking, phishing, tailgating, pretexting (impersonation), baiting, and or dumpster diving. These attacks may be carried out in person, over the phone, by computer, or other technologies (wireless). Physical Security: This stage is one that it overlooked by many, due to its lack in technology. Tests performed in this stage involve examining the perimeter. Possible physical layers include fences, man traps, safe locks, key cards, barriers protecting assets, etc. Target Exploitation: Once a target has been defined, using the information provided in the other stages will be used in an attempt to exploit or attack the target. *IMPORTANT* All exploits or attacks used must have a target that was or has been defined by a previous stage. There should be NO irrational targets exploited or attacked. Privilege Escalation / Persistence: After a successful exploitation has been made on a target, testing the duration of access or maintaining access and attempts to escalate privileges will be conducted.
18
Target Discovery and Vulnerability Scanning: A Whois report was completed for target discovery. Whois is a database that is open to the public which lists IP addresses, DNS servers, Locations, and the name of the person who registered the site. This is helpful when determining which IP address needs to be scanned. A vulnerability scan was outside the scope of this project for we did not have proper permission to conduct such tests. However, tools that may have been used to determine the application’s security are Nmap, openVas, and owaspZap. Many tools exist for web application testing but these are the basic ones. These tools would help in determining different attack vectors which could be used to exploit the server. Social Engineering: For these, we drafted phishing emails and sent it to 8 of the student workers for our client and kept track of how they would respond. We were successfully able to send 1 email that was meant to be an obvious phishing attempt, and had a user give us their credentials in this process. Every user we sent this email to opened it, but only 1 clicked the link and signed in. This user was then prompted to change their password and from telling the user that their password had been compromised, we no longer had the option to send phishing emails. This was because of two reasons, the first being we did not have permission to keep sending them from the head of SUU IT Security, and the next was that once one user found out, the rest of the students would be aware of the phishing campaign alter what results would have been. (The templates and drafts of these emails are in Appendix G while more details are shown in Section 4 - Results.) Physical Security: For this, we received access to the clients computer and were told to see what we could find. Our client took us to his office on SUU’s campus to access his laptop that SUU has given him. The laptop was a Windows 8 machine on a docking station connected to Southern Utah Universities network. The client wanted to stay with us as he had personally identifiable information (PII) on the machine and wanted to let us know when we got close so we would not get to it. When we booted the computer, the computer had many users on it, one of which was the user “SUU”. This user is a known user to many on campus for all laptops, so we were able to access this account. From that point, when we signed in, we discovered this user was an Administrator on the machine. From this point, we were able to access any files on the users machine. We attempted pulling the network cable to see if we could find more information without alerting any possible security measures from that point forward with no luck. Once we described this to the client and showed him what we can gain access to, he requested we stop as the physical test was a success and that was all they feel they needed to know. Target Exploitation: Around this step is when the project started to slow down. With the client being in the room with the security test, as well as one person falling for the phishing email, we were unable to continue with the exploitation stage after a very short period. The main goal was to provide feedback to the client of the vulnerabilities found, but not to actually exploit the vulnerabilities. We attempted to exploit a few things in the physical security test, such as running powershell commands and other commands to see if we could find other network information, but this was done without the Ethernet cable plugged in from the docking station. The results of this exploitation attempt were then concluded to not be useful. Privilege Escalation / Persistence: As mentioned in the previous step, without any useful exploitation of vulnerabilities, we were unable to do this step. Privilege escalation and persistence are to be done on any successful exploits, so without those this step was not done.
19
20
