Openssl is an opensource software which is widely used for implementing the transport layer security like SSL and TSL. Openssl provides a cryptographic functions and lot of other functions. Almost two years ago ,there is new function injected to openssl version 1.0.1 which is called heartbeat. What the heartbeat protocol does on openssl ? Heartbeat keep the secure connection alive for a bit.It keeps the session alive so it doesn’t get the connection taken down. Typically the SSL connections will be terminated immediately if there is no activity . By using the heartbeat protocol, attackers can steal the memory contents without leaving any trace on the system that the system being hacked.
This flaw allows an attacker to retrieve the private memory of an application that uses the vulnerable openssl libssl library in chunks of 64k at any time. Note that an attacker can repeatedly leverage the vulnerability to retrieve as many 64K chunks of memory as are necessary to retrieve the intended secrets.(Like credit card information,passwords, and other sensitive information etc..). So heartbeat protocol leaks the memory contents and that’s why this bug is named as heartbleed .
In order to coordinate recovery from this bug , opensource have classified the compromised secrets to four categories
- primary key material (secret keys)
- Secondary key material (Username and password)
- Protected content (sensitive data)
- Collateral (Memory address)
Any service that supports STARTLS (imap,smtp,http,pop) may also be affected. You can find more information about heartbleed here.
Here is the impacted and non-impacted openssl version.
[highlight]OpenSSL 1.0.1 through 1.0.1f (inclusive) are vulnerable[/highlight]
OpenSSL 1.0.1g is NOT vulnerable
OpenSSL 1.0.0 branch is NOT vulnerable
OpenSSL 0.9.8 branch is NOT vulnerable
1. How can you find if VMware ESXi node is affected by heartbleed or not ?
You can check the openssl version using the below command.VMware ESXi 5.5 has vulnerable openssl .Login to ESXi server and execute the below mentioned commands.
~ # vmware -vl VMware ESXi 5.5.0 build-1331820 VMware ESXi 5.5.0 GA ~ # openssl version -a |grep OpenSSL OpenSSL 1.0.1e 11 Feb 2013 ~ #
2.How can i find if my VMware vCenter server is affected by heartbleed or not ? (Vmware vCenter server 5.5 is impacted )
Login to vcenter server and start – > run – > cmd (Press Enter)
Microsoft Windows [Version 6.1.7601] Copyright (c) 2009 Microsoft Corporation. All rights reserved. C:\Users\Lingeswaran>"C:\Program Files\VMware\Infrastructure\Inventory Service\bin\openssl.exe" version -a OpenSSL 0.9.8y 5 Feb 2013 built on: Tue Feb 12 23:38:08 2013 platform: VC-WIN64A OPENSSLDIR: "/usr/local/ssl" C:\Users\Lingeswaran>"C:\Program Files\VMware\CIS\openSSL\openssl.exe" version -a OpenSSL 1.0.1e 11 Feb 2013 built on: Tue Feb 12 19:37:08 2013 platform: VC-WIN64A OPENSSLDIR: "/usr/local/ssl" C:\Users\Lingeswaran>
In my case, i have two version of openssl and openssl 1.0.1e has the vulnerable.
3.How to fix the issue ?
As of now there is no direct patch has been released by VMware to fix the vulnerable openssl. But you can isolate the management network from the internet. Normally virtual machines are exposed to the internet and exposuring the Vsphere components directly on the internet is strongly discouraged .
Here is the small test to find whether the heartbeat is enabled or not .
Login to VMware ESXi 5.5 server and run the below command.
~ # openssl s_client -connect 192.168.2.51:443 -tlsextdebug
CONNECTED(00000003)
TLS server extension "renegotiation info" (id=65281), len=1
0001 - <SPACES/NULS>
TLS server extension "heartbeat" (id=15), len=1
0000 - 01 .
depth=0 C = US, ST = California, L = Palo Alto, O = "VMware, Inc", OU = VMware E SX Server Default Certificate, emailAddress = ssl-certificates@vmware.com, CN = localhost.localdomain, unstructuredName = "1391302217,564d7761726520496e632e"
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = US, ST = California, L = Palo Alto, O = "VMware, Inc", OU = VMware E SX Server Default Certificate, emailAddress = ssl-certificates@vmware.com, CN = localhost.localdomain, unstructuredName = "1391302217,564d7761726520496e632e"
verify error:num=27:certificate not trusted
verify return:1
depth=0 C = US, ST = California, L = Palo Alto, O = "VMware, Inc", OU = VMware E SX Server Default Certificate, emailAddress = ssl-certificates@vmware.com, CN = localhost.localdomain, unstructuredName = "1391302217,564d7761726520496e632e"
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:/C=US/ST=California/L=Palo Alto/O=VMware, Inc/OU=VMware ESX Server Default Certificate/emailAddress=ssl-certificates@vmware.com/CN=localhost.localdomain/un structuredName=1391302217,564d7761726520496e632e
i:/O=VMware Installer
---
subject=/C=US/ST=California/L=Palo Alto/O=VMware, Inc/OU=VMware ESX Server Defau lt Certificate/emailAddress=ssl-certificates@vmware.com/CN=localhost.localdomain /unstructuredName=1391302217,564d7761726520496e632e
issuer=/O=VMware Installer
---
No client certificate CA names sent
---
SSL handshake has read 1147 bytes and written 637 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : AES256-GCM-SHA384
Session-ID:
Session-ID-ctx:
Master-Key: 2257233FAA935CFE8A08730EC9DCD08CB353873DDB0B20E78227E51975F9E6D0 7A219FCD1A660D890B90255F217C5F29
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1394096526
Timeout : 300 (sec)
Verify return code: 21 (unable to verify the first certificate)
---
bad select 4
~ #
If you see “TLS server extension “heartbeat” (id=15), len=1″ in the above command output,then the host has the heartbleed bug.
Refer the VMware KB to find the other impacted Vmware products on this bug.
Hope this article is informative to you. Share it ! Comment it !! Be Sociable !!!
Leave a Reply