When Security Products Become the Target

When Security Products Become the Target

Speakers: Aviv Yahav, Vulnerability Researcher, NGO Research

Conference: DistrictCon

YouTube: https://www.youtube.com/watch?v=7yQDjDc-Glk

Overview

In this insightful talk titled "When Security Products Become the Target," Aviv Yahav, a Vulnerability Researcher at NGO Research, delves into the critical and often overlooked area of attacking security appliances. Specifically, Yahav presents his research on Fortinet's FortiWeb, their web application firewall (WAF) appliance. The presentation highlights two significant vulnerabilities discovered during his research: an out-of-bounds read that escalated to a full authentication bypass, and a pre-authentication SQL injection leading to remote code execution (RCE).

Yahav's motivation for targeting security products stems from several key factors. These appliances often run with root privileges, making them prime targets where a single vulnerability can bypass all subsequent security controls. Furthermore, he observed a discernible trend of remote code execution vulnerabilities emerging in Fortinet products, piquing his interest. Beyond the technical rationale, Yahav admits a personal enjoyment in subverting devices designed for protection, turning them into points of compromise. This research underscores the importance of scrutinizing the security of the very tools intended to safeguard our networks.

Background

▶ Watch: Attacking FortiWeb: Motivation and Agenda (0:00)

Aviv Yahav's research began with a clear focus on security appliances, driven by their unique characteristics. He notes that these devices frequently operate as the root user, meaning any successful exploit grants maximum privileges. They also represent a single point of failure within an organization's security posture; compromising the appliance negates all downstream protections. Yahav specifically identified a growing trend of remote code execution vulnerabilities in Fortinet products, citing examples like "Zordigate" in 2023 and "40jump" in 2024, indicating a pattern ripe for further investigation.

For his environment setup, Yahav opted for the private cloud deployment option of FortiWeb, which provides a virtual machine (VM) file. This allowed him to spin up the appliance locally for inspection. A crucial initial step involved extracting the file system. By grabbing the VMDK file, listing partitions (dev/sda1), and mounting it, he discovered the root filesystem was unencrypted and readily accessible – a researcher-friendly characteristic not always found in other Fortinet products like FortiGate, which often employ encryption or signing.

With the file system extracted, the next phase was mapping the attack surface. Key areas identified were:

• The /bin directory containing the httpd binary, which turned out to be an Apache server.
• The /cgi-bin directory, accessible from the web.
• The Apache server's configuration, located at /mig-admin/httpd.conf. The server listens on port 443.
• Crucially, custom Apache modules were bundled with the Apache build. These modules, rather than standard Apache components, were identified as the primary source of vulnerabilities.

Yahav also mentioned developing a custom reverse engineering (RE) tooling solution to enhance efficiency, which he elaborated on later in the talk. This systematic approach laid the groundwork for the subsequent vulnerability discoveries.

Key Findings

▶ Watch: First Bug: Authentication Cookie Structure Explained (6:00)

Aviv Yahav's research on Fortinet FortiWeb yielded two critical vulnerabilities, demonstrating how seemingly minor flaws can escalate into severe security risks:

1. Authentication Bypass via Out-of-Bounds Read: This bug originated as a blind out-of-bounds read within the custom Apache module responsible for parsing session cookies. While initially frustrating due to the inability to directly leak memory, Yahav creatively transformed this primitive into a logic bug. By manipulating the error field in the session cookie to trigger an out-of-bounds access, he forced the server to use a predictable (in this case, NULL) secret key for HMAC signature verification and payload decryption. This allowed an unauthenticated attacker to craft valid session cookies, effectively bypassing the entire authentication mechanism for /API/V2 endpoints.

1. Pre-Authentication Remote Code Execution (RCE) via SQL Injection: The second major finding was a pre-authentication SQL injection vulnerability residing within another custom Apache handler associated with the "fabric connector" feature. The Authorization header, supplied by the user without any sanitation, was directly concatenated into an SQL query. Yahav leveraged this SQL injection to achieve arbitrary file write capabilities using the INTO OUTFILE statement. Overcoming several practical limitations—such as character limits, lack of spaces, and the need to make the written file executable—he devised a multi-stage exploit to write a web shell to the /cgi-bin directory and then execute it with root privileges.

