We’ve just released a whitepaper discussing the behavior of different operating
systems once they receive IPv6 configuration parameters from different sources.
For that purpose a number of lab tests were conducted.
In short, it’s a mess.
Again, RFC ambiguity and/or
(perceived) vendor implementation freedom suck big time. For us practitioners
out (t)here this means (once more) we need extensive test labs and good
troubleshooting guides for large scale IPv6 deployments.
Troopers is right around the corner and as
I am responsible for the whole conference network I wanted to make sure that
everything is working as expected. I went to the venue on Friday because of two
things I wanted/needed to setup. Compared to last year’s setup we had a couple
of changes in regards to the provider connection (resulting in some changes for
our network setup). First, we now have a rather big pipe for the uplink and more
importantly (well that depends on the point of view ;)) there is a native IPv6
connection. Before that I had to tunnel all IPv6 traffic from the venue to one
of our gateways and to forward it out (as native IPv6) from there. As this step
isn’t necessary anymore, and the staff on the venue isn’t that experienced with
IPv6, I had in mind to setup and verify that IPv6 is working as desired. The
router used over there is a
Mikrotek Routerboard. As I haven’t
worked with these devices before, I was curious whether everything works as it
should ;).
Based on recent research in the ERNW IPv6 lab and with
our MLD talk looming
we’ve put together a (as we think) comprehensive document discussing how to
thoroughly test MLD implementations in various components (network devices or
servers/clients). We hope it can contribute to a better understanding of the
protocol and that it can serve as either a checklist for your own environment or
as a source of inspiration for researchers looking at MLD themselves.
Last year,
during the
IPv6 Security Summit
of Troopers 14 I had the
pleasure to present publicly, for first time, my IPv6 Penetration Testing /
Security Assessment framework called
Chiron, while later, it was also
presented at Brucon 14 as part of the 5×5
project. This year, I am returning back to the place where it all started,
to the beautiful city of Heidelberg to give another workshop about Chiron at
the
IPv6 Security Summit
of Troopers 15. But, is it just another
workshop with the known Chiron features or has something changed?
I would say a lot :). The most significant enhancements are described below.
This is a guest post from Vladimir Wolstencroft, to provide some details of his
upcoming
#TR15 talk.
What do you get when you combine a security appliance vendor, a bug bounty
program, readily available virtualised machines, a lack of understanding of best
security practices and broken crypto?
Ownage, a good story and maybe even that bounty…
Focusing on Barracuda’s numerous security appliances, this talk will detail bug
hunting methods and the principles used to examine these machines:
Starting with a black box test and the challenges that this approach poses, to
decrypting the firmware, getting system root, bricking the box, fighting the
(de)activation methods, getting system root again, DOS’ing the VM host and
finally using Barracuda’s own source code to find those vulnerabilities that
otherwise would be invisible or impossible to find! There were also some
unexpected outcomes that followed…
Developing a secure and feature rich hypervisor is no easy task. Recently, the
open source Xen hypervisor was affected by two interesting vulnerabilities
involving its x86 emulation code:
XSA 110 and
XSA 105. Both bugs show that the
attack surface of hypervisors is often larger than expected. XSA 105 was
originally reported)
by Andrei Lutas from BitDefender. The patch adds missing privilege checks to the
emulation routines of several critical system instructions including LGDT and
LIDT. The vulnerable code can be reached from unprivileged user code running
inside hardware virtual machine (HVM) guests and can be used to escalate guest
privileges. XSA 110 was reported by Jan Beulich from SUSE and concerns
insufficient checks when emulating long jumps, calls or returns.
We have pretty much finalized the agenda for the
Troopers TelcoSecDay and here’s another
cool talk (the others can be found
here,
here and
here):
Rob Kuiters: On her majesty’s secret service – GRX and a Spy Agency
Synopsis: In 2013 the GPRS Roaming eXchange (GRX) was in mainstream media as
part of the high profile Edward Snowden revelations. The leaked documents
indicated that the UK government’s intelligence organisation, Government
Communications Headquarters’ (GCHQ) hacked the Belgian GRX provider, Belgacom
International Carrier Services (BICS). They did this by targeting the GRX
provider’s employees with the ultimate aim of gaining access to Belgacom’s Core
GRX routers. Allegedly, GCHQ hacked the GRX routers in order to carry out
man-in-the middle “traffic sniffing” attacks against mobile users who are
roaming with smartphones or other devices capable of handling data.
Server operating systems with an OS, for which vendor support has ended, come
with many risks that have to be considered and addressed. The primary goal
should be always to decommission or migrate the majority of end-of-life (EoL)
servers to OS versions, supported by the vendor. Here it should be noted that a
migration to an up-to-date OS should be preferably done before your organization
enters the end of life of that software 😉
in addition to those
recently announced and
these,
we’ve identified three more suitable talks for the TelcoSecDay
.
These are:
Hendrik Schmidt: Security Aspects of VoLTE
Synopsis: VoLTE is on its rise in mobile telecommunications. The service is
provided by the IP Multimedia Subsystem (IMS) which consists of a couple of
components. All those components offer new and, from an attacker’s perspective,
interesting interfaces. This talk evaluates the most interesting interfaces and
demonstrates attack vectors an attacker could abuse. This covers attacks from
customer access, Internet VoIP services and roaming exchange.
.