Building on Insinuator.net - Bold Statements

One More Thing: Introducing the New macOS 26 Tahoe Hardening Guide

Wed, 11 Feb 2026 00:00:00 +0000

After seven years, we’re publishing a new macOS hardening guide. Fully updated, modernized, and now publicly available on GitHub as Markdown and on our website as PDF.

The previous guide, written for macOS Mojave (10.14), reflected a very different macOS security model. At the time, hardening often meant working around the operating system, manually enforcing controls, and compensating for missing platform guarantees. That guide served its purpose, but the platform has fundamentally changed since then.

Setting up Secure Boot on Gentoo Linux

Mon, 28 Jul 2025 00:00:00 +0000

The purpose of this blog post is to explain how Secure Boot works. In particular, we will explain where current implementations of Secure Boot by Linux distributors fall short compared to Microsoft Windows and Apple macOS.

Major distributors like Canonical, Debian, openSUSE, and Red Hat place a high priority on making their operating systems work out of the box. Given the current Linux landscape with out-of-tree drivers and incompatible licenses, providing the end user with all the drivers possibly needed to boot the system can be challenging.

Insecure Boot: Injecting initramfs from a debug shell

Thu, 03 Jul 2025 00:00:00 +0000

Many Linux hardening guides focus on well-known protections: full-disk encryption, Secure Boot, and password-protected bootloaders. While these measures are critical, they often overlook a subtle but serious attack vector: the ability to drop into a debug shell via the Initial RAM Filesystem (initramfs). This oversight can enable an attacker with brief physical access to bypass conventional boot protections and inject persistent malware into the system.

In this post, it is demonstrated how this attack works on modern Linux distributions, such as Ubuntu and Fedora, and explained why existing guidance often fails to mention it.

Cookie Prefixes – The Lesser Known Cookie Security Feature

Tue, 08 Apr 2025 00:00:00 +0000

When you’re analyzing web applications as a pentester or reading pentest reports about web applications, you will often see findings regarding cookies missing certain security flags. The Set-Cookie HTTP header and the JavaScript document.cookie API allow to use, for example, the flags Secure, Path, and Domain. Common audit and pentest tools will tell you when your web application does not or just insecurely implements these cookie flags.

However, they do not provide optimal security even when using these flags correctly. However, there are mitigations available that partly solve the issues.

BMBF UNCOVER – Monitoring von Sicherheitsvorfällen in Fahrzeugen

Fri, 21 Jun 2024 00:00:00 +0000

English Abstract

For the realization and introduction of autonomous vehicles, the safe interaction of functions, systems and services as well as their monitoring over the entire product life cycle is essential. An exclusive security-by-design approach is no longer sufficient and must be continuously supported by feedback obtained from in-the-wild operation. This is where the recently successfully completed joint project BMBF UNCOVER comes into play, which targets the requirements of the standards ISO/SAE 21434 (Road vehicles – Cybersecurity engineering) and ISO 21448 (Road vehicles – Safety of the intended functionality (SOTIF)).

Student Project - Audit Framework

Fri, 20 Oct 2023 00:00:00 +0000

Introduction

In 2021, ERNW collaborated with Hochschule Mannheim for their CEP (Cyber Security Entwicklungsprojekt) to build an auditing framework for testing operating system configurations against security procedures. This project is part of the education program of the university to give the students the chance to utilize the knowledge gained throughout the first semesters in a real world project. ERNW posed as the fictitious customer, providing a requirements document and regular meetings with all project groups for feedback. We planned to process and adapt the results for an open source auditing framework. Unfortunately, we were not able to finish this project yet, but we think the students should get some attention for their work independent from our side. So here is a short summary of what the students created and the corresponding repositories.

Release of PTE Analysis plugins for Volatility 3

Fri, 31 Dec 2021 00:00:00 +0000

I’m happy to announce the release of several plugins for Volatility 3 that allow you to dig deeper into the memory analysis. One of those plugins is PteMalfind, which is essentially an improved version of malfind. Another one is PteResolve which, similarly to the WinDBG command !pte, allows you to inspect Page Table Entry (PTE) information for e.g., a given virtual address. In this blog post we will have a closer look at these and more plugins, and the PteEnumerator base class and what you can do with it. The memory dump used for this blog post is available here. Some of the injection tools used in this blog post can be gathered from here.

ERNW White Paper 70 – HL7 FHIR: Preserving Distributed Resource Integrity

Fri, 18 Dec 2020 00:00:00 +0000

With this blog post I am pleased to announce the publication of a new ERNW White Paper about the HL7 FHIR communication standard.

Introduction

Digital networking is already widespread in many areas of life. More and more medical devices are also being networked in the healthcare industry. This growth makes the development and use of new medical communication standards necessary since existing solutions can only meet the changing requirements with great effort. The HL7 FHIR standard is an example of such a medical communication standard. FHIR is said to have increased the interoperability between different medical contexts,e.g., administration, billing, and clinical care, to enable data exchange of various systems. The FHIR standard addresses the security risks associated with strongly networked communication from a large number of systems across the trust and organizational boundaries only indirectly because FHIR does not define mandatory security controls or requirements.

Reversing C++ Without Getting a Heart Attack – DEvirtualize VIrtual Calls With Devi

Thu, 12 Nov 2020 00:00:00 +0000

TLDR: This blogpost presents devi, a tool that can help you devirtualize virtual calls in C++ binaries. It uses Frida to trace the execution of a binary and uncover the call sources and destinations of virtual calls. The collected information can then be viewed in IDA Pro, Binary Ninja, or Ghidra. The plugin adds the respective control-flow edges allowing further analysis (using different plugins) or simply providing more comfort when analyzing C++ binaries.

Doing it Server-Side with CypherDog 4.0

Thu, 17 Sep 2020 00:00:00 +0000

Arrroooo… Bloodhound Crew!! Heard the news? CypherDog 4.0 is out and it’s full of new features…

Now a couple of you might be thinking “Hey there, wait a minute… didn’t CypherDog 3.0 come out not that long ago..??”, and I am happy to see some of you are paying attention…
Indeed, when Bloodhound 3 came out, I quickly updated CypherDog 2 to CypherDog 3 to be compatible with it.
But Bloodhound 3 is compatible with neo4j 3 and 4, however the neo4j REST API has been deprecated in neo4j 4 and CypherDog 3 relied on it.
Long story short, CypherDog 4.0 is a full rewrite compatible with the new neo4j 4 HTTP API, and since I was refactoring the whole thing, I added some cool new features to the tool.
The idea was to be able to do more with less keystrokes, and to do it server-side…
And so I made a meme.

How can data from fitness trackers be obtained and analyzed with a forensic approach?

Thu, 10 Sep 2020 00:00:00 +0000

The use of Internet of Things devices is continuously increasing: People buy devices, such as smart assistants, to make their lives more comfortable or fitness trackers to assess sports activities. According to the Pew Research Center [1], every fifth American wears a device to track their fitness. In Germany, the number increases likewise. The increasing number of fitness trackers in use can also be seen in criminal proceedings, as there exist more and more cases where these devices provide evidence.

ACM WiSec 2020

Sun, 26 Jul 2020 00:00:00 +0000

Last week I attended ACM WiSec. Of course, only virtually. The first virtual conference I attended. Coincidentally, it was also the first conference I presented at. While the experience was quite different from a “real” conference, the organizers did a great job to make the experience as good as possible with, for example, a mattermost instance to interact with other conference participants.

In the following, I will list a few talks and papers that I either found very interesting or that generally stood out to me:

Back from the ATT&CK jungle…

Wed, 06 May 2020 00:00:00 +0000

So there was a pandemic, the whole world was under lockdown, and I got a bit depressed.
I needed something new in my life, so I decided to take my favorite dog out for a walk in the ATT&CK jungle to check out the newly added sub-techniques…

If you’re not familiar with ATT&CK and are wondering what this is all about, no worries…
ATT&CK stands for Adversarial Tactics, Techniques & Common Knowledge.
It’s a treasure trove of information about real-life offensive tradecraft.
I like to see it as an open-source encyclopedia of corporate post-exploitation.
There is a growing community around the project and more info keeps being added to it.
[Check out this post by @LikeTheCoins if you want to know more]

DNS exfiltration case study

Wed, 04 Mar 2020 00:00:00 +0000

Lately, we came across a remote code execution in a Tomcat web service by utilizing Expression Language. The vulnerable POST body field expected a number. When sending ${1+2} instead, the web site included a Java error message about a failed conversion to java.lang.Long from java.lang.String with value "3".

From that error message we learned a couple of things:

The application uses Java
We are able to execute EL expressions
Output from the EL engine is always returned as String

Whenever you are able to execute code within a Java Context, the most interesting part is to check whether we can get a Runtime object and execute arbitrary OS commands.

BASTA! Autumn 2019 – Security in DevOps

Thu, 28 Nov 2019 00:00:00 +0000

Some time ago I had the pleasure to speak at the BASTA! Autumn 2019 conference. There, I promised to publish my slides such that they can be used as a reference for developers and security guys like me. And with this blog post I would like to hold up to my promise.

Overall, the talk was about the challenges of “How to bring security into modern DevOps processes”. Hence, I demonstrated how security can be integrated more or less seamlessly into the modern agile software development workflow. I proposed some risk-depended recommendations about which measurements should be established, for example, within the CI pipeline.

Blue Hands On Bloodhound

Fri, 18 Oct 2019 00:00:00 +0000

Hi there,

SadProcessor here, happy to be back on the Insinuator to share with you some of my latest BloodHound adventures and experiments…

TL;DR Well too bad for you…

Before diving into a bit of code and some BloodHound data manipulation,
I would like to thank the BruCon Crew for having me over last week for BruCON0x0B.
I had the pleasure of delivering a 4h BloodHound & Cypher workshop in the lovely city of Gent [in a fantastic training room], and I am pleased with the interaction & feedback I had with the attendees.
I was also very happy to see almost as many Blues as Reds in the room [as well as regular security folks!!], all together having a play with BloodHound & Cypher.

A Brief History of the IPv4 Address Space

Mon, 26 Aug 2019 00:00:00 +0000

This is meant to be the first part of a 3-part series discussing the space & 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.

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.

Troopers 19 – Badge Hardware

Thu, 18 Jul 2019 00:00:00 +0000

This post by Jeff (@jeffmakes) was delayed due to interferences with other projects but nevertheless, enjoy!

This year, it was my great honour to design the hardware for the Troopers19 badge.

