Hardening a Linux client system to an acceptable degree is a time-consuming
process, one that demands familiarity with a broad set of configuration
parameters, framework recommendations, and the reasoning behind each control.
This post introduces our new Linux client hardening guide
(MD,
PDF), a comprehensive, publicly
available hardening reference for Linux systems.
Motivation and Scope
The guide covers the full breadth of controls needed to significantly raise the
security posture of a modern Linux installation while preserving operational
usability (this will be very subjective, the guide reflects my opinion of
“usable”). It has been developed and validated against Ubuntu 24.04 LTS as the
primary reference platform, and cross-tested on Fedora, Debian 12, and Arch
Linux as well as on traditionally server-oriented distributions like openSUSE
Leap 15.6, Debian 12, Rocky Linux 9, and Red Hat Enterprise Linux 9 while not
focussing on those as the guide is created for Linux clients.
Over the last few weeks, I have had a very productive exchange with
Christoph Klaassen
on the impact of AI on security governance and compliance. In this post, we
summarize our thoughts.
During a penetration test for a customer, we identified a command injection
vulnerability in Geutebrück security cameras that allows authenticated attackers
to execute arbitrary commands as root through the web interface. The root cause
is unsanitized user input being passed into a sed script (and at least 12
other CGI endpoints). In addition to the injection, we identified an XSS
vulnerability, an exposed system menu leaking configuration and log data, and an
insecure GET-parameter-to-environment-variable mapping that enables abuse of
variables like LD_PRELOAD and LD_DEBUG. We reported the findings to
Geutebrück and a patched firmware was provided. This post walks through how we
got from a sed error message to a root shell.
While investigating how process mitigation settings are initialized, I
encountered the global variable PspSystemMitigationOptions. Tracing how this
value is populated led me to the CmControlVector. In this blog post, we take a
look at the Windows kernel land configuration manager, especially its global
CmControlVector variable. Quick note: the kernel’s configuration manager is
not related to Microsoft Intune’s
Configuration Manager.
In short, the configuration manager is responsible for managing and implementing
the registry. However, it is also responsible for setting up parts of the system
during early boot.
Exactly one week ago, Sven and I had the incredible opportunity to give our very
first talk at KubeCon + CloudNativeCon
2026: How To Break Multi-Tenancy Again and Again …and What We Can Learn From It.
We discussed the challenges of namespace-based multi-tenancy and presented
real-world exploits in
Kubeflow, Istio,
and Traefik that bypass threat boundaries between namespaces and workloads.
Based on these problems, we developed a methodology to assess and address them.
You can find the methodology discussed in the talk in
detail in another blog post or
on GitHub. You can also find the
slides here.
This page introduces our structured methodology for assessing security risks in
Kubernetes environments that use Namespace-based Multi-Tenancy. It addresses
weaknesses that break Namespace-based isolation that not well studied, yet. We
found this issues during our research and presented them together with this
methodology in our
Talk at KubeCon + CloudNativeCon Europe 2026.
The methodology assumes that industry best practices, such as NetworkPolicies,
Role-Based Access Control (RBAC), and Pod Security Standards, are already in
place. These measures provide a necessary baseline level of protection against
well-known isolation threats. However, they are insufficient to address a class
of more subtle attack vectors arising from interactions between tenants and
shared components. Such attack vectors may still compromise the confidentiality,
integrity, and availability (CIA) of the cluster and its workloads, even in
well-hardened environments.
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.