today we want to share a method on how to test an OCSP over HTTP validation
service with Burp and some Python magic. First a little background about OCSP
(Online Certificate Status Protocol): the main purpose of OCSP is to validate
the status of an X.509 certificate.
The OCSP responder is the key part of the system. It is run by the certificate
authority and responds with one of three possible different answers. The first
one is “good”, which indicates that the certificate is not banned, “revoked”
means that the certificate is banned, and “unknown” simply says that the status
could not be determined, because the issuing CA of the Cert is not known to the
responder.
On Monday the 28th of September 2015 a rather rare event occurred. At around 4
a.m. the moon changed its colour into a dim of red, luckily the sky was clear
enough to see something.
If you missed that event your next chance will be in about 15 years or so.
The reason for being awake this early wasn’t the moon in the first place but
what followed afterwards – my trip to the
hardwear.io Security Conference in The Hague.
During my stay in The Hague I needed to print something, so I asked for a Copy
shop and this is where they sent me:
Against the common rule to just talk about the personal favorites, I will cover
all talks in one, two or more sentences (arbitrarily decided while
writing). This also gives you a broader picture of the conference.
Jumping right in with the keynote of Day 1 by Jon Callas and my favorite quote
“Make your devices fixable”. Enough said.
Unlike the German Oktoberfest in Munich which already started in September, the
Oktoberfest in The Hague started on 2nd October.
In spite of this competing event the decision going to the last day of the
hardwear.io Conference definitely paid off.
Day 2 started with the Keynote from Harald Welte (the father of Osmocom) and his
view about Telecom Security for the last few years. His observation is that
nothing has changed so far – we still suffer from a lack of tools and
monoculture throughout the industry.
On October 1st and 2nd Flo and I were presenting at
hardwear.io in The Hague, NL. My topic was
“Living in a fool’s wireless-secured paradise”
and Flo was presenting his current research
on medical device security. It was the first talk at an international
security conference for me and I am still quite excited!
I was speaking about the (in)security of wireless consumer alarm
systems, which you can buy just in every consumer electronics store
around the corner for about $10 – $250. I analyzed the systems on
different levels, e.g. looking at UART and JTAG and the wireless domain
with Software Defined Radio (SDR). I gave an overview of my current
research and the tools I usually use for hardware hacking, especially my
favorite thing to play with: SDR.
Last week Christopher and I were the instructors of
an IPv6 workshop.
In this one we usually build a lab with the participants incl. a variety of
routed segments and native IPv6 Internet access. Once the latter part is
implemented people start poking around and surfing the Internet from their
laptops, not least to find out which sites they can actually reach from an
v6-only network (please note that
actually there are many).
I am currently at the 25th
Virus Bulletin International Conference in
Prague. The VB2015 is hosted by the Virus Bulletin portal and provides three
full days of learning opportunities and networking.
VB2015 focuses on the key themes:
Malware & botnets
Anti-malware tools & techniques
Mobile devices
Hacking & vulnerabilities
Spam & social networks
Network security
General Observations:
What I liked about VB2015 was the very friendly and always helpful staff. The
good conference location, it never felt overcrowded or to empty and the very
good catering during the conference.
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.
In the beginning of September, I had an opportunity to take part in BlackHoodie
– a reversing workshop for women organized by Marion Marschalek, senior malware
researcher at Cyphort, Inc. It took place on 5th and 6th of September at
University of Applied Sciences St. Pölten, Austria.
Besides me, 14 more young women from different countries came to attend the
workshop; the overall atmosphere was very friendly and productive. Before the
actual event all participants were getting preparatory assignments and
recommendations (not to spend our two days on learning the very basics), and
during the workshop itself we got our hands on analyzing and reversing some
actual malware samples. I personally found it very interesting how one can
detect and overcome several layers of anti-analysis protection. I left the
workshop excited and packed with some new knowledge as a basis for further
skills development – it’s just the beginning! 😉
Python has reached a defacto standard in exploit development lifecycles and most
of the proof of concept tools you’ll find out there are written in Python
(besides the metasploit framework, which is written in Ruby). Python allows to
write scripts handling with remote services, fiddling with binary data and
interacting with C libraries (or Java in case of Jython/.Net in IronPython) in a
fast and easy way. The huge standard library with it’s “battery included”
principle removes some of the dependency hell known from other
frameworks/languages. I want to share some of my python coding experiences with
you, and maybe this could give some helpful tips for your future work, to make
the world a bit safer 🙂 (PS: most of the examples are written in Python 3.x or
compatible to both Python branches).
