1|Page

HALL FORBES PLC

SANDRA BURRIS
Date 01/13/2023
2|Page

Customer Information
Company Name: Rogers and Lane Inc
City: Stanley and Velez Plc State: Quasi ut explicabo Zip Code: Moon and Hess
Traders
URL: Phelps and Mcleod
Traders

Customer Contact Information

Contact Name: Wesley Parker
Title: Eiusmod reiciendis c
Telephone: +1 (572) 908-7405
E-mail: jixinadez@mailinator.com

Consultant Information
Company Name: Serpico Template Report, LLC
Contact Name: Daquan Hays
Title: Voluptas architecto
Telephone: +1 (842) 918-4487
E-mail: paxenow@mailinator.com
Business Address: 123 Paper St
City TestCity State: MA Zip Code: 11111
URL: http://www.serpicoreport.com
 3|Page

1.0 Executive Summary

Serpico Template Company (STC) was contracted to perform a penetration test for Rogers and Lane Inc. This report
discusses the results from the assessment. Really, if you are reading this you should update the template to match your
executive summary. The symbols throughout this report are used to display the data. Please see the README to
understand how they work.

Overall, STC was able to achieve the goals of the assessment and exfiltrate the targeted data. The following table
outlines the critical findings discovered during the assessment:

Finding Name DREAD Score

NIST800-30 Rating table is as follows:

Impact of Threat
Threat Informational Low Moderate High Critical
Likelihood High Informational Low Moderate High Critical
Moderate Informational Low Moderate Moderate High
Low Informational Low Low Moderate Moderate
 4|Page

2.0 Attack Narrative

The following discusses the details of the assessment.
 5|Page

3.0 Findings
3.1 Findings Table
The following were the results from the assessment:

Finding Name NIST800 Rating

SNMP Configured with Default Password
Lack of System Monitoring or Logging
Cross Site Scripting (XSS)
Direct Object References
Path Traversal
Insecure Java RMI Endpoint
End of Life Systems In Use
Internal IP Address Disclosure
Unvalidated redirect
WebDAV
X-Content-Type-Options header missing
Cross Site Scripting (XSS)
Path Traversal
Blind SQL Injection
Blind SQL Injection (timing attack)
Cookie set for parent domain

CRITICAL FINDINGS
The following are all of the Critical Findings from the assessment.
 6|Page

HIGH RISK FINDINGS

The following are all of the Critical Findings from the assessment.
 7|Page

OTHER FINDINGS
The following are all of the Critical Findings from the assessment.
 8|Page

SNMP Configured with Default Password

Likelihood Impact NIST800 RISK

Summary
Simple Network Management Protocol (SNMP) is a protocol used for managing devices on the network. SNMP uses
community stings to access the devices in either read or write mode. While conducting the internal assessment, several
devices were discovered with the default SNMP community stings of private and public.

An adversary can use this access to view or change the devices configuration. In some cases passwords and other
sensitive information can be extracted from the device. This information is used by an attacker access to other systems
within the origination.

Proof
The following screenshot shows information obtained from the vulnerable system <IP>:

<insert a screenshot>

The following IP addresses were confirmed vulnerable:

<insert list of IP addresses>

Remediation
SNMP community stings should be treated the same as account passwords.

It is recommended that <<CUSTOMER>> implement the following password policy for SNMP configured devices:

 Use alphanumeric, special characters and spaces to create the pass phrase
 Use pass phrases at least 32 characters long
 Change the pass phrase frequently
 Do not reuse pass phrases

References
 9|Page

Lack of System Monitoring or Logging

Likelihood Impact NIST800 RISK

Summary
During this assessment it was found that almost no logging or system auditing is in place. A mature system monitoring
and logging process is critical to understand and analyze the implications from a security incident. Furthermore, it is an
important step in the security maturity of an organization.

Proof

Remediation

References
 10 | P a g e

Cross Site Scripting (XSS)

Likelihood Impact NIST800 RISK

Summary
The OWASP guide [1] gives the following description for Cross-Site Scripting:

Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and
trusted web sites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the
form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and
occur anywhere a web application uses input from a user within the output it generates without validating or encoding
it.

An attacker can use XSS to send a malicious script to an unsuspecting user. The end user’s browser has no way to know
that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source,
the malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and
used with that site. These scripts can even rewrite the content of the HTML page.

Proof

Remediation
The following is recommended to remediate XSS vulnerabilities:

 Never trust user input

 Never insert untrusted data except in allowed locations
 HTML escape before inserting untrusted data into HTML element content
 Use whitelists in place for Black lists for input filtering