We wanted to make a wifi-connected MicroPython-powered badge; something that would be fun to take home and hack on. It was a nice opportunity to use a microcontroller platform that I hadn’t tried before. I also used the project as a chance to finally migrate my PCB workflow from Eagle to Kicad. Inevitably it was a painful transition, which resulted in quite some delay to the project as I floundered around in the new tool, but it does mean the design files are in an open format which I hope will benefit the community of Troopers attendees and future badge designers!

DirectoryRanger 1.5.0 Is Available

Thu, 13 Jun 2019 00:00:00 +0000

The next major release of DirectoryRanger is now available for customers, and for everyone who would like to try it ;-). Current attacks show that quite often the topic of Active Directory Security is not on the security agenda, but it should be, and this was the reason for us to build the tool and, of course, to maintain and improve it. So what are the major new features released with DirectoryRanger 1.5.0? Here we go:

Troopers 19 – Hack your badge

Mon, 15 Apr 2019 00:00:00 +0000

Sadly, TROOPERS 19 is already over. I had great fun meeting all of you, helping you with your badge problems and seeing others hacking on their badges for example to get custom images on there.

With this year’s badge we wanted to give you something you can reuse after the conference, learn new things new build something on your own.

As promised in our talk Jeff and I would like to give you a short introduction into the badge internals. Along with this post we will release the source code for the badge firmware, the provisioning server and the schematics for the PCB.

2019 – Year Of The Blue Dog…

Mon, 28 Jan 2019 00:00:00 +0000

Back from Holidays, you started the year well motivated to make the world a safer place.
However, sitting at your desk today you realize nothing really changed since last year, and you are surfing the web, feeling a bit blue, trying to avoid that pile of emails waiting for you and wondering how you could gain some visibility on your domain in order to better defend it.
No worries, emails can wait a bit longer. All you need is some fresh air and something cool to keep your defensive mind motivated for the year, and I might have just what you need; so put on your shoes and let me take you on a 15 minute Cypher walk with a cool blue dog…

DirectoryRanger 1.1.0 Introduces Informational Audit Checks

Mon, 03 Dec 2018 00:00:00 +0000

With version 1.1.0 our tool DirectoryRanger introduces a new feature: informational audit checks. These checks do not have a severity rating because they are just “for your information” and the included information might or might not contain security issues, depending on other facts. But these checks can help to reduce your Active Directory attack surface by pointing you to some aspects which need your attention and at least require to be discussed and documented (and they might also imply governance measures like a risk acceptance).

nmap-parse-output: A tool for analyzing Nmap scans

Fri, 24 Aug 2018 00:00:00 +0000

tl;dr: With the tool nmap-parse-output you can convert, manipulate or extract data from a Nmap/masscan scan output. This allows you to get the information you’re looking for by just entering a straightforward command.

Preamble

A while ago, we had to scan a mass amount of IPs within a project for a customer. While it’s feasible to read the whole output of a Nmap scan if you have just a few alive hosts, this was not possible anymore for this mass amount of systems. We’ve started with a masscan to scan all 2^16 ports of the IP ranges and wanted to perform a more precise analysis of the alive hosts (which had responded to at least one SYN packet) with Nmap. The result of this scan grew to nearly a hundred megabyte and we now had to do an analysis of which ports we had to look deeper into and which are intended to be open.

IPython Support for Binary Ninja

Fri, 17 Aug 2018 00:00:00 +0000

This blogpost is about the release of a plugin for Binary Ninja that allows you to run a Python Kernel inside the Binary Ninja GUI environment to which you can attach a Jupyer (QT) console, formerly known as IPython shell. The first section is about why this is useful, the second is about some issues I encountered and how to solve them, and the third contains everything you need to know to set it up.

dizzy version 2.0 released

Fri, 03 Aug 2018 00:00:00 +0000

A new major version of our fuzzing framework dizzy has been released.

This blog post will cover the biggest changes and new features, as well as give you a short introduction into how to use them.

You can find the new version on github.

Installation

There are two supported ways of installing dizzy:

via pypi
$ pip install dizzy
via setup.py
$ git clone https://https://github.com/ernw/dizzy && cd dizzy && python setup.py install

PoSh_ATTCK – ATT&CK Knowledge at your PowerShell Fingertips…

Sat, 07 Jul 2018 00:00:00 +0000

When I recently joined the Windows Security team at ERNW, Enno asked me if I wanted to write a ‘welcome’ blogpost on a topic of my choosing… Up for the challenge, and since I had been playing with BloodHound & Cypher for the last couple of months, I first thought I would do something on that topic.

However, after gathering my thoughts and some Cypher I had collected here and there, I realized that the topic of Bloodhound Cypher might actually require several blog posts… And so I changed my mind. I will keep the joys of Cypher for later, and in this post, I will talk about a tiny tool I wrote to query the Mitre ATT&CK™ knowledge base from the comfort of a PowerShell prompt.

New Release of Glibc Heap Analysis Plugins

Wed, 06 Jun 2018 00:00:00 +0000

After quite some time and work, I’m happy to announce the new release of the Linux Heap Analysis Plugins, which are now part of the Rekall project, but not yet part of an official Rekall release, so you have to grab them manually.
This release fixes several bugs and adds the following features:

Support for Glibc version 2.26 (tcache chunks) and 2.27
Heapsearch now includes Rekall’s yara scan functionality
x86 Glibc versions with a modified MALLOC_ALIGNMENT value of 16 (as done in arch’s glibc package 2.26) are now supported
Improved retrieval of main_arena and new automated retrieval of malloc_par struct; so for the majority of cases, the corresponding cmd line options are not necessary anymore and hence no debug information have to be retrieved.
main_arena and malloc_par struct retrieval now also applies for statically linked binaries; there might however be cases, where it is necessary to specify the malloc_par struct offset and the used glibc version number

While Glibc version 2.27 does not really change much for the heap from a forensics point of view, version 2.26 introduced a new feature called tcache (per thread cache). Those caches are essentially just a new type of bin, holding freed chunks, but seem to improve the performance.
Sadly, only two days after its first commit, there was already a blog post explaining the functionality (not so sad 😉 ) and also some discovered vulnerabilities (here we go with the sad part).
Besides introducing a new landscape for attackers, this feature added two new heap management structs and one additional chunk per thread-heap (each thread has its own heap, up until an upper limit). This chunk is located at the beginning of each heap and hence, part of a raw heap dump (so be aware of that, if you are doing a raw analysis without the plugins).
The chunk holds the content of the tcache_perthread_struct, which has to members:

printf(“Hello World!”) Part 2

Mon, 30 Apr 2018 00:00:00 +0000

As our journey to the new product continues we are facing the typical challenges of phase 2 in the software development life cycle, the design phase (see part 1 for the overview of the phases):

Design and Components

The new tool will deal with Active Directory security so it has to integrate into large scale Windows based customer environments, which in turn makes the decision about the components quite easy ;-). We have chosen .NET as our primary development platform including key components from Microsoft to run our application, these components include the IIS and Microsoft SQL Express/Server and of course one Windows Server.

printf(“Hello World!”)

Fri, 23 Feb 2018 00:00:00 +0000

ERNW has a new baby, so please say “hello” to the new ERNW SecTools GmbH ;-).
But why another ERNW company? Short answer: Because we want to contribute to changing the way how software is built today: insecure, focused on profit and sometimes made by people who ignore lessons from history. So how can we contribute in this space? Start changing it ;-).

Confucius said: “The man who moves a mountain begins by carrying away small stones” and that’s our way to go. It is not about building error free or unbreakable software, it is about changing the way how software is built today, about improving security and about raising the bar.

Virtualized Training Environment with Ansible

Fri, 02 Feb 2018 00:00:00 +0000

As Kai and I will be holding a TROOPERS workshop on automation with ansible, we needed a setup for the attendees to use ansible against virtual machines we set up with the necessary environment. The idea was, that every attendee has their own VMs to run ansible against, ideally including one to run ansible from, as we want to avoid setup or version incompatibilities if they set up their own ansible environment on their laptop. Also they should only be able to talk to their own machines, thus avoiding conflicts because of accidental usage of wrong IPs or host names but also simplify the setup for the users.

Why It Might Make Sense to Use IPv6 in Enterprise Infrastructure Projects

Fri, 10 Nov 2017 00:00:00 +0000

Looking at IPv6 deployment graphs like this one 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).

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 these slides from RIPE74 to understand some of the reluctance to deploy IPv6 in certain companies).

Reading the BlueCoat FileSystem

Thu, 05 Oct 2017 00:00:00 +0000

You may remember our last post regarding the SGOS system and the proprietary file system. Since then, we got access to a newer version of the system (6.6.4.2). Still not the most current one (which seems to be 6.7.1.1) nor of the 6.6.x branch (which seems to be 6.6.5.1) though. As this system version also used the same proprietary filesystem (although it initially booted from a FAT32 partition), I decided to take a deeper look into this.

A Life Without Vendors Binary Blobs

Mon, 07 Aug 2017 00:00:00 +0000

This blogpost will be about my first steps with coreboot and libreboot and a life with as few proprietary firmware blobs as possible. My main motivation were the latest headlines about fancy firmware things like Intel ME, Computrace and UEFI backdoors. This post is not intended to be about a as much as possible hardened system or about coreboot/libreboot being more secure, but rather to be able to look into every part of software running on that system if you want to.

IPv6 RA Flags, RDNSS and DHCPv6 Conflicting Configurations Revisited

Mon, 17 Jul 2017 00:00:00 +0000

As you may know, we published a whitepaper discussing the behavior of different operating systems once they receive IPv6 configuration parameters from different sources two years ago. At that time, the results were quite a mess. We were curious whether the situation is still so “dire” like two years ago. We fired up the lab, updated the tested operating systems and performed the tests again.

To summarize, at least in scenarios were only one router is involved, the results look way more consistent (even cross operating system) then two years ago. So we made progress on this front. Unfortunately, as soon as a second router is introduced into the segment it gets messy and the operating systems do show inconsistent behavior.

Release of Glibc Heap Analysis Plugins for Rekall

Thu, 13 Jul 2017 00:00:00 +0000

I’m happy to announce the release of several Glibc heap analysis plugins (for Linux), resp. plugins to gather information from keepassx and zsh, which are now included in the Rekall Memory Forensic Framework. This blogpost will demonstrate these plugins and explain how they can be used. More detailed information, including real world scenarios, will be released after the talk at this years DFRWS USA.

Before being able to reliably analyze the heap of a process, a profile, for the Glibc version being used, must be provided. However, this step should for most cases be fairly simple and only consist of gathering the offset for the mp_ and main_arena variables:

Agile Development & Security

