As we all know an IPv6 enabled host can have multiple addresses. In order to
select a source address for a to-be established outbound connection, operating
systems implement a source address selection mechanism that evaluates multiple
source address candidates and selects the (potentially) best candidate. Criteria
for this selection are defined in
RFC6724 (which obsoletes RFC 3484).
To find out if there are differences as for the way various OSs implement this
mechanism we performed a little study whose results can be found in
this whitepaper.
Those differences might be particularly relevant for data center environments or
enterprise networks with a variety of heterogeneous client operating systems. If
interested in IPv6 in enterprise networks
this training
that I’ll give in some weeks might be worth attending for some of you, too.
Last week, we decided to take a look onto the EMET library provided by
Microsoft. This library is intended to introduce several security features to
applications which are not explicitly compiled to use them.
It also adds an additional layer to protect against typical exploiting
techniques by filtering library calls, preventing usage of dangerous
functions/components and inserting mitigation technologies.
As EMET is already a target for many researchers, we currently only started to
get an overview of it’s structure and how the different components are
interacting with each other. Today we would like to share some of our results
with you.
During penetration tests, we often find interesting files on web servers. Almost
as often, those files enable us to carry out further attacks with much higher
impact. Inspired by Chris Gate’s great series
From Low to Pwned,
we decided to share the following small piece.
The web server under test did not deliver directory listings. However, the
directory contained a .DS_Store file
(one of macOS’ many — lets say special — traits). While .DS_Store files store
various information, a simple cat shows one relevant characteristic:
This is the second part of a series with considerations on DMZ networks in 2016
(part 1 can be found
here).
Beforehand I had planned to cover classification & segmentation approaches in
this one, but after my little rant on how “the business” might approach & think
about reverse proxies in the first part, I felt tempted to elaborate a bit
further on this particular topic. I kindly ask for your patience 😉 and will
digress a bit for the moment.
I’m currently involved in a “DMZ Redesign” effort in a sufficiently large
enterprise (800+ hosts in “the DMZ”) and I thought this might be an opportunity
to reflect on some aspects of “DMZ networks” in a series of posts.
Some of you already know that, at ERNW, we have a
tendency to discuss stuff starting with some formal definitions and a bit of
abstract (overview) approach. It’s not different this time ;-), so let’s first
find out what the term “DMZ” means, what such a thing is considered to be and to
deliver, and what the actual state of affairs might be in 2016. Different people
within an organization might have quite different understandings in this
space.
Further it’s entirely possible that the DMZ networks are not operated by
a company themselves but by an outsourcing partner which then means that
“placing a system in the DMZ” becomes “ordering a DMZ [network] port” by means
of some web-based procedure or ticket system, which in turn might have a number
of interesting implications (we’ll have a dedicated post on those).
Today we started publishing several of our hardening documents to a
dedicated GitHub repository — and we’re
quite excited about it! It took a while to develop a suitable markdown template
to support all the requirements you have when you write a hardening guide, but
we’re online now!
At the moment, only a few hardening guides are online, but that
should continuously increase in the future.
After a couple of years in pentesting Telco Networks, I’d like to give you some
insight into our pentesting methodology and setup we are using for testing
“Mobile and Telecommunication Devices”. I am not talking about pentesting
professional providers’ equipment (as in previous blogposts), it is about
pentesting of devices that have a modem in place like a lot of IoT devices (you
know about the fridge having a GSM Modem, right?) do.
We couldn’t be more proud to welcome such a predestined #1 hardware hacking
victim, than VICTor is!
Before Brian and I gave a lecture on hardware hacking last week at
DHBW Mosbach, we felt, that we needed a custom
victim which is fully documented and provides a good “hackability” to the
students.
Surely we could also have used some cheap $wifi_ap, but here’s the thing: Would
you really want to use a device which you don’t really know? Mostly, there’s a
massive lack of documentation regarding the SoCs used…not to mention the
unavailability of schematics and layouts.
As we wanted to teach students the basics of hardware hacking effectively, we
decided to create something by ourselves.
Today I want to give a little review about the latest app released by
SektionEins called “System and Security Info” due to its recent media
appearance. So first of all the app can be obtained via the Apple App store for
0,99€ at the time this article was written. This article will try to answer two
basic questions: for whom (or “which groups of people”) is this app helpful, and
which security features does this app actually has. The design of the app is
straight forward and pretty minimalistic with a clean and modern design. The
first page of the Application called “Overview” provides nothing more than the
current CPU usage of the device, with detailed subdivision in User, Idle, Total
and Load. The next section provides an overview about the used RAM divided into
Wire, Active RAM usage, Inactive RAM usage, “other”, free and the total amount
of the device’s ram. The next option shows the used and unused part of the
devices available storage, with “used”, “free” and total amount of space. While
these features can be handled with several other (free and open source)
applications I won’t write a comment wether it these components make sense.
Right now, I’m in Buenos Aires for IETF95 where, amongst others, an
Internet-Draft authored by
Eric Vyncke,
Antonios Atlasis and myself will be presented
(and hopefully discussed) in two working groups. In the following I want to
quickly lay out why we think this is an important contribution.
As some of you may remember about two years ago we started an internal research
project on the IPv6 “helper procotol” Multicast Listener Discovery (MLD) and
its security properties. One outcome of this research project was
Jayson Salazar‘s excellent thesis on the topic
(the full document
can be found here),
another outcome were the related talks we gave at DeepSec 2014 and at
Troopers15.