We reported a possible Man-in-the-Middle (MitM) attack scenario in which
a VirtualService can redirect or intercept traffic within the service mesh.
This affects Namespace-based Multi-Tenancy clusters where tenants have the
permissions to deploy Istio resources (networking.istio.io/v1).
This blog post highlights the risks of using Istio in multi-tenant clusters and
explains how users can mitigate these risks and safely operate Istio in their
deployments.
There is a growing landscape of security products promising to protect an
organization’s IT infrastructure from attacks. Solutions referred to as EDR, and
sometimes also as XDR, are designed to protect endpoints from all malicious
activity. The ever-increasing cases of breaches and the associated costs,
especially in the realm of
ransomware attacks,
raise the question of whether there is more that can be done to add an
additional layer to traditional endpoint protection concepts. That is why a
customer of ours commissioned us to evaluate whether EDR supplementing solutions
provide extended protection against ever-evolving threats, as well as to shine a
light on the performance overheads those solutions might introduce.
During a customer project, we identified privilege escalation vulnerabilities in
Broadcom VMware Aria Operations. It is possible to escalate the privileges of an
administrative vCenter user to an Aria administrator and take over systems
integrated in Aria. Meaning, the vCenter user can gain privileged access to
systems they have no access to. While both users might sound similarly
privileged, this is not true in most environments – especially not in complex
corporate environments: An insignificant vCenter user in a development
environment can take over all other vCenters in a complex corporate environment.
This blog post describes the journey of how we discovered an interesting
Bluetooth SoC within the Datong NP330, a
Printer Server IoT device.
Our initial goal was to reverse-engineer and analyze the Bluetooth controller
that is included in the device. So we wanted to be able to dump the firmware or,
if possible, get shell access on the printer server. During that journey we
found a few vulnerabilities that ultimately let an attacker fully compromise the
device. This is possible over Bluetooth or network via unauthenticated remote
code execution with root privileges.
AI agents are here, there, and everywhere. Smarter, faster, and more skilled,
they gain greater autonomy and trust. We trust their capabilities to do many
tasks much faster and sometimes better than we can. We trust them as they
usually demonstrate their eagerness to please us and fulfill our commands. Isn’t
that too good to be true, and we might be dealing with a double-edged sword
here? Can attackers use the same capabilities of the AI agents to attack their
own users? Can they exploit their eagerness to please their users to fulfill the
attackers’ intentions? And most importantly: what’s the worst that could happen
if you fully trust some random AI Agent?
During a customer project we identified an issue with the validation of JWT
tokens that allowed us to bypass the authentication by using unsigned tokens
with arbitrary payloads. During analysis we found out that this is caused by a
vulnerability within the library
OpenID Connect Authenticator for Tomcat.
OpenID Connect Authenticator for Tomcat
between versions 2.0.0 and 2.5.0, as well as the current state on branch
master contain a security flaw (introduced with commit 64e9a99) that allows
attackers to bypass JWT signature validation easily.
After seven years, we’re publishing a new macOS hardening guide. Fully updated,
modernized, and now publicly available on
GitHub
as
Markdown
and on our website as
PDF.
The previous guide, written for macOS Mojave (10.14), reflected a very different
macOS security model. At the time, hardening often meant working around the
operating system, manually enforcing controls, and compensating for missing
platform guarantees. That guide served its purpose, but the platform has
fundamentally changed since then.
When conducting pentests of Bluetooth devices or whilst working on Bluetooth
related research, we often use Bumble. In
this Blogpost I will present a solution to capture a live stream of Bumble
Bluetooth traffic in Wireshark.
Bumble is a fully featured Bluetooth stack, written entirely in Python. What
makes it extremely powerful for security assessments and research is the level
of control it provides. It can simulate certain conditions, including errors,
with a level of precision that most Bluetooth stacks don’t offer. However,
sometimes you not only need control, you also need visibility.
We are regularly offering a
GCP Incident Response and Analysis
training. In this training, we analyze resources in GCP cloud together with our
trainees that were successfully compromised by attackers, e.g., GCE instances
and Cloud Build projects. Therefore, we need tooling that quickly detects
misconfiguration of resources that helped the attacker during the compromise.
During the analysis of different tools and different kinds of misconfiguration
we realized that GCE instance access scopes are a blind spot of many (in fact
all that we tested) security audit tools. In this blog post, we want to
elaborate on the problems that arise from this behavior.
About six months ago we released a
security advisory
on this blog about vulnerabilities in Airoha-based Bluetooth headphones and
earbuds. Back then, we didn’t release all technical details to give vendors more
time to release updates and users time to patch their devices. Around the time
of the initial partial disclosure in the beginning of June, Airoha put out an
SDK release for their customers that mitigates the vulnerabilities. Now, half a
year later, we finally want to publish the technical details and release a tool
for researchers and users to continue researching and check whether their
devices are vulnerable.