Home / VMware / vCenter Server 5.5 / Heartbleed vulnerability on VMware ESXI 5.5 and Vcenter 5.5

Heartbleed vulnerability on VMware ESXI 5.5 and Vcenter 5.5

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

  1. primary key material (secret keys)
  2. Secondary key material (Username and password)
  3. Protected content (sensitive data)
  4. 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.

OpenSSL 1.0.1 through 1.0.1f (inclusive) are vulnerable

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 !!!

VMTURBO-CLOUD-CAPACITY

Leave a Reply

Your email address will not be published. Required fields are marked *