Insinuator


Some outright rants from a bunch of infosec practitioners.

Oct/14

15

Deaggregation by large organizations

Some hours ago Iljitsch van Beijnum posted an email with the above subject to the RIPE Best Current Operational Practices (BCOP) mailing list.
Therein he describes the growing issue of (IPv6 prefix) deaggregation desires/approaches by certain organizations vs. the filtering practices of other organizations (providers). I touched this problem, from an enterprise’s perspective, some time ago in the second part of my blog post series on IPv6 address planning. Given we think that the discussion is heavily needed from several angles, I had actually submitted a talk on the topic twice (for the RIPE meeting in Warsaw in May and the upcoming one in London) which was unfortunately rejected at both occasions.
I’m hence very happy to see that a dialogue about the inherent dilemma might be started by Iljitsch’s mail. As a contribution to the development of a BCOP document I will hereby publish our draft slides of the talk which was initially planned. Furthermore two fellow IPv6 practitioners (Hi Roland & Nico!) and I plan to release a detailed paper with research results as for IPv6 prefix distribution at major European IXs in the near future.

Let’s hope that we as the IPv6 community can reach some consensus in this space soon. See you in London,
have a good one everybody

Enno

 

, | Post your comment here.

Oct/14

14

North American IPv6 Summit 2014

Hello everyone,

I know I am a bit late with this post, but I was speaking on the North American IPv6 Summit in Denver three weeks ago. The focus of my talk was on Why IPv6 Security is hard – Structural Deficits of IPv6 & Their Implications (slightly modified/updated from the Troopers IPv6 Security Summit).  We consider the NA IPv6 Summit as one of the most important IPv6 events at all and we were happy to contribute to the overall success. The conference was organized for the 7th time by the Rocky Mountain IPv6 Task Force and took place in the Grand Hyatt Denver (37th floor ;-)). Luckily the weather was perfect, and the view of the landscape from the conference rooms was just amazing. I really enjoyed the time in Denver, as the organizer sdid all they could to treat the speaker well J. The talks were of mix of regular research or case-study type talks and some sponsored talks ranging from deployment experience, security and statistics to SDN (Yes, I said it ;)) and the Internet of Things (I said it again ;)). The line-up was nicely put together.

(more…)

, | Post your comment here.

This is a guest post from Antonios Atlasis.

Last week I had the pleasure to give you my impressions regarding my experience about hacking for b33r at Ghent, that is, my participation at BruCON 2014 hacking conference. As I said among else, the reason that I was there was to present Chiron, my IPv6 penetration testing/security assessment framework, which was supported by the Brucon 5×5 program. The first version of Chiron had been presented at Troopers 14, during the IPv6 Security Summit.

(more…)

, , | Post your comment here.

Sep/14

27

“Hacking for a B33r” at Ghent

This is a guest post by Antonios Atlasis.

This week I had the pleasure to attend BruCON 2014. While participating at the Brucon 5×5 program, I had also the chance to attend this well-known European Con which is held in the beautiful city of Ghent.

(more…)

, | Post your comment here.

Yesterday I gave a talk with the above title in a private setting. Given it might be of interest for some of you, the slides can be found here.

Have a great weekend everybody

Enno

| Post your comment here.

This is a guest post from Antonios Atlasis.

Today we had the opportunity at ERNW to have a full-day discussion about MLD. The discussion was led by Jayson Salazar who writes his thesis on the topic.

For the newcomers to IPv6 world, the purpose of MLD, a subprotocol of IPv6, as defined in RFC 2710, is “to enable each IPv6 router to discover the presence of multicast listeners (that is, nodes wishing to receive multicast packets) on its directly attached links, and to discover specifically which multicast addresses are of interest to those neighboring nodes.” MLD was updated by MLDv2 in RFC 3810 in order to “add the ability for a node to report interest in listening to packets with a particular multicast address only from specific source addresses or from all sources except for specific source addresses.

(more…)

, | Post your comment here.

Aug/14

25

ERNW’s Top 9 Burp Plugins

In the context of an internal evaluation, we recently had a look at most of the burp plugins available from the BApp store. The following overview represents our personal top 9 plugins, categorized in “Scanner Extensions”, “Manual Testing” and “Misc” in alphabetic order:
(more…)

, | Post your comment here.

This is a guest post by Antonios Atlasis.

Continuing the discussion about the IPv6 Atomic Fragments started at the IPv6 hacker’s mailing list and the freshly proposed draft RFC regarding the deprecation of the generation of IPv6 Atomic Fragments, we decided to check very quickly what is the current situation regarding the acceptance or the rejection of Atomic fragments in the “real world”. Thanks to Rafael Schaefer and the RISC lab at ERNW, we got some first measurements really fast.

(more…)

, , | Post your comment here.

This is a guest post from Antonios Atlasis.

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).

(more…)

, | Post your comment here.

Aug/14

20

HackRF One the story continues…

Hello fellow frequency hoppers,

once again, we welcomed Michael Ossmann at the ERNW headquarters for fun with SDR. This time with Mike´s advanced SDR workshop. And to be up front about it…it was plain awesome. For everybody who is not familiar with Software Defined Radio (SDR): Let’s regard it as the ultimate tool when working with radio signals. Take a look a this to learn more.

Mike showed us the new revision of his HackRF One and explained us some more advanced techniques when it comes to Radio Frequnecies hacking. Compared to last time, the workshop focused on reversing signals and how to synthesize them. So this time we were crafting RF packets ourselves instead of just replaying a capture. This introduces different attack types which can be carried out over the air for  example bruteforcing or fuzzing of radio devices.

GreatScottgadgets.com HackRF One

GreatScottgadgets.com
HackRF One

We thought about some devices that would be worth taking a look at because you probably dont want to start reversing your car`s remote key.So we ended up analyzing “simpler” devices for training purposes and decided to mess around with a Shutter remote control and an Instant Messaging device.

The remote shutter control operates the shutter of a DSRL so you can take pictures without holding the camera in your hands. So a user could focus the cam and take pictures. An attacker on the other hand could take pictures when the camera is not supposed to or simply jam the reciever to prevent from pictures being taken. This was quite easy and worked very well, so we went on to other interesting devices…

Mike brought a modified version of the IM-Me (Instant Messenging device for children). We tried to record and analyze its signals to be able to spoof messages and run arbitrary shell commands on a remote system that has installed a special “IM-Me” Server application based on previous research. Our goal was to synthesize commands which are sent to the device e.g “ls”. The first step in doing this is to capture a clean signal and filter it properly to be able to demodulate the signal into binary data to process it further. Mike explaind pretty handy tricks to accomplish these tasks on which we will talk about in further posts, so stay tuned.

Im-Me

Im-Me

If yo are interested in the IM-me take a look at this and this to learn more.

So THANKS a lot Mike. It once again has been quite interesting to see
where RF testing is heading and how much more is to be learned on this field.

So long,
Wojtek & Brian

, | Post your comment here.

<< Latest posts

Older posts >>

Contact


Mail | Twitter | Imprint

©2010-2013 ERNW GmbH
To top