Matthias Luft

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.

Continue reading

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

Continue reading

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.

Happy patching & stay tuned,

Continue reading

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.

Continue reading

Flo and I had the pleasure to present at the CSA Nordic 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!

Our slides can be found here:

Hacking Medical Devices

Tools of the Trade: Lessons Learned from the (C)ISO’s Desk

 

best,

Matthias

Continue reading

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:

Continue reading

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

Continue reading

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:

Continue reading

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:

Continue reading

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

Continue reading