Sun, 26 Feb 2017 00:00:00 +0000

I’m a big fan of Chris Gates’ publications on DevOops and From Low to Pwned. The content reflects a lot of issues that we also experience in many assessments in general and assessments in agile environments in particular. In addition, we were supporting several projects recently that were organized in an agile way. In this post, I want to summarize some thoughts on how security work can/should be integrated into agile projects. The post was also a result from the preparation of our upcoming Troopers workshop on Docker Security & Devops, which of course also covers organizational aspects, but not to the degree this post describes them.

IPv6 Properties of Windows Server 2016 / Windows 10

Mon, 30 Jan 2017 00:00:00 +0000

In this post we’ll take a detailed look at the properties of the Windows Server 2016 IPv6 stack.
I perform(ed) this exercise for several reasons:

Server 2016 is the latest OS released by Microsoft so this might give an indication as for their plans & strategy when it comes to supporting certain specifications.
(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…).
as I laid out in this post the configuration approach an organization takes for their servers might depend on the support of specific features.
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 this or this in the past).
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.

Version

IPv6 Configuration Approaches for Servers

Wed, 21 Dec 2016 00:00:00 +0000

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.

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:

Considerations on DMZ Design in 2016, Part 3: Some Notes on Firewall Rule Management

Mon, 21 Nov 2016 00:00:00 +0000

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 here, part 2 on reverse proxies here).
Again, I dare to deviate a bit from the plan & 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.

(Securely) Updating Smart Devices / Some Considerations

Tue, 15 Nov 2016 00:00:00 +0000

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 “Internet of Things Software Update Workshop (IoTSU)” might be a good starting point).
Given Matthias and I will moderate the respective session at tomorrow’s IoT Insight Summit I started writing down some points that we consider relevant in this context.

IPv6 Source Address Selection

Wed, 02 Nov 2016 00:00:00 +0000

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 RFC6724 (which obsoletes RFC 3484).

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 this whitepaper. 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 this training that I’ll give in some weeks might be worth attending for some of you, too.

Diving into EMET

Mon, 26 Sep 2016 00:00:00 +0000

Last week, we decided to take a look onto the EMET library provided by Microsoft. This library is intended to introduce several security features to applications which are not explicitly compiled to use them.

It also adds an additional layer to protect against typical exploiting techniques by filtering library calls, preventing usage of dangerous functions/components and inserting mitigation technologies.

As EMET is already a target for many researchers, we currently only started to get an overview of it’s structure and how the different components are interacting with each other. Today we would like to share some of our results with you.

Files Your Webserver Shouldn’t Deliver

Sun, 18 Sep 2016 00:00:00 +0000

During penetration tests, we often find interesting files on web servers. Almost as often, those files enable us to carry out further attacks with much higher impact. Inspired by Chris Gate’s great series From Low to Pwned, we decided to share the following small piece.

The web server under test did not deliver directory listings. However, the directory contained a .DS_Store file (one of macOS’ many — lets say special — traits). While .DS_Store files store various information, a simple cat shows one relevant characteristic:

Considerations on DMZ Design in 2016, Part 2: A Quick Digression on Reverse Proxies

Thu, 08 Sep 2016 00:00:00 +0000

This is the second part of a series with considerations on DMZ networks in 2016 (part 1 can be found here). Beforehand I had planned to cover classification & segmentation approaches in this one, but after my little rant on how “the business” might approach & 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.

Considerations on DMZ Design in 2016, Part 1

Sat, 27 Aug 2016 00:00:00 +0000

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.

Some of you already know that, at ERNW, 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.
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).

ERNW Hardening Repository

Sun, 21 Aug 2016 00:00:00 +0000

Today we started publishing several of our hardening documents to a dedicated GitHub repository — and we’re quite excited about it! It took a while to develop a suitable markdown template to support all the requirements you have when you write a hardening guide, but we’re online now!

At the moment, only a few hardening guides are online, but that should continuously increase in the future.

Click here for the GitHub ERNW Hardening Repository!

Some Notes on Utilizing Telco Networks for Penetration Tests

Wed, 25 May 2016 00:00:00 +0000

After a couple of years in pentesting Telco Networks, I’d like to give you some insight into our pentesting methodology and setup we are using for testing “Mobile and Telecommunication Devices”. I am not talking about pentesting professional providers’ equipment (as in previous blogposts), it is about pentesting of devices that have a modem in place like a lot of IoT devices (you know about the fridge having a GSM Modem, right?) do.

Introduction of a new hardware guy

Wed, 18 May 2016 00:00:00 +0000

Hi folks!

We couldn’t be more proud to welcome such a predestined #1 hardware hacking victim, than VICTor is!
Before Brian and I gave a lecture on hardware hacking last week at DHBW Mosbach, we felt, that we needed a custom victim which is fully documented and provides a good “hackability” to the students.
Surely we could also have used some cheap $wifi_ap, but here’s the thing: Would you really want to use a device which you don’t really know? Mostly, there’s a massive lack of documentation regarding the SoCs used…not to mention the unavailability of schematics and layouts.
As we wanted to teach students the basics of hardware hacking effectively, we decided to create something by ourselves.

Review about the System and Security Info iOS App from SektionEins GmbH

Wed, 18 May 2016 00:00:00 +0000

Dear readers of Insinuator,

Today I want to give a little review about the latest app released by SektionEins called “System and Security Info” due to its recent media appearance. So first of all the app can be obtained via the Apple App store for 0,99€ at the time this article was written. This article will try to answer two basic questions: for whom (or “which groups of people”) is this app helpful, and which security features does this app actually has. The design of the app is straight forward and pretty minimalistic with a clean and modern design. The first page of the Application called “Overview” provides nothing more than the current CPU usage of the device, with detailed subdivision in User, Idle, Total and Load. The next section provides an overview about the used RAM divided into Wire, Active RAM usage, Inactive RAM usage, “other”, free and the total amount of the device’s ram. The next option shows the used and unused part of the devices available storage, with “used”, “free” and total amount of space. While these features can be handled with several other (free and open source) applications I won’t write a comment wether it these components make sense.

draft-vyncke-pim-mld-security

Mon, 04 Apr 2016 00:00:00 +0000

Right now, I’m in Buenos Aires for IETF95 where, amongst others, an Internet-Draft authored by Eric Vyncke, Antonios Atlasis 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.

As some of you may remember about two years ago we started an internal research project on the IPv6 “helper procotol” Multicast Listener Discovery (MLD) and its security properties. One outcome of this research project was Jayson Salazar‘s excellent thesis on the topic (the full document can be found here), another outcome were the related talks we gave at DeepSec 2014 and at Troopers15.

Building a secure and reliable IPv6 Guest Wi-Fi Network by Christopher Werny

Fri, 01 Apr 2016 00:00:00 +0000

Christopher Werny leads the network security team for ERNW and since 2005 he is involved in numerous IPv6 projects where he is responsible for planning, implementation and troubleshooting existing projects.

The first topic he approached was “How to build a conference WLAN Network in General”. The very first suggestion was to put it to the 5GHz channel because there could be a lot of interferences in the 2.4 GHz channel. The basic idea here is to disable 802.11b completely if it´s possible in your environment and no-one is using it anyway. Further you should also consider nearby Wi-Fi signals and on which channels they reside. His next recommendation was about setting the inactivity timer to short intervals, this will avoid unnecessary resource spending from the APs when they try to track down moved or shut down devices. His last general recommendation from him was regarding a central DHCP Server. This will enable the roaming from mobile devices without getting a new IP-Address when bridged mode is enabled for the APs.

Troopers 16 USB Condom

Tue, 29 Mar 2016 00:00:00 +0000

At times with many many digitally transmittable diseases, protection might be more important than ever. When connecting your smartphone to a rogue charger, or a foreign smartphone to your own laptop, you never now what will happen. You never know what data crosses the lines. But there is help: A USB condom!

As the Troopers 16 Badge was a neat integrated device, we had the challenge to identify something to be soldered for our attendees. The past has shown, that soldering rocks and all of our attendees, all of you, really enjoy it! After some looking around and roaming the Internet, we decided to go for a simple device, which would protect you and your devices in a hostile world. A slim PCB, which will protect your phone when having to connect it to some unknown charger or for situations when “a mate” just wants to connect his/her phone to your laptop for “charging purposes”.

Check your SAP landscape for default Solution Manager users

Thu, 10 Mar 2016 00:00:00 +0000

This is a guest post from Joris van de Vis @jvis, on his upcoming Troopers talk. Additional credits go to: Robin Vleeschhouwer, and Fred van de Langenberg.

As presented at Troopers this year, ERP-SEC research has uncovered a set of potential default accounts related to the use of SAP Solution Manager. These default accounts might pose a big risk to your SAP supported business as some of them have wide authorisations. It is therefore important to check if they exist in your landscape and change the default passwords.

Cloud Security & Trust

Thu, 10 Mar 2016 00:00:00 +0000

Hi,

I gave a presentation on Cloud Security, Compliance & Trust the other day. The basic message was to look beyond the Cloud buzzword and see the actual technologies which are used, understand which security principles still apply and which need to be re-thought, giving a rough direction about regulatory compliance in Cloud environments (which of course is non-binding, as I’m not a lawyer), and the importance of trust evaluations (especially) when it comes to Cloud services.

Docker, DevOps & Security

Thu, 10 Mar 2016 00:00:00 +0000

Hi,

this week I gave a presentation together with Florian Barth from Stocard on Docker, DevOps/Microservices, and Security — a topic and collaboration that I will definitely cover in even more detail in the future!

The slides can be found here.

so long,

Matthias

Dual Stack vs. IPv6-only in Enterprise Networks

Wed, 17 Feb 2016 00:00:00 +0000

I had the pleasure to sit in Mark Townsley “Addressing Networking Challenges With Latest Innovations in IPv6” session at Cisco Live yesterday and – somewhat inevitably – there was a mention of Facebook having implemented an IPv6-only approach in their data centers (here’s a talk from Paul Saab/FB laying out details). So, with the “IPv6 Panel” looming, I started reflecting on “Why don’t we see this in our customer space?”. This post quickly summarizes some observations and thoughts.

IPv6 Address Planning in 2016 / Observations

Sun, 14 Feb 2016 00:00:00 +0000

Hi,

I’ll be on the “IPv6 Panel” at Cisco Live next week and somewhat in preparation I started thinking about what we currently see when it comes to IPv6 deployment in our customer space. We notably observe a large gap between “textbook planning & transition strategies” and what’s happening in real-life in those organizations. I hence decided to write down some of these observations in a quick series of posts to be published in the upcoming days and, maybe more importantly, to reflect on the reasoning of this apparent mismatch between theory and practice. I dare to add a dose of devil’s advocate here+there…
For today let’s start with some comments on IPv6 address planning.

