mailing list archives
Re: Regarding VMWare and OpenSSH vulns
From: Aleksandar Nikolic <nikolic.alek () gmail com>
Date: Sat, 23 Jun 2012 14:03:24 +0200
Forgot to add a link to that ssh CRC bug
And one other thing. There was a mention
of "Trinity" ssh bug during the meeting.
The bug that Trinity in matrix uses tu hack into matrix after running nmap.
We joked about it, and I thought it might be fun
to have it as a script, in case in some distant future some Trinity
actually needs it.
Turns out it's not that easy to exploit. Problem
is it requires quite a bit of ssh protocol to
implemented. Even original exploits from that time, as far as I know,
used a patched-up version of an actual ssh client, and not a
standalone exploit. So, maybe it would be
doable once NSE has ssh lib.
In case you care for this piece of history, the bug it self was found
by Michal Zalewski and here are a few links with details:
On Sat, Jun 23, 2012 at 1:51 PM, Aleksandar Nikolic
<nikolic.alek () gmail com> wrote:
on the last nse brainstorming meeting, I was tasked with looking
into recent VMWare and OpenSSH vulns and selecting the ones
which would be suitable for nse scripts. This is what I've found.
I've browsed trough VMWare security advisories for this year.
Most of the vulns are local privileges escalation and guest to
host escape vulns. I have found only three remotely exploitable
vulns, which are pretty specific.
VMware Virtual Machine Remote Device Denial of Service
VMWare has the ability to attach remote devices, like CDROMs or such, to
a virtual machine. An attacker that controls the remote device, can exploit
this vulnerability to cause Denial Of Service against the VM.
Since this vulnerability requires a control over remote device,
without it we are unable
to check for this vuln. Only way would be by fingerprinting the VMWare software
and matching the vulnerable version.
ESX NFS traffic parsing vulnerability
There is a vulnerability in ESX(i) when parsing NFS traffic.
An attacker that can control NFS traffic can exploit this vulnerability to
cause Denial Of Service against the VM or even achieve remote code execution.
Same comment applies for this one. It might not be impossible to trigger the
bug by NSE script, but it will most certainly be very very difficult.
Apart from that obvious complexity, the advisory is lax on details which would
make it even more difficult. Also, it would require a pretty specific ESX setup.
The vCenter Chargeback Manager (CBM) contains a flaw in its handling
of XML API requests. This vulnerability allows an unauthenticated
remote attacker to download files from the CBM server or conduct a
denial-of-service against the server.
This one might not be that hard to check for or even exploit. But
again, very specific software which I don't think is freely available,
and lack of info in the advisory.
For all this vulnerabilities, easiest way to check for them is to
When we have VMWare Workstation or player, only thing we can access remotely is
vmauthd whose version rarely changes and which doesn't reflect the VM version.
So that one is useless for out purpose.
Another thing is fingerprinting ESX. I've discussed this with David,
and there are already
service probes for it, so fingerprinting would be done by version scan.
I've looked into metasploit's vmware scripts, and only two pre-auth
scripts are vmauth brute, which we already have, and ESX
fingerprinting which I've discussed above.
I must say that I'm somewhat disappointed as I can't say that any of
would be suitable for NSE scripts.
Maybe the original author of the idea on the ScriptIdeas page has some
Now for OpenSSH vulns:
Idea here was to go trough recent OpenSSH vulns and select ones that
are _practical_ vulns and not theoretical crypto flaws, and select the
ones that would make a nice NSE script.
There is really only one problem here. There weren't that many OpenSSH
vulns in the past 10 years.
Only vuln I could find that might be suitable for NSE script and
wasn't more than 10 years old was Tavis Ormandy's CRC DoS vuln from
2006 which would very well be detected by version matching.
Believe me, I am as sad as you are that there are no more OpenSSH vulns...
Again, if the original idea author has some specific ideas, please share.
And of course, if anybody has some ideas about these two topics, please
Sent through the nmap-dev mailing list
Archived at http://seclists.org/nmap-dev/