Virtual machine weaknesses now.
Under most circumstances,
it’s safe to assume that the virtual machines
are isolated from each other,
that the host is separated from the guest, and the guest is separated from the host.
But the configuration settings and vulnerabilities
within the hypervisor and the VM Tools
and other locations can weaken that isolation.
Let us talk through some of the potential weaknesses of using virtual machines,
and virtual machines and sandboxes are kind of synonyms for each other.
So when we say sandbox, when we say virtual machine, they are very similar devices.
Virtual machines and sandboxes are based on the same principles.
So if we have a host and a guest, if the host is compromised
then it’s possible that the guest could be compromised.
For example, a simple remote access tool running on the host
would only need to take a screenshot
to watch the activity of the guest virtual machine,
or run a key logger which would effectively break
the isolation between them completely.
Maintaining the security of the host operating system
is of paramount importance.
Highlighting the need for a separate secure laptop
for high stakes situations
where you’re considering using virtualization
as your isolation and compartmentalization security control.
Also, vice versa to what we’ve just discussed,
a guest VM could compromise the host operating system,
or other VMs due to vulnerabilities and configuration settings.
The hypervisor sandbox or the VM Tools installed
can have security vulnerabilities that could compromise this isolation.
One such example of a previous hypervisor vulnerability is Venom,
which you can see a diagram here in front of you.
For vulnerable hypervisors,
it allows an attacker to escape from the confines
of a vulnerable virtual machine guest,
which we call a virtual machine escape, and potentially obtain
code execution access to the host.
This has been patched now by all the major vendors,
but obviously if you’re using a old unpatched hypervisor,
you may even still be vulnerable to this.
Here you can see previous virtual machine hypervisor vulnerabilities
that have occurred over the years,
2007 through to 2014, 2015,
I’m sure there’ll be more to come.
So that’s vulnerabilities within the hypervisor.
Here’s an example of the virtual machine tools having vulnerabilities.
In VMware, this allowed a standard user to escalate privileges
to an admin or root user within the confines of the guest,
no virtual machine escape in this case,
but it’s an example of VMware Tool vulnerabilities.
As you can see, vulnerabilities can and do exist with virtual machines.
Virtual machines can leak information, so for example,
traces of your virtual machine’s session could be left
on the local hard drive of the host,
even if it’s a live operating system.
For example, host operating systems usually use
virtual memory called swapping or paging
which copies parts of the RAM to the hard drive.
This could contain information about the guest’s session,
and it could be left on the host’s hard drive.
So it’s potential to get leakage from your virtual machine.
Let's think about active attacks now and malware.
VMs are used by security researches to deliberately isolate malware,
so that the malware can be forensically examined and reversed engineered
in order to understand how the malware works.
Because of this, advanced malware writers
have designed counter measures that can detect
when their malware is running on a virtual system,
in an attempt to prevent that very same reverse engineering.
The more sophisticated malware examines the memory,
the file system, the registry,
running processes for virtual machine environment artifacts,
and looks for VM specific virtual hardware and processor instructions.
It’s relatively trivial to detect, if you’re running in a virtual machine.
In some cases, detection of a virtual environment
causes the malware to shut down its malicious functionality,
so that it cannot be properly analyzed in the virtual environment.
This is a defense mechanism for the malware.
This is great for us,
when using VMs for isolation, and as a security control,
as the malware effectively disables itself,
and sometimes even deletes itself to help prevent forensic examination.
It uses this form of defense because it is better for the malware
to not be reversed engineered
because it can give it a longer life.
So it’s good that malware disables itself,
but it’s not all good news.
Some malware uses the virtual machine detection
to then attempt to exploit security holes
in the VM software,
like the Venom example that we’ve just seen.
Attempting to perform virtual machine escapes,
this wouldn't be good, but fortunately,
hypervisor VM tool vulnerabilities, and other vulnerabilities,
haven't been too prevalent,
so mostly the malware will either keep running and not be able to escape
the isolation, or simply disable itself.
Shared networks are also an attack vector.
If the guests and hosts share the same network,
if any of those machines are compromised,
the other machines could be targets for attack.
Not technically escaping the virtual machine,
but just simply by performing network attacks on the other machines
that are part of the same network.
In most instances, if you are using VirtualBox on your laptop,
the host and guest will share the same network. So for example,
maybe you have a Debian host and a Windows guest,
which have a bridged network adapter.
Windows, the guest is compromised, the Windows VM then attempts an SSL stripping attack
on all the other machines on the network to steal the passwords.
Even though you have isolation between the Windows guest and the Debian host,
and the isolation at the operating system level isn't compromised,
but the network level,
there is an interface and that interface can be used as an attack vector.
VM hosts and guests obviously shares CPUs.
This means it’s theoretically possible to perform what is called covert timing channel attacks.
This is the passing of information
in which one process signals information to another process
by modulating its own use of system resources.
For example, central processing unit, time, in such a way
that this manipulation affects
the real response time observed by the second process.
This means guest and host can communicate
via timing variations based on prearranged methods.
A timing channel is one example of a covert channel.
Again, on CPUs, because the CPU is shared,
it may be possible to perform side channel attacks, too.
For example, extract description keys from either the guest
or the host.
There’s a paper here on this very same thing,
and in a lab the researchers were able to do that
under the right conditions using ElGamal.
Features like shared folders, clipboard access
and drag and drop functionality,
all reduce the isolation and allow attack vectors.
Anything you allow the guest to access,
for convenience, is a trade off with security.
The guest can then possibly view your files
and copy and paste the contents of the clipboard.
If within your VM you have configured them to be accessible,
hardware and hardware emulation could be used to breach the isolation.
So I’m talking about hardware like the microphone, the webcam,
3D acceleration,
serial port, floppy drive, CD drive, USB port and so on.
These could be manipulated and used as an attack vector.
There’s also a possibility that a bug could be found
in the underlining technology that is used by a hypervisor,
such as the Intel VTD.
And I’m aware of one such example, which is this.
This is a complex attack that was able to bypass Intel's
VTD imposed protection.
Intel VTD, if you’re not aware, enables hardware support
for isolation and virtualization,
and a vulnerability was found by these two researches here at Invisible Labs.
So there was no vulnerabilities in the hypervisors themselves,
but in the underlining technology,
and when there is problems in the underlying hardware technology,
you can't just patch it.
And then when we start to think about who needs serious security,
privacy and anonymity.
Running a number of virtual machines requires a fast machine
with good CPU and memory.
Many of the people who need security, privacy and anonymity,
are unfortunately not rich.
They live in places where there isn't a lot of money,
and they can't afford a machine to support virtual machines.
This is a disadvantage, a major disadvantage
of virtual machines for people with limited funds.
Virtual machines shouldn't be relied upon as your sole means of protection.
It is one layer of a defense in-depth approach.
All of the security controls detailed throughout the course should be applied as well,
where appropriate, based on your threat model, your risk,
your adversaries, and the consequences,
including hardening the virtual machine, which we will cover next.
So virtual machines and sandboxes are not perfect,
but when configured correctly,
they are a very, very effective security control,
that I highly recommend that you use.