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.
During a red-teaming-style customer project, we managed to get access to an
Rundeck API token. Rundeck is a job scheduler and
runbook automation platform designed to automate routine IT tasks across
multiple systems. At first, we were excited about this API token because if we
could create new Rundeck jobs, we could execute arbitrary code on the Rundeck
nodes and move laterally from there. However, it turned out that with this token
we only had permissions to run existing jobs.
We discovered a private key for accessing an IBM Hardware Management Console
(HMC) during a recent red team engagement. The IBM Hardware Management Console
(HMC) is a dedicated management system used to control and manage IBM servers,
especially those running on Power Systems (like IBM Power9/Power10) and
mainframes (z Systems). After brief research, we identified two security
vulnerabilities that can be leveraged to gain root access to the HMC.
Access for most users via SSH is limited through the hmcbash, a restricted
shell environment. Using LD_PRELOAD, attackers can break out of the restricted
bash and gain access to additional binaries installed on the system. With the
restrictions lifted, attackers can use a setuid binary, copysshkey, to
elevate privileges to root.
When you’re analyzing web applications as a pentester or reading pentest reports
about web applications, you will often see findings regarding cookies missing
certain security flags. The Set-Cookie HTTP header and the JavaScript
document.cookie API allow to use, for example, the
flags Secure, Path, and Domain.
Common audit and pentest tools will tell you when your web application does not
or just insecurely implements these cookie flags.
However, they do not provide optimal security even when using these flags
correctly. However, there are mitigations available that partly solve the
issues.