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.
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.
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.
We recently conducted a security assessment of VMware Carbon Black Cloud, a unified SaaS solution that integrates endpoint detection and response (EDR), anti-virus, and vulnerability management capabilities. As part of our evaluation, we tested the solution’s ability to detect and prevent malicious activity on Windows and Linux systems. Our analysis focused on the Carbon Black agents for these platforms, and although we did not identify any critical vulnerabilities, we want to share some of the findings in this blog post.
As part of our research into the Auracast feature set in Bluetooth, we also started looking into vendor implementations. At the time we started with our research, there weren’t a lot of products on the market yet. But new products are coming out pretty frequently now.
One of the vendors that had Auracast implemented pretty early was Samsung. At the time the Samsung Galaxy S23 and S24 phones were able to broadcast Audio, while the Galaxy Buds were able to join these broadcasts.
In our previous blog post we analyze the security of Auracast broadcasts. In short, broadcasts can be encrypted by specifying a so-called Broadcast Code (or Passcode). We show that the key derivation used to derive an AES key from the Broadcast Code is not sufficient to properly protect the broadcast. The weak key derivation, combined with the way the encryption works, allows an attacker to perform an efficient offline brute-force attack against captured Auracast packets. However, when the Broadcast Code is chosen properly, this attack can be made very difficult and likely economically unreasonable.
However, we found that the Bluetooth specification is lacking in this regard. Both the specification of the Broadcast Code itself, and the example values given in the specification and other documents are inadequate.
This, in our opinion, inadequate specification and the poorly chosen examples of Broadcast Codes lead us to suspect that vendors may not be aware of the requirements for a secure Broadcast Code.
This is essentially what happened with Samsung’s implementation.
Recently, one of our customers contacted us to investigate the extent of some unwanted and unexpected behavior regarding browsing data of employees.
Employees started contacting IT support because private browser bookmarks, private login credentials etc. showed up on their work machines. All affected employees stated that they never created these bookmarks on work systems. And interestingly, the data seemed to have been collected over quite some time.
Our customer wanted to understand how private data ended up in their environment. Obviously, private employee data in the enterprise landscape could cause some data privacy trouble (GDPR).
Our customer suspected that Microsoft Teams might be related to this because the company’s employees are allowed to join Teams meetings from private devices. Since this option was often used in many companies during COVID-related work-from-home times, we suspect that a larger number of enterprises may be affected by this problem.