Internal Penetration Test Report · PDF fileTools Used in Penetration Testing

Information Security Services Link Mountain, LLC PO Box 182, Port Sanilac MI, 48469 – www.linkmountain.com

Report Date: LONGDATEAuthor: AUTHOR

Link Mountain, LLCPO Box 182, Port Sanilac MI, 48469www.linkmountain.com

Internal Penetration Test Report

For

CLIENTNAME[Your Logo Here]

This is a sample internal report for visualization only. External and application security review reports use the same format.

Report formatting may vary with engagements. Charts given in this sample do not correlate with any actual data or verbiage

contained in this sample.

CONFIDENTIAL Table of Contents This document contains proprietary and confidential information of a highly sensitive nature. Reproduction or distribution without

the express written permission of Link Mountain, LLC or the Client named above is strictly prohibited.

http://www.linkmountain.com/


Contents

Executive Summary ............................................................................................................................................................. 4

Recommendations .............................................................................................................................................................. 4

Management Summary ....................................................................................................................................................... 4

Scope of Testing .................................................................................................................................................................. 5

Testing Details .................................................................................................................................................................... 6 Host Detection ....................................................................................................................................................................... 6 Host Fingerprinting ................................................................................................................................................................ 6 Firewall and Filtering Analysis ................................................................................................................................................ 6 Internet Control Message Protocol (ICMP) ............................................................................................................................ 6 Stateful Firewall Analysis ........................................................................................................................................................ 7 TCP Full Connect Port Scanning .............................................................................................................................................. 8 Source Port Scanning ............................................................................................................................................................. 8 User Datagram Protocol (UDP) ............................................................................................................................................... 8 DNS Zone Transfer ................................................................................................................................................................. 8 Network Perimeter Device Configuration Summary .............................................................................................................. 9 Vulnerability Scanning ............................................................................................................................................................ 9

Scanners Used .................................................................................................................................................................... 9 Summary of Scanning Results ............................................................................................................................................ 9

Penetration Testing .............................................................................................................................................................. 10 Objectives ............................................................................................................................................................................ 10 Tools Used in Penetration Testing ........................................................................................................................................ 10 Test Coverage: Reconnaissance ........................................................................................................................................... 10

Network Test Coverage: NetBios enumeration ................................................................................................................ 10 Network Test Coverage: LDAP ......................................................................................................................................... 10 Network Test Coverage: SNMP Enumeration .................................................................................................................. 10 Network Test Coverage: Open administrative interfaces ................................................................................................. 11 Network Test Coverage: Authentication attacks .............................................................................................................. 11

Wireless Test Coverage ........................................................................................................................................................ 11 Social Engineering Test Coverage ........................................................................................................................................ 12 Application Test Coverage: Information Disclosure ............................................................................................................. 12 Test Coverage: Authentication ............................................................................................................................................ 12 Test Coverage: Authorization ............................................................................................................................................... 13 Test Coverage: Business Logic .............................................................................................................................................. 14 Test Coverage: Data Validation - Reflection Issues ............................................................................................................... 14 Test Coverage: Data Validation – Injection and Miscellaneous ............................................................................................ 14 Test Coverage: Denial of Service .......................................................................................................................................... 15 Test Coverage: Session Handling .......................................................................................................................................... 15 Test Coverage: Encryption .................................................................................................................................................... 16 Test Coverage: Web Services ............................................................................................................................................... 16 Test Coverage: AJAX ............................................................................................................................................................. 17 Test Coverage: Configuration Issues .................................................................................................................................... 17

Finding Details .................................................................................................................................................................. 18

Appendix 1: Severity Levels ................................................................................................................................................... 19

Appendix 2: Severity Levels and PCI Compliance .................................................................................................................... 20





Executive SummaryThe first objective of this internal penetration test was to fully examine the CLIENTNAME systems to identify vulnerabilities that could allow an attacker positioned within the internal network to compromise the confidentiality, integrity or availability of those systems. Our second objective was to safeguard the stability of the CLIENTNAME systems under test. Our third objective was to prove exploitability by pursuing vulnerabilities to the point of compromise. The priority of these objectives dictated that vulnerabilities were not necessarily pursued to the point of full exploitation and compromise. Full exploitation was not pursued if the vulnerability appeared to be systemic, or if remediation was mandatory for PCI compliance, or if exploitation would have jeopardized either full test coverage or the stability of the systems under test.

