First, a few words regarding my experience at Black Hat: for me, it was the
first time attending the conference and then directly as a speaker. I thoroughly
enjoyed Black Hat. It took a while to get used to the size of the conference and
the vibe of Las Vegas. What was especially interesting for me was connecting
with other researchers. One thing that stood out was meeting with the team from
MSRC and putting faces to the team itself. It feels way more personal to know
who you’re talking to when you know the people handling your cases. During
TROOPERS I typically have the chance to connect with many researchers, mainly
from Europe. At Black Hat US, on the other hand, it is possible to connect more
with the US scene and meet people you haven’t seen in a long time! Seeing
familiar faces again is always nice, as opposed to putting them into your
biometric template database. One nice detail was that some international
researchers are aware of the research BSI (German: “Bundesamt für Sicherheit in
der Informationstechnik” – “German federal office for IT security”) is
facilitating. The results of our presentation stem from the “Windows Dissected”
project we are performing on behalf of the BSI.
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 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.
The majority of the work was conducted in the context of the “Windows Dissected”
project. This project, funded by the BSI (German: “Bundesamt für Sicherheit in
der Informationstechnik” – the German Federal Office for Information Security),
has the goal to perform ” various in-depth security analyses of
security-critical components and functions in Windows.” Over the next years we
will discuss these results here once they are published.
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.
During our recent research, we experimented with different Bluetooth USB
dongles. There are tons of options, and sometimes, it’s challenging to determine
what chipset a dongle actually contains, what Bluetooth features it supports,
and whether it works on Linux. Inspired by the recent
ESP32 Bluetooth research,
we wondered whether we could turn our Raspberry Pi Pico Ws into a functioning
Bluetooth dongle. We had a few lying around, and the advantage here is that we
know exactly which
Bluetooth controller it uses
– the Infineon CYW43439. It’s also very easy to get one. You can just buy the
Pico W for a few bucks, even cheaper than some Bluetooth dongles. You also have
a controller family that has been researched quite a bit in the
internalblue project. However,
there was one disadvantage. We did not find any code that exposes the CYW43439’s
HCI interface via USB. So we had to write that on our own.
In a recent customer project, we discovered vulnerabilities in Microsoft
Bookings, an online appointment scheduling tool integrated into Microsoft 365,
allowing companies to have customers book meetings in available times
themselves. The findings originate from insufficient input validation on the
public meeting scheduling endpoint. Although Microsoft has largely mitigated
this vulnerability, our analysis provides important insights into potential
risks and areas for improvement.
Introduction & Context
Microsoft Bookings is a service that allows organizations to manage appointments
and meetings via a web interface. With integration to services such as Microsoft
Teams, the security of the booking process is critical. This blog post outlines
our technical analysis of the vulnerability, including proof-of-concept details
and an overview of the vendor response.