The VERTIV Avocent AutoView switches are analog keyboard, video, and mouse (KVM) switches used in data center servers. They also expose a web server in the network, which allows for some configuration.
During a penetration test for a customer, a device of this type was identified in the infrastructure and analyzed, revealing an authentication bypass in the web application.
With the rise of AI assistance features in an increasing number of products, we have begun to focus some of our research efforts on refining our internal detection and testing guidelines for LLMs by taking a brief look at the new AI integrations we discover.
Alongside the rise of applications with LLM integrations, an increasing number of customers come to ERNW to specifically assess AI applications. Our colleagues Florian Grunow and Hannes Mohr analyzed the novel attack vectors that emerged and presented the results at TROOPERS24 already.
In this blog post, written by my colleague Malte Heinzelmann and me, Florian Port, we will examine multiple interesting exploit chains that we identified in an exemplary application, highlighting the risks resulting from the combination of sensitive data exposure and excessive agency. The target application is an AI email client, which adds a ChatGPT-like assistant to your Google Mail account.
Ultimately, we discovered a prompt injection payload that can be concealed within HTML emails, which is still interpreted by the model even if the user does not directly interact with the malicious email.
The #TROOPERS25 ‘AD & Entra ID Security’ track was a blast – as was the whole conference 😉 – bringing together some of the smartest researchers in the field and a great audience of practitioners willing to share their experiences during the roundtable. The slides of the talks have been released in the interim on the TROOPERS website, but since many speakers published additional blogposts or released tools, we provide a compilation of resources from the track in the following.
The purpose of this blog post is to explain how Secure Boot works. In particular, we will explain where current implementations of Secure Boot by Linux distributors fall short compared to Microsoft Windows and Apple macOS.
Major distributors like Canonical, Debian, openSUSE, and Red Hat place a high priority on making their operating systems work out of the box. Given the current Linux landscape with out-of-tree drivers and incompatible licenses, providing the end user with all the drivers possibly needed to boot the system can be challenging.
In this post we will describe how to set up Secure Boot on Gentoo Linux. Gentoo Linux is sometimes described as a meta-distribution. It leaves many decisions up to its users—and with that, a fair amount of work. The upside is that users can decide exactly how to set up the boot chain without having to work “against” the distributor. For this reason, we chose Gentoo Linux to demonstrate the different ways to set up Secure Boot.
On a hardened system, Secure Boot should be deployed along with full disk encryption1.
In the last blog post, we discussed the full authentication flow using Windows Hello for Business (WHfB) with face recognition to authenticate against an Active Directory with Kerberos and showcased existing and new vulnerabilities. In this blog post, we dive into the architectural challenges WHfB faces and explore how we can exploit them.
Many Linux hardening guides focus on well-known protections: full-disk encryption, Secure Boot, and password-protected bootloaders. While these measures are critical, they often overlook a subtle but serious attack vector: the ability to drop into a debug shell via the Initial RAM Filesystem (initramfs). This oversight can enable an attacker with brief physical access to bypass conventional boot protections and inject persistent malware into the system.
In this post, it is demonstrated how this attack works on modern Linux distributions, such as Ubuntu and Fedora, and explained why existing guidance often fails to mention it.
Important note: Some media coverage on this topic falsely or inaccurately depicts the attack conditions. To be clear: Any vulnerable device can be compromised if the attacker is in Bluetooth range. That is the only precondition.
During our research on Bluetooth headphones and earbuds, we identified several vulnerabilities in devices that incorporate Airoha Systems on a Chip (SoCs). In this blog post, we briefly want to describe the vulnerabilities, point out their impact and provide some context to currently running patch delivery processes as described at this year’s TROOPERS Conference.
Windows Hello for Business is a key component of Microsoft’s passwordless authentication strategy. It enables user authentication not only during system sign-in but also in conjunction with new and advanced features such as Personal Data Encryption, Administrator Protection, and Recall. Rather than depending on traditional passwords, Windows Hello leverages a PIN or biometric methods – such as fingerprint or facial recognition – to unlock cryptographic keys protected by the Trusted Platform Module (TPM).
The X11 Window System has been used since September 1987 for Unix desktop systems, allowing applications to display their windows. Today, one of the server implementations of the protocol is the X.Org X server and XWayland, which both use the same codebase. While reviewing the X server, several legacy security issues were identified. These appear to originate from earlier design stages when security considerations were less prominent. Despite the project’s maturity and widespread use, some of these issues have persisted.