During a recent customer project we identified several vulnerabilities in the
VMware vRealize Automation Center such as a DOM-based cross-site scripting and a
missing renewal of session tokens during the login. The vulnerabilities have
been disclosed to VMware on November 20th, 2017. A security advisory for the
vulnerabilities has been made available
here on April
12th, 2018.
Just a few words regarding the cross-site scripting vulnerability. This
vulnerability is present within a GET request to the URL /vcac/gadgets/ifr
because of certain URL parameters whose values are directly passed to an eval
function call. The vulnerable parameters are gwt:onLoadErrorFn and
gwt:onPropertyErrorFn. It seems that these parameters are actually never used
by the application and we only found them by looking at the source code.
In various scenarios it might be helpful or even required to have a statically
compiled version of Nmap available. This applies to e.g. scenarios where only
limited user privileges are available and installing anything to the system
might not be desirable.
For such cases I’ve started to create recipes to build such binaries. Similar
projects are already available on GitHub, but there are several reasons why I
chose to create my own tools:
In this article, we describe the impact of the increased use of Docker in
corporate environments on forensic investigations and incident analysis. Even
though Docker is being used more and more (Portworx, Inc., 2017), the
implications of the changed runtime environment for forensic processes and tools
have barely been considered. We describe the technological basics of Docker and,
based on them, outline the differences that occur with respect to digital
evidence and previously used methods for evidence acquisition. Specifically, we
look at digital evidence within a Docker container which are lost or need to be
acquired in different ways compared to a classical virtual machine, and what new
traces and opportunities arise from Docker itself.
A new ERNW whitepaper was just published. I wrote this whitepaper in the course
of my bachelor thesis and it examines multi-factor authentication in Microsoft
Windows environments:
Credential theft and the subsequent reuse of stolen credentials are a
significant problem in today’s information security. To counter the associated
risks, a planned approach is required as part of a comprehensive security
architecture program. This includes the implementation of multi-factor
authentication as an important building block. This whitepaper covers the
relevant steps of implementing a multi-factor authentication system in an
enterprise environment and closes with a security evaluation.
the
last post was
about a fuse filesystem which provides a read-only access to the proprietary
bluecoat filesystem. After some further investigations based on the
possibilities this offered us, I started to implement a tool which allows to
modify parts of the filesystem.
Protection Mechanisms
Since last time, the discovered filesystem structures still had unknown fields.
Some of those fields could be reconstructed and their purpose in the whole
construct. The format of the Partition-Header for example could now be
described as
A while ago I wrote a short paper laying out options for an enterprise
organization to get global IPv6 address space from the RIPE NCC, discussing the
advantages and disadvantages of different approaches. As I think the topic may
be of interest for others, too, I’ve distilled an anonymized version. It can be
found here. I hope
some of you find it useful.
As you may remember, back in 2014 we published
a whitepaper (compiled
by Antonis Atlasis) on the support of
IPv6 in different pentesting tools. This is almost three years ago and we
thought it is time for an update. In short not much has changed. Most of the
tools which didn’t support IPv6 are still not supporting it or haven’t got any
update since then.
This post will cover the tools where we could identify some progress on
supporting IPv6.
Just recently we discussed IPv6 filter rules for NIC-level firewalls (in a
virtualized data center) with a customer. I’d like to take this as an
opportunity to lay out potential approaches for local packet filtering of IPv6,
which in turn might somewhat depend on the address configuration strategy chosen
for the respective systems (for the latter you may refer to
this post
or
to this talk
from the Troopers NGI event).
Some of this has already been discussed in
RFC 4890 Recommendations for Filtering ICMPv6 Messages in Firewalls
but that document is from 2007 and things may have changed in the interim.
Let’s start with a quick look at the traffic which might be of interest. We will
take a server perspective here, read: which types of IPv6 traffic might have to
be accepted by a host/NIC firewall in order to support proper operations? I will
discuss the following, with a focus on the implications of filtering them
locally:
A Cisco Catalyst 3560 switch running the software “C3560c405ex-UNIVERSALK9-M”
version 15.2(2)E4 connecting
A Linux based attacker system running Chiron and
A FreeBSD target system, running different OS versions and configurations and
A Linux based laptop running a control script that remotely performed the
necessary tasks on the two machines mentioned above
The main question was: Would the impact on the target system and the possible
attacks that were observed with the Windows Server 2016 victim be reproducible
on other operating systems? Or would those behave totally differently?
27 April 2016 marked a turning point for a lot of countries as well as a lot
businesses worldwide: EU regulation 2016/679 (going by it’s more widely known
name General Data Protection Regulation and abbreviated GDPR) was adopted by the
European Parliament, the Council as well as the Commission [1]. Especially
readers from countries outside of the EU might ask “Why should this be of
interest for me?”.
The point is: if your business is dealing with data of EU citizens (e.g. because
you are having an online shop selling goods in the EU, or you operate a social
network platform with customers that are EU citizens) you are liable under GDPR
– this is regulated in Article 3, section 2 of the regulation: “This Regulation
applies to the processing of personal data of data subjects residing in the
Union by a controller not established in the Union, where the processing
activities are related to: (a) the offering of goods or services to such data subjects in the Union; or (b) the monitoring of their behaviour.”
I’d guess that if you are reading these lines you become aware (if not have been
so before) that your business might most probably be affected by GDPR as well.
Now, the purpose of this blog post is not to enlighten you on the basics of GDPR
but to discuss one special, interesting aspect of this regulation:
pseudonymisation and how it might support your way to become compliant with
GDPR.