The Remediation Guidance section, which follows this section, includes information to help with prioritizing and assignment of remediation efforts.

Full details of our findings are found in the Finding Details section of the report; the following is an executive level summary of issues found:

The perimeter, network layer, and host configuration was found to be well secured or configured and no faults were found.

The application layer exposed several vulnerabilities. These application faults comprise the greatest risk to the security of the systems under test. There were no application vulnerabilities that we rated critical in severity, however there were two high severity and four medium severity findings.

Wireless networks were not tested, nor were any tests conducted that involved social engineering. Tests with the potential to produce denial of service were not in scope and not conducted.





Risk Summary: Overall and by CategoryThis chart shows the organizations overall security rating, and status of vulnerabilities by category, after manual testing and removal of all false positives.

Overall Risk Rating: HIGH RISK



PerimeterWeb Services

NetworkConfiguration

ApplicationSocial Engineering

Wireless

0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5

Risk By Category

No RiskLow RiskMedium RiskHigh RiskUntested



Findings by Severity

This chart shows all findings, rated by severity, and is derived from manual testing efforts as well as automated scanning after manual review and removal of false positives.

Vulnerabilities by CategoryThis chart shows the source categories of vulnerabilities identified.



Vulnerabilites by Category

PerimeterWeb ServicesNetworkConfigurationApplicationSocial EngineeringWireless

Cross Domain Referer Leakage Cross-domain script include

Autocomplete EnabledCookie Faults

File Upload FunctionalityPassword Recovery Enumeration

Weak Password ComplexityCross Site Request Forgery

Cross Site Scripting (XSS)

0 0.5 1 1.5 2 2.5 3 3.5 4

Severity By Finding

CriticalHighMediumLowInformational



Remediation Guidance

This section contains guidance for managing remediation of the vulnerabilities identified in this report.

Finding Reports:

The finding details section of this report contains individual finding reports for all of the vulnerabilities identified. Finding reports are also provided as separate pdf documents. This allows you to selectively distribute specific finding reports to the personnel who need them.

Remediation Checklist:

This document is accompanied by a remediation checklist. If you will be requesting a remediation test from us, this document is required and will speed things up considerably by informing us about what you want us to re-test and what steps you took in remediation. If you do not intend to retest, it is still advisable to retain a record of the remediation steps taken. The provided checklist can be used for that purpose.

Prioritization:

Priority of Work RecommendationsThe following chart gives our recommended priority for remediation work. It charts relative return on security investment based on the ratio of remediation effort required, (1-5 scale, in our experience) and the severity of the vulnerability (1-5 scale). The chart shows the ratio of the two (severity divided by remediation effort). The cart is ordered with the highest estimated security return on investment at the top of the chart, with decreasing return on investment to the bottom of the chart.

It is recommended that you correct those vulnerabilities at the top of the chart first.



Cross Domain Referer Leakage Cross-domain script include

Cookie Faults Password Recovery Enumeration

Weak Password ComplexityCross Site Request Forgery

Cross Site Scripting (XSS)Autocomplete Enabled

File Upload Functionality

0 0.5 1 1.5 2 2.5 3

Remediation Priority - Security Return on Investment

Ratio



RecommendationsLink Mountain, LLC recommends that all of the vulnerabilities be remediated, and a remediation test be conducted to verify remediation. If this is a test in support of PCI-DSS compliance, remediation verification is mandatory: (PCI-DSS 11.3.a: Verify that noted vulnerabilities were corrected and testing repeated.).





Scope of Testing

The following CLIENTNAME hosts were in scope and included in this penetration test:

Hosts In Scope (By IP Address)

The following CLIENTNAME applications were in scope and included in this penetration test:

Applications in Scope (By URL)

The following accounts and credentials were provided by CLIENTNAME and used in application testing (if any):

Testing Accounts and Credentials

The following engagement windows were defined for this test:

Engagement Windows

The following testing activities were excluded from scope:

Excluded Testing ActivityWireless TestingSocial EngineeringDenial of Service





Testing Details

Passive Reconnaissance

