<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Enno Rey on Insinuator.net - Bold Statements</title>
    <link>https://insinuator.net/authors/enno-rey/</link>
    <description>Recent content in Enno Rey on Insinuator.net - Bold Statements</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Thu, 30 Apr 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://insinuator.net/authors/enno-rey/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>When paradigms are shifting: InfoSec in the age of AI</title>
      <link>https://insinuator.net/2026/04/when-paradigms-are-shifting-infosec-in-the-age-of-ai/</link>
      <pubDate>Thu, 30 Apr 2026 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2026/04/when-paradigms-are-shifting-infosec-in-the-age-of-ai/</guid>
      <description>&lt;p&gt;Over the last few weeks, I have had a very productive exchange with&#xA;&lt;a href=&#34;https://www.linkedin.com/in/christoph-klaassen-9a4651144/&#34;&gt;Christoph Klaassen&lt;/a&gt;&#xA;on the impact of AI on security governance and compliance. In this post, we&#xA;summarize our thoughts.&lt;/p&gt;</description>
    </item>
    <item>
      <title>MCTTP 2025 / Keynote</title>
      <link>https://insinuator.net/2025/10/mcttp-2025-/-keynote/</link>
      <pubDate>Mon, 20 Oct 2025 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2025/10/mcttp-2025-/-keynote/</guid>
      <description>&lt;p&gt;Three weeks ago, I attended &lt;a href=&#34;https://www.mcttp.de&#34;&gt;MCTTP 2025&lt;/a&gt; in Munich,&#xA;organized by Vogel IT and curated by the fine folks Florian Hansemann, Dr. Marc&#xA;Maisch, and Florian Oelmaier. Awesome event with some very cool talks, and great&#xA;conversations over dinner and most notably at the Oktoberfest on Saturday&#xA;(thanks again for that special trip, Flo!). I had the pleasure and honor to give&#xA;the keynote on the 2nd day. The goal was to make it a bit entertaining and&#xA;enlightening for the international audience, so I covered some German&#xA;literature, too ;-). The slides can be found&#xA;&lt;a href=&#34;https://ernw.de/download/Enno_ERNW_MCTTP_keynote.pdf&#34;&gt;here&lt;/a&gt;, and the transcript&#xA;&lt;a href=&#34;https://ernw.de/download/ERNW_Enno_MCTTP_2025_Faust.pdf&#34;&gt;here&lt;/a&gt;. Looking forward&#xA;to meeting some folks again next year, maybe even at&#xA;&lt;a href=&#34;https://troopers.de&#34;&gt;TROOPERS26&lt;/a&gt; 😉&lt;/p&gt;</description>
    </item>
    <item>
      <title>#TROOPERS25 AD &amp; Entra ID Security Track</title>
      <link>https://insinuator.net/2025/08/troopers25-ad-entra-id-security-track/</link>
      <pubDate>Thu, 14 Aug 2025 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2025/08/troopers25-ad-entra-id-security-track/</guid>
      <description>&lt;p&gt;The #TROOPERS25 ‘AD &amp;amp; Entra ID Security’ track was a blast – as was the whole&#xA;conference 😉 –  bringing together some of the smartest researchers in the field&#xA;and a great audience of practitioners willing to share their experiences during&#xA;the &lt;a href=&#34;https://troopers.de/roundtables/&#34;&gt;roundtable&lt;/a&gt;. The slides of the talks have&#xA;been released in the interim on the &lt;a href=&#34;https://troopers.de&#34;&gt;TROOPERS website&lt;/a&gt;, but&#xA;since many speakers published additional blogposts or released tools, we provide&#xA;a compilation of resources from the track in the following.&lt;/p&gt;</description>
    </item>
    <item>
      <title>A Brief History of the IPv4 Address Space</title>
      <link>https://insinuator.net/2019/08/a-brief-history-of-the-ipv4-address-space/</link>
      <pubDate>Mon, 26 Aug 2019 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2019/08/a-brief-history-of-the-ipv4-address-space/</guid>
      <description>&lt;p&gt;This is meant to be the first part of a 3-part series discussing the space &amp;amp; types of IP addresses, with a particular focus on what has changed between IPv4 and IPv6. In this first post I’ll take the audience through a historical tour of some developments within the IPv4 address space.&lt;/p&gt;&#xA;&lt;p&gt;In a second part I’ll discuss the properties of different types of addresses from a routing and from a security perspective, both in the IPv4 and in the IPv6 space. In the third part we’ll look at the implications of deploying IPv6 in certain networks based on those differences, e.g. “how to handle ACLs and IP address based log analysis approaches in a dual-stack network where systems have one RFC 1918 IPv4 address and multiple IPv6 GUAs?” (for specific reasons the latter two parts might be published on another medium though). In any case let’s start with a brief history of IPv4. The goal here is to understand how we got to the state that we have today.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Black Hat US 2019 / Some Talks</title>
      <link>https://insinuator.net/2019/08/black-hat-us-2019-/-some-talks/</link>
      <pubDate>Tue, 13 Aug 2019 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2019/08/black-hat-us-2019-/-some-talks/</guid>
      <description>&lt;p&gt;I’ve been at Black Hat Vegas last week and in the following I’ll shortly discuss some talks I’ve attended and which I found interesting.&lt;/p&gt;&#xA;&lt;p&gt;&lt;strong&gt;&lt;a href=&#34;https://twitter.com/gabbifish&#34;&gt;Gabriele Fisher&lt;/a&gt; &amp;amp; &lt;a href=&#34;https://twitter.com/lukevalenta&#34;&gt;Luke Valenta&lt;/a&gt;: Monsters in the Middleboxes. Building Tools for Detecting HTTPS Interception&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;This talk was about identifying if inbound HTTPS traffic reaching a server had been intercepted by a &lt;a href=&#34;https://tools.ietf.org/rfc/rfc3234.txt&#34;&gt;middlebox&lt;/a&gt; (or its software equivalent which is usually called “middleware”, a prominent example being the Lenovo Superfish piece a few years ago) on its path.&lt;/p&gt;</description>
    </item>
    <item>
      <title>IPv6 Surveys / Application Space</title>
      <link>https://insinuator.net/2019/06/ipv6-surveys-/-application-space/</link>
      <pubDate>Sun, 30 Jun 2019 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2019/06/ipv6-surveys-/-application-space/</guid>
      <description>&lt;p&gt;In some organizations we work with a certain state of IPv6 deployment has been reached in the interim which includes, among others, the following aspects:&lt;/p&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;the network infrastructure is IPv6-enabled (incl. interface addressing, routing [protocols] and the like).&lt;/li&gt;&#xA;&lt;li&gt;parts of supporting services (security functions, monitoring, system management) include IPv6 in a proper way.&lt;/li&gt;&#xA;&lt;li&gt;3rd party providers have been contractually obliged to deliver their services in an “IPv6-enabled” mode (as opposed to only being “IPv6-capable” which was the standard requirement in many RFIs during earlier years).&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;p&gt;It might then happen that networking people (who often are the initial motivators for deploying IPv6) in such organizations are stating, when asked about IPv6: “it’s [mostly] done”.&lt;br&gt;&#xA;Point is that, alas, this does not necessarily mean that a single service or application is *actually using* IPv6, so while the above certainly constitutes an achievement it might not even be halfway through.&lt;/p&gt;</description>
    </item>
    <item>
      <title>IPv6 Properties of Windows Server 2019 / Windows 10 (1809)</title>
      <link>https://insinuator.net/2019/06/ipv6-properties-of-windows-server-2019-/-windows-10-1809/</link>
      <pubDate>Wed, 12 Jun 2019 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2019/06/ipv6-properties-of-windows-server-2019-/-windows-10-1809/</guid>
      <description>&lt;p&gt;In this post I’ll cover some properties of the Windows Server 2019 IPv6 stack. It is an update of a similar post I wrote on the &lt;a href=&#34;https://insinuator.net/2017/01/ipv6-properties-of-windows-server-2016-windows-10/&#34;&gt;IPv6 properties of Server 2016&lt;/a&gt; a while ago.&lt;/p&gt;&#xA;&lt;p&gt;For this reason I will mostly look at the same properties I did at the time (read: at times without providing too much technical background information; that can be found in the other post) and I’ve hence performed the same types of practical tests.&lt;/p&gt;</description>
    </item>
    <item>
      <title>The Week in Review #RIPE78</title>
      <link>https://insinuator.net/2019/05/the-week-in-review-%23ripe78/</link>
      <pubDate>Sun, 26 May 2019 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2019/05/the-week-in-review-%23ripe78/</guid>
      <description>&lt;p&gt;This week &lt;a href=&#34;https://twitter.com/bcp38_&#34;&gt;Chris&lt;/a&gt; and I participated in the RIPE 78 meeting in Reykjavík. Being part of the group was fun as always and we had quite some interesting conversations with peers from (not only) the IPv6 community.&lt;br&gt;&#xA;Big thanks to the &lt;a href=&#34;https://twitter.com/RIPE_NCC&#34;&gt;RIPE NCC&lt;/a&gt; team for the smooth organization and for taking care of us!&lt;/p&gt;&#xA;&lt;p&gt;In this post I’ll provide some notes on talks I found particularly interesting, plus links to our own contributions.&lt;/p&gt;</description>
    </item>
    <item>
      <title>IPv6 Security for Enterprise Organisations @ #RIPE78</title>
      <link>https://insinuator.net/2019/05/ipv6-security-for-enterprise-organisations-@-%23ripe78/</link>
      <pubDate>Fri, 17 May 2019 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2019/05/ipv6-security-for-enterprise-organisations-@-%23ripe78/</guid>
      <description>&lt;p&gt;&lt;a href=&#34;https://twitter.com/bcp38_&#34;&gt;Chris&lt;/a&gt; and I will give a tutorial on the above topic at &lt;a href=&#34;https://ripe78.ripe.net/&#34;&gt;next week’s RIPE Meeting&lt;/a&gt; in Reykjavík. In this post (actually this will probably become a small series of posts) I’ll try to summarize some thoughts on IPv6 security in enterprise environments in 2019.&lt;/p&gt;&#xA;&lt;p&gt;We’re going to cover three main areas:&lt;/p&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;Why IPv6 Is Different, Security-wise&lt;/li&gt;&#xA;&lt;li&gt;Traffic Filtering in IPv6 Networks&lt;/li&gt;&#xA;&lt;li&gt;IPv6 Security in L2 Networks / First Hop Security et al.&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;p&gt;Let’s start with the first item. In real-life scenarios the security of “a protocol” – IPv6 can rather be considered a “protocol family” which includes helper protocols like ICMPv6 and MLD (which in turn is implemented by means of ICMPv6 messages) and potentially others like DHCPv6 – might depend on a number of factors:&lt;/p&gt;</description>
    </item>
    <item>
      <title>Upcoming ISH Conference</title>
      <link>https://insinuator.net/2019/04/upcoming-ish-conference/</link>
      <pubDate>Wed, 03 Apr 2019 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2019/04/upcoming-ish-conference/</guid>
      <description>&lt;p&gt;We’re happy to announce that some fine folks of ERNW will be present at the upcoming &lt;a href=&#34;https://www.ish-muc.com/conference&#34;&gt;ISH Conference&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;p&gt;The next generation IT security training facility for all industries and any institution that manages complex infrastructure invites you to join the first ISH Conference about threats, prevention and response in Information Security on May 6th– 9th, 2019.&lt;br&gt;&#xA;The event consists of two days of conference and two days of training with insights and shared knowledge by world leading experts at the Information Security Hub (ISH) Munich Airport.&lt;br&gt;&#xA;Learn and discuss the newest threats and solutions with world-renowned experts like Eugene Kaspersky, Adam Meyer, Adrian Nish and others.&lt;/p&gt;</description>
    </item>
    <item>
      <title>IPv6 Address Management / The “External” Flag</title>
      <link>https://insinuator.net/2019/02/ipv6-address-management-/-the-external-flag/</link>
      <pubDate>Fri, 22 Feb 2019 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2019/02/ipv6-address-management-/-the-external-flag/</guid>
      <description>&lt;p&gt;We’re regularly asked to review IPv6 address plans from different organizations and I’d like to share some reflections from such a process currently happening. I’ve discussed a few aspects of IPv6 address planning before; those readers interested please see &lt;a href=&#34;https://insinuator.net/2019/01/ipv6-talks-publications/&#34;&gt;this post&lt;/a&gt; which contains some references.&lt;/p&gt;&#xA;&lt;p&gt;The organization in question is headquartered in Germany, has ~60K employees and a number of subsidiaries in European countries. They belong to a “traditional industry sector” (so they’re not an “Internet company”, even though they – as the majority of large organizations right now – strive to be one in a few years ;-).&lt;/p&gt;</description>
    </item>
    <item>
      <title>IPv6 Security in an IPv4-only Environment</title>
      <link>https://insinuator.net/2019/02/ipv6-security-in-an-ipv4-only-environment/</link>
      <pubDate>Wed, 20 Feb 2019 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2019/02/ipv6-security-in-an-ipv4-only-environment/</guid>
      <description>&lt;p&gt;Starting a post, in 2019, with a mention of sth being “IPv4-only” somewhat hurts ;-), but here we go. Recently &lt;a href=&#34;https://twitter.com/manelrodero&#34;&gt;Manel Rodero&lt;/a&gt; from Barcelona asked me the &lt;a href=&#34;https://twitter.com/manelrodero/status/1093272272599695360&#34;&gt;following question&lt;/a&gt; on Twitter:&lt;/p&gt;&#xA;&lt;p&gt;&lt;img src=&#34;tweet_mr.png&#34; alt=&#34;&#34;&gt;&lt;/p&gt;&#xA;&lt;p&gt;In this post I’ll try to discuss some inherent aspects of that question and ofc I’ll try to provide a response to it, too ;-).&lt;/p&gt;&#xA;&lt;p&gt;Let’s first think about the main IPv6-related &lt;em&gt;risks&lt;/em&gt; (= threats put into a context of relevance) in an “environment [that] is only IPv4”. While some of you might scratch your heads “what IPv6 threats could there be in an IPv4 setting?” I’m tempted to scratch my head: “what could be the reasons to run an university network without IPv6 these days, or to use BIND?” (which I have a strong opinion on, see &lt;a href=&#34;https://insinuator.net/2011/11/call-me-snake/&#34;&gt;here&lt;/a&gt; or &lt;a href=&#34;https://twitter.com/Enno_Insinuator/status/852358157292761089&#34;&gt;here&lt;/a&gt;). But I disgress. More seriously the main reason for the question can be broken down to:&lt;/p&gt;</description>
    </item>
    <item>
      <title>Some Notes on the IPv6 Properties of the Wireless Network @ Cisco Live Europe</title>
      <link>https://insinuator.net/2019/02/some-notes-on-the-ipv6-properties-of-the-wireless-network-@-cisco-live-europe/</link>
      <pubDate>Sun, 03 Feb 2019 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2019/02/some-notes-on-the-ipv6-properties-of-the-wireless-network-@-cisco-live-europe/</guid>
      <description>&lt;p&gt;Some years ago &lt;a href=&#34;https://twitter.com/bcp38&#34;&gt;Christopher&lt;/a&gt; wrote two posts (&lt;a href=&#34;https://insinuator.net/2016/02/observations-from-the-cisco-live-europe-2016-wifi-infrastructure/&#34;&gt;2016&lt;/a&gt;, &lt;a href=&#34;https://insinuator.net/2015/01/observations-from-the-cisco-live-europe-wifi-infrastructure/&#34;&gt;2015&lt;/a&gt;) about the  IPv6-related characteristics of the WiFi network at Cisco Live Europe. To somewhat continue this tradition and for mere technical interest I had a look at some properties of this year’s setting.&lt;/p&gt;&#xA;&lt;p&gt;There were two SSIDs of interest: a dual-stacked one (“CiscoLive2019”) and one with v6-only plus NAT64 (“CL-NAT64”). For some background on the underlying infrastructure components you might look at this &lt;a href=&#34;https://twitter.com/DarchisNicolas/status/1089095382171299840&#34;&gt;thread&lt;/a&gt; by &lt;a href=&#34;https://twitter.com/DarchisNicolas&#34;&gt;Nicolas Darchis&lt;/a&gt; from the NOC or at &lt;a href=&#34;https://twitter.com/networkautobahn/status/1089827410541977600&#34;&gt;this tweet&lt;/a&gt; from &lt;a href=&#34;https://twitter.com/networkautobahn&#34;&gt;Dominik Pickhardt&lt;/a&gt;. Some stats on IPv6 usage at CLEUR can be found &lt;a href=&#34;https://twitter.com/SNMPguy/status/1091018632593895425&#34;&gt;here&lt;/a&gt;.&lt;/p&gt;</description>
    </item>
    <item>
      <title>#TR19 Active Directory Security Track</title>
      <link>https://insinuator.net/2019/01/%23tr19-active-directory-security-track/</link>
      <pubDate>Wed, 23 Jan 2019 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2019/01/%23tr19-active-directory-security-track/</guid>
      <description>&lt;p&gt;As some of you might recall we’ve introduced a dedicated “Active Directory Security Track” at last year’s &lt;a href=&#34;https://www.troopers.de/&#34;&gt;Troopers&lt;/a&gt;. For Troopers19 we’ve expanded it to two days (as the SAP Security Track was discontinued), and in the following I’ll provide a list of talks in the track.&lt;/p&gt;&#xA;&lt;p&gt;&lt;strong&gt;Vincent Le Toux: You “try” to detect mimikatz&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;Abstract: This is 2019 and you still “try” to detect mimikatz. “Try”, because after many years, this post exploitation tool continues to be successful.&lt;br&gt;&#xA;As a contributor to mimikatz and also a blue team guy, I’m asking myself why antivirus vendors are unable to catch it after many years.&lt;br&gt;&#xA;How can a tool be blocked if nobody does not know what this tool is doing? Because surprisingly, it is known only for credential collection but mimikatz is a lot more.&lt;br&gt;&#xA;To mitigate the lack of antivirus vendor, should we buy new fancy EDR tool or try a technical approach? Apply a Framework? Rely on Compliance? Use a SIEM to collect logs and apply correlation? In sumarry, can we detect mimikatz?&lt;br&gt;&#xA;In this presentation we will try to understand why mimikatz has such power and especially some weakness related to credential gathering and active directory will be exposed.&lt;/p&gt;</description>
    </item>
    <item>
      <title>IPv6 Talks &amp; Publications</title>
      <link>https://insinuator.net/2019/01/ipv6-talks-publications/</link>
      <pubDate>Thu, 10 Jan 2019 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2019/01/ipv6-talks-publications/</guid>
      <description>&lt;p&gt;At first a very happy new year to everybody!&lt;/p&gt;&#xA;&lt;p&gt;While thinking about the agenda of the upcoming &lt;a href=&#34;https://www.troopers.de/&#34;&gt;Troopers&lt;/a&gt; NGI IPv6 Track I realized that quite a lot of IPv6-related topics have been covered in the last years by various IPv6 practitioners (like my colleague &lt;a href=&#34;https://twitter.com/bcp38_&#34;&gt;Christopher Werny&lt;/a&gt;) or researchers (like my friend &lt;a href=&#34;https://twitter.com/AntoniosAtlasis&#34;&gt;Antonios Atlasis&lt;/a&gt;). In a kind of shameless self plug I then decided to put together of list of IPv6 talks I myself gave at several occasions and of publications I (co-) authored. Please find this list below (sorted by years); you can click on the titles to access the respective documents/sources.&lt;br&gt;&#xA;I hope some of this can be of help for one or the other among you in the course of your own IPv6 efforts.&lt;br&gt;&#xA;Cheers,&lt;/p&gt;</description>
    </item>
    <item>
      <title>ERNW Whitepaper 67: Active Directory Trust Considerations</title>
      <link>https://insinuator.net/2018/12/ernw-whitepaper-67-active-directory-trust-considerations/</link>
      <pubDate>Tue, 11 Dec 2018 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2018/12/ernw-whitepaper-67-active-directory-trust-considerations/</guid>
      <description>&lt;p&gt;Last week &lt;a href=&#34;https://twitter.com/HarmJ0y&#34;&gt;Will “harmj0y” Schroeder&lt;/a&gt; published an excellent technical article titled &lt;a href=&#34;https://www.harmj0y.net/blog/redteaming/not-a-security-boundary-breaking-forest-trusts/&#34;&gt;“Not A Security Boundary: Breaking Forest Trusts”&lt;/a&gt; in which he lays out how a highly critical security compromise can be achieved across a forest boundary, resulting from a combination of default AD (security) settings and a novel attack method. His post is a follow-up to the DerbyCon talk “The Unintended Risks of Trusting Active Directory” which he had given together with &lt;a href=&#34;https://twitter.com/tifkin_&#34;&gt;Lee Christensen&lt;/a&gt; and &lt;a href=&#34;https://twitter.com/enigma0x3&#34;&gt;Matt Nelson&lt;/a&gt; at DerbyCon (video &lt;a href=&#34;http://www.irongeek.com/i.php?page=videos/derbycon8/track-2-03-the-unintended-risks-of-trusting-active-directory-lee-christensen-will-schroeder-matt-nelson&#34;&gt;here&lt;/a&gt;). They will also discuss this at the upcoming &lt;a href=&#34;https://www.troopers.de/&#34;&gt;Troopers&lt;/a&gt; Active Directory Security Track (details on some more talks, including &lt;a href=&#34;https://twitter.com/PyroTek3&#34;&gt;Sean Metcalf’s&lt;/a&gt; one, can be found in &lt;a href=&#34;https://insinuator.net/2018/11/first-talks-of-troopers19-accepted/&#34;&gt;this post&lt;/a&gt; or &lt;a href=&#34;https://insinuator.net/2018/12/and-five-talks-more-were-accepted-at-troopers19/&#34;&gt;this one&lt;/a&gt;).&lt;/p&gt;</description>
    </item>
    <item>
      <title>#TR18 Active Directory Security Track, Part 1</title>
      <link>https://insinuator.net/2018/03/%23tr18-active-directory-security-track-part-1/</link>
      <pubDate>Thu, 22 Mar 2018 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2018/03/%23tr18-active-directory-security-track-part-1/</guid>
      <description>&lt;p&gt;This is the first post discussing talks of the &lt;em&gt;Active Directory Security Track&lt;/em&gt; of &lt;a href=&#34;https://www.troopers.de/troopers18/&#34;&gt;this year’s Troopers&lt;/a&gt; which took place last week in Heidelberg (like in the last nine years ;-). It featured, amongst others, a new track focused on Microsoft AD and its security properties &amp;amp; implications. &lt;a href=&#34;https://www.troopers.de/troopers18/agenda/#agenda-day--2018-03-15&#34;&gt;This&lt;/a&gt; was the agenda.&lt;/p&gt;&#xA;&lt;p&gt;The idea for this special track was born out of two considerations:&lt;/p&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;we had noted there’s a lot of stuff going on in the space, both on the offense and on the defense side. And in pretty much every incident analysis &amp;amp; response project we were brought in recently Active Directory played a huge role…&lt;/li&gt;&#xA;&lt;li&gt;already in the early phase of the CfP several interesting submissions came in (maybe due to the fact that some big guns of the field had voiced &lt;a href=&#34;https://twitter.com/mattifestation/status/906180147203645440&#34;&gt;very&lt;/a&gt; &lt;a href=&#34;https://twitter.com/christruncer/status/845321214788849666&#34;&gt;kind&lt;/a&gt; &lt;a href=&#34;https://twitter.com/harmj0y/status/710229755795144704&#34;&gt;words&lt;/a&gt; &lt;a href=&#34;https://twitter.com/subTee/status/972191912277901312&#34;&gt;in&lt;/a&gt; &lt;a href=&#34;https://twitter.com/Cneelis/status/845321978089295872&#34;&gt;the&lt;/a&gt; &lt;a href=&#34;https://twitter.com/PyroTek3/status/918214609273868288&#34;&gt;past&lt;/a&gt;)… and creating an extra track simply relieved us from the burden to make a tough choice between those.&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;p&gt;As this was the first Troopers since its creation where I didn’t have any official roles and out of personal interest (in a very distant past I happened to be the co-author of the first German book on &lt;a href=&#34;https://www.amazon.de/Security-unter-Windows-NT-4/dp/3778526707/&#34;&gt;Windows NT4 Security&lt;/a&gt;)  I decided to spend the majority of conference day 2 in the AD track. In hindsight I’m tempted to say that the track was a huge success: brilliant talks, pretty much always a packed room, and quite good discussions after the talks. (yes, of course I’m biased, what makes you think that?).&lt;/p&gt;</description>
    </item>
    <item>
      <title>#TR18 Active Directory Security Track</title>
      <link>https://insinuator.net/2018/01/%23tr18-active-directory-security-track/</link>
      <pubDate>Fri, 05 Jan 2018 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2018/01/%23tr18-active-directory-security-track/</guid>
      <description>&lt;p&gt;A happy new year to everybody!&lt;/p&gt;&#xA;&lt;p&gt;At &lt;a href=&#34;https://www.troopers.de/&#34;&gt;Troopers18&lt;/a&gt; there will be a new special track on Microsoft Active Directory and its security aspects, similar to the SAP security track which we established some years ago. The AD security track will feature, amongst others, the following talks.&lt;/p&gt;&#xA;&lt;p&gt;&lt;strong&gt;Sean Metcalf: Active Directory Security. The Journey&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;&lt;strong&gt;Abstract&lt;/strong&gt;: This talk is a journey into the challenges most organizations encounter while trying to secure their ‘castle’. The attacker has to be right only once, right? Not exactly. We will walk through effective security strategies that will stymie and frustrate attackers and better protect the Active Directory environment.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Why It Might Make Sense to Use IPv6 in Enterprise Infrastructure Projects</title>
      <link>https://insinuator.net/2017/11/why-it-might-make-sense-to-use-ipv6-in-enterprise-infrastructure-projects/</link>
      <pubDate>Fri, 10 Nov 2017 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2017/11/why-it-might-make-sense-to-use-ipv6-in-enterprise-infrastructure-projects/</guid>
      <description>&lt;p&gt;Looking at IPv6 deployment graphs like &lt;a href=&#34;https://twitter.com/Enno_Insinuator/status/926767238920658950&#34;&gt;this one&lt;/a&gt; it becomes clear that IPv6 still is not widely deployed in enterprise space (the reason for the apparent oscillation in that curve is the difference between working days – where people use their office computers – and weekend where they preferably use their smartphones or their home equipment connected by means of broadband networks).&lt;/p&gt;&#xA;&lt;p&gt;There’s a number of good reasons for this (in a nutshell: the overall IPv6 architecture is oriented around, and benefits, the decoupling of mostly autonomous, self-organized endpoints from a well-managed/provider-managed network infrastructure which isn’t exactly the operations model many large enterprise organizations have in mind for their networks. also you might have a look at &lt;a href=&#34;https://ripe74.ripe.net/presentations/67-Enno_Rey_RIPE74_Structural_Deficits_IPv6.pdf&#34;&gt;these slides&lt;/a&gt; from RIPE74 to understand some of the reluctance to deploy IPv6 in certain companies).&lt;/p&gt;</description>
    </item>
    <item>
      <title>Position Paper on an Enterprise Organization’s IPv6 Address Strategy</title>
      <link>https://insinuator.net/2017/10/position-paper-on-an-enterprise-organizations-ipv6-address-strategy/</link>
      <pubDate>Mon, 09 Oct 2017 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2017/10/position-paper-on-an-enterprise-organizations-ipv6-address-strategy/</guid>
      <description>&lt;p&gt;A while ago I wrote a short paper laying out options for an enterprise organization to get global IPv6 address space from the RIPE NCC, discussing the advantages and disadvantages of different approaches. As I think the topic may be of interest for others, too, I’ve distilled an anonymized version. It can be found &lt;a href=&#34;https://www.ernw.de/download/ERNW_IPv6_Strategy_RIPE.pdf&#34;&gt;here&lt;/a&gt;. I hope some of you find it useful.&lt;/p&gt;&#xA;&lt;p&gt;Cheers, Enno&lt;/p&gt;</description>
    </item>
    <item>
      <title>RIPE IoT Roundtable Meeting / Balanced Security for IPv6 CPE Revisited</title>
      <link>https://insinuator.net/2017/09/ripe-iot-roundtable-meeting-/-balanced-security-for-ipv6-cpe-revisited/</link>
      <pubDate>Fri, 29 Sep 2017 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2017/09/ripe-iot-roundtable-meeting-/-balanced-security-for-ipv6-cpe-revisited/</guid>
      <description>&lt;p&gt;Last week I had the pleasure to participate at the first &lt;a href=&#34;https://www.ripe.net/participate/meetings/roundtable/september-2017/ripe-iot-roundtable-meeting-21-september-2017&#34;&gt;&lt;em&gt;RIPE IoT Roundtable Meeting&lt;/em&gt;&lt;/a&gt; in Leeds (thanks! to &lt;a href=&#34;https://www.ripe.net/about-us/press-centre/publications/speakers/marco-hogewoning&#34;&gt;Marco Hogewoning&lt;/a&gt; for organising it). It was a day with many fruitful discussions. I particularly enjoyed &lt;a href=&#34;https://twitter.com/kistel&#34;&gt;Robert Kisteleki&lt;/a&gt;‘s talk on RIPE NCC’s own design &amp;amp; (security) process considerations in the context of &lt;a href=&#34;https://atlas.ripe.net/&#34;&gt;RIPE Atlas&lt;/a&gt; (at TR17 NGI there was an &lt;a href=&#34;https://www.troopers.de/downloads/troopers17/TR17_RIPEatlas.pdf&#34;&gt;intro to Atlas&lt;/a&gt;, too).&lt;br&gt;&#xA;In this post I’d like to quickly lay out the main points of my own contribution on “Balanced Security for IPv6 CPE Revisited” (the slides can be found &lt;a href=&#34;https://www.ernw.de/download/RIPE_IoT_Roundtable_Sep2017_EnnoRey_BalancedIPv6Sec.pdf&#34;&gt;here&lt;/a&gt;).&lt;/p&gt;</description>
    </item>
    <item>
      <title>Local Packet Filtering with IPv6</title>
      <link>https://insinuator.net/2017/07/local-packet-filtering-with-ipv6/</link>
      <pubDate>Thu, 06 Jul 2017 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2017/07/local-packet-filtering-with-ipv6/</guid>
      <description>&lt;p&gt;Just recently we discussed IPv6 filter rules for NIC-level firewalls (in a virtualized data center) with a customer. I’d like to take this as an opportunity to lay out potential approaches for local packet filtering of IPv6, which in turn might somewhat depend on the address configuration strategy chosen for the respective systems (for the latter you may refer to &lt;a href=&#34;https://insinuator.net/2016/12/ipv6-configuration-approaches-for-servers/&#34;&gt;this post&lt;/a&gt; or to &lt;a href=&#34;https://www.ernw.de/download/ERNW_TR17_NGI_IPv6_Config_Approach_Servers.pdf&#34;&gt;this talk&lt;/a&gt; from the &lt;a href=&#34;https://www.troopers.de/troopers17/ngi/&#34;&gt;Troopers NGI event&lt;/a&gt;).&lt;/p&gt;&#xA;&lt;p&gt;Some of this has already been discussed in &lt;a href=&#34;https://www.ietf.org/rfc/rfc4890.txt&#34;&gt;RFC 4890 Recommendations for Filtering ICMPv6 Messages in Firewalls&lt;/a&gt; but that document is from 2007 and things may have changed in the interim.&lt;br&gt;&#xA;Let’s start with a quick look at the traffic which might be of interest. We will take a server perspective here, read: which types of IPv6 traffic might have to be accepted by a host/NIC firewall in order to support proper operations? I will discuss the following, with a focus on the implications of filtering them locally:&lt;/p&gt;</description>
    </item>
    <item>
      <title>RIPE74 / Why IPv6 Security Is So Hard</title>
      <link>https://insinuator.net/2017/05/ripe74-/-why-ipv6-security-is-so-hard/</link>
      <pubDate>Fri, 12 May 2017 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2017/05/ripe74-/-why-ipv6-security-is-so-hard/</guid>
      <description>&lt;p&gt;I’m on my way back from the &lt;a href=&#34;https://ripe74.ripe.net/&#34;&gt;RIPE74 meeting in Budapest&lt;/a&gt;. It was a great event: quite a few nice technical talks in the plenary, productive working group meetings and some really good hallway discussions.&lt;br&gt;&#xA;Big thanks to the RIPE NCC team for the smooth organization and for taking care of us!&lt;/p&gt;&#xA;&lt;p&gt;Here’s some stuff I found particularly interesting:&lt;/p&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;Andrew Alston’s take on “Anti-Shutdown Policies” (&lt;a href=&#34;https://ripe74.ripe.net/presentations/34-anti-shutdown-ripe.pdf&#34;&gt;slides&lt;/a&gt; and &lt;a href=&#34;https://ripe74.ripe.net/archives/video/41/&#34;&gt;video&lt;/a&gt; incl. extensive mic discussion)&lt;/li&gt;&#xA;&lt;li&gt;&lt;a href=&#34;https://twitter.com/pberndro&#34;&gt;Philip&lt;/a&gt; &amp;amp; &lt;a href=&#34;https://twitter.com/BarbarossaTM&#34;&gt;Maximilian&lt;/a&gt; from &lt;a href=&#34;https://www.freifunk-rheinland.net/&#34;&gt;Freifunk Rheinland&lt;/a&gt; on their efforts (&lt;a href=&#34;https://ripe74.ripe.net/presentations/46-as201701-ripe74.pdf&#34;&gt;slides&lt;/a&gt;, &lt;a href=&#34;https://ripe74.ripe.net/archives/video/47/&#34;&gt;video&lt;/a&gt;)&lt;/li&gt;&#xA;&lt;li&gt;Friso Feenstra on “That’s Why Rabobank Implemented IPv6” (&lt;a href=&#34;https://ripe74.ripe.net/presentations/3-That-is-why-Rabobank-has-IPv6.pdf&#34;&gt;slides&lt;/a&gt;, video) plus some insight into their address planning (&lt;a href=&#34;https://ripe74.ripe.net/presentations/4-Rabobank-corporate-IPv6-numberplan.pdf&#34;&gt;slides&lt;/a&gt;, &lt;a href=&#34;https://ripe74.ripe.net/archives/video/101/&#34;&gt;video&lt;/a&gt;)&lt;/li&gt;&#xA;&lt;li&gt;BCOP work on “&lt;a href=&#34;https://ripe74.ripe.net/presentations/132-Jan_Zorz-IPv6-prefix-delegations-BCOP-v-2.pdf&#34;&gt;IPv6 Prefix Assignments/Prefix Delegation&lt;/a&gt;” and “&lt;a href=&#34;https://ripe74.ripe.net/presentations/40-jan_zorz_IPv6-for-hosting-providers.pdf&#34;&gt;IPv6 Assignments for Hosting Providers&lt;/a&gt;“&lt;/li&gt;&#xA;&lt;li&gt;&lt;a href=&#34;https://twitter.com/lundstromjerry&#34;&gt;Jerry Lundström&lt;/a&gt;‘s DNS Replay Tool (&lt;a href=&#34;https://ripe74.ripe.net/presentations/79-RIPE74-DNSWG-drool.pdf&#34;&gt;slides&lt;/a&gt;, &lt;a href=&#34;https://ripe74.ripe.net/archives/video/161/&#34;&gt;video&lt;/a&gt;, &lt;a href=&#34;https://github.com/DNS-OARC/drool&#34;&gt;code&lt;/a&gt;)&lt;/li&gt;&#xA;&lt;li&gt;Jan Žorž (supported by Sander Steffann) on NAT64 testing (&lt;a href=&#34;https://ripe74.ripe.net/presentations/133-Jan_Zorz-NAT64-Check-v3.4.pdf&#34;&gt;slides&lt;/a&gt;, &lt;a href=&#34;https://ripe74.ripe.net/archives/video/160/&#34;&gt;video&lt;/a&gt;, &lt;a href=&#34;https://github.com/sjm-steffann/nat64check&#34;&gt;code&lt;/a&gt;)&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;p&gt;These were my own contributions:&lt;/p&gt;</description>
    </item>
    <item>
      <title>Some Quick Tips for Submitting a Talk to Black Hat or TROOPERS</title>
      <link>https://insinuator.net/2017/04/some-quick-tips-for-submitting-a-talk-to-black-hat-or-troopers/</link>
      <pubDate>Sat, 01 Apr 2017 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2017/04/some-quick-tips-for-submitting-a-talk-to-black-hat-or-troopers/</guid>
      <description>&lt;p&gt;Given the &lt;a href=&#34;https://www.blackhat.com/us-17/call-for-papers.html&#34;&gt;CfP for Black Hat US&lt;/a&gt; in Vegas ends in a few days – and as apparently &lt;a href=&#34;https://twitter.com/HashtagCyber/status/846093463120678913&#34;&gt;some&lt;/a&gt; &lt;a href=&#34;https://twitter.com/christruncer/status/845213468269662209&#34;&gt;people&lt;/a&gt; have already started to think about their TR18 submissions – I’ll quickly provide some loose recommendations on how to write a submission here. There’s quite some reasonable advice out there already (the BH CfP site lists &lt;a href=&#34;https://www.helpnetsecurity.com/2016/03/30/how-to-get-your-talk-accepted-at-black-hat/&#34;&gt;this&lt;/a&gt; and &lt;a href=&#34;http://hexsec.blogspot.de/2012/12/create-good-security-cfp-responses.html&#34;&gt;this&lt;/a&gt; which you should both read as well) but some of you might find it useful to get (yet) another perspective.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Testing RFC 6980 Implementations with Chiron</title>
      <link>https://insinuator.net/2017/03/testing-rfc-6980-implementations-with-chiron/</link>
      <pubDate>Sat, 11 Mar 2017 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2017/03/testing-rfc-6980-implementations-with-chiron/</guid>
      <description>&lt;p&gt;In the &lt;a href=&#34;https://insinuator.net/2017/01/ipv6-properties-of-windows-server-2016-windows-10/&#34;&gt;recent post&lt;/a&gt; on the IPv6 properties of the latest MS Windows versions I announced another one providing details on the &lt;a href=&#34;https://tools.ietf.org/rfc/rfc6980.txt&#34;&gt;RFC 6980&lt;/a&gt; related testing I had performed. So here we go.&lt;/p&gt;&#xA;&lt;p&gt;When doing IPv6 security testing there’s mainly four toolkits which can be used:&lt;/p&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;&lt;a href=&#34;https://twitter.com/AntoniosAtlasis&#34;&gt;Antonios Atlasis&lt;/a&gt;‘ &lt;a href=&#34;https://www.secfu.net/tools-scripts/&#34;&gt;Chiron&lt;/a&gt;&lt;/li&gt;&#xA;&lt;li&gt;Marc Heuse’s &lt;a href=&#34;https://github.com/vanhauser-thc/thc-ipv6&#34;&gt;THC-IPV6&lt;/a&gt;&lt;/li&gt;&#xA;&lt;li&gt;&lt;a href=&#34;https://twitter.com/FernandoGont&#34;&gt;Fernando Gont&lt;/a&gt;‘s &lt;a href=&#34;https://www.si6networks.com/tools/ipv6toolkit/&#34;&gt;IPv6 Toolkit&lt;/a&gt;&lt;/li&gt;&#xA;&lt;li&gt;&lt;a href=&#34;http://www.secdev.org/projects/scapy/&#34;&gt;Scapy&lt;/a&gt; (whose IPv6 capabilities are, afaik, mainly maintained by &lt;a href=&#34;https://twitter.com/guedou&#34;&gt;Guillaume Valadon&lt;/a&gt;. some tutorial on IPv6 packet crafting with scapy can &lt;a href=&#34;https://www.ernw.de/download/Advanced%20Attack%20Techniques%20against%20IPv6%20Networks-final.pdf&#34;&gt;be found here&lt;/a&gt;).&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;p&gt;Each of them has specific strenghts &amp;amp; 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.&lt;/p&gt;</description>
    </item>
    <item>
      <title>IPv6 Properties of Windows Server 2016 / Windows 10</title>
      <link>https://insinuator.net/2017/01/ipv6-properties-of-windows-server-2016-/-windows-10/</link>
      <pubDate>Mon, 30 Jan 2017 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2017/01/ipv6-properties-of-windows-server-2016-/-windows-10/</guid>
      <description>&lt;p&gt;In this post we’ll take a detailed look at the properties of the Windows Server 2016 IPv6 stack.&lt;br&gt;&#xA;I perform(ed) this exercise for several reasons:&lt;/p&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;Server 2016 is the latest OS released by Microsoft so this might give an indication as for their plans &amp;amp; strategy when it comes to supporting certain specifications.&lt;br&gt;&#xA;(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…).&lt;/li&gt;&#xA;&lt;li&gt;as I laid out &lt;a href=&#34;https://insinuator.net/2016/12/ipv6-configuration-approaches-for-servers/&#34;&gt;in this post&lt;/a&gt; the configuration approach an organization takes for their servers might depend on the support of specific features.&lt;/li&gt;&#xA;&lt;li&gt;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 &lt;a href=&#34;https://www.ernw.de/download/ERNW_Whitepaper_IPv6_RAs_RDNSS_DHCPv6_Conflicting_Parameters.pdf&#34;&gt;this&lt;/a&gt; or &lt;a href=&#34;https://www.ernw.de/download/newsletter/ERNW_Whitepaper57_IPv6_lab_source_address_selection_signed.pdf&#34;&gt;this&lt;/a&gt; in the past).&lt;/li&gt;&#xA;&lt;li&gt;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.&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;p&gt;&lt;strong&gt;Version&lt;/strong&gt;&lt;/p&gt;</description>
    </item>
    <item>
      <title>IPv6 Configuration Approaches for Servers</title>
      <link>https://insinuator.net/2016/12/ipv6-configuration-approaches-for-servers/</link>
      <pubDate>Wed, 21 Dec 2016 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2016/12/ipv6-configuration-approaches-for-servers/</guid>
      <description>&lt;p&gt;In this post I’ll discuss configuration approaches for systems which usually have been configured with “static” IP parameters in the IPv4 age/context (like servers in data centers). When it comes to IPv6 there are more options and we’ll have a look at their implications and potential advantages/disadvantages.&lt;/p&gt;&#xA;&lt;p&gt;From my perspective there’s mainly four possible approaches which we see being implemented or considered in our (predominantly enterprise) customer space. Before we have a closer look at those let’s quickly write down requirements that the involved planners or sysadmins might have in mind when it comes to provisioning the systems in question. Some of those requirements might seem obvious but it could still make sense to note them for the discussion to follow. These might include:&lt;/p&gt;</description>
    </item>
    <item>
      <title>Considerations on DMZ Design in 2016, Part 3: Some Notes on Firewall Rule Management</title>
      <link>https://insinuator.net/2016/11/considerations-on-dmz-design-in-2016-part-3-some-notes-on-firewall-rule-management/</link>
      <pubDate>Mon, 21 Nov 2016 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2016/11/considerations-on-dmz-design-in-2016-part-3-some-notes-on-firewall-rule-management/</guid>
      <description>&lt;p&gt;This is the 3rd part of this loose series on considerations of (operating) DMZs in 2016 (part 1 on the role of a DMZ is can be found &lt;a href=&#34;https://insinuator.net/2016/08/considerations-on-dmz-design-in-2016-part-1/&#34;&gt;here&lt;/a&gt;, part 2 on reverse proxies &lt;a href=&#34;https://insinuator.net/2016/09/considerations-on-dmz-design-in-2016-part-2-a-quick-digression-on-reverse-proxies/&#34;&gt;here&lt;/a&gt;).&lt;br&gt;&#xA;Again, I dare to deviate a bit from the plan &amp;amp; order I initially had in mind – today I will cover one process whose maturity may significantly influence the overall security posture of a DMZ environment: firewall rule management.&lt;/p&gt;</description>
    </item>
    <item>
      <title>(Securely) Updating Smart Devices / Some Considerations</title>
      <link>https://insinuator.net/2016/11/securely-updating-smart-devices-/-some-considerations/</link>
      <pubDate>Tue, 15 Nov 2016 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2016/11/securely-updating-smart-devices-/-some-considerations/</guid>
      <description>&lt;p&gt;How to provide updates to IoT devices – yes, I’m aware this might be a overly broad generalization for many different devices – has been the topic of many discussions in the last years (for those interested the papers from the “&lt;a href=&#34;https://www.iab.org/activities/workshops/iotsu/&#34;&gt;Internet of Things Software Update Workshop (IoTSU)&lt;/a&gt;” might be a good starting point).&lt;br&gt;&#xA;Given Matthias and I will moderate the respective session at tomorrow’s &lt;a href=&#34;https://www.troopers.de/iot-insight-summit-2016/iot-insight-summit-2016-overview/&#34;&gt;IoT Insight Summit&lt;/a&gt; I started writing down some points that we consider relevant in this context.&lt;/p&gt;</description>
    </item>
    <item>
      <title>IPv6 Source Address Selection</title>
      <link>https://insinuator.net/2016/11/ipv6-source-address-selection/</link>
      <pubDate>Wed, 02 Nov 2016 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2016/11/ipv6-source-address-selection/</guid>
      <description>&lt;p&gt;As we all know an IPv6 enabled host can have multiple addresses. In order to select a source address for a to-be established outbound connection, operating systems implement a source address selection mechanism that evaluates multiple source address candidates and selects the (potentially) best candidate. Criteria for this selection are defined in &lt;a href=&#34;https://tools.ietf.org/rfc/rfc6724.txt&#34;&gt;RFC6724&lt;/a&gt; (which obsoletes RFC 3484).&lt;/p&gt;&#xA;&lt;p&gt;To find out if there are differences as for the way various OSs implement this mechanism we performed a little study whose results can be found in &lt;a href=&#34;https://www.ernw.de/download/newsletter/ERNW_Whitepaper57_IPv6_lab_source_address_selection_signed.pdf&#34;&gt;this whitepaper&lt;/a&gt;. Those differences might be particularly relevant for data center environments or enterprise networks with a variety of heterogeneous client operating systems. If interested in IPv6 in enterprise networks &lt;a href=&#34;https://hm-ts.de/de/1-deutschsprachige-seminare/14-ipv6-in-enterprise-networks20160227140531.html&#34;&gt;this training&lt;/a&gt; that I’ll give in some weeks might be worth attending for some of you, too.&lt;/p&gt;</description>
    </item>
    <item>
      <title>To Control Something</title>
      <link>https://insinuator.net/2016/09/to-control-something/</link>
      <pubDate>Sat, 10 Sep 2016 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2016/09/to-control-something/</guid>
      <description>&lt;p&gt;Some years ago I discussed the meaning of the term “control” in &lt;a href=&#34;https://www.insinuator.net/2011/06/broken-trust-part-1-definitions-fundamentals-some-more-reflections-on-rsa/&#34;&gt;this post&lt;/a&gt;, but at the time I was mainly referring to the noun “control”. Given I’ll extensively use the term “control” as a verb in the next parts of “the &lt;a href=&#34;https://www.insinuator.net/2016/08/considerations-on-dmz-design-in-2016-part-1/&#34;&gt;DMZ&lt;/a&gt; &lt;a href=&#34;https://www.insinuator.net/2016/09/considerations-on-dmz-design-in-2016-part-2-a-quick-digression-on-reverse-proxies/&#34;&gt;series&lt;/a&gt;” and some &lt;a href=&#34;http://hardwear.io/schedule_hardwear/&#34;&gt;upcoming&lt;/a&gt; &lt;a href=&#34;http://www.day-con.org/schedule.htm&#34;&gt;talks&lt;/a&gt; I reflected a bit on its meaning (as a verb). In the following I’ll lay out the definition/understanding to be employed at those occasions.&lt;/p&gt;&#xA;&lt;p&gt;&lt;a href=&#34;http://www.merriam-webster.com/dictionary/control&#34;&gt;Merriam-Webster&lt;/a&gt; defines, amongst others, as follows:&lt;/p&gt;</description>
    </item>
    <item>
      <title>Considerations on DMZ Design in 2016, Part 2: A Quick Digression on Reverse Proxies</title>
      <link>https://insinuator.net/2016/09/considerations-on-dmz-design-in-2016-part-2-a-quick-digression-on-reverse-proxies/</link>
      <pubDate>Thu, 08 Sep 2016 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2016/09/considerations-on-dmz-design-in-2016-part-2-a-quick-digression-on-reverse-proxies/</guid>
      <description>&lt;p&gt;This is the second part of a series with considerations on DMZ networks in 2016 (part 1 can be found &lt;a href=&#34;https://www.insinuator.net/2016/08/considerations-on-dmz-design-in-2016-part-1/&#34;&gt;here&lt;/a&gt;). Beforehand I had planned to cover classification &amp;amp; segmentation approaches in this one, but after my little rant on how “the business” might approach &amp;amp; think about reverse proxies in the first part, I felt tempted to elaborate a bit further on this particular topic. I kindly ask for your patience 😉 and will digress a bit for the moment.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Considerations on DMZ Design in 2016, Part 1</title>
      <link>https://insinuator.net/2016/08/considerations-on-dmz-design-in-2016-part-1/</link>
      <pubDate>Sat, 27 Aug 2016 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2016/08/considerations-on-dmz-design-in-2016-part-1/</guid>
      <description>&lt;p&gt;I’m currently involved in a “DMZ Redesign” effort in a sufficiently large enterprise (800+ hosts in “the DMZ”) and I thought this might be an opportunity to reflect on some aspects of “DMZ networks” in a series of posts.&lt;/p&gt;&#xA;&lt;p&gt;Some of you already know that, at &lt;a href=&#34;https://www.ernw.de/&#34;&gt;ERNW&lt;/a&gt;, we have a tendency to discuss stuff starting with some formal definitions and a bit of abstract (overview) approach. It’s not different this time ;-), so let’s first find out what the term “DMZ” means, what such a thing is considered to be and to deliver, and what the actual state of affairs might be in 2016. Different people within an organization might have quite different understandings in this space.&lt;br&gt;&#xA;Further it’s entirely possible that the DMZ networks are not operated by a company themselves but by an outsourcing partner which then means that “placing a system in the DMZ” becomes “ordering a DMZ [network] port” by means of some web-based procedure or ticket system, which in turn might have a number of interesting implications (we’ll have a dedicated post on those).&lt;/p&gt;</description>
    </item>
    <item>
      <title>Follow-Up on CVE-2016-1409 – IPv6 NDP DoS Vulnerability</title>
      <link>https://insinuator.net/2016/08/follow-up-on-cve-2016-1409-ipv6-ndp-dos-vulnerability/</link>
      <pubDate>Sun, 21 Aug 2016 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2016/08/follow-up-on-cve-2016-1409-ipv6-ndp-dos-vulnerability/</guid>
      <description>&lt;p&gt;This is a guest post from &lt;a href=&#34;https://twitter.com/kafetzj&#34;&gt;Jed Kafetz&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;p&gt;After seeing &lt;a href=&#34;https://www.insinuator.net/2016/05/cve-2016-1409-ipv6-ndp-dos-vulnerability-in-cisco-software/&#34;&gt;Christopher’s post&lt;/a&gt; I decided to create a proof using GNS3 and Virtualbox.&lt;br&gt;&#xA;The aim is to perform the exact attacking using Antonios Atlasis’ &lt;a href=&#34;http://www.secfu.net/tools-scripts/&#34;&gt;Chiron tools&lt;/a&gt; and run a Wireshark packet capture to prove the hop limit drops below 255.&lt;/p&gt;&#xA;&lt;p&gt;The following topology is used in GNS3:&lt;/p&gt;&#xA;&lt;p&gt;&lt;img src=&#34;https://www.insinuator.net/wp-content/uploads/2016/08/nw_diagram.png&#34; alt=&#34;nw_diagram&#34;&gt;The routers used are Cisco C372 and the machine labled Ubuntu is running 14.04 LTS Ubuntu Desktop, default installation. F0/0 is on the right and F0/1 is on the left.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Not Sure Which Talks to Attend at BHUSA?</title>
      <link>https://insinuator.net/2016/07/not-sure-which-talks-to-attend-at-bhusa/</link>
      <pubDate>Fri, 29 Jul 2016 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2016/07/not-sure-which-talks-to-attend-at-bhusa/</guid>
      <description>&lt;p&gt;Hi,&lt;/p&gt;&#xA;&lt;p&gt;I won’t be in Vegas for Black Hat this year as there’s a direct conflict with one of my kids’ birthdays, but I thought one or another reader might find it helpful to get some inspiration as for selecting the talks to catch (not least as there’s so many interesting ones). I hence decided to quickly write this post.&lt;/p&gt;&#xA;&lt;p&gt;Here’s my would-be schedule for the first day (second day to follow, maybe, in another post), under the assumption to attend exactly one talk per slot. I could give a longer rationale per talk than the one below, based on several (mostly technical) factors, but this is just about providing suggestions in a brief form.&lt;br&gt;&#xA;Disclaimer: I was on the &lt;a href=&#34;https://www.blackhat.com/review-board.html&#34;&gt;BH guest review board&lt;/a&gt; this year so I might be biased in some cases.&lt;/p&gt;</description>
    </item>
    <item>
      <title>IPv6 &amp; Threat Intelligence</title>
      <link>https://insinuator.net/2016/06/ipv6-threat-intelligence/</link>
      <pubDate>Fri, 03 Jun 2016 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2016/06/ipv6-threat-intelligence/</guid>
      <description>&lt;p&gt;Tomorrow, I will join a meeting where I’m expected to contribute, amongst others, to a discussion on the impact of IPv6 on threat intelligence. To prepare for that I started putting together some thoughts &amp;amp; ideas on the topic, and I even thought I might share this in a post (the one you read right now ;-), not least to, maybe, stimulate a discussion.&lt;/p&gt;&#xA;&lt;p&gt;I don’t know much about threat intelligence so it might happen that, at times, I use some misguided terms or I expose a (too) naïve understanding of some concepts. Happy to be corrected in one way or another.&lt;/p&gt;</description>
    </item>
    <item>
      <title>The Beauty of IPv6 Link-Local Addressing. Not</title>
      <link>https://insinuator.net/2016/05/the-beauty-of-ipv6-link-local-addressing.-not/</link>
      <pubDate>Sat, 28 May 2016 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2016/05/the-beauty-of-ipv6-link-local-addressing.-not/</guid>
      <description>&lt;p&gt;In November 2014, after quite some controversy in the IETF OPSEC working group (for those interested look at the &lt;a href=&#34;http://www.ietf.org/mail-archive/web/opsec/current/maillist.html&#34;&gt;archives&lt;/a&gt;), the &lt;em&gt;Informational&lt;/em&gt; &lt;a href=&#34;https://tools.ietf.org/rfc/rfc7404.txt&#34;&gt;RFC 7404&lt;/a&gt; “Using Only Link-Local Addressing inside an IPv6 Network” was published. It is authored by &lt;a href=&#34;http://blogs.cisco.com/author/michaelbehringer&#34;&gt;Michael Behringer&lt;/a&gt; and &lt;a href=&#34;https://twitter.com/evyncke&#34;&gt;Eric Vyncke&lt;/a&gt; and discusses the advantages &amp;amp; disadvantages of an approach using “only link-local addresses on infrastructure links between routers”.&lt;/p&gt;&#xA;&lt;p&gt;So it’s (merely) about “infrastructure links” which some people call “transit networks” or “point to point” (ptp) links. I’m aware that there might be subtle differences between all these, depending on your specific use of the terms. Still I assume that most readers will have an understanding of what types of links are in focus of the RFC, and subsequently of this post.&lt;/p&gt;</description>
    </item>
    <item>
      <title>draft-vyncke-pim-mld-security</title>
      <link>https://insinuator.net/2016/04/draft-vyncke-pim-mld-security/</link>
      <pubDate>Mon, 04 Apr 2016 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2016/04/draft-vyncke-pim-mld-security/</guid>
      <description>&lt;p&gt;Right now, I’m in Buenos Aires for IETF95 where, amongst others, an Internet-Draft authored by &lt;a href=&#34;http://www.ciscopress.com/authors/bio/51D11BF7-F351-4ED9-995E-E0F5CB6C009D&#34;&gt;Eric Vyncke&lt;/a&gt;, &lt;a href=&#34;http://www.secfu.net/about-me/&#34;&gt;Antonios Atlasis&lt;/a&gt; and myself will be presented (and hopefully discussed) in two working groups. In the following I want to quickly lay out why we think this is an important contribution.&lt;/p&gt;&#xA;&lt;p&gt;As some of you may remember about two years ago we started an internal research project on the IPv6 “helper procotol” &lt;em&gt;Multicast Listener Discovery&lt;/em&gt; (MLD) and its security properties. One outcome of this research project was &lt;a href=&#34;https://twitter.com/anantary&#34;&gt;Jayson Salazar&lt;/a&gt;‘s excellent thesis on the topic (the full document &lt;a href=&#34;https://www.its.fh-muenster.de/doc/Security_Implications_of_MLD_in_IPv6_Networks.pdf&#34;&gt;can be found here&lt;/a&gt;), another outcome were the related talks we gave at DeepSec 2014 and at &lt;a href=&#34;https://www.troopers.de/media/filer_public/7c/35/7c35967a-d0d4-46fb-8a3b-4c16df37ce59/troopers15_ipv6secsummit_atlasis_rey_salazar_mld_considered_harmful_final.pdf&#34;&gt;Troopers15&lt;/a&gt;.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Dual Stack vs. IPv6-only in Enterprise Networks</title>
      <link>https://insinuator.net/2016/02/dual-stack-vs.-ipv6-only-in-enterprise-networks/</link>
      <pubDate>Wed, 17 Feb 2016 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2016/02/dual-stack-vs.-ipv6-only-in-enterprise-networks/</guid>
      <description>&lt;p&gt;I had the pleasure to sit in Mark Townsley “&lt;a href=&#34;https://clnv.s3.amazonaws.com/2015/usa/pdf/BRKRST-2616.pdf&#34;&gt;Addressing Networking Challenges With Latest Innovations in IPv6&lt;/a&gt;” session at Cisco Live yesterday and – somewhat inevitably – there was a mention of Facebook having implemented an IPv6-only approach in their data centers (&lt;a href=&#34;https://www.youtube.com/watch?v=An7s25FSK0U&#34;&gt;here’s a talk&lt;/a&gt; from Paul Saab/FB laying out details). So, with the &lt;a href=&#34;https://cisco.rainfocus.com/scripts/catalog/cleu16.jsp?search=pnlcrs-2307&#34;&gt;“IPv6 Panel”&lt;/a&gt; looming, I started reflecting on “Why don’t we see this in our customer space?”. This post quickly summarizes some observations and thoughts.&lt;/p&gt;</description>
    </item>
    <item>
      <title>IPv6 Address Planning in 2016 / Observations</title>
      <link>https://insinuator.net/2016/02/ipv6-address-planning-in-2016-/-observations/</link>
      <pubDate>Sun, 14 Feb 2016 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2016/02/ipv6-address-planning-in-2016-/-observations/</guid>
      <description>&lt;p&gt;Hi,&lt;/p&gt;&#xA;&lt;p&gt;I’ll be on the “&lt;a href=&#34;https://cisco.rainfocus.com/scripts/catalog/cleu16.jsp?search=pnlcrs-2307&#34;&gt;IPv6 Panel&lt;/a&gt;” at &lt;a href=&#34;http://www.ciscolive.com/emea/&#34;&gt;Cisco Live&lt;/a&gt; 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 &amp;amp; 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…&lt;br&gt;&#xA;For today let’s start with some comments on IPv6 address planning.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Developing an Enterprise IPv6 Security Strategy / Part 6: Controls on the Host Level</title>
      <link>https://insinuator.net/2016/02/developing-an-enterprise-ipv6-security-strategy-/-part-6-controls-on-the-host-level/</link>
      <pubDate>Tue, 02 Feb 2016 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2016/02/developing-an-enterprise-ipv6-security-strategy-/-part-6-controls-on-the-host-level/</guid>
      <description>&lt;p&gt;In this part of the series (for the other parts see &lt;a href=&#34;https://www.insinuator.net/2015/12/developing-an-enterprise-ipv6-security-strategy-part-1-baseline-analysis-of-ipv4-network-security/&#34;&gt;[1]&lt;/a&gt;, &lt;a href=&#34;https://www.insinuator.net/2015/12/developing-an-enterprise-ipv6-security-strategy-part-2-network-isolation-on-the-routing-layer/&#34;&gt;[2]&lt;/a&gt;, &lt;a href=&#34;https://www.insinuator.net/2015/12/developing-an-enterprise-ipv6-security-strategy-part-3-traffic-filtering-in-ipv6-networks-i/&#34;&gt;[3]&lt;/a&gt;, &lt;a href=&#34;https://www.insinuator.net/2015/12/developing-an-enterprise-ipv6-security-strategy-part-4-traffic-filtering-in-ipv6-networks-ii/&#34;&gt;[4]&lt;/a&gt;, &lt;a href=&#34;https://www.insinuator.net/2015/12/developing-an-enterprise-ipv6-security-strategy-part-5-first-hop-security-features/&#34;&gt;[5]&lt;/a&gt;) we’ll discuss approaches to implement security measures suited to protect from IPv6-related threats on the host level.&lt;/p&gt;&#xA;&lt;p&gt;These can be grouped into the following generic categories each of which will be described in more detail in the following:&lt;/p&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;“Minimal machine” approach&lt;/li&gt;&#xA;&lt;li&gt;Static configuration of IPv6 parameters&lt;/li&gt;&#xA;&lt;li&gt;Tweaking the behavior of IPv6-related mechanisms/protocols&lt;/li&gt;&#xA;&lt;li&gt;Local packet filtering&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;p&gt;Some of you might recall that we published IPv6 hardening guides for both &lt;a href=&#34;https://www.ernw.de/download/ERNW_Guide_to_Securely_Configure_Linux_Servers_For_IPv6_v1_0.pdf&#34;&gt;Linux&lt;/a&gt; and &lt;a href=&#34;https://www.ernw.de/download/ERNW_Guide_to_Configure_Securely_Windows_Servers_For_IPv6_v1_0.pdf&#34;&gt;Windows&lt;/a&gt; a while ago and we’ll reference those exact documents below, by [Hard_Linux] and [Hard_Windows] respectively.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Things to Consider When Starting Your IPv6 Deployment</title>
      <link>https://insinuator.net/2016/01/things-to-consider-when-starting-your-ipv6-deployment/</link>
      <pubDate>Mon, 11 Jan 2016 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2016/01/things-to-consider-when-starting-your-ipv6-deployment/</guid>
      <description>&lt;p&gt;Hi,&lt;/p&gt;&#xA;&lt;p&gt;today I’m going to suspend the “&lt;a href=&#34;https://www.insinuator.net/tag/ipv6/&#34;&gt;Developing an Enterprise IPv6 Security Strategy&lt;/a&gt;” series for a moment and discuss some other aspects of IPv6 deployment.&lt;br&gt;&#xA;We’ve been involved in a number of IPv6 projects in large organizations in the past few years and in many of those there was a &lt;a href=&#34;https://www.ernw.de/download/ERNW_IPv6_Today_Tomorrow.pdf&#34;&gt;planning phase in which several documents were created&lt;/a&gt; (often these include a road map, an address concept/plan and a security concept).&lt;br&gt;&#xA;Point is: at some point it’s getting real ;-), read: IPv6 is actually enabled on some systems. Pretty much all enterprise customers we know start(ed) their IPv6 deployment “at the perimeter”, enabling IPv6 (usually in dual-stack mode) on some systems/services facing the Internet and/or external parties.&lt;br&gt;&#xA;Unfortunately there’s a number of (seemingly small) things that can go wrong in this phase and “little errors” made today are probably meant to stay for a long time (in German we have the nice phrase “Nichts ist so dauerhaft wie ein Provisorium”, and I’m sure people with an IT operations background will understand this even without a translator…).&lt;br&gt;&#xA;In this post I will hence lay out some things to consider when you enable IPv6 on perimeter elements for the first time.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Developing an Enterprise IPv6 Security Strategy / Part 5: First Hop Security Features</title>
      <link>https://insinuator.net/2015/12/developing-an-enterprise-ipv6-security-strategy-/-part-5-first-hop-security-features/</link>
      <pubDate>Thu, 31 Dec 2015 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2015/12/developing-an-enterprise-ipv6-security-strategy-/-part-5-first-hop-security-features/</guid>
      <description>&lt;p&gt;In the previous parts of this series (&lt;a href=&#34;https://www.insinuator.net/2015/12/developing-an-enterprise-ipv6-security-strategy-part-1-baseline-analysis-of-ipv4-network-security/&#34;&gt;part 1&lt;/a&gt;, &lt;a href=&#34;https://www.insinuator.net/2015/12/developing-an-enterprise-ipv6-security-strategy-part-2-network-isolation-on-the-routing-layer/&#34;&gt;part 2&lt;/a&gt;, &lt;a href=&#34;https://www.insinuator.net/2015/12/developing-an-enterprise-ipv6-security-strategy-part-3-traffic-filtering-in-ipv6-networks-i/&#34;&gt;part 3&lt;/a&gt;, &lt;a href=&#34;https://www.insinuator.net/2015/12/developing-an-enterprise-ipv6-security-strategy-part-4-traffic-filtering-in-ipv6-networks-ii/&#34;&gt;part 4&lt;/a&gt;) we covered several aspects of IPv6 security, mainly on the infrastructure level. In today’s post I will follow up by briefly discussing so-called &lt;em&gt;First Hop Security&lt;/em&gt; features.&lt;/p&gt;&#xA;&lt;p&gt;IPv6 &lt;em&gt;First Hop Security&lt;/em&gt; (“IPv6 FHS”) is a collection of features (initially implemented, and named, by Cisco but available on other platforms too) that can be found on many access layer switches to prevent different attacks in IPv6 networks. The availability of those features is sometimes divided into three phases and started in 2010 with the release of IOS images containing mainly &lt;em&gt;RA Guard&lt;/em&gt; (see below) and port-based IPv6 ACLs. Phase two was released in early 2012 and contained some more features (namely from the “IPv6 Snooping” framework) whereas phase three was released at the end of 2012 and contained some more advanced features (e.g. &lt;em&gt;IPv6 Source Guard&lt;/em&gt;). Nowadays usually “phase one” features are supported on many platforms, at least on physical ones (&lt;a href=&#34;https://www.troopers.de/media/filer_public/9c/76/9c76bcf0-9653-4d70-9b3d-0d38bbfb2c5e/tr15_ipv6_security_summit_fhs_virtualized_environments_v10.pdf&#34;&gt;support on virtual switches is still somewhat lacking&lt;/a&gt;).&lt;br&gt;&#xA;There’s an excellent &lt;a href=&#34;http://docwiki.cisco.com/wiki/FHS&#34;&gt;Cisco FHS Wiki&lt;/a&gt; maintained by &lt;a href=&#34;https://twitter.com/ayourtch&#34;&gt;Andrew Yourtchenko&lt;/a&gt;, &lt;a href=&#34;https://twitter.com/SCOTTHOGG&#34;&gt;Scott Hogg&lt;/a&gt; wrote a &lt;a href=&#34;http://www.gtri.com/ipv6-neighbor-discovery-keep-calm-and-ipv6-on/&#34;&gt;good overview&lt;/a&gt;, as &lt;a href=&#34;http://blog.ipspace.net/2013/07/first-hop-ipv6-security-features-in.html&#34;&gt;did Ivan Pepelnjak&lt;/a&gt;, and &lt;a href=&#34;http://www.rmv6tf.org/wp-content/uploads/2013/04/5-IPv6-Attacks-and-Countermeasures-v1.2.pdf&#34;&gt;this is a nice presentation&lt;/a&gt; on some elements by Jim Small from 2013. Still, from our perspective the main question is: which of those features should be deployed in production networks/can be observed in real-life enterprise networks. Actually it’s only two:&lt;/p&gt;</description>
    </item>
    <item>
      <title>#TR16 IPv6 Security Summit – New Talks Added</title>
      <link>https://insinuator.net/2015/12/%23tr16-ipv6-security-summit-new-talks-added/</link>
      <pubDate>Wed, 23 Dec 2015 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2015/12/%23tr16-ipv6-security-summit-new-talks-added/</guid>
      <description>&lt;p&gt;In the interim we’ve worked on the agenda of next year’s &lt;em&gt;&lt;a href=&#34;https://www.troopers.de/ipv6-security-summit/&#34;&gt;IPv6 Security Summit&lt;/a&gt;&lt;/em&gt; (for those not familiar with the event, &lt;a href=&#34;https://www.troopers.de/events/troopers15/322_ipv6_security_summit/&#34;&gt;here’s the 2015 edition&lt;/a&gt; and &lt;a href=&#34;https://www.troopers.de/events/troopers14/372_ipv6_security_summit/&#34;&gt;here the one of 2014&lt;/a&gt;), and some new talks have been added.&lt;/p&gt;&#xA;&lt;p&gt;&lt;strong&gt;Rafael Schaefer: Advanced IPv6 Attacks Using Chiron. Hands-On Workshop&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;Outline: During the IPv6 Security Summit at Troopers 14, &lt;a href=&#34;http://www.secfu.net/tools-scripts/&#34;&gt;Chiron&lt;/a&gt;, an all-in-one IPv6 penetration testing framework was released publicly for first time. Since then, the advanced features of Chiron were used to discover some 0-day evasion techniques against high-end commercial and open-source Intrusion Detection / Prevention Systems. Moreover, for Troopers 15 it was enhanced with new features, like advanced MLD support and a fake DHCPv6 server, which can be combined with its other features, like the use of arbitrary Extension Headers and fragmentation to leverage really advanced attacks.&lt;br&gt;&#xA;In this workshop, after a quick refreshing to the basic capabilities of Chiron, we will focus on the advanced IPv6 functionalities that the framework offers. We will not only show how to reproduce the latest published IPv6 attacks, but moreover, how you can create your own arbitrary IPv6 attacking scenarios for your own security assessments or penetration testing purposes. A lab will be set up in order not only to reproduce the presented techniques, but to also try your skills and – why not – to discover your own 0-day techniques :).&lt;/p&gt;</description>
    </item>
    <item>
      <title>Developing an Enterprise IPv6 Security Strategy / Part 4: Traffic Filtering in IPv6 Networks (II)</title>
      <link>https://insinuator.net/2015/12/developing-an-enterprise-ipv6-security-strategy-/-part-4-traffic-filtering-in-ipv6-networks-ii/</link>
      <pubDate>Tue, 22 Dec 2015 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2015/12/developing-an-enterprise-ipv6-security-strategy-/-part-4-traffic-filtering-in-ipv6-networks-ii/</guid>
      <description>&lt;p&gt;In this part of our little series (&lt;a href=&#34;https://www.insinuator.net/2015/12/developing-an-enterprise-ipv6-security-strategy-part-1-baseline-analysis-of-ipv4-network-security/&#34;&gt;part 1&lt;/a&gt;, &lt;a href=&#34;https://www.insinuator.net/2015/12/developing-an-enterprise-ipv6-security-strategy-part-2-network-isolation-on-the-routing-layer/&#34;&gt;part 2&lt;/a&gt;, &lt;a href=&#34;https://www.insinuator.net/2015/12/developing-an-enterprise-ipv6-security-strategy-part-3-traffic-filtering-in-ipv6-networks-i/&#34;&gt;part 3&lt;/a&gt;) we continue discussing IPv6 specific filtering of network traffic, namely at intersection points.&lt;/p&gt;&#xA;&lt;p&gt;As stated in the 1st part, a number of potential security problems in IPv6 networks are related to Extension Headers of IPv6, in particular when combined with fragmentation. At the same time, as of today (December 2015) there is no Internet service or application that actually needs those headers.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Developing an Enterprise IPv6 Security Strategy / Part 3: Traffic Filtering in IPv6 Networks (I)</title>
      <link>https://insinuator.net/2015/12/developing-an-enterprise-ipv6-security-strategy-/-part-3-traffic-filtering-in-ipv6-networks-i/</link>
      <pubDate>Mon, 14 Dec 2015 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2015/12/developing-an-enterprise-ipv6-security-strategy-/-part-3-traffic-filtering-in-ipv6-networks-i/</guid>
      <description>&lt;p&gt;So this is the third part of our little series on securing IPv6 in enterprise environments. In the &lt;a href=&#34;https://www.insinuator.net/2015/12/developing-an-enterprise-ipv6-security-strategy-part-1-baseline-analysis-of-ipv4-network-security/&#34;&gt;first part&lt;/a&gt; we tried to develop an understanding of threats in IPv4 networks as a kind-of baseline while analyzing the main differences induced by IPv6 and in the &lt;a href=&#34;https://www.insinuator.net/2015/12/developing-an-enterprise-ipv6-security-strategy-part-2-network-isolation-on-the-routing-layer/&#34;&gt;second part&lt;/a&gt; we laid out protection strategies on the infrastructure level, focusing on network isolation on the routing layer. Today I’ll dive into discussing IPv6-specific filtering of network traffic.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Developing an Enterprise IPv6 Security Strategy / Part 2: Network Isolation on the Routing Layer</title>
      <link>https://insinuator.net/2015/12/developing-an-enterprise-ipv6-security-strategy-/-part-2-network-isolation-on-the-routing-layer/</link>
      <pubDate>Mon, 07 Dec 2015 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2015/12/developing-an-enterprise-ipv6-security-strategy-/-part-2-network-isolation-on-the-routing-layer/</guid>
      <description>&lt;p&gt;In the &lt;a href=&#34;https://www.insinuator.net/2015/12/developing-an-enterprise-ipv6-security-strategy-part-1-baseline-analysis-of-ipv4-network-security/&#34;&gt;first part&lt;/a&gt; of this series we tried to identify which risks related to network-related threats actually change when IPv6 gets deployed and hence which ones to take care of in a prioritized manner (as opposed to those which one might be tempted to [initially] disregard with a “has been there in IPv4 already and we did not address it then, why now?” stance). Let’s assume we went through this step and, for those most relevant risks we identified, we want to come up with infrastructure level controls first, before tackling controls to be deployed on the host level (as in many organizations the sysowners of “hosts” like servers in datacenters tend to expect “the network/infrastructure guys to provide the 1st layer of defense against threats”, in particular once those originate from an apparent network layer protocol, that is IPv6).&lt;/p&gt;</description>
    </item>
    <item>
      <title>Developing an Enterprise IPv6 Security Strategy / Part 1: Baseline Analysis of IPv4 Network Security</title>
      <link>https://insinuator.net/2015/12/developing-an-enterprise-ipv6-security-strategy-/-part-1-baseline-analysis-of-ipv4-network-security/</link>
      <pubDate>Wed, 02 Dec 2015 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2015/12/developing-an-enterprise-ipv6-security-strategy-/-part-1-baseline-analysis-of-ipv4-network-security/</guid>
      <description>&lt;p&gt;We’ve been involved in some activities in this space recently and I thought it could be a good idea to share a couple of things we’ve discussed &amp;amp; displayed. Furthermore some time ago – in the &lt;em&gt;&lt;a href=&#34;https://www.insinuator.net/2015/06/is-ipv6-more-secure-than-ipv4-or-less/&#34;&gt;Is IPv6 more Secure than IPv4? Or Less?&lt;/a&gt;&lt;/em&gt; post – I announced to come up with (something like) an “IPv6 threats &amp;amp; controls catalogue” at some point… so here we go: in an upcoming series of a few blogposts I will lay out some typical elements of an “Enterprise IPv6 Security Strategy” incl. several technical pieces (and I plan to give a talk on the exact topic at next year’s &lt;a href=&#34;https://www.troopers.de/ipv6-security-summit/&#34;&gt;IPv6 Security Summit&lt;/a&gt;).&lt;/p&gt;</description>
    </item>
    <item>
      <title>Some Notes on the “Drop IPv6 Fragments” vs. “This Will Break DNS[SEC]” Debate</title>
      <link>https://insinuator.net/2015/11/some-notes-on-the-drop-ipv6-fragments-vs.-this-will-break-dnssec-debate/</link>
      <pubDate>Tue, 03 Nov 2015 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2015/11/some-notes-on-the-drop-ipv6-fragments-vs.-this-will-break-dnssec-debate/</guid>
      <description>&lt;p&gt;Some readers will probably be aware that we are amongst the proponents of a quite strict stance when it comes to filtering IPv6 packets with (certain) Extension Headers and/or fragmentation, because those can be the source of many security problems (as laid out &lt;a href=&#34;https://www.ernw.de/download/eu-14-Atlasis-Rey-Schaefer-briefings-Evasion-of-HighEnd-IPS-Devices-wp.pdf&#34;&gt;here&lt;/a&gt;, &lt;a href=&#34;http://gsec.hitb.org/materials/sg2015/D3%20-%20Marc%20Heuse%20-%20Hiding%20in%20Complexity.pdf&#34;&gt;here&lt;/a&gt; or &lt;a href=&#34;https://www.insinuator.net/2015/01/evasion-of-cisco-acls-by-abusing-ipv6-discussion-of-mitigation-techniques/&#34;&gt;here&lt;/a&gt;). Actually I still think it was a very good idea of, amongst others, Randy Bush and Ron Bonica to &lt;a href=&#34;https://tools.ietf.org/id/draft-bonica-6man-frag-deprecate-02.txt&#34;&gt;suggest the deprecation of IPv6 fragmentation in the IETF&lt;/a&gt;.&lt;br&gt;&#xA;On the other hand there are voices arguing that fragmented IPv6 packets will be needed in some cases, namely DNS[SEC]-related ones.&lt;br&gt;&#xA;In this post I will discuss some details of this debate (taking place in many circles, incl. &lt;a href=&#34;http://lists.si6networks.com/pipermail/ipv6hackers/2015-October/thread.html&#34;&gt;this thread&lt;/a&gt; on the &lt;em&gt;ipv6-hackers&lt;/em&gt; mailing list which, btw, &lt;a href=&#34;http://lists.si6networks.com/listinfo/ipv6hackers/&#34;&gt;you should subscribe to&lt;/a&gt;).&lt;/p&gt;</description>
    </item>
    <item>
      <title>The Strange Case of $SOME_SOFTWARE Adding an IPv6 Extension Header, and an Internet Router Dropping Them</title>
      <link>https://insinuator.net/2015/10/the-strange-case-of-some_software-adding-an-ipv6-extension-header-and-an-internet-router-dropping-them/</link>
      <pubDate>Mon, 05 Oct 2015 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2015/10/the-strange-case-of-some_software-adding-an-ipv6-extension-header-and-an-internet-router-dropping-them/</guid>
      <description>&lt;p&gt;Last week Christopher and I were the instructors of &lt;a href=&#34;http://www.hmtrainingsolutions.com/de/1-seminar/87-ipv6-in-enterprise-networks141205170415.html&#34;&gt;an IPv6 workshop&lt;/a&gt;. In this one we usually build a lab with the participants incl. a variety of routed segments and native IPv6 Internet access. Once the latter part is implemented people start poking around and surfing the Internet from their laptops, not least to find out which sites they can actually reach from an v6-only network (please note that actually &lt;a href=&#34;http://w3techs.com/technologies/breakdown/ce-ipv6/ranking&#34;&gt;there are many&lt;/a&gt;).&lt;/p&gt;</description>
    </item>
    <item>
      <title>Sending Mixed Signals – What Can Happen in the Course of Vulnerability Disclosure</title>
      <link>https://insinuator.net/2015/09/sending-mixed-signals-what-can-happen-in-the-course-of-vulnerability-disclosure/</link>
      <pubDate>Thu, 10 Sep 2015 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2015/09/sending-mixed-signals-what-can-happen-in-the-course-of-vulnerability-disclosure/</guid>
      <description>&lt;p&gt;&lt;strong&gt;Update:&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;Given there’s quite some speculation and, as we think, misinformation going around we think it’s helpful to add/clarify the following information:&lt;/p&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;we fully comply with the injunction and we have no intentions to violate it. we do not plan to publish any technical information besides the report (agreed upon with FireEye themselves) and the slides (based on the former) anyway. No 3rd parties except for the ones involved (FireEye, lawyers) have received any additional technical information from our side, let alone an earlier version of the report.&lt;/li&gt;&#xA;&lt;li&gt;the injunction covers accompanying details mostly within the architecture space, but not the core vulnerabilities themselves. Those are not part of the injunction.&lt;/li&gt;&#xA;&lt;li&gt;we stand by the timeline as provided below. In particular, the following two points:&lt;br&gt;&#xA;– FireEye received a draft version of the report which had the objectionable material (as identified by the cease and desist letter) fully removed on August 11th.&lt;br&gt;&#xA;– according to the cease and desist letter FireEye’s lawyer sent us, they were informed – from our side – about the planned talk at 44CON on Jul 23rd.&lt;/li&gt;&#xA;&lt;li&gt;there’s an injunction, but not a lawsuit. I used the term “sue” after consulting &lt;a href=&#34;http://www.merriam-webster.com/dictionary/sue&#34;&gt;Merriam-Webster&lt;/a&gt; which states: “sue: to seek justice or right from (a person) by legal process”, but this might have been misinterpreted by some readers. As stated, there’s a pending injunction, but not a lawsuit.&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;p&gt;Please note that we won’t share legal documents with 3rd parties or publish them as we consider this inappropriate.&lt;br&gt;&#xA;Please note further that, during the whole process, our goal was to perform a responsible disclosure procedure with its inherent objectives (namely vulnerability remediation by vendor and education of various stakeholders involved, see also &lt;a href=&#34;https://www.ernw.de/download/ERNW_Newsletter_50_Vulnerability_Disclosure_Reflections_CaseStudy.pdf&#34;&gt;here&lt;/a&gt; or &lt;a href=&#34;https://www.insinuator.net/2015/07/reflections-on-vulnerability-disclosure/&#34;&gt;here&lt;/a&gt;). We consider this disclosure process as concluded. We don’t see a need to add technical details from our side as we feel that the objectives of responsible disclosure are met (not least as patches are released since quite some time and both &lt;a href=&#34;https://www.fireeye.com/content/dam/fireeye-www/support/pdfs/fireeye-ernw-vulnerability.pdf&#34;&gt;vendor&lt;/a&gt; &amp;amp; finder have released reports).&lt;/p&gt;</description>
    </item>
    <item>
      <title>Black Hat Talks &amp; Papers related to Windows/Active Directory Security</title>
      <link>https://insinuator.net/2015/08/black-hat-talks-papers-related-to-windows/active-directory-security/</link>
      <pubDate>Fri, 07 Aug 2015 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2015/08/black-hat-talks-papers-related-to-windows/active-directory-security/</guid>
      <description>&lt;p&gt;This year’s Black Hat US saw a number of quite interesting talks in the context of Windows or Active Directory Security. For those of you too lazy to search for themselves 😉 and for our own Windows/AD Sec team (who couldn’t send anyone to Vegas due to heavy project load) I’ve compiled a little list of those.&lt;/p&gt;&#xA;&lt;p&gt;&lt;a href=&#34;https://twitter.com/pdjstone&#34;&gt;Paul Stone&lt;/a&gt; &amp;amp; &lt;a href=&#34;https://twitter.com/NoxrNet&#34;&gt;Alex Chapman&lt;/a&gt;: WSUSPect – Compromising the Windows Enterprise via Windows Update&lt;br&gt;&#xA;Slides &lt;a href=&#34;https://www.blackhat.com/docs/us-15/materials/us-15-Stone-WSUSpect-Compromising-Windows-Enterprise-Via-Windows-Update.pdf&#34;&gt;here&lt;/a&gt;.&lt;br&gt;&#xA;Whitepaper &lt;a href=&#34;http://www.contextis.com/media/documents/CTX_WSUSpect_White_Paper.pdf&#34;&gt;here&lt;/a&gt;. (Attention: on the BH website there’s an older this. the above link leads to the latest one).&lt;/p&gt;</description>
    </item>
    <item>
      <title>IPv6 Hackers Meeting @ IETF 93 in Prague</title>
      <link>https://insinuator.net/2015/07/ipv6-hackers-meeting-@-ietf-93-in-prague/</link>
      <pubDate>Wed, 29 Jul 2015 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2015/07/ipv6-hackers-meeting-@-ietf-93-in-prague/</guid>
      <description>&lt;p&gt;After the &lt;a href=&#34;http://www.insinuator.net/2013/08/ipv6-hackers-meeting-ietf-87-in-berlin-slides/&#34;&gt;first “IPv6 Hackers Meeting”&lt;/a&gt; held two years ago in Berlin, &lt;a href=&#34;https://twitter.com/FernandoGont&#34;&gt;Fernando Gont&lt;/a&gt; kindly organized a &lt;a href=&#34;http://www.ipv6hackers.org/home&#34;&gt;similar event in Prague&lt;/a&gt; last week.&lt;/p&gt;&#xA;&lt;p&gt;Although a bit on short notice it was a good meeting with interesting discussions. I contributed with shortened versions of two talks we had delivered in the past:&lt;/p&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;the “&lt;a href=&#34;https://www.ernw.de/download/Atlasis_Rey_Schaefer_IETF93_IPv6Hackers_Evasion_of_HighEnd_IPS_Devices.pdf&#34;&gt;Evasion of High-End IDPS Devices at the IPv6 Era&lt;/a&gt;” talk which &lt;a href=&#34;https://twitter.com/AntoniosAtlasis&#34;&gt;Antonios&lt;/a&gt;, Rafael and I had given at Black Hat US &amp;amp; Europe 2014. The accompanying white paper with the exact details &lt;a href=&#34;https://www.ernw.de/download/eu-14-Atlasis-Rey-Schaefer-briefings-Evasion-of-HighEnd-IPS-Devices-wp.pdf&#34;&gt;can be found here&lt;/a&gt;; the tool Chiron &lt;a href=&#34;http://www.secfu.net/tools-scripts/&#34;&gt;here&lt;/a&gt; (and a tutorial &lt;a href=&#34;https://www.ernw.de/download/Chiron_Tutorial.pdf&#34;&gt;here&lt;/a&gt;).&lt;/li&gt;&#xA;&lt;li&gt;the “MLD Considered Harmful” talk that Antonios, &lt;a href=&#34;https://twitter.com/anantary&#34;&gt;Jayson&lt;/a&gt; and I had presented at the &lt;a href=&#34;https://www.troopers.de/events/troopers15/322_ipv6_security_summit/&#34;&gt;Troopers IPv6 Security Summit 2015&lt;/a&gt;. The mentioned Internet-Draft on MLD security which &lt;a href=&#34;https://www.vyncke.org/ipv6status/&#34;&gt;Eric Vyncke&lt;/a&gt;, Antonios and myself are working on can be &lt;a href=&#34;https://tools.ietf.org/html/draft-vyncke-pim-mld-security-00&#34;&gt;found here&lt;/a&gt;. We’re happy to receive any feedback on that one.&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;p&gt;Special thanks go to &lt;a href=&#34;http://www.internetsociety.org/who-we-are/staff/mr-jan-%C5%BEor%C5%BE&#34;&gt;Jan Zorz&lt;/a&gt; and to &lt;a href=&#34;http://www.nic.cz/&#34;&gt;CZ.NIC&lt;/a&gt; for hosting us and providing refreshments. Much appreciated, guys!&lt;/p&gt;</description>
    </item>
    <item>
      <title>Reflections on Vulnerability Disclosure</title>
      <link>https://insinuator.net/2015/07/reflections-on-vulnerability-disclosure/</link>
      <pubDate>Tue, 14 Jul 2015 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2015/07/reflections-on-vulnerability-disclosure/</guid>
      <description>&lt;p&gt;In this post I’ll discuss some aspects of vulnerability disclosure. I don’t want to delve into an abstract &amp;amp; general discussion of vulnerability disclosure (for those interested &lt;a href=&#34;http://googleprojectzero.blogspot.de/2015/02/feedback-and-data-driven-updates-to.html&#34;&gt;here’s some discussion&lt;/a&gt; in the context of Google’s Project Zero, &lt;a href=&#34;http://www.cert.org/vulnerability-analysis/vul-disclosure.cfm&#34;&gt;this is the well-known CERT/CC approach&lt;/a&gt;, &lt;a href=&#34;http://weis2006.econinfosec.org/docs/17.pdf&#34;&gt;this a paper from WEIS 2006&lt;/a&gt; laying out some variants, and finally &lt;a href=&#34;https://www.schneier.com/essays/archives/2007/01/schneier_full_disclo.html&#34;&gt;some statement by Bruce Schneier back in 2007&lt;/a&gt;). Instead I will lay out which approach we followed in the past (and why we did so) and which developments make us consider it necessary to re-think our way of handling. The post is not meant to provide definitive answers; it was also written not least to provide clarity for ourselves (“write down a problem in order to better penetrate it”) and, maybe, to serve as a starting point for a discussion which will help the community (and us) to find a position on some of the inherent challenges.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Evasion of Cisco ACLs by (Ab)Using IPv6 – Part 2</title>
      <link>https://insinuator.net/2015/07/evasion-of-cisco-acls-by-abusing-ipv6-part-2/</link>
      <pubDate>Wed, 08 Jul 2015 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2015/07/evasion-of-cisco-acls-by-abusing-ipv6-part-2/</guid>
      <description>&lt;p&gt;When we wrote our initial blogpost regarding the &lt;a href=&#34;http://www.insinuator.net/2015/01/evasion-of-cisco-acls-by-abusing-ipv6-discussion-of-mitigation-techniques/&#34;&gt;evasion of Cisco ACLs by (Ab)Using IPv6&lt;/a&gt;, where we described (&lt;a href=&#34;http://www.insinuator.net/2015/01/the-persistent-problem-of-state-in-ipv6-security/&#34;&gt;known to Cisco&lt;/a&gt;) cases of Access Control Lists (ACL) circumvention, we also suggested some mitigation techniques including the blocking of some (if not all) IPv6 Extension Headers.&lt;br&gt;&#xA;Almost a month later, we got &lt;a href=&#34;http://www.insinuator.net/2015/01/evasion-of-cisco-acls-by-abusing-ipv6-discussion-of-mitigation-techniques/#respond&#34;&gt;a comment&lt;/a&gt; from &lt;em&gt;Matej Gregr&lt;/em&gt; that, even if the ACLs of certain Cisco Switches are configured to block IPv6 Extension headers like Hop-by-Hop or Destination Options headers, this does not actually happen/work as expected. Of course this made us re-visit the lab in the interim ;-).&lt;/p&gt;</description>
    </item>
    <item>
      <title>IPv6 Adress Planning / Some Notes</title>
      <link>https://insinuator.net/2015/06/ipv6-adress-planning-/-some-notes/</link>
      <pubDate>Tue, 16 Jun 2015 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2015/06/ipv6-adress-planning-/-some-notes/</guid>
      <description>&lt;p&gt;In the course of a customer project I recently documented some thoughts and general objectives of IPv6 address planning, expanding on stuff I wrote a while ago in the &lt;a href=&#34;http://www.insinuator.net/2014/05/ipv6-address-plan-considerations-part-3-the-plan/&#34;&gt;series on “Address Plan Considerations”&lt;/a&gt;. An excerpt of that (newer) document &lt;a href=&#34;https://www.ernw.de/download/ERNW_IPv6_Adressplanung.pdf&#34;&gt;can be found here&lt;/a&gt;. Due to the context it originates from it’s in German, still I hope it’s useful for some readers.&lt;br&gt;&#xA;If you’re interested in the topic it might be a good idea to listen to &lt;a href=&#34;https://twitter.com/ipv6tom&#34;&gt;Tom Coffeen&lt;/a&gt;‘s talk at the upcoming &lt;a href=&#34;http://www.ipv6conference.ch/sessions/&#34;&gt;IPv6 Business Conference&lt;/a&gt;, too.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Is IPv6 more Secure than IPv4? Or Less?</title>
      <link>https://insinuator.net/2015/06/is-ipv6-more-secure-than-ipv4-or-less/</link>
      <pubDate>Mon, 08 Jun 2015 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2015/06/is-ipv6-more-secure-than-ipv4-or-less/</guid>
      <description>&lt;p&gt;&lt;a href=&#34;http://www.hoggnet.com/&#34;&gt;Scott Hogg&lt;/a&gt; recently (in his post “&lt;a href=&#34;https://community.infoblox.com/blogs/2015/02/10/holding-ipv6-neighbor-discovery-higher-standard-security&#34;&gt;Holding IPv6 Neighbor Discovery to a Higher Standard of Security&lt;/a&gt;“) gave the following answer:&lt;/p&gt;&#xA;&lt;p&gt;“The security of IPv4 is roughly equivalent to IPv6. So why do we expect more from IPv6?”&lt;/p&gt;&#xA;&lt;p&gt;While I highly value Scott’s IPv6 expertise – not least because I learned a lot about IPv6 security from &lt;a href=&#34;http://www.ciscopress.com/store/ipv6-security-9781587055942&#34;&gt;the book on the topic&lt;/a&gt; he wrote together with &lt;a href=&#34;https://www.vyncke.org/ipv6status/&#34;&gt;Eric Vyncke&lt;/a&gt; – I strongly disagree with his statement, mainly with the first part. In this post I will lay out why I think that IPv6 is actually &lt;em&gt;less&lt;/em&gt; secure than IPv4.&lt;/p&gt;</description>
    </item>
    <item>
      <title>IPv6 &amp; Complexity</title>
      <link>https://insinuator.net/2015/05/ipv6-complexity/</link>
      <pubDate>Wed, 27 May 2015 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2015/05/ipv6-complexity/</guid>
      <description>&lt;p&gt;IPv6 is often called a “complex protocol”, not least by myself (for example in my &lt;a href=&#34;https://www.troopers.de/media/filer_public/42/1a/421a0a30-0a35-486a-b25e-7eea27f18ef7/troopers14-why_ipv6_security_is_so_hard-structural_deficits_of_ipv6_and_their_implications-enno_rey.pdf&#34;&gt;keynote to the IPv6 Security Summit 2014&lt;/a&gt;). In this post I want to have a quick look at three questions:&lt;/p&gt;&#xA;&lt;p&gt;– Can IPv6 be considered a “complex protocol”?&lt;br&gt;&#xA;– Is it “more complex” than IPv4?&lt;br&gt;&#xA;– Can we expect IPv6 networks to be “complex networks”?&lt;/p&gt;&#xA;&lt;p&gt;I’d like to start with some clarifications and a definition. First of all: when I discuss IPv6 “as a protocol”, this actually means “the IPv6 procotol family” incl. those helper protocols needed to support (“core”) IPv6 in performing properly in most networks, like ICMPv6 and MLD.&lt;br&gt;&#xA;Then, of course, we have to define the term “complexity”, which is a difficult task in itself. [MITCHELL2009] gives an overview of several potential (definition) approaches in a dedicated chapter and the same undertaking is performed – in quite different ways – by most of the authors of individual contributions to [PELITI1988].&lt;/p&gt;</description>
    </item>
    <item>
      <title>RIPE70 in Amsterdam</title>
      <link>https://insinuator.net/2015/05/ripe70-in-amsterdam/</link>
      <pubDate>Sun, 24 May 2015 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2015/05/ripe70-in-amsterdam/</guid>
      <description>&lt;p&gt;Two weeks ago Christopher and I joined the RIPE70 meeting in Amsterdam. Being part of the group was fun as always and we had quite some interesting conversations with peers from the IPv6 community.&lt;/p&gt;&#xA;&lt;p&gt;We could even contribute a bit to some discussions, with two talks. I gave one titled “Will It Be Routed? – On IPv6 Address Space Allocation &amp;amp; Assignment Approaches in Very Large Organizations” in the Address Policy Working Group session on Wednesday. This is the abstract:&lt;/p&gt;</description>
    </item>
    <item>
      <title>OS IPv6 Behavior in Conflicting Environments</title>
      <link>https://insinuator.net/2015/04/os-ipv6-behavior-in-conflicting-environments/</link>
      <pubDate>Thu, 30 Apr 2015 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2015/04/os-ipv6-behavior-in-conflicting-environments/</guid>
      <description>&lt;p&gt;I was invited by the &lt;a href=&#34;http://www.swissipv6council.ch/&#34;&gt;Swiss IPv6 Council&lt;/a&gt; to give a talk on this topic yesterday. We had good conversations after the talk – thanks for the invitation!&lt;/p&gt;&#xA;&lt;p&gt;For those interested the slides &lt;a href=&#34;https://www.ernw.de/download/ERNW_IPv6_Behavior_Conflicting_Environments_20150430.pdf&#34;&gt;can be found here&lt;/a&gt;. I will happily discuss the intricacies of DHCPv6 and how to deploy it in complex environments at the upcoming &lt;a href=&#34;http://www.ipv6conference.ch/&#34;&gt;IPv6 Business Conference&lt;/a&gt; in Zurich and in my “&lt;a href=&#34;http://www.hmtrainingsolutions.com/de/seminare/1-seminar/88-ipv6-in-enterprise-networks141205170702.html&#34;&gt;IPv6 in Enterprise Networks&lt;/a&gt;” training in Berlin.&lt;/p&gt;&#xA;&lt;p&gt;Have a great day everybody&lt;/p&gt;</description>
    </item>
    <item>
      <title>SI6 Networks’ IPv6 Toolkit v2.0 (Guille) released at the Troopers IPv6 Security Summit</title>
      <link>https://insinuator.net/2015/04/si6-networks-ipv6-toolkit-v2.0-guille-released-at-the-troopers-ipv6-security-summit/</link>
      <pubDate>Sun, 05 Apr 2015 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2015/04/si6-networks-ipv6-toolkit-v2.0-guille-released-at-the-troopers-ipv6-security-summit/</guid>
      <description>&lt;p&gt;This is a guest post from &lt;a href=&#34;https://twitter.com/FernandoGont&#34;&gt;Fernando Gont&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;p&gt;On March 16^(th), 2015, at the Troopers &lt;a href=&#34;https://www.troopers.de/events/troopers15/322_ipv6_security_summit/&#34;&gt;IPv6 Security Summit&lt;/a&gt;, we finally released the SI6 Networks’ IPv6 Toolkit v2.0 (Guille). The aforementioned release is now available at the &lt;a href=&#34;http://www.si6networks.com/tools/ipv6toolkit&#34;&gt;SI6 IPv6 Toolkit homepage&lt;/a&gt;. It is the result of over a year of work, and includes improvements in the following areas:&lt;/p&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;Increased portability&lt;/li&gt;&#xA;&lt;li&gt;Bug fixes&lt;/li&gt;&#xA;&lt;li&gt;Additional features in existing tools&lt;/li&gt;&#xA;&lt;li&gt;Brand-new tools&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;p&gt;Increased Portability&lt;/p&gt;&#xA;&lt;p&gt;One of the goals that the SI6 Toolkit had since its inception is that of portability. The SI6 Toolkit has supported all major BSD-derived OSes, Linux, and Mac OS for a number of years now. And this new release supports yet another new platform: OpenSolaris. We believe that besides supporting a greater user base, increased portability ultimately results in improved code quality.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Troopers15 Videos Online</title>
      <link>https://insinuator.net/2015/03/troopers15-videos-online/</link>
      <pubDate>Sat, 28 Mar 2015 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2015/03/troopers15-videos-online/</guid>
      <description>&lt;p&gt;We’ve just published the videos from TROOPERS15. The playlist can be found &lt;a href=&#34;https://www.youtube.com/playlist?list=PL1eoQr97VfJkfckz9nZFR7tZoBkjij23f&#34;&gt;here&lt;/a&gt;.&lt;br&gt;&#xA;Thanks! again to everybody for joining us in Heidelberg. We had a great time with you 😉&lt;/p&gt;&#xA;&lt;p&gt;Have a good weekend,&lt;/p&gt;&#xA;&lt;p&gt;Enno&lt;/p&gt;&#xA;&lt;p&gt; &lt;/p&gt;</description>
    </item>
    <item>
      <title>Final Agenda of Troopers15 TelcoSecDay</title>
      <link>https://insinuator.net/2015/03/final-agenda-of-troopers15-telcosecday/</link>
      <pubDate>Tue, 10 Mar 2015 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2015/03/final-agenda-of-troopers15-telcosecday/</guid>
      <description>&lt;p&gt;Admitted, we’re a bit late this time, but here we go with the agenda of this year’s TelcoSecDay.&lt;/p&gt;&#xA;&lt;p&gt;Given the high number of quality contributions overall there’s more talks than in the previous years and we’ll hence start more early (and finish later 🙂 ), so please plan accordingly.&lt;br&gt;&#xA;This is the agenda, details for the invididual talks can be found in the respective links:&lt;/p&gt;&#xA;&lt;p&gt;8:30-9:00 Opening &amp;amp; Intro&lt;br&gt;&#xA;9:00-9:45 &lt;a href=&#34;http://www.insinuator.net/2015/02/troopers-15-telcosecday-first-talks/&#34;&gt;Luca Bruno: Through the Looking-Glass, and What Eve Found There&lt;/a&gt;&lt;br&gt;&#xA;9:45-10:30 &lt;a href=&#34;http://www.insinuator.net/2015/02/troopers-telcosecday-next-talks/&#34;&gt;Dieter Spaar: How to Assess M2M Communication from an Attacker’s Perspective&lt;/a&gt;&lt;br&gt;&#xA;Break&lt;br&gt;&#xA;11:00-11:45 &lt;a href=&#34;http://www.insinuator.net/2015/02/troopers-15-telcosecday-first-talks/&#34;&gt;Tobias Engel: Securing the SS7 Interconnect&lt;/a&gt;&lt;br&gt;&#xA;11:45-12:30 &lt;a href=&#34;http://www.insinuator.net/2015/02/troopers-telcosecday-next-talks/&#34;&gt;Ravishankar Borgaonkar: TelcoSecurity Mirage: 1G to 5G&lt;/a&gt;&lt;br&gt;&#xA;12:30-13:00 &lt;a href=&#34;http://www.insinuator.net/2015/02/troopers-telcosecday-next-talks-ii/&#34;&gt;Hendrik Schmidt: Security Aspects of VoLTE&lt;/a&gt;&lt;br&gt;&#xA;Lunch&lt;br&gt;&#xA;14:00-14:45 &lt;a href=&#34;http://www.insinuator.net/2015/02/another-talk-added-to-troopers15-telcosecday/&#34;&gt;Rob Kuiters: On her majesty’s secret service – GRX and a Spy Agency&lt;/a&gt;&lt;br&gt;&#xA;14:45-15:30 &lt;a href=&#34;http://www.insinuator.net/2015/02/troopers-telcosecday-next-talks-ii/&#34;&gt;“Watching the Watchers”&lt;/a&gt;&lt;br&gt;&#xA;Break&lt;br&gt;&#xA;16:00-16:45 &lt;a href=&#34;http://www.insinuator.net/2015/02/troopers-15-telcosecday-first-talks/&#34;&gt;Markus Vervier: Borrowing Mobile Network Identities – Just Because We Can&lt;/a&gt;&lt;br&gt;&#xA;16:45-17:15 &lt;a href=&#34;http://www.insinuator.net/2015/02/troopers-telcosecday-next-talks-ii/&#34;&gt;Shahar Tal: I hunt TR-069 admins – CWMP Insecurity&lt;/a&gt;&lt;br&gt;&#xA;Refreshment&lt;br&gt;&#xA;17:30-18:00 Sébastien Roche (Orange): tba&lt;/p&gt;</description>
    </item>
    <item>
      <title>IPv6 Router Advertisement Flags, RDNSS and DHCPv6 Conflicting Configurations</title>
      <link>https://insinuator.net/2015/03/ipv6-router-advertisement-flags-rdnss-and-dhcpv6-conflicting-configurations/</link>
      <pubDate>Mon, 09 Mar 2015 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2015/03/ipv6-router-advertisement-flags-rdnss-and-dhcpv6-conflicting-configurations/</guid>
      <description>&lt;p&gt;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.&lt;/p&gt;&#xA;&lt;p&gt;In short, it’s a mess. Again, &lt;a href=&#34;http://queue.acm.org/detail.cfm?id=1999945&#34;&gt;RFC ambiguity&lt;/a&gt; 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.&lt;/p&gt;&#xA;&lt;p&gt;The detailed results can be found &lt;a href=&#34;https://www.ernw.de/download/ERNW_Whitepaper_IPv6_RAs_RDNSS_DHCPv6_Conflicting_Parameters.pdf&#34;&gt;in this paper&lt;/a&gt;. We hope to contribute to a better understanding of IPv6 specifics. I mean, &lt;a href=&#34;https://www.ernw.de/download/ERNW_IPv6_Today_Tomorrow.pdf&#34;&gt;after all it’s here already&lt;/a&gt;.&lt;/p&gt;</description>
    </item>
    <item>
      <title>An MLD Testing Methodology</title>
      <link>https://insinuator.net/2015/03/an-mld-testing-methodology/</link>
      <pubDate>Fri, 06 Mar 2015 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2015/03/an-mld-testing-methodology/</guid>
      <description>&lt;p&gt;Based on recent research in the ERNW IPv6 lab and with &lt;a href=&#34;https://www.troopers.de/events/troopers15/467_mld_considered_harmful__breaking_another_ipv6_subprotocol/&#34;&gt;our MLD talk&lt;/a&gt; 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.&lt;/p&gt;</description>
    </item>
    <item>
      <title>A Chiron Workshop at the IPv6 Security Summit of Troopers 15</title>
      <link>https://insinuator.net/2015/03/a-chiron-workshop-at-the-ipv6-security-summit-of-troopers-15/</link>
      <pubDate>Wed, 04 Mar 2015 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2015/03/a-chiron-workshop-at-the-ipv6-security-summit-of-troopers-15/</guid>
      <description>&lt;p&gt;This is a guest post from &lt;a href=&#34;https://twitter.com/AntoniosAtlasis&#34;&gt;Antonios Atlasis&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;p&gt;&lt;a href=&#34;http://www.insinuator.net/2014/02/a-short-teaser-on-my-new-ipv6-testing-framework/&#34;&gt;Last year&lt;/a&gt;, during the &lt;a href=&#34;https://www.troopers.de/events/troopers14/372_ipv6_security_summit/&#34;&gt;IPv6 Security Summit&lt;/a&gt; of &lt;a href=&#34;https://www.troopers.de/archives/troopers14/&#34;&gt;Troopers 14&lt;/a&gt; I had the pleasure to present publicly, for first time, my IPv6 Penetration Testing / Security Assessment framework called &lt;a href=&#34;http://www.secfu.net/tools-scripts/&#34;&gt;&lt;em&gt;Chiron&lt;/em&gt;&lt;/a&gt;&lt;em&gt;,&lt;/em&gt; while later, it was also presented at &lt;a href=&#34;http://2014.brucon.org/index.php/&#34;&gt;Brucon 14&lt;/a&gt; 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 &lt;em&gt;Chiron&lt;/em&gt; at the &lt;a href=&#34;https://www.troopers.de/events/troopers15/322_ipv6_security_summit/&#34;&gt;IPv6 Security Summit&lt;/a&gt; of &lt;a href=&#34;https://www.troopers.de/troopers/&#34;&gt;Troopers 15&lt;/a&gt;. But, is it just another workshop with the known Chiron features or has something changed?&lt;br&gt;&#xA;I would say a lot :). The most significant enhancements are described below.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Bug Hunting for the Man on the Street</title>
      <link>https://insinuator.net/2015/03/bug-hunting-for-the-man-on-the-street/</link>
      <pubDate>Tue, 03 Mar 2015 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2015/03/bug-hunting-for-the-man-on-the-street/</guid>
      <description>&lt;p&gt;This is a guest post from Vladimir Wolstencroft, to provide some details of his upcoming &lt;a href=&#34;https://www.troopers.de/events/troopers15/499_bug_hunting_for_the_man_on_the_street/&#34;&gt;#TR15 talk&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;p&gt;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?&lt;br&gt;&#xA;Ownage, a good story and maybe even that bounty…&lt;/p&gt;&#xA;&lt;p&gt;Focusing on Barracuda’s numerous security appliances, this talk will detail bug hunting methods and the principles used to examine these machines:&lt;br&gt;&#xA;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…&lt;/p&gt;</description>
    </item>
    <item>
      <title>What to Do Today if You Want to Deploy IPv6 Tomorrow</title>
      <link>https://insinuator.net/2015/03/what-to-do-today-if-you-want-to-deploy-ipv6-tomorrow/</link>
      <pubDate>Tue, 03 Mar 2015 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2015/03/what-to-do-today-if-you-want-to-deploy-ipv6-tomorrow/</guid>
      <description>&lt;p&gt;Today I gave a talk with said title in a private setting. Assuming the content might be of interest for some of you, we published the slides &lt;a href=&#34;https://www.ernw.de/download/ERNW_IPv6_Today_Tomorrow.pdf&#34;&gt;here&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;p&gt;As always we’re happy to receive comments or feedback.&lt;br&gt;&#xA;Cheers&lt;/p&gt;&#xA;&lt;p&gt;Enno&lt;/p&gt;</description>
    </item>
    <item>
      <title>Another Talk Added to Troopers15 TelcoSecDay</title>
      <link>https://insinuator.net/2015/02/another-talk-added-to-troopers15-telcosecday/</link>
      <pubDate>Sat, 14 Feb 2015 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2015/02/another-talk-added-to-troopers15-telcosecday/</guid>
      <description>&lt;p&gt;We have pretty much finalized the agenda for the &lt;a href=&#34;https://www.troopers.de/troopers/&#34;&gt;Troopers&lt;/a&gt; TelcoSecDay and here’s another cool talk (the others can be found &lt;a href=&#34;http://www.insinuator.net/2015/02/troopers-15-telcosecday-first-talks/&#34;&gt;here&lt;/a&gt;, &lt;a href=&#34;http://www.insinuator.net/2015/02/troopers-telcosecday-next-talks/&#34;&gt;here&lt;/a&gt; and &lt;a href=&#34;http://www.insinuator.net/2015/02/troopers-telcosecday-next-talks-ii/&#34;&gt;here&lt;/a&gt;):&lt;/p&gt;&#xA;&lt;p&gt;&lt;strong&gt;Rob Kuiters: On her majesty’s secret service – GRX and a Spy Agency&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;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.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Troopers TelcoSecDay – Next Talks (II)</title>
      <link>https://insinuator.net/2015/02/troopers-telcosecday-next-talks-ii/</link>
      <pubDate>Thu, 12 Feb 2015 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2015/02/troopers-telcosecday-next-talks-ii/</guid>
      <description>&lt;p&gt;Hi,&lt;/p&gt;&#xA;&lt;p&gt;in addition to those &lt;a href=&#34;http://www.insinuator.net/2015/02/troopers-15-telcosecday-first-talks/&#34;&gt;recently announced&lt;/a&gt; and &lt;a href=&#34;http://www.insinuator.net/2015/02/troopers-telcosecday-next-talks/&#34;&gt;these&lt;/a&gt;, we’ve identified three more suitable talks for the TelcoSecDay &lt;img src=&#34;http://www.insinuator.net/wp-includes/images/smilies/icon_wink.gif&#34; alt=&#34;;-)&#34;&gt;.&lt;/p&gt;&#xA;&lt;p&gt;These are:&lt;/p&gt;&#xA;&lt;p&gt;&lt;strong&gt;Hendrik Schmidt: Security Aspects of VoLTE&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;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.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Troopers TelcoSecDay – Next Talks</title>
      <link>https://insinuator.net/2015/02/troopers-telcosecday-next-talks/</link>
      <pubDate>Tue, 10 Feb 2015 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2015/02/troopers-telcosecday-next-talks/</guid>
      <description>&lt;p&gt;Hi,&lt;/p&gt;&#xA;&lt;p&gt;in addition to those &lt;a href=&#34;http://www.insinuator.net/2015/02/troopers-15-telcosecday-first-talks/&#34;&gt;recently announced&lt;/a&gt; we’ve identified two more suitable talks for the TelcoSecDay 😉&lt;br&gt;&#xA;These are&lt;/p&gt;&#xA;&lt;p&gt;&lt;strong&gt;Ravishankar Borgaonkar – TelcoSecurity Mirage: 1G to 5G&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;Synopsis: The evolution of the mobile networking technology from 1G to 5G is driving the needs of our modern Digital Society. In this talk, we visit the security pillars of these technologies and discuss if 5G can strengthen them or not from an end-users perspective. In particular, we try to fill up security requirements for 5G networks based on the ongoing design direction.&lt;/p&gt;</description>
    </item>
    <item>
      <title>IPv6-related Requirements for Security Devices</title>
      <link>https://insinuator.net/2015/02/ipv6-related-requirements-for-security-devices/</link>
      <pubDate>Sun, 08 Feb 2015 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2015/02/ipv6-related-requirements-for-security-devices/</guid>
      <description>&lt;p&gt;This is the sequel to the similar post on “&lt;a href=&#34;http://www.insinuator.net/2015/01/ipv6-related-requirements-for-the-internet-uplink-or-mpls-networks/&#34;&gt;IPv6-related Requirements for the Internet Uplink or MPLS Networks&lt;/a&gt;“. As mentioned there these requirements were created in the course of an RfP for network security services. The goal of this document was to provide a check list of IPv6-related requirements that security devices being part of the individual providers’ offerings have to fulfill in order to fully support the future IPv6 network. &lt;/p&gt;</description>
    </item>
    <item>
      <title>Troopers 15 TelcoSecDay – First Talks</title>
      <link>https://insinuator.net/2015/02/troopers-15-telcosecday-first-talks/</link>
      <pubDate>Sat, 07 Feb 2015 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2015/02/troopers-15-telcosecday-first-talks/</guid>
      <description>&lt;p&gt;At &lt;a href=&#34;https://www.troopers.de/troopers/&#34;&gt;Troopers15&lt;/a&gt; there will be another TelcoSecDay, like in the years before (&lt;a href=&#34;https://www.troopers.de/events/troopers14/395_telcosec_day_2014_invitation_only/&#34;&gt;2014&lt;/a&gt;, &lt;a href=&#34;https://www.troopers.de/events/troopers13/406_telcosec_day_2013_invitation_only/&#34;&gt;2013&lt;/a&gt;, &lt;a href=&#34;https://www.troopers.de/events/troopers12/427_telcosec_day/&#34;&gt;2012&lt;/a&gt;). Here’s the first three talks (of overall 5-6):&lt;/p&gt;&#xA;&lt;p&gt;&lt;strong&gt;Luca Bruno: Through the Looking-Glass, and What Eve Found There&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;Synopsis: Traditionally, network operators have provided some kind of public read-only access to their current view of the BGP routing table, by the means of a “looking glass”.&lt;br&gt;&#xA;In this talk we inspect looking glass instances from a security point of view, showing many shortcomings and flaws which could let a malicious entity take control of critical devices connected to them. In particular, we will highlight how easy it is for a low-skilled attacker to gain access to core routers within multiple ISP infrastructures.&lt;/p&gt;</description>
    </item>
    <item>
      <title>IPv6 Hardening Guide for OS X</title>
      <link>https://insinuator.net/2015/02/ipv6-hardening-guide-for-os-x/</link>
      <pubDate>Wed, 04 Feb 2015 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2015/02/ipv6-hardening-guide-for-os-x/</guid>
      <description>&lt;p&gt;Similar to the documents we released &lt;a href=&#34;http://www.insinuator.net/2014/12/ipv6-hardening-guide-for-linux-servers/&#34;&gt;for Linux&lt;/a&gt; and &lt;a href=&#34;http://www.insinuator.net/2014/12/ipv6-hardening-guide-for-windows-servers/&#34;&gt;Windows&lt;/a&gt; (and actually inspired by a comment to the post on the Linux guide) &lt;a href=&#34;https://twitter.com/AntoniosAtlasis&#34;&gt;Antonios&lt;/a&gt; wrote another guide, this time for Mac OS X.&lt;/p&gt;&#xA;&lt;p&gt;It can &lt;a href=&#34;https://www.ernw.de/download/ERNW_Hardening_IPv6_MacOS-X_v1_0.pdf&#34;&gt;be found here&lt;/a&gt;. We hope some of you might find it helpful.&lt;br&gt;&#xA;Have a great day&lt;/p&gt;&#xA;&lt;p&gt;Enno&lt;/p&gt;&#xA;&lt;p&gt;PS: in the past we also made a &lt;a href=&#34;https://www.ernw.de/download/hardening/ERNW_Checklist_OSX_Hardening.pdf&#34;&gt;general Mac OS X hardening document available&lt;/a&gt; and we’ve discussed an additional patch &lt;a href=&#34;http://www.insinuator.net/2013/07/basic-os-x-hardening-dma/&#34;&gt;in this post&lt;/a&gt;.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Is RFC 6939 Support Finally Here – Checking the Implementation of the “Client Link Layer Address Option” in DHCPv6</title>
      <link>https://insinuator.net/2015/02/is-rfc-6939-support-finally-here-checking-the-implementation-of-the-client-link-layer-address-option-in-dhcpv6/</link>
      <pubDate>Wed, 04 Feb 2015 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2015/02/is-rfc-6939-support-finally-here-checking-the-implementation-of-the-client-link-layer-address-option-in-dhcpv6/</guid>
      <description>&lt;p&gt;One of the main DHCPv6 enhancements – fyi: we have already discussed DHCPv6 &lt;a href=&#34;http://www.insinuator.net/tag/dhcpv6/&#34;&gt;in some other posts&lt;/a&gt; – many practitioners have been waiting for quite some time now, is full support of &lt;a href=&#34;https://tools.ietf.org/rfc/rfc6939.txt&#34;&gt;RFC 6939&lt;/a&gt; (Client Link-Layer Address Option in DHCPv6) by network devices (acting as relays) and DHCPv6 servers. RFC 6939 support would allow a number of things which large organizations use in their DHCPv4 based networks, incl.&lt;/p&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;reservations (assigning a kind-of fixed DHCP address based on the MAC address of a system which in turn allows for “centralized administration of somewhat static addresses”).&lt;/li&gt;&#xA;&lt;li&gt;correlation of IPv4 and IPv6 addresses of a given host identified by its MAC address.&lt;/li&gt;&#xA;&lt;li&gt;(some type) of security enforcement based on the MAC address of a host gathered in the course of a DHCP exchange (see for example slide #29 of &lt;a href=&#34;https://ripe68.ripe.net/presentations/294-cern-ipv6-deployment.pdf&#34;&gt;this presentation of the IPv6 deployment at CERN&lt;/a&gt;, btw: slide #9 might be helpful when discussing IPv6 transition plans with your CIO. or not).&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;p&gt;So far it seemed very few components support RFC 6939. When &lt;a href=&#34;https://twitter.com/bckcntryskr&#34;&gt;Tim Martin&lt;/a&gt; mentioned at Cisco Live that Cisco devices running IOS XE support it by default, we decided go to the lab ;-).&lt;/p&gt;</description>
    </item>
    <item>
      <title>IPv6-related Requirements for the Internet Uplink or MPLS Networks</title>
      <link>https://insinuator.net/2015/01/ipv6-related-requirements-for-the-internet-uplink-or-mpls-networks/</link>
      <pubDate>Sat, 31 Jan 2015 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2015/01/ipv6-related-requirements-for-the-internet-uplink-or-mpls-networks/</guid>
      <description>&lt;p&gt;We’re currently involved in a complex RfP procedure for global network services of a large organization. As part of that we were asked to define a list of IPv6 related requirements as for the  Internet uplink and MPLS circuit connections. The involved service providers/carrier offerings will be checked to comply with those.&lt;/p&gt;&#xA;&lt;p&gt;As a source of inspiration we mainly used the excellent “&lt;a href=&#34;http://docwiki.cisco.com/wiki/What_To_Ask_From_Your_Service_Provider_About_IPv6&#34;&gt;What To Ask From Your Service Provider About IPv6&lt;/a&gt;” document from Cisco, and enhanced that with stuff we observed in other environments (go wrong), namely with regard to MTU/PMTUD  and in the &lt;a href=&#34;https://ripe69.ripe.net/presentations/137-RIPE69_Langner_Rey_Schaetzle_Slash48_Considered_Harmful.pdf&#34;&gt;space of prefix filtering&lt;/a&gt;. Here’s the first draft list we came up with:&lt;/p&gt;</description>
    </item>
    <item>
      <title>Evaluation of IPv6 Capabilities of Commercial IPAM Solutions</title>
      <link>https://insinuator.net/2015/01/evaluation-of-ipv6-capabilities-of-commercial-ipam-solutions/</link>
      <pubDate>Wed, 28 Jan 2015 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2015/01/evaluation-of-ipv6-capabilities-of-commercial-ipam-solutions/</guid>
      <description>&lt;p&gt;Originating from a customer IPv6 deployment project, in early 2014 we defined a number of requirements as for the IPv6 capabilities of IPAM solutions, with a certain focus on security-related requirements (due to the specific environment of the project). We subsequently performed a practical evaluation of several commercial solutions, based on documentation, lab implementation and vendor communication.&lt;/p&gt;&#xA;&lt;p&gt;We just released &lt;a href=&#34;https://www.ernw.de/download/newsletter/ERNW_Newsletter_46_Evaluation_of_Commercial_IPAM_Solutions_IPv6_Capabilities.pdf&#34;&gt;a newsletter describing the requirements and the results of the evaluation&lt;/a&gt;.&lt;br&gt;&#xA;It should be noted that in the interim newer versions of the evaluated products might be available which might have enhanced features. Hence, from our perspective, understanding the requirements of an individual environment might even be more important than the actual results described in that document (as those only reflect a certain point of time). We hope to contribute here to a well-informed requirements definition and decision taking process on your side.&lt;br&gt;&#xA;Feel free to get back to us on any of the points laid out or, even better, join us at the Troopers &lt;a href=&#34;https://www.troopers.de/events/troopers15/322_ipv6_security_summit/&#34;&gt;IPv6 Security Summit&lt;/a&gt; in Heidelberg on Mar 16th/17th in order to discuss any related points.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Evasion of Cisco ACLs by (Ab)Using IPv6 &amp; Discussion of Mitigation Techniques</title>
      <link>https://insinuator.net/2015/01/evasion-of-cisco-acls-by-abusing-ipv6-discussion-of-mitigation-techniques/</link>
      <pubDate>Wed, 28 Jan 2015 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2015/01/evasion-of-cisco-acls-by-abusing-ipv6-discussion-of-mitigation-techniques/</guid>
      <description>&lt;p&gt;This is a guest post of &lt;a href=&#34;https://twitter.com/antoniosatlasis&#34;&gt;Antonios Atlasis&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;p&gt;During our blogpost regarding &lt;a href=&#34;http://www.insinuator.net/2015/01/dhcpv6-guard-do-it-like-ra-guard-evasion/&#34;&gt;&lt;em&gt;DHCPv6 Guard evasion&lt;/em&gt;&lt;/a&gt;, one of the side-effects was that Access Control Lists (ACLs) configured to block access to UDP ports 546 can be evaded by abusing (again) IPv6 Extension headers. Having that in mind, we decided to check the effectiveness of Cisco IPv6 ACLs under various scenarios. Our goal was to examine whether the IPv6 ACLs of Cisco routers can be evaded, as well as under which conditions this can take place. To this end, several representative scenarios from enterprise environments or other potential ones are examined.&lt;/p&gt;</description>
    </item>
    <item>
      <title>The Persistent Problem of State in IPv6 (Security)</title>
      <link>https://insinuator.net/2015/01/the-persistent-problem-of-state-in-ipv6-security/</link>
      <pubDate>Wed, 28 Jan 2015 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2015/01/the-persistent-problem-of-state-in-ipv6-security/</guid>
      <description>&lt;p&gt;I’ve discussed the heavy complexity of IPv6 and its negative impact on security architectures relying on state  – you know, “stateful” firewalls and the like 😉 – before (&lt;a href=&#34;https://www.ernw.de/download/ERNW_Security_Implications_of_Disruptive_Technologies_web.pdf&#34;&gt;here&lt;/a&gt; and &lt;a href=&#34;https://www.troopers.de/media/filer_public/42/1a/421a0a30-0a35-486a-b25e-7eea27f18ef7/troopers14-why_ipv6_security_is_so_hard-structural_deficits_of_ipv6_and_their_implications-enno_rey.pdf&#34;&gt;here&lt;/a&gt;. btw, the widely discussed IPv6-related &lt;a href=&#34;http://blog.bimajority.org/2014/09/05/the-network-nightmare-that-ate-my-week/&#34;&gt;network outage&lt;/a&gt; at MIT last year was a state problem as well: switches keeping track of multicast groups, of which in turn many existed due privacy extensions combined with the &lt;a href=&#34;http://www.insinuator.net/2014/09/mld-and-neighbor-discovery-are-they-related/&#34;&gt;unfortunate relationship of MLD and ND&lt;/a&gt;).&lt;/p&gt;&#xA;&lt;p&gt;One of the conclusions I’ve drawn in the past was recommending to minimize the amount of state one might use within security architectures in the IPv6 world. First, this is bad news for quite some well-established security controls that need a certain amount of state to work properly, like IDPS systems – which subsequently &lt;a href=&#34;https://www.ernw.de/download/Atlasis_Rey_Schaefer_BHEU_2014_Evasion_of_HighEnd_IPS_Devices.pdf&#34;&gt;have hard times to work properly&lt;/a&gt; in IPv6 networks.&lt;br&gt;&#xA;Secondly there’s another severe caveat. As I fully realized yesterday, at Cisco Live Europe, in &lt;a href=&#34;https://twitter.com/ayourtch&#34;&gt;Andrew Yourtchenko&lt;/a&gt;‘s excellent breakout session on “Advanced IPv6 Security in the Core”, this carries some consequences for stateless (and hence: seemingly “unaffected”) security controls, too.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Troopers15 IPv6 Security Summit</title>
      <link>https://insinuator.net/2015/01/troopers15-ipv6-security-summit/</link>
      <pubDate>Tue, 20 Jan 2015 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2015/01/troopers15-ipv6-security-summit/</guid>
      <description>&lt;p&gt;We’ve finalized the agenda for this year’s IPv6 Security Summit. Here’s an overview of the event:&lt;/p&gt;&#xA;&lt;p&gt;The “IPv6 Security Summit” is a special two-day convention in the context of the &lt;a href=&#34;https://www.troopers.de/troopers/&#34;&gt;Troopers security conference&lt;/a&gt;. It will be run in two tracks of both half-day workshops and 90 minute presentations on specific topics. The goal is to foster the discussion of IPv6 security aspects &amp;amp; issues and to provide practical advice for security officers, network planners and practitioners in the IPv6 security field.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Main IPv6 Related Mailing Lists</title>
      <link>https://insinuator.net/2015/01/main-ipv6-related-mailing-lists/</link>
      <pubDate>Sat, 17 Jan 2015 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2015/01/main-ipv6-related-mailing-lists/</guid>
      <description>&lt;p&gt;We’re sometimes approached with the question “Which IPv6 mailing lists do you guys read/subscribe to?” – here’s a quick overview of the main ones guys like Christopher, Patrick, Rafael, Antonios and myself are periodically lurking at, to discuss IPv6 (network|security) related stuff with other practitioners and to learn from them:&lt;/p&gt;&#xA;&lt;p&gt;ipv6-ops.&lt;br&gt;&#xA;This list is a forum for people who are actually deploying IPv6 in the Internet. Its focus is on OPERATIONAL issues.&lt;br&gt;&#xA;&lt;a href=&#34;http://lists.cluenet.de/mailman/listinfo/ipv6-ops/&#34;&gt;http://lists.cluenet.de/mailman/listinfo/ipv6-ops/&lt;/a&gt;&lt;/p&gt;</description>
    </item>
    <item>
      <title>How To Configure Snort to Stop IPv6 Evasion Attacks</title>
      <link>https://insinuator.net/2015/01/how-to-configure-snort-to-stop-ipv6-evasion-attacks/</link>
      <pubDate>Sun, 11 Jan 2015 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2015/01/how-to-configure-snort-to-stop-ipv6-evasion-attacks/</guid>
      <description>&lt;p&gt;This is a guest post from &lt;a href=&#34;https://twitter.com/AntoniosAtlasis&#34;&gt;Antonios Atlasis&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;p&gt;Hi all,&lt;/p&gt;&#xA;&lt;p&gt;during our BlackHat US 2014 talk titled “&lt;a href=&#34;https://www.ernw.de/download/Atlasis_Rey_BHUSA_2014_IPv6_Evasion_of_HighEnd_IPS_Devices_web.pdf&#34;&gt;&lt;em&gt;Evasion of High-End IPS Devices in the Age of IPv6&lt;/em&gt;&lt;/a&gt;”, among others we discussed a Snort preprocessor rule (116:456) which, when enabled (not the case by default), triggers an alert when an IPv6 datagram with nine (9) or more IPv6 Extension Headers is used (such a header was used by us to evade Snort). However, we mentioned that:&lt;/p&gt;</description>
    </item>
    <item>
      <title>DHCPv6 Guard: Do It Like RA Guard Evasion</title>
      <link>https://insinuator.net/2015/01/dhcpv6-guard-do-it-like-ra-guard-evasion/</link>
      <pubDate>Thu, 08 Jan 2015 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2015/01/dhcpv6-guard-do-it-like-ra-guard-evasion/</guid>
      <description>&lt;p&gt;&lt;strong&gt;Or: When Cisco ACL Can Count Up to Five 🙂&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;This is a guest post by &lt;a href=&#34;https://twitter.com/AntoniosAtlasis&#34;&gt;Antonios Atlasis&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;p&gt;Hi all,&lt;/p&gt;&#xA;&lt;p&gt;RA Guard Evasion is well-known in the IPv6 “circles”; there is &lt;a href=&#34;https://tools.ietf.org/rfc/rfc7113.txt&#34;&gt;RFC 7113&lt;/a&gt; Advice for IPv6 Router Advertisement Guard (RA-Guard) and many interesting blog-posts like this one &lt;a href=&#34;http://www.insinuator.net/2011/03/ipv6-security-part-2-ra-guard-%E2%80%93-lets-get-practical/&#34;&gt;here&lt;/a&gt;, &lt;a href=&#34;http://www.insinuator.net/2012/03/the-story-continues-another-ipv6-update/&#34;&gt;here&lt;/a&gt;, and this excellent write-up &lt;a href=&#34;http://6lab.cz/article/rogue-router-advertisement-attack/&#34;&gt;here&lt;/a&gt; that discuss this issue.&lt;br&gt;&#xA;Moreover, as Jim Smalls states in his comprehensive “&lt;a href=&#34;http://www.rmv6tf.org/wp-content/uploads/2013/04/5-IPv6-Attacks-and-Countermeasures-v1.2.pdf&#34;&gt;IPv6 Attacks and Countermeasures&lt;/a&gt;” presentation given at the &lt;a href=&#34;http://www.rmv6tf.org/na-ipv6-summit/2013-na-ipv6-summit/2013-presentations&#34;&gt;North American IPv6 Summit 2013&lt;/a&gt;, DHCPv6 Guard or a corresponding IPv6 ACL can stop a DHCPv6 Rogue Servers, but (only?) for non-malicious/non-fragmented DHCPv6 packets (slide 35). However, at that time there wasn’t any known attack tool in the wild that had the fragmentation evasion built in.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Should IPv6 Packets With Source Address ::1 Be Processed When Received on an External Interface?</title>
      <link>https://insinuator.net/2015/01/should-ipv6-packets-with-source-address-1-be-processed-when-received-on-an-external-interface/</link>
      <pubDate>Mon, 05 Jan 2015 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2015/01/should-ipv6-packets-with-source-address-1-be-processed-when-received-on-an-external-interface/</guid>
      <description>&lt;p&gt;This is a guest post from &lt;a href=&#34;https://twitter.com/AntoniosAtlasis&#34;&gt;Antonis Atlasis&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;p&gt;Most of you are probably aware of the recently discovered/-closed severe ntpd vulnerabilities (CVE-2014-9293, CVE-2014-9294, CVE-2014-9295, CVE-2014-9296, see also &lt;a href=&#34;http://support.ntp.org/bin/view/Main/SecurityNotice&#34;&gt;the initial ntp.org security notice&lt;/a&gt;). Some days ago the Project Zero team at Google published a blog post “&lt;a href=&#34;http://googleprojectzero.blogspot.de/2015/01/finding-and-exploiting-ntpd.html&#34;&gt;Finding and exploiting ntpd vulnerabilities&lt;/a&gt;” with additional details. In this one they mentioned a seemingly minor but quite important detail: on a default OS X installation one of the built-in protection mechanisms of ntpd (that is the restriction to process certain packets only if they are sourced on the local machine) can easily be circumvented by sending IPv6 packets with a spoofed source address of ::1 (the equivalent to 127.0.0.1 in IPv4 which would be discarded by the kernel once received from an external source).&lt;/p&gt;</description>
    </item>
    <item>
      <title>Troopers15 – 5th Round of Talks Selected</title>
      <link>https://insinuator.net/2015/01/troopers15-5th-round-of-talks-selected/</link>
      <pubDate>Sat, 03 Jan 2015 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2015/01/troopers15-5th-round-of-talks-selected/</guid>
      <description>&lt;p&gt;Happy new year and all the best for 2015 to everybody!&lt;br&gt;&#xA;Here’s the next round of Troopers15 talks (all the others can be found &lt;a href=&#34;http://www.insinuator.net/tag/TR15/&#34;&gt;here&lt;/a&gt;):&lt;/p&gt;&#xA;&lt;p&gt;===&lt;/p&gt;&#xA;&lt;p&gt;Marion Marschalek &amp;amp; Moti Joseph: The Wallstreet of Windows Binaries        &lt;strong&gt;FIRST TIME MATERIAL&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;&lt;strong&gt;Synopsis&lt;/strong&gt;: Nowadays common ways to find exploitable vulnerabilities include but are not limited to fuzzing, static and dynamic analysis and patch reversing. All common approaches have advantages and limits. Fuzzers tend to only find a limited number of bugs, depending on the sophistication of the fuzzer which is indirectly dependent on the development time invested. Reverse engineering a binary for finding bugs, regardless whether statically or with a debugger, is tedious and requires a lot of time and expertise.&lt;br&gt;&#xA;As we are lazy bastards, we refuse to do all the work by hand and brain. And, as we are greedy bastards, we want a maximum scope of vulnerabilities we can cover and not be limited to what we see from a fuzzers perspective.&lt;br&gt;&#xA;So as you know – in general the lazy greedy bastards have the better ideas. We present you with our idea, which is built after the model of the Wallstreet. We built a tool which weighs the value of a function in a Windows binary as the Wallstreet values a stock; the value telling us the likability of a function to be exploitable.&lt;br&gt;&#xA;The Wallstreet technique works with two different evaluation methods, for once the likability that a function is vulnerable and also the likability that it is exploitable.&lt;br&gt;&#xA;We collect indicators, which help us evaluate that a specific function is potentially vulnerable. Such could be a present memory allocation or conversion function, a lacking sanitization check or a suspicious pattern in the functionname such as ‘create’, ‘convert’ or ‘set’. A combination of these and a handful more indicators lets us calculate what we call the speculation value.&lt;br&gt;&#xA;For the validation of the exploitability we traverse the call tree of a suspicious candidate, to verify its accessibility in an automated way. Only functions which we can influence as an attacker are interesting for us; thus we rate these accessible functions with a price-to-earnings value. Finally putting speculation value and price-to-earnings value in context, we evaluate a function with either ‘buy’ if we believe it comes with an exploitable vulnerability, or with ‘sell’ when we are certain it is not interesting to us. No worries, the presentation will not contain advanced mathematical equations.&lt;br&gt;&#xA;Our tool parses binaries and persists all the gathered information to a database, from where we can retrieve highly suspicious functions in an automated way. Without getting our hands dirty, that is. And because we are lazy bastards who like colors, a lot, we use visuals to make evaluation even easier. The tool is dubbed Wallstreet, free after the most famous stock market on the planet. It is based on Python, C and SQLite and will be released under the WTFPL license (&lt;a href=&#34;http://www.wtfpl.net/)&#34;&gt;http://www.wtfpl.net/)&lt;/a&gt;. Also, there will be demos 😀&lt;br&gt;&#xA;Wrapping it up, this presentation shows an easy to use approach which makes the complicated topic of binary exploitation more accessible. Wallstreet of Windows Binaries provides beginners with better understanding of the challenges and practitioners with a hands-on tool.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Troopers15 – Fourth Round of Talks Selected</title>
      <link>https://insinuator.net/2014/12/troopers15-fourth-round-of-talks-selected/</link>
      <pubDate>Mon, 29 Dec 2014 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2014/12/troopers15-fourth-round-of-talks-selected/</guid>
      <description>&lt;p&gt;As we promised some days ago here’s the fourth round of Troopers15 talks (the first three can be found &lt;a href=&#34;http://www.insinuator.net/tag/tr15/&#34;&gt;here&lt;/a&gt;). We really can’t wait for the con ourselves 😉 !&lt;/p&gt;&#xA;&lt;p&gt;Arrigo Triulzi: Pneumonia, Shardan, Antibiotics and Nasty MOV: a Dead Hand’s Tale&lt;br&gt;&#xA;&lt;strong&gt;FIRST TIME MATERIAL&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;Synopsis: Starting in the 80’s we will discuss the influence of nuclear weapons on the design of an ITsec “Dead Hand” system for a security practitioner, how it merged with research into firmware backdoors and microcode modification and finally triggered when instead of enjoying Summer pneumonia struck unannounced, or rather, announced by the Dead Hand via Twitter.&lt;/p&gt;</description>
    </item>
    <item>
      <title>IPv6 Hardening Guide for Windows Servers</title>
      <link>https://insinuator.net/2014/12/ipv6-hardening-guide-for-windows-servers/</link>
      <pubDate>Mon, 22 Dec 2014 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2014/12/ipv6-hardening-guide-for-windows-servers/</guid>
      <description>&lt;p&gt;After we recently released the “&lt;a href=&#34;http://www.insinuator.net/2014/12/ipv6-hardening-guide-for-linux-servers/&#34;&gt;Linux IPv6 Hardening Guide&lt;/a&gt;” we got a number of suggestions “could you pls provide a similar document for $OS?” (btw: thanks to you all for the overwhelming interest in the Linux document and the active discussion of ip6tables rule approaches on the &lt;a href=&#34;http://lists.si6networks.com/listinfo/ipv6hackers/&#34;&gt;&lt;em&gt;ipv6hackers&lt;/em&gt; mailing list&lt;/a&gt;).&lt;/p&gt;&#xA;&lt;p&gt;Hence Antonios thankfully decided to put together a list of configuration steps for Windows servers. It &lt;a href=&#34;https://www.ernw.de/download/ERNW_Guide_to_Configure_Securely_Windows_Servers_For_IPv6_v1_0.pdf&#34;&gt;can be found here&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;p&gt;Once more we’d like to emphasize that the approach described is only suited for very specific environments with high security requirements and an associated ratio of “generous operational resources”. From our perspective this guide is intended mostly to serve as a source of inspiration (“what could be done”) and for documentation purposes (“how to do it”). Everything described should be carefully tested in your specific environment.&lt;br&gt;&#xA;For example, we were recently involved in IPv6 security planning in an organization where the Windows guys (completely legitimately) came up with a stance of “before we fully accept and ratify the strategy and policy just discussed, we’d like to get feedback from Microsoft, if we still have full support once we follow this path”.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Troopers15 – Third Round of Talks Selected</title>
      <link>https://insinuator.net/2014/12/troopers15-third-round-of-talks-selected/</link>
      <pubDate>Sat, 20 Dec 2014 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2014/12/troopers15-third-round-of-talks-selected/</guid>
      <description>&lt;p&gt;As we promised some days ago here’s the third round of Troopers15 speakers (first one &lt;a href=&#34;http://www.insinuator.net/2014/11/troopers15-first-round-of-talks-selected/&#34;&gt;here&lt;/a&gt;, second &lt;a href=&#34;http://www.insinuator.net/2014/12/troopers15-second-round-of-talks-selected/&#34;&gt;here&lt;/a&gt;). It’s going to be awesome!&lt;/p&gt;&#xA;&lt;p&gt;&lt;a href=&#34;http://3vildata.tumblr.com/&#34;&gt;Andreas Lindh&lt;/a&gt;: Defender Economics         &lt;strong&gt;FIRST TIME MATERIAL&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;Synopsis: There are a lot of preconceptions about defense, the most prevalent one probably the “defenders dilemma” in which it is stated that an attacker only needs to find one weakness to compromise a network while a defender needs to defend all of them. While this may be true in a technical sense, things become a lot more complicated once you apply real world considerations. Preconceptions like this are often the foundation on which risk management and ultimately defense strategies are based, something that has led to a number of false but generally accepted assumptions about attackers and their capabilities, and how to defend against them.&lt;br&gt;&#xA;This talk will discuss the capabilities, and more importantly the limitations, of different types of attackers. Using the ancient wisdom of the Teenage Mutant Ninja Turtles, the speaker will explain how knowledge of an attacker’s limitations can be leveraged to raise the cost of attack, something that will tip the scale in the defenders favor. The speaker will also explain how different defensive measures will affect different types of attackers, how they are likely to react to them, and in the end how to get them to hopefully move on to another target.&lt;/p&gt;</description>
    </item>
    <item>
      <title>IPv6 Hardening Guide for Linux Servers</title>
      <link>https://insinuator.net/2014/12/ipv6-hardening-guide-for-linux-servers/</link>
      <pubDate>Wed, 17 Dec 2014 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2014/12/ipv6-hardening-guide-for-linux-servers/</guid>
      <description>&lt;p&gt;We were recently approached by a customer asking us for support along the lines of “do you have any recommendations as for strict hardening of IPv6 parameters on Linux systems?”. It turned out that the systems in question process quite sensitive data and are located in certain, not too big network segments with very high security requirements.&lt;/p&gt;&#xA;&lt;p&gt;They indicated they were willing to spend significant operational resources on “securely configuring them”. So Antonios deciced to write a small hardening guide for IPv6 on Linux, mostly focusing on manual configuration of pretty much everything (including neighbor cache entries 😉 with accompanying deactivation of all automatic mechanisms, together with ip6tables based local packet filtering.&lt;br&gt;&#xA;The document &lt;a href=&#34;https://www.ernw.de/download/ERNW_Guide_to_Securely_Configure_Linux_Servers_For_IPv6_v1_0.pdf&#34;&gt;can be found here&lt;/a&gt;.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Penetration Testing Tools that (do not) Support IPv6</title>
      <link>https://insinuator.net/2014/12/penetration-testing-tools-that-do-not-support-ipv6/</link>
      <pubDate>Thu, 11 Dec 2014 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2014/12/penetration-testing-tools-that-do-not-support-ipv6/</guid>
      <description>&lt;p&gt;We just released a white paper authored by &lt;a href=&#34;https://twitter.com/AntoniosAtlasis&#34;&gt;Antonios Atlasis&lt;/a&gt; that provides an overview which pentesting tools currently support IPv6 and how to (still) use them if that’s not the case. It can be found &lt;a href=&#34;https://www.ernw.de/category/newsletter/index.html&#34;&gt;in our newsletter section&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;p&gt;Best&lt;/p&gt;&#xA;&lt;p&gt;Enno&lt;/p&gt;</description>
    </item>
    <item>
      <title>Troopers15 – Second Round of Talks Selected</title>
      <link>https://insinuator.net/2014/12/troopers15-second-round-of-talks-selected/</link>
      <pubDate>Fri, 05 Dec 2014 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2014/12/troopers15-second-round-of-talks-selected/</guid>
      <description>&lt;p&gt;As we promised some days ago when we &lt;a href=&#34;http://www.insinuator.net/2014/11/troopers15-first-round-of-talks-selected/&#34;&gt;published the first round&lt;/a&gt;, here we go with the second:&lt;/p&gt;&#xA;&lt;p&gt;&lt;a href=&#34;https://twitter.com/michaelossmann&#34;&gt;Mike Ossmann&lt;/a&gt;: RF Retroreflectors, Emission Security and SDR&lt;/p&gt;&#xA;&lt;p&gt;Synopsis: The leaked pages from the NSA ANT catalog provided a glimpse into the modern world of emission security. Extending beyond passive monitoring of unintentional emissions, today’s spooks employ active attacks with tools such as RF retroreflectors. I’ll report on my experiments to reproduce such techniques with open source hardware and software, primarily using SDR.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Security Implications of Using IPv6 GUAs Only</title>
      <link>https://insinuator.net/2014/12/security-implications-of-using-ipv6-guas-only/</link>
      <pubDate>Mon, 01 Dec 2014 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2014/12/security-implications-of-using-ipv6-guas-only/</guid>
      <description>&lt;p&gt;When planning for IPv6 addressing, many organizations – rightfully &amp;amp; wisely – decide to go with &lt;em&gt;global unicast addresses&lt;/em&gt; (GUAs) only (hence not to use &lt;em&gt;unique local addresses&lt;/em&gt;/ULAs as of &lt;a href=&#34;https://tools.ietf.org/rfc/rfc4193.txt&#34;&gt;RFC 4193&lt;/a&gt; at all), in order to avoid &lt;em&gt;address selection hell&lt;/em&gt; or just for &lt;a href=&#34;https://www.ietf.org/rfc/rfc3439.txt&#34;&gt;simplicity&lt;/a&gt; &amp;amp; consistency reasons. This post discusses security implications and complementary security controls of such an approach.&lt;/p&gt;&#xA;&lt;p&gt;In their IPv4 networks, most of these organizations currently use RFC 1918 space, combined with NAT for specific connections or use cases. Ideally NAT is only in place “where strictly needed”, in practice it’s often used as a &lt;a href=&#34;http://blog.ipspace.net/2013/09/sooner-or-later-someone-will-pay-for.html&#34;&gt;kludge&lt;/a&gt; to conceal of all types of bad network design or debatable application architectures. I won’t enter the “is NAT a security control?” debate here, one statement might be allowed though: as of section 3 (“Because private addresses have no global meaning, routing information about private networks shall not be propagated on inter-enterprise links, and packets with private source or destination addresses should not be forwarded across such links.”) &lt;a href=&#34;https://tools.ietf.org/rfc/rfc1918.txt&#34;&gt;RFC 1918&lt;/a&gt; space is usually not reachable from the Internet. So using such address space for internal networks is a nice example of the &lt;em&gt;isolation principle&lt;/em&gt; as of the “&lt;a href=&#34;http://www.insinuator.net/2012/03/applying-the-ernw-seven-sisters-approach-to-voip-networks-applying-the-ernw-seven-sisters-approach-to-telco-networks/&#34;&gt;Seven Sisters&lt;/a&gt;” approach we like to use. Now, bringing NAT into these networks &lt;strong&gt;enables&lt;/strong&gt; connections (usually between trusted and untrusted networks) which simply would not be possible without it [NAT], so this &lt;strong&gt;actually breaks the isolation property&lt;/strong&gt;. Question: how can one ever call something that &lt;strong&gt;increases&lt;/strong&gt; the number of possible interactions between assets and potential attack originators a ‘security control’?!&lt;/p&gt;</description>
    </item>
    <item>
      <title>IPv6 in RFIs/Tendering Processes</title>
      <link>https://insinuator.net/2014/11/ipv6-in-rfis/tendering-processes/</link>
      <pubDate>Fri, 28 Nov 2014 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2014/11/ipv6-in-rfis/tendering-processes/</guid>
      <description>&lt;p&gt;In one of our customer environments each vendor offering an IT product/solution is asked to fill out a questionnaire collecting information on a number of technical parameters with regard to their product[s]. We were recently asked to come up with a proposal of 8 to 10 IPv6-related questions to be added to the questionnaire/process. Here’s what we suggested:&lt;/p&gt;&#xA;&lt;p&gt;When displaying, storing or exporting IP addresses, can your solution correctly handle IPv6 addresses of all types (link-local, ULAs, GUAs)?&lt;br&gt;&#xA;When receiving IP addresses as input or processing them (e.g. in a database), can your solution correctly handle IPv6 addresses of all types (link-local, ULAs, GUAs) and of variable length?&lt;br&gt;&#xA;Does your solution implement RFC 5952 in the sense that input (of IPv6 addresses) can be in any format, but output (e.g. in log files) follows the RFC 5952 recommendation?&lt;br&gt;&#xA;Can your solution handle both A and AAAA records from DNS?&lt;br&gt;&#xA;Does your solution use link-local or GUAs/ULAs for intra-subnet communication? Which is the default and can both types of addresses be configured?&lt;br&gt;&#xA;Does your product/offering comply with any of the profiles in the ripe-554 requirements specification?&lt;br&gt;&#xA;[http://www.ripe.net/ripe/docs/ripe-554]&lt;br&gt;&#xA;Do all security-related functions of your solution (e.g. traffic filtering/ACLs, blacklisting, logging) fully support IPv6, with performance being equal to that of IPv4?&lt;br&gt;&#xA;Do all implementations of management interfaces &amp;amp; protocols (SNMP, syslog etc.) used within your solution fully support IPv6?&lt;br&gt;&#xA;Does your solution have a built-in webserver? Can this be configured to listen on an IPv6 address and has it been tested to successfully work in an IPv6-only or dual-stack setting?&lt;br&gt;&#xA;Has your solution been thoroughly tested in an IPv6 only or in a dual-stack setting? Please provide proper test documentation.&lt;br&gt;&#xA;In dual-stack settings which approach (e.g. Happy Eyeballs as of RFC 6555) does your solution follow as for preferring IPv6 over IPv4 or vice versa? Can this be configured/adjusted if needed?&lt;/p&gt;</description>
    </item>
    <item>
      <title>MLD Considered Harmful?</title>
      <link>https://insinuator.net/2014/11/mld-considered-harmful/</link>
      <pubDate>Thu, 27 Nov 2014 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2014/11/mld-considered-harmful/</guid>
      <description>&lt;p&gt;This is a guest post from &lt;a href=&#34;https://twitter.com/AntoniosAtlasis&#34;&gt;Antonios Atlasis&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;p&gt;On Thursday the 20^(th) Enno, Jayson and I had the pleasure to present our latest research results  regarding MLD at &lt;a href=&#34;http://www.deepsec.net/speaker.html#PSLOT153&#34;&gt;Deepsec 2014&lt;/a&gt;, both from vendors’ implementation perspective as well as regarding protocol design flaws (some preliminary results as well as our testing methodology were discussed &lt;a href=&#34;http://www.insinuator.net/2014/11/mld-to-be-reconsidered/&#34;&gt;here&lt;/a&gt; and &lt;a href=&#34;http://www.insinuator.net/2014/11/protocol-properties-attack-vectors/&#34;&gt;here&lt;/a&gt;).&lt;/p&gt;&#xA;&lt;p&gt;For refreshing out memory, in a nutshell, the purpose of MLD, a subprotocol of IPv6, is to inform routers about the presence of nodes which are interested in receiving specific multicast traffic (&lt;a href=&#34;http://tools.ietf.org/html/rfc2710&#34;&gt;RFC 2710&lt;/a&gt;). The newer version of MLD, MLDv2 adds the ability for source address selection (&lt;a href=&#34;http://tools.ietf.org/html/rfc3810&#34;&gt;RFC 3810&lt;/a&gt;).&lt;/p&gt;</description>
    </item>
    <item>
      <title>Troopers15 – First Round of Talks Selected</title>
      <link>https://insinuator.net/2014/11/troopers15-first-round-of-talks-selected/</link>
      <pubDate>Sat, 22 Nov 2014 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2014/11/troopers15-first-round-of-talks-selected/</guid>
      <description>&lt;p&gt;We’re delighted to provide the first announcement of talks of next year’s &lt;a href=&#34;https://www.troopers.de/&#34;&gt;Troopers&lt;/a&gt; edition. Looks like it’s going to be a great event again &lt;img src=&#34;http://www.insinuator.net/wp-includes/images/smilies/icon_wink.gif&#34; alt=&#34;;-)&#34;&gt;.&lt;br&gt;&#xA;Here we go:&lt;/p&gt;&#xA;&lt;p&gt;Jacob Torrey – The foundation is rotting and the basement is flooding: A deeper look at the implicit trust relationships in your organization        &lt;strong&gt;FIRST TIME MATERIAL&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;Synopsis: In this session, a new hardware-level attack on PCIe is presented as an example for the implicit trust your organization places in 3rd parties. These implicit trust relationships that are typically overlooked will be closely examined under the lens of “InfoSec debt” and providing guidance to InfoSec decision makers on the ROI or risks of adding additional IT services/appliances to an organization’s network.&lt;br&gt;&#xA;The “InfoSec debt” metric can then be tracked over time and provides an intuitive way to explain the cost/benefits of IT security to other organizational stakeholders.&lt;/p&gt;</description>
    </item>
    <item>
      <title>MLD to Be Reconsidered?</title>
      <link>https://insinuator.net/2014/11/mld-to-be-reconsidered/</link>
      <pubDate>Fri, 14 Nov 2014 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2014/11/mld-to-be-reconsidered/</guid>
      <description>&lt;p&gt;This is guest post from &lt;a href=&#34;https://twitter.com/AntoniosAtlasis&#34;&gt;Antonios Atlasis&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;p&gt;Following my September post about the connection between &lt;a href=&#34;http://www.insinuator.net/2014/09/mld-and-neighbor-discovery-are-they-related/&#34;&gt;MLD and Neighbor Discovery&lt;/a&gt;, as well as &lt;a href=&#34;http://www.insinuator.net/2014/11/protocol-properties-attack-vectors/&#34;&gt;Enno’s introduction&lt;/a&gt; about our &lt;a href=&#34;http://www.deepsec.net/speaker.html#PSLOT153&#34;&gt;upcoming talk at DeepSec&lt;/a&gt;, I would like to try to enlighten you about this with some technical details. First, we have some facts:&lt;/p&gt;&#xA;&lt;ol&gt;&#xA;&lt;li&gt;MLD is pre-enabled in most modern Operating Systems.&lt;/li&gt;&#xA;&lt;li&gt;MLD traffic is sent out-of the-box during the stack initialization, as well as periodically.&lt;/li&gt;&#xA;&lt;li&gt;They also interact with/respond to MLD Queries without any further configuration.&lt;/li&gt;&#xA;&lt;/ol&gt;&#xA;&lt;p&gt;To run the tests, first we wrote down all potential security issues that may arise by (ab)using MLD, starting from the simple ones, like:&lt;/p&gt;</description>
    </item>
    <item>
      <title>Protocol Properties &amp; Attack Vectors</title>
      <link>https://insinuator.net/2014/11/protocol-properties-attack-vectors/</link>
      <pubDate>Thu, 13 Nov 2014 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2014/11/protocol-properties-attack-vectors/</guid>
      <description>&lt;p&gt;Next week, at &lt;a href=&#34;http://www.deepsec.net/&#34;&gt;DeepSec&lt;/a&gt;, we’re going to give a &lt;a href=&#34;http://www.deepsec.net/speaker.html#PSLOT153&#34;&gt;talk about Multicast Listener Discovery&lt;/a&gt; (MLD), a component of IPv6 which is realized by means of ICMPv6 messages. There are two versions of MLD (mainly specified in RFC 2710 and RFC 3810 respectively) and while MLD is technically implemented by ICMPv6 exchanges, these specifications describe a whole set of rules and communication formats, hence we can safely talk about “the MLD protocol”.&lt;/p&gt;&#xA;&lt;p&gt;Now, you might ask: how does one tackle the task of examining the security “of a protocol”?&lt;/p&gt;</description>
    </item>
    <item>
      <title>Dynamics of IPv6 Prefixes within the LIR Scope in the RIPE NCC Region</title>
      <link>https://insinuator.net/2014/11/dynamics-of-ipv6-prefixes-within-the-lir-scope-in-the-ripe-ncc-region/</link>
      <pubDate>Thu, 06 Nov 2014 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2014/11/dynamics-of-ipv6-prefixes-within-the-lir-scope-in-the-ripe-ncc-region/</guid>
      <description>&lt;p&gt;To contribute to the &lt;a href=&#34;http://www.insinuator.net/2014/10/deaggregation-by-large-organizations/&#34;&gt;current debate&lt;/a&gt; on IPv6 route deaggregation &amp;amp; “strict-filtering” performed by certain ISPs we just released a white paper on “&lt;a href=&#34;https://www.ernw.de/newsletter/newsletter-44-november-2014-dynamics-of-ipv6-prefixes-within-the-lir-scope-in-the-ripe-ncc-region/index.html&#34;&gt;Dynamics of IPv6 Prefixes within the LIR Scope in the RIPE NCC Region&lt;/a&gt;“. I will give a &lt;a href=&#34;https://ripe69.ripe.net/wp-content/uploads/presentations/137-RIPE69_Langner_Rey_Schaetzle_Slash48_Considered_Harmful.pdf&#34;&gt;talk&lt;/a&gt; on the overall topic later today at the &lt;em&gt;Routing Working Group&lt;/em&gt;. We sincerely hope that the IPv6 community becomes aware of the inherent issues, and that practical solutions can be found which consider &amp;amp; meet the needs of the different parties involved.&lt;/p&gt;</description>
    </item>
    <item>
      <title>IPv6 for IPv4 Experts</title>
      <link>https://insinuator.net/2014/11/ipv6-for-ipv4-experts/</link>
      <pubDate>Tue, 04 Nov 2014 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2014/11/ipv6-for-ipv4-experts/</guid>
      <description>&lt;p&gt;If any of you is interested in the intricacies of IPv6 Neighbor Discovery (ND) I briefly referred to in the course of &lt;a href=&#34;http://www.insinuator.net/2014/10/router-advertisement-options-to-the-rescue-a-deep-dive-into-dhcpv6-part-2/&#34;&gt;my series on DHCPv6&lt;/a&gt;, I recommend reading section 5.2 “The Host, the Link, and the Subnet in IPv6” of Yar Tikhiy’s excellent ebook “IPv6 for IPv4 Experts”. It can &lt;a href=&#34;https://sites.google.com/site/yartikhiy/home/ipv6book&#34;&gt;be found here&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;p&gt;Best&lt;/p&gt;&#xA;&lt;p&gt;Enno&lt;/p&gt;</description>
    </item>
    <item>
      <title>I Don’t Have Any Neighbors – A Deep Dive into DHCPv6, Part 1</title>
      <link>https://insinuator.net/2014/10/i-dont-have-any-neighbors-a-deep-dive-into-dhcpv6-part-1/</link>
      <pubDate>Fri, 31 Oct 2014 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2014/10/i-dont-have-any-neighbors-a-deep-dive-into-dhcpv6-part-1/</guid>
      <description>&lt;p&gt;Probably due to the (“secondary”) role it has been historically assigned within the IPv6 universe, DHCPv6 is a protocol which is very different from its IPv4 counterpart. Some of the differences and similarities have been discussed recently (e.g. see &lt;a href=&#34;https://twitter.com/SCOTTHOGG&#34;&gt;Scott Hogg&lt;/a&gt;‘s article on “&lt;a href=&#34;https://community.infoblox.com/blogs/2014/10/21/high-availability-dhcpv6&#34;&gt;High Availability DHCPv6&lt;/a&gt;“). This post aims at covering a fundamental, yet widely unknown or misunderstood difference, that is the properties of DHCPv6 addresses and their behavior on the local-link.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Router Advertisement Options to the Rescue – A Deep Dive into DHCPv6, Part 2</title>
      <link>https://insinuator.net/2014/10/router-advertisement-options-to-the-rescue-a-deep-dive-into-dhcpv6-part-2/</link>
      <pubDate>Fri, 31 Oct 2014 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2014/10/router-advertisement-options-to-the-rescue-a-deep-dive-into-dhcpv6-part-2/</guid>
      <description>&lt;p&gt;This is the sequel post to the &lt;a href=&#34;http://www.insinuator.net/2014/10/i-dont-have-any-neighbors-a-deep-dive-into-dhcpv6-part-1/&#34;&gt;first part&lt;/a&gt; in which I mainly covered some elements of the specification wrt the “on-link” flag and the IPv6 subnet model.&lt;br&gt;&#xA;In short each IPv6 address has an associated flag which determines if the host considers the respective address to be part of “a network where neighbors exist”. If this is the case ND is performed to talk to them, otherwise all communication with other hosts on that prefix is sent to the router. This flag is NOT set for DHCPv6 addresses (and, btw, just to make this clear already, there’s no way of setting it as part of the DHCP configuration procedure either) so communication with hosts with the same DHCPv6 provided prefix is supposed to go through a router, which in turn is very different (behavior) from the IPv4 world.&lt;/p&gt;</description>
    </item>
    <item>
      <title>A “Please, Don’t Waste my Time” Approach and the Sourcefire/Snort Evasion</title>
      <link>https://insinuator.net/2014/10/a-please-dont-waste-my-time-approach-and-the-sourcefire/snort-evasion/</link>
      <pubDate>Sat, 18 Oct 2014 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2014/10/a-please-dont-waste-my-time-approach-and-the-sourcefire/snort-evasion/</guid>
      <description>&lt;p&gt;This is a guest post from &lt;a href=&#34;http://www.secfu.net/about-me/&#34;&gt;Antonios Atlasis&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;p&gt;Yesterday we (Rafael Schaefer, Enno and me) had the pleasure to deliver together our talk at BlackHat Europe 2014 named &lt;a href=&#34;https://www.blackhat.com/eu-14/briefings.html#evasion-of-high-end-idps-devices-at-the-ipv6-era&#34;&gt;Evasion of High-End IDPS Devices at the IPv6 Era&lt;/a&gt; (by the way, latest slides can be found &lt;a href=&#34;https://www.ernw.de/download/Atlasis_Rey_Schaefer_BHEU_2014_Evasion_of_HighEnd_IPS_Devices.pdf&#34;&gt;here&lt;/a&gt; and the white paper &lt;a href=&#34;https://www.ernw.de/download/eu-14-Atlasis-Rey-Schaefer-briefings-Evasion-of-HighEnd-IPS-Devices-wp.pdf&#34;&gt;here&lt;/a&gt;). In this talk we summarised all the IDPS evasion techniques that we have found so far. At previous blogposts I had the chance to describe how to evade &lt;a href=&#34;http://www.insinuator.net/2014/08/evading-idps-by-combining-ipv6-extension-headers-and-fragmentation-features-the-story-of-my-life/&#34;&gt;Suricata&lt;/a&gt; and &lt;a href=&#34;http://www.insinuator.net/2014/05/a-novel-way-of-abusing-ipv6-extension-headers-to-evade-ipv6-security-devices/&#34;&gt;TippingPoint&lt;/a&gt;. In this post I am going to describe some other techniques that can be used to evade &lt;a href=&#34;https://www.snort.org/&#34;&gt;Snort&lt;/a&gt;, and its companion commercial version, &lt;a href=&#34;http://www.sourcefire.com/&#34;&gt;Sourcefire&lt;/a&gt;. The tool used to evade these IDPS is –  what else – &lt;a href=&#34;http://www.insinuator.net/2014/10/chiron-an-all-in-one-ipv6-penetration-testing-framework/&#34;&gt;Chiron&lt;/a&gt;.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Deaggregation by large organizations</title>
      <link>https://insinuator.net/2014/10/deaggregation-by-large-organizations/</link>
      <pubDate>Wed, 15 Oct 2014 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2014/10/deaggregation-by-large-organizations/</guid>
      <description>&lt;p&gt;Some hours ago &lt;a href=&#34;https://twitter.com/iljitsch&#34;&gt;Iljitsch van Beijnum&lt;/a&gt; posted &lt;a href=&#34;https://www.ripe.net/ripe/mail/archives/bcop/2014-October/000079.html&#34;&gt;an email&lt;/a&gt; with the above subject to the RIPE Best Current Operational Practices (BCOP) &lt;a href=&#34;https://www.ripe.net/mailman/listinfo/bcop&#34;&gt;mailing list&lt;/a&gt;.&lt;br&gt;&#xA;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 &lt;a href=&#34;http://www.insinuator.net/2014/01/ipv6-address-plan-considerations-part-2-the-pi-space-from-singlemultiple-rirs-debate/&#34;&gt;second part&lt;/a&gt; of my blog post series on &lt;a href=&#34;http://www.insinuator.net/2014/05/ipv6-address-plan-considerations-part-3-the-plan/&#34;&gt;IPv6 address planning&lt;/a&gt;. 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.&lt;br&gt;&#xA;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 &lt;a href=&#34;https://www.ernw.de/download/RIPE69_Rey_Langner_Slash48_Considered_Harmful_v082_DRAFT.pdf&#34;&gt;draft slides&lt;/a&gt; of the talk which was initially planned. Furthermore two fellow IPv6 practitioners (Hi Roland &amp;amp; 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.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Chiron – An All-In-One IPv6 Penetration Testing Framework</title>
      <link>https://insinuator.net/2014/10/chiron-an-all-in-one-ipv6-penetration-testing-framework/</link>
      <pubDate>Sat, 04 Oct 2014 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2014/10/chiron-an-all-in-one-ipv6-penetration-testing-framework/</guid>
      <description>&lt;p&gt;This is a guest post from &lt;a href=&#34;http://www.secfu.net/about-me/&#34;&gt;Antonios Atlasis&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;p&gt;Last week I had the pleasure to give you my impressions regarding my experience about &lt;a href=&#34;http://www.insinuator.net/2014/09/hacking-for-a-b33r-at-ghent/&#34;&gt;&lt;em&gt;hacking for b33r at Ghent&lt;/em&gt;&lt;/a&gt;, that is, my participation at &lt;a href=&#34;http://2014.brucon.org/&#34;&gt;&lt;em&gt;BruCON 2014&lt;/em&gt;&lt;/a&gt; hacking conference. As I said among else, the reason that I was there was to present &lt;a href=&#34;http://www.secfu.net/tools-scripts/&#34;&gt;&lt;em&gt;Chiron&lt;/em&gt;&lt;/a&gt;, my IPv6 penetration testing/security assessment framework, which was supported by the &lt;a href=&#34;http://blog.brucon.org/2013/12/2014-5by5-announcement.html&#34;&gt;&lt;em&gt;Brucon 5×5&lt;/em&gt;&lt;/a&gt; program. The first version of &lt;em&gt;Chiron&lt;/em&gt; had been presented at &lt;a href=&#34;https://www.troopers.de/troopers14/troopers14-ipv6-security-summit-2014/troopers14-ipv6-security-summit-2014-workshop-an-all-in-one-advanced-ipv6-testing-framework/index.html&#34;&gt;Troopers 14&lt;/a&gt;, during the &lt;a href=&#34;https://www.troopers.de/troopers14/troopers14-ipv6-security-summit-2014/index.html&#34;&gt;&lt;em&gt;IPv6 Security Summit&lt;/em&gt;&lt;/a&gt;.&lt;/p&gt;</description>
    </item>
    <item>
      <title>“Hacking for a B33r” at Ghent</title>
      <link>https://insinuator.net/2014/09/hacking-for-a-b33r-at-ghent/</link>
      <pubDate>Sat, 27 Sep 2014 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2014/09/hacking-for-a-b33r-at-ghent/</guid>
      <description>&lt;p&gt;This is a guest post by &lt;a href=&#34;http://www.secfu.net/about-me/&#34;&gt;Antonios Atlasis&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;p&gt;This week I had the pleasure to attend &lt;a href=&#34;http://2014.brucon.org/&#34;&gt;BruCON 2014&lt;/a&gt;. While participating at the &lt;em&gt;Brucon 5×5&lt;/em&gt; program, I had also the chance to attend this well-known European Con which is held in the beautiful city of Ghent.&lt;/p&gt;&#xA;&lt;p&gt;The main event took place two days (on 25th and 26th of September), while some very interesting trainings were given in the previous days. There was mainly one track, plus some workshops that you could also attend, if you wished. You could book your seat at one of the workshops using an &lt;a href=&#34;http://sched.brucon.org/&#34;&gt;on-line scheduling system&lt;/a&gt;.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Security Implications of Disruptive Technologies</title>
      <link>https://insinuator.net/2014/09/security-implications-of-disruptive-technologies/</link>
      <pubDate>Sat, 20 Sep 2014 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2014/09/security-implications-of-disruptive-technologies/</guid>
      <description>&lt;p&gt;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 &lt;a href=&#34;https://www.ernw.de/download/ERNW_Security_Implications_of_Disruptive_Technologies_web.pdf&#34;&gt;here&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;p&gt;Have a great weekend everybody&lt;/p&gt;&#xA;&lt;p&gt;Enno&lt;/p&gt;</description>
    </item>
    <item>
      <title>MLD and Neighbor Discovery. Are They Related?</title>
      <link>https://insinuator.net/2014/09/mld-and-neighbor-discovery.-are-they-related/</link>
      <pubDate>Wed, 03 Sep 2014 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2014/09/mld-and-neighbor-discovery.-are-they-related/</guid>
      <description>&lt;p&gt;This is a guest post from &lt;a href=&#34;http://www.secfu.net/about-me/&#34;&gt;Antonios Atlasis&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;p&gt;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.&lt;/p&gt;&#xA;&lt;p&gt;For the newcomers to IPv6 world, the purpose of MLD, a subprotocol of IPv6, as defined in &lt;a href=&#34;http://tools.ietf.org/html/rfc2710&#34;&gt;RFC 2710&lt;/a&gt;, is “&lt;em&gt;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.&lt;/em&gt;” MLD was updated by MLDv2 in &lt;a href=&#34;http://tools.ietf.org/html/rfc3810&#34;&gt;RFC 3810&lt;/a&gt; in order to “&lt;em&gt;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.&lt;/em&gt;”&lt;/p&gt;</description>
    </item>
    <item>
      <title>Atomic Fragments vs. Fragmentation in the IPv6 “Real World”</title>
      <link>https://insinuator.net/2014/08/atomic-fragments-vs.-fragmentation-in-the-ipv6-real-world/</link>
      <pubDate>Thu, 21 Aug 2014 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2014/08/atomic-fragments-vs.-fragmentation-in-the-ipv6-real-world/</guid>
      <description>&lt;p&gt;This is a guest post by &lt;a href=&#34;http://www.secfu.net/about-me/&#34;&gt;Antonios Atlasis&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;p&gt;Continuing the &lt;a href=&#34;http://www.insinuator.net/2014/08/packet-too-big-messages-and-atomic-fragments/&#34;&gt;discussion&lt;/a&gt; about the IPv6 Atomic Fragments &lt;a href=&#34;http://lists.si6networks.com/pipermail/ipv6hackers/2014-August/001638.html&#34;&gt;started&lt;/a&gt; at the &lt;a href=&#34;http://lists.si6networks.com/listinfo/ipv6hackers/&#34;&gt;IPv6 hacker’s mailing list&lt;/a&gt; and the &lt;a href=&#34;http://www.ietf.org/id/draft-gont-v6ops-ipv6-ehs-in-real-world-00.txt&#34;&gt;freshly proposed draft RFC&lt;/a&gt; regarding &lt;a href=&#34;http://www.ietf.org/internet-drafts/draft-gont-6man-deprecate-atomfrag-generation-00.txt&#34;&gt;the deprecation of the generation of IPv6 Atomic Fragments&lt;/a&gt;, 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.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Packet Too Big Messages and Atomic Fragments</title>
      <link>https://insinuator.net/2014/08/packet-too-big-messages-and-atomic-fragments/</link>
      <pubDate>Wed, 20 Aug 2014 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2014/08/packet-too-big-messages-and-atomic-fragments/</guid>
      <description>&lt;p&gt;This is a guest post from &lt;a href=&#34;http://www.secfu.net/about-me/&#34;&gt;Antonios Atlasis&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;p&gt;Taking the chance from &lt;a href=&#34;http://lists.si6networks.com/pipermail/ipv6hackers/2014-August/001638.html&#34;&gt;a discussion&lt;/a&gt; on the &lt;a href=&#34;http://lists.si6networks.com/listinfo/ipv6hackers/&#34;&gt;IPv6 hacker’s mailing list&lt;/a&gt; and the &lt;a href=&#34;http://www.ietf.org/id/draft-gont-v6ops-ipv6-ehs-in-real-world-00.txt&#34;&gt;freshly proposed draft RFC&lt;/a&gt; regarding &lt;a href=&#34;http://www.ietf.org/internet-drafts/draft-gont-6man-deprecate-atomfrag-generation-00.txt&#34;&gt;the deprecation of the generation of IPv6 Atomic Fragments&lt;/a&gt;, 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).&lt;/p&gt;</description>
    </item>
    <item>
      <title>Evading IDPS by Combining IPv6 Extension Headers and Fragmentation “Features” – The Story of My Life…</title>
      <link>https://insinuator.net/2014/08/evading-idps-by-combining-ipv6-extension-headers-and-fragmentation-features-the-story-of-my-life/</link>
      <pubDate>Sat, 09 Aug 2014 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2014/08/evading-idps-by-combining-ipv6-extension-headers-and-fragmentation-features-the-story-of-my-life/</guid>
      <description>&lt;p&gt;This is a guest post from &lt;a href=&#34;http://www.secfu.net/about-me/&#34;&gt;Antonios Atlasis&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;p&gt;In the “&lt;a href=&#34;http://www.insinuator.net/2014/05/a-novel-way-of-abusing-ipv6-extension-headers-to-evade-ipv6-security-devices/&#34;&gt;A Novel Way of Abusing IPv6 Extension Headers to Evade IPv6 Security Devices&lt;/a&gt;” blogpost I described a way to evade a high-end commercial IDPS device, the Tipping Point IDPS (TOS Tipping Point, Package 3.6.1.4036 and vaccine 3.2.0.8530 digital), by abusing a minor detail at the IPv6 specification. As I promised at the end of that blogpost, this is not the end. In this blogpost I am going to describe several new and different ways of evading another popular IDPS, an open-source one this time, &lt;a href=&#34;http://suricata-ids.org/&#34;&gt;Suricata&lt;/a&gt;.&lt;/p&gt;</description>
    </item>
    <item>
      <title>IPv6 for Managers</title>
      <link>https://insinuator.net/2014/07/ipv6-for-managers/</link>
      <pubDate>Tue, 22 Jul 2014 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2014/07/ipv6-for-managers/</guid>
      <description>&lt;p&gt;We’re currently involved in a number of IPv6 activities in different organizations and one of the questions we are still facing – even in cases where there’s already a (in most cases networking team driven/originated) “project” (incl. budget, project sponsor, milestones etc.) – is along the lines of “How to sell IPv6 to our management?”.&lt;/p&gt;&#xA;&lt;p&gt;In the following I will shortly lay out the line of reasoning and the terminology we usually employ for the task. Furthermore I’ve anonymized a presentation which we recently prepared as “input” for the network team of an enterprise organization; &lt;a href=&#34;https://www.ernw.de/download/ERNW_Why_IPv6_clean.pdf&#34;&gt;it can be found her&lt;/a&gt;e. In case you want to get this as a PPT (for recyling purposes) pls send me a direct email (in exchange, we might ask you for a small donation of your will to the &lt;a href=&#34;https://www.troopers.de/troopers-charity/index.html&#34;&gt;Troopers charity project&lt;/a&gt;… ).&lt;/p&gt;</description>
    </item>
    <item>
      <title>IPv6 Requirements for Cloud Service Providers</title>
      <link>https://insinuator.net/2014/07/ipv6-requirements-for-cloud-service-providers/</link>
      <pubDate>Tue, 08 Jul 2014 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2014/07/ipv6-requirements-for-cloud-service-providers/</guid>
      <description>&lt;p&gt;Some weeks ago, at RIPE 68 in Warsaw, &lt;a href=&#34;http://www.steffann.nl/site/&#34;&gt;Sander Steffann&lt;/a&gt; gave a &lt;a href=&#34;https://ripe68.ripe.net/presentations/340-RIPE-554bis.pdf&#34;&gt;presentation about revising RIPE 554&lt;/a&gt; which, in his own words, “is a template guideline for procurement of stuff that should do IPv6” (&lt;a href=&#34;https://ripe68.ripe.net/archives/steno/38/&#34;&gt;here’s&lt;/a&gt; the steganography transcript of the IPv6 working group session). Some of you will probably know &lt;a href=&#34;https://www.ripe.net/ripe/docs/ripe-554&#34;&gt;RIPE 554&lt;/a&gt; as a quite helpful document for identifying reasonable real-world requirements for IPv6 capable network devices (in particular at times when vendors quite willingly put an “IPv6 ready” sticker on all their gear…).&lt;/p&gt;</description>
    </item>
    <item>
      <title>m0n0wall as an IPv6 firewall</title>
      <link>https://insinuator.net/2014/05/m0n0wall-as-an-ipv6-firewall/</link>
      <pubDate>Fri, 30 May 2014 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2014/05/m0n0wall-as-an-ipv6-firewall/</guid>
      <description>&lt;p&gt;This is a guest post from &lt;a href=&#34;http://www.secfu.net&#34;&gt;Antonios Atlasis&lt;/a&gt;&lt;/p&gt;&#xA;&lt;p&gt;Last October I had a quick look at &lt;a href=&#34;https://www.pfsense.org/&#34;&gt;pfSense 2.1&lt;/a&gt; regarding the IPv6 support that it offers. It was the first stable support of pfSense that offered the capability for IPv6 network connectivity (a few comments about it can be found &lt;a href=&#34;http://www.secfu.net/2013/10/07/ipv6-support-of-pfsense-2-1/&#34;&gt;here&lt;/a&gt;). However, I knew that &lt;a href=&#34;http://m0n0.ch/wall/&#34;&gt;m0n0wall&lt;/a&gt; supported IPv6 quite a long time ago and that their developers had incorporated the support of IPv6 features which are not available in pfSense yet, so today I decided to have a look at it too.&lt;/p&gt;</description>
    </item>
    <item>
      <title>A Novel Way of Abusing IPv6 Extension Headers to Evade IPv6 Security Devices</title>
      <link>https://insinuator.net/2014/05/a-novel-way-of-abusing-ipv6-extension-headers-to-evade-ipv6-security-devices/</link>
      <pubDate>Mon, 26 May 2014 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2014/05/a-novel-way-of-abusing-ipv6-extension-headers-to-evade-ipv6-security-devices/</guid>
      <description>&lt;p&gt;(Or How the Smallest Detail Can Make a Difference)&lt;/p&gt;&#xA;&lt;p&gt;This is a guest post from &lt;a href=&#34;http://www.secfu.net/&#34;&gt;Antonios Atlasis&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;p&gt; &lt;/p&gt;&#xA;&lt;p&gt;As it is well known to the IPv6 enthusiasts, one of the most significant changes that IPv6 brings with it, apart from supporting a really huge address space, is the improved support for Extensions and Options, which is achieved by the usage of IPv6 Extension headers. According to &lt;a href=&#34;http://www.rfc-editor.org/rfc/rfc2460.txt&#34;&gt;RFC 2460&lt;/a&gt;, “&lt;em&gt;changes in the way IP header options are encoded allows for more efficient forwarding, less stringent limits on the length of options, and greater flexibility for introducing new options in the future&lt;/em&gt;.” So, by adding IPv6 Extension headers, according to the designers of the protocol, flexibility and efficiency in the IP layer is improved.&lt;/p&gt;</description>
    </item>
    <item>
      <title>IPv6 Address Plan Considerations, Part 3: The Plan ;-)</title>
      <link>https://insinuator.net/2014/05/ipv6-address-plan-considerations-part-3-the-plan-/</link>
      <pubDate>Wed, 14 May 2014 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2014/05/ipv6-address-plan-considerations-part-3-the-plan-/</guid>
      <description>&lt;p&gt;This is the third – and hence presumably last – part of the series of posts on IPv6 address planning (first part can be found &lt;a href=&#34;http://www.insinuator.net/2014/01/ipv6-address-plan-considerations-part-1-general-guidelines/&#34;&gt;here&lt;/a&gt;, second one &lt;a href=&#34;http://www.insinuator.net/2014/01/ipv6-address-plan-considerations-part-2-the-pi-space-from-singlemultiple-rirs-debate/&#34;&gt;here&lt;/a&gt;). It’s split into three main pieces. In the beginning I will lay out some general objectives to be considered when designing an address plan. Then I’ll have a look at potential hierarchy levels and finally I’ll discuss some real-life samples we’ve seen recently.&lt;/p&gt;</description>
    </item>
    <item>
      <title>The Three Billion Dollar App – Some Notes on My Upcoming Troopers Talk</title>
      <link>https://insinuator.net/2014/02/the-three-billion-dollar-app-some-notes-on-my-upcoming-troopers-talk/</link>
      <pubDate>Tue, 25 Feb 2014 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2014/02/the-three-billion-dollar-app-some-notes-on-my-upcoming-troopers-talk/</guid>
      <description>&lt;p&gt;This is a guest post from Vladimir Wolstencroft from our friends of &lt;a href=&#34;http://www.aurainfosec.com/&#34;&gt;aura information security&lt;br&gt;&#xA;=&lt;/a&gt;=================================================================&lt;/p&gt;&#xA;&lt;p&gt;Mobile messaging applications have been occupying people’s attention and it seems to be all the latest news. Perhaps I should have called my presentation the 19 Billion dollar app but at the time of writing and research I thought the proposed 3 Billion dollar amount for SnapChat was a little ludicrous, who could have known that would have been just a drop in the ocean.&lt;/p&gt;</description>
    </item>
    <item>
      <title>A Short Teaser on My New IPv6 Testing Framework</title>
      <link>https://insinuator.net/2014/02/a-short-teaser-on-my-new-ipv6-testing-framework/</link>
      <pubDate>Fri, 21 Feb 2014 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2014/02/a-short-teaser-on-my-new-ipv6-testing-framework/</guid>
      <description>&lt;h1 id=&#34;this-is-a-guest-post-from-antonios-atlasis&#34;&gt;This is a guest post from Antonios Atlasis&lt;/h1&gt;&#xA;&lt;p&gt; &lt;/p&gt;&#xA;&lt;p&gt;Hi,&lt;/p&gt;&#xA;&lt;p&gt;my name is Antonios and I am an independent IT Security Researcher from Greece. One of my latest “hobbies” is IPv6 and its potential insecurities so, please let me talk to you about my latest experience on this.&lt;/p&gt;&#xA;&lt;p&gt;This week, I had the opportunity to work together with the ERNW guys at their premises. They had built an IPv6 lab that included several commercial IPv6 security devices (firewalls, IDS/IPS and some high-end switches) and they kindly offered their lab to me to play with (thank you guys 🙂 – I always liked …expensive toys). The goal of this co-operation was two-fold: First, to test my new (not yet released) IPv6 pen-testing tool and secondly, to try to find out any IPv6-related security or operational issues on these devices (after all, they all claim that they are “IPv6-Ready”, right?).&lt;/p&gt;</description>
    </item>
    <item>
      <title>Analyzing a CVE-2013-3346/CVE-2013-5065 Exploit with peepdf</title>
      <link>https://insinuator.net/2014/02/analyzing-a-cve-2013-3346/cve-2013-5065-exploit-with-peepdf/</link>
      <pubDate>Mon, 10 Feb 2014 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2014/02/analyzing-a-cve-2013-3346/cve-2013-5065-exploit-with-peepdf/</guid>
      <description>&lt;p&gt;This is a guest post from Jose Miguel Esparza (&lt;a href=&#34;https://twitter.com/EternalTodo&#34;&gt;@EternalTodo&lt;/a&gt;)&lt;/p&gt;&#xA;&lt;p&gt; &lt;/p&gt;&#xA;&lt;p&gt;There are already some good blog posts talking about this exploit, but I think this is a really good example to show how &lt;a href=&#34;http://peepdf.eternal-todo.com/&#34;&gt;&lt;em&gt;peepdf&lt;/em&gt;&lt;/a&gt; works and what you can learn if you attend the workshop &lt;a href=&#34;https://www.troopers.de/troopers14/troopers14-1-day-workshop-squeezing-exploit-kits-and-pdf-exploits/index.html&#34;&gt;&lt;em&gt;“Squeezing Exploit Kits and PDF Exploits”&lt;/em&gt;&lt;/a&gt; at &lt;a href=&#34;https://www.troopers.de/troopers14/index.html&#34;&gt;Troopers14&lt;/a&gt;.  The mentioned exploit was using the &lt;a href=&#34;http://www.zerodayinitiative.com/advisories/ZDI-13-212/&#34;&gt;Adobe Reader ToolButton Use-After-Free&lt;/a&gt; vulnerability to execute code in the victim’s machine and then the &lt;a href=&#34;http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-5065&#34;&gt;Windows privilege escalation 0day&lt;/a&gt; to bypass the &lt;a href=&#34;http://cansecwest.com/slides/2013/Adobe%20Sandbox.pdf&#34;&gt;Adobe sandbox&lt;/a&gt; and execute a new payload without restrictions.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Preliminary Agenda for Troopers 2014 Telco Sec Day</title>
      <link>https://insinuator.net/2014/02/preliminary-agenda-for-troopers-2014-telco-sec-day/</link>
      <pubDate>Tue, 04 Feb 2014 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2014/02/preliminary-agenda-for-troopers-2014-telco-sec-day/</guid>
      <description>&lt;p&gt;Given we’ve received a number of inquiries as for the agenda of this year’s TelcoSecDay here’s a first preliminary agenda. To get an idea of the event’s character you might have a look at the agenda of the &lt;a href=&#34;https://www.troopers.de/archives/troopers12/agenda12/troopers12-telcosec-day/index.html&#34;&gt;2012 edition&lt;/a&gt; or the &lt;a href=&#34;https://www.troopers.de/archives/troopers13/agenda13/troopers13-telcosec-day-2013/index.html&#34;&gt;2013 edition&lt;/a&gt;. Pls note that there might be changes/additions to the following outline as we’re currently discussing potential contributions with two European operators. Here we go, for today:&lt;/p&gt;&#xA;&lt;p&gt;9:00: Opening Remarks &amp;amp; Introduction&lt;br&gt;&#xA;9:15: Ravi Borgaonkor – Evolution of SIM Card Security&lt;br&gt;&#xA;10:15: Break&lt;br&gt;&#xA;10:45: Adrian Dabrowski&lt;br&gt;&#xA;11:45: Collin Mulliner – PatchDroid – Third Party Security Patches for Android&lt;br&gt;&#xA;12:30: Lunch&lt;br&gt;&#xA;13:45: Philippe Langlois&lt;br&gt;&#xA;14:45: Break&lt;br&gt;&#xA;15:15: Haya Shulman – The Illusion of Challenge-Response Authentication&lt;br&gt;&#xA;16:00: Christian Sielaff &amp;amp; Daniel Hauenstein – Breaking Network Monitoring Tools Used in Telco Space&lt;br&gt;&#xA;16:30: Closing Remarks&lt;br&gt;&#xA;19:00: Joint dinner (hosted by ERNW) in Heidelberg Altstadt for those interested and/or staying for the main conference&lt;/p&gt;</description>
    </item>
    <item>
      <title>IPv6 Address Plan Considerations, Part 2: The “PI Space from (Single|Multiple) RIR(s) Debate”</title>
      <link>https://insinuator.net/2014/01/ipv6-address-plan-considerations-part-2-the-pi-space-from-singlemultiple-rirs-debate/</link>
      <pubDate>Thu, 23 Jan 2014 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2014/01/ipv6-address-plan-considerations-part-2-the-pi-space-from-singlemultiple-rirs-debate/</guid>
      <description>&lt;p&gt;This is the second part of the – presumably – three-part series on IPv6 address planning which I started &lt;a href=&#34;http://www.insinuator.net/2014/01/ipv6-address-plan-considerations-part-1-general-guidelines/&#34;&gt;here&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;p&gt;Before an enterprise organization (strictly speaking “their internal service provider acting as LIR”, as laid out in the first part) starts assigning prefix[es]/lengths to their networks usually another discussion has to be undertaken &amp;amp; solved: “go with one /32 [PI space] from one RIR or apply for /32s from several RIRs”.&lt;/p&gt;</description>
    </item>
    <item>
      <title>More Troopers Talks Selected</title>
      <link>https://insinuator.net/2014/01/more-troopers-talks-selected/</link>
      <pubDate>Sat, 18 Jan 2014 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2014/01/more-troopers-talks-selected/</guid>
      <description>&lt;p&gt;Today we have to pleasure to announce another round of &lt;a href=&#34;https://www.troopers.de/&#34;&gt;Troopers&lt;/a&gt; talks.&lt;br&gt;&#xA;Here we go:&lt;/p&gt;&#xA;&lt;p&gt; &lt;br&gt;&#xA;Noam Liram: Vulnerability Classification in the SaaS Era      &lt;strong&gt;FIRST TIME MATERIAL&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;Abstract: In this talk we will thoroughly analyze two major SaaS vulnerabilities that were found by Adallom (one of which is still in responsible disclosure stages at the time of writing). By demonstrating this new class of exploits which we have nick-named “Ice Dagger” attacks, we aim to change the current industry-wide criteria for vulnerability classifications, which were developed in the Desktop/Server world, are inadequate when classifying SaaS vulnerabilities. We will specifically discuss the details of MS13-104.&lt;/p&gt;</description>
    </item>
    <item>
      <title>IPv6 Address Plan Considerations, Part 1: General Guidelines</title>
      <link>https://insinuator.net/2014/01/ipv6-address-plan-considerations-part-1-general-guidelines/</link>
      <pubDate>Fri, 10 Jan 2014 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2014/01/ipv6-address-plan-considerations-part-1-general-guidelines/</guid>
      <description>&lt;p&gt;In an upcoming series of blog posts I will discuss some principles &amp;amp; considerations on developing an IPv6 address plan. In (hopefully) rather quick succession there will be three posts:&lt;/p&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;the first  on some general rules as for IPv6 address planning which we regard instrumental in the process.&lt;/li&gt;&#xA;&lt;li&gt;the second covering the “PI space from a single RIR or PI space from each (relevant, as for $ORG) RIR?” debate.&lt;/li&gt;&#xA;&lt;li&gt;the third on actual approaches to structuring/grouping each region’s /32 (or /36) into subdivisions like sites, VRFs, facilities, use types, buildings, whatever. I understand that this part is probably the one quite some readers are most interested in; still for a reasonable line of thought the others have to be covered in advance.&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;p&gt;As you might have already spotted from the prefix lengths mentioned above, the presumed setting (read: the main audience) of this piece is a sufficiently large enterprise organization with sites/subsidiaries/plants all over the globe, potentially mainly in the EMEA, APAC and Americas regions. So if you’re [with] a service provider organization, a university or small[er] organization, some of the recommendations I lay out might not apply to you. This focus (or restriction thereof) is for the simple reason of ignorance. Given I haven’t been involved in many address planning efforts in such organizations I don’t feel qualified to advance opinions on their settings.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Troopers 2014 – Third Round of Talks Selected</title>
      <link>https://insinuator.net/2014/01/troopers-2014-third-round-of-talks-selected/</link>
      <pubDate>Fri, 03 Jan 2014 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2014/01/troopers-2014-third-round-of-talks-selected/</guid>
      <description>&lt;p&gt;At first a very happy new year to all our readers!&lt;/p&gt;&#xA;&lt;p&gt;Today we announce the third round of Troopers 2014 talks (first round &lt;a href=&#34;http://www.insinuator.net/2013/11/troopers-2014-first-round-of-talks-selected/&#34;&gt;here&lt;/a&gt;, second &lt;a href=&#34;http://www.insinuator.net/2013/12/troopers-2014-second-round-of-talks-selected/&#34;&gt;here&lt;/a&gt;).&lt;/p&gt;&#xA;&lt;p&gt;Here we go:&lt;/p&gt;&#xA;&lt;p&gt;===&lt;/p&gt;&#xA;&lt;p&gt;Daniel Mende: Implementing an USB Host Driver Fuzzer         &lt;strong&gt;FIRST TIME MATERIAL&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;Abstract: The Universal Serial Bus (USB) can be found everywhere these days, may it be to connect a mouse or keyboard to the computer, transfer data on a flash drive connected via USB or to attach some additional hardware like a Digital Video Broadcast receiver. Some of these devices use a standardized device class which are served by an operating system default driver while other, special purpose devices, do not fit into any of those classes, so vendors ship their own drivers. As every vendor specific USB driver installed on a system adds additional attack surface, there needs to be some method to evaluate the stability and the security of those vendor proprietary drivers. The simplest way to perform a stability analysis of closed source products is the fuzzing approach. As there have been no publicly available tools for performing USB host driver fuzzing, I decided to develop one ;-), building on Sergey’s and Travis’ legendary &lt;a href=&#34;https://www.troopers.de/wp-content/uploads/2012/12/TROOPERS13-You_wouldnt_share_a_syringe_Would_you_share_a_USB_port-Sergey_Bratus+Travis_Goodspeed.pdf&#34;&gt;Troopers13 talk&lt;/a&gt;. Be prepared to learn a lot about USB specifics, and to see quite a number of blue screens and stack traces on major server operating systems…&lt;/p&gt;</description>
    </item>
    <item>
      <title>Troopers 2014 – Second Round of Talks Selected</title>
      <link>https://insinuator.net/2013/12/troopers-2014-second-round-of-talks-selected/</link>
      <pubDate>Wed, 18 Dec 2013 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2013/12/troopers-2014-second-round-of-talks-selected/</guid>
      <description>&lt;p&gt;We’re very happy to announce the second round of Troopers 2014 talks today (first round &lt;a href=&#34;http://www.insinuator.net/2013/11/troopers-2014-first-round-of-talks-selected/&#34;&gt;here&lt;/a&gt;).&lt;br&gt;&#xA;Some (well, actually most 😉 ) of these talks haven’t been presented before, at any other occasion, so this is exciting fresh material which was/is prepared especially for &lt;a href=&#34;https://www.troopers.de&#34;&gt;Troopers&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;p&gt; &lt;/p&gt;&#xA;&lt;p&gt;&lt;strong&gt;Andreas Wiegenstein &amp;amp; Xu Jia: Risks in Hosted SAP Environments.&lt;/strong&gt; &lt;strong&gt;FIRST TIME MATERIAL&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;**Synopsis: **Many SAP customers have outsourced the operation of their SAP systems in order to save cost. In doing so, they entrust their most critical data to a hosting provider, potentially sharing the same SAP server with a number of companies and organizations unknown to them. These companies and organizations virtually sit in the same boat, without knowing each other and without trusting each other. They all trust in the ability of their hosting provider to run their operating environment in a secure way, though.&lt;/p&gt;</description>
    </item>
    <item>
      <title>ERNW Newsletter 42: Dangers of Disabled Pre-Boot Authentication in  Corporate Environments</title>
      <link>https://insinuator.net/2013/12/ernw-newsletter-42-dangers-of-disabled-pre-boot-authentication-in-corporate-environments/</link>
      <pubDate>Mon, 16 Dec 2013 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2013/12/ernw-newsletter-42-dangers-of-disabled-pre-boot-authentication-in-corporate-environments/</guid>
      <description>&lt;p&gt;It’s been a long time… we just published an &lt;a href=&#34;https://www.ernw.de/category/newsletter/index.html&#34;&gt;ERNW Newsletter&lt;/a&gt;. Here’s the abstract:&lt;/p&gt;&#xA;&lt;p&gt;In order to protect sensitive data on corporate laptops, most companies are using full disk encryption solutions. While native encryption products like Microsoft Bitlocker, Apple FileVault and open source solutions like TrueCrypt were already heavily scrutinized by security researchers, many popular commercial third party products are to some point still black boxes.&lt;/p&gt;&#xA;&lt;p&gt;In this paper, we discuss Check Point Full Disk Encryption (FDE) with active “Windows Integrated Logon”. Checkpoint FDE is a software package that is part of Check Point Endpoint Security and offers full disk encryption on Microsoft  Windows and Mac OS X systems. The “Windows Integrated Logon” feature reduces total cost of ownership by disabling pre-boot authentication. Check Point themselves warn about security risk associated with using this feature.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Design &amp; Configuration of IPv6 Segments with High Security Requirements</title>
      <link>https://insinuator.net/2013/12/design-configuration-of-ipv6-segments-with-high-security-requirements/</link>
      <pubDate>Fri, 13 Dec 2013 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2013/12/design-configuration-of-ipv6-segments-with-high-security-requirements/</guid>
      <description>&lt;p&gt;Such was the title of a talk I gave yesterday at &lt;a href=&#34;http://www.acsac.org/&#34;&gt;ACSAC 29&lt;/a&gt;. It was an updated and shortened version of a similar talk I had given at the &lt;a href=&#34;https://www.troopers.de/&#34;&gt;Troopers&lt;/a&gt; IPv6 Security Summit (btw: &lt;a href=&#34;https://www.troopers.de/troopers14/troopers14-ipv6-security-summit-2014/index.html&#34;&gt;this&lt;/a&gt; is the preliminary agenda of the 2014 event).&lt;/p&gt;&#xA;&lt;p&gt;The slides of the ACSAC talk can be found &lt;a href=&#34;https://www.ernw.de/download/ERNW_ACSAC_IPv6_High_Secure_Networks.pdf&#34;&gt;here&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;p&gt;have a great weekend everybody&lt;/p&gt;&#xA;&lt;p&gt;Enno&lt;/p&gt;</description>
    </item>
    <item>
      <title>ACSAC 2013</title>
      <link>https://insinuator.net/2013/12/acsac-2013/</link>
      <pubDate>Thu, 12 Dec 2013 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2013/12/acsac-2013/</guid>
      <description>&lt;p&gt;Matthias and I currently have to pleasure to be at &lt;a href=&#34;http://www.acsac.org/&#34;&gt;ACSAC&lt;/a&gt;, in New Orleans.&lt;br&gt;&#xA;From my perspective, at ACSAC the usual conference visit side-effect of personal interaction with peers plays an even larger role than at many other events. In fact we met a number of people we hadn’t seen for quite some time and I could even clear a long unresolved debt (Hi Pastor! and thanks for those &lt;a href=&#34;https://archive.org/details/International_Journal_of_PoC_2013_08_05&#34;&gt;International Journal of PoC&lt;/a&gt; issues).&lt;/p&gt;</description>
    </item>
    <item>
      <title>Troopers 2014 – First Round of Talks Selected</title>
      <link>https://insinuator.net/2013/11/troopers-2014-first-round-of-talks-selected/</link>
      <pubDate>Sat, 16 Nov 2013 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2013/11/troopers-2014-first-round-of-talks-selected/</guid>
      <description>&lt;p&gt;We’re delighted to provide the first announcement of talks of next year’s &lt;a href=&#34;http://www.troopers.de&#34;&gt;Troopers&lt;/a&gt; edition. Looks like it’s going to be a great event again 😉&lt;br&gt;&#xA;Here we go:&lt;/p&gt;&#xA;&lt;p&gt;==================&lt;/p&gt;&#xA;&lt;p&gt;Toby Kohlenberg: Granular Trust – Making it Work&lt;/p&gt;&#xA;&lt;p&gt;Over the last 5 years the concept of using dynamic or granular trust models to control access to systems, networks and applications has become well known and is now seeing partial adoption in many places. The challenge is how granular and dynamic can you get and the question is whether it is worth it. As the architect of Intel’s trust model Toby can speak to the entire journey from initial idea through current implementation and the likely road ahead. This talk will include the good, bad and ugly parts of designing a trust model and then implementing it in a Fortune 50 company’s production environment. You will learn from his mistakes so you can make different ones.&lt;/p&gt;</description>
    </item>
    <item>
      <title>IPv6 Scanner</title>
      <link>https://insinuator.net/2013/11/ipv6-scanner/</link>
      <pubDate>Sat, 09 Nov 2013 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2013/11/ipv6-scanner/</guid>
      <description>&lt;p&gt;This is a guest post from Antonios Atlasis.&lt;/p&gt;&#xA;&lt;p&gt;===&lt;/p&gt;&#xA;&lt;p&gt;Having just finished the second &lt;a href=&#34;https://www.ernw.de/wp-content/uploads/M44b-Advanced_Attack_Techniques-06_11_2013_Heidelberg.pdf&#34;&gt;“Advanced Attack Techniques against IPv6 Networks” workshop&lt;/a&gt; (some of the course material can be found &lt;a href=&#34;http://www.insinuator.net/2013/06/slides-scripts-from-antonios-atlasis-advanced-attack-techniques-against-ipv6-networks-workshop/&#34;&gt;here&lt;/a&gt;), organised and hosted by ERNW and their partner &lt;a href=&#34;http://hmtrainingsolutions.com/en.html&#34;&gt;HM Training Solutions&lt;/a&gt;, I would like to take this opportunity to release publicly one of my scripting tools, an IPv6 scanner. This tool is based on Scapy (so you have to install Scapy and its prerequisites before using it). It should not be considered as a replacement or a competitor of nmap against IPv6 or of the scanners incorporated into the great IPv6 toolkits already released by &lt;a href=&#34;https://www.thc.org/thc-ipv6/&#34;&gt;Marc Heuse&lt;/a&gt; and &lt;a href=&#34;http://www.si6networks.com/tools/ipv6toolkit/index.html&#34;&gt;Fernando Gont&lt;/a&gt;, but, instead, as a tool released mainly for educational purposes. Specifically, this scanner, apart from supporting some of the most well known port scanning techniques, from ping scanning to SYN, RESET, ACK, XMAS, etc., etc., TCP or UDP scanning, it also combines, by using the suitable switches, some IDS/IPS evasion techniques. As I have found out up to now, at least two of them, if used “properly”, can be effective against a very popular IDS/IPS software used by many “Fortune 100” companies out there. This means that you can launch actually any type of the supported network-scanning techniques while flying under the radar of this specific IDS software (and perhaps some other too, who knows…). But first of all, as always please check the corresponding README file.&lt;/p&gt;</description>
    </item>
    <item>
      <title>IPAM Requirements in IPv6 Networks</title>
      <link>https://insinuator.net/2013/10/ipam-requirements-in-ipv6-networks/</link>
      <pubDate>Thu, 24 Oct 2013 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2013/10/ipam-requirements-in-ipv6-networks/</guid>
      <description>&lt;p&gt;I recently had a discussion with some practitioners about requirements to IP Address Management (IPAM) solutions which are specific for IPv6 networks. We came up with the following:&lt;/p&gt;&#xA;&lt;p&gt;Mandatory: Track all dynamic IPv6 assignments (SLAAC + PrivExtensions, DHCP etc.), by polling neighbor caches from network devices. Support SNMPv3 for this task.&lt;br&gt;&#xA;Optional (read: nice-to-have): support other methods than SNMP to gather this info (e.g. SSH-ing into devices and execution of appropriate “show” commands).&lt;/p&gt;</description>
    </item>
    <item>
      <title>The Impact of Pervasive Monitoring on Corporate InfoSec</title>
      <link>https://insinuator.net/2013/10/the-impact-of-pervasive-monitoring-on-corporate-infosec/</link>
      <pubDate>Wed, 23 Oct 2013 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2013/10/the-impact-of-pervasive-monitoring-on-corporate-infosec/</guid>
      <description>&lt;p&gt;A few weeks ago I gave a presentation with the above title at some corporate infosec event. Given I’ve been asked for the slides many times now, I’ve converted them to a PDF which can be found &lt;a href=&#34;https://www.ernw.de/download/ERNW_Pervasive_Monitoring_Corporate_InfoSec_web.pdf&#34;&gt;here&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;p&gt;We hope to contribute to the necessary debate thereby…&lt;/p&gt;&#xA;&lt;p&gt;Have a good one,&lt;/p&gt;&#xA;&lt;p&gt;Enno&lt;/p&gt;</description>
    </item>
    <item>
      <title>IPv6 Hackers Meeting @ IETF 87 in Berlin / Slides</title>
      <link>https://insinuator.net/2013/08/ipv6-hackers-meeting-@-ietf-87-in-berlin-/-slides/</link>
      <pubDate>Thu, 01 Aug 2013 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2013/08/ipv6-hackers-meeting-@-ietf-87-in-berlin-/-slides/</guid>
      <description>&lt;p&gt;&lt;a href=&#34;http://www.ipv6hackers.org/meetings/berlin-2013&#34;&gt;That meeting&lt;/a&gt; was actually a great event. Once more, big thanks! to Fernando for organizing it and to &lt;a href=&#34;http://www.eantc.com/&#34;&gt;EANTC&lt;/a&gt; for providing the logistics.&lt;br&gt;&#xA;A couple of unordered notes to follow:&lt;/p&gt;&#xA;&lt;p&gt;a) The slides of our contribution can be found &lt;a href=&#34;http://www.ernw.de/download/ERNW_IETF87_IPv6Hackers_Capabilities_v0_9.pdf&#34;&gt;here&lt;/a&gt;. Again, pls note that this is work in progress and we’re happy to receive any kind of feedback.&lt;br&gt;&#xA;[given Fernando explicitly mentioned Troopers, we’ve allowed ourselves to put some reference to it into this version of the slide deck…]&lt;/p&gt;</description>
    </item>
    <item>
      <title>SNMP Reflected Amplification DDoS Attacks</title>
      <link>https://insinuator.net/2013/07/snmp-reflected-amplification-ddos-attacks/</link>
      <pubDate>Wed, 31 Jul 2013 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2013/07/snmp-reflected-amplification-ddos-attacks/</guid>
      <description>&lt;p&gt;Just recently on the NANOG mailing list a discussion popped up titled “&lt;a href=&#34;http://mailman.nanog.org/pipermail/nanog/2013-July/060094.html&#34;&gt;SNMP DDoS: the vulnerability you might not know you have&lt;/a&gt;“.&lt;br&gt;&#xA;There’s a couple of points here:&lt;/p&gt;&#xA;&lt;p&gt;a) if you’re interested in the technical details of these attacks (and mitigation advice), pls see &lt;a href=&#34;http://www.bitag.org/documents/SNMP-Reflected-Amplification-DDoS-Attack-Mitigation.pdf&#34;&gt;this excellent technical&lt;/a&gt; report the Broadband Internet Technical Advisory Group published last year (apparently Comcast &lt;a href=&#34;ttp://corporate.comcast.com/comcast-voices/taking-steps-to-prevent-unintentional-network-abuse&#34;&gt;had observed&lt;/a&gt; such attacks before).&lt;/p&gt;&#xA;&lt;p&gt;b) Daniel and I gave a &lt;a href=&#34;https://www.ernw.de/download/ERNW_HITB_Dubai_2007_Attacking_SNMP.pdf&#34;&gt;talk on attacking SNMP&lt;/a&gt; at HITB Dubai 2007 (&lt;a href=&#34;http://conference.hitb.org/&#34;&gt;Hi Amy &amp;amp; Dhillon! 😉&lt;/a&gt;) laying out the basic idea for that type of attack and we later described it in a bit more detail at &lt;a href=&#34;http://www.shmoocon.org/shmoocon_2009&#34;&gt;ShmooCon 2009&lt;/a&gt; where we even demoed it publicly (camera recording stopped at that point, for obvious reasons). We used (a slightly modified version of) &lt;a href=&#34;https://www.ernw.de/download/snmpattack.pl&#34;&gt;this tool&lt;/a&gt;.&lt;br&gt;&#xA;From the research we did at the time we can confirm this was/presumably still is a huge problem, at least for European carriers’ broadband segments (acting as amplifiers).&lt;/p&gt;</description>
    </item>
    <item>
      <title>Responsible Disclosure and Academic Freedom, Again</title>
      <link>https://insinuator.net/2013/07/responsible-disclosure-and-academic-freedom-again/</link>
      <pubDate>Sat, 27 Jul 2013 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2013/07/responsible-disclosure-and-academic-freedom-again/</guid>
      <description>&lt;p&gt;Reading &lt;a href=&#34;http://www.guardian.co.uk/technology/2013/jul/26/scientist-banned-revealing-codes-cars&#34;&gt;this article&lt;/a&gt; from the Guardian,  on &lt;a href=&#34;http://www.cs.ru.nl/~flaviog/&#34;&gt;this guy&lt;/a&gt; apparently being banned from fully discussing research results in &lt;a href=&#34;https://www.usenix.org/conference/usenixsecurity13/dismantling-megamos-crypto-wirelessly-lockpicking-vehicle-immobilizer&#34;&gt;his talk&lt;/a&gt; at upcoming &lt;a href=&#34;https://www.usenix.org/conference/usenixsecurity13&#34;&gt;USENIX Security&lt;/a&gt;, leaves me scratching my head once more. Things might (as so often) be more complex than they seem, but this looks like yet-another misconception as for the contribution of security research (and its public discussion) to the greater good of us all. Which is unfortunate for the speakers (I’ve been in a similar situation once, receiving a threatening legal letter from a very large organization one day before one of our Black Hat presentations and can tell you that stuff like that doesn’t add to one’s anticipation of the talk or the event…), for the audience (including some ERNW guys who will be a USENIX-SEC, so, btw, expect a summary post here) and for the whole community of security researchers.&lt;/p&gt;</description>
    </item>
    <item>
      <title>IPv6 Hackers Meeting @ IETF 87, Berlin</title>
      <link>https://insinuator.net/2013/07/ipv6-hackers-meeting-@-ietf-87-berlin/</link>
      <pubDate>Fri, 26 Jul 2013 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2013/07/ipv6-hackers-meeting-@-ietf-87-berlin/</guid>
      <description>&lt;p&gt;Next to &lt;a href=&#34;https://www.ietf.org/meeting/87/index.html&#34;&gt;IETF 87&lt;/a&gt; going on in Berlin in a few days there will be an &lt;a href=&#34;http://www.ipv6hackers.org/meetings/berlin-2013&#34;&gt;informal meeting of the “IPv6 Hackers”&lt;/a&gt; on Tuesday. We really look forward to personally meet a number of people who we (so far) only know from the associated &lt;a href=&#34;http://www.si6networks.com/community/mailing-lists.html&#34;&gt;mailing list&lt;/a&gt; or similar machine-enhanced exchange. We hope to contribute as well. Based on the stuff of &lt;a href=&#34;https://www.troopers.de/archives/troopers13/agenda13/troopers13-ipv6-security-summit-2013/troopers13-ipv6-security-summit-2013-workshop-overview-of-the-real-world-capabilities-of-major-commercial-security-products/index.html&#34;&gt;this workshop&lt;/a&gt; from the &lt;a href=&#34;https://www.troopers.de/archives/troopers13/agenda13/troopers13-ipv6-security-summit-2013/index.html&#34;&gt;IPv6 Security Summit&lt;/a&gt; at &lt;a href=&#34;http://www.troopers.de&#34;&gt;Troopers13&lt;/a&gt; we might give a short project presentation along the lines of “Some Notes on Testing the Real-World IPv6 Capabilities of Commercial Security Products”, providing an overview of some testing done on commercial gear, together with a discussion of testing approaches, tools and key aspects.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Some Notes on Types of Security Controls &amp; the Way they’re Implemented in Enterprise Environments</title>
      <link>https://insinuator.net/2013/07/some-notes-on-types-of-security-controls-the-way-theyre-implemented-in-enterprise-environments/</link>
      <pubDate>Sun, 21 Jul 2013 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2013/07/some-notes-on-types-of-security-controls-the-way-theyre-implemented-in-enterprise-environments/</guid>
      <description>&lt;p&gt;Welcome back, Dear Reader,&lt;/p&gt;&#xA;&lt;p&gt;in this post I’d like to share some reflections on the (potentially inefficient) way some security controls can be observed to be deployed in complex organisations and what this may mean for the future of those controls.&lt;/p&gt;&#xA;&lt;p&gt;In general the space of security controls can be categorized according to different schemes, such as:&lt;/p&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;By fundamental principle (preventive, detective, reactive, corrective, deterrent, compensating etc. security controls. see for example this &lt;a href=&#34;http://www.sans.edu/research/security-laboratory/article/security-controls&#34;&gt;overview&lt;/a&gt; or &lt;a href=&#34;http://www.mhprofessional.com/downloads/products/0072254238/0072254238_ch01.pdf&#34;&gt;this one&lt;/a&gt; or some illustration &lt;a href=&#34;https://www.troopers.de/wp-content/uploads/2012/10/TROOPERS09_rey_keynote_stop_the_madness.pdf&#34;&gt;here&lt;/a&gt;).&lt;/li&gt;&#xA;&lt;li&gt;By “state of matter” (e.g. components, implementation, operations. again, for some supplemental information look at &lt;a href=&#34;https://www.troopers.de/wp-content/uploads/2012/10/TROOPERS09_rey_keynote_stop_the_madness.pdf&#34;&gt;this one&lt;/a&gt;).&lt;/li&gt;&#xA;&lt;li&gt;By type of admission: whitelisting vs. blacklisting (some general discussion &lt;a href=&#34;http://kevtownsend.wordpress.com/2011/08/24/whitelisting-vs-blacklisting/&#34;&gt;here&lt;/a&gt;, the respective Schneier-Ranum Face-Off to be found &lt;a href=&#34;http://searchsecurity.techtarget.com/magazineContent/Schneier-Ranum-Face-Off-on-whitelisting-and-blacklisting&#34;&gt;here&lt;/a&gt;, and &lt;a href=&#34;http://www.schneier.com/blog/archives/2011/01/whitelisting_vs.html&#34;&gt;this&lt;/a&gt; is only Bruce’s half, but with a number of comments).&lt;/li&gt;&#xA;&lt;li&gt;Related to the overall architecture of implementation: centralized vs. distributed.&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;p&gt;For today’s topic I’ll just focus on the latter two and will introduce those shortly.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Ganz Gallien?</title>
      <link>https://insinuator.net/2013/07/ganz-gallien/</link>
      <pubDate>Sun, 14 Jul 2013 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2013/07/ganz-gallien/</guid>
      <description>&lt;p&gt;“Nein! Ein von unbeugsamen Galliern bevölkertes Dorf hört nicht auf, dem Eindringling Widerstand zu leisten.”&lt;/p&gt;&#xA;&lt;p&gt;This is a famous quote pretty much every German kid used to know. Not sure if this still applies though, my three haven’t touched Asterix comics so far. Anyhow, you might ask why I cite this.&lt;/p&gt;&#xA;&lt;p&gt;Simple answer: see &lt;a href=&#34;http://www.guardian.co.uk/world/2013/jul/09/xmission-isp-customers-privacy-nsa&#34;&gt;this recent article&lt;/a&gt; from the Guardian on a Utah-based ISP “resisting some pressure”. That’s the spirit…&lt;/p&gt;&#xA;&lt;p&gt;Have a great Sunday everybody,&lt;/p&gt;</description>
    </item>
    <item>
      <title>Slides &amp; Scripts from Antonios Atlasis’ “Advanced Attack Techniques against IPv6 Networks” Workshop</title>
      <link>https://insinuator.net/2013/06/slides-scripts-from-antonios-atlasis-advanced-attack-techniques-against-ipv6-networks-workshop/</link>
      <pubDate>Tue, 25 Jun 2013 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2013/06/slides-scripts-from-antonios-atlasis-advanced-attack-techniques-against-ipv6-networks-workshop/</guid>
      <description>&lt;p&gt;After his great presentations on &lt;a href=&#34;https://www.troopers.de/archives/troopers13/agenda13/troopers13-ipv6-security-summit-2013/troopers13-ipv6-security-summit-2013-presentations/index.html#extension_headers&#34;&gt;IPv6 Extensions Headers&lt;/a&gt; and &lt;a href=&#34;https://www.troopers.de/archives/troopers13/agenda13/troopers13-ipv6-security-summit-2013/troopers13-ipv6-security-summit-2013-presentations/index.html#fragmentation_overlapping&#34;&gt;security problems related to fragmentation&lt;/a&gt; we had invited Antonios Atlasis to Heidelberg to give  &lt;a href=&#34;https://www.ernw.de/wp-content/uploads/M44b-Advanced_Attack_Techniques_24-06-2013_Heidelberg.pdf&#34;&gt;this workshop&lt;/a&gt; at ERNW. It was a great experience with many fruitful discussions between the participants (mostly security practitioners from very large organizations planning to have their Internet edge IPv6 enabled within the next 6-12 months) and him/us. Antonios thankfully decided to make his &lt;a href=&#34;https://www.ernw.de/download/Advanced%20Attack%20Techniques%20against%20IPv6%20Networks-final.pdf&#34;&gt;slides&lt;/a&gt; and &lt;a href=&#34;https://www.ernw.de/download/Advanced_Attack_Techniques_Scripts.zip&#34;&gt;scripts&lt;/a&gt; available for those interested in further research on the topics (it should be noted that the scripts have not been tested thoroughly and he’s happy to receive feedback of any kind at antoniosDOTatlasisDOTgmailDOTcom). Today Marc (Heuse) gives &lt;a href=&#34;https://www.ernw.de/wp-content/uploads/M44a-PentestWorkshop_25-06-2013_Heidelberg.pdf&#34;&gt;his workshop&lt;/a&gt; on pentesting in the IPv6 age. Hopefully such events help to move things into the right direction in the IPv6 security space…&lt;/p&gt;</description>
    </item>
    <item>
      <title>Microsoft Doc “Best Practices for Securing Active Directory”</title>
      <link>https://insinuator.net/2013/06/microsoft-doc-best-practices-for-securing-active-directory/</link>
      <pubDate>Wed, 05 Jun 2013 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2013/06/microsoft-doc-best-practices-for-securing-active-directory/</guid>
      <description>&lt;p&gt;Hi,&lt;/p&gt;&#xA;&lt;p&gt;MS just &lt;a href=&#34;http://blogs.technet.com/b/security/archive/2013/06/03/microsoft-releases-new-mitigation-guidance-for-active-directory.aspx&#34;&gt;released&lt;/a&gt; a new guide on securing Active Directory. At the first glance seems a fairly comprehensive document to me.&lt;/p&gt;&#xA;&lt;p&gt;At this occasion I may furthermore draw your attention to our (German language) &lt;a href=&#34;https://www.ernw.de/wp-content/uploads/ERNW_Newsletter_40_AD_SRV2008R2_BSI_compliant_de_signed.pdf&#34;&gt;newsletter no. 40&lt;/a&gt; covering hardening MS Windows Server 2008 + AD.&lt;/p&gt;&#xA;&lt;p&gt;have a good one,&lt;/p&gt;&#xA;&lt;p&gt;Enno&lt;/p&gt;</description>
    </item>
    <item>
      <title>Troopers13 Videos Online</title>
      <link>https://insinuator.net/2013/06/troopers13-videos-online/</link>
      <pubDate>Sat, 01 Jun 2013 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2013/06/troopers13-videos-online/</guid>
      <description>&lt;p&gt;Hi,&lt;/p&gt;&#xA;&lt;p&gt;as we’ve received quite some requests re: the videos from &lt;a href=&#34;http://www.troopers.de&#34;&gt;Troopers&lt;/a&gt; 2013: the YouTube playlist can be found &lt;a href=&#34;https://www.youtube.com/playlist?list=PL1eoQr97VfJl1LdMzyQPz71uR6bwiUGog&#34;&gt;here&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;p&gt;Have fun (and learn something ;-)) watching, cu next year&lt;/p&gt;&#xA;&lt;p&gt;Enno&lt;/p&gt;</description>
    </item>
    <item>
      <title>RA Guard (Evasion) – We Stand Corrected</title>
      <link>https://insinuator.net/2013/05/ra-guard-evasion-we-stand-corrected/</link>
      <pubDate>Mon, 20 May 2013 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2013/05/ra-guard-evasion-we-stand-corrected/</guid>
      <description>&lt;p&gt;Recently  &lt;a href=&#34;http://6lab.cz/article/author/xpivar00/&#34; title=&#34;Posts by Jozef Pivarník&#34;&gt;Jozef Pivarník&lt;/a&gt; and &lt;a href=&#34;http://6lab.cz/article/author/gregr/&#34; title=&#34;Posts by Matěj Grégr&#34;&gt;Matěj Grégr&lt;/a&gt; published an &lt;a href=&#34;http://6lab.cz/article/rogue-router-advertisement-attack/&#34;&gt;excellent write-up&lt;/a&gt; on RA Guard &amp;amp; evasion techniques. Amongst others they tested the “undetermined-transport” ACL we described &lt;a href=&#34;http://www.insinuator.net/2013/04/some-more-notes-on-ra-guard-evasion-and-undetermined-transport/&#34;&gt;here&lt;/a&gt; and &lt;a href=&#34;http://www.insinuator.net/2012/03/the-story-continues-another-ipv6-update/&#34;&gt;here&lt;/a&gt;. As it turns out the “workaround” for implementing &lt;em&gt;undetermined-transport&lt;/em&gt; on platforms seemingly not supporting it, causes some bad collateral damage: the respective port does not forward &lt;em&gt;any&lt;/em&gt; IPv6 packets any more (this was brought to my attention by Roberto Taccon). We had done some tests after applying it (by means of the “workaround”) but we had just looked at fragmented RA packets (which did not get through =&amp;gt; test succeeded). So, frankly: the undetermined-transport trick does not make sense at all on the “unsupported platforms”…&lt;/p&gt;</description>
    </item>
    <item>
      <title>IPv6 Attacks &amp; Pentesting Workshops</title>
      <link>https://insinuator.net/2013/05/ipv6-attacks-pentesting-workshops/</link>
      <pubDate>Tue, 14 May 2013 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2013/05/ipv6-attacks-pentesting-workshops/</guid>
      <description>&lt;p&gt;Due to “popular demand” and given &lt;a href=&#34;http://www.mh-sec.de/&#34;&gt;Marc&lt;/a&gt; couldn’t join us at the &lt;a href=&#34;https://www.troopers.de/archives/troopers13/agenda13/troopers13-ipv6-security-summit-2013/index.html&#34;&gt;IPv6 Security Summit&lt;/a&gt; (as flights into FRA were canceled that day due to snow) we decided to invite him and &lt;a href=&#34;https://www.troopers.de/archives/troopers13/agenda13/troopers13-ipv6-security-summit-2013/troopers13-ipv6-security-summit-2013-presentations/index.html#extension_headers&#34;&gt;Antonios Atlasis&lt;/a&gt; another time, to present their knowledge, skills &amp;amp; voodoo in two workshops held in Heidelberg, in late June. More details can be found &lt;a href=&#34;https://www.ernw.de/newsfeed/ipv6-attacks-pentesting-workshops/index.html&#34;&gt;here&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;p&gt;See you all potentially at the Heise IPv6 Kongress, take care&lt;/p&gt;&#xA;&lt;p&gt;Enno&lt;/p&gt;&#xA;&lt;p&gt; &lt;/p&gt;</description>
    </item>
    <item>
      <title>RA Guard Support</title>
      <link>https://insinuator.net/2013/05/ra-guard-support/</link>
      <pubDate>Thu, 02 May 2013 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2013/05/ra-guard-support/</guid>
      <description>&lt;p&gt;Hi,&lt;/p&gt;&#xA;&lt;p&gt;on the &lt;a href=&#34;http://lists.cluenet.de/mailman/listinfo/ipv6-ops&#34;&gt;[ipv6-ops]&lt;/a&gt; mailing list currently there’s some discussion about RA guard support on switches from different vendors.&lt;/p&gt;&#xA;&lt;p&gt;Stefan, one of our students (btw: working on a topic similar to this &lt;a href=&#34;https://www.troopers.de/archives/troopers13/agenda13/troopers13-ipv6-security-summit-2013/troopers13-ipv6-security-summit-2013-workshop-overview-of-the-real-world-capabilities-of-major-commercial-security-products/index.html&#34;&gt;session&lt;/a&gt;), quickly put together a preliminary list, based on publicly available information (read: the WWW ;-)). Some of you may find this useful; it can be found &lt;a href=&#34;https://www.ernw.de/download/raguard_support_05022013.pdf&#34;&gt;here&lt;/a&gt;. Furthermore on the list &lt;a href=&#34;http://www.forwardingplane.net/2011/03/ipv6-features-matrix-for-network-hardware/&#34;&gt;this link&lt;/a&gt; was mentioned which seems to provide some info as well (albeit potentially not very up-to-date).&lt;/p&gt;</description>
    </item>
    <item>
      <title>Presentations from TR13 TelcoSecDay Online</title>
      <link>https://insinuator.net/2013/04/presentations-from-tr13-telcosecday-online/</link>
      <pubDate>Sun, 28 Apr 2013 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2013/04/presentations-from-tr13-telcosecday-online/</guid>
      <description>&lt;p&gt;Hi,&lt;/p&gt;&#xA;&lt;p&gt;just to let you know that all presentations from this year’s &lt;a href=&#34;https://www.troopers.de/archives/troopers13/agenda13/troopers13-telcosec-day-2013/index.html&#34;&gt;TelcoSecDay&lt;/a&gt; are published in the interim. (Harald [Welte] couldn’t participate as in the morning of that day FRA airport was closed on short notice).&lt;/p&gt;&#xA;&lt;p&gt;Next year’s TSD will happen on 03/18/2014.&lt;/p&gt;&#xA;&lt;p&gt;Take care,&lt;/p&gt;&#xA;&lt;p&gt;Enno&lt;/p&gt;&#xA;&lt;p&gt; &lt;/p&gt;</description>
    </item>
    <item>
      <title>BPDU Guard in Virtualized Environments (2)</title>
      <link>https://insinuator.net/2013/04/bpdu-guard-in-virtualized-environments-2/</link>
      <pubDate>Wed, 17 Apr 2013 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2013/04/bpdu-guard-in-virtualized-environments-2/</guid>
      <description>&lt;p&gt;Just a quick update here: Ivan (who gave the magnificent &lt;a href=&#34;https://www.troopers.de/archives/troopers13/agenda13/troopers13-presentations/index.html#virtual_firewalls&#34;&gt;Virtual Firewalls&lt;/a&gt; talk at &lt;a href=&#34;http://www.troopers.de&#34;&gt;Troopers&lt;/a&gt; recently) blogged about this and some guy added some feedback from an environment with Cisco FEX and “one of the server guys start[ing] a Citrix Netscaler” ;-). See the second comment to his &lt;a href=&#34;http://blog.ioshints.info/2013/04/vm-bpdu-spoofing-attack-works-quite.html&#34;&gt;post&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;p&gt;This shows, once more, that the dependencies of various technologies (and what they are used for) must be well understood in cloud/virtualized environments. Complexity … but who do we tell. Y’ all know that, right?&lt;/p&gt;</description>
    </item>
    <item>
      <title>Some more Notes on RA Guard Evasion and “undetermined-transport”</title>
      <link>https://insinuator.net/2013/04/some-more-notes-on-ra-guard-evasion-and-undetermined-transport/</link>
      <pubDate>Sat, 13 Apr 2013 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2013/04/some-more-notes-on-ra-guard-evasion-and-undetermined-transport/</guid>
      <description>&lt;p&gt;I just had an interesting discussion with Jim Small (who gives the “IPv6 Attacks and Countermeasures” talk at the &lt;a href=&#34;http://rmv6tf.org/na-ipv6-summit/2013-na-ipv6-summit/2013-agendaspeakers&#34;&gt;North American IPv6 Summit&lt;/a&gt; next week) about the feasibility of the “undetermined-transport” keyword in PACLs on Cisco 3560 switches (here running  IOS 15.0(2)SE). Actually there’s some kind-of funny behavior as for it on that platform (and there’s even some &lt;a href=&#34;http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/release/15.0_2_se/configuration/guide/swv6acl.html#wp4334642&#34;&gt;Cisco documentation stating it’s not supported&lt;/a&gt;). Let’s have a look, and start with a quick refresher.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Troopers13 IPv6 Security Summit – First Presentations Available</title>
      <link>https://insinuator.net/2013/03/troopers13-ipv6-security-summit-first-presentations-available/</link>
      <pubDate>Mon, 11 Mar 2013 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2013/03/troopers13-ipv6-security-summit-first-presentations-available/</guid>
      <description>&lt;p&gt;We had a great day today at the &lt;a href=&#34;https://www.troopers.de/agenda13/troopers13-ipv6-security-summit-2013/index.html&#34;&gt;Troopers IPv6 Security Summit&lt;/a&gt;. Good conversations, quite some technical discussion and a prevailing overall will to improve actual IPv6 network security.&lt;/p&gt;&#xA;&lt;p&gt;&lt;a href=&#34;https://www.ernw.de/download/IPv6%20Extension%20Headers%20-%20New%20Features,%20and%20New%20Attack%20Vectors.pdf&#34;&gt;Here&lt;/a&gt; are the slides of Antonios Atlasis’ great talk on extension headers and &lt;a href=&#34;https://www.ernw.de/download/IPv6%20Extension%20Headers%20-%20New%20Features,%20and%20New%20Attack%20Vectors.py&#34;&gt;these&lt;/a&gt; are some of his accompanying Python/Scapy scripts. My own presentation on high secure IPv6 networks can be found &lt;a href=&#34;https://www.ernw.de/download/ERNW_TR13_High_Secure_Networks_v1_0web.pdf&#34;&gt;here&lt;/a&gt;. The slides of the &lt;a href=&#34;https://www.troopers.de/agenda13/troopers13-ipv6-security-summit-2013/troopers13-ipv6-security-summit-2013-workshop-overview-of-the-real-world-capabilities-of-major-commercial-security-products/index.html&#34;&gt;real-world capabilities workshop&lt;/a&gt; will not be published yet as we first have to discuss some stuff with a vendor.&lt;/p&gt;</description>
    </item>
    <item>
      <title>IPv6 Neighbor Cache Exhaustion Attacks – Risk Assessment &amp; Mitigation Strategies, Part 1</title>
      <link>https://insinuator.net/2013/03/ipv6-neighbor-cache-exhaustion-attacks-risk-assessment-mitigation-strategies-part-1/</link>
      <pubDate>Tue, 05 Mar 2013 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2013/03/ipv6-neighbor-cache-exhaustion-attacks-risk-assessment-mitigation-strategies-part-1/</guid>
      <description>&lt;p&gt;Recently there has been quite some discussion about so-called neighbor cache exhaustion (“NCE”) attacks in the IPv6 world. &lt;a href=&#34;http://inconcepts.biz/~jsw/IPv6_NDP_Exhaustion.pdf&#34;&gt;This&lt;/a&gt; is Jeff Wheeler’s “classic paper” on the subject, my kind-of personal networking guru &lt;a href=&#34;https://www.troopers.de/agenda13/troopers13-presentations/index.html#virtual_firewalls&#34;&gt;Ivan Pepelnjak&lt;/a&gt; &lt;a href=&#34;http://blog.ioshints.info/2011/05/ipv6-neighbor-discovery-exhaustion.html&#34;&gt;blogged&lt;/a&gt; about it back some time, &lt;a href=&#34;https://groups.google.com/forum/?fromgroups=#!topic/ipv6hackers/cFCcsjnhImw&#34;&gt;here&lt;/a&gt;‘s a related discussion on the IPv6 hackers mailing list and in March 2012 (only three months after the respective IETF draft’s version 0 was released) the &lt;a href=&#34;%20https://tools.ietf.org/html/rfc6583&#34;&gt;RFC 6583&lt;/a&gt; was published, covering various protection strategies.&lt;/p&gt;</description>
    </item>
    <item>
      <title>IPv6 Security Problems Related to Extension Headers &amp; Fragmentation</title>
      <link>https://insinuator.net/2013/03/ipv6-security-problems-related-to-extension-headers-fragmentation/</link>
      <pubDate>Mon, 04 Mar 2013 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2013/03/ipv6-security-problems-related-to-extension-headers-fragmentation/</guid>
      <description>&lt;p&gt;&lt;a href=&#34;http://www.mh-sec.de/&#34;&gt;Marc Heuse&lt;/a&gt; – who happens to give &lt;a href=&#34;https://www.troopers.de/agenda13/troopers13-ipv6-security-summit-2013/troopers13-ipv6-security-summit-2013-workshop-penetration-testing-in-ipv6-networks/index.html&#34;&gt;this workshop&lt;/a&gt; at the &lt;a href=&#34;https://www.troopers.de/agenda13/troopers13-ipv6-security-summit-2013/index.html&#34;&gt;Troopers IPv6 Security Summit&lt;/a&gt; next week – just sent &lt;a href=&#34;http://lists.si6networks.com/pipermail/ipv6hackers/2013-March/000972.html&#34;&gt;this email&lt;/a&gt; (subject: “Remote system freeze thanks to Kaspersky Internet Security 2013”) to the &lt;a href=&#34;http://lists.si6networks.com/listinfo/ipv6hackers/&#34;&gt;IPv6 hackers mailing list&lt;/a&gt;, describing how a system running a certain flavor of Kaspersky security products can be remotely frozen when receiving IPv6 packets with a specific combination of extension headers and fragmentation (which in turn can be easily generated by his &lt;a href=&#34;www.thc.org/thc-ipv6&#34;&gt;IPv6 protocol attack suite&lt;/a&gt;).&lt;/p&gt;</description>
    </item>
    <item>
      <title>APT</title>
      <link>https://insinuator.net/2013/02/apt/</link>
      <pubDate>Thu, 21 Feb 2013 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2013/02/apt/</guid>
      <description>&lt;p&gt;Many of you have probably seen the public media coverage (e.g. [&lt;a href=&#34;http://www.nytimes.com/2013/02/19/technology/chinas-army-is-seen-as-tied-to-hacking-against-us.html?hp&amp;amp;_r=0&#34;&gt;1&lt;/a&gt;], [&lt;a href=&#34;http://www.spiegel.de/politik/ausland/chinas-armee-soll-beruechtigte-hacker-truppe-betreiben-a-884164.html&#34;&gt;2&lt;/a&gt;]) of  Mandiant’s &lt;a href=&#34;http://intelreport.mandiant.com/Mandiant_APT1_Report.pdf&#34;&gt;latest report&lt;/a&gt; on APT.&lt;/p&gt;&#xA;&lt;p&gt;Just to let you know: &lt;a href=&#34;https://www.troopers.de/agenda13/index.html&#34;&gt;Trooper&lt;/a&gt;‘s traditional panel discussion on the first day will be on APT this year. So if you want to discuss the topic with other practitioners from the field, join us there.&lt;/p&gt;&#xA;&lt;p&gt;have a great day&lt;/p&gt;&#xA;&lt;p&gt;Enno&lt;/p&gt;</description>
    </item>
    <item>
      <title>TROOPERS13: TelcoSecDay, IPv6 Security Summit and some more Updates</title>
      <link>https://insinuator.net/2013/02/troopers13-telcosecday-ipv6-security-summit-and-some-more-updates/</link>
      <pubDate>Sat, 02 Feb 2013 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2013/02/troopers13-telcosecday-ipv6-security-summit-and-some-more-updates/</guid>
      <description>&lt;p&gt;Here’s a number of updates as for upcoming &lt;a href=&#34;https://www.troopers.de/&#34;&gt;TROOPERS13&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;p&gt;The preliminary agenda for this year’s TelcoSecDay can be found &lt;a href=&#34;https://www.troopers.de/agenda13/troopers13-telcosec-day-2013/index.html&#34;&gt;here&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;p&gt;&lt;a href=&#34;https://www.troopers.de/agenda13/troopers13-ipv6-security-summit-2013/index.html&#34;&gt;Here&lt;/a&gt;‘s the (again: preliminary) agenda of the IPv6 Security Summit.&lt;/p&gt;&#xA;&lt;p&gt;Last, but not least we’ve included another four talks in the main conference:&lt;/p&gt;&#xA;&lt;p&gt;======&lt;/p&gt;&#xA;&lt;p&gt;Sergey Bratus &amp;amp; Travis Goodspeed: You wouldn’t share a syringe. Would you share a USB port?&lt;/p&gt;&#xA;&lt;p&gt;Synopsis: Previous work has shown that a USB port left unattended may be subject to pwnage via insertion of a device that types into your command shell (e.g. &lt;a href=&#34;http://www.social-engineer.org/framework/Computer_Based_Social_Engineering_Tools:_Social_Engineer_Toolkit_(SET)#Teensy_USB_HID_Attack_Vector&#34;&gt;here&lt;/a&gt;). Impressive attack payloads have been delivered over USB to &lt;a href=&#34;http://arstechnica.com/gaming/2010/08/the-ps3-jailbroken-usb-hack-allows-homebrew-copied-games/&#34;&gt;jailbreak PS3&lt;/a&gt; and a “&lt;a href=&#34;https://www.usenix.org/sites/default/files/conference/protected-files/michele_woot12_slides.pdf&#34;&gt;smart TV&lt;/a&gt;“. Not surprisingly, USB stacks started incorporating defenses such as device registration, USB firewalls, and other protective kits. But do these protective measures go far enough to let you safely plug in a strange thumb drive into your laptop’s USB port?&lt;/p&gt;</description>
    </item>
    <item>
      <title>Troopers 2013 – Third Round of Talks Selected</title>
      <link>https://insinuator.net/2013/01/troopers-2013-third-round-of-talks-selected/</link>
      <pubDate>Thu, 17 Jan 2013 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2013/01/troopers-2013-third-round-of-talks-selected/</guid>
      <description>&lt;p&gt;We’re very happy to announce the third round of Troopers 2013 talks today (first round &lt;a href=&#34;http://www.insinuator.net/2012/12/troopers-2013-first-round-of-talks-selected/&#34;&gt;here&lt;/a&gt;, second &lt;a href=&#34;http://www.insinuator.net/2013/01/troopers-2013-second-round-of-talks-selected/&#34;&gt;here&lt;/a&gt;).&lt;/p&gt;&#xA;&lt;p&gt;So much quality stuff… it seems to get (ever) better every year ;-).&lt;/p&gt;&#xA;&lt;p&gt;Here we go:&lt;/p&gt;&#xA;&lt;p&gt;==================&lt;/p&gt;&#xA;&lt;p&gt;&lt;strong&gt;Michael Ossmann &amp;amp; Dominic Spill: Introducing Daisho – monitoring multiple communication technologies at the physical layer.&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;&lt;strong&gt;Synopsis:&lt;/strong&gt; Most communications media can be monitored and debugged at various levels of the stack, but we believe that it is most important to examine them at the physical layer. From there, the security of every level can be investigated and tested. The task of monitoring physical layer communications has become increasingly difficult as we try to squeeze more and more bandwidth out of our links. A passive tapping circuit can be used to monitor a 100BASE-TX connections, but no such circuit exists for 1000BASE-T networks.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Troopers 2013 – Second Round of Talks Selected</title>
      <link>https://insinuator.net/2013/01/troopers-2013-second-round-of-talks-selected/</link>
      <pubDate>Thu, 10 Jan 2013 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2013/01/troopers-2013-second-round-of-talks-selected/</guid>
      <description>&lt;p&gt;We’re very happy to announce the second round of Troopers 2013 talks today (first round &lt;a href=&#34;http://www.insinuator.net/2012/12/troopers-2013-first-round-of-talks-selected/&#34;&gt;here&lt;/a&gt;).&lt;br&gt;&#xA;Some (well, actually most ;-)) of these talks haven’t been presented before, at any other occasion, so this is exciting fresh material which was/is prepared especially for &lt;a href=&#34;https://www.troopers.de/agenda13/index.html&#34;&gt;Troopers&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;p&gt;Here we go:&lt;/p&gt;&#xA;&lt;p&gt;==================&lt;/p&gt;&#xA;&lt;p&gt;&lt;strong&gt;Andreas Wiegenstein &amp;amp; Xu Jia: Ghost in the Shell.&lt;/strong&gt; &lt;strong&gt;FIRST TIME MATERIAL&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;&lt;strong&gt;Synopsis:&lt;/strong&gt; Security conferences in the past years have made it clear, that common security vulnerabilities such as SQL Injection, XSS, CSRF, HTTP verb tampering and many others also exist in SAP software. This talk covers several vulnerabilities that are unique to SAP systems and shows how these can be used in order to bypass crucial security mechanisms and at the same time operate completely below the (forensic) Radar. We uncovered undocumented mechanisms in the SAP kernel, that allow launching attacks that cannot be traced back to the attacker by forensic means. These mechanisms allow to *actively* inject commands at any time into the running backend-session of an arbitrary logged on user, chosen by the attacker. We named this attack mechanism “Ghost in the Shell”. We will also demo how to use this attack vector to distribute malware to the attacked user’s client machine despite mechanisms in the SAP standard that are designed to prevent this.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Insider Threats in the Cloud</title>
      <link>https://insinuator.net/2013/01/insider-threats-in-the-cloud/</link>
      <pubDate>Sat, 05 Jan 2013 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2013/01/insider-threats-in-the-cloud/</guid>
      <description>&lt;p&gt;at first a happy new year to all our readers!&lt;br&gt;&#xA;And, of course, to everybody else, too ;-). May 2013 bring good things for you all, in particular (but not only) in the infosec space.&lt;/p&gt;&#xA;&lt;p&gt;At the &lt;a href=&#34;http://www.acsac.org/&#34;&gt;recent ATSAC 2012 conference&lt;/a&gt; a guy from the CERT Insider Threat Center gave a talk on the exact topic. Given that the &lt;a href=&#34;http://www.enisa.europa.eu/activities/risk-management/files/deliverables/cloud-computing-risk-assessment/at_download/fullReport&#34;&gt;ENISA Cloud Computing Risk Assessment&lt;/a&gt; lists “Cloud Provider Malicious Insider” as one of the top eight risks (out of overall 35 risks evaluated) and we just had some discussion about this in a customer environment, this might be of interest for some readers.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Troopers 2013 – First Round of Talks Selected</title>
      <link>https://insinuator.net/2012/12/troopers-2013-first-round-of-talks-selected/</link>
      <pubDate>Sun, 23 Dec 2012 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2012/12/troopers-2013-first-round-of-talks-selected/</guid>
      <description>&lt;p&gt;We’re delighted to provide the first announcement of talks of next year’s Troopers edition. Looks like it’s going to be a great event again 😉&lt;br&gt;&#xA;Here we go:&lt;/p&gt;&#xA;&lt;p&gt;==================&lt;/p&gt;&#xA;&lt;p&gt;&lt;strong&gt;Peter Kieseberg: Malicious pixels – QR-codes as attack vectors.&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;**Synopsis: **QR-Codes, a version of two-dimensional barcodes that are able to store quite large amounts of information, started gaining huge popularity throughout the last few years, including all sorts of new applications for them. Originating from the area of logistics, they found their ways into marketing and since the rise of modern smartphones with their ability to scan them in the street; they can be found virtually everywhere, often linking to sites on the internet. Currently even standards for paying using QR-codes were proposed and standardized. In this talk we will highlight possible attack vectors arising from the use of QR-Codes. Furthermore we will outline an algorithm for calculating near-collisions in order to launch phishing attacks and we will demonstrate the practical utilization of this technique.&lt;/p&gt;</description>
    </item>
    <item>
      <title>IPv6 Privacy Extensions</title>
      <link>https://insinuator.net/2012/05/ipv6-privacy-extensions/</link>
      <pubDate>Mon, 14 May 2012 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2012/05/ipv6-privacy-extensions/</guid>
      <description>&lt;p&gt;Last week Christopher Werny and I gave a talk on IPv6 Privacy Extensions at the &lt;a href=&#34;http://www.ipv6-kongress.de/&#34;&gt;Heise IPv6 Kongress&lt;/a&gt;. As our slides were not included in the event’s material &lt;a href=&#34;http://ernw.de/download/ERNW_Privacy_Extensions.pdf&#34;&gt;here’s the presentation’s slide deck&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;p&gt;As &lt;a href=&#34;http://www.insinuator.net/2011/05/yet-another-update-on-ipv6-security-some-notes-from-the-ipv6-kongress-in-frankfurt/&#34;&gt;in 2011&lt;/a&gt; we really liked the conference; there was a number of interesting talks and we met quite some fellows from the IPv6 security space. Btw: we plan to organize a dedicated IPv6 security summit in late 2012 (probably on 6th and 7th of November) in Heidelberg, similar to the &lt;a href=&#34;http://www.troopers.de/archives/troopers12/agenda/telcosec-day/&#34;&gt;Telco Sec Day&lt;/a&gt; at Troopers. We’ll annouce details as for this one in some weeks.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Slides from Troopers Telco Sec Day Online</title>
      <link>https://insinuator.net/2012/05/slides-from-troopers-telco-sec-day-online/</link>
      <pubDate>Mon, 14 May 2012 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2012/05/slides-from-troopers-telco-sec-day-online/</guid>
      <description>&lt;p&gt;As I mentioned the Telco Sec Day in the last post… for those who missed Flo’s announcement: in the interim all slides of the Telco Sec Day are available online &lt;a href=&#34;http://www.troopers.de/archives/troopers12/downloads/&#34;&gt;here&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;p&gt;Obviously, given I initiated the event, I’m biased 😉 but to me it provided great insight from both the talks and the networking with other guys from the telco security field, and it did actually what it was meant for: fostering the exchange between different players in that space, for the sake of sustainably improving its’ overall security posture.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Troopers TelcoSecDay</title>
      <link>https://insinuator.net/2012/03/troopers-telcosecday/</link>
      <pubDate>Sat, 17 Mar 2012 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2012/03/troopers-telcosecday/</guid>
      <description>&lt;p&gt;As there has been some public demand for that, here we go with the final agenda for the Troopers “&lt;a href=&#34;http://www.troopers.de/troopers12/agenda/telcosec-day/&#34;&gt;TelcoSecDay&lt;/a&gt;“. The workshop is meant to provide a platform for research exchange between operators, vendors and researchers. The slides of the talks will potentially be made available as well.&lt;/p&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;8:30: Opening Remarks &amp;amp; Introduction&lt;/li&gt;&#xA;&lt;li&gt;9:00: Sebastian Schrittwieser (SBA Research): Guess Who’s Texting You? Evaluating the Security of Smartphone Messaging Applications.&lt;/li&gt;&#xA;&lt;li&gt;10:00: Peter Schneider (NSN): How to secure an LTE-Network: Just applying the 3GPP security standards and that’s it?&lt;/li&gt;&#xA;&lt;li&gt;10:45: Break&lt;/li&gt;&#xA;&lt;li&gt;11:00: Kevin Redon (T-Labs): Weaponizing Femtocells – The Effect of Rogue Devices on Mobile Telecommunications&lt;/li&gt;&#xA;&lt;li&gt;11:45: Christian Kagerhuber (Group IT Security, Deutsche Telekom AG): Security Compliance Audit Automation (SCA, TeleManagementForum TMF528)&lt;/li&gt;&#xA;&lt;li&gt;12:30: Lunch&lt;/li&gt;&#xA;&lt;li&gt;13:45: Philipp Langlois (P1 Security): Assault on the GRX (GPRS Roaming eXchange) from the Telecom Core Network perspective, from 2.5G to LTE Advanced.&lt;/li&gt;&#xA;&lt;li&gt;15:00: Break&lt;/li&gt;&#xA;&lt;li&gt;15:15: Harald Welte (sysmocom): Structural deficits in telecom security&lt;/li&gt;&#xA;&lt;li&gt;16:30: Closing Remarks&lt;/li&gt;&#xA;&lt;li&gt;17:00: End of workshop&lt;/li&gt;&#xA;&lt;li&gt;19:00: Joint dinner (hosted by ERNW) in Heidelberg Altstadt for those interested and/or staying for the main conference&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;p&gt;====&lt;/p&gt;</description>
    </item>
    <item>
      <title>Applying the ERNW Seven Sisters Approach to VoIP Networks</title>
      <link>https://insinuator.net/2012/03/applying-the-ernw-seven-sisters-approach-to-voip-networks/</link>
      <pubDate>Sat, 03 Mar 2012 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2012/03/applying-the-ernw-seven-sisters-approach-to-voip-networks/</guid>
      <description>&lt;p&gt;Hi,&lt;/p&gt;&#xA;&lt;p&gt;if you’re following this blog regularly or if you’ve ever attended an &lt;a href=&#34;http://www.hmtrainingsolutions.com/&#34;&gt;ERNW-led workshop&lt;/a&gt; which included an “architecture section” you will certainly remember the “Seven Sisters of Infrastructure Security” stuff (used for example in &lt;a href=&#34;http://www.insinuator.net/2011/01/ipv6-security-part-1-ra-guard-the-theory-3/&#34;&gt;this post&lt;/a&gt;). These are a number of (well, more precisely, it’s seven ;-)) fundamental security principles which can be applied to any complex infrastructure, be that a network, a building, an airport or the like.&lt;/p&gt;&#xA;&lt;p&gt;As part of our upcoming &lt;a href=&#34;https://www.blackhat.com/html/bh-eu-12/bh-eu-12-briefings.html#rey&#34;&gt;Black Hat&lt;/a&gt; and &lt;a href=&#34;http://www.troopers.de/troopers12/agenda/protecting-voice-over-ip-in-2012/&#34;&gt;Troopers&lt;/a&gt; talks we will apply those principles to some VoIP networks we (security-) assessed and, given we won’t cover them in detail there, it might be helpful to perform a quick refresher of them, together with an initial application to VoIP deployments. Here we go; these are the “Seven Sisters of Infrastructure Security”:&lt;/p&gt;</description>
    </item>
    <item>
      <title>A Structured Approach to Handling External Connections, Part 1</title>
      <link>https://insinuator.net/2012/02/a-structured-approach-to-handling-external-connections-part-1/</link>
      <pubDate>Fri, 03 Feb 2012 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2012/02/a-structured-approach-to-handling-external-connections-part-1/</guid>
      <description>&lt;p&gt;I’m currently involved in creating an up to date approach to handling external connections (read: temporary/permanent connections with external parties like business partners) of a very large enterprise. Currently they have sth along the lines of: “there’s two types of external connections, trusted and untrusted. the untrusted ones have to be connected by means of a double staged firewall”.&lt;/p&gt;&#xA;&lt;p&gt;Which – of course – doesn’t work at all in a &lt;a href=&#34;http://en.wikipedia.org/wiki/Volatility,_uncertainty,_complexity_and_ambiguity&#34;&gt;VUCA&lt;/a&gt; world, for a number of reasons (the demarcation between trusted and untrusted is quite unclear – just think of mergers &amp;amp; acquisitions –; “business doesn’t like implementing 2-staged firewalls in some part of the world where they just signed the memorandum for a joint venture to build windmills in the desert”; firewalls might not be the appropriate control for quite some threats anyway – see for example slide 46 of &lt;a href=&#34;http://www.troopers10.org/content/e728/e897/e907/TROOPERS10_Rapid_Risk_Assessment_Enno_Rey.pdf&#34;&gt;this presentation&lt;/a&gt;– and so on). Not to mention that I personally think that the “double staged firewall” thing is based on an outdated threat model, in particular when implemented with two different vendors (for the simple reason that the added operational effort usually is not worth the added security benefit. see &lt;a href=&#34;http://www.insinuator.net/2011/05/evaluating-operational-feasibility/&#34;&gt;this post&lt;/a&gt; for some discussion of the concept of “operational feasibility”…).&lt;/p&gt;</description>
    </item>
    <item>
      <title>ShmooCon, Again</title>
      <link>https://insinuator.net/2012/01/shmoocon-again/</link>
      <pubDate>Sun, 29 Jan 2012 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2012/01/shmoocon-again/</guid>
      <description>&lt;p&gt;&lt;a href=&#34;http://www.insinuator.net/2011/01/washington-dc-for-shmoocon/%20&#34;&gt;Once more&lt;/a&gt; &lt;a href=&#34;http://www.shmoocon.org&#34;&gt;ShmooCon&lt;/a&gt; is the place to be for some days in late January. Great con, great people and five ERNW guys amongst them 😉&lt;/p&gt;&#xA;&lt;p&gt;We regard Shmoo(Con) as one of the most important community events at all and it allows us to meet fellow researchers from the US who we can’t easily sit down with to chat very often.&lt;/p&gt;&#xA;&lt;p&gt;And some lucky guys from ERNW will even continue the trip to head to San Diego (!) for &lt;a href=&#34;http://www.nanog.org/meetings/nanog54/index.php&#34;&gt;NANOG&lt;/a&gt; and &lt;a href=&#34;http://www.internetsociety.org/events/ndss-symposium-2012&#34;&gt;NDSS&lt;/a&gt;. Not to mention they stay in some fancy beach resort ;-), while I myself fly back today. (Getting older I don’t enjoy staying away from home for a week anymore and I have been missing my kids since some days…)&lt;/p&gt;</description>
    </item>
    <item>
      <title>Troopers 2012 – Final round of talks selected</title>
      <link>https://insinuator.net/2012/01/troopers-2012-final-round-of-talks-selected/</link>
      <pubDate>Wed, 25 Jan 2012 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2012/01/troopers-2012-final-round-of-talks-selected/</guid>
      <description>&lt;p&gt;It’s done. The exciting (and demanding) process of selecting talks for Troopers is complete (for the record: second round of talk selection was &lt;a href=&#34;http://www.insinuator.net/2012/01/troopers-2012-%E2%80%93-second-round-of-talks-selected/&#34;&gt;here&lt;/a&gt;, the first &lt;a href=&#34;http://www.insinuator.net/2011/12/troopers-2012-%E2%80%93-first-round-of-talks-selected/&#34;&gt;here&lt;/a&gt;).&lt;/p&gt;&#xA;&lt;p&gt;We’re quite happy and looking forward to the event 😉&lt;/p&gt;&#xA;&lt;p&gt; &lt;/p&gt;&#xA;&lt;p&gt;==================&lt;/p&gt;&#xA;&lt;p&gt;Rodrigo Branco: Into the Darkness – Dissecting Targeted Attacks&lt;/p&gt;&#xA;&lt;p&gt;The current threat landscape around cyber attacks is complex and hard to understand even for IT pros. The media coverage on recent events increases the challenge by putting fundamentally different attacks into the same category, often labeled as advanced persistent threats (APTs). The resulting mix of attacks includes everything from broadly used, exploit-kit driven campaigns driven by cyber criminals, to targeted attacks that use 0-day vulnerabilities and are hard to fend off – blurring the threat landscape, causing confusion where clarity is most needed.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Troopers 2012 – Second Round of Talks Selected</title>
      <link>https://insinuator.net/2012/01/troopers-2012-second-round-of-talks-selected/</link>
      <pubDate>Thu, 12 Jan 2012 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2012/01/troopers-2012-second-round-of-talks-selected/</guid>
      <description>&lt;p&gt;Hi everybody,&lt;/p&gt;&#xA;&lt;p&gt;after having announced the first round of &lt;a href=&#34;http://www.troopers.de&#34;&gt;Troopers&lt;/a&gt; speakers &lt;a href=&#34;http://www.insinuator.net/2011/12/troopers-2012-%E2%80%93-first-round-of-talks-selected/&#34;&gt;here&lt;/a&gt;, we’re happy to publish the second round today 😉&lt;/p&gt;&#xA;&lt;p&gt;Here we go:&lt;/p&gt;&#xA;&lt;p&gt; &lt;/p&gt;&#xA;&lt;p&gt;==================&lt;/p&gt;&#xA;&lt;p&gt;Dmitry Sklyarov – “Secure Password Managers” and “Military-Grade Encryption” on Smartphones: Oh Really?&lt;/p&gt;&#xA;&lt;p&gt;Abstract:  The task of providing privacy and data confidentiality with mobile applications becomes more and more important as the adoption of smartphones and tablets grows. As a result, there are a number of vendors and applications providing solutions to address those needs, such as password managers and file encryption utilities for mobile devices.&lt;/p&gt;</description>
    </item>
    <item>
      <title>ENISA Smartphone Secure Development Guidelines</title>
      <link>https://insinuator.net/2011/12/enisa-smartphone-secure-development-guidelines/</link>
      <pubDate>Mon, 19 Dec 2011 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2011/12/enisa-smartphone-secure-development-guidelines/</guid>
      <description>&lt;p&gt;I just stumbled across &lt;a href=&#34;http://www.enisa.europa.eu/act/application-security/smartphone-security-1/smartphone-secure-development-guidelines&#34;&gt;this document&lt;/a&gt; recently published by the European Network and Information Security Agency (ENISA). It’s part of &lt;a href=&#34;http://www.enisa.europa.eu/act/application-security/smartphone-security-1&#34;&gt;their smartphone security initiative&lt;/a&gt; which we’ve already mentioned in &lt;a href=&#34;http://www.insinuator.net/2011/09/appstore-security-5-lines-of-defence-against-malware/&#34;&gt;this post&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;p&gt;Here’s an excerpt from the introduction:&lt;/p&gt;&#xA;&lt;p&gt;“This document was produced jointly with the OWASP mobile security project. It is also published as an ENISA deliverable in accordance with our work program 2011. It is written for developers of smartphone apps as a guide to developing secure apps. It may however also be of interest to project managers of smartphone development projects.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Troopers 2012 – First round of talks selected</title>
      <link>https://insinuator.net/2011/12/troopers-2012-first-round-of-talks-selected/</link>
      <pubDate>Sun, 18 Dec 2011 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2011/12/troopers-2012-first-round-of-talks-selected/</guid>
      <description>&lt;p&gt;We’re delighted to provide the first announcement of talks of next year’s &lt;a href=&#34;http://www.troopers.de&#34;&gt;Troopers&lt;/a&gt; edition. Looks like it’s going to be a great event again  😉&lt;/p&gt;&#xA;&lt;p&gt;Here we go:&lt;/p&gt;&#xA;&lt;p&gt;==================&lt;/p&gt;&#xA;&lt;p&gt;Andreas Wiegenstein: Real SAP Backdoors&lt;/p&gt;&#xA;&lt;p&gt;Abstract: In the past year the number of lecture sessions with traumatizing headlines about hacking SAP systems has dramatically risen. Their content, however, is usually the same. Insecure implementations of algorithms, side effects in commands, flawed business logic and designs that brilliantly miss the point of security. In essence, security defects built into the SAP framework by mistake.&lt;/p&gt;</description>
    </item>
    <item>
      <title>On the discussion about the iTunes 10.5.1 update</title>
      <link>https://insinuator.net/2011/11/on-the-discussion-about-the-itunes-10.5.1-update/</link>
      <pubDate>Mon, 28 Nov 2011 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2011/11/on-the-discussion-about-the-itunes-10.5.1-update/</guid>
      <description>&lt;p&gt;Currently there’s &lt;a href=&#34;http://krebsonsecurity.com/2011/11/apple-took-3-years-to-fix-finfisher-trojan-hole/&#34;&gt;quite some discussion&lt;/a&gt; ongoing why it took Apple so long to fix a &lt;a href=&#34;http://support.apple.com/kb/HT5030&#34;&gt;severe vulnerability in the update process&lt;/a&gt; of iTunes. A severe vulnerability which could easily be exploited by means of an automated tool called &lt;a href=&#34;http://www.infobytesec.com/down/isr-evilgrade-Readme.txt&#34;&gt;evilgrade&lt;/a&gt; which can be downloaded &lt;a href=&#34;http://www.infobytesec.com/developments.html&#34;&gt;here&lt;/a&gt; (Hi Francisco!). Just one small note here: did you know that evilgrade was first shown and released at the &lt;a href=&#34;http://www.troopers08.org/content/&#34;&gt;2008 edition&lt;/a&gt; of &lt;a href=&#34;http://www.troopers.de&#34;&gt;Troopers&lt;/a&gt;? We had a number of initial releases of tools in the last years (like &lt;a href=&#34;http://code.google.com/p/waffit/source/browse/trunk/wafw00f.py&#34;&gt;wafw00f&lt;/a&gt; at the &lt;a href=&#34;http://www.troopers09.org/content/&#34;&gt;2009 edition&lt;/a&gt; and &lt;a href=&#34;http://vasto.nibblesec.org/&#34;&gt;VASTO&lt;/a&gt; at the &lt;a href=&#34;http://www.troopers10.org/content/e3/index_eng.html&#34;&gt;2010 edition&lt;/a&gt;) and we will continue this fine tradition in 2012. I can already promise that some nice code is going to be released for the first time at Troopers12…&lt;/p&gt;</description>
    </item>
    <item>
      <title>Carriers Converge Their Internet and MPLS Infrastructure: Time to Redo Your Risk Assessment?</title>
      <link>https://insinuator.net/2011/11/carriers-converge-their-internet-and-mpls-infrastructure-time-to-redo-your-risk-assessment/</link>
      <pubDate>Fri, 25 Nov 2011 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2011/11/carriers-converge-their-internet-and-mpls-infrastructure-time-to-redo-your-risk-assessment/</guid>
      <description>&lt;p&gt;The above is the exact title of a &lt;a href=&#34;http://www.gartner.com/DisplayDocument?ref=seo&amp;amp;id=1853618%20&#34;&gt;Gartner research note&lt;/a&gt; published some days ago. Its main thesis is that an increased convergence of carriers’ MPLS and Internet infrastructures onto shared IP infrastructures requires that enterprises re-evaluate their security and performance risks.&lt;/p&gt;&#xA;&lt;p&gt;While I do not agree with the overall line of reasoning in the paper, it still highlights a number of interesting points when it comes to MPLS security. Which in turn reminds me of quite some stuff we’ve done in the past, mainly our Black Hat Europe 2009 &lt;a href=&#34;http://www.ernw.de/content/e7/e181/e1309/download1357/ERNW_BlackHatEurope09_all_your_packets_ger.pdf%20&#34;&gt;talk “All your packets are belong to us – Attacking backbone technologies”&lt;/a&gt;. Today we’ll release an updated version of the accompanying whitepaper as a kind-of technical report. Its title is “Practical Attacks against MPLS or Carrier Ethernet Networks” and it can be found &lt;a href=&#34;http://www.ernw.de/download/ERNW_MPLS-Carrier-Ethernet.pdf%20&#34;&gt;here&lt;/a&gt;.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Call me Snake</title>
      <link>https://insinuator.net/2011/11/call-me-snake/</link>
      <pubDate>Wed, 16 Nov 2011 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2011/11/call-me-snake/</guid>
      <description>&lt;p&gt;Once again there’s a &lt;a href=&#34;http://www.insinuator.net/2011/09/today-i-feel-like-stansfield/&#34;&gt;reference&lt;/a&gt; to some action movie here, as some of you may have immediately spotted ;-).&lt;/p&gt;&#xA;&lt;p&gt;For the record: this one is from “Snake Plissken”, the main protagonist in John Carpenter’s “Escape from New York”. There’s another well-known quote of the same character in the kind-of sequel “Escape from L.A.” which goes like: “The more things change, the more they stay the same”. I’m aware that this is not the initial source (but French novelist Jean-Baptiste Alphonse Karr presumably is, at the time in French ;-)); still this gives a nice  transition to today’s topic.&lt;/p&gt;</description>
    </item>
    <item>
      <title>“What’s so special about Troopers?”</title>
      <link>https://insinuator.net/2011/11/whats-so-special-about-troopers/</link>
      <pubDate>Fri, 11 Nov 2011 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2011/11/whats-so-special-about-troopers/</guid>
      <description>&lt;p&gt;This week I stayed some days in Zurich, to give a workshop and to meet both clients and fellow researchers (kudos again to C. for the awesome office tour @Google). In the course of one of those dinners somehow Troopers was mentioned and a guy asked: “I’ve heard of the conference. What’s so special about it?”&lt;/p&gt;&#xA;&lt;p&gt;Funnily enough I didn’t even have to respond myself as a &lt;a href=&#34;http://www.troopers.de/archives/troopers11/agenda/&#34;&gt;2011&lt;/a&gt; attendee coincidentally present at the table jumped in and started praising the event (“best con ever. great spirit, great talks”). Obviously this gave me a big grin… but it reminded as well me that some of you might ask themselves the very same question.&lt;/p&gt;</description>
    </item>
    <item>
      <title>iOS 5, S/MIME, and Digital Certificate Management</title>
      <link>https://insinuator.net/2011/11/ios-5-s/mime-and-digital-certificate-management/</link>
      <pubDate>Fri, 04 Nov 2011 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2011/11/ios-5-s/mime-and-digital-certificate-management/</guid>
      <description>&lt;p&gt;As a follow-up to &lt;a href=&#34;http://www.insinuator.net/2011/10/certificate-based-device-authentication-with-ios-devices/&#34;&gt;this post&lt;/a&gt; somebody pointed us to &lt;a href=&#34;http://www.css-security.com/blog/ios-5-smime-and-digital-certificate-management/&#34;&gt;this interesting article&lt;/a&gt; on S/MIME support and associated certificate mgmt in iOS 5. Nice read which some of you may find worthwhile.&lt;/p&gt;&#xA;&lt;p&gt;On a related note: if anyone is aware of an easy way/good (3rd party) solution for pushing certs to iOS devices (besides SCEP) we would be very interested in that one. In that case pls leave a comment or shoot us an email.&lt;/p&gt;</description>
    </item>
    <item>
      <title>All Your Clouds are Belong to us</title>
      <link>https://insinuator.net/2011/10/all-your-clouds-are-belong-to-us/</link>
      <pubDate>Mon, 24 Oct 2011 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2011/10/all-your-clouds-are-belong-to-us/</guid>
      <description>&lt;p&gt;&lt;a href=&#34;http://www.nds.rub.de/media/nds/veroeffentlichungen/2011/10/22/AmazonSignatureWrapping.pdf&#34;&gt;This&lt;/a&gt; is a _very_ interesting paper just published by some researchers (mainly) from RUB (Ruhr-University Bochum). Here’s the abstract:&lt;/p&gt;&#xA;&lt;p&gt;“Cloud Computing resources are handled through control interfaces. It is through these interfaces that the new machine images can be added, existing ones can be modied, and instances can be started or ceased. Effectively, a successful attack on a Cloud control interface grants the attacker a complete power over the victim’s account, with all the stored data included.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Certificate Based Device Authentication with iOS Devices</title>
      <link>https://insinuator.net/2011/10/certificate-based-device-authentication-with-ios-devices/</link>
      <pubDate>Wed, 05 Oct 2011 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2011/10/certificate-based-device-authentication-with-ios-devices/</guid>
      <description>&lt;p&gt;We recently performed a Proof-of-Concept (PoC) implementation of certificate based auth with iPads in some large environment. So far the focus has been mainly on WLAN access; VPN and EAS authentication are going to follow in the next step.&lt;/p&gt;&#xA;&lt;p&gt;As we figure that the topic might be of interest for some of you, we’ve extracted a certain, not-too-customer-specific part of the deliverable and converted it into an &lt;a href=&#34;http://www.ernw.de/content/e15/e26/e1662/download1664/ERNW_Newsletter_36_Cert_for_iOS_en_ger.pdf&#34;&gt;ERNW newsletter&lt;/a&gt;. Special thanks go to Rene Graf for leading the project! 😉&lt;/p&gt;</description>
    </item>
    <item>
      <title>Broken Trust, Part 2: Applying the Approach to… Dropbox</title>
      <link>https://insinuator.net/2011/10/broken-trust-part-2-applying-the-approach-to-dropbox/</link>
      <pubDate>Mon, 03 Oct 2011 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2011/10/broken-trust-part-2-applying-the-approach-to-dropbox/</guid>
      <description>&lt;p&gt;After having introduced the basic elements of our concept of trust, control and confidence in &lt;a href=&#34;http://www.insinuator.net/2011/06/broken-trust-part-1-definitions-fundamentals-some-more-reflections-on-rsa/&#34;&gt;this&lt;/a&gt; post, today I’ll try to strengthen your (and maybe even my own as well ;-)) understanding of these ideas by applying them to another candidate, that is Dropbox. Hence this post is mainly about performing a certain analysis method to some object; conclusions as for the question if Dropbox is suited to be used in enterprise environments processing sensitive data are out of scope and are left entirely to you, the valued reader.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Today I feel like Stansfield</title>
      <link>https://insinuator.net/2011/09/today-i-feel-like-stansfield/</link>
      <pubDate>Tue, 20 Sep 2011 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2011/09/today-i-feel-like-stansfield/</guid>
      <description>&lt;p&gt;… the corrupt DEA agent in Luc Besson’s great movie “Léon (The Professional)”. I’m sure quite some of you, dear readers, know the plot…&lt;br&gt;&#xA;Just before the final shootout, when sending the first men of the NYPD ESU team into Léon’s apartment, he tells them to “Be careful!”. After learning those men got killed he just comments: “I told you”.&lt;br&gt;&#xA;[btw: before yelling to bring “EEEEEEEVERYONE!!!!”, as those familiar with the piece will certainly remember ;-)].&lt;/p&gt;</description>
    </item>
    <item>
      <title>Appstore security: 5 lines of defence against malware</title>
      <link>https://insinuator.net/2011/09/appstore-security-5-lines-of-defence-against-malware/</link>
      <pubDate>Sat, 17 Sep 2011 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2011/09/appstore-security-5-lines-of-defence-against-malware/</guid>
      <description>&lt;p&gt;A few days ago the European Network and Information Security Agency (ENISA) published &lt;a href=&#34;http://www.enisa.europa.eu/act/application-security/smartphone-security-1/appstore-security-5-lines-of-defence-against-malware/at_download/fullReport%20&#34;&gt;this quite interesting document&lt;/a&gt; with the exact title. Here’s what it covers:&lt;/p&gt;&#xA;&lt;p&gt;“The booming smartphone industry has a special way of delivering software to end-users: appstores. Popular appstores have hundreds of thousands of apps for anything from online banking to mosquito repellent, and the most popular stores (Apple Appstore, Google Android market) claim billions of app downloads. But appstores have not escaped the attention of cyber attackers. Over the course of 2011 numerous malicious apps were found, across a variety of smartphone models. Using malicious apps, attackers can easily tap into the vast amount of private data processed on smartphones such as confidential business emails, location data, phone calls, SMS messages and so on. Starting from a threat model for appstores, this paper identifies five lines of defence that must be in place to address malware in appstores: app review, reputation, kill-switches, device security and jails.”&lt;/p&gt;</description>
    </item>
    <item>
      <title>(Auditing) Remote Access Security in 2011</title>
      <link>https://insinuator.net/2011/08/auditing-remote-access-security-in-2011/</link>
      <pubDate>Sun, 14 Aug 2011 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2011/08/auditing-remote-access-security-in-2011/</guid>
      <description>&lt;p&gt;I’m currently involved in a “Remote Access Security Assessment” and you might be wondering what exactly this means. Well, so did we. At least to some degree (btw: last year we provided some notes on types of security assessments &lt;a href=&#34;http://www.insinuator.net/2010/05/security-assessments/&#34;&gt;here&lt;/a&gt;).&lt;/p&gt;&#xA;&lt;p&gt;It happens quite often we’re brought into an organization to perform “a security assessment” of “some item” (“our network”, “that new procurement portal”, “the PKI” etc.). It happens as well the customer does not have a very clear idea of the way such an assessment should be carried out (telling us “you are the experts, you should know what to do”). Or the five people from the customer’s side present in the kick-off meeting have five different concepts (ok, four. as one of them only wants “to get that damned assessment done so we can finally go live”) and we end up moderating their arguments on what should be tested, how this should be done, when this is going to happen, which type of report format is needed (obviously, there’s different ones, depending on the goal/scope/methodology of the assessment…) etc.&lt;/p&gt;</description>
    </item>
    <item>
      <title>OS X Security in Corporate Networks</title>
      <link>https://insinuator.net/2011/08/os-x-security-in-corporate-networks/</link>
      <pubDate>Sat, 06 Aug 2011 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2011/08/os-x-security-in-corporate-networks/</guid>
      <description>&lt;p&gt;&lt;a href=&#34;https://www.isecpartners.com/storage/docs/presentations/iSEC_BH2011_Mac_APT.pdf&#34;&gt;Interesting presentation&lt;/a&gt; just given at Black Hat Vegas.&lt;/p&gt;&#xA;&lt;p&gt;May be worth a read for those of you responsible for security in networks with MAC users.&lt;/p&gt;&#xA;&lt;p&gt;have a great weekend,&lt;/p&gt;&#xA;&lt;p&gt;Enno&lt;/p&gt;</description>
    </item>
    <item>
      <title>Smart (and Scary) Supply Chain Attack</title>
      <link>https://insinuator.net/2011/08/smart-and-scary-supply-chain-attack/</link>
      <pubDate>Thu, 04 Aug 2011 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2011/08/smart-and-scary-supply-chain-attack/</guid>
      <description>&lt;p&gt;&lt;a href=&#34;http://www.cisco.com/en/US/products/csr/cisco-sr-20110803-cd.html&#34;&gt;This advisory&lt;/a&gt; describes an interesting attack vector:&lt;/p&gt;&#xA;&lt;p&gt;“In the period of December 2010 until August 2011, Cisco shipped warranty CDs that contain a reference to a third-party website known to be a malware repository. When the CD is opened with a web browser, it automatically and without warning accesses this third-party website. Additionally, on computers where the operating system is configured to automatically open inserted media, the computer’s default web browser will access the third-party site when the CD is inserted, without requiring any further action by the user.”&lt;/p&gt;</description>
    </item>
    <item>
      <title>iOS Hardening Configuration Guide</title>
      <link>https://insinuator.net/2011/07/ios-hardening-configuration-guide/</link>
      <pubDate>Sun, 17 Jul 2011 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2011/07/ios-hardening-configuration-guide/</guid>
      <description>&lt;p&gt;Hi everybody,&lt;br&gt;&#xA;eye-catching title of this post, huh?&lt;/p&gt;&#xA;&lt;p&gt;Actually there is some justification for it ;-), that is bringing &lt;a href=&#34;http://www.dsd.gov.au/publications/iOS_Hardening_Guide.pdf&#34;&gt;this excellent document covering the exact topic&lt;/a&gt; to your attention.&lt;br&gt;&#xA;Other than that this post contains some unordered reflections which arose in a recent meeting in a quite large organization on the “common current iPad topic” (executives would like to have/use an iPad, infosec doesn’t like the idea, business – as we all know – wins, so bring external expertise in “to help us find a way of doing this securely” yadda yadda yadda).&lt;br&gt;&#xA;Which – given those nifty little boxes are _consumer_ devices which were probably never meant to process sensitive corporate data – might be a next-to-impossible task… at least in a way that satisfies business expectations as for “usability”…[btw: can anybody confirm my observation that there’s a correlation between “rigor of restriction approach” to “number of corporate emails forwarded to private webmail accounts”?]&lt;/p&gt;</description>
    </item>
    <item>
      <title>Broken Trust, Part 1: Definitions &amp; Fundamentals &#43; Some More Reflections on RSA</title>
      <link>https://insinuator.net/2011/06/broken-trust-part-1-definitions-fundamentals--some-more-reflections-on-rsa/</link>
      <pubDate>Sun, 19 Jun 2011 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2011/06/broken-trust-part-1-definitions-fundamentals--some-more-reflections-on-rsa/</guid>
      <description>&lt;p&gt;This again is going to be a little series of posts. Their main topic – next to the usual deviations &amp;amp; ranting I tend to include in blogposts 😉 – is some discussion of “trust” and putting this discussion into the context of recent events and future developments in the infosec space. The title originates from a conversation between Angus Blitter and me in a nice Thai restaurant in Zurich where we figured the consequences of the &lt;a href=&#34;http://arstechnica.com/security/news/2011/06/rsa-finally-comes-clean-securid-is-compromised.ars%20&#34;&gt;latest RSA revelations&lt;/a&gt;. While we both expect that – unfortunately – not much is really going to happen (surprisingly many people, including some CSOs we know, are still trying to somehow downplay this or sweep it under the carpet, shying away from the – obvious – consequences it might have to accept that for a number of environments RSA SecurID is potentially reduced to single factor auth nowadays…), the long term impact on our understanding of 3rd party (e.g. vendor) trust might be more interesting. Furthermore “Broken Trust” seems a promising title for a talk at upcoming &lt;a href=&#34;http://www.day-con.org&#34;&gt;Day-Con V&lt;/a&gt;… 😉&lt;/p&gt;</description>
    </item>
    <item>
      <title>Extracting Data from Very Large Pcap Files – Part 3: Pcap Filtering in the Cloud</title>
      <link>https://insinuator.net/2011/06/extracting-data-from-very-large-pcap-files-part-3-pcap-filtering-in-the-cloud/</link>
      <pubDate>Mon, 13 Jun 2011 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2011/06/extracting-data-from-very-large-pcap-files-part-3-pcap-filtering-in-the-cloud/</guid>
      <description>&lt;p&gt;This is the third (and last) part of the series (parts &lt;a href=&#34;http://www.insinuator.net/2011/04/extracting-data-from-very-large-pcap-files-part-1-tools-and-hardware/%20&#34;&gt;1&lt;/a&gt; &amp;amp; &lt;a href=&#34;http://www.insinuator.net/2011/06/extracting-data-from-very-large-pcap-files-%E2%80%93-part-2-results-from-the-local-lab/%20&#34;&gt;2&lt;/a&gt; here). We’ll provide the results from some additional tests supported by public cloud services, namely AWS (Amazon Web Services).&lt;/p&gt;&#xA;&lt;p&gt; &lt;br&gt;&#xA;&lt;strong&gt;Lab Setup&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;The Amazon Elastic Compute Cloud (short: EC2) provides a flexible environment for the on demand provisioning of virtual machines of different performance levels. For our lab setup, a so-called extra large instance was used. According to Amazon, the technical specs are the following:&lt;/p&gt;</description>
    </item>
    <item>
      <title>Extracting Data from Very Large Pcap Files – Part 2: Results from the Local Lab</title>
      <link>https://insinuator.net/2011/06/extracting-data-from-very-large-pcap-files-part-2-results-from-the-local-lab/</link>
      <pubDate>Thu, 02 Jun 2011 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2011/06/extracting-data-from-very-large-pcap-files-part-2-results-from-the-local-lab/</guid>
      <description>&lt;p&gt;In the &lt;a href=&#34;http://www.insinuator.net/2011/04/extracting-data-from-very-large-pcap-files-part-1-tools-and-hardware/&#34;&gt;first post&lt;/a&gt; I’ve laid out the tools and lab setup, so in this one I’m going to discuss some results.&lt;/p&gt;&#xA;&lt;p&gt;&lt;strong&gt;Description of overall test methodology&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;To evaluate the performance of the different setups used to analyze capture data, both tcpdump and pcap_extractor (see last post) were used. For the tests, five capture files were created using mergecap. Various sample traffic dumps were merged to five large files with different file sizes. All these files consisted of several capture files containing a variety of protocols (including iSCSI and FCoE packets). Capture files of ∼40, ∼80, ∼200, ∼500, and ∼800 GB size were created and were analyzed with both tools. For all tests the filtering expressions for tcpdump and pcap_extractor were configured to search for a specific source IP and a specific destination IP matching to iSCSI packets contained in the capture file. Additionally pcap_extractor was “instructed” to look for some search string (formatted like a credit card number).To address the performance bottleneck (again, see last post), that is the I/O throughput, two different setups of the testing environment (see above) were implemented, the first one going with a raid0 approach using four SSD hard drives, the second one with four individual SSD hard drives, each of them processing only a fourth of the analyzed capture file. Standard UNIX time command was invoked to measure the time of execution. Additionally the tools analyzing the data were started with the highest possible scheduling priority to ensure execution with the maximum of available resources. This is a sample command line invoking the test:&lt;/p&gt;</description>
    </item>
    <item>
      <title>HITB Aftermath</title>
      <link>https://insinuator.net/2011/05/hitb-aftermath/</link>
      <pubDate>Sat, 28 May 2011 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2011/05/hitb-aftermath/</guid>
      <description>&lt;p&gt;Hi,&lt;br&gt;&#xA;didn’t find the time so far to post a short blog about &lt;a href=&#34;http://conference.hackinthebox.org/hitbsecconf2011ams/&#34;&gt;HITB Amsterdam&lt;/a&gt; so far… but here we go.&lt;/p&gt;&#xA;&lt;p&gt;Unfortunately I couldn’t arrive in AMS earlier than Thursday evening so I missed the first day (and – from what I heard – some great talks). However we went out for dinner that night with the likes of Andreas (Wiegenstein), Jim (Geovedi), Raoul (Chiesa), Travis (Goodspeed), Claudio (Criscione) and some more guys and I had some quite good conversations, both on technical matters and on Intra-European cultural differences ;-). Btw: thanks again to Martijn for taking care of the restaurant.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Yet another update on IPv6 security – Some notes from the IPv6-Kongress in Frankfurt</title>
      <link>https://insinuator.net/2011/05/yet-another-update-on-ipv6-security-some-notes-from-the-ipv6-kongress-in-frankfurt/</link>
      <pubDate>Mon, 16 May 2011 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2011/05/yet-another-update-on-ipv6-security-some-notes-from-the-ipv6-kongress-in-frankfurt/</guid>
      <description>&lt;p&gt;A couple of hours ago Christopher (Werny) and I gave &lt;a href=&#34;http://ernw.de/content/e7/e181/e1641/download1643/ERNW_IPv6_Security_in_LANs_ger.pdf&#34;&gt;this presentation&lt;/a&gt; at the Heise IPv6-Kongress, which overall was a quite interesting and well-organized event bringing together a number of practitioners from the field. While yesterday’s talks were dominated by a certain euphoria and optimistic pioneer spirit, the second day featured some security talks which induced slight shadows to the brave new world of IPv6 ;-). I particularly enjoyed meeting Eric Vyncke from Cisco (one of the two authors of &lt;a href=&#34;http://www.amazon.com/IPv6-Security-Scott-Hogg/dp/1587055945&#34;&gt;this great book&lt;/a&gt;) and Marc “van Hauser” Heuse who released a new version of the &lt;a href=&#34;http://www.thc.org/thc-ipv6/&#34;&gt;THC-IPV6 tool set&lt;/a&gt; today. We had some fruitful discussions and we took the opportunity to test some of his newly implemented attacks against “RA Guard” running on a 4948E Chris and I had brought for a demo within our talk. Unfortunately – or fortunately in terms of a &lt;a href=&#34;http://www.troopers.de/wp-content/uploads/2011/04/TR11_Enno_Rey_Keynote_Day01.pdf%20&#34;&gt;“from theory to reality”&lt;/a&gt; approach – I have to say that Marc found a quite clever way to circumvent RA Guard by putting the actual “RA payload” into a second frame following a first one mostly containing a “long &amp;amp; empty” destination option (after a fragmentation header pointing to the mentioned second one). To get an idea pls see these screenshots from Wireshark. &lt;a href=&#34;http://www.insinuator.net/wp-content/uploads/2011/05/thc_wireshark_over.png&#34;&gt;&lt;img src=&#34;http://www.insinuator.net/wp-content/uploads/2011/05/thc_wireshark_over.png&#34; alt=&#34;&#34; title=&#34;thc_wireshark_over&#34;&gt;&lt;/a&gt; &lt;a href=&#34;http://www.insinuator.net/wp-content/uploads/2011/05/thc_wireshark_details1.png&#34;&gt;&lt;img src=&#34;http://www.insinuator.net/wp-content/uploads/2011/05/thc_wireshark_details1.png&#34; alt=&#34;&#34; title=&#34;thc_wireshark_details&#34;&gt;&lt;/a&gt;&lt;/p&gt;</description>
    </item>
    <item>
      <title>Evaluating Operational Feasibility</title>
      <link>https://insinuator.net/2011/05/evaluating-operational-feasibility/</link>
      <pubDate>Mon, 02 May 2011 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2011/05/evaluating-operational-feasibility/</guid>
      <description>&lt;p&gt;Hi,&lt;br&gt;&#xA;I’ve discussed the concept of evaluating the operational “feasibility” (or “impact”, depending on your point of view) of security controls &lt;a href=&#34;http://www.insinuator.net/2010/12/security-benefit-operational-impact-or-the-illusion-of-infinite-resources/%20&#34;&gt;before&lt;/a&gt;. Some people approached me asking “which considerations should we take into account when trying to understand or rate this for $SOME_SECURITY_CONTROL?”. Therefore, in the following I’ll give an unordered list of factors to consider to get an understanding of the “operational feasibility” of a given security control. Two things should be noted in advance:&lt;/p&gt;</description>
    </item>
    <item>
      <title>Extracting Data from Very Large Pcap Files – Part 1: Tools and Hardware</title>
      <link>https://insinuator.net/2011/04/extracting-data-from-very-large-pcap-files-part-1-tools-and-hardware/</link>
      <pubDate>Thu, 28 Apr 2011 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2011/04/extracting-data-from-very-large-pcap-files-part-1-tools-and-hardware/</guid>
      <description>&lt;p&gt;There is a common misconception that the sheer amount of data coupled with multiplexed channels (e.g. WDM technology) make successful eavesdropping attacks on high speed Ethernet links – like those connecting data centers – highly unlikely. This is mainly based on the assumption that the amount of resources (e.g. RAM, [sufficiently fast] storage or CPU power) needed to process large files of captured data is a limiting factor. However, to the best of our knowledge, no practical evaluation of these assumptions has so far been performed.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Once more: hardening is better than patching</title>
      <link>https://insinuator.net/2011/04/once-more-hardening-is-better-than-patching/</link>
      <pubDate>Wed, 13 Apr 2011 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2011/04/once-more-hardening-is-better-than-patching/</guid>
      <description>&lt;p&gt;I can’t help myself. And I fully understand that some of you, dear readers, might get a bit annoyed by always hearing the same tune from our side. This post is, surprise!, about yesterday’s Microsoft Patch Tuesday which – as can be seen &lt;a href=&#34;http://www.microsoft.com/technet/security/bulletin/ms11-apr.mspx&#34;&gt;here&lt;/a&gt; and &lt;a href=&#34;http://blogs.technet.com/b/srd/archive/2011/04/12/assessing-the-risk-of-the-april-security-updates.aspx%20&#34;&gt;here&lt;/a&gt; – disclosed quite a number of vulnerabilities in various Microsoft components. To make the point evoked in this post’s title I’d like to draw your attention to two particular bulletins, both rated as critical.&lt;/p&gt;</description>
    </item>
    <item>
      <title>RSA: Anatomy of an Attack</title>
      <link>https://insinuator.net/2011/04/rsa-anatomy-of-an-attack/</link>
      <pubDate>Wed, 06 Apr 2011 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2011/04/rsa-anatomy-of-an-attack/</guid>
      <description>&lt;p&gt;Lots of stuff has been written about &lt;a href=&#34;http://blogs.rsa.com/rivner/anatomy-of-an-attack/&#34;&gt;this blog post&lt;/a&gt; from RSA describing the (potential) details of the attack, so I will refrain from detailed comments on this piece that Marsh Ray nicely called “some of the most egregious hyperbole I’ve read in infosec”.&lt;/p&gt;&#xA;&lt;p&gt;Just one short note. Presumably the attack, in an early stage, used a “spreadsheet [that] contained a zero-day exploit that installs a backdoor through an Adobe Flash vulnerability (CVE-2011-0609)”.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Reflections on the RSA Break-in</title>
      <link>https://insinuator.net/2011/03/reflections-on-the-rsa-break-in/</link>
      <pubDate>Sun, 20 Mar 2011 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2011/03/reflections-on-the-rsa-break-in/</guid>
      <description>&lt;p&gt;Some of you may have heard of the &lt;a href=&#34;http://www.rsa.com/node.aspx?id=3872&#34;&gt;break-in at RSA&lt;/a&gt; and may now be wondering “what does this mean to us?” and “what can be done?”. Not being an expert on RSA SecurID at all – I’ve been involved in some projects, however not on the technical implementation side but on the architecture or overall [risk] management side – I’ll still try to contribute to the debate 😉&lt;/p&gt;&#xA;&lt;p&gt;Feel free to correct me either by comment or by personal email in case the following contains factual errors.&lt;/p&gt;</description>
    </item>
    <item>
      <title>VMSA-2011-0005: VMware vCenter Orchestrator remote code execution vulnerability</title>
      <link>https://insinuator.net/2011/03/vmsa-2011-0005-vmware-vcenter-orchestrator-remote-code-execution-vulnerability/</link>
      <pubDate>Mon, 14 Mar 2011 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2011/03/vmsa-2011-0005-vmware-vcenter-orchestrator-remote-code-execution-vulnerability/</guid>
      <description>&lt;p&gt;Reading &lt;a href=&#34;http://www.vmware.com/security/advisories/VMSA-2011-0005.html&#34;&gt;this advisory&lt;/a&gt; I’m quite tempted to emit another rant on the relationship of heavy use of 3rd party components, lack of (security) quality assurance and services running at times where they’re not needed (see second workaround &lt;a href=&#34;http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&amp;amp;cmd=displayKC&amp;amp;externalId=1034175&#34;&gt;here&lt;/a&gt;). I’ll refrain  from that for today. Just wanted to let you know that the &lt;a href=&#34;http://blog.o0o.nu/2010/07/cve-2010-1870-struts2xwork-remote.html&#34;&gt;underlying vulnerability&lt;/a&gt; in Struts2 was initially discovered by Meder Kydyraliev who gives &lt;a href=&#34;http://www.troopers.de/troopers11/agenda/milking-a-horse-or-executing-remote-code-in-modern-java-web-frameworks/&#34;&gt;this talk&lt;/a&gt; at &lt;a href=&#34;http://www.troopers.de&#34;&gt;Troopers&lt;/a&gt; in two weeks. He’ll certainly describe the inner workings of this one, and others… 😉&lt;/p&gt;</description>
    </item>
    <item>
      <title>IPv6 Security ‒ The Story Continues</title>
      <link>https://insinuator.net/2011/03/ipv6-security-the-story-continues/</link>
      <pubDate>Wed, 09 Mar 2011 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2011/03/ipv6-security-the-story-continues/</guid>
      <description>&lt;p&gt;Just a short addition to the previous posts (&lt;a href=&#34;http://www.insinuator.net/2011/01/ipv6-security-part-1-ra-guard-the-theory-3/&#34;&gt;[1]&lt;/a&gt;, &lt;a href=&#34;http://www.insinuator.net/2011/03/ipv6-security-part-2-ra-guard-%E2%80%93-lets-get-practical/&#34;&gt;[2]&lt;/a&gt;) on IPv6 security today. In the last two days I had the opportunity to sharpen my understanding of some aspects of IPv6 behavior in (Windows-) LANs. Actually I gave an IPv6 workshop for some members of the “Project Services” team of Hamburg-based &lt;a href=&#34;http://www.cuc.de&#34;&gt;computer &amp;amp; competence&lt;/a&gt; IT-solutions provider [btw: thanks to Mr. Wendler of CuC for organizing it, and thanks to Mr. Cassel for the breakfast…].&lt;/p&gt;</description>
    </item>
    <item>
      <title>IPv6 Security Part 2, RA Guard – Let’s get practical</title>
      <link>https://insinuator.net/2011/03/ipv6-security-part-2-ra-guard-lets-get-practical/</link>
      <pubDate>Sat, 05 Mar 2011 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2011/03/ipv6-security-part-2-ra-guard-lets-get-practical/</guid>
      <description>&lt;p&gt;Hi everybody,&lt;/p&gt;&#xA;&lt;p&gt;this post is the sequel of &lt;a href=&#34;http://www.insinuator.net/2011/01/ipv6-security-part-1-ra-guard-the-theory-3/&#34;&gt;this one&lt;/a&gt; on the IPv6 security feature called “RA guard”. As announced in that post I recently got a 4948 on ebay. After installing the appropriate image and noticing that RA guard was still unavailable I found out it should have been a 4948E which is capable of “doing IPv6 in hardware” (as opposed to the “simple 4948” only supporting IPv6 in a “software switched” way. and pls note there’s also the informal term 4948-E denoting a 4948 running an “enhanced image”).&lt;/p&gt;</description>
    </item>
    <item>
      <title>Ross Anderson on Responsible Disclosure and Academic Freedom</title>
      <link>https://insinuator.net/2011/01/ross-anderson-on-responsible-disclosure-and-academic-freedom/</link>
      <pubDate>Thu, 06 Jan 2011 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2011/01/ross-anderson-on-responsible-disclosure-and-academic-freedom/</guid>
      <description>&lt;p&gt;Hi,&lt;/p&gt;&#xA;&lt;p&gt;just a short, somewhat non-technical,  post today: I really like &lt;a href=&#34;http://www.cl.cam.ac.uk/~rja14/Papers/ukca.pdf&#34;&gt;this response&lt;/a&gt; Ross Anderson gave to the “UK Cards Association” asking Cambridge University for taking offline a thesis of one of their students. It (the letter) pretty much summarizes how security research should be treated and backed by those interested in a more secure world we live in.&lt;/p&gt;&#xA;&lt;p&gt;On a personal note I’d like to add that Ross’ main volume “Security Engineering: A Guide to Building Dependable Distributed Systems”, initially published in 2001 and updated in the interim with a second edition in 2008, has been the most influential security book for me on my long way in the infosec space (which started back in 1997, with some workshops on firewalls I gave for IT auditors). If I could take only one infosec book to a lonely island, it would be this one.&lt;/p&gt;</description>
    </item>
    <item>
      <title>IPv6 Security Part 1, RA Guard – The Theory</title>
      <link>https://insinuator.net/2011/01/ipv6-security-part-1-ra-guard-the-theory/</link>
      <pubDate>Wed, 05 Jan 2011 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2011/01/ipv6-security-part-1-ra-guard-the-theory/</guid>
      <description>&lt;p&gt;Hi,&lt;/p&gt;&#xA;&lt;p&gt;at first a happy new year to our loyal readers (and, of course, to everybody else too ;-)! We hope you all had some pleasant transition times, not suffering from bad hangovers after 27C3 or sth 😉&lt;/p&gt;&#xA;&lt;p&gt;Things are heating up for &lt;a href=&#34;http://www.troopers.de&#34;&gt;Troopers&lt;/a&gt; and in the course of that we started putting together the slides for the workshops (I’m delighted that Flo told me today there’s already quite a number of bookings for the workshops…). I myself will give the “IPv6 Security in LANs” workshop, together with Christopher. The workshop preparation will be accompanied by a series of blogposts with three main areas to be covered:&lt;/p&gt;</description>
    </item>
    <item>
      <title>Cloud needn’t be daunting | Guide to legal aspects for non-legals</title>
      <link>https://insinuator.net/2010/12/cloud-neednt-be-daunting-guide-to-legal-aspects-for-non-legals/</link>
      <pubDate>Thu, 23 Dec 2010 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2010/12/cloud-neednt-be-daunting-guide-to-legal-aspects-for-non-legals/</guid>
      <description>&lt;p&gt;The British Standards Institution recently published “Cloud Computing. A Practical Introduction to the Legal Issues”. I ordered an electronic copy yesterday (I did that &lt;a href=&#34;http://shop.bsigroup.com/en/ProductDetail/?pid=000000000030215581&#34;&gt;here&lt;/a&gt;, for GBP 30) and after a first glance can say there’s lots of valuable information in it.&lt;/p&gt;&#xA;&lt;p&gt;Merry christmas to everybody, have some peaceful and relaxing days&lt;/p&gt;&#xA;&lt;p&gt;Enno&lt;/p&gt;</description>
    </item>
    <item>
      <title>The OSSTMM 3 – What I like about it</title>
      <link>https://insinuator.net/2010/12/the-osstmm-3-what-i-like-about-it/</link>
      <pubDate>Mon, 13 Dec 2010 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2010/12/the-osstmm-3-what-i-like-about-it/</guid>
      <description>&lt;p&gt;Given the upcoming public release of &lt;a href=&#34;http://www.isecom.org&#34;&gt;ISECOM&lt;/a&gt;‘s &lt;a href=&#34;http://www.isecom.org/osstmm/&#34;&gt;Open Source Security Testing Methodology Manual (OSSTMM)&lt;/a&gt; version 3, I took the opportunity to have a closer look at it. While we at ERNW never adopted the OSSTMM for our own way of performing security assessments (mostly due to the fact that performing assessments is our main business since 2001 and our approach has been developed and constantly honed since then so that we’re simply used to doing it “our way”) I’ve followed parts of ISECOM’s work quite closely as some of the brightest minds in the security space are contributing to it and they come up with innovative ideas regularly.&lt;br&gt;&#xA;So I was eager to get an early copy of it to spend some weekend time going through it (where I live we have about 40 cm of snow currently so there’s “plenty of occasions for a cosy reading session” ;-))&lt;br&gt;&#xA;One can read the OSSTMM (at least) two ways: as a manual for performing security testing or as a “whole philosophy of approaching [information] security”. I did the latter and will comment on it in a two-part post, covering the things I liked first and taking a more critical perspective on some portions in the second. Here we go with the first, in an unordered manner:&lt;/p&gt;</description>
    </item>
    <item>
      <title>Security Benefit &amp; Operational Impact or “the Illusion of Infinite Resources”</title>
      <link>https://insinuator.net/2010/12/security-benefit-operational-impact-or-the-illusion-of-infinite-resources/</link>
      <pubDate>Sat, 11 Dec 2010 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2010/12/security-benefit-operational-impact-or-the-illusion-of-infinite-resources/</guid>
      <description>&lt;p&gt;When taking security decisions of whatever kind (e.g. for/against a certain control) one should always consider two main parameters: the security benefit of some action (“how much do we gain with regard to security/to risk reduction?”) and  the operational impact or effort (“how much does it cost us opex-wise?”).&lt;br&gt;&#xA;While this may seem fairly obvious it is often overlooked. One reason is that people think “doing more can’t hurt”. Which, unfortunately might be plain wrong in many cases. There is _always_ an operational cost of an additional measure. And the security benefit _must_ be worth this cost.&lt;br&gt;&#xA;If it’s not, implementing a certain control might just be… waste.&lt;br&gt;&#xA;Before giving two examples I’d like to note that this is one aspect I particularly like in the &lt;a href=&#34;http://www.isecom.org/osstmm/&#34;&gt;ISECOM OSSTMM&lt;/a&gt; where one of the main metrics, that is the “rav” can be higher than 100% which in turn can be used “to prove when money is being overspent on the wrong types of controls or redundant controls”.&lt;br&gt;&#xA;[it should be noted that I’m in heavy disaccord with quite some other parts of the OSSTMM; more on this in a post to follow in some days. still the “rav” as a potential representation for showing waste is a really nice thing].&lt;/p&gt;</description>
    </item>
    <item>
      <title>Troopers 2011 – First round of speakers selected</title>
      <link>https://insinuator.net/2010/12/troopers-2011-first-round-of-speakers-selected/</link>
      <pubDate>Tue, 07 Dec 2010 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2010/12/troopers-2011-first-round-of-speakers-selected/</guid>
      <description>&lt;p&gt;We’re delighted to announce the first speakers of next year’s &lt;a href=&#34;http://www.troopers.de&#34;&gt;Troopers&lt;/a&gt; edition. Looks like it’s going to be a great event again ;-).&lt;br&gt;&#xA;Here we go:&lt;/p&gt;&#xA;&lt;p&gt;==================&lt;/p&gt;&#xA;&lt;p&gt;Ravishankar Borgaonkar &amp;amp; Kevin Redon: Femtocell: Femtostep to the Holy Grail  (Attacks &amp;amp; Research Track)&lt;/p&gt;&#xA;&lt;p&gt;Abstract: Femtocells are now being rolled out across the world to enhance third generation (3G) coverage and to provide assurance of always best connectivity in the 3G telecommunication networks. It acts as an access point that securely connect standard mobile handset to the mobile network operator’s core network using an existing wired broadband connection.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Reflections on the vulnerability factor (notes on RRA, part 3)</title>
      <link>https://insinuator.net/2010/12/reflections-on-the-vulnerability-factor-notes-on-rra-part-3/</link>
      <pubDate>Mon, 06 Dec 2010 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2010/12/reflections-on-the-vulnerability-factor-notes-on-rra-part-3/</guid>
      <description>&lt;p&gt;Today I’m going to discuss the (presumably) most complex and difficult-to-handle of the three parameters contributing to a risk (as of the RRA), that is the “vulnerability [factor]”.&lt;br&gt;&#xA;First it should be noted that “likelihood” and “vulnerability” must (“mentally”) be clearly separated which means that “likelihood” denotes: likelihood of threat showing up _without_ consideration of existing controls. Security controls already present will affect the vulnerability factor (in particular if they are effective ;-), but _not_ the likelihood.&lt;br&gt;&#xA;First reflect on “how often will somebody stand at the door of our data center with the will to enter?” or “how often will a piece of malware show up at our perimeter?” or “how often will it happen that an operator commits a mistake?” and assign an associated value to the likelihood.&lt;br&gt;&#xA;Then, _in a separate_ step, think about: “will that person be able to enter my data center?” (maybe it’s an external support engineer and, given their high workload, your admins are willing to violate the external_people_only_allowed_to_access_dc_when_attended policy. which – of course – is purely fictional and will never happen in your organization ;-)) or “how effective are our perimeter controls as for malware?” (are they? ;-)) or “hmm… what’s the maturity of our change management processes?” and assign an associated value to the vulnerability factor.&lt;br&gt;&#xA;As stated in an earlier post: this will allow for identifying areas where to act and thus allow for efficient overall steering of infosec resources.&lt;br&gt;&#xA;Mixing likelihood and vulnerability might lead to self complacent stuff like “oh, evidently likelihood of unauthorized access to datacenter is ‘1’ as we have that brand new shiny access control system” …&lt;/p&gt;</description>
    </item>
    <item>
      <title>ERNW Rapid Risk Assessment (RRA), Some Additional Notes, Part 2</title>
      <link>https://insinuator.net/2010/12/ernw-rapid-risk-assessment-rra-some-additional-notes-part-2/</link>
      <pubDate>Sat, 04 Dec 2010 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2010/12/ernw-rapid-risk-assessment-rra-some-additional-notes-part-2/</guid>
      <description>&lt;p&gt;This is the second part of the series (part 1 &lt;a href=&#34;http://www.insinuator.net/2010/11/ernw-rapid-risk-assessment-rra-some-additional-notes-part-1/&#34;&gt;here&lt;/a&gt;) providing some background on the way we perform risk assessments. It can be seen as a direct continuation of the last post; today I cover the &lt;em&gt;method of estimation&lt;/em&gt; and the &lt;em&gt;scale &amp;amp; calculation formula&lt;/em&gt; used.&lt;/p&gt;&#xA;&lt;h2 id=&#34;11-method-of-estimation&#34;&gt;1.1 Method of Estimation&lt;/h2&gt;&#xA;&lt;p&gt;Again, two main approaches exist&lt;a href=&#34;http://www.insinuator.net/wp-includes/js/tinymce/plugins/paste/pasteword.htm?ver=327-1235#_ftn1&#34;&gt;[1]&lt;/a&gt;:&lt;/p&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;&lt;em&gt;Qualitative estimation&lt;/em&gt; which uses a scale of qualifying attributes (e.g. &lt;em&gt;Low, Medium, High&lt;/em&gt;) to describe the magnitude of each of the contributing factors listed above. [ISO 27005, p. 14] states that qualitative estimation may be used&#xA;&lt;ul&gt;&#xA;&lt;li&gt;As an initial screening activity to identify risks that require more detailed analysis.&lt;/li&gt;&#xA;&lt;li&gt;Where this kind of analysis is appropriate for decisions.&lt;/li&gt;&#xA;&lt;li&gt;Where the numerical data or resources are inadequate for a quantitative estimation.&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;p&gt;As the latter is &lt;em&gt;pretty much always&lt;/em&gt; the case for information security risks, in the infosec space usually qualitative estimation can be found. A sample qualitative scale (1–5, mapping to “very low” to “very high”) for the &lt;em&gt;vulnerability factor&lt;/em&gt; will be provided in the next part of this series.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Trust &amp; Control in the Age of Virtualization and the Cloud</title>
      <link>https://insinuator.net/2010/11/trust-control-in-the-age-of-virtualization-and-the-cloud/</link>
      <pubDate>Wed, 17 Nov 2010 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2010/11/trust-control-in-the-age-of-virtualization-and-the-cloud/</guid>
      <description>&lt;p&gt;Two days ago I gave the keynote at an industry event, reflecting on the changing role of traditional security controls in the age of virtualization and the cloud. As this was an updated version of the stuff distributed in the conference proceedings, some people have asked for it. Voilà, &lt;a href=&#34;http://www.ernw.de/content/e7/e181/e1612/download1614/ERNW_LANline_VirtCloudSec_Keynote_ger.pdf&#34;&gt;here we go&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;p&gt;have a good one,&lt;/p&gt;&#xA;&lt;p&gt;Enno&lt;/p&gt;</description>
    </item>
    <item>
      <title>ERNW Rapid Risk Assessment (RRA), Some Additional Notes, Part 1</title>
      <link>https://insinuator.net/2010/11/ernw-rapid-risk-assessment-rra-some-additional-notes-part-1/</link>
      <pubDate>Sun, 07 Nov 2010 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2010/11/ernw-rapid-risk-assessment-rra-some-additional-notes-part-1/</guid>
      <description>&lt;p&gt;At several occasions we’ve been asked to provide some background on the &lt;a href=&#34;http://www.troopers.de/content/e728/e897/e907/TROOPERS10_Rapid_Risk_Assessment_Enno_Rey.pdf&#34;&gt;Rapid Risk Assessment (RRA)&lt;/a&gt; methodology we frequently use for a transparent (and documented) understanding of risks in certain situations and to deliver structured input for subsequent decision taking. As I had to write down (in another context) some notes on risk assessments and – from our perspective – practical, reasonable ways of performing them, I take the opportunity to lay out a bit the underlying ideas of the RRA approach. Which, btw, is no rocket science at all. Honestly, I sometimes wonder why stuff like this isn’t practiced everywhere, on a daily basis 😉&lt;/p&gt;</description>
    </item>
    <item>
      <title>The Case For/Against Split Tunneling</title>
      <link>https://insinuator.net/2010/11/the-case-for/against-split-tunneling/</link>
      <pubDate>Thu, 04 Nov 2010 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2010/11/the-case-for/against-split-tunneling/</guid>
      <description>&lt;p&gt;Once again, in some customer environment the question of allowing/prohibiting split tunneling for (in this case: IPsec) VPN connections popped up today. Given our strict stance when it comes to “fundamental architectural security principles” the valued reader might easily imagine we’re no big fans of allowing split tunneling (term abbreviated in the following by “ST”), as this usually constitutes a severe violation of the “isolation principle”, further aggravated by the fact that this (violation) takes place on a “trust boundary” (of trusted/untrusted networks).&lt;br&gt;&#xA;Still, we’re security &lt;em&gt;practitioners&lt;/em&gt; (and not everybody has such a firm belief in the value of “fundamental architectural security principles” as we have), so we had to deal with the proponents’ arguments. In particular as one of them mentioned additional costs (in case of disallowed ST forcing all 80K VPN users’ web browsing through some centralized corporate infrastructure) of US$ 40,000,000.&lt;br&gt;&#xA;[yes, you read that correctly: 40 million. I’ve still no idea where this – in my perception: crazy – number comes from]. Anyhow, how to deal with this?&lt;br&gt;&#xA;Internally we performed a &lt;a href=&#34;www.troopers.de/.../TROOPERS10_Rapid_Risk_Assessment_Enno_Rey.pdf&#34;&gt;rapid risk assessment (RRA)&lt;/a&gt; focused on two main threats, that were:&lt;/p&gt;</description>
    </item>
    <item>
      <title>Back from Day-Con</title>
      <link>https://insinuator.net/2010/10/back-from-day-con/</link>
      <pubDate>Sat, 30 Oct 2010 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2010/10/back-from-day-con/</guid>
      <description>&lt;p&gt;… which was, as in the years before, an awesome &lt;a href=&#34;http://www.day-con.org&#34;&gt;event&lt;/a&gt;. Great talks, great people, great fun.&lt;br&gt;&#xA;Bruce Potter gave a &lt;a href=&#34;http://www.ernw.de/download/DayCon-10-Keynote.pdf&#34;&gt;keynote&lt;/a&gt; which did exactly what a good keynote should do: make the audience think and entertain it at the same time.&lt;br&gt;&#xA;[Those readers familiar with ERNW’s security model will certainly notice that we do not necessarily agree with everything he said. We still think that – in particular in times where infosec resources are scarce anyway – putting your bets on prevention provides a better cost/[security] benefit ratio than going for extensive detection capabilities.&lt;br&gt;&#xA;Fix the doors first, then think about installing a CCTV.&lt;br&gt;&#xA;Still, human nature tends to exchange “good security with low visibility” for “poor security with potentially good visibility” quite easily… as can be noted every day in many environments.]&lt;/p&gt;</description>
    </item>
    <item>
      <title>ERNW to contribute to government sponsored research project on telco security</title>
      <link>https://insinuator.net/2010/10/ernw-to-contribute-to-government-sponsored-research-project-on-telco-security/</link>
      <pubDate>Wed, 20 Oct 2010 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2010/10/ernw-to-contribute-to-government-sponsored-research-project-on-telco-security/</guid>
      <description>&lt;p&gt;Today we dare to (mis-) use the blog for a shameless self promotion 😉&lt;br&gt;&#xA;We’re happy to announce that ERNW will contribute to a government sponsored research project called &lt;a href=&#34;http://www.asmonia.de&#34;&gt;ASMONIA&lt;/a&gt; (which stands for the German title of the project that is &lt;em&gt;Angriffsanalyse und Schutzkonzepte für MObilfunkbasierte Netzinfrastrukturen unterstützt durch kooperativen InformationsAustausch&lt;/em&gt; [&lt;em&gt;Attack analysis and Security concepts for MObile Network infrastructures, supported by collaborative Information exchAnge&lt;/em&gt;]. those readers familiar with that kind of projects will have an idea of the importance of such acronyms ;-).&lt;/p&gt;</description>
    </item>
    <item>
      <title>Some recent presentations</title>
      <link>https://insinuator.net/2010/10/some-recent-presentations/</link>
      <pubDate>Mon, 11 Oct 2010 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2010/10/some-recent-presentations/</guid>
      <description>&lt;p&gt;Just a short notice today on some recent presentations from our team. As some of you might know we regularly give talks at conferences. This not only encompasses highly sophisticated security events like Black Hat or &lt;a href=&#34;http://www.troopers.de&#34;&gt;Troopers&lt;/a&gt;. Additionally – on our mission for a safer world – we try to spread the (security) word at various industry events that are usually focused on some aspect of the large and ramified IT world, not necessarily equipped with a strong focus on information security.&lt;br&gt;&#xA;A number of such events took place in the last few weeks and here’s some links on presentations given there. While not being as technically deep as the average Black Hat or Troopers &lt;a href=&#34;http://www.troopers.de&#34;&gt;&lt;/a&gt; attendee might expect, we still hope that one or another valued reader finds them useful (pls note that some parts are in German).&lt;/p&gt;</description>
    </item>
    <item>
      <title>MS10-063, Prevention</title>
      <link>https://insinuator.net/2010/09/ms10-063-prevention/</link>
      <pubDate>Wed, 15 Sep 2010 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2010/09/ms10-063-prevention/</guid>
      <description>&lt;p&gt;One of the four vulnerabilities rated “critical” from yesterday’s MS patchday, that is &lt;a href=&#34;http://www.microsoft.com/technet/security/bulletin/MS10-063.mspx&#34;&gt;MS10-063&lt;/a&gt;, has an interesting “Workarounds” section as for MS Internet Explorer. There it’s stated:&lt;/p&gt;&#xA;&lt;p&gt;“Disabling the support for the parsing of embedded fonts in Internet Explorer prevents this application from being used as an attack vector.”&lt;/p&gt;&#xA;&lt;p&gt;which, according to the advisory, should/can be done by setting the “Font Downloading” parameter to “Disable”.&lt;/p&gt;&#xA;&lt;p&gt;Which is exactly what &lt;a href=&#34;http://www.ernw.de/content/e15/e28/e1497/download1499/ERNW_Newsletter_31_Secure_IE8_Configuration_en_ger.pdf&#34;&gt;this document&lt;/a&gt; suggests. So taking a preventive approach, once more, might have saved some concerns (“Will we be targeted by this one”) and patch/testing time…&lt;/p&gt;</description>
    </item>
    <item>
      <title>That “new worm”…</title>
      <link>https://insinuator.net/2010/09/that-new-worm/</link>
      <pubDate>Mon, 13 Sep 2010 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2010/09/that-new-worm/</guid>
      <description>&lt;p&gt;Recently I noticed &lt;a href=&#34;http://www.h-online.com/security/news/item/New-email-worm-on-the-move-1076585.html&#34;&gt;this news&lt;/a&gt; titled “New email worm on the move”. At roughly the same time I received an email from a senior security responsible from a large customer asking for mitigation advice as they got “hit pretty hard” (by this exact piece of malware).&lt;br&gt;&#xA;Given I’m mainly an infrastructure and architecture guy usually I’m not too involved in malware protection stuff (besides my continuous ranting that – from an architectural point of view – endpoint based antivirus has a bad security benefit vs. capex/opex ratio). So I’m by no means an expert in this field. Still I keep scratching my head when I read the associated announcements (like &lt;a href=&#34;http://blog.trendmicro.com/old-malware-out-of-its-shell/&#34;&gt;this&lt;/a&gt;, &lt;a href=&#34;http://www.avertlabs.com/research/blog/index.php/2010/09/09/widespread-reporting-of-here-you-have-virus/&#34;&gt;this&lt;/a&gt; or &lt;a href=&#34;http://www.symantec.com/business/security_response/writeup.jsp?docid=2010-090922-4703-99&#34;&gt;this&lt;/a&gt;) from major “antivirus”, “malware protection” or “endpoint security” vendors – to save typing, in the remainder of the post I call them SNAKE vendors (where “SNAKE” stands for “Smart Nimble APT Kombat Execution”… or sth equally ingenious of the valued reader’s choice… 😉&lt;/p&gt;</description>
    </item>
    <item>
      <title>“blackberry api to record phone calls”</title>
      <link>https://insinuator.net/2010/08/blackberry-api-to-record-phone-calls/</link>
      <pubDate>Wed, 25 Aug 2010 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2010/08/blackberry-api-to-record-phone-calls/</guid>
      <description>&lt;p&gt;This is currently the most frequent search term leading Internet users to the Troopers website.&lt;br&gt;&#xA;Probably &lt;a href=&#34;http://www.troopers.de/content/e728/e897/e900/TROOPERS10_Bugs_and_Kisses_Sheran_Gunasekera.pdf&#34;&gt;Sheran Gunasekera’s great presentation “Bugs &amp;amp; Kisses – Spying on BlackBerry users for fun”&lt;/a&gt; is the piece they are after. Whatever they look for, this search term may help to shed light to an aspect that seems a bit overlooked in the ongoing debate about governments (U.A.E., Saudi Arabia, India) trying to get their hands on communication acts performed with BlackBerries in their countries.&lt;br&gt;&#xA;[For those interested in that discussion &lt;a href=&#34;http://www.schneier.com/blog/archives/2010/08/uae_to_ban_blac.html&#34;&gt;this blog entry of Bruce Schneier&lt;/a&gt; may serve as a starting point.]&lt;/p&gt;</description>
    </item>
    <item>
      <title>Just a Quick Note on the Library Loading / Binary Planting Stuff</title>
      <link>https://insinuator.net/2010/08/just-a-quick-note-on-the-library-loading-/-binary-planting-stuff/</link>
      <pubDate>Tue, 24 Aug 2010 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2010/08/just-a-quick-note-on-the-library-loading-/-binary-planting-stuff/</guid>
      <description>&lt;p&gt;For those of you who missed it: Microsoft released the &lt;a href=&#34;http://www.microsoft.com/technet/security/advisory/2269637.mspx&#34;&gt;associated advisory&lt;/a&gt; yesterday, together with a &lt;a href=&#34;http://support.microsoft.com/?kbid=2264107&#34;&gt;hotfix&lt;/a&gt; introducing a new registry key that allows users to control the DLL search path algorithm. For a detailed explanation of the problem we refer to &lt;a href=&#34;http://arstechnica.com/microsoft/news/2010/08/new-windows-dll-security-flaw-everything-old-is-new-again.ars&#34;&gt;the excellent article on Ars Technica&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;p&gt;For the record: no, AV (anti-virus software) will – in most cases – not protect you from security problems related to this one. And, no, there is no easy patch for this one either.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Application Virtualization as Browser Security Control?</title>
      <link>https://insinuator.net/2010/08/application-virtualization-as-browser-security-control/</link>
      <pubDate>Mon, 09 Aug 2010 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2010/08/application-virtualization-as-browser-security-control/</guid>
      <description>&lt;p&gt;One of the biggest pains in the ass of most ISOs – and subsequently subject of fierce debates between business and infosec – is the topic of “Browser Security”, i.e. essentially the question “How to protect the organization from malicious code  brought into the environment by users surfing the Internet?”.&lt;/p&gt;&#xA;&lt;p&gt;Commonly the chain of events (of a typical malware infection act) can be broken down to the following steps:&lt;/p&gt;&#xA;&lt;p&gt;1.) Some code – no matter if binary or script code – gets transferred (mostly: downloaded) to some system “from the Internet”, that means “over the network”.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Spooky Story about Break-In in Military Contractor Facility</title>
      <link>https://insinuator.net/2010/07/spooky-story-about-break-in-in-military-contractor-facility/</link>
      <pubDate>Sun, 25 Jul 2010 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2010/07/spooky-story-about-break-in-in-military-contractor-facility/</guid>
      <description>&lt;p&gt;… recently published &lt;a href=&#34;http://www.tampabay.com/news/publicsafety/crime/thieves-swipe-thousands-of-laptops-from-special-ops-contractor-in/1108521&#34;&gt;here&lt;/a&gt;.&lt;br&gt;&#xA;While I certainly agree with those comments stating that there’s a fishy element in the – conspiracy theory nurturing – story itself, this reminds me that Graeme Neilson (who gave the “&lt;a href=&#34;http://www.troopers.de/content/e728/e897/e938/TROOPERS10_Netscreen_of_the_Dead_Graeme_Neilson.pdf&#34;&gt;Netscreen of the Dead&lt;/a&gt;” talk at &lt;a href=&#34;http://www.troopers.de&#34;&gt;Troopers&lt;/a&gt;, discussing modified firmware on Juniper and Fortinet devices) and I plan to give a talk on “Supply Chain (In-)Security” at this year’s &lt;a href=&#34;http://www.day-con.org&#34;&gt;Day-Con&lt;/a&gt; event. We still have to figure out with Angus if it fits into the agenda (and if we have enough material for an interesting 45 min storyline ;-)) though. Stay tuned for news on this here.&lt;/p&gt;</description>
    </item>
    <item>
      <title>News from the Desktop, Edition 2010/07/21</title>
      <link>https://insinuator.net/2010/07/news-from-the-desktop-edition-2010/07/21/</link>
      <pubDate>Wed, 21 Jul 2010 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2010/07/news-from-the-desktop-edition-2010/07/21/</guid>
      <description>&lt;p&gt;Back on track as for one of our favorite rant subjects: desktop security. &lt;a href=&#34;http://www.microsoft.com/technet/security/advisory/2286198.mspx&#34;&gt;This stuff&lt;/a&gt;, commonly called the “LNK vulnerability”, has gained quite some momentum in the last days, including the release of &lt;a href=&#34;http://www.metasploit.com/modules/exploit/windows/browser/ms10_xxx_windows_shell_lnk_execute&#34;&gt;a &lt;em&gt;Metasploit&lt;/em&gt; module&lt;/a&gt; and a temporary raise of &lt;a href=&#34;http://isc.sans.edu/&#34;&gt;SANS Internet Storm Center&lt;/a&gt;‘s Infocon level to yellow (it’s back on green in the interim).&lt;/p&gt;&#xA;&lt;p&gt;CVE-2010-2568 has been assigned and some technical details can be found &lt;a href=&#34;http://blogs.technet.com/b/mmpc/archive/2010/07/16/the-stuxnet-sting.aspx&#34;&gt;here&lt;/a&gt; and &lt;a href=&#34;http://www.sophos.com/blogs/chetw&#34;&gt;here&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;p&gt;To give you a rough idea how this piece works, here’s a quote from the &lt;a href=&#34;http://www.kb.cert.org/vuls/id/940193&#34;&gt;US-CERT advisory&lt;/a&gt;:&lt;/p&gt;</description>
    </item>
    <item>
      <title>The Emperor’s New Security Indicators</title>
      <link>https://insinuator.net/2010/07/the-emperors-new-security-indicators/</link>
      <pubDate>Sun, 18 Jul 2010 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2010/07/the-emperors-new-security-indicators/</guid>
      <description>&lt;p&gt;Interesting research from Stuart Schechter et.al. &lt;a href=&#34;http://usablesecurity.org/emperor/&#34;&gt;here&lt;/a&gt;.&lt;br&gt;&#xA;They evaluated the effect that the removal or modification of online banking sites’ security features had on the users’ behavior (as for entering or withholding their passwords). Maybe for some of you not too surprising it turned out that the vast majority of users entered their passwords even if obviously alarming clues were present on the websites.&lt;br&gt;&#xA;This, again, shows how important it is to understand how users behave, what their motives and incentives are and how to build environments that help them acting securely. This even more applies to corporate space. At times, bringing an industrial/organizational psychologist in might be a much better investment than writing yet-another-ignored-piece-of-policy.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Our Favorite Subject: [It’s all about] Risk</title>
      <link>https://insinuator.net/2010/07/our-favorite-subject-its-all-about-risk/</link>
      <pubDate>Sun, 11 Jul 2010 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2010/07/our-favorite-subject-its-all-about-risk/</guid>
      <description>&lt;p&gt;Some days ago my old friend Pete Herzog from &lt;a href=&#34;http://www.isecom.org&#34;&gt;ISECOM&lt;/a&gt; posted a blog entry titled “Hackers May Be Giants with Sharp Teeth” &lt;a href=&#34;https://www.infosecisland.com/blogview/5031-Hackers-May-Be-Giants-with-Sharp-Teeth.html&#34;&gt;here&lt;/a&gt; which – along with some quite insightful reflections on the way kids perceive “bad people” – contains his usual rant on (the uselessness of) risk assessment.&lt;br&gt;&#xA;Given that this debate (whether taking a risk-based infosec approach is a wise thing or not) is a constant element of our – Pete’s and mine – long lasting relationship I somehow feel enticed to respond 😉&lt;/p&gt;</description>
    </item>
    <item>
      <title>News from Old Friends, Edition 2010/06/09</title>
      <link>https://insinuator.net/2010/06/news-from-old-friends-edition-2010/06/09/</link>
      <pubDate>Wed, 09 Jun 2010 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2010/06/news-from-old-friends-edition-2010/06/09/</guid>
      <description>&lt;p&gt;This is the first post of a – potential – series of rants on ubiquitous pieces of crap (security-wise), bothering pretty much every ISO I know.&lt;br&gt;&#xA;I’m talking about “common desktop applications” and today’s topic is going to be the beloved Adobe Flash Player. Some of you who had the opportunity (or imposition 😉 to listen to one my talks covering “modern enterprise security space” (e.g. &lt;a href=&#34;http://troopers09.org/content/e644/e676/TROOPERS09_rey_keynote_stop_the_madness.pdf&#34;&gt;this one&lt;/a&gt;) might remember me saying sth like “If a fairy godmother turned up and asked me for three things to get rid of in order to enhance overall corporate information security in a sustainable way, my answers would be…” and then giving Adobe Flash as the first mention. (before you ask: amongst the other candidates are Apple Quicktime, Windows GDI and “Javascript in Acrobat Reader”).&lt;/p&gt;</description>
    </item>
    <item>
      <title>Some reflections on virtualization security, part 1</title>
      <link>https://insinuator.net/2009/12/some-reflections-on-virtualization-security-part-1/</link>
      <pubDate>Mon, 07 Dec 2009 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2009/12/some-reflections-on-virtualization-security-part-1/</guid>
      <description>&lt;p&gt;Today was an interesting day, for a number of reasons. Amongst those it stuck out that we were approached by two very large environments (both &amp;gt; 50K employees) to provide security review/advise, as they want to “virtualize their DMZs, by means of VMware ESX”.&lt;br&gt;&#xA;[yes, more correctly I could/should have written: “virtualize some of their DMZ segments”. but this essentially means: “mostly all of their DMZs” in 6-12 months. and “their DMZ backend systems together with some internal servers” in 12-24 months. and “all of this” in 24-36 months. so it’s the same discussion anyway, just on a shifted timescale ;-)]&lt;/p&gt;</description>
    </item>
    <item>
      <title>New SSL/TLS MiTM Attacks</title>
      <link>https://insinuator.net/2009/11/new-ssl/tls-mitm-attacks/</link>
      <pubDate>Mon, 09 Nov 2009 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2009/11/new-ssl/tls-mitm-attacks/</guid>
      <description>&lt;p&gt;A number of customers has approached us with questions like “Those new MiTM attacks against SSL/TLS, what’s their impact as for the security of our SSL VPNs with client certificates”?&lt;br&gt;&#xA;In the following we give our estimation, based on the information publicly available as of today.&lt;/p&gt;&#xA;&lt;p&gt;On 11/04/09 two security researchers (Marsh Ray and Steve Dispensa) published a &lt;a href=&#34;http://extendedsubset.com/Renegotiating_TLS.pdf&#34;&gt;paper&lt;/a&gt; describing some previously (presumably/hopefully) unknown MiTM attacks against SSL/TLS. CVE-2009-3555 was assigned to the underlying vulnerabilities within SSL/TLS.&lt;br&gt;&#xA;The attacks described might potentially allow an attacker to hijack an authenticated user’s (SSL/TLS) session. In an &lt;a href=&#34;https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.txt&#34;&gt;IETF draft&lt;/a&gt; published 11/09/09 and describing a potential protocol extension intended to mitigate the attacks the following is stated:&lt;br&gt;&#xA;“SSL and TLS renegotiation are vulnerable to an attack in which the attacker forms a TLS connection with the target server, injects content of his choice, and then splices in a new TLS connection from a client.  The server treats the client’s initial TLS handshake as a renegotiation and thus believes that the initial data transmitted by the attacker is from the same entity as the subsequent client data.”&lt;/p&gt;</description>
    </item>
    <item>
      <title>If they had used DLP…</title>
      <link>https://insinuator.net/2009/10/if-they-had-used-dlp/</link>
      <pubDate>Sat, 31 Oct 2009 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2009/10/if-they-had-used-dlp/</guid>
      <description>&lt;p&gt;… &lt;a href=&#34;http://www.securityfocus.com/brief/1030&#34; title=&#34;Security Focus on Peer to Peer Data Loss&#34;&gt;this&lt;/a&gt; would not have happened. At least this is what $SOME_DLP_VENDOR might tell you.&lt;br&gt;&#xA;Maybe, maybe not. It wouldn’t have happened if they’d followed “common security best practices” either. Like “not to process sensitive data on (presumably) private laptops” or “not to run file sharing apps on organizational ones” or “not to connect to organizational VPNs and home networks simultanously”. yadda yadda yadda.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Series on “Outdated Threat Models” – Part 1</title>
      <link>https://insinuator.net/2009/10/series-on-outdated-threat-models-part-1/</link>
      <pubDate>Sun, 25 Oct 2009 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2009/10/series-on-outdated-threat-models-part-1/</guid>
      <description>&lt;p&gt;Yesterday I took a long run (actually I did the full distance &lt;a href=&#34;http://www.albmarathon.de&#34;&gt;here&lt;/a&gt;) and usually such exercises are good opportunities to “reflect on the world in general and the infosec dimension of it in particular”… at least as long as your blood sugar is still on a level to support somewhat reasonable brain activity 😉&lt;/p&gt;&#xA;&lt;p&gt;Anyhow, one of the outcomes of the number of strange mental stages I went through was the idea of a series of blogposts on architectural or technological approaches that are widely regarded as “good security practice” but may – when looked at with a bit more of scrutiny – turn out to be based on what I’d call “outdated threat models”.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Welcome to insinuator.net</title>
      <link>https://insinuator.net/2009/10/welcome-to-insinuator.net/</link>
      <pubDate>Tue, 20 Oct 2009 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2009/10/welcome-to-insinuator.net/</guid>
      <description>&lt;p&gt;Welcome to insinuator.net, the semi-official blog of &lt;a href=&#34;http://www.ernw.net&#34; title=&#34;ERNW Website&#34;&gt;ERNW GmbH&lt;/a&gt;.&lt;br&gt;&#xA;You may ask: Why yet another infosec blog? Aren’t there already just too many around? Well, possibly. But that opulence is part of blogging in general, isn’t it? 😉&lt;br&gt;&#xA;Given we are trying to contribute to “public space &amp;amp; opinion” in a number of ways anyway [e.g. by our &lt;a href=&#34;http://www.ernw.de/content/e7/e181/index_eng.html&#34; title=&#34;Event Archives&#34;&gt;presentations&lt;/a&gt; or our &lt;a href=&#34;http://www.ernw.net/nl&#34; title=&#34;ERNW Newsletter&#34;&gt;newsletter&lt;/a&gt;] it seemed just too logical – and we’ve been asked by various people as well – to add another element to global blogosphere. Voilà, here we go!&lt;br&gt;&#xA;What can you, dear reader, expect? Of course all kinds of shameless self-references, maybe occasionally a little bit of insight or even wisdom (yes, you’re right: modesty is not amongst our key virtues, at times) and – hopefully – some entertainment.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
