271 lines
16 KiB
Typst
271 lines
16 KiB
Typst
#import "@preview/diagraph:0.3.6": render
|
||
|
||
#import "helper.typ"
|
||
|
||
#let cover(title, place, author) = {
|
||
// Define page
|
||
set page(
|
||
paper: "a4",
|
||
background: [
|
||
#image("title.png")
|
||
],
|
||
margin: (
|
||
top: 50%
|
||
)
|
||
)
|
||
// Reset counter
|
||
counter(page).update(n => n - 1)
|
||
|
||
text(size: 32pt, [
|
||
#text("Penetration Test Report")\
|
||
#text(title, weight: "black")
|
||
])
|
||
|
||
v(0pt)
|
||
|
||
text(size: 16pt, [
|
||
#place, #datetime.today().display("[day].[month].[year]") • #author
|
||
])
|
||
}
|
||
|
||
#let legal(author) = {
|
||
// Define page
|
||
set page(
|
||
paper: "a4",
|
||
)
|
||
// Reset counter
|
||
counter(page).update(n => n - 1)
|
||
|
||
block(height: 1fr)
|
||
|
||
show heading: it => {
|
||
v(1em)
|
||
par(text(it.body, fill: gray))
|
||
}
|
||
text(fill: silver,
|
||
[
|
||
#heading(level: 2, outlined:false, "Report Version & Authorship")
|
||
|
||
#table(
|
||
columns: (15%, 15%, 40%, 30%,),
|
||
align: center,
|
||
stroke: gray,
|
||
[*Version*], [*Date*], [*Author*], [*Changes & Comment*],
|
||
[#helper.placeholder("Draft")], [#helper.placeholder("01.01.1970")], [#helper.placeholder(author)], [#helper.placeholder("Some")]
|
||
)
|
||
|
||
#heading(level: 2, outlined:false, "Classification")
|
||
This report and all associated materials are strictly confidential and may be communicated and/or distributed by the Client only with written approval of the author. All report data, including findings and recommendations, may be stored encrypted in the author's secure archive for a minimum of 3 months post-engagement, in compliance with applicable data protection regulations.
|
||
|
||
#heading(level: 2, outlined:false, "Legal Disclaimer")
|
||
This report constitutes the professional findings of a penetration test conducted under the scope and terms agreed upon by the client. All results reflect the state of security vulnerabilities as assessed during the engagement using standardized methodologies and tools. The findings presented are not guarantees of security or compliance; they represent identified weaknesses which may require remediation as by the professional impression of the author.
|
||
|
||
The client is responsible for interpreting these findings within their operational context and for implementing appropriate security measures. No liability is assumed for actions taken based on this report. This assessment does not constitute security certification, and its results are valid only for the scope and timeframe of the engagement. Neither the contents of this document nor the expressions of the author in any form are legal advice.
|
||
])
|
||
}
|
||
|
||
#let toc() = {
|
||
outline(
|
||
title: "Table of contents",
|
||
indent: 10pt,
|
||
depth: 2
|
||
)
|
||
}
|
||
|
||
#let managementSummary(target: str, targetInSentence: str, testFocus: str, testObject: str, testScenario: str, recommendation: str) = {
|
||
[
|
||
= Management Summary
|
||
|
||
== Motivation
|
||
|
||
This penetration test was conducted to proactively identify, assess, and validate the severity of security vulnerabilities within the defined scope of #targetInSentence, specifically those exploitable by #testFocus. Adversarial techniques to bypass controls, gain unauthorized access, and compromise critical assets were performed for this test scenario to determine the actual impact on confidentiality, integrity, and availability.
|
||
|
||
== Test Object
|
||
|
||
#testObject
|
||
|
||
== Test Methodology
|
||
|
||
The aim of the test was to uncover vulnerabilities and weaknesses of all kinds. These were carried out in accordance with the OWASP Web Security Testing Guide, version 4#footnote("https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing"), and, where applicable, the MITRE ATT&CK Framework#footnote("https://attack.mitre.org"). Recommendations for system hardening were made based on the current version of the CIS Benchmarks#footnote("https://www.cisecurity.org/") and the appropriate variant in each case.
|
||
|
||
The penetration test was performed as a #testScenario.
|
||
|
||
== Findings
|
||
|
||
The penetration test revealed #context([
|
||
#let num = helper.riskCategoryStats.values().map(v => v.final()).sum()
|
||
#if num == 1 {
|
||
[ #num finding ]
|
||
} else {
|
||
[ #num findings ]
|
||
}
|
||
]) which can be categorized by risk:
|
||
|
||
#table(
|
||
columns: (16.66%, 16.66%, 16.66%, 16.66%, 16.66%, 16.66%),
|
||
align: center,
|
||
[Critical], [High], [Medium], [Low], [None], [Other],
|
||
table.cell(context(helper.riskCategoryStats.Critical.final()), fill: red, align: center),
|
||
table.cell(context(helper.riskCategoryStats.High.final()), fill: orange, align: center),
|
||
table.cell(context(helper.riskCategoryStats.Medium.final()), fill: yellow, align: center),
|
||
table.cell(context(helper.riskCategoryStats.Low.final()), fill: lime, align: center),
|
||
table.cell(context(helper.riskCategoryStats.None.final()), fill: white, align: center),
|
||
table.cell(context(helper.riskCategoryStats.Other.final()), fill: gray, align: center),
|
||
)
|
||
|
||
== Recommendations & Next Steps
|
||
|
||
#recommendation
|
||
]
|
||
}
|
||
|
||
#let scopeAndSetup(target: str, start: str, end: str, setup: str, nodes: str, scope: array) = {
|
||
[
|
||
== Test Scope and Setup
|
||
|
||
#if start != "" {
|
||
if end != "" {
|
||
[ The test was conducted from #start to #end. ]
|
||
} else {
|
||
[ The test was conducted on #start. ]
|
||
}
|
||
}
|
||
|
||
#setup
|
||
|
||
The following scope was set for the penetration test:
|
||
|
||
#table(
|
||
columns: (25%, 50%, 25%),
|
||
align: center,
|
||
[*Type*], [*Value*], [*State*],
|
||
..for (i, value) in scope.enumerate() {
|
||
(
|
||
table.cell(value.type),
|
||
table.cell(value.content),
|
||
if value.inScope {
|
||
table.cell("In scope", fill: lime, align: center)
|
||
} else {
|
||
table.cell("Out of scope", fill: gray, align: center)
|
||
}
|
||
)
|
||
}
|
||
)
|
||
|
||
#if nodes != "" {
|
||
[ From the perspective of the machine used for the penetration test, the network layout was seen as shown in the graph below - simplified by leaving out hops that are not relevant for the penetration test, like third-party network operators and ISPs. ]
|
||
|
||
figure(
|
||
render("
|
||
digraph G {
|
||
rankdir=LR;
|
||
node [shape=rectangle];
|
||
|
||
" + nodes + "
|
||
}
|
||
"),
|
||
caption: [
|
||
Schematic graph showing the test objective network
|
||
]
|
||
)
|
||
}
|
||
]
|
||
}
|
||
|
||
#let ciaAppendix() = {
|
||
[
|
||
== CIA Triad
|
||
|
||
The CIA triad is a fundamental framework for information security that encompasses three important principles: confidentiality, integrity, and availability. In this report, each of the three principles is used to highlight specific aspects of the security implications for the area under observation. All three principles are explained in more detail below.
|
||
|
||
=== Confidentiality (C)
|
||
The principle of confidentiality means that information is only accessible to authorized users or entities. It protects sensitive data from unauthorized access or disclosure through measures such as encryption, access controls, and data classification. By maintaining confidentiality, companies reduce the risks of data breaches and unauthorized disclosure, thereby preserving the privacy and trustworthiness of their information assets.
|
||
|
||
=== Integrity (I)
|
||
Integrity preserves the accuracy, consistency, and reliability of data. It prevents unauthorized changes, deletions, or falsifications through techniques such as checksums, digital signatures, and access controls. By maintaining data integrity, companies ensure the reliability and credibility of their information assets, thereby minimizing the risk of fraud or manipulation.
|
||
|
||
=== Availability (A)
|
||
Availability ensures the smooth and reliable provision of information. Potential interruptions to services, systems, or networks are mitigated through redundancy, failover mechanisms, and disaster recovery planning. By maintaining high availability, companies maintain operational continuity and user satisfaction by mitigating the impact of downtime or failures. At the same time, the unavailability of information can have serious consequences, such as lost revenue.
|
||
]
|
||
}
|
||
|
||
#let cvssAppendix() = {
|
||
[
|
||
== Common Vulnerability Scoring System (CVSS)
|
||
|
||
The Common Vulnerability Scoring System (CVSS) provides a standardized, vendor- and platform-agnostic methodology for quantifying the technical severity of software, hardware, and firmware vulnerabilities. Its outputs deliver numerical scores that contextualize a vulnerability’s risk relative to others, facilitating consistent prioritization across diverse systems. CVSS is structured around three interdependent metric groups: *Base*, *Temporal*, and *Environmental*. The Base Score captures the inherent characteristics of a vulnerability (e.g., exploitability, impact), assigning it a severity rating under idealized conditions. Temporal Metrics dynamically adjust this base score based on time-sensitive factors like exploit availability or the existence of patches. Finally, Environmental Metrics tailor the severity assessment to an organization’s specific deployment, accounting for mitigations, criticality of affected assets, and other contextual factors unique to the environment.
|
||
|
||
The only metric group that can be calculated without deep knowledge of the environment and situation is the Base Score, as the Base Score reflects intrinsic vulnerability characteristics (e.g., exploit complexity, impact on confidentiality/integrity) and is designed to be vendor-neutral and environment-agnostic. It does not account for the specific client’s infrastructure, patch status, or operational context. Since a penetration test reports on a single target environment, the Base Score represents the objective severity of the flaw within the scope of the test (e.g., "this flaw could be exploited in this network").
|
||
|
||
The version of the Common Vulnerability Scoring System used in this report is 3.1#footnote("https://www.first.org/cvss/v3-1/user-guide").
|
||
|
||
=== Attack Vector (AV)
|
||
|
||
This metric quantifies how remotely an attacker can exploit a vulnerability, directly influencing the Base Score:
|
||
|
||
- *Network (N)*: Highest severity. Attack possible from anywhere on the internet (e.g., sending a malicious packet across routers).
|
||
- *Adjacent (A)*: Moderate severity. Exploit limited to local networks (e.g., same subnet, Bluetooth/Wi-Fi, or secure VPN).
|
||
- *Local (L)*: Lower severity. Requires local access (console/SSH) or user interaction (e.g., phishing a document).
|
||
- *Physical (P)*: Lowest severity. Requires direct physical contact (e.g., evil-maid attacks, cold boot, DMA via USB).
|
||
|
||
=== Attack Complexity (AC)
|
||
|
||
This metric quantifies the technical difficulty of exploiting a vulnerability, independent of user interaction. It directly impacts the Base Score:
|
||
|
||
- *Low (L)*: Attack is repeatable and predictable with no special conditions. Example: Exploiting a buffer overflow in a service accessible via network.
|
||
- *High (H)*: Exploit requires attacker preparation or external factors, reducing reliability. This may include:
|
||
- Gathering target-specific knowledge (e.g., configuration settings, shared secrets).
|
||
- Overcoming mitigations (e.g., race conditions, anti-exploit techniques).
|
||
- Network manipulation (e.g., man-in-the-middle attacks).
|
||
- Example: Exploiting a flaw requiring a victim’s browser to accept a malicious file.
|
||
|
||
=== Privileges Required (PR)
|
||
|
||
This metric measures the attacker’s initial access level needed to exploit a vulnerability, directly impacting the Base Score:
|
||
|
||
- *None (N)*: Highest severity. Exploitable by unauthorized attackers with no prior access (e.g., unauthenticated web attack).
|
||
- *Low (L)*: Moderate severity. Requires basic user privileges (e.g., standard account access to non-sensitive resources).
|
||
- *High (H)*: Lowest severity. Needs administrative privileges to access critical system settings/files (e.g., root/superuser access).
|
||
|
||
=== User Interaction (UI)
|
||
|
||
This metric assesses whether a vulnerability requires human involvement (beyond the attacker) to be exploited, directly influencing the Base Score:
|
||
|
||
- *None (N)*: Highest severity. Exploitable without user action (e.g., automated network attack).
|
||
- *Required (R)*: Lower severity. Requires user interaction (e.g., clicking a malicious link or installing software).
|
||
|
||
=== Scope (S)
|
||
|
||
This metric determines if a vulnerability breaches security boundaries, allowing impact on components outside its original security scope (e.g., an app exploiting a database). Directly impacts Base Score severity:
|
||
|
||
- *Unchanged (U)*: Lowest severity. Vulnerability only affects resources within the same security authority (e.g., a web app affecting its own files).
|
||
- *Changed (C)*: Highest severity. Vulnerability crosses security boundaries, impacting components under different authorities (e.g., a compromised web server accessing a database).
|
||
]
|
||
}
|
||
|
||
#let boxAppendix() = {
|
||
[
|
||
== Appendix: Penetration Testing Box Scenarios
|
||
|
||
Penetration testing engagements are classified by the level of information provided to the testing team. This classification directly impacts the methodology, scope, and findings. The three standard scenarios are *Black Box*, *Grey Box*, and *White Box*. While Black Box and White Box refer to quite clear and precise situations, Grey box is a bit vague, in-between of both. Due to this, these terms should always be interpreted in the current situation and not be seen as precise and clear terminology. Nonetheless, the selection of the box scenario directly determines the scope of findings and realism of threat simulation. Black box tests external risks, grey box evaluates insider-adjacent threats, and white box provides the deepest technical analysis.
|
||
|
||
=== Black Box Testing
|
||
|
||
The testing team has no prior knowledge of the target system (e.g., internal architecture, source code, credentials, or network topology). Testing simulates an external attacker with only publicly available information. The purpose is to evaluate realistic attack surfaces, unpatched vulnerabilities exposed to the internet, and the effectiveness of perimeter defenses.
|
||
|
||
For example: a penetration test against a company’s public-facing e-commerce website (`www.maride.inv`). Testers are provided only the domain name and must identify vulnerabilities using only publicly available and gathered information. No access to internal systems or credentials is granted.
|
||
|
||
=== Grey Box Testing
|
||
|
||
The testing team is provided limited, realistic information (e.g., user credentials, network diagrams, or documentation). This simulates a threat actor with compromised credentials or insider access. The purpose is to bridge the gap between external and internal testing; uncover vulnerabilities exploitable by authenticated users or partial insider knowledge.
|
||
|
||
For example: testing a corporate web application where testers are given a low-privileged user account (e.g., "standard employee" credentials). Testers identify issues like privilege escalation, insecure data handling, or business logic flaws that an internal user could exploit.
|
||
|
||
=== White Box Testing
|
||
|
||
The testing team has complete, detailed access to the target system (e.g., source code, infrastructure diagrams, credentials, and system configurations). This simulates a highly motivated insider threat with deep system knowledge. The purpose is to perform exhaustive code-level analysis, identify root causes of vulnerabilities, and validate secure development practices.
|
||
|
||
For example: reviewing the source code of a custom mobile banking application. Testers are provided full access to the code repository, database schemas, and API documentation to identify flaws like hardcoded secrets, cryptographic misconfigurations, or insecure API endpoints.
|
||
]
|
||
}
|