Team82 disclosed a vulnerability in Splunk indexers and forwarders that could leak memory, or allow an attacker to crash a Splunk server and cause a denial-of-service condition.
Splunk patched the vulnerability in Splunk Enterprise, CVE-2021-3422. Users are advised to update.
Splunk indexers handles parsing and indexing of data as it moves through the security tool. Forwarders, meanwhile, send data to instances such as an indexer, usually over TCP port 9997.
Using a carefully crafted exploit, an attacker could read sensitive information from the splunkd process memory, and leak it into the Splunk data.
Another consequence could be an access violation exception due to a page fault, which terminates the entire splunkd service and therefore, causes a denial-of-service condition.
Splunk Enterprise is a platform that allows users to analyze, search, and visualize machine-generated data coming from various sources including websites, applications, OT and IoT sensors, devices, and more. That information is indexed and correlated in such a way that it is searchable and can be used to generate alerts and other reporting.
Splunk is market leader in IT operations management and analysis, and large enterprises worldwide rely on it to consume information and build intelligence around security events and gain insight into vulnerabilities. As more companies converge OT under IT management, Team82 decided to research key Splunk Enterprise components. Our work uncovered a vulnerability that could be triggered by an attacker to possibly leak memory or cause denial-of-service conditions, leaving organizations blind to events and incidents the software would normally alert to.
Splunk has patched CVE-2021-3422, and today disclosed some additional details about the issue. Users are advised to update their respective instances of Splunk Enterprise to current versions to remediate the vulnerability. Splunk's security advisory can be found here.
A main component of Splunk Enterprise is an indexer, which handles parsing and indexing of data. It is the main server receiving data from another architectural component called a forwarder, which forwards data to instances such as indexer, usually over TCP port 9997. Forwarders require minimal resources and have little impact on performance, so the forwarder usually resides on the machine where the data originates.
Forwarders are more robust than raw network feeds for data forwarding, with capabilities across different versions such as:
Tagging of metadata (source, source type, and host)
Configurable buffering
Data compression
SSL security
Use of any available network ports
Forwarders communicate with indexers via a special protocol called S2S (Splunk-to-Splunk), which is available in multiple versions, each with different capabilities such as data compression, tagging of metadata, and more.
In order to send an event (a single piece of data in Splunk), the forwarder would need to initiate a TCP conversation and send a unique signature that includes the protocol version. Next, depending on the protocol flavor and version, the forwarder would need to communicate the supported capabilities and/or register a channel to deliver the event. Finally, the event can be constructed and sent to the indexer to be handled.
The new S2S protocol (v3) implementation supports different key-value types including numbers, strings, and more. One of the keys is a field that supports a dynamic variable type (aka field_enum_dynamic), which acts as an index and allows the forwarder to send a numeric key field that will be dynamically translated to the required string on the server side, similar to an enumerated type behavior.
Team82 discovered that Splunk does not verify the values of field_enum_dynamic variable type, therefore attackers can build a specifically crafted event with an arbitrary key field type value. The result is an out-of-bounds (OOB) read vulnerability in the parsing flow of this field that allows an attacker to control the offset to the value that will be dereferenced.
Using a carefully crafted exploit, an attacker could read sensitive information from the splunkd process memory, and leak it into the Splunk data. Another consequence could be an access violation exception due to a page fault, which terminates the entire splunkd service and therefore, causes a denial-of-service condition.
Spunk has released patches and fixed versions for impacted products, which are detailed, below, and in its security advisory.
To mitigate the risk, users can enable TLS authentication or use forwarder tokens for access control. Both options will limit the attacker's ability to send S2S messages and therefore, reduce the possibility of parsing malicious data.
By using TLS authentication you can send data from forwarders to indexers using SSL certificates that you procure, rather than the ones that Splunk provides. For best practices see: Configure Splunk forwarding to use your own SSL certificates
Another option is to configure Splunk Enterprise to allow communication from authorized forwarders through the use of tokens. A token is a unique key that is generated and enabled on the indexer, and configured on the forwarder.
A forwarder attempting to send data to an indexer without the correct token value will be rejected. Forwarder access control is independent of Secure Sockets Layer (SSL) and can be used in environments that do not have SSL enabled between Splunk platform instances.
CVSSv3.1 Score: 7.5, High
CVSSv3.1 Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Advisory: Splunk Security Advisory
CWE-547 USE OF HARD-CODED, SECURITY-RELEVANT CONSTANTS:
Optigo Networks Visual BACnet Capture Tool and Optigo Visual Networks Capture Tool version 3.1.2rc11 are vulnerable to an attacker impersonating the web application service and mislead victim clients.
Optigo Networks recommends users to upgrade to the following:
CVSS v3: 7.5
CWE-288 AUTHENTICATION BYPASS USING AN ALTERNATE PATH OR CHANNEL:
Optigo Networks Visual BACnet Capture Tool and Optigo Visual Networks Capture Tool version 3.1.2rc11 contain an exposed web management service that could allow an attacker to bypass authentication measures and gain controls over utilities within the products.
Optigo Networks recommends users to upgrade to the following:
CVSS v3: 9.8
CWE-547 USE OF HARD-CODED, SECURITY-RELEVANT CONSTANTS:
Optigo Networks Visual BACnet Capture Tool and Optigo Visual Networks Capture Tool version 3.1.2rc11 contain a hard coded secret key. This could allow an attacker to generate valid JWT (JSON Web Token) sessions.
Optigo Networks recommends users to upgrade to the following:
CVSS v3: 7.5
CWE-912 HIDDEN FUNCTIONALITY:
The "update" binary in the firmware of the affected product sends attempts to mount to a hard-coded, routable IP address, bypassing existing device network settings to do so. The function triggers if the 'C' button is pressed at a specific time during the boot process. If an attacker is able to control or impersonate this IP address, they could upload and overwrite files on the device.
Per FDA recommendation, CISA recommends users remove any Contec CMS8000 devices from their networks.
If asset owners cannot remove the devices from their networks, users should block 202.114.4.0/24 from their networks, or block 202.114.4.119 and 202.114.4.120.
Please note that this device may be re-labeled and sold by resellers.
Read more here: Do the CONTEC CMS8000 Patient Monitors Contain a Chinese Backdoor? The Reality is More Complicated….
CVSS v3: 7.5
CWE-295 IMPROPER CERTIFICATE VALIDATION:
The affected product is vulnerable due to failure of the update mechanism to verify the update server's certificate which could allow an attacker to alter network traffic and carry out a machine-in-the-middle attack (MITM). An attacker could modify the server's response and deliver a malicious update to the user.
Medixant recommends users download the v2025.1 or later version of their software.
CVSS v3: 5.7