Our new Biannual ICS Risk & Vulnerability Report is the most up-to-date look at CVEs disclosed in OT devices.
Check it out!
Splunk Patches Indexer Vulnerability Discovered by Team82
By Sharon Brizinov | March 24, 2022
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.
Indexers and Forwarders Key Components
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)
Use of any available network ports
S2S Protocol Facilitates Communication
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 fieldthat allows an attacker to control the offset to the value that will be dereferenced.
Demonstrating how a specially crafted malicious S2S v3 packet could trigger CVE-2021-3422 and leak process memory data.
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.
Fixes and Mitigations
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.
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.