References
 11 | P a g e

Direct Object References

Likelihood Impact NIST800 RISK

Summary
The OWASP guide [1] gives the following description for Insecure Direct Object Reference:

Applications frequently use the actual name or key of an object when generating web pages. Applications do not always
verify the user is authorized for the target object. This results in an insecure direct object reference flaw. Testers can
easily manipulate parameter values to detect such flaws and code analysis quickly shows whether authorization is
properly verified.

Proof

Remediation
Use per user or session indirect object references. This prevents attackers from directly targeting unauthorized
resources. For example, instead of using the resource’s database key, a drop down list of six resources authorized for the
current user could use the numbers 1 to 6 to indicate which value the user selected. The application has to map the per-
user indirect reference back to the actual database key on the server.

Check access. Each use of a direct object reference from an untrusted source must include an access control check to
ensure the user is authorized for the requested object.

References
 12 | P a g e

Path Traversal

Likelihood Impact NIST800 RISK

Summary
Quoting from [1], a Path Traversal attack aims to access files and directories that are stored outside the web root folder.
By browsing the application, the attacker looks for absolute links to files stored on the web server. By manipulating
variables that reference files with “dot-dot-slash (../)” sequences and its variations, it may be possible to access arbitrary
files and directories stored on file system, including application source code, configuration and critical system files,
limited by system operational access control. The attacker uses “../” sequences to move up to root directory, thus
permitting navigation through the file system.

This attack can be executed with an external malicious code injected on the path, like the Resource Injection attack. To
perform this attack it’s not necessary to use a specific tool; attackers typically use a spider/crawler to detect all URLs
available.

This attack is also known as “dot-dot-slash”, “directory traversal”, “directory climbing” and “backtracking”.

Proof

Remediation

References
https://www.owasp.org/index.php/Path_Traversal

http://cwe.mitre.org/data/definitions/22.html

http://www.webappsec.org/projects/threat/classes/path_traversal.shtml
 13 | P a g e

Insecure Java RMI Endpoint

Likelihood Impact NIST800 RISK

Summary
The following server endpoints use an insecure Java RMI endpoint allowing for unauthenticated remote code execution.

Quoting the exploit discussion from [1], the default configuration of the RMI Registry and RMI Activation services, which
allow loading classes from any remote (HTTP) URL. As it invokes a method in the RMI Distributed Garbage Collector
which is available via every RMI endpoint, it can be used against both rmiregistry and rmid, and against most other
(custom) RMI endpoints as well. Note that it does not work against Java Management Extension (JMX) ports since those
do not support remote class loading, unless another RMI endpoint is active in the same Java process.

RMI method calls do not support or require any sort of authentication.

Proof

Remediation

References
 14 | P a g e

End of Life Systems In Use

Likelihood Impact NIST800 RISK

Summary
A number of End of Life Operating Systems were found on the internal network (e.g. Microsoft Windows XP). The
consultant abused the lack of patching on a subset of these systems to gain a foothold in the internal network.

Proof

Remediation

References
 15 | P a g e

Internal IP Address Disclosure

Likelihood Impact NIST800 RISK

Summary
While reviewing <<CUSTOMER>>'s web server, web servers were discovered to disclose the system's internal IP address
via the Content-Location header. The disclosure of the systems internal IP address gives an adversary an indication of
how the internal network my be addressed.

Proof

Remediation
It is recommended that <<CUSTOMER>> reconfigure their web servers to use the systems fully qualified domain name
(FQDN).

References
 16 | P a g e

Unvalidated redirect

Likelihood Impact NIST800 RISK

Summary
Web applications occasionally use parameter values to store the address of the page to which the client will be
redirected -- for example: 'yoursite.com/page.asp?redirect=www.yoursite.com/404.asp'An unvalidated redirect occurs
when the client is able to modify the affected parameter value in the request and thus control the location of the
redirection. For example, the following URL 'yoursite.com/page.asp?redirect=www.anothersite.com' will redirect to
'www.anothersite.com'.Cyber-criminals will abuse these vulnerabilities in social engineering attacks to get users to
unknowingly visit malicious web sites.The tool has discovered that the server does not validate the parameter value
prior to redirecting the client to the injected value.

Proof

Remediation
The application should ensure that the supplied value for a redirect is permitted. This can be achieved by performing
whitelisting on the parameter value.The whitelist should contain a list of pages or sites that the application is permitted
to redirect users to. If the supplied value does not match any value in the whitelist then the server should redirect to a
standard error page.

