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