thatsBroken

Let me start out by saying that ESX and ESXi both have the ability to allow management from a defined IP address or IP mask.  In addition, they both allow you to set a management interface and bind the management interface to only allow connections from an administrative subnet.  This is just security best practice and in this case, following best practice will mitigate much of the risk involved in this ‘Information Leakage’ issue.

Both ESX and ESXi have a web based management interface that can be used to browse the data store and download the vShpere (thick) client for managing the ESX/ESXi host.  This management interface seems a little dangerous to me in that exposes a massive web service (vim.wsdl) and at lest a portion can queried successfully without authentication.

The webservice endpoint is at https://esx-server-ip/sdk

The web service is configured to point to /usr/lib/vmware/hostd/docroot if you want to go snooping yourself.

I do vulnerability research and write code to detect remotely vulnerable hosts on a network.  Some of the best remote detection rules I’ve written depend on very obscure ‘information disclosure’ vulnerabilities.

Web apps there are all kinds of tricks to finding the exact build of an app by generating diffs of publicly accessible supporting java-script files.  Another trick is to enumerate all of the calls you can  make to a web service as an unauthenticated user and then start parsing the responses.  You’ll start to develop a fuzzy finger print that will generate ranges of possible versions.

This blog posting isn’t about any of these neat techniques.  This blog post is about sending a single specific post to the vmware sdk running on the management interface with no authentication or cookie trickery.

The following post request will generate an xml response that be parsed to identify the ESX version right down to the build level.  The build level is increased on every major update which provides exceptional granularity to patch detection.

POST /sdk HTTP/1.1\r\nContent-Type: text/xml; charset=\”utf-8\”\r\nSOAPAction: \”urn:internalvim25/4.0\”\r\nContent-Length: 410\r\n\r\n<soap:Envelope xmlns:xsd=\”http://www.w3.org/2001/XMLSchema\” xmlns:xsi=\”http://www.w3.org/2001/XMLSchema-instance\” xmlns:soap=\”http://schemas.xmlsoap.org/soap/envelope/\”>\r\n  <soap:Body>\r\n    <RetrieveServiceContent xmlns=\”urn:internalvim25\”>\r\n      <_this xsi:type=\”ServiceInstance\” type=\”ServiceInstance\” serverGuid=\”\”>ServiceInstance</_this>\r\n    </RetrieveServiceContent>\r\n  </soap:Body>\r\n</soap:Envelope>\r\n\r\n\r\n

What does the response look like?

Well you get a whole bunch of XML but the interesting bit is here:

<RetrieveServiceContentResponse xmlns=”urn:internalvim25″><returnval><rootFolder type=”Folder”>ha-folder-root</rootFolder><propertyCollector type=”PropertyCollector”>ha-property-collector</propertyCollector><viewManager type=”ViewManager”>ViewManager</viewManager><about><name>VMware ESX</name><fullName>VMware ESX 4.0.0 build-164009</fullName><vendor>VMware, Inc.</vendor><version>4.0.0</version><build>164009</build><localeVersion>INTL</localeVersion><localeBuild>000</localeBuild><osType>vmnix-x86</osType><p

So my question to you:  Is this a ‘vulnerability’ vmware needs to fix or just some undocumented feature that doesn’t really need to be fixed?  The build number matches directly to patches that increment the build when applied…