Developing an Enterprise IPv6 Security Strategy / Part 6: Controls on the Host Level

Tue, 02 Feb 2016 00:00:00 +0000

In this part of the series (for the other parts see [1], [2], [3], [4], [5]) we’ll discuss approaches to implement security measures suited to protect from IPv6-related threats on the host level.

These can be grouped into the following generic categories each of which will be described in more detail in the following:

“Minimal machine” approach
Static configuration of IPv6 parameters
Tweaking the behavior of IPv6-related mechanisms/protocols
Local packet filtering

Some of you might recall that we published IPv6 hardening guides for both Linux and Windows a while ago and we’ll reference those exact documents below, by [Hard_Linux] and [Hard_Windows] respectively.

TROOPERS16 Training Teaser: Dos and Don’ts of Secure Active Directory Administration

Wed, 27 Jan 2016 00:00:00 +0000

In the last few years, attack techniques which fall in the categories of “Credential Theft” or “Credential Reuse” have grown into one of the biggest threats to Microsoft Windows environments. Microsoft has stated more than one time, that nearly almost all of their customers that run Active Directory have experienced “Pass-the-Hash” (PtH) attacks recently.[1] Once an attacker gains an initial foothold on a single system in the environment it takes often less than 48 hours until the entire Active Directory infrastructure is compromised. To defend against this kind of attacks, a well-planned approach is required as part of a comprehensive security architecture and operations program. As breach has to be assumed[2], this includes a preventative mitigating control strategy, where technical and organizational controls are implemented, as well as preparations against insider attacks. This is mainly achieved by partitioning the credential flow in order to firstly limit their exposure and secondly limit their usefulness if an attacker was able to get them. Although we spoke last year at Troopers 15 about “How to Efficiently Protect Active Directory from Credential Theft & Large Scale Compromise”[3], we would like to summarize exemplary later in this post Active Directory pentest findings that we classified in four categories in order to better understand what goes typically wrong and thus has to be addressed. For a better understanding of the overall security goals, we classified the findings as to belonging as a security best practice violation of the following categories:

Things to Consider When Starting Your IPv6 Deployment

Mon, 11 Jan 2016 00:00:00 +0000

Hi,

today I’m going to suspend the “Developing an Enterprise IPv6 Security Strategy” series for a moment and discuss some other aspects of IPv6 deployment.
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 planning phase in which several documents were created (often these include a road map, an address concept/plan and a security concept).
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.
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…).
In this post I will hence lay out some things to consider when you enable IPv6 on perimeter elements for the first time.

Developing an Enterprise IPv6 Security Strategy / Part 5: First Hop Security Features

Thu, 31 Dec 2015 00:00:00 +0000

In the previous parts of this series (part 1, part 2, part 3, part 4) 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 First Hop Security features.

IPv6 First Hop Security (“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 RA Guard (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. IPv6 Source Guard). Nowadays usually “phase one” features are supported on many platforms, at least on physical ones (support on virtual switches is still somewhat lacking).
There’s an excellent Cisco FHS Wiki maintained by Andrew Yourtchenko, Scott Hogg wrote a good overview, as did Ivan Pepelnjak, and this is a nice presentation 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:

Developing an Enterprise IPv6 Security Strategy / Part 4: Traffic Filtering in IPv6 Networks (II)

Tue, 22 Dec 2015 00:00:00 +0000

In this part of our little series (part 1, part 2, part 3) we continue discussing IPv6 specific filtering of network traffic, namely at intersection points.

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.

Developing an Enterprise IPv6 Security Strategy / Part 3: Traffic Filtering in IPv6 Networks (I)

Mon, 14 Dec 2015 00:00:00 +0000

So this is the third part of our little series on securing IPv6 in enterprise environments. In the first part 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 second part 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.

Developing an Enterprise IPv6 Security Strategy / Part 2: Network Isolation on the Routing Layer

Mon, 07 Dec 2015 00:00:00 +0000

In the first part 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).

Developing an Enterprise IPv6 Security Strategy / Part 1: Baseline Analysis of IPv4 Network Security

Wed, 02 Dec 2015 00:00:00 +0000

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 & displayed. Furthermore some time ago – in the Is IPv6 more Secure than IPv4? Or Less? post – I announced to come up with (something like) an “IPv6 threats & 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 IPv6 Security Summit).

Some Notes on the “Drop IPv6 Fragments” vs. “This Will Break DNS[SEC]” Debate

Tue, 03 Nov 2015 00:00:00 +0000

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 here, here or here). Actually I still think it was a very good idea of, amongst others, Randy Bush and Ron Bonica to suggest the deprecation of IPv6 fragmentation in the IETF.
On the other hand there are voices arguing that fragmented IPv6 packets will be needed in some cases, namely DNS[SEC]-related ones.
In this post I will discuss some details of this debate (taking place in many circles, incl. this thread on the ipv6-hackers mailing list which, btw, you should subscribe to).

Social Coding – Simple Things to Keep in Mind (updated)

Mon, 26 Oct 2015 00:00:00 +0000

The current trend of social coding finally arrived at ERNW! From now on, you will find our public released tools and scripts commonly on https://github.com/ernw. Therefore I would like to share some thoughts/guidelines which you have to keep in mind if you want to be a social coder:

Github and other repository hosts are great if you want to share opensource tools with the community, as they will find a common platform with defined workflows to extend/fix the work to get better software for everyone. What some should note is that (especially in terms of decentralized version control systems (DVCSs) like git, bazaar or mercurial) public really means public. Back in earlier days, if you shared your code with others you probably created a source code package of a defined version of your code. They will get the files you published, nothing more (and nothing less). Beginning with websites like sourceforge, a broader range of public VCSs came up (mostly driven by CVS or SVN). At this time, others were able to view your commit history (if you granted access to them) and all your mistakes you’ve done before your published code state (for example accidentally committed sensitive data). Those mistakes can still happen today. The difference with the DVCS used nowadays is that most of the time you have lesser control of your commit history (in the same way if someone had copied your history commit by commit in SVN, but then you may had noticed it because of the high network traffic). With DVCS, everyone gets a full copy (clone) of your repository even on a simple “checkout” (as called in SVN). This means he/she is able to search your history locally and has all the time he/she needs to do it. Even if you delete your repository (or modify the history), the original state is shared over all who have cloned it beforehand (thats one reason why DMCA takedowns are not that powerful/useful against git repositories). Most of the public hosting platforms even included a search over all repositories (which is really useful if you want to find some tool or try to find the reason why a local tool doesn’t work).

OCSP over HTTP testing with Python

Mon, 19 Oct 2015 00:00:00 +0000

Dear Readers,

today we want to share a method on how to test an OCSP over HTTP validation service with Burp and some Python magic. First a little background about OCSP (Online Certificate Status Protocol): the main purpose of OCSP is to validate the status of an X.509 certificate.

The OCSP responder is the key part of the system. It is run by the certificate authority and responds with one of three possible different answers. The first one is “good”, which indicates that the certificate is not banned, “revoked” means that the certificate is banned, and “unknown” simply says that the status could not be determined, because the issuing CA of the Cert is not known to the responder.

The Strange Case of $SOME_SOFTWARE Adding an IPv6 Extension Header, and an Internet Router Dropping Them

Mon, 05 Oct 2015 00:00:00 +0000

Last week Christopher and I were the instructors of an IPv6 workshop. 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 there are many).

Python For Hackers

Tue, 29 Sep 2015 00:00:00 +0000

Python has reached a defacto standard in exploit development lifecycles and most of the proof of concept tools you’ll find out there are written in Python (besides the metasploit framework, which is written in Ruby). Python allows to write scripts handling with remote services, fiddling with binary data and interacting with C libraries (or Java in case of Jython/.Net in IronPython) in a fast and easy way. The huge standard library with it’s “battery included” principle removes some of the dependency hell known from other frameworks/languages. I want to share some of my python coding experiences with you, and maybe this could give some helpful tips for your future work, to make the world a bit safer 🙂 (PS: most of the examples are written in Python 3.x or compatible to both Python branches).

Internet Information Service 7.5 Hardening Guide

Fri, 26 Jun 2015 00:00:00 +0000

Internet Information Services (IIS) contains several components that perform important functions for the application and Web server roles in Windows Server. As it is designed to be used in an enterprise environment, the security of this system must be kept at a high level.

By default IIS implements a lot of basic security measures, but are these the relevant ones to protect your business?

In order to answer this question for one of our customers, we have compiled the most relevant security settings in an IIS 7.5 Hardening Guide for you. In this guide we define a baseline security level, which is to be used for so called “crash and burn systems” (systems with non-critical data, systems whose availability have no business relevant impact) and a security level high, which includes all other systems. The mitigations in the baseline section are non-critical and therefore no further test are necessary. The mitigation in the section high, are critical in terms of availability and need to be tested extensively. The system owner must decide, which security level is the right one for their system, and which mitigation from section high are mandatory for their system.

IPv6 Adress Planning / Some Notes

Tue, 16 Jun 2015 00:00:00 +0000

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 series on “Address Plan Considerations”. An excerpt of that (newer) document can be found here. Due to the context it originates from it’s in German, still I hope it’s useful for some readers.
If you’re interested in the topic it might be a good idea to listen to Tom Coffeen‘s talk at the upcoming IPv6 Business Conference, too.

An unpacker for Alcatel TiMOS images

Fri, 12 Jun 2015 00:00:00 +0000

Hi,

I wrote a small python script that extracts the content from Alcatel .tim firmware files. It took some time staring at hex values, as well as a fair amount of guess work to figure out the file format.

All .tim files start with a common header, containing the TiMOS version string, the build string, the used compression algorithm and the number of segments included in the file. The common header is followed by a header for each segment in the file. The segment header contains values like the name of the segment, the beginning of the segment in the image file, the size of the segment, compressed as well as extracted, a checksum of the decompressed data and also the base address and entry point of the data in the routers memory. A segment header can look like this:

Is IPv6 more Secure than IPv4? Or Less?

Mon, 08 Jun 2015 00:00:00 +0000

Scott Hogg recently (in his post “Holding IPv6 Neighbor Discovery to a Higher Standard of Security“) gave the following answer:

“The security of IPv4 is roughly equivalent to IPv6. So why do we expect more from IPv6?”

While I highly value Scott’s IPv6 expertise – not least because I learned a lot about IPv6 security from the book on the topic he wrote together with Eric Vyncke – 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 less secure than IPv4.

