Dennis and I already published blog posts about our research project dealing
with vulnerabilities in parcel tracking implementations at
DHL
and DPD. At the
Winterkongress (winter
congress) in Winterthur, Switzerland, we had the great opportunity to give a
talk about the matter. The talk was recorded and can be watched
here.
DigiGes held the Winterkongress, which
took place in Winterthur on 01.03. till 02.03.2024. The main topics are ethics,
threats, and opportunities of IT. This year, many talks looked at AI in some
way.
I was writing some challenges for PacketWars at
TROOPERS22. One was intended to be a JWT key confusion
challenge where the public key from an RSA JWT should be recovered and used to
sign a symmetric JWT. For that, I was searching for a library vulnerable to JWT
key confusion by default and found lua-resty-jwt. The original repository by
SkyLothar is not maintained and different from the library that is installed
with the LuaRocks package manager. The investigated library is a
fork of the original repository,
maintained by cdbattags in version 0.2.3 and was downloaded more than
4.8 million times
according to LuaRocks.
This blog post is the continuation of our parcel research. We already reported
about how we broke parcel tracking at
DHL
and the disclosure process of the identified problems. As DHL is not the only
parcel service in Germany, we also investigated the other available parcel
services. In this blog post, we want to talk about DPD, also called Geopost,
which belongs to the French Post Office.
Efficient Guessing of Tracking Numbers
DPD uses the recipient’s ZIP code to unlock detailed shipment information and
additional options. After trying some ZIP codes manually, we received CAPTCHA
prompts in the web interface (more on this later).
At Troopers 2023, we gave a talk on how to attack DHL parcel tracking
information based on OSINT. Since we previously had an exemplary disclosure
process about this attack with DHL, Mr. Kiehne (from DHL) joined us to provide
interesting background information and insights on how they addressed our
findings.
We want to thank DHL and especially Mr. Kiehne for sharing those insights with
us at Troopers 2023. It is the ideal case, but still not common that
organizations talk openly about their actions and views on a disclosure process.
During the past year we had several projects where our target application used
Jasper Reports in some way. In a few of the
cases we found an API that offered to render a template along with some
arguments into a PDF file. This was done with the help of the Jasper Reports
Java library. Due to the way the library and the expression mechanism works,
this endpoint gave us the possibility to inject Java code and gain remote code
execution on the target systems.
Process Hollowing is a technique used by various malware families (such as
FormBook, TrickBot and Agent Tesla) to hide their malicious code within a benign
appearing process. The typical workflow for setting up such a
hollowed process is as
follows:
Create a new process (victim) using a benign executable, in suspended state.
Unmap the executable from that process.
Allocate memory for the malicious executable at the address of the
previously mapped victim executable.
Write the malicious executable to the new memory area and potentially apply
relocations.
Adjust the entry point.
Resume process.
We will refer to this as the “normal” Process Hollowing workflow. There are also
variants of this technique, one being to not unmap the original executable and
to allocate the new memory somewhere else. We will call this one no-unmap. But
wait, why does malware not simply overwrite the existing executable but creates
a new memory area which stands out due to its characteristics? In this blog post
we will have a closer look at this overwrite approach but also on the no-unmap
method, their effects on analysis/detection tools and on some tricks to make the
detection harder. We are also releasing Proof of Concept implementations of all
mentioned tools/plugins (the links are at the end of this post).
Updated on 20.06.22 with CVEs and link to Broadcom Security Notice.
In April 2021 we reported seven vulnerabilities in Broadcom Automic Automation
(UC4) 12.3.5+hf.3. CVE IDs were assigned on 16.06.22, the corresponding Broadcom
Security Notice can be found
here.
The vulnerabilities have been found in the course of a research project, in
which we analyzed the security of multiple Endpoint Management solutions.
Similar vulnerabilities have been found in other solutions as we pointed out in
previous posts about the
Ivanti DSM Suite,
Nagios XI,
and
Solarwinds N-Central.
The outcome of the research project will be published as a whitepaper and a
conference talk at
Troopers 2022.
Using a static passkey for Bluetooth Low Energy pairing is insecure. Recent
versions of the Bluetooth specification contain an explicit warning about this.
However, in practice, we often see static passkeys being used. Moreover, there
are no public implementations of proofs-of-concept that can practically show why
using a static passkey is an issue. This is why we implemented one.
In a recent assessment, we were testing a device that offered a Bluetooth
interface for data export and configuration. This device uses Bluetooth Low
Energy (BLE), and a static passkey (or PIN) is required to pair with it. This
passkey is displayed for a few seconds when the device is booted and stays the
same on each reboot. In fact, it is derived from static, device-specific data.
The Federal Office for Information Security (BSI) aims to sensitize
manufacturers and the public regarding security risks of networked medical
devices in Germany. In response to the often fatal security reports and press
releases of networked medical devices, the BSI initiated the project
Manipulation of Medical Devices (ManiMed) in 2019. In this project, a security
analysis of selected products is carried out through security assessments
followed by Coordinated Vulnerability Diclosure (CVD) processes. The project
report was published on December 31, 2020, and can be accessed on the BSI
website
[1].
In this post, we are discussing a bug we came across in Mesas llvmpipe Gallium3D
graphics driver. This bug was accessible through Chromium’s WebGL implementation
and can provide control of the program counter (pc) within Chromium’s GPU
process if llvmpipe is used. Llvmpipe is a software rasterizer that is used on
Linux if no hardware acceleration (graphics card) is available. This is a pretty
rare edge case as llvmpipe has no widespread use. An estimate by Google is that
approx 0.06% of the Chromium users are affected by this. However, as this is a
simple but valid Chromium bug, we want to give you a quick walkthrough. The
issue is tracked as
CVE-2021-21153
and was fixed in February 2020.