In June 2020 we reported three vulnerabilities in Nagios XI 5.7.1 to the
vendor.
The following CVE IDs were assigned to the issues :
CVE-2020-15901: Command Injection in Nagios XI web interface (RCE)
CVE-2020-15902: Cross Site Scripting (XSS)
CVE-2020-15903: Reserved, details will be given on vendor fix
CVE-2020-15901 and CVE-2020-15902 have meanwhile been fixed in version 5.7.2
according to the changelog on the Nagios website
(https://www.nagios.com/downloads/nagios-xi/change-log/). CVE-2020-15903 is
currently being worked on by the vendor and will probably be fixed in the near
future.
Last week I attended ACM WiSec. Of course, only
virtually. The first virtual conference I attended. Coincidentally, it was also
the first conference I presented at. While the experience was quite different
from a “real” conference, the organizers did a great job to make the experience
as good as possible with, for example, a mattermost instance to interact with
other conference participants.
In the following, I will list a few talks and papers that I either found very
interesting or that generally stood out to me:
I should start by telling you that this post does not contain anything
fundamentally new. Hence, if you already know the tools mentioned in the title,
this post may probably not be for you. However, if you are not too familiar with
these tools and want to understand a little bit more on how they work together,
you should keep on reading.
First, let us get a high-level overview of the different tools. We begin with
QEMU. QEMU is a piece of software to emulate hardware
such as processors. Imagine, for example, that you are running an operating
system such as Linux or Windows on a x86-64 machine and that you would like to
analyze a binary that has been compiled for an ARM or MIPS processor. Of course,
you can use static analysis on the binary, but if you want to find out more
about the runtime behavior, well, it would be good to have a corresponding
runtime environment.
From the end of 2019 on, we reported two critical vulnerabilities in the Ivanti
DSM Suite to the vendor. The following CVE IDs were assigned to the issues (but
note that they have a status of RESERVED, i.e. titles and descriptions may
change in the future):
CVE-2020-12441: Denial-of-Service (DoS) in Ivanti Service Manager HEAT Remote
Control 7.4
CVE-2020-13793: Unsafe storage of AD credentials in Ivanti DSM netinst 5.1
The vulnerabilities have meanwhile been fixed and an updated software version
can be downloaded
here.
So there was a pandemic, the whole world was under lockdown, and I got a bit
depressed.
I needed something new in my life, so I decided to take my favorite dog out for
a walk in the ATT&CK jungle to check out the newly added sub-techniques…
If you’re not familiar with ATT&CK and are wondering what this is all about, no
worries…
ATT&CK stands for Adversarial Tactics, Techniques & Common Knowledge.
It’s a treasure trove of information about real-life offensive tradecraft.
I like to see it as an open-source encyclopedia of corporate
post-exploitation.
There is a growing community around the project and more info keeps being added
to it.
[Check out
this post
by @LikeTheCoins if you want to know more]
Digital networking is already widespread in many areas of life. In the
healthcare industry, a clear trend towards networked devices is noticeable, so
that the number of high-tech medical devices in hospitals is steadily
increasing.
In this blog post, we want to elucidate a vulnerability we identified during the
security assessment of a patient monitor. The device sends HL7 v2.x messages,
such as observation results to HL7 v2.x capable electronic medical record (EMR)
systems. A user with malicious intent can tamper these messages. As HL7 v2.x is
a common medical communication standard, we also want to present how this kind
of vulnerability may be mitigated. The assessment was part of the BSI project
ManiMed, which we would like to present in the following section.
Nowadays, Bluetooth is an integral part of mobile devices. Smartphones
interconnect with smartwatches and wireless headphones. By default, most devices
are configured to accept Bluetooth connections from any
nearby unauthenticated device. Bluetooth packets are processed by the Bluetooth
chip (also called a controller), and then passed to the host (Android, Linux,
etc.). Both, the firmware on the chip and the host Bluetooth subsystem, are a
target for Remote Code Execution (RCE) attacks.
With the current situation, it’s not easy to find the right angle to start this
blog post, so I won’t even try… but with Troopers cancelled, my Bloodhound
workshop went down the drain, and I didn’t get a chance to meet or catch up with
all of you and share my latest BloodHound adventures. So I decided to write a
quick post to share all this…
As you might have heard, BloodHound 3 was released last month, so I thought it
was time to update the Dog Whisperers Handbook.
It’s basically a quick intro to BloodHound and Cypher, with a lot of links to
resources for further learning.
You can download the latest version
here. Hope you enjoy it.
We recently came across an issue when playing around with VMware NSX-T which not
anyone might be aware of when getting started with it. Because many of our
customers start with transitioning to NSX-T, we want to share this with you. In
short, the Distributed Firewall (DFW) of NSX-T can be easily bypassed in the
default configuration because it only works effectively if at the same time, the
SpoofGuard feature is enabled on all logical switch ports which is not the
case by default.
Lately, we came across a remote code execution in a Tomcat web service by
utilizing
Expression Language.
The vulnerable POST body field expected a number. When sending ${1+2} instead,
the web site included a Java error message about a failed conversion to
java.lang.Long from java.lang.String with value "3".
From that error message we learned a couple of things:
The application uses Java
We are able to execute EL expressions
Output from the EL engine is always returned as String
Whenever you are able to execute code within a Java Context, the most
interesting part is to check whether we can get a Runtime object and execute
arbitrary OS commands.
