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.
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!
Yesterday 7Elements released
the description
of a Remote Code Execution vulnerability in VMware vCenter. The information came
in at a good point as I’m at the moment drafting a follow-up blogpost for
this one
which will summarize some of our approaches to virtualization security. The
vCenter vulnerability is both quite critical and particularly interesting in
several ways:
Once there is proper network isolation & restriction, the vulnerability should
not be exploitable from the overall corporate network (or maybe even the
Internet — a quick inaccurate shodan search for “vcenter” returned about 1800
results and at random checks actually revealed vCenter systems). It should
also not be exploitable from ESXi hosts managed through the vCenter: ESXi
hosts need to be able to connect to the vCenter for heartbeat messages,
however “only” on ports 443 and 902 — the vulnerability exploits a service
running on TCP
ports 9875 – 9877.
It is questionable whether the exploited Java RMI functionality is really
required for the operation of VMware infrastructures. This
blogpost provides further
detail on the known type of vulnerability in Java applications. VMware had a
similar issue back in 2010,
where their workaround
to fix a vulnerability was to just disable the affected component, resulting
in the impression that it wasn’t even required in the first place. Let’s see
whether the future will bring up more vulnerabilities which could have been
prevented by implementing more thorough hardening of all components (e.g.
following the minimal machine principle). Furthermore in 2011 there was a
similar 3^(rd) party component vulnerability in vCenter which we covered
in this blogpost.
The totality of our posts on VMware security can be found
here.
For high-security environments we have been recommending for some time to use
a dedicated vCenter per hypervisor cluster (i.e. if you have two hypervisor
clusters, one for internal and one for DMZ systems, you should use two
separate vCenter systems). Vulnerabilities like these illustrate the need for
that, given that the ESXi hosts need to be able to access the vCenter on the
network level.
I had the honour to be invited to BT‘s SnoopCon, which is
their annual internal conference for people involved with security at BT. There
were several external and internal speakers and I was stunned by the quality of
the talks and the collaborative atmosphere. Since this event is somewhat
internal (even though I’m obviously allowed to talk about it), I won’t go into
details, however there were two particularly great talks about military war
games (which I personally enjoyed very much given my history in CTF contests)
and PoS security.
Flo and I had the pleasure to present at the CSANordic Summit in Norway.
Being in Oslo for the first time, we enjoyed the conference (small, familiar
atmosphere) very much and want to thank Lars and Kai for putting together such a
good event & having us there!
Today the ERNW Team participated in the Mudiator mud
race in
Mannheim.
This mud run features 25 obstacles over 8 km, you can do either one or two
rounds. Participating for the first time, the ERNW team went for one round (the
Legionnaire distance as opposed to the two round Hercules distance):
Following our idea of open access to knowledge (both about vulnerabilities and
sports 😉 ), here are some hints/lessons learned:
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…).
We’re currently starting the preparation for the
Troopers15PacketWars 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:
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:
Last week we had the opportunity and pleasure to present some of our research
results at BlackHat US 2014 (besides of meeting a lot of old friends and having
a great researchers’ dinner).
Enno and Antonios gave their presentation on IDPS evasion by IPv6 Extension
Headers, described
here.
The material can be found
here: Slides,
tools (the main tool used was Chiron,
authored by Antonios) &
whitepaper.
Ayhan and me presented our results of the security analysis of Cisco’s
EnergyWise protocol. The protocol enables network-wide power monitoring and
control (ie turning servers off or on, putting phones to standby — basically
controlling the power state of all EnergyWise-enabled or PoE devices). The main
problem (besides a DoS vulnerability we found in IOS, see
official Cisco advisory)
is its PSK-based authentication model, which enables an attacker to cause
large-scale blackouts in data centers if the deployment is lacking certain
controls (for example our good old favorite, segmentation…). There will be a
longer blogpost/newsletter on this topic soon.
The material can be found
here: Slides &
tools