IPv6 & Complexity

Wed, 27 May 2015 00:00:00 +0000

IPv6 is often called a “complex protocol”, not least by myself (for example in my keynote to the IPv6 Security Summit 2014). In this post I want to have a quick look at three questions:

– Can IPv6 be considered a “complex protocol”?
– Is it “more complex” than IPv4?
– Can we expect IPv6 networks to be “complex networks”?

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

How to Get a BaseStation

Sun, 17 May 2015 00:00:00 +0000

In our talks in the past we showed what might be possible if an attacker gets access to backhaul and/or core network of a telecommunication provider. In a security analysts perspective this is really disgusting, but provider always will argument that those attack scenarios are not realistic.

Because of legal restrictions we are not able to demonstrate this in practice (e.g. by breaking in into a BTS environment somewhere in the woods) but what we can do is this: building a lab.
Sometimes it is really shocking what you can buy on Ebay, right? Here we got one very interesting component: a Huawei BBU3900 BaseStation which is used by a couple of providers. Okay, it is for GSM-Rail, but the technology behind is very equal. And for 100 dollars (plus shipping) you don’t ask further questions…

OS IPv6 Behavior in Conflicting Environments

Thu, 30 Apr 2015 00:00:00 +0000

I was invited by the Swiss IPv6 Council to give a talk on this topic yesterday. We had good conversations after the talk – thanks for the invitation!

For those interested the slides can be found here. I will happily discuss the intricacies of DHCPv6 and how to deploy it in complex environments at the upcoming IPv6 Business Conference in Zurich and in my “IPv6 in Enterprise Networks” training in Berlin.

Have a great day everybody

MLD, a tale on Complexity in IPv6

Sat, 04 Apr 2015 00:00:00 +0000

The purpose of this blog post is to elucidate how and why MLD, an IPv6 protocol we’ve been lately talking quite a bit about, is an unnecessarily complex beast . This article should also serve to summarize a couple of points we’ve mentioned during our talks about MLD but which because of time constraints never make it into the main discussion. We’ve talked about other aspects of MLD in previous posts. So, have a look at those if this is a topic which you find interesting. Without further ado, let’s start for today.

IPv6 Router Advertisement Flags, RDNSS and DHCPv6 Conflicting Configurations

Mon, 09 Mar 2015 00:00:00 +0000

We’ve just released a whitepaper discussing the behavior of different operating systems once they receive IPv6 configuration parameters from different sources. For that purpose a number of lab tests were conducted.

In short, it’s a mess. Again, RFC ambiguity and/or (perceived) vendor implementation freedom suck big time. For us practitioners out (t)here this means (once more) we need extensive test labs and good troubleshooting guides for large scale IPv6 deployments.

The detailed results can be found in this paper. We hope to contribute to a better understanding of IPv6 specifics. I mean, after all it’s here already.

Practical IPv6 Troubleshooting while Setting up the Troopers Network

Mon, 09 Mar 2015 00:00:00 +0000

Hello Everyone,

Troopers is right around the corner and as I am responsible for the whole conference network I wanted to make sure that everything is working as expected. I went to the venue on Friday because of two things I wanted/needed to setup. Compared to last year’s setup we had a couple of changes in regards to the provider connection (resulting in some changes for our network setup). First, we now have a rather big pipe for the uplink and more importantly (well that depends on the point of view ;)) there is a native IPv6 connection. Before that I had to tunnel all IPv6 traffic from the venue to one of our gateways and to forward it out (as native IPv6) from there. As this step isn’t necessary anymore, and the staff on the venue isn’t that experienced with IPv6, I had in mind to setup and verify that IPv6 is working as desired. The router used over there is a Mikrotek Routerboard. As I haven’t worked with these devices before, I was curious whether everything works as it should ;).

An MLD Testing Methodology

Fri, 06 Mar 2015 00:00:00 +0000

Based on recent research in the ERNW IPv6 lab and with our MLD talk looming we’ve put together a (as we think) comprehensive document discussing how to thoroughly test MLD implementations in various components (network devices or servers/clients). We hope it can contribute to a better understanding of the protocol and that it can serve as either a checklist for your own environment or as a source of inspiration for researchers looking at MLD themselves.

What to Do Today if You Want to Deploy IPv6 Tomorrow

Tue, 03 Mar 2015 00:00:00 +0000

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

As always we’re happy to receive comments or feedback.
Cheers

Enno

How to go ahead with future end of life Windows (2003) Servers

Thu, 12 Feb 2015 00:00:00 +0000

Server operating systems with an OS, for which vendor support has ended, come with many risks that have to be considered and addressed. The primary goal should be always to decommission or migrate the majority of end-of-life (EoL) servers to OS versions, supported by the vendor. Here it should be noted that a migration to an up-to-date OS should be preferably done before your organization enters the end of life of that software 😉

IPv6-related Requirements for Security Devices

Sun, 08 Feb 2015 00:00:00 +0000

This is the sequel to the similar post on “IPv6-related Requirements for the Internet Uplink or MPLS Networks“. 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.

IPv6 Hardening Guide for OS X

Wed, 04 Feb 2015 00:00:00 +0000

Similar to the documents we released for Linux and Windows (and actually inspired by a comment to the post on the Linux guide) Antonios wrote another guide, this time for Mac OS X.

It can be found here. We hope some of you might find it helpful.
Have a great day

Enno

PS: in the past we also made a general Mac OS X hardening document available and we’ve discussed an additional patch in this post.

Is RFC 6939 Support Finally Here – Checking the Implementation of the “Client Link Layer Address Option” in DHCPv6

Wed, 04 Feb 2015 00:00:00 +0000

One of the main DHCPv6 enhancements – fyi: we have already discussed DHCPv6 in some other posts – many practitioners have been waiting for quite some time now, is full support of RFC 6939 (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.

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”).
correlation of IPv4 and IPv6 addresses of a given host identified by its MAC address.
(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 this presentation of the IPv6 deployment at CERN, btw: slide #9 might be helpful when discussing IPv6 transition plans with your CIO. or not).

So far it seemed very few components support RFC 6939. When Tim Martin mentioned at Cisco Live that Cisco devices running IOS XE support it by default, we decided go to the lab ;-).

Using Android without Google, Part 1

Tue, 03 Feb 2015 00:00:00 +0000

We’re using our smart phones every day to manage contacts, calendar entries, e-mail, and social communication (please note that we at ERNW still have a strict “no company data on smartphones/tablets” – which includes email). Everything is easy to use and automated syncing provides access to our data from anywhere. Data is stored in most cases on premises of a cloud service provided by the OS vendor of your smart phone – mostly Google, Apple or Microsoft. You don’t need to pay for this service – and the cloud provider could use your data for personalization and service improvements.

IPv6-related Requirements for the Internet Uplink or MPLS Networks

Sat, 31 Jan 2015 00:00:00 +0000

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.

As a source of inspiration we mainly used the excellent “What To Ask From Your Service Provider About IPv6” document from Cisco, and enhanced that with stuff we observed in other environments (go wrong), namely with regard to MTU/PMTUD and in the space of prefix filtering. Here’s the first draft list we came up with:

Evaluation of IPv6 Capabilities of Commercial IPAM Solutions

Wed, 28 Jan 2015 00:00:00 +0000

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.

We just released a newsletter describing the requirements and the results of the evaluation.
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.
Feel free to get back to us on any of the points laid out or, even better, join us at the Troopers IPv6 Security Summit in Heidelberg on Mar 16th/17th in order to discuss any related points.

The Persistent Problem of State in IPv6 (Security)

Wed, 28 Jan 2015 00:00:00 +0000

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 (here and here. btw, the widely discussed IPv6-related network outage 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 unfortunate relationship of MLD and ND).

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 have hard times to work properly in IPv6 networks.
Secondly there’s another severe caveat. As I fully realized yesterday, at Cisco Live Europe, in Andrew Yourtchenko‘s excellent breakout session on “Advanced IPv6 Security in the Core”, this carries some consequences for stateless (and hence: seemingly “unaffected”) security controls, too.

Evaluating Behavior-based Malware Detection

Fri, 23 Jan 2015 00:00:00 +0000

Quite some organizations complemented their traditional AV solutions with a technology that can best be described as behavior-based malware detection. While we all know we are talking about products like Fireeye Email/Network Security, zScaler Web Security/APT Protection, or Cisco WSA, there are a lot of terms around to describe this type of products (such as next generation malware analysis/detection, Secure Web Gateways, or behavior-based malware detection). Those offerings typically promise the detection of malware by analyzing the behavior of ‘samples’ (which are files captured in transit of different types, such as executables or PDF documents). However, beyond the taxonomy challenges, both assessment and consulting work gets us frequently in contact with those solutions. While the main task during assessments is to bypass those solutions, the main question in the consulting context typically is “to what degree are the solutions suited to protect from common targeted attacks in the enterprise context”. Luckily, the experience from assessment work allows us to tackle this question in a structured way (which is our approach for consulting anyways: Benefit from our assessment experiences in order to provide reasonable consulting advice…).

How To Configure Snort to Stop IPv6 Evasion Attacks

Sun, 11 Jan 2015 00:00:00 +0000

This is a guest post from Antonios Atlasis.

Hi all,

during our BlackHat US 2014 talk titled “Evasion of High-End IPS Devices in the Age of IPv6”, 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:

DHCPv6 Guard: Do It Like RA Guard Evasion

Thu, 08 Jan 2015 00:00:00 +0000

Or: When Cisco ACL Can Count Up to Five 🙂

This is a guest post by Antonios Atlasis.

Hi all,

RA Guard Evasion is well-known in the IPv6 “circles”; there is RFC 7113 Advice for IPv6 Router Advertisement Guard (RA-Guard) and many interesting blog-posts like this one here, here, and this excellent write-up here that discuss this issue.
Moreover, as Jim Smalls states in his comprehensive “IPv6 Attacks and Countermeasures” presentation given at the North American IPv6 Summit 2013, 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.

Should IPv6 Packets With Source Address ::1 Be Processed When Received on an External Interface?

Mon, 05 Jan 2015 00:00:00 +0000

This is a guest post from Antonis Atlasis.

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 the initial ntp.org security notice). Some days ago the Project Zero team at Google published a blog post “Finding and exploiting ntpd vulnerabilities” 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).

Some Design Aspects of Hacking Challenges

Sun, 04 Jan 2015 00:00:00 +0000

We’re currently starting the preparation for the Troopers15 PacketWars Challenge, and since I’ve participated in quite some CTF games and have been involved in the preparation of a number of PacketWars Battles, I thought I’d write down some thoughts on the design of hacking challenges.

