Taking the chance from
a discussion
on the
IPv6 hacker’s mailing list
and the
freshly proposed draft RFC
regarding
the deprecation of the generation of IPv6 Atomic Fragments,
I decided to test very quickly what is the current status related with the
latest and some of the most poplar Operating Systems (OS) status (whether they
send Atomic Fragments in response to Packet Too Big messages, or not). The
motivation behind this was to check which one of them is potentially vulnerable
to the DoS attack using the technique described in the above proposed RFC and
taking it for granted that Atomic Fragments are blocked in the real world (but
more about this, in another blogpost in the near future).
In the light of the recent release of version 5.0 of Microsoft’s Enhanced
Mitigation Experience Toolkit (EMET) on July 31, it seems to be more than
appropriate to talk a bit about the new features and some general things to take
into account when using EMET (for the new certificate pinning feature of EMET
4.0, see
Friedwart’s comment).
For all of you who don’t know EMET, in short, it’s a free mitigation tool for
Windows developed by Microsoft, helping the user by preventing vulnerabilities
in software from being successfully exploited. The tool works by protecting
applications via a number of security mitigation technologies, vastly extending
Windows operating system mitigation capabilities as Data Execution Prevention
(DEP) and Address Space Layout Randomization (ASLR).
We’re currently involved in a number of IPv6 activities in different
organizations and one of the questions we are still facing – even in cases where
there’s already a (in most cases networking team driven/originated) “project”
(incl. budget, project sponsor, milestones etc.) – is along the lines of “How to
sell IPv6 to our management?”.
In the following I will shortly lay out the line of reasoning and the
terminology we usually employ for the task. Furthermore I’ve anonymized a
presentation which we recently prepared as “input” for the network team of an
enterprise organization;
it can be found here. In
case you want to get this as a PPT (for recyling purposes) pls send me a direct
email (in exchange, we might ask you for a small donation of your will to the
Troopers charity project…
).
Some weeks ago, at RIPE 68 in Warsaw,
Sander Steffann gave a
presentation about revising RIPE 554
which, in his own words, “is a template guideline for procurement of stuff that
should do IPv6” (here’s the
steganography transcript of the IPv6 working group session). Some of you will
probably know RIPE 554 as a quite
helpful document for identifying reasonable real-world requirements for IPv6
capable network devices (in particular at times when vendors quite willingly put
an “IPv6 ready” sticker on all their gear…).
regularly we get requests from customers where the idea of using Skype as a VoIP
solution in their corporate environment is brought up. There are a lot of
eavesdropping and more conceptual concerns (e.g. refer to
this
or
this,
and of course the legendary
“Silver Needle in the Skype”
paper from Black Hat EU 2006), but those won’t be covered in this post (just to
say this: at ERNW the use of Skype is strictly prohibited at by policy).
Last October I had a quick look at pfSense 2.1
regarding the IPv6 support that it offers. It was the first stable support of
pfSense that offered the capability for IPv6 network connectivity (a few
comments about it can be found
here). However,
I knew that m0n0wall supported IPv6 quite a long time
ago and that their developers had incorporated the support of IPv6 features
which are not available in pfSense yet, so today I decided to have a look at it
too.
I recently stumbled over a
document from
Microsoft which lists all services/applications that support IPv6. Most of the
content wasn’t new for me, but one item caught my attention. Windows Update. I
haven’t heard before that Windows Update can be done over IPv6 (but this could
just be me not looking hard enough ;)), so I was eager to test it out seeing if
this is really the case. I was also curious why Microsoft referenced this
document
in the respective column.
This is the third – and hence presumably last – part of the series of posts on
IPv6 address planning (first part can be found
here,
second one
here).
It’s split into three main pieces. In the beginning I will lay out some general
objectives to be considered when designing an address plan. Then I’ll have a
look at potential hierarchy levels and finally I’ll discuss some real-life
samples we’ve seen recently.
TROOPERS14 has come to an end, and it’s finally time to let you have a go at the
Badge’s source code. As promised, it was slightly modified and extended, to show
you the full potential of your new gadget. I’ve added some nice payloads from
Nikhil Mittal and a few own ones. Above that, for those who took their parts for
soldering home, I’ve also added a few quick instructions on how to do the
soldering.
Greetings from the Print Media Academy in Heidelberg. Just in time for
TROOPERS14, I’ve got the great honor to present this years badge!
Being a TROOPER is tough: You need to know loads of information, learn even more
and be able to work fast.
This year we decided to increase your efficiency and speed when collecting data
from computer systems and, let’s say, hacking them! Your newest gadget is based
on a plain
Arduino Leonardo,
modded with one of our famous shields. After adding a few LEDs and buttons, it
will power up to full functionality.