These findings underscore the significant risks posed by vulnerabilities in security products, especially when they grant unauthenticated access and high-privilege code execution.

Technical Deep Dive

▶ Watch: Second Bug: Unauthenticated SQL Injection Discovered (18:00)

The technical depth of Aviv Yahav's presentation reveals a methodical approach to vulnerability research, starting from file system analysis and culminating in sophisticated exploit chains.

Authentication Bypass (Out-of-Bounds Read)

The first vulnerability targeted the FortiWeb admin portal's authentication mechanism, which relies on a session cookie. This cookie, as Yahav described, is composed of three parts:

1. error: A field that can be 0 or 1. Its purpose was initially unclear to Yahav, but it proved to be the key to the vulnerability.
2. payload: Encrypted data containing session information such as username, role, and other metadata. This part ensures confidentiality.
3. auth_hash: An HMAC SHA1 hash of the encrypted payload ciphertext, signed with the same secret key used for payload encryption. This part is intended to guarantee integrity.

Authentication for /API/V2 routes is handled by a custom Apache module handler. Yahav identified this handler through the Apache configuration, which uses the Location directive on /API/V2 to trigger it. The specific module was named FWB_CGI_module (or FortiWeb CGI module).

To understand its implementation, Yahav examined the ap_prelinked_modules array, a standard Apache mechanism that lists all bundled modules. He found FWB_CGI_module in this array, which points to a module descriptor. This descriptor, a C data structure, contains a function pointer FortiWeb_CGI_module_register_hooks. This function is called once on Apache startup to register a callback function that will be triggered for every incoming request to the /API/V2 routes.

The core parsing logic for the cookie resides in the function cookieval_unwrap. Inside this function, snprintf and scanf are used to extract values from the cookie into variables. After extraction, the module verifies the HMAC signature of auth_hash and decrypts the payload. Crucially, the secret key used for these operations is chosen from memory based on the error field.

Here lies the vulnerability: if the error parameter is manipulated to an out-of-bounds value (e.g., error=8), it causes an out-of-bounds read when indexing the secret key array. Initially, Yahav aimed for a memory leak, but it turned out to be a blind out-of-bounds read—the accessed value never returned in the response. Through persistence, he discovered that the memory region immediately following the legitimate secret key array was filled with NULL bytes.

This transformed the blind out-of-bounds read into a powerful logic bug. By setting error=8 in the cookie, Yahav forced the server to use a NULL secret key for both HMAC verification and payload decryption. This meant an attacker could:

1. Encrypt their desired session payload (e.g., username=admin, role=administrator) with a known key (or even a NULL key if they knew the encryption algorithm).
2. Generate an auth_hash using a NULL key.
3. Combine these with error=8 into a valid-looking cookie.

Yahav replicated Fortinet's 40crypt (for AES encryption of payload) and 40sign (for HMAC SHA1 of auth_hash) logic in Python. By crafting a cookie with error=8, a custom payload, and a corresponding auth_hash generated with a NULL key, he successfully bypassed authentication to an endpoint like /API/V2/system/status, receiving a 200 OK response with sensitive JSON data. The speaker noted that this vulnerability saw exploitation in the wild after it was reported and patched.

Pre-Authentication RCE (SQL Injection)

The second critical vulnerability was a pre-authentication SQL injection found in another custom Apache handler, this one related to the "fabric connector" feature. This handler was triggered for routes under /api/v2/fabric. The vulnerability resided in the function get_fabric_user_by_token, reachable from the module's FDS_callback.

The access_check function within this handler parses user-supplied HTTP headers, specifically the Authorization header. The value of this header is stored directly into a char token variable without any validation or sanitation. This token variable is then passed to get_fabric_user_by_token, where it is concatenated directly into an SQL query. The absence of prepared statements or proper escaping made it a straightforward SQL injection.

The goal was to achieve Remote Code Execution (RCE). Yahav planned to leverage the SQL INTO OUTFILE statement, which allows writing query results directly to a file on the server's filesystem. The strategy was to write a web shell to the /cgi-bin directory.

However, several limitations needed to be overcome:

