Fix now available: Splunk and the Heartbleed vulnerability

Security Splunk

Dear Splunk users,

This is an update to yesterday’s post on our handling of the OpenSSL Heartbleed vulnerability. Thank you again for your patience and understanding as we spent the necessary time to prepare and test our fix for this important issue. As I mentioned yesterday, we are working hard to balance getting the fix out to you as quickly as possible while still spending sufficient time testing it to ensure a high quality delivery.

Take me to the fix!

As of now, Splunk Enterprise 6.0.3 is now available for download. This includes universal forwarder builds.

This release contains two fixes for vulnerabilities in OpenSSL:

Further information about these vulnerabilities is posted on our Security Portal.

Patches now available

Follow these links for the respective patch numbers:

What happens next?

We’ve made 6.0.3 available for download, and we’re now continuing to test our patches for each 6.x version. We’ll be posting patches for 6.0, 6.0.1, and 6.0.2 in the next few days now delivering patches for each affected version (see above). This means you have a choice as to whether you want to upgrade to 6.0.3 or patch your existing version. As always, we recommend upgrading to the latest version if possible.

As we’ve mentioned, the great majority of Splunk deployments are behind firewalls and/or require VPN access, and so do not have a high level of exposure as a result of this vulnerability. That said, once you’ve upgraded or patched, you should determine whether to revoke and reissue any SSL certificates you have in use based on your organization’s requirements. Refer to “About securing your Splunk configuration with SSL” in the Splunk Enterprise documentation for details on how Splunk uses SSL.

If you are using the default certificates provided by Splunk, you can regenerate and reissue them using the utility provided in $SPLUNK_HOME/bin, although these certificates provide minimal protection on their own. Note: You must either rename or move the original default certificates out of the way before you regenerate them.

If you are using your own self-signed or CA-generated certificates, you should revoke and reissue these certificates before changing your Splunk Web password(s).

As always, we recommend following the hardening guidelines in the “Securing Splunk” manual.

----------------------------------------------------
Thanks!
rachel perkins

Related Articles

Machine Learning in Security: Detect DNS Data Exfiltration Using Deep Learning
Security
8 Minute Read

Machine Learning in Security: Detect DNS Data Exfiltration Using Deep Learning

This blog discusses in detail about detecting DNS data exfiltration attacks using deep learning
Guided Automation Using Real Incident Data for Easier Playbook Building in Splunk SOAR
Security
2 Minute Read

Guided Automation Using Real Incident Data for Easier Playbook Building in Splunk SOAR

Build powerful playbooks in Splunk SOAR faster and easier with guided automation, using real incident data to streamline security responses in seconds.
Picture Paints a Thousand Codes: Dissecting Image-Based Steganography in a .NET (Quasar) RAT Loader
Security
13 Minute Read

Picture Paints a Thousand Codes: Dissecting Image-Based Steganography in a .NET (Quasar) RAT Loader

Uncover how to identify malicious executable loaders that use steganography to deliver payloads such as Quasar RAT.