First of all, my experience is limited almost exclusively to attack-defend-CTFs or interactive war games (such as PacketWars or CCDC). While thinking about this blogpost, I also came across several terms which are used, so I decided to give a short summary:

Hardening Against Local PrivEsc: Protecting Your Links

Tue, 30 Dec 2014 00:00:00 +0000

Following up on this post, we want to provide some details on two rather new (well, compared to its lifespan) Linux kernel parameters — and emphasize the need to enable those:

fs.protected_hardlinks
fs.protected_symlinks

For BSD, similar parameters for hardlinks exist: security.bsd.hardlink_check_uid/security.bsd.hardlink_check_gid.

Those parameters control whether users are allowed to create links pointing to files which are not owned by them. If fs.protected_hardlinks/symlinks is set to 1, users can only create links to files which they own. Attackers have used this possibility for a long time, and here are some sample attack scenarios:

IPv6 Hardening Guide for Windows Servers

Mon, 22 Dec 2014 00:00:00 +0000

After we recently released the “Linux IPv6 Hardening Guide” 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 ipv6hackers mailing list).

Hence Antonios thankfully decided to put together a list of configuration steps for Windows servers. It can be found here.

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

IPv6 Hardening Guide for Linux Servers

Wed, 17 Dec 2014 00:00:00 +0000

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.

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.
The document can be found here.

Security Implications of Using IPv6 GUAs Only

Mon, 01 Dec 2014 00:00:00 +0000

When planning for IPv6 addressing, many organizations – rightfully & wisely – decide to go with global unicast addresses (GUAs) only (hence not to use unique local addresses/ULAs as of RFC 4193 at all), in order to avoid address selection hell or just for simplicity & consistency reasons. This post discusses security implications and complementary security controls of such an approach.

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 kludge 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.”) RFC 1918 space is usually not reachable from the Internet. So using such address space for internal networks is a nice example of the isolation principle as of the “Seven Sisters” approach we like to use. Now, bringing NAT into these networks enables connections (usually between trusted and untrusted networks) which simply would not be possible without it [NAT], so this actually breaks the isolation property. Question: how can one ever call something that increases the number of possible interactions between assets and potential attack originators a ‘security control’?!

IPv6 in RFIs/Tendering Processes

Fri, 28 Nov 2014 00:00:00 +0000

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:

When displaying, storing or exporting IP addresses, can your solution correctly handle IPv6 addresses of all types (link-local, ULAs, GUAs)?
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?
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?
Can your solution handle both A and AAAA records from DNS?
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?
Does your product/offering comply with any of the profiles in the ripe-554 requirements specification?
[http://www.ripe.net/ripe/docs/ripe-554]
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?
Do all implementations of management interfaces & protocols (SNMP, syslog etc.) used within your solution fully support IPv6?
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?
Has your solution been thoroughly tested in an IPv6 only or in a dual-stack setting? Please provide proper test documentation.
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?

MLD Considered Harmful?

Thu, 27 Nov 2014 00:00:00 +0000

This is a guest post from Antonios Atlasis.

On Thursday the 20^(th) Enno, Jayson and I had the pleasure to present our latest research results regarding MLD at Deepsec 2014, both from vendors’ implementation perspective as well as regarding protocol design flaws (some preliminary results as well as our testing methodology were discussed here and here).

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 (RFC 2710). The newer version of MLD, MLDv2 adds the ability for source address selection (RFC 3810).

MLD to Be Reconsidered?

Fri, 14 Nov 2014 00:00:00 +0000

This is guest post from Antonios Atlasis.

Following my September post about the connection between MLD and Neighbor Discovery, as well as Enno’s introduction about our upcoming talk at DeepSec, I would like to try to enlighten you about this with some technical details. First, we have some facts:

MLD is pre-enabled in most modern Operating Systems.
MLD traffic is sent out-of the-box during the stack initialization, as well as periodically.
They also interact with/respond to MLD Queries without any further configuration.

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:

Protocol Properties & Attack Vectors

Thu, 13 Nov 2014 00:00:00 +0000

Next week, at DeepSec, we’re going to give a talk about Multicast Listener Discovery (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”.

Now, you might ask: how does one tackle the task of examining the security “of a protocol”?

Dynamics of IPv6 Prefixes within the LIR Scope in the RIPE NCC Region

Thu, 06 Nov 2014 00:00:00 +0000

To contribute to the current debate on IPv6 route deaggregation & “strict-filtering” performed by certain ISPs we just released a white paper on “Dynamics of IPv6 Prefixes within the LIR Scope in the RIPE NCC Region“. I will give a talk on the overall topic later today at the Routing Working Group. We sincerely hope that the IPv6 community becomes aware of the inherent issues, and that practical solutions can be found which consider & meet the needs of the different parties involved.

IPv6 for IPv4 Experts

Tue, 04 Nov 2014 00:00:00 +0000

If any of you is interested in the intricacies of IPv6 Neighbor Discovery (ND) I briefly referred to in the course of my series on DHCPv6, 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 be found here.

Best

Enno

I Don’t Have Any Neighbors – A Deep Dive into DHCPv6, Part 1

Fri, 31 Oct 2014 00:00:00 +0000

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 Scott Hogg‘s article on “High Availability DHCPv6“). 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.

Router Advertisement Options to the Rescue – A Deep Dive into DHCPv6, Part 2

Fri, 31 Oct 2014 00:00:00 +0000

This is the sequel post to the first part in which I mainly covered some elements of the specification wrt the “on-link” flag and the IPv6 subnet model.
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.

Deaggregation by large organizations

Wed, 15 Oct 2014 00:00:00 +0000

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

MLD and Neighbor Discovery. Are They Related?

Wed, 03 Sep 2014 00:00:00 +0000

This is a guest post from Antonios Atlasis.

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

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

Atomic Fragments vs. Fragmentation in the IPv6 “Real World”

Thu, 21 Aug 2014 00:00:00 +0000

This is a guest post by Antonios Atlasis.

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

Packet Too Big Messages and Atomic Fragments

Wed, 20 Aug 2014 00:00:00 +0000

This is a guest post from Antonios Atlasis.

Taking the chance from a discussion on the IPv6 hacker’s mailing list and the freshly proposed draft RFC regarding the deprecation of the generation of IPv6 Atomic Fragments, I decided to test very quickly what is the current status related with the latest and some of the most poplar Operating Systems (OS) status (whether they send Atomic Fragments in response to Packet Too Big messages, or not). The motivation behind this was to check which one of them is potentially vulnerable to the DoS attack using the technique described in the above proposed RFC and taking it for granted that Atomic Fragments are blocked in the real world (but more about this, in another blogpost in the near future).

Some Things to Consider when Using EMET

Fri, 08 Aug 2014 00:00:00 +0000

In the light of the recent release of version 5.0 of Microsoft’s Enhanced Mitigation Experience Toolkit (EMET) on July 31, it seems to be more than appropriate to talk a bit about the new features and some general things to take into account when using EMET (for the new certificate pinning feature of EMET 4.0, see Friedwart’s comment). For all of you who don’t know EMET, in short, it’s a free mitigation tool for Windows developed by Microsoft, helping the user by preventing vulnerabilities in software from being successfully exploited. The tool works by protecting applications via a number of security mitigation technologies, vastly extending Windows operating system mitigation capabilities as Data Execution Prevention (DEP) and Address Space Layout Randomization (ASLR).

IPv6 for Managers

Tue, 22 Jul 2014 00:00:00 +0000

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?”.

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; it can be found here. 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 Troopers charity project… ).

IPv6 Requirements for Cloud Service Providers

Tue, 08 Jul 2014 00:00:00 +0000

Some weeks ago, at RIPE 68 in Warsaw, Sander Steffann gave a presentation about revising RIPE 554 which, in his own words, “is a template guideline for procurement of stuff that should do IPv6” (here’s the steganography transcript of the IPv6 working group session). Some of you will probably know RIPE 554 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…).

Skype GPO

Thu, 03 Jul 2014 00:00:00 +0000

Hi all,

regularly we get requests from customers where the idea of using Skype as a VoIP solution in their corporate environment is brought up. There are a lot of eavesdropping and more conceptual concerns (e.g. refer to this or this, and of course the legendary “Silver Needle in the Skype” paper from Black Hat EU 2006), but those won’t be covered in this post (just to say this: at ERNW the use of Skype is strictly prohibited at by policy).

m0n0wall as an IPv6 firewall

Fri, 30 May 2014 00:00:00 +0000

This is a guest post from Antonios Atlasis

Last October I had a quick look at pfSense 2.1 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 here). However, I knew that m0n0wall 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.

Microsoft Windows Update over IPv6 (or not?)

Wed, 21 May 2014 00:00:00 +0000

Hello everyone,

I recently stumbled over a document from Microsoft which lists all services/applications that support IPv6. Most of the content wasn’t new for me, but one item caught my attention. Windows Update. I haven’t heard before that Windows Update can be done over IPv6 (but this could just be me not looking hard enough ;)), so I was eager to test it out seeing if this is really the case. I was also curious why Microsoft referenced this document in the respective column.

IPv6 Address Plan Considerations, Part 3: The Plan ;-)

Wed, 14 May 2014 00:00:00 +0000

This is the third – and hence presumably last – part of the series of posts on IPv6 address planning (first part can be found here, second one here). 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.

A TROOPER’s Keyboard, part2

Wed, 09 Apr 2014 00:00:00 +0000

Greetings fellow TROOPERs,

TROOPERS14 has come to an end, and it’s finally time to let you have a go at the Badge’s source code. As promised, it was slightly modified and extended, to show you the full potential of your new gadget. I’ve added some nice payloads from Nikhil Mittal and a few own ones. Above that, for those who took their parts for soldering home, I’ve also added a few quick instructions on how to do the soldering.

A TROOPER’s Keyboard

Wed, 19 Mar 2014 00:00:00 +0000

Greetings from the Print Media Academy in Heidelberg. Just in time for TROOPERS14, I’ve got the great honor to present this years badge!

Being a TROOPER is tough: You need to know loads of information, learn even more and be able to work fast.

This year we decided to increase your efficiency and speed when collecting data from computer systems and, let’s say, hacking them! Your newest gadget is based on a plain Arduino Leonardo, modded with one of our famous shields. After adding a few LEDs and buttons, it will power up to full functionality.

Configuring IPv6 Snooping and DHCPv6 Guard on Cisco IOS

Thu, 30 Jan 2014 00:00:00 +0000

Hi everyone,

Some of you may already know (the ones who are following Enno on Twitter) that Enno and I had our lab day in preparation for the IPv6 Security Summit at Troopers. We had a brand new and shiny Cat4948E as our lab device to do some testing of the current generation of Cisco’s IPv6 First Hop Security (FHS) mechanisms. The Catalyst was running the latest image available (15.1(2)SG3).

In this small blog post, we will take a look at the configuration and behavior of IPv6 Snooping and DHCPv6 Guard. So let’s start with IPv6 Snooping:

IPv6 Address Plan Considerations, Part 2: The “PI Space from (Single|Multiple) RIR(s) Debate”

Thu, 23 Jan 2014 00:00:00 +0000

This is the second part of the – presumably – three-part series on IPv6 address planning which I started here.

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 & solved: “go with one /32 [PI space] from one RIR or apply for /32s from several RIRs”.

Tomcat 7 Hardening Guide

Sat, 11 Jan 2014 00:00:00 +0000

Hi,

continuing our tradition from last year (see here and here), we summarized more of our hardening recommendations for you. This guide is covering Tomcat 7 and is supposed to provide a solid base of hardening measures. It includes configuration examples and all necessary commands for each control, specifically for the most recent branch of Tomcat as there were some significant changes. Download: ERNW_Checklist_Tomcat7_Hardening.pdf

Have a good one,

Matthias

IPv6 Address Plan Considerations, Part 1: General Guidelines

Fri, 10 Jan 2014 00:00:00 +0000

In an upcoming series of blog posts I will discuss some principles & considerations on developing an IPv6 address plan. In (hopefully) rather quick succession there will be three posts:

the first on some general rules as for IPv6 address planning which we regard instrumental in the process.
the second covering the “PI space from a single RIR or PI space from each (relevant, as for $ORG) RIR?” debate.
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.

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.

ERNW Newsletter 42: Dangers of Disabled Pre-Boot Authentication in Corporate Environments

Mon, 16 Dec 2013 00:00:00 +0000

It’s been a long time… we just published an ERNW Newsletter. Here’s the abstract:

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.

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.

Design & Configuration of IPv6 Segments with High Security Requirements

Fri, 13 Dec 2013 00:00:00 +0000

Such was the title of a talk I gave yesterday at ACSAC 29. It was an updated and shortened version of a similar talk I had given at the Troopers IPv6 Security Summit (btw: this is the preliminary agenda of the 2014 event).

The slides of the ACSAC talk can be found here.

have a great weekend everybody

Enno

3D-Printers in the Cloud

Wed, 27 Nov 2013 00:00:00 +0000

Dear readers,

with the rise of low-cost 3D-printers in the homes of thousands [1] of enthusiastic tinkerers the word spreads about these magical machines which can produce any mechanical, artsy, useful or useless parts you might come up with. Standing in living rooms worldwide, they don’t seem like a big threat [2] to anybody. But what happens if you connect them to the Internet?

IPv6 Scanner

Sat, 09 Nov 2013 00:00:00 +0000

This is a guest post from Antonios Atlasis.

===

Having just finished the second “Advanced Attack Techniques against IPv6 Networks” workshop (some of the course material can be found here), organised and hosted by ERNW and their partner HM Training Solutions, 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 Marc Heuse and Fernando Gont, 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.

IPAM Requirements in IPv6 Networks

Thu, 24 Oct 2013 00:00:00 +0000

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:

Mandatory: Track all dynamic IPv6 assignments (SLAAC + PrivExtensions, DHCP etc.), by polling neighbor caches from network devices. Support SNMPv3 for this task.
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).

HackRF – A Must-Have Gadget

Mon, 26 Aug 2013 00:00:00 +0000

Dear readers,

today we welcomed Michael Ossmann at the ERNW headquarter for an exclusive workshop on his HackRF gadget. Everybody was quite excited to get hands-on with this shiny piece of hardware, which is currently crowd-funded on Kickstarter. For everybody who’s not familiar with Software Defined Radio (SDR): Let’s regard it as the ultimate tool when working with radio signals.

Michael Ossmann in the house.

Let’s quote Michael’s campaign website:

Transmit or receive any radio signal from 30 MHz to 6000 MHz on USB power with HackRF. HackRF is an open source hardware project to build a Software Defined Radio (SDR) peripheral.

SLES 11 Hardening Guide

Thu, 15 Aug 2013 00:00:00 +0000

SUSE Linux Enterprise Server (SLES) has been around since 2000. As it is designed to be used in an enterprise environment the security of these systems must be kept at a high level. SLES implements a lot of basic security measures that are common in most Linux systems, but are these enough to protect your business? We think that with a little effort you can raise the security of your SLES installation a lot.

Basic OS X Hardening & DMA

Wed, 31 Jul 2013 00:00:00 +0000

In the course of a recent endpoint assessment, we also had a OS X 10.8 client system as a target. While we still rely on the Firewire “capability” of unlocking systems on a regular base (using this great tool), we noticed that Apple released a patch to disable Firewire DMA access whenever the system is in a locked state (e.g. with an active screensaver or no user logged in). As we test the Firewire DMA access vulnerability quite often (at least we thought so 😉 ) to prepare for demonstrations in the board room or client assessments, we were quite surprised that we must have actually missed that nice update. In order to verify the effectiveness of the patch, we ran our typical test bed and can quite happily confirm that the update successfully mitigates Firewire DMA access in locked system states.

Some Notes on Types of Security Controls & the Way they’re Implemented in Enterprise Environments

Sun, 21 Jul 2013 00:00:00 +0000

Welcome back, Dear Reader,

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.

In general the space of security controls can be categorized according to different schemes, such as:

By fundamental principle (preventive, detective, reactive, corrective, deterrent, compensating etc. security controls. see for example this overview or this one or some illustration here).
By “state of matter” (e.g. components, implementation, operations. again, for some supplemental information look at this one).
By type of admission: whitelisting vs. blacklisting (some general discussion here, the respective Schneier-Ranum Face-Off to be found here, and this is only Bruce’s half, but with a number of comments).
Related to the overall architecture of implementation: centralized vs. distributed.

For today’s topic I’ll just focus on the latter two and will introduce those shortly.

EMET v4.0 with New Certificate Trust Feature Released

Mon, 01 Jul 2013 00:00:00 +0000

Microsoft released EMET v4.0 with a new (security) feature that enables protection against fraudulent websites or compromised root certification authorities (do you remember Comodo, DigiNotar, DigiCert, Turktrust et al. ;-)?)

EMET defines via “certificate trust“ a trust chain between the domain name of a website (and its associated website certificate) and a root CA certificate. This is done through so called “pinning rules”. Here is one of the default pinning rules of EMET 4.0 for the domain name login.live.com:

Microsoft Doc “Best Practices for Securing Active Directory”

Wed, 05 Jun 2013 00:00:00 +0000

Hi,

MS just released a new guide on securing Active Directory. At the first glance seems a fairly comprehensive document to me.

At this occasion I may furthermore draw your attention to our (German language) newsletter no. 40 covering hardening MS Windows Server 2008 + AD.

have a good one,

Enno

RA Guard (Evasion) – We Stand Corrected

Mon, 20 May 2013 00:00:00 +0000

Recently Jozef Pivarník and Matěj Grégr published an excellent write-up on RA Guard & evasion techniques. Amongst others they tested the “undetermined-transport” ACL we described here and here. As it turns out the “workaround” for implementing undetermined-transport on platforms seemingly not supporting it, causes some bad collateral damage: the respective port does not forward any 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 => test succeeded). So, frankly: the undetermined-transport trick does not make sense at all on the “unsupported platforms”…

IPv6 Attacks & Pentesting Workshops

Tue, 14 May 2013 00:00:00 +0000

Due to “popular demand” and given Marc couldn’t join us at the IPv6 Security Summit (as flights into FRA were canceled that day due to snow) we decided to invite him and Antonios Atlasis another time, to present their knowledge, skills & voodoo in two workshops held in Heidelberg, in late June. More details can be found here.

See you all potentially at the Heise IPv6 Kongress, take care

Enno

RA Guard Support

Thu, 02 May 2013 00:00:00 +0000

Hi,

on the [ipv6-ops] mailing list currently there’s some discussion about RA guard support on switches from different vendors.

Stefan, one of our students (btw: working on a topic similar to this session), 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 here. Furthermore on the list this link was mentioned which seems to provide some info as well (albeit potentially not very up-to-date).

Some more Notes on RA Guard Evasion and “undetermined-transport”

Sat, 13 Apr 2013 00:00:00 +0000

I just had an interesting discussion with Jim Small (who gives the “IPv6 Attacks and Countermeasures” talk at the North American IPv6 Summit 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 Cisco documentation stating it’s not supported). Let’s have a look, and start with a quick refresher.

IPv6 Extension Headers: New Features, and New Attack Vectors

Sun, 17 Feb 2013 00:00:00 +0000

This is a guest post from Antonios Atlasis

IPv6 introduces a lot of new features and consequently, a lot of new capabilities. Obviously, the most significant of them is the huge address space that it offers. However, this is not the only one. IPv6 also introduces the use of the IPv6 Extension Headers. The IPv6 header has been considerably simplified in comparison with IPv4 one. On the other hand, the IPv6 Extension Headers, not only do the “job” of most of the fields which were removed from the main header, but, additionally, they add many more. However, any new “technology” creates new attack opportunities and a “new” protocol, such as IPv6 could not be an exception, especially since its design and implementation is more complicated than it’s predecessor.

Fragmentation (overlapping) attacks in IPv6. Have we learned our lesson, yet?

Tue, 29 Jan 2013 00:00:00 +0000

This is a guest post from Antonios Atlasis

It has been a year since fragmentation attacks in IPv6 were last examined publicly (in Black Hat Europe 2012). Issues well known from the IPv4 era appeared again in IPv6. Surprisingly enough, some of the most popular Operating Systems (OS), included ones considered “secure”, were proven to be vulnerable to such attacks, although fragmentation overlapping is strictly forbidden in IPv6 since 2009 (RFC5722). Some other OS, although in a better shape, still appeared to have some issues in specific cases.

Insider Threats in the Cloud

Sat, 05 Jan 2013 00:00:00 +0000

at first a happy new year to all our readers!
And, of course, to everybody else, too ;-). May 2013 bring good things for you all, in particular (but not only) in the infosec space.

At the recent ATSAC 2012 conference a guy from the CERT Insider Threat Center gave a talk on the exact topic. Given that the ENISA Cloud Computing Risk Assessment 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.

Windows Server 2008 R2 BSI-compliance

