First day at hack.lu. Three of us kicked the conference
off with the ARM IoT Firmware Emulation workshop by
Saumil. The goal of this workshop was not
so much to write exploits or to pwn boxes but to learn how to build a beneficial
research environment by emulating the hardware of a Linux based IoT device to
run its firmware in order to run analysis and tests.
First step is to obtain the firmware. This could be done by dumping it directly
from the device or by downloading firmware images from the vendor. In order to
dump the firmware from the device one has to obtain access to the underlying
system which is usually done by finding the serial console on the hardware since
this one often exposes an unauthenticated root shell. I think there is enough
documentation online on how to identify and connect to a serial console so I
won’t cover the details here. It’s also covered in Saumil’s
slides
in detail. Having the bootup logs from this console will be helpful later
though. While talking about baud rates for the serial console Saumil made a
great pun I don’t want to withhold: “Most common is baud rate 115200. If you
find a console with baud rate 9600 you are in fact talking to an acoustic
coupler. That’s not an IoT device, it rather belongs to a museum.”
As Kai and I will be holding a
TROOPERS workshop on automation with ansible,
we needed a setup for the attendees to use ansible
against virtual machines we set up with the necessary environment. The idea was,
that every attendee has their own VMs to run ansible against, ideally including
one to run ansible from, as we want to avoid setup or version incompatibilities
if they set up their own ansible environment on their laptop. Also they should
only be able to talk to their own machines, thus avoiding conflicts because of
accidental usage of wrong IPs or host names but also simplify the setup for the
users.
this week I gave a presentation together with
Florian Barth from
Stocard on Docker, DevOps/Microservices, and Security
— a topic and collaboration that I will definitely cover in even more detail in
the future!
In my
last blog post,
I gave an overview about recent vulnerabilities discovered in the x86 emulation
layer of Xen. While both of the discussed vulnerabilities only allow for guest
privilege escalation, the complexity of the involved code seemed to indicate
that even more interesting bugs could be discovered. So I spent some time
searching for memory corruption issues and discovered a very interesting bug
that resulted in XSA 123 . This
post gives an overview about the root cause of the bug and a short description
of exploitation challenges. A follow-up post will describe possible exploitation
strategies in more detail.
Developing a secure and feature rich hypervisor is no easy task. Recently, the
open source Xen hypervisor was affected by two interesting vulnerabilities
involving its x86 emulation code:
XSA 110 and
XSA 105. Both bugs show that the
attack surface of hypervisors is often larger than expected. XSA 105 was
originally reported)
by Andrei Lutas from BitDefender. The patch adds missing privilege checks to the
emulation routines of several critical system instructions including LGDT and
LIDT. The vulnerable code can be reached from unprivileged user code running
inside hardware virtual machine (HVM) guests and can be used to escalate guest
privileges. XSA 110 was reported by Jan Beulich from SUSE and concerns
insufficient checks when emulating long jumps, calls or returns.
Recently we started playing around with Cisco’s virtual router, the CSR 1000V,
while doing some protocol analysis. We found Cisco offering an BIN file for
download (alternatively there is an ISO file which contains a GRUB boot loader
and the BIN file, or an OVA file which contains a virtual machine description
and the ISO file) and file(1) identifies it as DOS executable:
$ file csr1000v-universalk9.03.12.00.S.154-2.S-std.SPA.bin
csr1000v-universalk9.03.12.00.S.154-2.S-std.SPA.bin: DOS executable (COM)
We didn’t manage to get the file running, neither in a (Free-)DOS environment,
nor in a wine virtual DOS environment, except using the boot loader from the ISO
file. So we became curious as for the structure and ingredients of the file.
In the course of our virtualization research, we came across a certain technical
issue we couldn’t find an easy solution on knowledge bases and the like.
However, as we found the question several times on the web, the following post
gives just a short hint on a technical detail.
If you want to connect two virtual machines in VMware Fusion using a serial port
(e.g. for debugging purposes), Fusion doesn’t provide you an GUI option to
configure that. However, if you just add the following config to the debugger
system’s VMX file:
During a recent research project we performed an in-depth security assessment of
Microsoft’s virtualization technologies, including Hyper-V and Azure. While we
already had experience in discovering security vulnerabilities in other virtual
environments (e.g.
here and
here), this was
our first research project on the Microsoft virtualization stack and we took
care to use a
structured evaluation strategy
to cover all potential attack vectors.
Part of our research concentrated on the Hyper-V hypervisor itself and we
discovered a critical vulnerability which can be exploited by an unprivileged
virtual machine to crash the hypervisor and potentially compromise other virtual
machines on the same physical host. This bug was recently patched, see
MS13-092 and
our
corresponding post.
First of all, I hope you all had a good start to 2014. Having some time off
“between the years” (which is a German saying for the time between Christmas and
NYE), I caught up on several virtualization security topics.
While virtualization is widely accepted as a sufficiently secure technology in
many areas of IT operations (also for sensitive applications or exposed systems,
like
DMZs)
by 2014, there are several recent vulnerabilities and incidents that are worth
mentioning.
In the course of a current virtualization research project, I was reviewing a
lot of documentation on hypervisor security. While “hypervisor security” is a
very wide field, hypervisor breakouts are usually one of the most (intensely)
discussed topics. I don’t want to go down the road of rating the risk of
hypervisor breakouts and giving appropriate recommendations (even though we do
this on a regular base which, surprisingly often, leads to almost religious
debates. I know I say this way too often:I’ll cover this topic in a future post
;)), but share a few observations of analyzing well-known examples of
vulnerabilities that led to guest-to-host-escape scenarios. The following table
provides an overview of the vulnerabilities in question:
