Last year on the
Hex-rays plugin Contest the
Dynamic IDA Enrichment (DIE) plugin won first place, so we decided to have a
look and play around with it.
DIE extends IDA to add Dynamic Data to the static analysis. So after the
installation, we are able to perform the static analysis using a lot of
supporting information from the actual execution of the binary under assessment.
Since DIE is purely written in Python you will need at least Python 2.7 and IDA
Versions prior to 6.8 won´t work. In the current version DIE will only work on
Windows which will hopefully soon be available cross-platform.
Hello everybody,
this time I’d like to share some thoughts and results about our telco research
last year. We gathered a lot of information out of some projects we’d like to
share and discuss with you. The following sections also provide an idea of the
upcoming Telecommunication Security Workshop I will give with Kevin Redon at
Troopers
(click).
The workshop will be about Radio Network Security (covered by Kevin) and
security aspects of the Core Network (covered by myself), mainly focusing on
Voice over LTE (VoLTE). That’s also the topic of today’s post.
As part of my research on the security of paravirtualized devices, I reported a
number of vulnerabilities to the Xen security team, which were patched
today. All of them are double
fetch vulnerabilities affecting the different backend components used for
paravirtualized devices. While the severity and impact of these bugs varies
heavily and is dependent on a lot of external factors, I would recommend
patching them as soon as possible. In the rest of this blog post I’ll give a
short teaser about my research with full details coming out in the first quarter
of 2016 .
In this blogpost we will briefly explain a well known Syscall hooking technique
(a more detailed explanation can be gathered from e.g.
http://resources.infosecinstitute.com/hooking-system-service-dispatch-table-ssdt/)
used by multiple malware samples (like the laqma trojan) and right after discuss
how some memory analysis tools have trouble in the analysis and/or reporting of
these.
Before we go further, I just shortly wanted to say, that this post is not
intended to be a bashing of any tool. We have the greatest respect for all the
effort and work which has been and most probably will be done in the future.
Yesterday 7Elements released
the description
of a Remote Code Execution vulnerability in VMware vCenter. The information came
in at a good point as I’m at the moment drafting a follow-up blogpost for
this one
which will summarize some of our approaches to virtualization security. The
vCenter vulnerability is both quite critical and particularly interesting in
several ways:
Once there is proper network isolation & restriction, the vulnerability should
not be exploitable from the overall corporate network (or maybe even the
Internet — a quick inaccurate shodan search for “vcenter” returned about 1800
results and at random checks actually revealed vCenter systems). It should
also not be exploitable from ESXi hosts managed through the vCenter: ESXi
hosts need to be able to connect to the vCenter for heartbeat messages,
however “only” on ports 443 and 902 — the vulnerability exploits a service
running on TCP
ports 9875 – 9877.
It is questionable whether the exploited Java RMI functionality is really
required for the operation of VMware infrastructures. This
blogpost provides further
detail on the known type of vulnerability in Java applications. VMware had a
similar issue back in 2010,
where their workaround
to fix a vulnerability was to just disable the affected component, resulting
in the impression that it wasn’t even required in the first place. Let’s see
whether the future will bring up more vulnerabilities which could have been
prevented by implementing more thorough hardening of all components (e.g.
following the minimal machine principle). Furthermore in 2011 there was a
similar 3^(rd) party component vulnerability in vCenter which we covered
in this blogpost.
The totality of our posts on VMware security can be found
here.
For high-security environments we have been recommending for some time to use
a dedicated vCenter per hypervisor cluster (i.e. if you have two hypervisor
clusters, one for internal and one for DMZ systems, you should use two
separate vCenter systems). Vulnerabilities like these illustrate the need for
that, given that the ESXi hosts need to be able to access the vCenter on the
network level.
At the 16th of September Apple released its new version of the mobile operating
system iOS 9. As several versions before, this new iteration suffers from a
weakness that makes it possible to bypass the lockscreen without entering the
respective PIN code. Exploiting this flaw requires Siri to be enabled and
phyiscal access to the phone. A successful exploitation results in a major loss
of confidentiality as all photos and contacts in the phonebook can be accessed
by the attacker. The following steps lead to the lockscreen bypass:
this is a short write up about the Maintenance Operation Protocol (MOP), an
ancient remote management protocol from the
DECnet protocol suite. It’s old, rarely
used and in most cases not needed at all. But as we stumbled across this
protocol in some network assessments, it seems like a lot of network admins and
other users don’t know about it. Even various hardening guides we’ve seen don’t
mention MOP at all.
our home automation research, especially with KNX, is still in progress. As part
of this research we’ve implemented various tools to easy the process of
identifying and enumerating KNX devices, in both IP driven networks and on the
bus.
Lately we’ve written two Nmap NSE scripts to discover KNXnet/IP gateways. These
allow everyone to discover such gateways in local and remote networks and print
some useful information about them. One of them follows the specification to
discover gateways by sending multicast packets, where all devices on the network
must respond to. Due to the specification of KNXnet/IP this process is rather
non-invasive because only a single UDP packet is needed to discover multiple
gateways. The other script allows to identify gateways via unicast connections
by a slightly different message type, which allows discovery over e.g. the
Internet.
Today we received a few
ShareBrained Technology – PortaPack H1
to use with our HackRFs. Having done a first few minutes of scanning, I just
wanted to give you a quick overview of its features and potential…
After having had
Michael Ossmann in
for a few workshops with his
Jawbreaker and
HackRF One
we have used the HackRF on multiple occasions. No matter if
research projects
or actual customer projects, the HackRF has always been of great help. As we
mainly use it on laptops, we’ve got certain constraints concerning its
portability when wanting to do some quick mobile scanning. Although there are a
few solutions for tablets and smartphones, they haven’t been quite able to
convince all of us. So a while back we decided to keep an eye on the
PortaPack and
have been since been waiting for its release.
During the last few months information about one of North Koreas operating
systems was leaked. It is a Linux based OS that tries to simulate the look and
feel of a Mac. Some of it’s features have already been discussed on
variousblogposts and news
articles.
We thought we would take a short look at the OS. This blog post contains some of
the results.
As you can imagine, most interesting for us was to investigate features that
impact the privacy of the users. There are some
publications concerning the security
of the OS, this is an aspect that we will not cover in this post. We will stick
to a privacy issue that we identified in this post. As ERNW has a long history
of “Making the World a Safer Place”, we consider this topic an important one.
The privacy of potential users (especially from North Korea) may be impacted and
therefore we think that the results must be made available for the public. So,
here we go …