Recently I had the pleasure to attend the 24th USENIX Security Symposium and its
co-located Workshop on Offensive Technologies (WOOT) in Washington, D.C. The
workshop has received quite some attention this year, 57 submissions of which 19
have been accepted, so that the organizers decided to double its length from one
to two days.
The first day of the workshop began with an excellent keynote by Adam Langley,
in which he reflected on the current state of SSL/TLS and its vulnerabilities.
As a side remark he mentioned that to tackle the everlasting problem of such
vulnerabilities to occur, research should be performed with a much higher level
of abstraction rather than focusing on the exact details of a “certain hash
function of some specific CBC cipher”.
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.
This year’s Black Hat US saw a number of quite interesting talks in the context
of Windows or Active Directory Security. For those of you too lazy to search for
themselves 😉 and for our own Windows/AD Sec team (who couldn’t send anyone to
Vegas due to heavy project load) I’ve compiled a little list of those.
Paul Stone &
Alex Chapman: WSUSPect – Compromising the Windows
Enterprise via Windows Update
Slides here.
Whitepaper
here.
(Attention: on the BH website there’s an older this. the above link leads to the
latest one).
Although a bit on short notice it was a good meeting with interesting
discussions. I contributed with shortened versions of two talks we had delivered
in the past:
the “MLD Considered Harmful” talk that Antonios,
Jayson and I had presented at the
Troopers IPv6 Security Summit 2015.
The mentioned Internet-Draft on MLD security which
Eric Vyncke, Antonios and myself are
working on can be
found here.
We’re happy to receive any feedback on that one.
Special thanks go to
Jan Zorz
and to CZ.NIC for hosting us and providing refreshments.
Much appreciated, guys!
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 …
Some of you might use WebEx in their daily life. And some of you might use Linux
(as I and many of us do). However, this combination often results in issues with
your PC’s sound or microphone use in a WebEx session.
The problem here is that WebEx won’t run as intended with Firefox and JRE x64.
But the solution is quite easy! Use the x86-versions of each.
In this post I’ll discuss some aspects of vulnerability disclosure. I don’t want
to delve into an abstract & general discussion of vulnerability disclosure (for
those
interested here’s some discussion in
the context of Google’s Project Zero,
this is the well-known CERT/CC approach,
this a paper from WEIS 2006
laying out some variants, and
finally some statement by Bruce Schneier back in 2007). Instead
I will lay out which approach we followed in the past (and why we did so) and
which developments make us consider it necessary to re-think our way of
handling. The post is not meant to provide definitive answers; it was also
written not least to provide clarity for ourselves (“write down a problem in
order to better penetrate it”) and, maybe, to serve as a starting point for a
discussion which will help the community (and us) to find a position on some of
the inherent challenges.
When we wrote our initial blogpost regarding the
evasion of Cisco ACLs by (Ab)Using IPv6,
where we described
(known to Cisco)
cases of Access Control Lists (ACL) circumvention, we also suggested some
mitigation techniques including the blocking of some (if not all) IPv6 Extension
Headers.
Almost a month later, we got
a comment
from Matej Gregr that, even if the ACLs of certain Cisco Switches are
configured to block IPv6 Extension headers like Hop-by-Hop or Destination
Options headers, this does not actually happen/work as expected. Of course this
made us re-visit the lab in the interim ;-).