We break through VMware vCenter

    Security of virtual systems is now a fashionable trend, so this question cannot be ignored. Today we will break the heart of the VMware infrastructure - the vCenter server. At the same time, we will use 0-day vulnerabilities so that life does not seem like honey. We will break it with old-school methods that are in no way connected with virtual technologies: the trend, of course, is fashionable, but the bugs are all the same banal.

    PS: As usual with responsible white-huts, all the bugs described here should already be closed, they were 0-days at the time of hacking, that is, in 2011. This text was published in Hacker Magazine No. 7/12 (162), and was also the basis for reports at CONFidence 2012, PHD 2012 and Defcon 20.



    VMware vCenter



    Many enterprise systems live in virtual environments. It's cheaper. It’s more convenient, it’s cooler! The leader in providing these same environments is the notorious VMware company. These guys have a cool hypervisor and, which is also important, a bunch of all kinds of software for easy deployment, management and control. All this makes VMware solutions flexible, scalable, and ultimately efficient. For convenient administration of all this cool little guy, the guys developed server software, which consolidates the entire administrative part of the infrastructure - VMware vCenter. That is, you have, for example, 10 iron machines with VMware ESX (i). A total of 50 virtual machines are running on them. Administering this virtual zoo is rather inconvenient if you do not have this vCenter itself. In addition, thanks to vCenter, all sorts of tricks are possible, like transparent migration of virtual images in the event of failure of one of the ESX to work, etc. In short, a mega-convenient and important thing. This is the end of the advertisement. The main point is that if an evil hacker breaks your vCenter, the entire network is in its nasty hands.

    We break through the defense



    The famous researcher Claudio Criscone has come across this “center” more than once, and therefore knows how to break it. So, in one of the pen-tests, I came across this software and decided to use Claudio’s wisdom in order to forget everything there. Actually, Claudio's idea was simple: our friend found a vulnerability in the vCenter update manager. The vulnerability was not even the fault of VMware programmers. The fact is that the web interface of this manager (hanging on TCP port 9084) uses Jetty as a web server. Therefore, Claudio found the vulnerability there. Vulnerability - a classic of the genre: going beyond the boundaries of the catalog:

    target:9084/vci/download/health.xml/%3f/../../../../../../FILE.EXT


    Claudio slide from BlackHat conference ;-)

    It's simple: we read any files on which the account under which vCenter is running has enough rights. But here is the question that Claudio asked - how can I read a file? In general, he rummaged in the file system and found a wonderful access log file in which the session code was stored (see screenshot of the slide).


    The contents of the ill-fated file ;-)

    What is this code? The fact is that the vSphere client works with vCenter via SOAP, that is, it is regular HTTPS traffic, in the body of which is an XML structure with data, commands, etc. In this case, after the administrator authentication, the SOAP session code is written to it , and then this code is checked as a cookie with PHPSESSIONID, like analogue 8) Obviously, having stolen this code, we can slip it into our SOAP request, and vCenter will think that we have already authenticated as some admin (if the session is still alive ) That is, Claudio suggests through a vulnerability in the Jetty web server to read the log with these SOAP codes.

    target:9084/vci/download/health.xml/%3f/../../../../../../ProgramData\VMware\VMware VirtualCenter\Logs\vpxd-profiler-6.log

    Then, substitute these codes into requests from vSphere. To do this, he even developed a proxy server, which on the fly replaces the session code in packages from vSphere, and included this proxy in his Metasploit add-on VASTO. In addition, in this addon there are many other chips, but now we will not talk about it.

    In this way, our Italian friend from Google suggests punishing vCenter. But the trouble was that all these bugs were outdated by the time of my pen-test (spring-summer 2011): we had to deal with the latest version of the software, which means that Jetty was patched-patched.

    Doesn’t the shell hit the same funnel twice?

    Feeling disappointed (the freebies did not work), I began to think what to do. In general, any pen tester in this situation will simply pass by and write in the report that there are no vulnerabilities on this resource. But, as usual, feeling indignation in the Force, I did not trust these patches of yours. Something made me continue to mock Jetty by combining exploit options to go outside the directory. And after 15 minutes I got the result. A vulnerability was again in another place of the same update manager:

    target:9084/vci/download/.\..\..\..\..\..\..\..\..\FILE.EXT

    This is already something, because you can go read the file with SOAP codes!


    Trying to find your happiness ...

    But again, we were disappointed - session codes are no longer in this wonderful file. You can only note the excellent work of the programmers from VMware, who swept the logs and made us byaku. Well, let's look for ourselves what else can be on the file system, what comes in handy ... The very first thing that comes to mind is to steal the secret key for SSL. Then with this key we can intercept SSL traffic and decrypt it (wireshark allows you to do this without problems). The key itself can be found like this:

    target:9084/vci/downloads/.\..\..\..\..\..\..\..\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\SSL\rui.key

    Accordingly, if we organize a man-in-the-middle attack using ARP SPOOFING, we can intercept traffic between the server and the administrative workstation. By the way, the IP addresses of administrators and their logins can still be found in the profiler file. Of course, we can replace the SSL certificate (cain can do this without problems) and decrypt the traffic without stealing the key, but then the administrator will see a warning about an invalid SSL certificate. If we stole the key, the administrator will not see anything, since the certificate will be correct. That is, such an attack is more cunning and secretive ...


    Warning about a fake certificate!

    VMware vCenter Orchestrator

    But on the server with vCenter there is one more wonderful thing that comes free of charge and is installed at will - it is the Orchestrator. Another management interface, this time by the Center itself. What is this for? And this is no less cool thing. It is used to manage the life cycle of a data center. This is a whole framework for developing and automating various processes in a virtual infrastructure. In short, that's cool and that's it. Studying the file system, I came across the following file:

    target:9084/vci/download/.\..\..\..\..\..\..\..\..\Program files\VMware\Infrastructure\Orchestrator\configuration\jetty\etc\passwd.properties


    Already something!

    That's exactly how we get some MD5 hash. It is obvious that there is a password hidden from the administrative account in this same "Orchestra". What can I say? Using salt-free MD5 is not a secret. So in this context, we got the password very quickly (in the screenshot, the default password hashed the password, by the way, so administrators can also cause problems). Using the received password, we logged in through the web interface. Comfortable, cute, nice design, but we need more. Poking around in the web interface, we noticed that the same vCenter Server is used to manage the virtual infrastructure, which means that the Orchestrator must be able to authenticate there. And he knows how, because somewhere in the settings an access password is set.


    Access Settings for vCenter.

    Having opened the HTML-code, I was happy: the password is displayed there in the clear, as it is, although visually, in the browser, it hides behind the "stars".


    The admin account from vCenter is ours!

    In addition, there are passwords from the mail account, from domain accounts and from other things that the Orchestrator should be able to use. Straight password manager for a hacker! It is clear that the entire system was successfully hacked, not only virtual, but also a domain controller, which means everything that was there.

    Moarrrrrr!



    It would seem that everything, but there is one more detail. As you noticed, the Orchestrator stores passwords somewhere. And so that they can be obtained in pure form and used. This tells us that it was possible not to break the MD5 hash, but to look for where these passwords lie. Rummaging around a bit, I found them: for example, the password for vCenter access is stored:

    target:9084/vci/download/.\..\..\..\..\..\..\..\..\Program Files\VMware\Infrastructure\Orchestrator\app-server\server\vmo\conf\plugins\VC.xml

    Moreover, judging by the format of the encoded string, this encryption is reversible. Even similar passwords look very encrypted.

    truehttps://new-virtual-center-host:443/sdkvmware000a506275767b74786b383a4a60be767864740329d5fcf324ec7fc98b1e0aaeef %u


    Another interesting file is C: \ Program Files \ VMware \ Infrastructure \ Orchestrator \ app-server \ server \ vmo \ conf \ vmo.propirties. Here, the DBMS password is encoded using the same method.

    It remains to understand the essence of the encoding method and understand whether our guess is true or not. This is where my friend and colleague comes in, and part-time, also the LeetMore CTF team player, Alexander jugMinozhenko. For him, such tasks are like two fingers ... With one glance he determined that the first two bytes describe the length of the entire password, and then comes the encoded representation. Sasha simply decompiled the Java class of the “Orchestrator”, which is responsible for saving the password, and parsed the encoding algorithm. The bottom line is simple: take the password length, then encode each byte of the password into a hex, adding to it the position number of the byte (starting from zero). Thus, the encoded value is “Password01.” looks like:

    000a506275767b74786b383a4a60be767864740329d5fcf324ec7fc98b1e0aaeef

    Sasha wrote a decoder (in Ruby):

    #Закодированная строка
    pass = "010506275767b74786b383a4a60be767864740329d5fcf324ec7fc98b1e0aaeef"
    #Считаем длину
    len = (pass[0..2]).to_i # Первые 3 символа длина пароля
    enc_pass = pass[3..-1].scan(/.{2}/)  # Разбиваем hex-строку на  байты
    dec_pass = (0...len).collect do |i|  
            byte = enc_pass[i].to_i(16) # Переводим hex в целое число
            byte -= i # вычитаем позицию байта и получаем раскодированное значение
            byte.chr 
    end
    #Результат – чистый пароль: “Password01.”
    puts "Password: #{dec_pass.join()}"
    


    Thus, the attack comes down to using our 0-day, to read a file, and the second - to decode passwords from read files. And again, we get full access to vCenter. In a few seconds ... (the corresponding module for Metasploit is ready)

    The final



    As you can see, 0-day are simple and dangerous. What can I say more? .. If administrators filtered access using a firewall, restricting access to administrative ports, an attack would be much more difficult. Much remains behind the scenes, because protecting the virtual infrastructure is not just one minute and not one server. I can advise everyone on the VMware Hardening Guide (http://www.vmware.com/files/pdf/techpaper/VMW-TWP-vSPHR-SECRTY-HRDNG-USLET-101-WEB-1.pdf). This PDF lists many places worth paying attention to. That's all, do not be sick!

    Also popular now: