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:
Today I had to give the pleasure to give a keynote at the
SIGS DC Day on the need to evaluate Cloud Service
Providers in a way that looks behind (or at least tries to) security whitepapers
and certification reports. The slides can be found
here.
I also particularly enjoyed the following two talks:
Sean O’Tool from Swisscom AG covered challenges of an infrastructure to cloud
migration. Even though he only briefly touched the topic, I enjoyed his
description of their firewalling model: Seeing that centralized firewall
operation (or more precisely, rule design and approval) is limited/challenged by
the understanding of the application, they transferred control over firewall
rule sets (beyond a basic set of infrastructure/ground rules) to the application
teams (using of features like OpenStack’s security groups, where he also talked
about limitations of those). They compensated the loss of “centralized
enforcement by a security group” with rule reviews — an approach that will
become way more relevant (and necessary) in the future.
Last month the annual USENIX Security Symposium with its co-located workshops
(WOOT, CSET, FOCI, ASE, and HotSec) was held in Austin, Texas. The program of
the conference together with the published papers can be found
here
and information on the workshops can be found
here.
The research topics were quite diverse and included subjects such as low-level
attacks, cryptographic attacks, and vehicle attacks. To give you an impression
on the research that has been presented at the conference, let us discuss some
of the talks in the following:
Some years ago I discussed the meaning of the term “control” in
this post,
but at the time I was mainly referring to the noun “control”. Given I’ll
extensively use the term “control” as a verb in the next parts of “the
DMZseries”
and some upcomingtalks I reflected a bit on its meaning
(as a verb). In the following I’ll lay out the definition/understanding to be
employed at those occasions.
Internal workshops are one of the reoccurring events at ERNW, that help us to
gain knowledge in areas outside our usual expertise. One of the recent workshops
which happened during the week from August 22nd-25th was Hardware Hacking. Held
by Brian Butterly (@BadgeWizard) and Dominic
Spill (@dominicgs), this workshop took place in two parts.
Brian kickstarted the introductory session by guiding us through the fundamental
steps of Hardware Hacking. Brian did an excellent job of making things simpler
by giving a detailed explanation on the basic concepts. For a beginner in
hardware hacking, the topic could be rather intimidating if not handled
properly.
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.
Users of the KNX, a standard
for home automation bus systems, may already have come across KNXnet/IP (also
known as EIBnet/IP): It is an extension for KNX that defines Ethernet as a
communication medium for KNX which allows communication with KNX buses over IP
driven networks. Additionally, it enables one to couple multiple bus
installations over IP gateways, or so called KNXnet/IP gateways.
In the course of some KNX related research we’ve had access to various KNXnet/IP
gateways from different vendors, most of them coupled in a lab setup for testing
purposes. The typical tools used for such tasks are
ETS, the
professional software developed by the creators of KNX (proprietary, test
licenses available) and
eibd, an open source
implementation of the KNX standard developed by the TU Vienna.
This year’s MRMCD16 had a topic that immediately
let me submit a talk about medical device security: “diagnosis:critical”. Or to
quote the official website:
Security issues in soft- and hardware have a low chance of healing, especially
in medical IT.
Despite years of therapy using code reviews and programming guidelines, we still
face huge amounts of vulnerable software that probably is in need of palliative
treatment.
Security vulnerabilities caused by the invasion of IT in the medical sector are
becoming real threats. From insulin pumps over analgesic pumps through to pace
makers, more and more medical devices have been hacked already. This year’s
motto “mrmcd2016 - diagnosis:critical” stands summarizing for the current state
of the whole IT sector.
Welcome back to the radare2 reversing tutorials. If you’ve missed the previous
parts, you can find them here and
here.
Last time we’ve used the rabin2 application to view the strings found inside
the challenge01 binary to find password candidates. Based on the results we
looked into the assembly to find the correct password. In this post, we’ll go
through the next challenge and try out some of the features provided by radare2.
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).