FortiPenTest Exploit Engine
Penetration testing helps organizations identify weaknesses and security gaps so they can put mitigation in place before attackers can exploit them. Given that the average cost of a breach worldwide now exceeds $3.8 million, and over $8.6 million per event in the US, penetration testing’s valued is clear.
FortiGuard Labs provides multiple services and tools to help organizations evaluate the relative security of their systems and networks. FortiPenTest is a cloud-based penetration-testing-as-a-service tool based on the OWASP Top 10, the standard framework used by developers and web application security solutions to ensure they have the right defenses in place against the most prevalent threats. The same framework is also used by systems analysts and penetration testers to find issues before attackers can exploit them.
FortiPenTest v21.2 introduces an exploit engine, FortiPenTest Scripting Engine (FSE), that enables security practitioners to explore potential application vulnerabilities hosted on a target network and determine the exploitability of any applications found to be vulnerable. This critical feature enables FortiPenTest to more accurately simulate real-world attacks, and gives developers and security teams more insights into how a typical attack scenario might be carried out by adversaries.
Overview of FortiPenTest
FortiPenTest leverages a variety of technologies to test target systems for security vulnerabilities. FSE leverages the Lua framework to enable users to write signatures using FortiGuard Labs’ proprietary scripting language. FortiPenTest then processes these signatures to inspect and determine the exploitability of a target application. We use Lua because it is a common scripting language used by many popular applications, whether thick-client or network applications, because of its fast execution. It is lightweight, has a short learning curve, and provides fast execution.
FSE provides a set of high-level application programming interfaces (APIs) that allows script developers to interact with different network protocols, including HTTP, FTP, SMB, and DNS. This protocol flexibility allows script developers to focus on detection logic without concerning themselves too much with the conventional API initialization routines that low-level programmers typically need to deal with during software development.
The following diagram depicts a high-level overview of FortPenTest’s FSE architecture:
Figure 1 shows there are two types of signatures supported by FSE—custom and group signatures.
A custom signature can be treated as an on-demand signature. It is a single script file that can be uploaded by a user, so the contents specified in the script are eventually executed by FSE.
A group signature is a collection of proof-of-concept (POC) exploit signatures developed by our in-house analysts. This collection covers a wide range of applications, including highly targeted applications like WordPress, Joomla, Apache Struts, Microsoft Exchange Server, and others. The goal of group signatures is to provide N-day exploit assessment against assets deemed to be potentially vulnerable. As a side note, some of these N-day exploits covered by group signatures are also based on FortiGuard Labs zero-day research.
Fuzzer Modules vs Exploit Signatures
Fuzzing is a software testing technique that involves inputting invalid, unexpected, or random data to an application. The application is then monitored for things like crashes, memory leaks, or failing code assertions that can be exploited by malware.
An automated fuzzer module is the primary component of FortiPenTest’s vulnerability scanning operation. The module includes a suite of fuzzer modules, shown in Figure 2, that inspect applications for different vulnerabilities based on the OWASP Top 10.
While there are some similarities between the application vulnerability inspection provided by fuzzer modules and exploit signatures, it is important to keep in mind that fuzzer modules do not perform exploitability testing once they discover a vulnerability. Fuzzer modules simply apply relatively aggressive and generic vulnerability patterns to discover potential software bugs that would be difficult to discover otherwise. However, because they do not test those flaws for exploitability, it is important to keep in mind that fuzzer modules can be prone to false positives.
A false positive in this context is a software bug that cannot be effectively exploited. Part of the reason FortiPenTest’s fuzzer modules don’t exploit every vulnerability is such actions might cause undesired behavior during the exploitation process. Hackers have goals just like software developers and will only target those vulnerabilities that can be leveraged for their nefarious objectives. This is why FortiPenTest also includes precise vulnerability patterns to classify exploitable bugs discovered through operations like fuzzing, enabling appropriate countermeasures to be taken.
When Exploit Signatures Come Into Play
FSE comes with a broad set of group signatures designed to identify specific application vulnerabilities—especially those with an assigned Common Vulnerabilities and Exposures (CVE) number—and then run exploitability testing. The caveat is that group signatures are not enabled by default. Instead, users need to explicitly enable them in the Scan Configuration page, as shown in Figure 5.
But the critical question is, when should a user enable a group signature? There are a several use cases, but the most common is if you want to find out if your application is vulnerable to N-day vulnerabilities being exploited in the wild but you cannot or do not want to run the tests manually. In this case, FSE enables you to run a set of group signatures automatically.
However, you should keep in mind that each group signature supports specific vulnerable applications, so you will only want to execute the group signature for the application you want to test. Running all group signatures against an asset will consume more resources, will take longer to complete, and will not produce different results.
Walkthrough of FSE Exploit Signatures
FSE provides group signatures for SAP and WordPress applications. (You can find the full list of application CVEs we currently support in the FortiPenTest v21.2 user guide.) In this section, we will show you how to make use of a group signature to inspect SAP ERP system version 7.5 for potential vulnerabilities.
i. After you have authorized your asset, go to the configuration page, and click on the plus icon under Options.
ii. The Scan Configuration page will then pop up. Here, you can enter additional settings, such as HTTP proxy, authentication method, credentials to be used in authenticating your asset, etc. You will also need to input the credentials used by the targeted asset. In this FSE example, if your SAP ERP system is not using its default credentials, the SAP signature will require you to enter the new credentials. Otherwise, the SAP group signature will not be able to correctly detect vulnerabilities.
iii. Click Next until you come to the Exploit Engine tab. From there, you will find a list of group signatures. In this example, we chose the sap group signature. (Again, you do not want to execute a group signature for applications not hosted on your server. This will just add significant time and overhead to the process without producing better results.) Once selected, the group signature is enabled and will be executed by FortiPenTest once you have selected at least one category from the application list, as shown in Figure 5.
iv. Click the Next button until you reach the final tab and make sure you hit the Save button to preserve the settings you have configured before starting the scanning process.
v. The scan process might take a while depending on the complexities of your asset. After the scan is completed, the result will be shown, as in Figure 7.
vi. You can click on the root URL of your target asset, i.e., the first entry from the list of URIs, to retrieve the FSE result.
From the output shown in Figure 8, it is worth mentioning that the Vulnerability State code can be translated to:
- Vulnerable = 2
- Denial-of-Service = 4
- Exploitable = 8
Most of the group signatures use Vulnerable and Exploitable codes. This code is used to advise you of the exploitation outcome. For instance, a Vulnerable code is used if the asset is affected by the vulnerability defined in the Description but does not have a known exploitable signature. If the Exploitable code is returned, the asset is determined to be both vulnerable and exploitable. In that case, FortiPenTest also provides its Common Vulnerability Scoring System (CVSS)—an industry standard scoring system that captures the principal characteristics of a vulnerability and generates a numerical score reflecting its severity.
Rest assured that the exploit payloads used by the group signatures do not perform anything malicious or harmful. However, the payloads do create some artifacts on the vulnerable server as a proof-of-exploit. For example, it may drop dummy files, create dummy user accounts, etc. depending on the type of vulnerabilities the group signatures are trying to exploit. Conveniently, these artifacts are cleaned up by the group signatures at the post-exploitation stage. Most importantly, for security practitioners, you can leverage the custom rule mentioned in the Remediation section from FSE scan result to protect your network applications via Fortinet’s FortiGate Intrusion Prevention System (IPS). For existing FortiGate users, you can apply the provided custom rule on a FortiGate device, as shown in Figure 10.
Meanwhile, you can also follow more detailed step-by-step instructions on how to add an application control signature on a FortiGate from our administration guide, here.
FortiPenTest Leverages FortiGuard Labs Intelligence
FortiGuard Labs, Fortinet’s threat intelligence and research organization, provides world-class protection to Fortinet customers using a wide variety of advanced and proprietary technologies. One of the long-standing technologies used by many customers is FortiGuard IPS. The FortiPenTest exploit engine leverages the IPS intelligence derived by detecting the prevalent vulnerable applications running in a customers’ network environment. This data is then used by FortiGuard Labs analysts as a critical source for exploit signature production.
It is also worth pointing out that once an application with an associated attack signature is identified, FortiGuard Labs analysts determine the feasibility of producing a corresponding FSE exploit signature. Unlike the exploit signatures developed based on public POCs, the process of developing new exploit signatures typically takes longer, as a significant amount of research is required. Therefore, we distinguish this type of exploit signature from those derived from other sources. You can see the FortiGuard IPS encyclopedia link from the scan output shown in Figure 11. It identifies if a detected exploit signature was derived from our IPS intelligence feed.
High-Level Look at the FortiPenTest
In this overview we provided a high-level look at the FortiPenTest FSE design and how it could be a valuable addition to your regular network application assessment process, including how you can use your FortiPenTest results as the basis for new IPS rules for your FortiGate deployments. We also provided you with a quick guide on how to run automated exploitability testing using a group signature against designated network applications.
We will be discussing some new exciting features from FSE in the next article, including new custom signatures. In the meantime, check out this demo to learn more about FortiPenTest. Until then, stay safe!
References
[1] FortiPenTest Fuzzer Modules – https://docs.fortinet.com/document/fortipentest/21.2.0/fortipentest-user-guide/966543/what-is-fortipentest#Fuzzer_Module
[2] FortiPenTest Complete User Code – https://fortinetweb.s3.amazonaws.com/docs.fortinet.com/v2/attachments/e7c37db1-983a-11eb-b70b-00505692583a/FortiPenTest-21.2-User_Guide.pdf
Learn how Fortinet’s adaptive cloud security solutions provide the necessary visibility and control across cloud infrastructures, enabling secure applications and connectivity from data center to cloud.