A brief reconnaissance encompassing both active and passive techniques was conducted using Whois queries, Search engines and other web resources to determine the breadth and depth of information available about the target network, with particular emphasis on harvesting of potential user names and information that could aid in dictionary attacks, phishing and social engineering attacks.

Passive and Active Reconnaissance Information

Host Fingerprinting

By connecting to open ports, we attempted to guess at the type of host and its general purpose. The table below provides a description of the hosts identified and the methods used:

Host FingerPrint Source

Firewall and Filtering Analysis

Internet Control Message Protocol (ICMP)

The most common form of ICMP with which most people are familiar is referred to as ping or echo. Various types of ICMP packets, including echo, timestamp, and netmask address request, were sent to the target hosts.

Firewalls will often be configured to block ICMP echo and echo reply packets, but allow timestamp request and netmask address request packets. Any of these packets can be used to help determine the network configuration of the target host, its operating system, to perform a denial of service (DoS) attack, or as a covert channel to carry information between a compromised host and an attacker. ICMPPLACEHOLDERMSG

ScanType Host State Service

Stateful Firewall Analysis

TCP is the most common form of traffic on the Internet and is the basis for HTTP and File Transfer Protocol (FTP) communication.





TCP packets have numerous options that enable connections to be initiated, acknowledged, and completed. The most commonly used of these flags are SYN, ACK, PSH, RST, and FIN. Operating systems and devices often respond to unusual combinations of these flags in ways that can be used to bypass firewalls and/or to determine the type of operating system or device.

A normal TCP session begins with a three way handshake starting with the session originator with a packet having the flag bits set to SYN. This is responded to by the target with SYN ACK, and finally an ACK packet is sent from the original sender, completing the three way handshake. Originator…SYN >…Target Target…SYN/ACK>…OriginatorOriginator…> ACK…Target

A firewall that is not capable of stateful inspection, such as a simple packet filtering firewall, will block SYN packets from reaching a port that is disallowed, thereby blocking the normal three way handshake, but can allow other flag combinations to pass. A well configured stateful firewall should drop any packet that is not part of an established TCP session or normal handshake sequence to an allowed port. A stateless or poorly configured stateful firewall can allow these abnormal packets through, and the hosts will respond with a RST flag, to reset the session (because the target host has no knowledge of an established session with the originator).

The target hosts were scanned with the flag bits set to ACK. This is an abnormal request, since there was no existing TCP session with the targets. The following table details ports that responded differently with normal packets and abnormal ACK packets. Ports listed as ‘unfiltered’ responded to ACK packets with a RST packet from the target host. If the port is closed for a normal connection, this is the expected result since a closed port is one that responds with a RST packet. If, however, the port is filtered (dropped) for a normal connection and unfiltered for an ACK pack, this indicates that the packet reached the host. This allows attackers to learn about services which may be running on the target, even if it is not reachable for a full connection.

Normal Connect Abnormal ACK OnlyHost Port Proto TCP-SYN-FULL TCP-ACK-1000

TCP Full Connect Port Scanning

We tested the target hosts by scanning all 65,535 tcp ports with normal packets, to determine which ports were open for connection from the internet.

Host Port Proto State Service

Source Port Scanning

Firewalls and other perimeter filtering devices are often configured in a manner to restrict certain types of communication on certain ports. Poorly configured filtering devices can sometimes be mislead into permitting unauthorized packets that were not intended if the attacker uses a port normally associated

CONFIDENTIAL Table of Contents

This document contains proprietary and confidential information of a highly sensitive nature. Reproduction or distribution without the express written permission of Link Mountain, LLC or the Client named above is strictly prohibited.



with FTP, Domain Name Services (DNS), or Kerberos traffic. In the following table, the Ephemeral port column shows the port state for normal TCP full connect traffic using the ephemeral port range. The FTP Data Port and DNS Port columns show the port state for TCP full connect traffic using the FTP Data Port (20/tcp) or DNS Port (53/tcp).

Host Port Proto TCPSYN_FULL TCP-SRC20-1000 TCP-SRC53-1000

User Datagram Protocol (UDP)

UDP is the second most common form of traffic on the Internet and is the basis for most streaming audio and video communication.

Host Port Proto State Service

DNS Zone Transfer

