Virtual machine weaknesses now. 2
Under most circumstances, 3
it’s safe to assume that the virtual machines 4
are isolated from each other, 5
that the host is separated from the guest, and the guest is separated from the host. 6
But the configuration settings and vulnerabilities 7
within the hypervisor and the VM Tools 8
and other locations can weaken that isolation. 9
Let us talk through some of the potential weaknesses of using virtual machines, 10
and virtual machines and sandboxes are kind of synonyms for each other. 11
So when we say sandbox, when we say virtual machine, they are very similar devices. 12
Virtual machines and sandboxes are based on the same principles. 13
So if we have a host and a guest, if the host is compromised 14
then it’s possible that the guest could be compromised. 15
For example, a simple remote access tool running on the host 16
would only need to take a screenshot 17
to watch the activity of the guest virtual machine, 18
or run a key logger which would effectively break 19
the isolation between them completely. 20
Maintaining the security of the host operating system 21
is of paramount importance. 22
Highlighting the need for a separate secure laptop 23
for high stakes situations 24
where you’re considering using virtualization 25
as your isolation and compartmentalization security control. 26
Also, vice versa to what we’ve just discussed, 27
a guest VM could compromise the host operating system, 28
or other VMs due to vulnerabilities and configuration settings. 29
The hypervisor sandbox or the VM Tools installed 30
can have security vulnerabilities that could compromise this isolation. 31
One such example of a previous hypervisor vulnerability is Venom, 32
which you can see a diagram here in front of you. 33
For vulnerable hypervisors, 34
it allows an attacker to escape from the confines 35
of a vulnerable virtual machine guest, 36
which we call a virtual machine escape, and potentially obtain 37
code execution access to the host. 38
This has been patched now by all the major vendors, 39
but obviously if you’re using a old unpatched hypervisor, 40
you may even still be vulnerable to this. 41
Here you can see previous virtual machine hypervisor vulnerabilities 42
that have occurred over the years, 43
2007 through to 2014, 2015, 44
I’m sure there’ll be more to come. 45
So that’s vulnerabilities within the hypervisor. 46
Here’s an example of the virtual machine tools having vulnerabilities. 47
In VMware, this allowed a standard user to escalate privileges 48
to an admin or root user within the confines of the guest, 49
no virtual machine escape in this case, 50
but it’s an example of VMware Tool vulnerabilities. 51
As you can see, vulnerabilities can and do exist with virtual machines. 52
Virtual machines can leak information, so for example, 53
traces of your virtual machine’s session could be left 54
on the local hard drive of the host, 55
even if it’s a live operating system. 56
For example, host operating systems usually use 57
virtual memory called swapping or paging 58
which copies parts of the RAM to the hard drive. 59
This could contain information about the guest’s session, 60
and it could be left on the host’s hard drive. 61
So it’s potential to get leakage from your virtual machine. 62
Let's think about active attacks now and malware. 63
VMs are used by security researches to deliberately isolate malware, 64
so that the malware can be forensically examined and reversed engineered 65
in order to understand how the malware works. 66
Because of this, advanced malware writers 67
have designed counter measures that can detect 68
when their malware is running on a virtual system, 69
in an attempt to prevent that very same reverse engineering. 70
The more sophisticated malware examines the memory, 71
the file system, the registry, 72
running processes for virtual machine environment artifacts, 73
and looks for VM specific virtual hardware and processor instructions. 74
It’s relatively trivial to detect, if you’re running in a virtual machine. 75
In some cases, detection of a virtual environment 76
causes the malware to shut down its malicious functionality, 77
so that it cannot be properly analyzed in the virtual environment. 78
This is a defense mechanism for the malware. 79
This is great for us, 80
when using VMs for isolation, and as a security control, 81
as the malware effectively disables itself, 82
and sometimes even deletes itself to help prevent forensic examination. 83
It uses this form of defense because it is better for the malware 84
to not be reversed engineered 85
because it can give it a longer life. 86
So it’s good that malware disables itself, 87
but it’s not all good news. 88
Some malware uses the virtual machine detection 89
to then attempt to exploit security holes 90
in the VM software, 91
like the Venom example that we’ve just seen. 92
Attempting to perform virtual machine escapes, 93
this wouldn't be good, but fortunately, 94
hypervisor VM tool vulnerabilities, and other vulnerabilities, 95
haven't been too prevalent, 96
so mostly the malware will either keep running and not be able to escape 97
the isolation, or simply disable itself. 98
Shared networks are also an attack vector. 99
If the guests and hosts share the same network, 100
if any of those machines are compromised, 101
the other machines could be targets for attack. 102
Not technically escaping the virtual machine, 103
but just simply by performing network attacks on the other machines 104
that are part of the same network. 105
In most instances, if you are using VirtualBox on your laptop, 106
the host and guest will share the same network. So for example, 107
maybe you have a Debian host and a Windows guest, 108
which have a bridged network adapter. 109
Windows, the guest is compromised, the Windows VM then attempts an SSL stripping attack 110
on all the other machines on the network to steal the passwords. 111
Even though you have isolation between the Windows guest and the Debian host, 112
and the isolation at the operating system level isn't compromised, 113
but the network level, 114
there is an interface and that interface can be used as an attack vector. 115
VM hosts and guests obviously shares CPUs. 116
This means it’s theoretically possible to perform what is called covert timing channel attacks. 117
This is the passing of information 118
in which one process signals information to another process 119
by modulating its own use of system resources. 120
For example, central processing unit, time, in such a way 121
that this manipulation affects 122
the real response time observed by the second process. 123
This means guest and host can communicate 124
via timing variations based on prearranged methods. 125
A timing channel is one example of a covert channel. 126
Again, on CPUs, because the CPU is shared, 127
it may be possible to perform side channel attacks, too. 128
For example, extract description keys from either the guest 129
or the host. 130
There’s a paper here on this very same thing, 131
and in a lab the researchers were able to do that 132
under the right conditions using ElGamal. 133
Features like shared folders, clipboard access 134
and drag and drop functionality, 135
all reduce the isolation and allow attack vectors. 136
Anything you allow the guest to access, 137
for convenience, is a trade off with security. 138
The guest can then possibly view your files 139
and copy and paste the contents of the clipboard. 140
If within your VM you have configured them to be accessible, 141
hardware and hardware emulation could be used to breach the isolation. 142
So I’m talking about hardware like the microphone, the webcam, 143
3D acceleration, 144
serial port, floppy drive, CD drive, USB port and so on. 145
These could be manipulated and used as an attack vector. 146
There’s also a possibility that a bug could be found 147
in the underlining technology that is used by a hypervisor, 148
such as the Intel VTD. 149
And I’m aware of one such example, which is this. 150
This is a complex attack that was able to bypass Intel's 151
VTD imposed protection. 152
Intel VTD, if you’re not aware, enables hardware support 153
for isolation and virtualization, 154
and a vulnerability was found by these two researches here at Invisible Labs. 155
So there was no vulnerabilities in the hypervisors themselves, 156
but in the underlining technology, 157
and when there is problems in the underlying hardware technology, 158
you can't just patch it. 159
And then when we start to think about who needs serious security, 160
privacy and anonymity. 161
Running a number of virtual machines requires a fast machine 162
with good CPU and memory. 163
Many of the people who need security, privacy and anonymity, 164
are unfortunately not rich. 165
They live in places where there isn't a lot of money, 166
and they can't afford a machine to support virtual machines. 167
This is a disadvantage, a major disadvantage 168
of virtual machines for people with limited funds. 169
Virtual machines shouldn't be relied upon as your sole means of protection. 170
It is one layer of a defense in-depth approach. 171
All of the security controls detailed throughout the course should be applied as well, 172
where appropriate, based on your threat model, your risk, 173
your adversaries, and the consequences, 174
including hardening the virtual machine, which we will cover next. 175
So virtual machines and sandboxes are not perfect, 176
but when configured correctly, 177
they are a very, very effective security control, 178
that I highly recommend that you use.