In
the recent post
on the IPv6 properties of the latest MS Windows versions I announced another one
providing details on the RFC 6980
related testing I had performed. So here we go.
When doing IPv6 security testing there’s mainly four toolkits which can be used:
Scapy (whose IPv6 capabilities are,
afaik, mainly maintained by Guillaume Valadon.
some tutorial on IPv6 packet crafting with scapy can
be found here).
Each of them has specific strenghts & limits, which will not be discussed here.
For the testing I performed I chose Chiron as it has the most powerful options
when it comes to IPv6 extension headers and fragmentation.
Last week we gave a talk at the very first 31c0n in
Auckland, New Zealand. The talk focused mainly on the methodology that we use to
assess security products.
More specifically, this methodology consists of 7 steps
Literature Research
Jailbreak the Target
Identify Components
Understand the Architecture
Map the Attack Surface
Prioritize
Analyze.
Details on these steps as well as general suggestions to viable alternatives for
security products can be found
here in the
slides.
The event of the events is getting closer and again, we are very optimistic to
have a lot of awesome
trainings, talks, evening events, and discussions.
But we again will also have some “features” and gimmicks for those of you who
would like to play with new, old, or just interesting technologies. As you might
remember, since some years one of these features is and again will be our own
GSM Network. As we are
improving our setup from
year to year, this time we’d like to give you the chance to actively participate
with ideas and your own services.
I’m a big fan of Chris Gates’ publications on
DevOops
and
From Low to Pwned.
The content reflects a lot of issues that we also experience in many assessments
in general and assessments
in agile environments in particular.
In addition, we were supporting several projects recently that were organized in
an agile way. In this post, I want to summarize some thoughts on how security
work can/should be integrated into agile projects. The post was also a result
from the preparation of our upcoming Troopers workshop on
Docker Security & Devops,
which of course also covers organizational aspects, but not to the degree this
post describes them.
Exactly one week ago I noticed an “urgent” tweet from Tavis Ormandy to get in
contact with the Cloudflare team.
Normally when a tweet like this appears from Tavis, something is horribly
broken. Well, today we know the background of this tweet as the
bug tracker
issue went public and it exposed quite a bug from Cloudflare.
While there is some background story how Tavis found the bug, because he wasn´t
actively looking into the Cloudflare infrastructure and it was rather discovered
by accident when odd data appeared in his fuzzing corpus. When he looked closely
he found data that was not in any mean related to the expected data from various
websites.
IP Multimedia Subsystem (IMS) offers many multimedia services to any IP-based
access network, such as LTE or DSL. In addition to VoLTE, IMS adds service
provider flexibility, better QoS and charging control to the 4th generation of
mobile networks. IMS exchanges SIP messages with its users or other IMS and
usually these communications are secured by TLS or IPSec. But if an attacker
manages to break the confidentiality and the integrity with IMS, he would find
it vulnerable to several attacks.
“Lockpicking in the IoT, …or why adding BTLE to a device sometimes isn’t smart
at all” by Ray was one of my favourite talks, as it beautifully showed many
different attack vectors as well as giving a nice guide for getting started in
this area.
It impressed me how carefree vendors and startups handled hardware and software
security in “smart” devices as it seems that their devices were more or less
easy to own. In his talk Ray pointed out physical AND implementational
weaknesses that remained even after he reported them to the vendors.
The most prominent sample he gave was when he opened a “Masterlock” by spinning
a magnet on the lock itself to open it.
This
was one of the few technical talks at 33c3 I managed to see, by that I mean
live-stream during an access control shift, by Clémentine Maurice and Moritz
Lipp.
The talk gave an overview of some already known possible information leaks by
abusing certain x86 instructions(the same concept applies to ARM too though) and
demonstrating the various ways an attacker could use them. They started off by
quickly explaining how the caches on modern CPUs are set up and how they work
and how you can exploit the timing differences in memory accesses to leak data
without actually knowing the content of the cache. This data leak can then be
used to establish a covert channel.
Have you for example thought about classes of incidents that are most likely to
affect you and formulated Incident Handling Preparation Plans for those
incidents?
In this post we’ll take a detailed look at the properties of the Windows Server
2016 IPv6 stack.
I perform(ed) this exercise for several reasons:
Server 2016 is the latest OS released by Microsoft so this might give an
indication as for their plans & strategy when it comes to supporting certain
specifications.
(here you may keep in mind that the ~50 IETF meetings having passed since the
publication of RFC 2460 provided ample opportunity for creative minds to come
up with ever new ideas for “enhancing” IPv6, without too much real-life
feedback/reality checks from enterprise space though, as simply not many of
such organizations have deployed it at scale… or are incentivized to send
their employees to week-long meetings in expensive hotels on other continents
twice a year…).
as I laid out
in this post
the configuration approach an organization takes for their servers might
depend on the support of specific features.
obviously for both IPv6 planning and operations it might be helpful to
understand the respective behavior of individual operating systems (which is
why we researched stuff like
this
or
this
in the past).
many years ago Microsoft published white papers with details as for the TCP/IP
parameters of their OSs (incl. stuff like registry parameters to control it
etc.) but I’m not aware of such a document for Server 2016 or Windows 10. I
hence hope this post can somewhat contribute to public knowledge of the
intricacies of their latest IPv6 stack.
