Wireshark in IP version 6 workshop was a part of IPv6 summit sessions of
Troopers 16. It was held by Jeffery Carrell on the second day of IPv6 summit on
Tuesday, the 15th of March. The workshop was generally divided into two
sections: a short introduction to IPv6 and analyzing some IPv6 packets on
Wireshark.
Introduction to IPv6
IPv6 protocol was defined at the end of 1990’s, mainly to provide a huge address
pool after realizing that the world would run out of IPv4 addresses quickly. The
work on IPv6 started before the introduction of NAT and Private addressing to
IPv4, which are considered temporary solutions of IPv4 address shortage problem.
IPv6 address consists of 128 bits, divided into 8 groups called nibbles,
quibbles or hextets separated by colons. Each nibble consists of four
hexadecimal digits. The 128 bits address length provides 340 trillion trillion
trillion addresses. An IPv6 address is divided into two parts: the left part is
the network identifier while the right one is the host identifier. The default
prefix is /64 which divided the IP address into two halves. An IPv6 address
looks as follows: 2001:0db8:1010:61ab:f005:ba11:00da:11a5/64
Felix Wilhelm presented in his talk various ways to attack his new target – The
PA-500 which is produced by Palo Alto Networks.
He discovered vulnerabilities in 3 different exposed aspects of the device. The
first vulnerability occurred inside of an unauthenticated API from the
Management-Website which could only be accessed within the Admin Network. This
vulnerability was a typical off-by-one Command Injection, which could be abused
by reaching out to the API with a special client=wget Request.
Hey there!
The God of frequencies Michael Ossmann visited us again this year at the
TROOPERS16 and showed us how to break
another device using a specific setup.
Last time he introduced the HackRF One to us (Read
here:https://www.insinuator.net/2014/08/hackrf-one-the-story-continues/), but
this post is a short summary of his talk about “Rapid Radio Reversing”, he is a
wireless security researcher, who makes hardware for hackers. Best known for the
HackRF, Ubertooth, and Daisho projects, he founded Great Scott Gadgets in an
effort to put exciting, new tools into the hands of innovative people.
**tldr;**This blogpost presents a measurement study of a current security state
regarding to open ports on a direct comparison of IPv4 and IPv6. The study
analyses almost 58,000 dual-stacked domains in order to find discrepancies in
applied security policies. We further discuss the potential reasons and, more
importantly, the implications of the identified differences. \tldr;
For those of you who couldn’t participate at Troopers Conference 2016 in
Heidelberg or watch my talk at the IPv6 Security Summit, I want to recap some of
the most important parts of my research in this blogpost.
He is a security researcher in Google’s Project Zero. He has been involved with
computer hardware and software security for over 10 years looking at a range of
different platforms and applications. With a great interest in logical
vulnerabilities he has numerous disclosures in a wide range of products from web
browsers to virtual machine breakouts as well as being a Pwn2Own and Microsoft
Mitigation Bypass bounty winner. He has spoken at a number of security
conferences including Black Hat USA, CanSecWest, Bluehat, HITB, and Infiltrate.
Troopers is (unfortunately) over. It was a blast (but I may be biased ;-))!
After things have settled, I want to take the opportunity to reflect my thoughts
and impressions on the IPv6-only WiFi we had deployed during the conference. To
make sure that everybody is on the same page let’s start at the beginning.
In the last couple of years we had provided Dual-Stack connectivity on the main
“Troopers” SSID but also had an additional IPv6-only SSID. This year we decided
to spice things up and made the “Troopers“ SSID IPv6-only (with NAT64) while
providing Dual-Stack connectivity on the “Legacy“ SSID. We wanted to get a
feeling how many clients and applications can work properly in an IPv6-only
environment. We intentionally didn’t announce it vastly beforehand, hoping that
attendees would just connect to the main SSID without noticing anything. We were
aware that some applications might expose issues but, as I said , we wanted to
get a feeling to which degree problems actually occured.
Real men used to wear pink pagers, but that’s the past and recently it was time
for Troopers 16. Meaning: Real Troopers wear awesome Badges! And, from the
feedback we got, they did!
Troopers might be over, but the era of the TR16 Badge is seemingly just
beginning. As such, here’s a quick insight into the badge!
To start, this is the first of (at least) three blogposts covering the badge. As
we’re currently in the middle of stripping and cleaning our source code
repository, this post now will not cover the firmware. The stripping is not
about hiding something, but as we used an Open Source
RTOS our repo
currently contains modules, which are for completely other architectures.
In addition we needed a few workarounds while getting the badge up and running
for the conference, following our own hacking sessions, there will be a
dedicated post concerned with hardware modifications and hacks which can be
performed.
only a few seconds left! As a short reminder, there is a GSM network running on
Troopers 2016. It should be available in the whole building. To attend the
network you need to
Get a SIM Card @Troopers_Desk
Put it in your phone
Start the phone
That’s it!
You can always dial *#100# to get your phone number. All further
information (and a phonebook) you’ll find on gsm.troopers.de, but here again a
brief summary:
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.
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.