A DNS zone file contains all the naming information that the name server stores regarding a specific DNS domain. This file often includes details of internal networks and other useful information that an attacker can use to build an accurate map of a target network.

Most organizations use more than one name ser ver. The main name server is known as the primary name server and all subsequent name servers are secondary name servers. It is important that each name server have current DNS zone information. To ensure this, a secondary name server requests a zone transfer from the primary server when it is started and also at regular intervals thereafter.

Organizations should configure the primary DNS server to allow zone transfers only when requested from secondary DNS servers and should configure secondary DNS servers to not respond to zone transfer requests at all.

For your information, here are the name servers tested and the responses obtained:

Zone Transfer Attempts

Network Perimeter Device Configuration Summary

Based upon the previously discussed results for host interrogation, including ICMP testing, stateful inspection tests, TCP and UDP port scans, source port scanning and services identified, (summary here).





Vulnerability Scanning

Scanners UsedNessus 4.2.2 (Professional Feed) with up to date signatures was used to scan the target hosts for known vulnerabilities.

Summary of Scanning ResultsFull details of the vulnerability scan are included in the attached report. Significant scanner reported issues were evaluated to eliminate false positives, and any remaining issues are addressed as findings in the Finding Detais section of this report.





Penetration TestingObjectivesThe first objective was maximum test coverage; the second objective was safeguarding the stability of the systems under test, and the last objective was proof of exploitability. The priority of these objectives dictated that vulnerabilities were not necessarily pursued to the point of full exploitation and compromise. Full exploitation was not pursued if the vulnerability appeared to be systemic, or if remediation was mandatory for PCI compliance, or if exploitation would have jeopardized either full test coverage or the stability of the systems under test.

Tools Used in Penetration TestingWeb Scarab was used to spider web applications, conduct selected tests and document test coverage, and custom perl scripts were used for automated fuzzing of application parameters. In addition, extensive manual inspection and manipulation was used.

Network Test Coverage: NetBios enumerationNative Windows Net API commands were used from the testing host to identify and attempt connection to NetBIOS shares.

NetBios Enumeration

Network Test Coverage: LDAPScanning tools were used to identify LDAP servers and, if found, Link Mountain, LLC attempted to enumerate LDAP trees.

LDAP Configuration

Network Test Coverage: SNMP EnumerationScanning tools were used to identify running SNMP agents and guess community strings. MIB walking was attempted for any SNMP agents found using default or easily guessable community strings.

SNMP Enumeration

Network Test Coverage: Open administrative interfacesPorts identified by NMap or scanners were manually tested using a browser or Netcat to manually confirm banner information and to look for open administrative interfaces. Directories discovered by Nikto or other scanning were also examined.

Admin Interfaces





Network Test Coverage: Authentication attacksIf authentication mechanisms were discovered, and a potential user list was also discovered or could be guessed, Link Mountain, LLC conducted either brute force or dictionary attacks.

Authentication Attacks

Wireless Test CoverageWireless testing addressed the following: Access point discovery (including rogue access points), WLAN authentication bypass (including hidden SSID and mac filter bypass), encryption flaws, WLAN infrastructure attacks, wireless client attacks and when present, WPA Enterprise and Radius authentication services.

Wireless Testing SummaryWeak Protocols

Default or Guessable Administrative Credentials

Rogue Access Points

Hidden SSID discovery

MAC filter evasion

Mis-association

Dis-association

Wireless MITM

WPA Enterprise

Social Engineering Test Coverage If in scope, electronic assisted social engineering attacks were attempted. The type of attacks used were dependent on vulnerabilities observed and available information.

Social Engineering Summary





Application Test Coverage: Information Disclosure Web servers and web application roots were tested for the existence of Robots.txt files, and if found, were examined for sensitive data. All pages served by web applications were examined for sensitive information disclosed in HTML comments. Pages were inspected for ‘hidden’ fields to determine if sensitive information was disclosed. All responses received from web servers and applications during testing were inspected for evidence of improper error handling at the application, database and web server layers. Extensive fuzzing was used with inputs designed to produce unhandled exception conditions.

Information Disclosure SummaryRobots.txt No faults found.

Comments All comments were reviewed and no faults were found.

Hidden Fields All hidden form fields were examined and no faults were found.

Error Handling No faults found.

