As a system administrator, it is part of the job to address the vulnerabilities that leave a network open to security incursions. When looking for these vulnerabilities, it’s not uncommon to find “false positives.” Vulnerability scanners are notorious for not considering the entire system architecture, reading solo system configurations and reporting vulnerabilities that don’t actually exist.
While it may be tempting to ignore these, you really shouldn’t, if for no other reason than staying on the good side of your compliance or security office. Unless you want to be on the “naughty list,” you must prevent the vulnerability scanners from detecting these false positives.
As a Splunk administrator, you may have received false positive notices stating that your Universal Forwarders, indexers, and KV Store/MongoDB are vulnerable to Secure Socket Layer (SSL) v.3 POODLE. Why are these notices false positives? According to Splunk, these components “do not permit an attacker to generate the necessary arbitrary requests to execute an attack.” Nonetheless, we are going to show you how to prevent these false positive vulnerabilities.
Splunk version 6.2 and greater provides a way to restrict older versions of protocols. SSLv3 is enabled out of the box to ensure support in existing environments where earlier versions of the Universal Forwarder are installed. If you are deploying a new environment, you can most likely disable SSLv3 and Transport Layer Security (TLS) 1.1, leaving only TLS 1.2 enabled. Why do we say most likely? You may need to use an older version of the Universal Forwarder for legacy operating systems (Windows 2003, XP, Vista and Solaris 8, 9) which will not support TLS 1.2. Splunk version 6.0 can support up to TLS 1.1 and version 6.2 can support up to TLS 1.2.
For this example, we used nmap’s ssl-poodle test script to scan port 8089 to test if SSLv3 Cipher Block Chaining (CBC) ciphers are allowed on a clean Splunk installation (see Figure 1 below). The scan results show that one of Splunk’s processes, splunkd, is likely vulnerable to POODLE. Even though, as stated above, Splunk does not consider this to be a vulnerability, here’s how you can prevent this false positive.
———- figure 1———-
$ nmap -sV --version-light --script ssl-poodle -p 8089 172.16.95.144Starting Nmap 7.10 ( https://nmap.org ) at 2016-03-18 13:26 MDT
Nmap scan report for 172.16.95.144
Host is up (0.00052s latency).
PORT STATE SERVICE VERSION
8089/tcp open ssl/http Splunkd httpd
| ssl-poodle:
| VULNERABLE:
| SSL POODLE information leak
| State: LIKELY VULNERABLE
| IDs: CVE:CVE-2014-3566 OSVDB:113251
| The SSL protocol 3.0, as used in OpenSSL through 1.0.1i and
| other products, uses nondeterministic CBC padding, which makes it easier
| for man-in-the-middle attackers to obtain cleartext data via a
| padding-oracle attack, aka the "POODLE" issue.
| Disclosure date: 2014-10-14
| Check results:
| TLS_RSA_WITH_AES_128_CBC_SHA
| TLS_FALLBACK_SCSV properly implemented
| References:
| http://osvdb.org/113251
| https://www.imperialviolet.org/2014/10/14/poodle.html
| https://www.openssl.org/~bodo/ssl-poodle.pdf
|_ https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3566
Since the vulnerability is on port 8089, we will need to adjust the SSL versions in the server.conf file. For purposes of this example we will limit Splunk to TLS 1.2. You can also use a deployment server to push this configuration out to your environment by creating a new application and a server.conf inside a local folder that contains:
[sslConfig]
sslVersions = tls1.2
We can then use Nmap to verify that the vulnerability no longer exists (see figure 2 below).
———- figure 2———-
$ nmap -sV --version-light --script ssl-poodle -p 8089 172.16.95.144Starting Nmap 7.10 ( https://nmap.org ) at 2016-03-22 12:58 MDT
Nmap scan report for 172.16.95.144
Host is up (0.00031s latency).
PORT STATE SERVICE VERSION
8089/tcp open ssl/http Splunkd httpd
Splunk has many configuration files, some we use daily – such as inputs, props and transforms – and some that are rarely used, such as server.conf. In this post, we demonstrated one way these rarely used configuration settings can make your life as a Splunk admin easier by preventing you from being placed on the aforementioned “naughty list.” We hope you enjoyed learning about an additional way to secure your Splunk environment. Stay tuned, as we cover additional ways to secure and harden Splunk.
Luke Netto is a Splunk Consulting Engineer with GTRI’s Professional Services.
