 Hello, everyone. Before we start, if you have empty seat near you, raise your hand, it's okay. Okay, let's start. Hello, everyone. My name is Alexander Nerzhenko. This talk is how to hack VMware vCenter server. In this talk, I'll discuss some ways to gain control over vCenter, which means to the whole network. I'll describe a few non-danger bugs. They were zero days when we found them. But if you can use all of them together, we can hack vCenter. So, first, about me. I'm a worker as a penetration testing at an ERP scan company. We do some business security research and testing. Also, I'm one of the organizers of DevCon Group in Russia and Zero Knights Conference. Also, I'd like to play some time CTF. And this talk was prepared with Alexei Sintsov, so I sent him to ID and support. Unfortunately, he couldn't attend DevCon. But before we start talking about VMware, I would like to talk about Pintest in general. So, the main goal of Pintest is to show weak elements in infrastructure, how to hack system, why we can hack it, and show how we can hack it. We have usually a large number of targets, different types. And unfortunately, we didn't have usually not much time. It's limited. So, we couldn't use all bug hunting methods like source code for you, because it's usually a lot of time and we need source, reverse engineering, the same reason. We could use a little bit of fuzzing if we have web or binary. Anyway, usually we can use logic, looking for logic flow, and searching bugs and public research. I would like to show that using public research like old bugs, old research, old information, and little bit analysis, we can find new bugs. So, one day we have network, big network, and all infrastructure was built on VMware, is exciting hosts and vSphere. So, all things pretty secure, all patched up with latest updates. There was no default password or anything stupid. So, we decided to try attack vCenter server, because vCenter is a solution to managed vSphere. So, if we can hack vCenter, we can hack all VM, machine, and all new infrastructure. We have vCenter version 4.1 update 1. There are a lot of services on vCenter like update manager, orchestrator, chargeback, and each services has a web server, and usually use Java technology. So, first thing we found in a public source, it's all directed to Russell, discovered by cloud doctor Sony. It's classic directed to Russell, I think, but it was fixed in our version. So, it's bad. But Alexei Sintsov didn't trust any fix or patch, and after few minutes he found another directed to Russell almost in the same place. Now there are metasploit module for this directed to Russell. So, we have... we can read any file, but load file to read. Cloudia proposes to read the file. It's a log file. And vCenter use SOAP protocol. And this log file contains SOAP request with session ID. So, if we replace our session ID with session ID from admin, we can get admin access. We also developed a tool called VASTA. It has connection and metasploit modules, and also has a local proxy for this task. But unfortunately, it also was fixed in our version. But it contains IP addresses of administrators. If it contains IP addresses of admins, we can try to use classic attack, and make an IP poisoning spoof SSL certificate, and sniff traffic. But administrators of this network were very clever, and they had a certificate to trust it, and didn't clear the knock button, so it doesn't work. So, we find another way. We just still keep the directed to Russell. And make an IP poisoning, keep traffic. But what if IP spoofing doesn't work? So, we do a little bit analysis, and found vCenter orchestrator. It's software for automatic configuration and management vCenter. It's installed by default with vCenter. It has interesting files, like DATTC, password properties. Each contains MD5 hash without a salt. So nowadays, like I know, it's not very secure. So we, of course, brute forces, and gain control. So, we get in, and this is interface of orchestrator configurations. Like you can see, there are a lot of plugins and pages. Interesting like database, LDAP, mail, SSH. All that pages, almost all have password field in them. So we think that it will be cool if we can read those password fields. And actually, there wasn't just in plain text. Yeah, just like that. Pretty easy for hackers. It's a job. So, we also find interesting files like vSXML and VMAO properties. This file looks like this. It has something like, it looks like hash, but actually it's not hash, because it has odd lengths. So, definitely not hash. So, I encoded few passwords. And as you can see, the first red byte looks like a length. Green bytes are, was always constant and they were in ASCII range. And black bytes, when you encode other passwords, or the same password, they were every time different. And also, I would like to say that now there are knowledge base article from VMware about this issue. So, I decompiled application and found this pretty simple algorithm. It just generates 60 random string. Then take password, password symbol, add position of this password, and that's all. It's, I think, not very clever decision to store password in this format. So, I write simple decoder and Ruby. So, it's another way to hack a system. But there was another way. We didn't find that bug during our penetration testing, but I think it's very interesting bug. It was discovered by guys from Digital Defense. They found out that vCentro Orchestrator has an old Stratz library, and that library has a remote code execution bug discovered by Medec. It was back in handling Ogenel expression. Ogenel expression is language for setting and getting Java properties. In the HTTP parameter, it's as Ogenel expression. So, you could just bypass this unicode hash sign and execute any Java code. So, it's this example of exploit. You just insert this code in getRequest and getRemoteCode execution. So, I think that's often during penetration testing we have like a big system, big applications, which has a lot of library and dependency. So, I think that's maybe cool to have some tool to find a fast, vulnerable library. So, I write this tool, it just gets library name, gets its version, and search in Soviet database. Now it uses standard Soviet database, but in future I would like to make my own database of the built-in. So, there are four vectors to attack the center. We find out it's like Dictatoriosland, IRP poisoning, Dictatoriosland, password decoding, code 40, and the remote code execution using Stratz bug. Also, we center infrastructure products. There are a lot of products we center, like operation management suite, capital stack, configuration management. They all have some sort of credentials for we center. So, there are maybe another vulnerabilities in the system. So, if you have one, you may think about how to make it more secure. So, for hardening, I recommend to update, of course, the batch virtual, filter administration services and configurations, such like usual user didn't have access to this. And VMware have vSphere security hardening wide. It's pretty interesting documents. It has a lot of tips, which may prevent from zero-days vulnerability, like to make permission on SSF certificate and password, something like that. So, conclusion, that batch are not always fixed bug properly. And if pentastero can get more profit if he tries to research something and few simple bugs, and we can own all infrastructure. So, I think that's all. Any questions?