Test Coverage: Authentication Authentication controls were assessed to determine if any common faults existed. Testing included verification of account lockout functionality, and examined password recovery and account creation logic for errors or weakness or disclosure of user accounts, brute force, CAPTCHA devices and race conditions and other common faults.

Authentication SummaryCredential Transport Security

User Account Enumeration

Guessable Accounts

Brute Force and Account Lockout

Authentication Bypass

Password Recovery and Reset.

Password Complexity

Secure Logout

Browser Caching

CAPTCHA





Devices

Multiple Factor Authentication

Race Conditions

Test Coverage: AuthorizationWeb servers and applications were extensively tested for the existence of common directory names that might have been missed in access control logic or have listable content. Traversal techniques were used to determine if web server or operating system faults could be used to bypass application access controls. Access control logic was tested by requesting resources from unexpected application states, particularly after error states were encountered, and manipulation of parameters and parameter names, host header and referrer values.

Authorization SummaryPath Traversal

Authorization Bypass

Privilege Escalation

Test Coverage: Business LogicWeb applications were tested for flaws in business logic specific to the applications.

Business Logic Summary

Test Coverage: Data Validation - Reflection IssuesWeb applications were extensively ‘fuzzed’, and the results were inspected for evidence of unsanitized values reflected back to the client. Header values and cookies were manually manipulated in a similar manner to test for reflection. If found, reflection conditions were tested for persistence and utility for scripting, framing or other reflection based attacks.

Data Validation – Reflection Issues SummaryReflected Cross Site Scripting

Persistent Cross Site Scripting

DOM Based Cross Site Scripting





Cross Site Flashing

Test Coverage: Data Validation – Injection and MiscellaneousWeb applications were extensively ‘fuzzed’, and the results were inspected for evidence of unsanitized input values reaching application or other server side code. Header values, parameter names and cookies were manually manipulated in a similar manner to test for input validation. Testing included values intended for many types of injection as well as overlength and other buffer overrun tests.

Input Validation - Injection and Miscellaneous SummarySQL Injection

LDAP Injection

ORM Injection

XML Injection

SSI Injection

XPath Injection

IMAP/SMTP Injection

Code Injection

OS Commanding

Buffer overflow

Incubated Vulnerabilities

HTTP Splitting/Smuggling

Test Coverage: Denial of ServiceIf in scope, several types of denial of service conditions were tested.

Denial of Service SummarySQL Wildcard Attacks

Account Lockout

Buffer Overflows

User Specified Object Allocation





User Input as a Loop Counter

User Provided Data to Written to Disk

Failure to Release Resources

Test Coverage: Session HandlingSession tokens were evaluated for predictability and checked for reuse in subsequent sessions. GET requests were examined to ensure that session tokens were not passed in query strings. Applications were inspected for mixed use of encrypted and unencrypted transport, to insure that cookies containing session tokens are not sent over clear text channels. Cookies containing session Ids were inspected for correct attributes. Server responses were examined for secure Cache-Control directives, and the application was inspected to determine if authenticated sessions could be abused by Cross Site Request Forgery attacks.

Session Handling SummarySession Predictability

Query Strings

Encrypted Transport

Cookie Attributes

Session Fixation

Session Re-Use

Cache Control

CSRF Vulnerabilities

Test Coverage: EncryptionTesting included verifying the enforcement of appropriate transport encryption, either SSLv3 or TLSv1. Cookies were examined for sensitive information encrypted with weak encryption or encoding schemes.

Encryption SummaryTransport Protocol

Transport Cipher Suites





Support

Other Encryption

Test Coverage: Web ServicesA search was conducted for WSDL files. Any discovered services or known WSDL paths were tested for injection, unhanded error conditions and information disclosure issues common to web services.

Web Services SummaryInformation Gathering

WSDL

XML Structural Testing

XML content-level Testing

HTTP GET parameters/REST Testing

SOAP Attachments

Replay Testing

Test Coverage: AJAXIf AJAX was found to be in use, we tested for the a full range of issues common to AJAX, which includes most of the issues common to conventional web applications including injection, reflection, authentication, authorization, bypass, overrun and other issues.

AJAX SummaryAJAX Vulnerabilities

