We punch VMware vCenter
Virtual system security is now a fashion trend, so you can not ignore this issue. Today we will break the very heart of the VMware infrastructure - the vCenter server. In this case, we will use 0-day vulnerabilities so that life does not seem like honey. We will break with old-school methods that are not related to virtual technologies: the trend, of course, is fashionable, but the bugs are all the same trivial.
PS: As usual in responsible white hats, all the bugs described here should already be closed, they were 0-actions at the time of hacking, that is, in 2011. This text was published in Hacker No. 7/12 (162) and also served as the basis for reports at CONFidence 2012, PHD 2012 and Defcon 20.
')
Many corporate systems live in virtual environments. It's cheaper. It is more convenient, it is cooler! The leader in providing these very environments is the notorious VMware company. These guys have a cool hypervisor and, which is also important, a bunch of software for convenient deployment, management and control. All this makes VMware solutions flexible, scalable and, ultimately, effective. For convenient administration of all this cool money, the guys have developed server software that consolidates the entire administrative part of the infrastructure - VMware vCenter. That is, you have, for example, 10 iron machines with VMware ESX (i). They have a total of 50 running virtual machines. To administer 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, such as transparent migration of virtual images in the event one ESX fails to work, etc. In short, a mega-friendly and important thing. On this advertising is over. The main point is that if an evil hackIr breaks your vCenter - the whole network is in his nasty hands.
The famous researcher Claudio Criscone has repeatedly come across this “center”, and therefore knows how to break it. Here I am in one of the pen tests I ran into this software and decided to use the wisdom of Claudio to fill it all. 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 (hangs on TCP port 9084) uses Jetty as the web server. Therefore, Claudio found the vulnerability there. Vulnerability - a classic of the genre: going beyond the directory:
Slide Claudio from the Blackhat Conference ;-)
It's simple: we read any files for which the account, from which vCenter is running, has enough rights. But the question that Claudio asked is how to read the file? In general, he rummaged through 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 malicious file ;-)
What is this code? The fact is that the vSphere client works with the vCenter via the SOAP protocol, that is, it is normal HTTPS traffic, the body of which is an XML structure with data, commands, etc. At the same time, after administrator authentication, the code of the SOAP session is written to it , and subsequently this code is checked as a cookie with PHPSESSIONID, an analog type 8) Obviously, having stolen this code, we can slip it into our SOAP request, and vCenter will think that we have already authenticated as a kind of admin (if the session is still alive) ). That is, Claudio suggests reading a log with these SOAP codes through a vulnerability in the Jetty web server.
Then you should substitute these codes in requests from vSphere. For this, he even developed a proxy server, which on the fly replaces the session code in packages from vSphere, and included this proxy as part of his add-on to Metasploit - 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 is that all these bugs were outdated by the time of my pen test (spring-summer 2011): we had to deal with the latest software version, which means that Jetty was patched-patched.
Does the projectile fall into the same funnel twice?
Frustrated (freebies did not work), I began to think what to do. In general, any pen-tester in such a situation will simply pass by and write in a report that there are no vulnerabilities on this resource. But, as usual, feeling the disturbances in the Force, I did not trust these to your patches. Something made me continue to mock Jetty, combining options for an exploit to go beyond the catalog. And after 15 minutes I got the result. Already in another place of the same update manager, again there was a vulnerability:
This is already something, because you can go read a file with SOAP-codes!
Trying to find your happiness ...
But again, disappointment awaited us - the session codes are no longer contained in this wonderful file. One can only note the excellent work of programmers from VMware, who swept the logs and made us badby. Well, let's find out for ourselves what else could be on the file system, which is useful to us ... 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 as follows:
Accordingly, if we organize the man-in-the-middle attack using ARP SPOOFING, we will be able to intercept traffic between the server and the administrative workstation. By the way, 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 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, as 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 with a free appendage and is installed at will - this is the “Orchestrator”. Another management interface, this time by the “Center” itself. What is it for? And this is not less cool stuff. It is used to manage the data center lifecycle. This is a whole framework for developing and automating various processes in a virtual infrastructure. In short, it's cool and that's it. Studying the file system, I came across the following file:
Already something!
That's exactly how we get some MD5-hash. Obviously, there is hidden the password from the administrative account in this very “Orchestrator”. What can I say? Using MD5 without salt is not a secret. So in this context, we very quickly got the password (in the screenshot, the default hashed password, by the way, so administrators can also cause problems). Using the received password, we logged in through the web interface. Comfortable, cute, pretty design, but we need more. Having checked the web interface, we noticed that the same vCenter Server is used to manage the virtual infrastructure, which means that the Orchestrator should be able to authenticate there. And he knows how, because somewhere in the settings an access password is set.
Access settings to 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 asterisks.
Admin account from vCenter is ours!
In addition, there passwords from the mail account, from domain accounts and from other things that the "Orchestra" should be able to use. Directly 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.
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 its pure form and use. This tells us that it was possible not to break the MD5-hash, but to look for where these passwords lie. Having rummaged a bit, I did find them: for example, the password for vCenter access is stored:
And, judging by the format of the encoded string, this encryption is reversible. Even similar passwords look encrypted very similar.
Another interesting file is C: \ Program Files \ VMware \ Infrastructure \ Orchestrator \ app-server \ server \ vmo \ conf \ vmo.propirties. Here the password from the DBMS is encoded in the same way.
It remains to understand the essence of the coding method and understand whether our guess is correct or not. This is where my friend and colleague comes in, and also the CTF-team player LeetMore - Alexander jug Minozhenko. For him, such puzzles are like two fingers ... With one of his eyes, he determined that the first two bytes describe the length of the entire password, and then comes the coded representation. Sasha simply decompiled the Orchestrator Java class, which is responsible for saving the password, and parsed the encoding algorithm. The point is simple: we take the password length, then we encode every byte of the password in Hex, adding to it the position number of the byte (starting from zero). Thus, the coded value of “Password01.” Looks like:
Sasha wrote a decoder (on Ruby):
Thus, the attack is reduced to the use of our 0-day, to read the file, and the second - to decode passwords from the read files. And again we get full access to vCenter. In a few seconds ... (the corresponding module for Metasploit is ready)
As you can see, 0-dei are simple and dangerous. What else can be said? .. If administrators filtered access using a firewall, restricting access to administrative ports, it would be much more difficult to launch an attack. Much remains behind the scenes, because the protection of the virtual infrastructure is not the matter of one minute and not one server. I can advise everyone VMware Hardening Guide (http://www.vmware.com/files/pdf/techpaper/VMW-TWP-vSPHR-SECRTY-HRDNG-USLET-101-WEB-1.pdf). This PDF contains many places you should pay attention to. That's all, do not get sick!
PS: As usual in responsible white hats, all the bugs described here should already be closed, they were 0-actions at the time of hacking, that is, in 2011. This text was published in Hacker No. 7/12 (162) and also served as the basis for reports at CONFidence 2012, PHD 2012 and Defcon 20.
')
VMware vCenter
Many corporate systems live in virtual environments. It's cheaper. It is more convenient, it is cooler! The leader in providing these very environments is the notorious VMware company. These guys have a cool hypervisor and, which is also important, a bunch of software for convenient deployment, management and control. All this makes VMware solutions flexible, scalable and, ultimately, effective. For convenient administration of all this cool money, the guys have developed server software that consolidates the entire administrative part of the infrastructure - VMware vCenter. That is, you have, for example, 10 iron machines with VMware ESX (i). They have a total of 50 running virtual machines. To administer 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, such as transparent migration of virtual images in the event one ESX fails to work, etc. In short, a mega-friendly and important thing. On this advertising is over. The main point is that if an evil hackIr breaks your vCenter - the whole network is in his nasty hands.
Breaking through the defense
The famous researcher Claudio Criscone has repeatedly come across this “center”, and therefore knows how to break it. Here I am in one of the pen tests I ran into this software and decided to use the wisdom of Claudio to fill it all. 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 (hangs on TCP port 9084) uses Jetty as the web server. Therefore, Claudio found the vulnerability there. Vulnerability - a classic of the genre: going beyond the directory:
target:9084/vci/download/health.xml/%3f/../../../../../../FILE.EXTSlide Claudio from the Blackhat Conference ;-)
It's simple: we read any files for which the account, from which vCenter is running, has enough rights. But the question that Claudio asked is how to read the file? In general, he rummaged through 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 malicious file ;-)
What is this code? The fact is that the vSphere client works with the vCenter via the SOAP protocol, that is, it is normal HTTPS traffic, the body of which is an XML structure with data, commands, etc. At the same time, after administrator authentication, the code of the SOAP session is written to it , and subsequently this code is checked as a cookie with PHPSESSIONID, an analog type 8) Obviously, having stolen this code, we can slip it into our SOAP request, and vCenter will think that we have already authenticated as a kind of admin (if the session is still alive) ). That is, Claudio suggests reading a log with these SOAP codes through a vulnerability in the Jetty web server.
target:9084/vci/download/health.xml/%3f/../../../../../../ProgramData\VMware\VMware VirtualCenter\Logs\vpxd-profiler-6.logThen you should substitute these codes in requests from vSphere. For this, he even developed a proxy server, which on the fly replaces the session code in packages from vSphere, and included this proxy as part of his add-on to Metasploit - 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 is that all these bugs were outdated by the time of my pen test (spring-summer 2011): we had to deal with the latest software version, which means that Jetty was patched-patched.
Does the projectile fall into the same funnel twice?
Frustrated (freebies did not work), I began to think what to do. In general, any pen-tester in such a situation will simply pass by and write in a report that there are no vulnerabilities on this resource. But, as usual, feeling the disturbances in the Force, I did not trust these to your patches. Something made me continue to mock Jetty, combining options for an exploit to go beyond the catalog. And after 15 minutes I got the result. Already in another place of the same update manager, again there was a vulnerability:
target:9084/vci/download/.\..\..\..\..\..\..\..\..\FILE.EXTThis is already something, because you can go read a file with SOAP-codes!
Trying to find your happiness ...
But again, disappointment awaited us - the session codes are no longer contained in this wonderful file. One can only note the excellent work of programmers from VMware, who swept the logs and made us badby. Well, let's find out for ourselves what else could be on the file system, which is useful to us ... 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 as follows:
target:9084/vci/downloads/.\..\..\..\..\..\..\..\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\SSL\rui.keyAccordingly, if we organize the man-in-the-middle attack using ARP SPOOFING, we will be able to intercept traffic between the server and the administrative workstation. By the way, 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 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, as 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 with a free appendage and is installed at will - this is the “Orchestrator”. Another management interface, this time by the “Center” itself. What is it for? And this is not less cool stuff. It is used to manage the data center lifecycle. This is a whole framework for developing and automating various processes in a virtual infrastructure. In short, it'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.propertiesAlready something!
That's exactly how we get some MD5-hash. Obviously, there is hidden the password from the administrative account in this very “Orchestrator”. What can I say? Using MD5 without salt is not a secret. So in this context, we very quickly got the password (in the screenshot, the default hashed password, by the way, so administrators can also cause problems). Using the received password, we logged in through the web interface. Comfortable, cute, pretty design, but we need more. Having checked the web interface, we noticed that the same vCenter Server is used to manage the virtual infrastructure, which means that the Orchestrator should be able to authenticate there. And he knows how, because somewhere in the settings an access password is set.
Access settings to 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 asterisks.
Admin account from vCenter is ours!
In addition, there passwords from the mail account, from domain accounts and from other things that the "Orchestra" should be able to use. Directly 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 its pure form and use. This tells us that it was possible not to break the MD5-hash, but to look for where these passwords lie. Having rummaged a bit, I did find 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.xmlAnd, judging by the format of the encoded string, this encryption is reversible. Even similar passwords look encrypted very similar.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <virtual-infrastructure-hosts> <virtual-infrastructure-host xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="VirtualCenterHost"> <enabled>true</enabled> <url>https://new-virtual-center-host:443/sdk</url> <administrator-username>vmware</administrator-username> <administrator-password>000a506275767b74786b383a4a60be767864740329d5fcf324ec7fc98b1e0aaeef </administrator-password> <pattern>%u</pattern> </virtual-infrastructure-host> </virtual-infrastructure-hosts> Another interesting file is C: \ Program Files \ VMware \ Infrastructure \ Orchestrator \ app-server \ server \ vmo \ conf \ vmo.propirties. Here the password from the DBMS is encoded in the same way.
It remains to understand the essence of the coding method and understand whether our guess is correct or not. This is where my friend and colleague comes in, and also the CTF-team player LeetMore - Alexander jug Minozhenko. For him, such puzzles are like two fingers ... With one of his eyes, he determined that the first two bytes describe the length of the entire password, and then comes the coded representation. Sasha simply decompiled the Orchestrator Java class, which is responsible for saving the password, and parsed the encoding algorithm. The point is simple: we take the password length, then we encode every byte of the password in Hex, adding to it the position number of the byte (starting from zero). Thus, the coded value of “Password01.” Looks like:
000a506275767b74786b383a4a60be767864740329d5fcf324ec7fc98b1e0aaeefSasha wrote a decoder (on 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 is reduced to the use of our 0-day, to read the file, and the second - to decode passwords from the 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-dei are simple and dangerous. What else can be said? .. If administrators filtered access using a firewall, restricting access to administrative ports, it would be much more difficult to launch an attack. Much remains behind the scenes, because the protection of the virtual infrastructure is not the matter of one minute and not one server. I can advise everyone VMware Hardening Guide (http://www.vmware.com/files/pdf/techpaper/VMW-TWP-vSPHR-SECRTY-HRDNG-USLET-101-WEB-1.pdf). This PDF contains many places you should pay attention to. That's all, do not get sick!
Source: https://habr.com/ru/post/151704/
All Articles