References
VulnDB: https://github.com/vulndb/data

https://www.owasp.org/index.php/Top_10_2010-A10-Unvalidated_Redirects_and_Forwards
 17 | P a g e

WebDAV

Likelihood Impact NIST800 RISK

Summary
Web Distributed Authoring and Versioning (WebDAV) is a facility that enables basic file management (reading and
writing) to a web server. It essentially allows the webserver to be mounted by the client as a traditional file system
allowing users a very simplistic means to access it as they would any other medium or network share.If discovered,
attackers will attempt to harvest information from the WebDAV enabled directories, or even upload malicious files that
could then be used to compromise the server.The tool discovered that the affected page allows WebDAV access. This
was discovered as the server allowed several specific methods that are specific to WebDAV ('PROPFIND', 'PROPPATCH',
etc.), however, further testing should be conducted on the WebDAV component specifically as the tool does support this
feature.

Proof

Remediation
Identification of the requirement to run a WebDAV server should be considered. If it is not required then it should be
disabled. However, if it is required to meet the application functionality, then it should be protected by SSL/TLS as well
as the implementation of a strong authentication mechanism.

References
VulnDB: https://github.com/vulndb/data

http://www.webdav.org/specs/rfc4918.html

http://en.wikipedia.org/wiki/WebDAV
 18 | P a g e

X-Content-Type-Options header missing

Likelihood Impact NIST800 RISK

Summary
'X-Content-Type-Options' is a type of HTTP header that can be used to prevent MIME content-sniffing attacks in Internet
Explorer and Google Chrome. MIME content-sniffing is a mechanism that allows browsers to inspect and dynamically
guess the content type and file type.MIME Sniffing checking algorithm has known problems which might allow users to
upload files that might contain malicous code. If an attacker can spoof a file type/content and upload it to the
application successfully, it is possible to inject malicous code which can be downloaded and viewed by other users of the
application. This can lead to attacks such as persistant Cross-Site Scripting.

Proof

Remediation
'X-Content-Type-Options: nosniff' header should be implemented which allows a web server to force the browser into
disabling MIME Sniffing for a served file. The nosniff option will only load any external resource if the content-type
maches what is expected of the file type.

References
VulnDB: https://github.com/vulndb/data

https://msdn.microsoft.com/en-us/library/gg622941(v=vs.85).aspx
 19 | P a g e

Cross Site Scripting (XSS)

Likelihood Impact NIST800 RISK

Summary
The OWASP guide [1] gives the following description for Cross-Site Scripting:

Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and
trusted web sites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the
form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and
occur anywhere a web application uses input from a user within the output it generates without validating or encoding
it.

An attacker can use XSS to send a malicious script to an unsuspecting user. The end user’s browser has no way to know
that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source,
the malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and
used with that site. These scripts can even rewrite the content of the HTML page.

Proof

Remediation
The following is recommended to remediate XSS vulnerabilities:

 Never trust user input

 Never insert untrusted data except in allowed locations
 HTML escape before inserting untrusted data into HTML element content
 Use whitelists in place for Black lists for input filtering

References
 20 | P a g e

Path Traversal

Likelihood Impact NIST800 RISK

Summary
Quoting from [1], a Path Traversal attack aims to access files and directories that are stored outside the web root folder.
By browsing the application, the attacker looks for absolute links to files stored on the web server. By manipulating
variables that reference files with “dot-dot-slash (../)” sequences and its variations, it may be possible to access arbitrary
files and directories stored on file system, including application source code, configuration and critical system files,
limited by system operational access control. The attacker uses “../” sequences to move up to root directory, thus
permitting navigation through the file system.

This attack can be executed with an external malicious code injected on the path, like the Resource Injection attack. To
perform this attack it’s not necessary to use a specific tool; attackers typically use a spider/crawler to detect all URLs
available.

This attack is also known as “dot-dot-slash”, “directory traversal”, “directory climbing” and “backtracking”.

Proof

Remediation

References
https://www.owasp.org/index.php/Path_Traversal

http://cwe.mitre.org/data/definitions/22.html

http://www.webappsec.org/projects/threat/classes/path_traversal.shtml
 21 | P a g e

Blind SQL Injection

Likelihood Impact NIST800 RISK