Thu, 26 Jul 2012 00:00:00 +0000

Recommendations by the German Federal Office for Information Security (BSI – Bundesamt für Sicherheit in der Informationstechnik) are obligatory for German government agencies, civil services and authorities (like recommendations of the NIST are relevant to American government agencies and authorities). They are often used as references and security best practices in other countries as well. Hence it is hard to understand why the recommendations on how to harden Windows Server 2008 based systems were published only some weeks ago and only on a preliminary draft basis (which is, obviously, better than nothing ;-)).

IPv6 Privacy Extensions

Mon, 14 May 2012 00:00:00 +0000

Last week Christopher Werny and I gave a talk on IPv6 Privacy Extensions at the Heise IPv6 Kongress. As our slides were not included in the event’s material here’s the presentation’s slide deck.

As in 2011 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 Telco Sec Day at Troopers. We’ll annouce details as for this one in some weeks.

The Story Continues – Another IPv6 Update

Fri, 30 Mar 2012 00:00:00 +0000

TROOPERS12 came to an end last week on Friday; needless to say it was an awesome event. 😉
The first two days offered workshops on various topics. On Monday Enno, Marc “Van Hauser” Heuse and I gave a one day workshop on “Advanced IPv6 Security”. I think attendees as well as trainers had a real good time during and after the workshop fiddling around with IPv6. Especially Marc had quite some fun as he discovered that we provided “global” IPv6 Connectivity for the conference network, and according to one of his tweets, TROOPERS12 was the first security conference he visited, offering this kind of connectivity.

Applying the ERNW Seven Sisters Approach to VoIP Networks

Sat, 03 Mar 2012 00:00:00 +0000

Hi,

if you’re following this blog regularly or if you’ve ever attended an ERNW-led workshop which included an “architecture section” you will certainly remember the “Seven Sisters of Infrastructure Security” stuff (used for example in this post). 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.

As part of our upcoming Black Hat and Troopers 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”:

A Structured Approach to Handling External Connections, Part 1

Fri, 03 Feb 2012 00:00:00 +0000

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

Which – of course – doesn’t work at all in a VUCA world, for a number of reasons (the demarcation between trusted and untrusted is quite unclear – just think of mergers & 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 this presentation– 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 this post for some discussion of the concept of “operational feasibility”…).

ENISA Smartphone Secure Development Guidelines

Mon, 19 Dec 2011 00:00:00 +0000

I just stumbled across this document recently published by the European Network and Information Security Agency (ENISA). It’s part of their smartphone security initiative which we’ve already mentioned in this post.

Here’s an excerpt from the introduction:

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

On the discussion about the iTunes 10.5.1 update

Mon, 28 Nov 2011 00:00:00 +0000

Currently there’s quite some discussion ongoing why it took Apple so long to fix a severe vulnerability in the update process of iTunes. A severe vulnerability which could easily be exploited by means of an automated tool called evilgrade which can be downloaded here (Hi Francisco!). Just one small note here: did you know that evilgrade was first shown and released at the 2008 edition of Troopers? We had a number of initial releases of tools in the last years (like wafw00f at the 2009 edition and VASTO at the 2010 edition) 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…

Carriers Converge Their Internet and MPLS Infrastructure: Time to Redo Your Risk Assessment?

Fri, 25 Nov 2011 00:00:00 +0000

The above is the exact title of a Gartner research note 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.

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 talk “All your packets are belong to us – Attacking backbone technologies”. 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 here.

iOS 5, S/MIME, and Digital Certificate Management

Fri, 04 Nov 2011 00:00:00 +0000

As a follow-up to this post somebody pointed us to this interesting article on S/MIME support and associated certificate mgmt in iOS 5. Nice read which some of you may find worthwhile.

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.

iTrust. Or not?

Sun, 23 Oct 2011 00:00:00 +0000

A few days ago (on 10/12/2011) Apple launched its new cloud offering which is called — who would have guessed 😉 — iCloud. Since we’re performing quite some research in the area of cloud security, we had a first look at the basic functionality and concepts of the iCloud. Its main features include the possibility to store full backups of Apple devices (at least, an iPhone, iPad or iPod touch running iOS 5 or a Mac running OS X Lion 10.7.2 is required), photos, music, or documents online. The data to be stored online is initially pushed to the cloud storage and then synchronized to any device which is using the same iCloud account. From this moment on, all changes on the cloudified data is immediately synchronized to the iCloud and then pushed to all participating devices. At this point, most infosec people might start to be worried a little bit: The common cloud concept of centralized data storage on premise of a third party does not cope well with the usual control focused approach of most technical infosec guys. The resulting concerns can be attributed to several main cloud computing related risks (which are proposed by ENISA and actually very valuable work:

Certificate Based Device Authentication with iOS Devices

Wed, 05 Oct 2011 00:00:00 +0000

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.

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 ERNW newsletter. Special thanks go to Rene Graf for leading the project! 😉

(Auditing) Remote Access Security in 2011

Sun, 14 Aug 2011 00:00:00 +0000

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

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.

OS X Security in Corporate Networks

Sat, 06 Aug 2011 00:00:00 +0000

Interesting presentation just given at Black Hat Vegas.

May be worth a read for those of you responsible for security in networks with MAC users.

have a great weekend,

Enno

Smart (and Scary) Supply Chain Attack

Thu, 04 Aug 2011 00:00:00 +0000

This advisory describes an interesting attack vector:

“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.”

iOS Hardening Configuration Guide

Sun, 17 Jul 2011 00:00:00 +0000

Hi everybody,
eye-catching title of this post, huh?

Actually there is some justification for it ;-), that is bringing this excellent document covering the exact topic to your attention.
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).
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”?]

Yet another update on IPv6 security – Some notes from the IPv6-Kongress in Frankfurt

Mon, 16 May 2011 00:00:00 +0000

A couple of hours ago Christopher (Werny) and I gave this presentation 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 this great book) and Marc “van Hauser” Heuse who released a new version of the THC-IPV6 tool set 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 “from theory to reality” 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 & empty” destination option (after a fragmentation header pointing to the mentioned second one). To get an idea pls see these screenshots from Wireshark.

Evaluating Operational Feasibility

Mon, 02 May 2011 00:00:00 +0000

Hi,
I’ve discussed the concept of evaluating the operational “feasibility” (or “impact”, depending on your point of view) of security controls before. 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:

Once more: hardening is better than patching

Wed, 13 Apr 2011 00:00:00 +0000

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 here and here – 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.

IPv6 Security ‒ The Story Continues

Wed, 09 Mar 2011 00:00:00 +0000

Just a short addition to the previous posts ([1], [2]) 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 computer & competence IT-solutions provider [btw: thanks to Mr. Wendler of CuC for organizing it, and thanks to Mr. Cassel for the breakfast…].

IPv6 Security Part 2, RA Guard – Let’s get practical

Sat, 05 Mar 2011 00:00:00 +0000

Hi everybody,

this post is the sequel of this one 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”).

IPv6 Security Part 1, RA Guard – The Theory

Wed, 05 Jan 2011 00:00:00 +0000

Hi,

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 😉

Things are heating up for Troopers 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:

Security Benefit & Operational Impact or “the Illusion of Infinite Resources”

Sat, 11 Dec 2010 00:00:00 +0000

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?”).
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.
If it’s not, implementing a certain control might just be… waste.
Before giving two examples I’d like to note that this is one aspect I particularly like in the ISECOM OSSTMM 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”.
[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].

Reflections on the vulnerability factor (notes on RRA, part 3)

Mon, 06 Dec 2010 00:00:00 +0000

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]”.
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.
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.
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.
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.
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” …

ERNW Rapid Risk Assessment (RRA), Some Additional Notes, Part 2

Sat, 04 Dec 2010 00:00:00 +0000

This is the second part of the series (part 1 here) 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 method of estimation and the scale & calculation formula used.

1.1 Method of Estimation

Again, two main approaches exist[1]:

Qualitative estimation which uses a scale of qualifying attributes (e.g. Low, Medium, High) to describe the magnitude of each of the contributing factors listed above. [ISO 27005, p. 14] states that qualitative estimation may be used
- As an initial screening activity to identify risks that require more detailed analysis.
- Where this kind of analysis is appropriate for decisions.
- Where the numerical data or resources are inadequate for a quantitative estimation.

As the latter is pretty much always 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 vulnerability factor will be provided in the next part of this series.

ERNW Rapid Risk Assessment (RRA), Some Additional Notes, Part 1

Sun, 07 Nov 2010 00:00:00 +0000

At several occasions we’ve been asked to provide some background on the Rapid Risk Assessment (RRA) 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 😉

The Case For/Against Split Tunneling

Thu, 04 Nov 2010 00:00:00 +0000

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).
Still, we’re security practitioners (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.
[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?
Internally we performed a rapid risk assessment (RRA) focused on two main threats, that were:

News from the Desktop, Edition 2010/07/21

Wed, 21 Jul 2010 00:00:00 +0000

Back on track as for one of our favorite rant subjects: desktop security. This stuff, commonly called the “LNK vulnerability”, has gained quite some momentum in the last days, including the release of a Metasploit module and a temporary raise of SANS Internet Storm Center‘s Infocon level to yellow (it’s back on green in the interim).

CVE-2010-2568 has been assigned and some technical details can be found here and here.

To give you a rough idea how this piece works, here’s a quote from the US-CERT advisory:

Software Developers Don’t Use Available Security Features

Wed, 21 Jul 2010 00:00:00 +0000

According to SANS NewsBites Vol. XII, Issue 53 recently published there’s a lack of 3rd party developer support for some security features Microsoft introduced already years ago. We at ERNW have made similar observations when performing security assessments of COTS [commercial off-the-shelf] software. We therefore created a methodology, a proof of concept tool and a metric to test and to rate closed source software, where (amongst other approaches) these security features are checked and their (non-) presence contributes to an overall evaluation as for the trustworthiness of the applications in question. The concept “How to rate the security in closed source software” was presented to the public at Troopers10 and at Hack in the Box 2010 in Amsterdam. The slides can be found here.

Our Favorite Subject: [It’s all about] Risk

Sun, 11 Jul 2010 00:00:00 +0000

Some days ago my old friend Pete Herzog from ISECOM posted a blog entry titled “Hackers May Be Giants with Sharp Teeth” here which – along with some quite insightful reflections on the way kids perceive “bad people” – contains his usual rant on (the uselessness of) risk assessment.
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 😉

News from Old Friends, Edition 2010/06/09

Wed, 09 Jun 2010 00:00:00 +0000

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.
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. this one) 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”).