Recently, we held a talk at the Winterkongress1 of the Digitale Gesellschaft Schweiz in Winterthur, Switzerland, about our research project on breaking German parcel tracking sites. We could not name all the parcel services for which we identified vulnerabilities respecting disclosure timelines. Today, we describe our findings at GLS, another player in the German parcel market, and the disclosure process of corresponding vulnerabilities.
Today, we describe our findings at United Parcel Service of America, Inc. (UPS), another German parcel market player, and the corresponding vulnerabilities’ disclosure process.
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.
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.
While looking at the source code I found a way to circumvent authentication entirely.
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.
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.
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.
In this blog post we want to provide an overview over the Jasper Reports Java library in terms of security especially with regard to expression injection attacks.
TL;DR; If you come across an API that lets you freely define a Jasper Report template you very likely have code execution. Or to put it differently: Never let Jasper Report templates be user or attacker controlled.
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.
In this blog post we will provide a short description of the vulnerabilities outlining the impact. More technical details will be published in the whitepaper and conference talk. All vulnerabilities were found in Broadcom Automic Automation (UC4) version 12.3.5+hf.3.
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.