Only a few days left until Troopers! I’d like to use this chance to publish the
final agenda of
TelcoSecDay 2016.
We will start around 8:30am and will finish at about 6:15pm. After this, we will
have a shared dinner in the historic center of Heidelberg. The exact location
will be announced during the TSD.
Same as last year, we will
have a GSM based telephony network running at Troopers 2016. The network will be
a closed network, which means it only can be used with Troopers SIM cards and
between Troopers attendees only. You can use the network for
doing Voice Calls
send Short Messages (SMS)
have Internet Access
submit Challenge Tokens (see below)
In contrast to last year, you will need a Troopers SIM card to attend the
network with your cellphone. The SIM cards will be handed out at the
registration desk; if you have questions you always can contact me or Kevin
Redon (thanks again for assisting us).
White-box cryptography is a relatively new field that aims at enabling safely
cryptographic operations in hostile situations.
A typical example is its use in digital-right management (DRM) schemes, but
nowadays you also find white-box implementations in mobile applications such as
Host Card Emulation (HCE) and the protection of credentials to the cloud.
In all these use-cases the software implementation uses the secret key of a
third-party which should remain secret from the owner of the device which is
running this executable.
today we want to examine the behavior of Cisco devices when they receive spoofed
IPv6 Neighbor Advertisement packets from an untrusted system pretending to be
the default router for the local segment. We start with a quick refresher how
Cisco devices behave in the legacy (IPv4) world when they receive a spoofed
broadcast ARP packet containing the IP address of the device but with a
different MAC address, followed by a discussion of the corresponding behavior in
the IPv6 world.
First of all: This is not an in-depth Kerberos how-to, nor is this tutorial
about the different aspects of web application testing. This tutorial is just to
give support in testing Kerberos authenticated web applications. The goal is to
hand over the right tools and steps to be able to perform the configuration and
be able to test the application.
When to use it?
When there is a 401 server response with the header “WWW-Authenticate:
Negotiate”. This can either mean Kerberos or NTLM authentication is needed. It
is possible to distinguish them by looking at valid authenticated client
traffic. As a simple reminder: The NTLM Authorization header will always start
with the value “TlRM…”, the Kerberos Authorization header will always start with
“YII…”. For further information this
link is
recommend.
In this tutorial the term “Kerberos authentication” will be used. There are
other terms sometimes used like SPNEGO, SSO or integrated authentication.
I had the pleasure to sit in Mark Townsley
“Addressing Networking Challenges With Latest Innovations in IPv6”
session at Cisco Live yesterday and – somewhat inevitably – there was a mention
of Facebook having implemented an IPv6-only approach in their data centers
(here’s a talk from Paul Saab/FB
laying out details). So, with the
“IPv6 Panel” looming,
I started reflecting on “Why don’t we see this in our customer space?”. This
post quickly summarizes some observations and thoughts.
Enno and I spent the first day on Cisco Live Europe in Berlin today attending
the “Advanced Practical Knowledge for Enterprise Deploying IPv6” technical
breakout held by Tim Martin and
Jim Bailey.
It was a good breakout session, and thanks again Tim for the honorable mention
of our work in your slides! We really appreciate it. Like
last year,
we were curious how the Wifi network was setup this year as I face a
corresponding task for Troopers in March,
with some
major changes
in comparison to the last years. The Wifi infastructure in Berlin looked very
similar to the one from last year in Milan, we had the “standard” Cisco Live
SSID as well as an IPv6-only (with NAT64 as translation mechanism) SSID. The
standard SSID looked identical to last year with the exception that now the
RA Throttling
feature on the WLC was active from the beginning! Neither the M nor the O flag
are set which means that my client has to use the legacy protocol to resolve
AAAA records. As I am running Windows, it does not support
RA option 25 but the option wasn’t
included in the RAs anyway. The preference was configured to the default
“medium”. One thing I noticed, but haven’t had a chance to ask
Andrew Yourtchenko, was that for the legacy
(IPv4) connection they use HSRPv2 as an FHRP protocol (indicated by the MAC
address
00:00:0c:9f:f0:01
I received from the gateway) but for IPv6 I received Router Advertisements from
two different MAC addresses (which both belong to Cisco, so I don’t think anyone
sent spoofed RAs). I am curious about the reasoning for this approach 🙂
What i also encountered was that the Peer-to-Peer Blocking feature was
apparently not enabled on the SSID as I was able to enumerate approx. 1600
active clients at the time. No worries, I haven’t done anything else, just was
curious whether the feature was activated or not…
While running some SS7 pentests last year, I developed a small tool automating
some of the well-known SS7 attack cases. Today I’m releasing the first version
of ss7MAPer, a SS7MAP (pen-)testing
toolkit.
The toolkit is build upon the
Osmocom SS7 stack and implements
some basic MAP messages. At its current state tests against the
HLR are ready for use,
in future versions tests against
VLR,
MSC and
SMSC will follow.
The source code of the tool is published on
github, feel free to use and extend.
I’ll be on the
“IPv6 Panel”
at Cisco Live next week and somewhat in
preparation I started thinking about what we currently see when it comes to IPv6
deployment in our customer space. We notably observe a large gap between
“textbook planning & transition strategies” and what’s happening in real-life in
those organizations. I hence decided to write down some of these observations in
a quick series of posts to be published in the upcoming days and, maybe more
importantly, to reflect on the reasoning of this apparent mismatch between
theory and practice. I dare to add a dose of devil’s advocate here+there…
For today let’s start with some comments on IPv6 address planning.
It’s me again with another teaser for an upcoming workshop at the
IPv6 Security Summit. This one
is a classic! If you happen to deploy IPv6 in your environment in the near
future, but didn’t had the time to think about the security implications, this
workshop
is the right place to start.
We will start the workshop with a quick refresher of the core behavior of IPv6
to make sure that every attendee is on the same page. Before we start discussing
and demonstrating various IPv6 attacks, we dive into (a little more abstract)
topic of why IPv6 security actually isn’t that easy to implement. We will
continue with IPv6 attacks targeted at the local link. Rafael and I will
introduce commonly used IPv6 attack tools as well as performing various attacks
in a dedicated lab environment. Every attendee is encouraged to participate in
these exercises. We will provide you with the necessary tools; you just have to
bring a laptop with (ideally) Linux installed. We will prepare some virtual
machines including VMware Player in case your corporate laptop runs Windows.