Splunk shows vulnerable to CVE-2012-4929 in my Nessus vulnerability scan, what is going on?

[ahattrell_splun]

Running a vulnerability scan with nessus against splunk shows port 8089 vulnerable to CVE-2012-4929, a "CRIME" attack, which is a type of man in the middle attack. I'd like to know if Splunk is actually vulnerable to such an attack.

[baonguyen78]

adding the sslConfig block to server.conf didn't work for me.

[wrangler2x]

I put these lines in ~/etc/system/local/server.conf -- with a clean restart of Splunk and re-scanned my system with nessus and the vulnerability warning was gone.

[sslConfig]
allowSslCompression = false 
useClientSSLCompression = false 
useSplunkdClientSSLCompression = false 
sslVersions = tls1.1, tls1.2 
sslVersionsForClient = tls1.1, tls1.2 

The last two lines were to deal with vuln warnings about ssl3.0

You'll have other lines in sslConf stanza. I'm only showing the ones I changed or added.

[jbsplunk · Accepted solution]

This is the official answer from Splunk regarding CVE-2012-4929.

You need the following things to be vulnerable to CVE-2012-4929:

• a user using an unpatched version of chrome or firefox that tries to use SSL compression
• a server that allows SSL compression
• a user logged into the web server
• some other untrusted web site making non-logged-in connections
• some way of observing the traffic or timing close enough that you can probe the zlib compression dictionary by injecting strings.

This is really a web browser bug, although some web servers have disabled SSL compression completely as a mitigation. However, vulnerable web browsers are super-rare at this point. The only one that was ever vulnerable was chrome (Firefox was maybe vulnerable for SPDY connections — reports differ -- but we've never supported SPDY anyway so it isn't relevant) Chrome pushed an auto-update security fix more than a month ago, so the vulnerability is basically dead now anyway.

Further, the complaint seems to be about the splunkd REST endpoints (I.e. port 8089) not splunkweb (I.e. port 8000). User's web browsers never access those ports directly anyway so there is zero vulnerability exposure there.

Splunkweb uses a webserver called "CherryPy" to serve the UI requests. By default it isn't using SSL at all (I.e. no exposure). We enabled SSL on splunkweb and pointed an SSL scanner against it and it does seem to allow negotiating SSL compression. There does not seem to be a simple way of disabling this.

So to recap:
1. The CVE is for a bug on the web browser side.

2. The default configuration of splunk isn't vulnerable even if you somehow had a vulnerable browser
3. The splunkweb side doesn't mitigate against vulnerable web browsers, but that’s unlikely to change since the web server that we use doesn't seem to have functionality that would allow for this type of a configuration change.

As such, the likelihood of being exposed to this particular vulnerability is near zero.

[fd26645]

If the vulnerability is that using compression makes the encryption easy to crack then what difference does it make if it is a web server talking to a web browser, or a splunk forwarder talking to a splunk indexer? In theory the vulnerability is still there… right? I’m no Alan Turing, but my gut tells me it’s a valid observation.

[bpaul_splunk]

In Splunk versions 6.0 and higher, there is a new option which can be set in server.conf to allow the disabling of compression.

allowSslCompression = true|false

• If set to true, the server will allow clients to negotiate SSL-layer data compression.

In versions 6.0 and 6.1, this defaults to false. In version 6.2 the setting defaults to true. Setting this to false should prevent scanners from determining Splunk is vulnerable.

[miguel_fernande]

I'm not sure about that compression setting defaulting to false in versions 6.0 and 6.1.

I say this because our scanners found our splunk instances(version 6.1.5) to be vulnerable for TLS crime UNTIL we added "allowSslCompression = false" to our server.conf file.

Once we did that the vulnerability went away.

I would recommend just adding the line to be safe for those who want/need to mitigate the TLS crime vulnerability scan hits.