Penetration Testing with Kali Linux OffSec
|
|
Flameshot
206 is an OS-agnostic, open-source, feature-rich screen-capturing tool. It comes with both a command-line and GUI interface and has integrated drawing tools to add highlights, pixelation, text, and other modifications to the captured image. 205 (Wikipedia, 2022), https://en.wikipedia.org/wiki/Snipping_Tool 206 (Flameshot, Github, 2022), https://github.com/flameshot-org/flameshot Penetration Testing with Kali Linux Copyright © 2023 OffSec Services Limited. All rights reserved. 101 5.2 Writing Effective Technical Penetration Testing Reports In this Learning Unit we’ll cover the following Learning Objectives: • Identify the purpose of a technical report • Understand how to specifically tailor content • Construct an Executive Summary • Account for specific test environment considerations • Create a technical summary • Describe technical findings and recommendations • Recognize when to use appendices, resources, and references 5.2.1 Purpose of a Technical Report As vendors of a penetration testing service, we want to provide our clients with as much value as possible. Reports are the mechanism by which value is delivered and the main artifact that enables the client to take forward action. Our ability to find twenty vulnerabilities in a web application won’t make a business impact if we can’t provide a presentation of both the vulnerabilities and our recommendations on potential remediation. Without a clear direction forward, the client is not getting full value for their time and money. To properly prepare a report for the client, we must understand two things: 1. The purpose of the report. 2. How we can deliver the information we’ve collected in a way that the audience can understand. When a client pays for a penetration testing engagement, it is often (mis)understood that they are “just” paying for an ethical hacker to legally attack their infrastructure to find and exploit weaknesses. While that may be technically necessary to deliver the required results, it is not the fundamental purpose of the engagement. There are even some cases in which clients would prefer not to have their infrastructure attacked at all! So, what is the point of a company engaging a penetration tester? The end goal is for the client to be presented with a path forward that outlines and highlights all the flaws that are currently present in their systems within the scope of the engagement, ways to fix those flaws in an immediate sense, and strategic goals that will prevent those vulnerabilities from appearing in the future. This output is often provided in the form of a penetration testing report. As far as the client is concerned, the report is (usually) the only deliverable of the engagement that truly matters. We might wonder how we ought to report on the parts of our engagement where we haven’t found any vulnerabilities. In many cases where we don’t find vulnerabilities, we should avoid including too many technical details on what we did in the report. A simple statement that no vulnerabilities have been found is often sufficient. We should ensure that we don’t confuse the client with the technical details of our attempts, as this will undermine the value of the issues we did actually find It’s the tester’s job to present that information in a way that is easy to understand and act upon. That said, some clients may prefer verbose and deep technical reports even on non-issues, which leads to another consideration: the audience. Penetration Testing with Kali Linux PWK - Copyright © 2023 OffSec Services Limited. All rights reserved. 102 The client receiving the report is an expert in their own specific industry. They will often (though not always) be aware of the security concerns of that industry and will expect us to have done our homework to also be aware of them. In practice, this means having a deep understanding of what would cause concern to the client in the event of an attack. In other words, understanding their key business goals and objectives. This is another reason why being clear on the Rules of Engagement is so important, because it gives us a window into the client’s core concerns. All issues discovered in the course of testing should be documented but we will want to highlight any issues we find that would affect these key areas. Examples of client-specific key areas of concern could include HIPAA, 207 which is a framework that governs medical data in the US, and PCI, 208 which is a framework that governs credit card and payment processing. Let’s consider the following scenario. Assume that Client A is a hospital and Client B is a bank, and we are contracted to perform a test on each of their internal infrastructure. We may come up with similar results for both, and while they may have the same technical severity, we may not necessarily document the findings with the same levels of risk and priority for remediation. Because Client A is a hospital with medical devices connected to their network, doctors and patients who need action to be taken quickly in response to monitoring alerts are very likely to be worried about network up-time and machine readiness. Medical devices connected to the network are often running on old machines with obsolete versions of embedded software. The need for continuous operations may have resulted in these devices missing upgrades and patches. While reporting, the vulnerabilities we find should be highlighted, and then we might make a suggestion to isolate the machines on their own logical subnet given that upgrades or patching cannot be applied promptly. On the other hand, this exact same scenario on Client B’s network could be catastrophic. If a server or device in a bank is missing a patch, that could very well be a foothold into the network. Because systems will need to communicate with other systems on the network, complete segmentation may not be feasible. Therefore, a missing patch is of far greater concern and may need to be reported as a critical issue. As we begin to record our findings, we’ll need to keep in mind the situation under which the vulnerability may be exploited and its potential impact. A clear text HTTP login on the internet is considered extremely unsafe. On an internal network, while still unsafe, it is less concerning given that more steps must be accomplished to properly exploit it. In much the same way, a hospital may not care that their Internet-facing login portal accepts TLS 1.0 ciphers. An eCommerce site is likely to be much more concerned, given the PCI violation that accepting TLS 1.0 creates. As report writers, we must present useful, accurate, and actionable information to the client without inserting our own biases. 5.2.2 Tailor the Content We must deliver skill-appropriate content for all the readers of our report. It may be read by executives, the heads of security, and by technical members of the security team. This means we want to not only provide a simple overview of the issues for the executives, but we will also want to provide sufficient technical detail for the more technical readers. 207 (HIPAA Guidelines, 2022) https://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/index.html 208 (PCI Guidelines, 2022), https://www.pcisecuritystandards.org/ Penetration Testing with Kali Linux PWK - Copyright © 2023 OffSec Services Limited. All rights reserved. 103 We can do this by splitting up content into an appropriate structure of sections and subsections. The number of audiences we have for a particular engagement depends heavily on our relationship with the client, their size, budget, and maturity. For the sake of this Module, we’ll consider an engagement for which we have only two target audiences. The first, and arguably the more important, is the management level. This is often the level at which many external engagement contracts are signed and where the value of investing in the testing needs to be highlighted. Depending on the business, this may be C-level functions (CISO, CSO, CFO, etc), or department heads of IT or security. However, most executives and upper-level directors will not necessarily have the technical ability to follow a detailed technical explanation. We should provide them with a section that highlights the outcome and impact of the engagement in a way that accurately reports on the vulnerabilities found while not being overloaded with technical details. The second audience we will consider is made up of the technical staff who have the technical knowledge to understand the report and implement the remediations outlined for the vulnerabilities that have been identified. This audience must be provided with enough technical detail to enable them to understand what is wrong, what the impact of each finding is, and how they can be fixed. In addition, this audience greatly benefits when we can provide advice on how to prevent similar types of issues from occurring in the future. 5.2.3 Executive Summary The first section of the report should be an Executive Summary. This enables senior management to understand the scope and outcomes of the testing at a sufficient level to understand the value of the test, and to approve remediation. We start with the quick bite-sized pieces of information that provide the big picture, and follow that up with the full Executive Summary. The Executive Summary should start with outlining the scope of the engagement. Having a clear scope agreed upon in advance of the testing defines the bounds of what will be covered. We then want to be very clear as to what exactly was tested and whether anything was dropped from the scope. Timing issues, such as insufficient testing time due to finding too many vulnerabilities to adequately report on, should be included to ensure that the scope statement for any subsequent test is appropriate. Including the scope statement in the report protects the penetration tester from any suggestion of not having completed the required testing. It also gives the client a more accurate model of what is practical given the budget and time constraints that were initially set. Second, we want to include the time frame of the test. This includes the length of time spent on testing, the dates, and potentially the testing hours as well. Third, we should refer to the Rules of Engagement and reference the referee report if a referee was part of the testing team. If denial of service testing was allowed, or social engineering was encouraged, that should be noted here. If we followed a specific testing methodology, we should also indicate that here. Finally, we can include supporting infrastructure and accounts. Using the example of a web application, if we were given user accounts by the client, include them here along with the IP addresses that the attacks came from (i.e our testing machines). We should also note any accounts that we created so the client can confirm they have been removed. The following is an example of this high level structure: Penetration Testing with Kali Linux PWK - Copyright © 2023 OffSec Services Limited. All rights reserved. 104 Executive Summary: - Scope: https://kali.org/login.php - Timeframe: Jan 3 - 5, 2022 - OWASP/PCI Testing methodology was used - Social engineering and DoS testing were not in scope - No testing accounts were given; testing was black box from an external IP address - All tests were run from 192.168.1.2" Yüklə Dostları ilə paylaş:
|