Introduction to Iris
Iris DFIR is an open-source, collaborative platform designed to streamline and enhance incident response processes. This powerful tool empowers incident response teams by providing a centralized dashboard, automated workflows, and real-time collaboration features, allowing for efficient communication and coordination during critical incidents. It integrates with Endpoint Detection and Response (EDR) tools for automated data collection and advanced analytics, facilitating quick identification of root causes.
The platform incorporates threat intelligence feeds and robust Indicator of Compromise (IOC) management to respond swiftly to known potential threats. Forensic investigations are streamlined with tools for artifact analysis, timeline reconstruction, and case management. Additionally, Iris DFIR automates reporting, ensuring comprehensive documentation of incidents, findings, and actions taken.
taken from Iris’s official demo
The discovery of the SSTI vulnerability (CVE-2024-25624)
While examining the different functionalities of the application, I found a Server-Side Template Injection (SSTI) vulnerability in the report generation functionality.
This vulnerability was exposed through the process of adding and using a malicious template. Initially, a specially crafted DOCX file containing a malicious Jinja2 payload, was uploaded via the “Report Templates Management” section. For POC purposes, the payload I used reads the content of /etc/passwd file.
the DOCX file with the payload
| {{ self.__init__.__globals__.__builtins__.__import__(‘os’).popen(‘cat /etc/passwd‘).read() }} |
A DOCX file containing a malicious SSTI payload was uploaded as a “Report Template”
When a report was generated using this template, the payload executed arbitrary code on the underlying server. This was confirmed by observing the output embedded in the resultant DOCX file, indicating unauthorized command execution, a clear sign of SSTI.
Report generation using a malicious template #1
Generated report with the content of “/etc/passwd”
Obtaining complete control of the server
This POC made me realize that SSTI is possible and OS commands can be executed on the server. Next, I wanted to see if I could obtain a reverse TCP shell from the server using a specially crafted payload, using SSTI. Shell on the underlying server will enable a complete takeover of the target server.
First, I set up a reverse TCP shell to listen for incoming connections.
Listening for incoming connections
Afterwards, I created a report template containing the payload that attempts to make a connection to my listening server.
Creation of a malicious Report Template
Then, I selected a random Case, and chose to generate a report using the newly created Report Template.
Report generation using a malicious template #2
Once I pressed “Generate”, the Iris server evaluated the malicious payloads, and sent a shell over TCP to my listening server. As a result, I was able to get complete a access to the server
TCP shell was returned to my server
I was surprised to find out that the web application system user had Root privileges. That means, I gained complete control on the server.
Full access on the server
Leveraging Arbitrary File Write to RCE through SSTI (CVE-2024-34060)
During the ongoing research I identified an arbitrary file write vulnerability. This vulnerability can be exploited by an attacker with low-level privileges, specifically if they have access to a shared case that includes an active pipeline. The exploit process involves the attacker uploading a malicious template file to an arbitrary route on the server. This action effectively overwrites a legitimate template file. For POC purposes I demonstrated the overwrite process for the “error-404.html” file (that is responsible for presenting error messages when users access non existent resources.
When users navigate to a non-existent resource, this is what they will get. Keep that in mind for the next steps.
Access to a non existent resource (before exploitation)
First, I accessed a random case and pressed on the “Pipelines” button
Access Pipelines for a certain case
Next, I created uploaded a HTML file with the following content:
| {{request.application.__globals__.__builtins__.__import__(‘os’).popen(‘cat /etc/hosts’).read()}} |
Attaching an HTML file containing a template to the pipeline
Afterwards, I clicked “intercept” on Burp Suite (proxy tool) in order to record the outgoing request. This was the request I intercepted when uploading the file.
Intercepting the upload request to the server
I modified the filename to this path
| ../../../../../../../../../iriswebapp/app/templates/pages/error-404.html |
Modification of the filename with a relative path the points to “error-404.html”I forwarded the request to the server and got this message on the web application.
The server just overwrote the content of the error-404.html with my own template.
Successful process of the pipeline
The vulnerability is triggered when a user attempts to access a forbidden or non-existent resource. Consequently, following a server restart, the compromised server will retrieve and execute the injected template whenever any user attempts to access a resource that is either forbidden or does not exist. This vulnerability poses a significant security risk, as it allows unauthorized code execution through seemingly innocuous user actions.
Access to a non existent resource (after exploitation)
Note – this vulnerability can result in a reverse shell as well.
Mitigation Analysis
As for the mitigation for CVE-2024-25624, Iris team has worked on a patch as part of v2.4.6.
This custom environment is intended to be used with the Jinja2 templating engine to enhance security by:
- Blocking access to certain unsafe attributes and methods.
- Preventing the execution of potentially harmful operations, such as calling built-in types directly. This makes it safer to render templates, particularly in environments where templates might be provided by untrusted sources.
| Python class IrisJinjaEnv(SandboxedEnvironment): def is_safe_attribute(self, obj, attr, value): unsafe_attributes = [ ‘os’, ‘subprocess’, ‘eval’, ‘exec’, ‘open’, ‘input’, ‘__import__’, ‘__class__’, ‘__bases__’, ‘__mro__’, ‘__subclasses__’, ‘__globals__’ ] if attr in unsafe_attributes or attr.startswith(‘__’) and attr.endswith(‘__’): return False return super().is_safe_attribute(obj, attr, value) def call(self, obj, *args, **kwargs): if isinstance(obj, (type,)): raise Exception(“Calling of built-in types is not allowed.”) return super().call(obj, *args, **kwargs) |
Also, this line of code was added to mitigate security risks associated with template rendering, particularly Cross-Site Scripting (XSS) attacks.
| Python app.jinja_env.autoescape = True |
Regarding the mitigation for CVE-2024-34060, Iris team has worked on a patch as part of v1.0.
The patch addresses the mishandling of filenames that originally supported relative paths.
| Python from werkzeug.utils import secure_filename class IrisEVTXInterface(IrisModuleInterface): def pipeline_files_upload(self, base_path, file_handle, case_customer, case_name, is_update): “”” Handle the files for a specific :return: “”” if base_path and Path(base_path).is_dir: file_handle.save(Path(base_path, file_handle.filename)) # Sanitize the filename file_name = secure_filename(file_handle.filename) file_handle.save(Path(base_path, file_name)) return InterfaceStatus.I2Success(“Successfully saved file {} to {}”.format(file_handle.filename, base_path)) |
The “secure_filename” Werkzeug function, takes filename as input and returns a secure version of it, ensuring it can be safely stored on a regular file system and passed to os.path.join(). The returned filename is an ASCII-only string for maximum portability.
Takeaways
- High-Risk Vulnerabilities: CVE-2024-25624 and CVE-2024-34060 present significant security threats to the Iris DFIR platform, capable of remote code execution and arbitrary file writes.
- SSTI Vulnerability (CVE-2024-25624): Discovered in the report generation functionality, this vulnerability allows attackers to execute arbitrary code by uploading a malicious DOCX file containing a Jinja2 payload.
- Arbitrary File Write (CVE-2024-34060): Identified during research, this vulnerability allows attackers to overwrite legitimate template files with malicious ones, leading to remote code execution upon accessing specific resources.
- Full Server Control: Exploiting the SSTI vulnerability can lead to obtaining a reverse TCP shell, granting complete control over the server, including root privileges.
- Mitigation Efforts: Iris has implemented patches to address these vulnerabilities:
- CVE-2024-25624: Introduced a custom Jinja2 environment to block unsafe attributes and methods, preventing harmful operations and enhancing template security.
- CVE-2024-34060: Applied the secure_filename function from Werkzeug to sanitize filenames, ensuring safe file handling and storage.
- Importance of Secure Development: The findings underscore the necessity for rigorous security practices in the development and maintenance of open-source platforms, especially those used in critical areas like incident response.
- Proactive Security Measures: Organizations should regularly audit their systems for vulnerabilities, apply timely patches, and adopt secure coding practices to mitigate risks associated with open-source software.
TL;DR
- There is a need for awareness of the potential risks of using open source code
- Introducing the remote code execution through SSTI we discovered on Iris.
- Introducing the remote code execution through Arbitrary File Write we discovered on Iris.
- CVE-2024-25624 ; CVE-2024-34060
- Github security advisories
- Mitigation analysis
