0 Comments | Posted by Enno Rey
Given there’s quite some speculation and, as we think, misinformation going around we think it’s helpful to add/clarify the following information:
- we fully comply with the injunction and we have no intentions to violate it. we do not plan to publish any technical information besides the report (agreed upon with FireEye themselves) and the slides (based on the former) anyway. No 3rd parties except for the ones involved (FireEye, lawyers) have received any additional technical information from our side, let alone an earlier version of the report.
- the injunction covers accompanying details mostly within the architecture space, but not the core vulnerabilities themselves. Those are not part of the injunction.
- we stand by the timeline as provided below. In particular, the following two points:
– FireEye received a draft version of the report which had the objectionable material (as identified by the cease and desist letter) fully removed on August 11th.
– according to the cease and desist letter FireEye’s lawyer sent us, they were informed – from our side – about the planned talk at 44CON on Jul 23rd.
- there’s an injunction, but not a lawsuit. I used the term “sue” after consulting Merriam-Webster which states: “sue: to seek justice or right from (a person) by legal process”, but this might have been misinterpreted by some readers. As stated, there’s a pending injunction, but not a lawsuit.
Please note that we won’t share legal documents with 3rd parties or publish them as we consider this inappropriate.
Please note further that, during the whole process, our goal was to perform a responsible disclosure procedure with its inherent objectives (namely vulnerability remediation by vendor and education of various stakeholders involved, see also here or here). We consider this disclosure process as concluded. We don’t see a need to add technical details from our side as we feel that the objectives of responsible disclosure are met (not least as patches are released since quite some time and both vendor & finder have released reports).
We’ve just released an ERNW Newsletter titled “Playing With Fire: Attacking the FireEye MPS” which describes several (meanwhile patched) vulnerabilities in FireEye‘s “Malware Protection System” (webMPS) version 7.5.1. Right now Felix gives a talk at 44CON in London on the topic, including some demos. He will release the slides after the talk => to catch the respective announcement you might follow him on Twitter (which is probably a good idea anyway if you’re interested in vulnerability research).
Recently I had the pleasure to attend the 24th USENIX Security Symposium and its co-located Workshop on Offensive Technologies (WOOT) in Washington, D.C. The workshop has received quite some attention this year, 57 submissions of which 19 have been accepted, so that the organizers decided to double its length from one to two days. (more…)
3 Comments | Posted by Niklaus Schiess
this is a short write up about the Maintenance Operation Protocol (MOP), an ancient remote management protocol from the DECnet protocol suite. It’s old, rarely used and in most cases not needed at all. But as we stumbled across this protocol in some network assessments, it seems like a lot of network admins and other users don’t know about it. Even various hardening guides we’ve seen don’t mention MOP at all.
our home automation research, especially with KNX, is still in progress. As part of this research we’ve implemented various tools to easy the process of identifying and enumerating KNX devices, in both IP driven networks and on the bus.
Lately we’ve written two Nmap NSE scripts to discover KNXnet/IP gateways. These allow everyone to discover such gateways in local and remote networks and print some useful information about them. One of them follows the specification to discover gateways by sending multicast packets, where all devices on the network must respond to. Due to the specification of KNXnet/IP this process is rather non-invasive because only a single UDP packet is needed to discover multiple gateways. The other script allows to identify gateways via unicast connections by a slightly different message type, which allows discovery over e.g. the Internet.
The scripts are now publicly available and will (hopefully) be included in Nmap soon.
Currently we are working on a tool which allows to enumerate KNX devices on the bus either from an IP driven network over a KNXnet/IP gateway or directly on the bus. Additionally information about the discovered devices included in the bus system will be extracted, e.g. what kind of device it is a sensor or an actuator.
It is planned to be released soon, so stay tuned 😉
Today we received a few ShareBrained Technology – PortaPack H1 to use with our HackRFs. Having done a first few minutes of scanning, I just wanted to give you a quick overview of its features and potential…
1 Comment | Posted by Enno Rey
This year’s Black Hat US saw a number of quite interesting talks in the context of Windows or Active Directory Security. For those of you too lazy to search for themselves 😉 and for our own Windows/AD Sec team (who couldn’t send anyone to Vegas due to heavy project load) I’ve compiled a little list of those.
During the last few months information about one of North Koreas operating systems was leaked. It is a Linux based OS that tries to simulate the look and feel of a Mac. Some of it’s features have already been discussed on various blog posts and news articles. We thought we would take a short look at the OS. This blog post contains some of the results.
As you can imagine, most interesting for us was to investigate features that impact the privacy of the users. There are some publications concerning the security of the OS, this is an aspect that we will not cover in this post. We will stick to a privacy issue that we identified in this post. As ERNW has a long history of “Making the World a Safer Place”, we consider this topic an important one. The privacy of potential users (especially from North Korea) may be impacted and therefore we think that the results must be made available for the public. So, here we go … (more…)
0 Comments | Posted by Benjamin Schwendemann
Some of you might use WebEx in their daily life. And some of you might use Linux (as I and many of us do). However, this combination often results in issues with your PC’s sound or microphone use in a WebEx session.
The problem here is that WebEx won’t run as intended with Firefox and JRE x64. But the solution is quite easy! Use the x86-versions of each.
Probably you don’t want to replace your x64 versions of either of them — and neither do I. So I wrote a little script which helps you to quickly switch to the x86 versions, while you still have the x64 versions installed. And here is how to do it:
In this post I’ll discuss some aspects of vulnerability disclosure. I don’t want to delve into an abstract & general discussion of vulnerability disclosure (for those interested here’s some discussion in the context of Google’s Project Zero, this is the well-known CERT/CC approach, this a paper from WEIS 2006 laying out some variants, and finally some statement by Bruce Schneier back in 2007). Instead I will lay out which approach we followed in the past (and why we did so) and which developments make us consider it necessary to re-think our way of handling. The post is not meant to provide definitive answers; it was also written not least to provide clarity for ourselves (“write down a problem in order to better penetrate it”) and, maybe, to serve as a starting point for a discussion which will help the community (and us) to find a position on some of the inherent challenges.