OpenSSL Heartbleed vulnerability Guidelines

Hi there folks,

unless you’ve been living under a rock, you’d know that a flaw has been discovered in OpenSSL, which is one of the most utilized encryption methods on the Internet and ICT at a global scale.

You can find here what OpenSSL Heartbleed bug is all about:
http://heartbleed.com/

A lot have been said and apart from the buzz there is some confusion around Heartbleed, so I want to provide you some sort of enlightment and guidelines, more about “What” and not “How” to deal with it.

Heartbleed verification and mitigation is time consuming, unless you have your ICT environment insanely documented you can’t bet that you are not exposed to Heartbleed, so let’s focus on the guidance model.

 

1 – Vendors affected by Heartbleed

You can find below an extensive list of security advisories regarding CVE-2014-0160 (a.k.a. Heartbleed) from the well known Linux Distributions and security + networking Software/Hardware vendors. I am sharing with you just a mere representation of vendors being impacted, the bulk part of the Iceberg it’s underwater with an endless list of vendors.

 

VMWare:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2076225

Cisco:
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20140409-heartbleed

Blackberry:
http://btsc.webapps.blackberry.com/btsc/viewdocument.do;jsessionid=5893087B0890E66745D0A2187EBB2FF1?externalId=KB35882&sliceId=1&cmd=displayKC&docType=kc&noCount=true&ViewedDocsListHelper=com.kanisa.apps.common.BaseViewedDocsListHelperImpl

Oracle:
http://www.oracle.com/technetwork/topics/security/opensslheartbleedcve-2014-0160-2188454.html

Google/Android:
http://googleonlinesecurity.blogspot.co.uk/2014/04/google-services-updated-to-address.html

Debian:
https://www.debian.org/security/2014/dsa-2896

Ubuntu:
http://www.ubuntu.com/usn/usn-2165-1/

Gentoo Linux:
http://www.gentoo.org/security/en/glsa/glsa-201404-07.xml

NetBSD:
http://ftp.netbsd.org/pub/NetBSD/security/advisories/NetBSD-SA2014-004.txt.asc

Nginx:
http://nginx.com/blog/nginx-and-the-heartbleed-vulnerability/

OpenBSD:
http://www.openbsd.org/errata55.html#002_openssl
http://ftp.openbsd.org/pub/OpenBSD/patches/5.5/common/002_openssl.patch.sig

FreeBSD:
http://www.freebsd.org/security/advisories/FreeBSD-SA-14:06.openssl.asc

Suse:
http://support.novell.com/security/cve/CVE-2014-0160.html

openSuse:
http://lists.opensuse.org/opensuse-security-announce/2014-04/msg00004.html

Novell:
http://support.novell.com/security/cve/CVE-2014-0160.html

Redhat:
https://access.redhat.com/security/cve/CVE-2014-0160
https://access.redhat.com/site/announcements/781953

Fedora Project:
https://lists.fedoraproject.org/pipermail/announce/2014-April/003205.html

Slackware:
hxxp://www.slackware.com/security/viewer.php?l=slackware-security&y=2014&m=slackware-security.533622

Sparklabs/viscosity openvpn client:
https://www.sparklabs.com/viscosity/releasenotes/

XenServer:
http://xenserver.org/component/easyblog/entry/xenserver-and-the-openssl-heartbleed-vulnerability.html?Itemid=179

Mozilla:
https://blog.mozilla.org/security/2014/04/08/heartbleed-security-advisory/

HP Networking:
http://h17007.www1.hp.com/docs/advisories/HPNetworkingSecurityAdvisory-OpenSSL-HeartbleedVulnerability.pdf

Citrix:
http://support.citrix.com/article/CTX140605

CAcert:
https://blog.cacert.org/2014/04/openssl-heartbleed-bug/

Fortinet:
http://www.fortiguard.com/advisory/FG-IR-14-011/

F5:
http://support.f5.com/kb/en-us/solutions/public/15000/100/sol15159.html

Aruba Networks:
http://www.arubanetworks.com/support/alerts/aid-040814.asc

Checkpoint:
https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk100173

Watchguard:
http://watchguardsecuritycenter.com/2014/04/08/the-heartbleed-openssl-vulnerability-patch-openssl-asap/

OpenVPN:
https://community.openvpn.net/openvpn/wiki/heartbleed

Despite all the information around I’m still  been asked over and over if there are Microsoft Services or products vulnerable to Heartbleed. The straight answer to that is the following:

Microsoft official spokesman:

“After a thorough investigation, Microsoft determined that Microsoft Account, Microsoft Azure, Office 365, Yammer and Skype, along with most Microsoft Services, are not impacted by the OpenSSL “Heartbleed” vulnerability. Windows’ implementation of SSL/TLS is also not impacted. A few Services continue to be reviewed and updated with further protections.”

http://blogs.technet.com/b/security/archive/2014/04/10/microsoft-devices-and-services-and-the-openssl-heartbleed-vulnerability.aspx

 

In late April 2014 Juniper Networks sent out a Security Advisory for their SSL VPN solution, you might not be aware of it but with the release of Windows 8.1 Microsoft integrated some 3rd-party vendors SSL VPN clients, Juniper is included.

Due to this 3rd-party integration on the OS base installation, all Windows 8.1 x86, x64 and RT should update the OS with the security update KB2962393.

 

Junos Pulse/SA (SSLVPN): Details on fixes for OpenSSL “Heartbleed” issue (CVE-2014-0160)/JSA10623  
http://kb.juniper.net/InfoCenter/index?page=content&id=KB29004

