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:
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.
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.
On November 3rd, 2019, we have reported a critical vulnerability affecting the
Android Bluetooth subsystem. This vulnerability has been assigned
CVE-2020-0022
and was now patched in the
latest security patch
from February 2020. The security impact is as follows:
On Android 8.0 to 9.0, a remote attacker within proximity can silently execute
arbitrary code with the privileges of the Bluetooth daemon as long as
Bluetooth is enabled. No user interaction is required and only the Bluetooth
MAC address of the target devices has to be known. For some devices, the
Bluetooth MAC address can be deduced from the WiFi MAC address. This
vulnerability can lead to theft of personal data and could potentially be used
to spread malware (Short-Distance Worm).
On Android 10, this vulnerability is not exploitable for technical reasons and
only results in a crash of the Bluetooth daemon.
Android versions even older than 8.0 might also be affected but we have not
evaluated the impact.
Users are strongly advised to install the latest available security patch from
February 2020. If you have no patch available yet or your device is not
supported anymore, you can try to mitigate the impact by some generic behavior
rules:
Recently, I discovered a sandbox breakout in the Groovy Sandbox used by the
Jenkins script-security Plugin in their Pipeline Plugin for build scripts. We
responsibly disclosed this vulnerability and in the current version of Jenkins
it has been fixed and the according
Jenkins Security Advisory 2019-09-12
has been published. In this blogpost I want to report a bit on the technical
details of the vulnerability.
Description
The groovy sandbox transforms some AST nodes of the script to add security
checks. For example
During security assessments we sometimes obtain access to a restricted shell on
a target system. To advance further and gain complete control of the system, the
next step is usually to break out of this shell. If the restricted shell
provides access to certain system binaries, these binaries can often be
exploited to perform such a break out. Here we would like to show an interesting
example of such a break out by using the tcpdump binary.
innovaphone fixed several vulnerabilities in two
VoIP products that we disclosed a while ago. The affected products are the
Linux Application Platform
and the
IPVA.
Unfortunately, the release notes are not public (yet?) and the vendor does not
include information about the vulnerabilities for the Linux Application
Platform. Therefore, we decided to publish some more technical details for the
issues.
Multiple Vulnerabilities in Linux Application Platform
The Linux Application Platform was affected by three vulnerabilities that could
be chained to get full root access to a target system. However, the initial
access vector is only exploitable by authenticated users. The vulnerabilities
have been identified on the Linux Application Platform V10 SR41. According to
the vendor they have been fixed in
V10 SR57.
Again, Cisco released security advisories for their software-defined networking
(SDN) solution called Application Centric Infrastructure (ACI). As before (see
blog post
here),
the published advisories originated from research performed in our ACI lab.
During code reviews we often see developers using weak RNGs like math.random()
to generate cryptographic secrets. We think it is commonly known that weak
random number generators (RNG) must not be used for any kind of secret and
recommend using secure alternatives. I explicitly did not state a specific
language yet, because basically every language offers both weak and strong RNGs.
So I asked myself: What if I use a weak RNG to generate a secret? Is it possible
to recover the secret from some derived value, like a hash?