Summary
Due to the requirement for dynamic content of today's web applications, many rely on a database backend to store data
that will be called upon and processed by the web application (or other programs). Web applications retrieve data from
the database by using Structured Query Language (SQL) queries.To meet demands of many developers, database servers
(such as MSSQL, MySQL, Oracle etc.) have additional built-in functionality that can allow extensive control of the
database and interaction with the host operating system itself. An SQL injection occurs when a value originating from
the client's request is used within a SQL query without prior sanitisation. This could allow cyber-criminals to execute
arbitrary SQL code and steal data or use the additional functionality of the database server to take control of more
server components.The successful exploitation of a SQL injection can be devastating to an organisation and is one of the
most commonly exploited web application vulnerabilities. Injection was detected as it was possible to inject specific SQL
queries, that if vulnerable, result in the responses for each injection being different. This is known as a blind SQL
injection vulnerability.

Proof

Remediation
The only proven method to prevent against SQL injection attacks while still maintaining full application functionality is to
use parameterized queries (also known as prepared statements). When utilising this method of querying the database,
any value supplied by the client will be handled as a string value rather than part of the SQL query.Additionally, when
utilising parameterized queries, the database engine will automatically check to make sure the string being used
matches that of the column. For example, the database engine will check that the user supplied input is an integer if the
database column is configured to contain integers.

References
VulnDB: https://github.com/vulndb/data

http://capec.mitre.org/data/definitions/7.html

http://projects.webappsec.org/w/page/13246963/SQL%20Injection

http://www.w3schools.com/sql/sql_injection.asp

https://www.owasp.org/index.php/Blind_SQL_Injection
 22 | P a g e

Blind SQL Injection (timing attack)

Likelihood Impact NIST800 RISK

Summary
Due to the requirement for dynamic content of today's web applications, many rely on a database backend to store data
that will be called upon and processed by the web application (or other programs). Web applications retrieve data from
the database by using Structured Query Language (SQL) queries.To meet demands of many developers, database servers
(such as MSSQL, MySQL, Oracle etc.) have additional built-in functionality that can allow extensive control of the
database and interaction with the host operating system itself. An SQL injection occurs when a value originating from
the client's request is used within a SQL query without prior sanitisation. This could allow cyber-criminals to execute
arbitrary SQL code and steal data or use the additional functionality of the database server to take control of more
server components.The successful exploitation of a SQL injection can be devastating to an organisation and is one of the
most commonly exploited web application vulnerabilities.This injection was detected as the tool was able to inject
specific SQL queries, that if vulnerable, result in the responses for each request being delayed before being sent by the
server. This is known as a time-based blind SQL injection vulnerability.

Proof

Remediation
The only proven method to prevent against SQL injection attacks while still maintaining full application functionality is to
use parameterized queries (also known as prepared statements). When utilising this method of querying the database,
any value supplied by the client will be handled as a string value rather than part of the SQL query.Additionally, when
utilising parameterized queries, the database engine will automatically check to make sure the string being used
matches that of the column. For example, the database engine will check that the user supplied input is an integer if the
database column is configured to contain integers.

References
VulnDB: https://github.com/vulndb/data

http://capec.mitre.org/data/definitions/7.html

http://projects.webappsec.org/w/page/13246963/SQL%20Injection

http://www.w3schools.com/sql/sql_injection.asp

https://www.owasp.org/index.php/Blind_SQL_Injection
 23 | P a g e

Cookie set for parent domain

Likelihood Impact NIST800 RISK

Summary
HTTP by itself is a stateless protocol. Therefore the server is unable to determine which requests are performed by
which client, and which clients are authenticated or unauthenticated.The use of HTTP cookies within the headers, allows
a web server to identify each individual client and can therefore determine which clients hold valid authentication, from
those that do not. These are known as session cookies.When a cookie is set by the server (sent the header of an HTTP
response) there are several flags that can be set to configure the properties of the cookie and how it is to be handled by
the browser.One of these flags represents the host, or domain. for which the cookie can be used.When the cookie is set
for the parent domain, rather than the host, this could indicate that the same cookie could be used to access other hosts
within that domain. While there are many legitimate reasons for this, it could also be misconfiguration expanding the
possible surface of attacks.

Proof

Remediation
The first step to remediation is to identify the context in which the cookie is being set and determine if it is required by
the whole domain, or just the specific host being tested.If it is only required by the host, then the domain flag should be
set as such. Depending on the framework being used, the configuration of this flag will be modified in different ways.

References
VulnDB: https://github.com/vulndb/data

https://www.owasp.org/index.php/Testing_for_cookies_attributes_(OTG-SESS-002)