So this is a *really* old blog post that I wrote a while back when I discovered, or at least so I believed, an XXE bug in the VMware vSphere client. I reported this to the VMware security team but they were not able to reproduce the part where you would use a UNC path to try and steal the credentials of an user. I then got busy and never continued to investigate why they were not able to reproduce it. Since the vSphere client is being replaced by a web client I decided it couldn’t hurt to release this old post, also the likely hood of this being exploited is pretty low.
Curiosity (from Latincuriosus “careful, diligent, curious,” akin to cura “care”) is a quality related to inquisitive thinking such as exploration, investigation, and learning, evident by observation in human and many animal species. (Wikipedia)
As always a driving force behind many discoveries, as well as the recent bug I found in the VMware vSphere client (vvc). Not a very interesting bug, yet a fun journey to approach things from a different perspective. After my last post about a portable virtual lab I wondered what the vvc used as a protocol to communicate with the esxi server and if it could contain any bugs. So this time instead of getting out ollydbg I decided to go for a more high-level approach. Let’s see how I poked around and found the XML External Entity (XXE) (pdf) vulnerability in the vvc.
I first looked in the directory of vvc, just to know the type of files that resided there, here is a screenshot:
Logically the file that drew my attention was the config file of which the following settings also seemed like they would come in handy:
Seems like if we want to tinker with the connection a higher time-out would give us more time and a higher verbosity level of logging could help us during the poking around. Enough looking around at this point let’s get more active.
If you google around you’ll find that the vvc uses port 443 for it’s connections and you’ll find a nice presentation and tool with an overview of multiple vulnerabilities that concern the esx infrastructure:
From the above presentation you see two nice attacks on the client namely:
- user assisted code execution
- password sniffing
You can also deduce that the client uses XML for it’s communication since it requests ‘/client/clients.xml’. Which implies that the client might be vulnerable for several known XML attacks. Now let’s see if the client is actually vulnerable for some known XML attacks. The first attacks that came to my mind are:
- External entity attack
- Billion laughs attack aka XML bomb
Why these two you might ask? Well the first one cause it usually yields nice results and the second one cause I’ve always wanted to try it. So let’s man-in-the-middle the vvc. WAIT….why would you still dig into the client if there are already two nice vulnerabilities for it one of them being code execution for crying out loud. I’ll sum it up in one word:
curiosity
A lot of times that’s more then enough reason to do stuff. Now let’s get on with testing if the vvc is vulnerable to an xxe attack. So we need to mitm the client, as always (when it’s a http based protocol) I wip out BURP. So the setup is as follow: VVC <—> BURP <—> ESXI, which translates to the following proxy configuration in burp:
So we listen on all interfaces on port 443 and redirect traffic to the esxi host 10.80.0.100. Now out of curiosity we’ll also have DebugView running, you never know what messages an application might show you. If you set the burp proxy to intercept server responses you’ll see the following when the vvc requests the ‘/client/clients.xml’:
If you drop the request in burp you’ll see the following in debugview:
Well this looks promising doesn’t it? We can control the communication between the vvc and the server and vvc also outputs more then enough debug information to know what’s going on. So let’s try and attack the client using the following response:
Hmm the client gives us an error stating that the hostname can’t be resolved which doesn’t really answer the question if the attack worked or not. So let’s have a look with process monitor:
Well that’s rather nice isn’t it? The vvc actually reads the file, we just don’t have a nice way to exfiltrate the contents of it. However we can also supply a network path and capture the credentials without the user knowing it, there are more then enough tutorials out there which illustrate this. The billion laughs attack is pretty straightforward you can copy/paste the wikipedia example and you’ll see your cpu and memory use go up, eventually .NET will give an out-of-memory exception but (afaik) it won’t really bring down the client.
DiabloHorn 