Virtual Security Management – Virtualisation is amazing for running things simultaneously, on-the-go etc but security problems do come with the positives.”
First of all, in the interests of fairness, I should point out that I think virtualisation is amazing. I love the idea that my laptop can run several different, largely independent operating systems simultaneously. I love the fact that I can get an entire network and domain infrastructure onto a single physical system, which has a considerably lower power draw than the physical servers would have. And I love the fact that full system backups (snapshots) can take seconds. There are, however, a number of problems, from a security perspective, that go hand in hand with virtualisation, one of which I will discuss here.
I was part of a team of penetration testers that conducted an internal penetration test for a public sector organisation earlier this year. The organisation utilised the well-known virtualisation platform VMware vSphere to host a number of their central systems, including one of their Active Directory domain controllers.
The virtualisation host management network was segregated from the internal network using a carefully constructed series of network VLANs and subnets. In order to perform management activities, a designated dual-homed administration server was configured, with access through the “Remote Desktop” protocol permitted only for members of the local “Administrators” security group. This group consisted of the built-in “Administrator” account (which was disabled) and the Active Directory “Domain Admins” security group. This server had all of the necessary tools for administration of the vSphere environment installed and configured, and the local “Administrators” group was given administrative permissions on the vSphere cluster.
A TCP port scan of the management server identified a web interface was available on port 9090, which turned out to be an unsecured installation of the JBoss JMX Console.
It was possible to upload a specially crafted file (known as a WAR file), and gain an interactive command shell on this server. Some example code is shown below:
1) Create a simple JAVA based interactive shell:
2) Compile the shell file into a WAR file:
3) Host the WAR file on a local web server.
4) Invoke the “AddUrl()” function on the JBoss DeploymentScanner MBean to transfer the WAR file to the server (“localhost” is the target):