1. Character Limitation: The Authorization header input was limited to 128 characters due to the scanf prefix used, insufficient for a full web shell.
2. Space Character Limitation: The %s modifier in scanf stops reading at the first space character, making standard SQL injection syntax difficult.
3. chmod Requirement: mod_cgi requires the executable bit to be set on CGI scripts. An attacker could write a file to /cgi-bin, but it wouldn't be executable without a chmod operation.

Yahav devised clever solutions for each obstacle:

• Overcoming Space Limitation: Instead of spaces, he used SQL comments (//) (e.g., SELECT//1,2,3). He later mentioned that simply using a tab character (\t) would also work and be more character-efficient.
• Overcoming Character Limitation: To write a full web shell string exceeding 128 characters, he implemented a multi-stage arbitrary file write. First, he created a temporary SQL table using an injection. Then, he sent multiple SQL injection requests, each appending a chunk of the web shell content to this temporary table. Once the full web shell string was constructed in the table, a final SQL injection with an INTO OUTFILE statement was used to write the table's contents to the target file (/cgi-bin/x.cgi). This effectively provided an arbitrary file write primitive.
• Overcoming chmod Requirement: This was the most creative part. Yahav identified an existing, unauthenticated CGI script at /cgi-bin/mldraw. This script contained the line import pylab. He used his arbitrary file write primitive to create a Python file at var/log/lib/python/pylab.py (a path that would be loaded by the import pylab statement). The content of this pylab.py file was os.system('chmod +x /cgi-bin/x.cgi'). By sending an unauthenticated request to /cgi-bin/mldraw, the Python interpreter would execute pylab.py, thereby triggering the chmod command and making the web shell executable. This two-part web shell strategy allowed for a web shell in an accessible path (/cgi-bin) and a chmod gadget in a less accessible but loadable path (var/log/lib/python).

The full RCE exploit flow involved: creating a fake SQL table, using multiple requests to write the web shell (x.cgi) to /cgi-bin, writing the chmod gadget (pylab.py) to var/log/lib/python/, sending a request to /cgi-bin/mldraw to execute chmod, and finally browsing to /cgi-bin/x.cgi to execute arbitrary commands as root.

Reverse Engineering Tooling

Yahav concluded the technical discussion by introducing a custom reverse engineering tool he developed to streamline his workflow. He explained that reverse engineering logic involving custom Apache data structures can be messy and time-consuming. Decompilations often show random offsets and multiple dereferences, making it difficult to understand the underlying C structures. While IDA Pro has a feature to import header files, it often breaks due to include path issues, requiring manual fixes.

To address this, Yahav created a "database" called Symbol Exchange. This tool effortlessly searches for structures, fields, and offsets across thousands of binary packages. It builds its database by processing ELF files that contain DWARF metadata. DWARF metadata is crucial as it contains rich debugging information, including type definitions. When a researcher finds a desired structure in Symbol Exchange, they can download a corresponding ELF file (with debug metadata). This ELF file can then be loaded into IDA Pro using its "Load DWARF file" feature. This process automatically populates IDA with the correct C type definitions, significantly cleaning up the decompilation and making it much more researcher-friendly and time-saving, as demonstrated by a before-and-after screenshot.

Demo / Proof of Concept

▶ Watch: Creative CHMOD Gadget for Web Shell Execution (26:00)

Aviv Yahav provided live demonstrations for both vulnerabilities, showcasing the practical impact of his findings.

For the authentication bypass, the demo illustrated the construction of a malicious cookie. The cookie was shown with error=8, and the crafted payload and auth_hash components. A request was then sent to an authenticated endpoint, /API/V2/system/status. The successful exploitation was confirmed by a 200 OK HTTP response and the display of the JSON response, indicating full access to an endpoint that should have required prior authentication. Yahav noted that the exploit was so quick it was hard to see the phases in the demo.

The pre-authentication RCE demonstration was a multi-stage process, reflecting the complexity of the exploit chain.

1. The first step showed the process of writing the web shell (x.cgi) to the /cgi-bin directory using the SQL injection and the temporary table technique to overcome character limitations.
2. Next, the creation of the chmod gadget (pylab.py) was demonstrated, writing the os.system('chmod +x /cgi-bin/x.cgi') payload to the Python library path (var/log/lib/python/pylab.py).
3. The crucial step of accessing /cgi-bin/mldraw was then shown. This action triggered the import pylab statement, which in turn executed the chmod command, making x.cgi executable.
4. Finally, a request was sent to the newly executable web shell, /cgi-bin/x.cgi, to execute a simple command (e.g., id). The output UID root, GID 0, and group 0 confirmed successful remote code execution with root privileges, demonstrating the complete compromise of the FortiWeb appliance.

These demonstrations provided clear, tangible evidence of the exploitability and severity of the discovered vulnerabilities.

Defensive Implications

▶ Watch: Q&A: Staying Motivated and Patch Details (34:00)

Aviv Yahav's research provides critical insights for defenders operating and securing web application firewalls and other security appliances. The following defensive implications are paramount:

• Rigorous Input Validation and Sanitization: All user-supplied input, including HTTP headers (like Authorization) and cookie parameters (like error), must undergo strict validation and sanitization. This is crucial to prevent both logic bugs (like the out-of-bounds read) and injection attacks (like SQL injection).
• Secure Coding Practices for Database Interactions: For any database operations, prepared statements or parameterized queries are non-negotiable. Direct string concatenation of user input into SQL queries, as seen in the RCE, is a fundamental security flaw that must be eliminated.
• Memory Safety: Developers must employ robust memory safety practices to prevent out-of-bounds reads and writes. This includes careful array indexing, boundary checks, and using memory-safe functions. Even "blind" memory corruption can be leveraged into logic bugs.
• Least Privilege Principle: Security products, despite their critical role, should adhere to the principle of least privilege. While some components may require root, unnecessary elevation of privileges for all services increases the impact of a compromise.
• Thorough Auditing of Custom Modules: Custom Apache modules, or any custom code integrated into core services, represent a significant attack surface. These modules must be subjected to stringent security audits, code reviews, and penetration testing, as they are often sources of unique and critical vulnerabilities.
• Strict Cookie Parsing and Validation: Session cookies and other authentication tokens must be parsed and validated with extreme care. Any part of the cookie that controls internal logic (like the error field) must be strictly checked for valid ranges and types.
• File System Permissions and Integrity: Prevent arbitrary file writes to sensitive directories like /cgi-bin. Implement integrity checks and restrict write permissions to prevent attackers from placing malicious executables or scripts.
• Leveraging Honeypots for Threat Detection: As highlighted by the speaker's mention of the company Defused, honeypots can be invaluable for detecting exploitation attempts against reported vulnerabilities in the wild. This provides early warning and intelligence for defenders.
• Prompt Patching and Updates: While not explicitly a defensive implication for development, the speaker's comment on the delay in patching (8 months) highlights the critical need for vendors to issue timely patches and for users to apply them promptly.

By addressing these areas, organizations can significantly enhance the resilience of their security infrastructure against sophisticated attacks targeting the very products designed to protect them.

Key Takeaways

• Security products are high-value targets: Appliances like WAFs are often deployed at critical network junctures, operate with elevated privileges, and represent a single point of failure, making them attractive to attackers.
• Custom components are a prime attack surface: Vulnerabilities are frequently found in custom-developed modules (e.g., Apache handlers) rather than standard, well-vetted open-source components.
• Blind memory corruptions can lead to logic bugs: Even if an out-of-bounds read doesn't directly leak data, creative analysis can reveal how it influences program logic (e.g., forcing a NULL secret key) to achieve powerful exploits like authentication bypass.
• Persistence and creative problem-solving are crucial for exploitation: Overcoming limitations like character restrictions, lack of spaces, or the need to execute chmod requires innovative, multi-stage exploit chains, such as using SQL comments, temporary tables, and import gadgets.
• SQL Injection remains a critical and exploitable flaw: Despite being a well-known vulnerability, direct concatenation of unsanitized user input into SQL queries persists, leading to severe impacts like remote code execution.
• Effective reverse engineering tooling significantly aids research: Tools like Symbol Exchange, which leverage DWARF metadata to automatically import C structures into disassemblers, can drastically reduce the time and effort required for understanding complex binaries.

About the Speaker(s)

Aviv Yahav is a Vulnerability Researcher at NGO Research. He is also active as a CTF developer and maintains a personal blog at boner.dd. His work focuses on discovering and analyzing security vulnerabilities, particularly in critical systems like security appliances.