Update for Vulnerability in Juniper Networks Windows In-Box Junos Pulse Client
https://technet.microsoft.com/library/security/2962393

 

2 – Verify if a vulnerable OpenSSL version is installed on Windows OS;

OpenSSL is not the default Windows implementation of SSL/TLS, there is a proprietary API (SSPI), which in case of IIS is Secure Channel, but OpenSSL is relatively common on Open Source platforms, such as Apache Web Servers.

1. You should verify if there is a vulnerable version of OpenSSL installed on Windows systems that are exploring any type of non-MS components;

Example: Apache running on Windows with mod_ssl using OpenSSL.

2. In case you find a vulnerable OpenSSL version installed on Windows you should upgrade to a more recent and non-vulnerable version or alternatively you can recompile OpenSSL with the option “-OPENSSL_NO_HEARTBEATS”;

OpenSSL Upgrade path:
https://www.openssl.org/news/secadv_20140407.txt

3 – Verify if there are non-Microsoft OS’s with a vulnerable version of  OpenSSL;

In your network environment you may have non-Microsoft systems with OpenSSL installed, it is relatively common on Linux Operating Systems and Apache Web Servers, or with services that rely on encryption, such as SSH (port 22), encrypted SMTP (port 26), https (443), NNTP encrypted (563), LDAP over SSL (636), FTP encrypted (989 and 990), Telnet encrypted (992), IMAPS (993), IRC encrypted (994), POP3S (995), etc.

To verify:

1. On your central asset/device management platform (e.g. SCCM) there are any Linux machines, Apache Web Servers or any other machines with OpenSSL installed being reported?

If yes, you should update OpenSSL to a non-vulnerable version or if that’s not possible at the moment at least recompile OpenSSL with option “-DOPENSSL_NO_HEARTBEATS”.

2. On your Mobile Device Management (e.g. Intune) platform there are any devices (e.g. some Android versions) vulnerable to OpenSSL being reported?

If yes, update to a OS version that is not vulnerable to OpenSSL, if that’s not possible you should review your organization security policy, normally the security best practices state that on such cases a vulnerable OS should not be allowed to connect to your network environment or access corporate information systems.

3. There are any systems vulnerable to Heartbleed being hosted on IaaS or Hosting provider?

If yes, you should update to a non-vulnerable version of OpenSSL and follow the recommendations mentioned on step 6.

4 – Verify if your remote access and publishing plataforms are indirectly exposing non-vulnerable systems to Heartbleed;

To access your Web Services or Web Servers you are probably relying on web publishing or reverse proxy network components, such as: network load balancers, Cache services, TLS offloaders, reverse proxy, etc;

If any of these network components supporting the communication channel are vulnerable to Heartbleed, your Front-end and Back-end environment can be exposed either.

Analyze and update the solutions from 3rd-party vendors, such as network appliances, etc, with the vendor list I’ve provided on Step 1.

5 – Assess your environment with vulnerability scanners;

Vulnerability assessment should be a common practice in your network environment, if that’s not the case and you are the one responsible for it you need to reevaluate your management practices and start doing it at a regular basis, it’s a standardized approach in the Industry!

There’s an huge external motivation, specially for the worst reasons, to assess and detect vulnerable systems to Heartbleed, you need to do a Vulnerability assessment as soon as possible, if you have done it recently but prior to Heartbleed disclosure you should repeat the process ASAP.

1. Use a remote vulnerability scanner to assess your published web site or application;

Some examples that you can use at no charge for a remote analysis:

https://www.ssllabs.com/ssltest/

http://tif.mcafee.com/heartbleedtest

https://play.google.com/store/apps/details?id=com.lookout.heartbleeddetector

 

2. Use a vulnerability scanner to check Heartbleed exposure on your local network.

For that you can Run a Pentesting Linux Distribution such as Kali Linux;

You’ll find NMAP which can be used with the Heartbleed detection script:

– Boot your Kali VM, LiveCD or Installation;

– Open a terminal session:

– Update all kali tools and OS components:

sudo apt-get update
sudo apt-get upgrade

– Download and install the Heatbleed detection script on NMAP:

cd /usr/share/nmap/nselib/
sudo wget
https://svn.nmap.org/nmap/nselib/tls.lua
cd /usr/share/nmap/scripts/
sudo wget
https://svn.nmap.org/nmap/scripts/ssl-heartbleed.nse
sudo nmap –script-updatedb

– Scan for Heartbleed through NMAP:

nmap –script ssl-heartbleed [server]

On [server] insert your server IP, netbios, FQDN or IP range (192.168.0.0/24)

 

6 – When you find a System that is vulnerable to Hearbleed;

If you detect a vulnerable system, for such system and all those that are depending of it, to avoid the exposure of credentials and private/public key pairs you should proactively change the passwords for those systems, generate a new private/public key pair of those certificates and proceed with a more deep and broad analysis to evaluate if you had any security compromise.

 

R-Tape Loading error,
Luís Rato

Anúncios

~ por Luis Rato em 18 de Maio de 2014.

Deixe uma Resposta

Preencha os seus detalhes abaixo ou clique num ícone para iniciar sessão:

Logótipo da WordPress.com

Está a comentar usando a sua conta WordPress.com Terminar Sessão / Alterar )

Imagem do Twitter

Está a comentar usando a sua conta Twitter Terminar Sessão / Alterar )

Facebook photo

Está a comentar usando a sua conta Facebook Terminar Sessão / Alterar )

Google+ photo

Está a comentar usando a sua conta Google+ Terminar Sessão / Alterar )

Connecting to %s

 
%d bloggers like this: