Breaking, Building, Events

ACM WiSec 2020

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:

Continue reading “ACM WiSec 2020”

Continue reading
Breaking

Medical Device Security: HL7v2 Injections in Patient Monitors

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.

Continue reading “Medical Device Security: HL7v2 Injections in Patient Monitors”

Continue reading
Breaking

CVE-2020-0022 an Android 8.0-9.0 Bluetooth Zero-Click RCE – BlueFrag

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.

One feature that is available on most classic Bluetooth implementations is answering over Bluetooth pings. Everything an attacker needs to know is the device’s Bluetooth address. Even if the target is not discoverable, it typically accepts connections if it gets addressed. For example, an attacker can run l2ping, which establishes an L2CAP connection and sends echo requests to the remote target.

In the following, we describe a Bluetooth zero-click short-distance RCE exploit against Android 9, which got assigned CVE-2020-0022 . We go through all steps required to establish a remote shell on a Samsung Galaxy S10e, which was working on an up-to-date Android 9 when reporting the issue on November 3 2019. The initial flaw used for this exploit is still present in Android 10, but we utilize an additional bug in Bionic (Android’s libc implementation), which makes exploitation way easier. The bug was finally fixed in the security patch from 1.2.2020 in A-143894715. Here is a demo of the full proof of concept:

Continue reading “CVE-2020-0022 an Android 8.0-9.0 Bluetooth Zero-Click RCE – BlueFrag”

Continue reading
Breaking, Building

DNS exfiltration case study

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.

Sending ${Runtime.getRuntime()} resolves to java.lang.Runtime@de30bb. Great, so we can use Runtime.exec(String cmd) to execute arbitrary code? Continue reading “DNS exfiltration case study”

Continue reading
Breaking

Jenkins – Groovy Sandbox breakout (SECURITY-1538 / CVE-2019-10393, CVE-2019-10394, CVE-2019-10399, CVE-2019-10400)

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.

Continue reading “Jenkins – Groovy Sandbox breakout (SECURITY-1538 / CVE-2019-10393, CVE-2019-10394, CVE-2019-10399, CVE-2019-10400)”

Continue reading
Breaking

How to break out of restricted shells with tcpdump

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. Continue reading “How to break out of restricted shells with tcpdump”

Continue reading
Breaking

Multiple Vulnerabilities in innovaphone VoIP Products Fixed

Dear all,

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. Continue reading “Multiple Vulnerabilities in innovaphone VoIP Products Fixed”

Continue reading
Breaking

On the insecurity of math.random and it’s siblings

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?

Continue reading “On the insecurity of math.random and it’s siblings”

Continue reading