Test Coverage: Configuration Issues Dirbuster, OpenVAS, Nessus and manual testing was used to find listable directories, common administrative interfaces and configuration errors. Information gained from HTML comments, error messages, Robots.txt files and other sources was manually examined for any information that could help identify code libraries in use. Default interfaces for web servers and any identified third party components were tested for secure configuration and patch levels.

Configuration Issues SummaryDB Listener

Infrastructure





Configuration

Application Configuration

File Extensions Handling

Old, Backup and Unreferenced Files

Admin Interfaces

HTTP Methods and XST





Finding Details

Sample report note: The finding details section contains individual finding reports for all of the vulnerabilities identified.

Finding reports are also provided as separate pdf documents. This allows you to selectively distribute specific finding reports to the personnel who need them. This is a sample to show format – most of our actual finding reports will contain extensive notes and screen captures.

Finding # 1: Finding Title.Severity: MediumTarget(s):Description:Remediation:Test Notes:

Screen Captures:





Appendix 1: Severity LevelsThere are a number of commonly used schemes for rating vulnerability severity; however many of them are rigid and do not consider context. While this has value, our own experience has shown that context matters very much in rating the true significance of any security fault. Our ratings are therefore subject to the context in which the fault is found and ultimately subject to the judgment of our security engineers.

5 severity levels are used in reporting security faults:

CRITICALIn the opinion of our security engineer, the fault puts the application or system at imminent and substantial risk. These faults require immediate attention. These faults are severe and easily discovered by attackers. They are immediately exploitable without combination with any other fault, or may require combination with another fault that has already been observed in the application or system under test. This rating also includes information disclosure where the information itself is confidential or of very high value to an attacker. Examples of the latter include password files, credit card data, source code disclosure or world readable or writable file systems. These faults should receive top priority in remediation.

HIGHFaults that, in the opinion of our security engineer could lead to compromise but are not easily discovered, or require significant time or unusual skill to exploit, or are serious but more limited in impact than a CRITICAL fault. These faults are immediately exploitable without combination with any other fault, or require combination with another fault that has already been observed in the application or system under test. These faults may include high value information disclosure if the information is useful for successful exploitation of another HIGH or CRITICAL fault, such as user account disclosure in combination with no account lockout, a condition that could lead to successful brute force or dictionary attack. These faults should be corrected immediately.

MEDIUMFaults that, in the opinion of our security engineer could lead to compromise, but are difficult to detect, difficult to exploit, are limited in impact or require combination with at least one other fault to be successfully exploited and no such fault has been observed. Also includes high value information disclosure such as stack traces, configuration files, platform error messages, etc. Also, any fault that we know requires remediation for PCI compliance will receive this rating as a minimum. While more severe faults should be corrected first, these are still dangerous faults and should be corrected as soon as possible.

LOWFaults that, in the opinion of our security engineer could aid in developing other attacks, or faults that if exploited would have limited impact. These faults also include information disclosure that may be helpful to an attacker but is of relatively low perceived value. While the relative value to an attacker is considered low, these are still security faults and should be corrected. They often lack only the existence of another fault, a newly discovered exploit, or an application, system or firewall change to take on greater significance.

INFORMATIONALThis severity level is used when our security engineer obtains results that you should know about, but may or may not represent any specific security issue. This severity level is often used when our security engineer must rely on your judgment, for example: when unsecured content or functionality is found, but the security engineer does not know and cannot determine by its nature if it should be (or if you intended it to be) restricted by access controls. You should carefully review all such findings and take corrective action if appropriate.





Appendix 2: Severity Levels and PCI ComplianceThere is no mandated vulnerability rating system for PCI-DSS compliance penetration testing, however all faults that are known to require remediation under PCI-DSS are rated to at least a MEDIUM. Therefore, at a minimum you should plan to correct all MEDIUM and higher faults, and it is recommended that all faults be corrected.

Before formulating a remediation plan, you should consult with your QSA. Your auditor knows your network, systems and applications and thus has an inside perspective that our security engineers do not have when testing for and rating faults. For this reason, faults that we rate as LOW or INFORMATIONAL may be of higher significance to your auditor.




Internal Penetration Test Report · PDF fileTools Used in Penetration Testing

Documents

Transcript of Internal Penetration Test Report · PDF fileTools Used in Penetration Testing