Copy Fail, Dirty Frag, Dirty Pipe – Warum SELinux Ihr bester Schutz gegen Local Privilege Escalation ist

Copy Fail, Dirty Frag, Dirty Pipe: Unterschiedliche Exploits mit dem gleichen Ziel: Local Privilege Escalation (LPE). Diese Klasse von Verwundbarkeiten ist häufig anzutreffen. Wenngleich sie nicht so problematisch wie Remote Code Execution (RCE)-Schwachstellen sind, ermöglichen sie Angreifenden durch die Erhöhung der Rechte weitere Möglichkeiten zur Ausbreitung und zur Ausführung von Schadsoftware. Daraus lassen sich nun, je nach Bedarf, unterschiedliche Blickwinkel betrachten. Wir könnten technisch auf die Verwundbarkeiten eingehen und sie beschreiben. Auch spannend ist die Methodik der Sicherheitsforschenden, und ob und wie „künstliche Intelligenz“ dafür eingesetzt wurde. Oder wir könnten Unterschiede zu anderen Schwachstellen dieser Art hervorheben.

Aber in diesem Digest (und in unserer täglichen Arbeit) sind wir pragmatischer und stellen uns die Frage: Wie geht man mit diesen Schwachstellen um? Die Ausnutzung von Schwachstellen ist – außer bei bewusst implementierten Backdoors – auf die Existenz von Defekten angewiesen, sogenannten Bugs. Die Sicherheit eines Systems ist daher darauf angewiesen, dass alle Bestandteile von Hardwarelogik bis Applikation „korrekt“ funktionieren. Eine Möglichkeit, Fehler aufzufangen, ist die Verwendung von Mandatory Access Control (MAC) in Form der SELinux-Erweiterung. Dadurch können Policies festgelegt werden, die den Zugriff auf Dateien und Systemkomponenten festlegen. In dieser Konstellation reicht dann die Korrektheit der eingestellten Policies (und der SELinux-Implementierung), um einen sicheren Betrieb des Systems zu ermöglichen. Ein praktisches Beispiel bietet ein Blick auf Mobil-Betriebssysteme. GrapheneOS hat dazu einige erläuternde Hinweise.

Aus unserer Sicht unterstützen die Lücken unsere in einem vorherigen Digest formulierte Erwartung, dass sich das Security-Modell im Desktop- und Serverbereich sukzessive an das aus dem Mobilbereich anpassen wird. Auch wenn das Thema SELinux eher in den Aufgabenbereich der eingesetzten Distribution fällt, können Sie durch kleine Konfigurationen viel Angriffsoberfläche reduzieren. Sprechen Sie uns gerne an, wenn wir Sie dabei unterstützen können.

https://discuss.grapheneos.org/d/35110-grapheneos-is-protected-against-copy-fail-and-similar-vulnerabilities-by-selinux

https://en.wikipedia.org/wiki/SELinux

https://copy.fail

https://github.com/V4bel/dirtyfrag

https://infosec.exchange/@jrt/116537982697417546

Weitere News im Mai

Keine Publikation ohne AI

Gespannt kann man verfolgen, wie Daniel Stenberg (@bagder@mastodon.social) und das Open-Source-Projekt curl die Interaktion von KI-gestützten Werkzeugen mit Open-Source-Projekten erleben. Nach einer Welle von AI „Slop“, also KI-generierten Bugmeldungen ohne substanziellen Gehalt, welche zum temporären Schließen des Bug-Bounty-Programms führte, verzeichnet curl nun viele qualitativ hochwertige Meldungen. Im gleichen Post weist Daniel Stenberg aber auch darauf hin, dass dies ebenfalls eine höhere Last für Maintainer darstellt. Nutzen Sie dies doch als Motivation, in von Ihnen genutzten Projekten mitzuwirken oder finanziell zu unterstützen, um diese Belastung aufzufangen und die Möglichkeiten zur Verbesserung der Lösungen nutzbar zu machen.

Mythos, die von Anthropic hochgepriesene KI-basierte Exploit-Maschine, überzeugte beim Einsatz für curl weniger, vermutlich weil vorher verfügbare Werkzeuge schon viele Schwachstellen finden konnten. Für Entwickelnde und Interessierte eine empfehlenswerte Lektüre.

DE-Zone für DNSSEC nicht verfügbar

Am 05.05. kam es zu einem kurzzeitigen Ausfall innerhalb der DE-Zone (im DNS-Jargon sind damit die „.de“-Domains gemeint) aufgrund eines Konfigurationsfehlers beim Signieren. Blackfort-tec hat eine gute Zusammenfassung, und auch DENIC hat derweil ein Post-Mortem veröffentlicht. Eine schöne Erinnerung, welche Abhängigkeiten in unserer zentralisierten Infrastruktur bestehen. Frohes Threat-Modelling!

https://blackfort-tec.de/insights/dnssec-denic-servfail-nsec3-fehler-de-zone

https://blog.denic.de/analyse-des-dns-ausfalls-vom-5-mai-2026

Android Intrusion Logging: Mehr Visibility in der Mobile-Vorfallsbehandlung

Alle Jahre wieder spendiert Google seinem Betriebssystem eine neue Version. Mit den jährlichen Versionssprüngen kommen auch regelmäßig neue Security- und Privatsphäre-Funktionen hinzu.

Neben verbesserter Betrugserkennung bei Anrufen erweitert Google in diesem Jahr Androids Advanced Protection Mode (AAPM), vergleichbar mit Apples Lockdown Mode, um neue Funktionen für die forensische Analyse von Mobilgeräten. Historisch sind die Logdaten von Androiden nicht für die forensische Analyse entwickelt, sondern für das Beheben von Fehlern. Diese Zweckentfremdung hat einige Nachteile. Logs sind im Regelfall nicht manipulationssicher, und möglicherweise relevante Ereignisse aus Forensikperspektive werden nicht geloggt, wenn sie für die Fehlerbehandlung nicht wichtig sind. Mit Android Intrusion Logging schafft Android eine neue Datenquelle für die Analyse von Mobilgeräten. Wir empfehlen besonders exponierten Personen und Organisationen mit erhöhtem Schutzbedarf die Aktivierung des Android Advanced Protction Mode (AAPM). Organisationen können über den DevicePolicyManager das Logging ebenfalls aktivieren und an eine Applikation delegieren.

https://blog.google/security/whats-new-in-android-security-privacy-2026

https://security.googleblog.com/2025/05/advanced-protection-mobile-devices.html

https://developer.android.com/reference/android/app/admin/DevicePolicyManager#DELEGATION_SECURITY_LOGGING

Vom Pentester zum Red Teamer: Wie wir neue Mitarbeitende fit machen

Der Schritt vom Pentester zum Red Teamer klingt nach einer logischen Weiterentwicklung. In der Praxis zeigt sich jedoch schnell, dass es kein gradueller Ausbau bestehender Fähigkeiten ist, sondern ein echter Perspektivwechsel. In diesem Artikel beschreiben wir, wie wir neue Mitarbeitende auf genau diesen Wechsel vorbereiten – und was dabei wirklich den Unterschied macht.

Der häufigste Irrtum

Mitarbeitende, die sich für das Red-Teaming-Thema interessieren, kommen häufig aus dem Infrastruktur- oder Active-Directory-Pentesting und gehen davon aus, dass der Schritt hinüber ins Red Teaming ein kleiner sein wird.

In der Praxis zeigt sich jedoch schnell: Red Teaming ist kein erweiterter Penetrationstest, sondern ein anderer Ansatz.

Während klassische Penetrationstests darauf abzielen, möglichst viele Schwachstellen in einem begrenzten Zeitfenster zu identifizieren, geht ein Red-Team-Assessment deutlich weiter. Es kombiniert technische Angriffe, physische Zutrittsversuche und Social Engineering, um die Wirksamkeit technischer, organisatorischer und menschlicher Abwehrmaßnahmen ganzheitlich zu überprüfen.

Im Fokus steht dabei nicht primär das schnelle Finden von Schwachstellen, sondern das möglichst realitätsnahe Emulieren eines Angreifers. Dazu gehört es auch, über längere Zeiträume unentdeckt zu bleiben, um tatsächliche Angriffsverläufe und Reaktionsfähigkeiten unter realen Bedingungen bewerten zu können.

Dieses Ziel erfordert ein anderes Mindset, angepasste Herangehensweisen und die Fähigkeit, das eigene Vorgehen kontinuierlich zu hinterfragen und weiterzuentwickeln.

Erfahrung im Infrastruktur-Penetrationstest ist aus unserer Sicht dabei aber eine sehr gute Basis.

Insbesondere sollten neue Red Teamer gängige Active-Directory-Angriffe sicher beherrschen, typische Fehlkonfigurationen erkennen und ein solides Verständnis für etablierte Tools und Techniken mitbringen. Ohne dieses Fundament wird Red-Teaming schnell zu blindem Tool-Einsatz.

Die entscheidenden Unterschiede: Mindset und OPSEC

Die größten Unterschiede liegt nicht primär in den verwendeten Tools, sondern im Mindset und Herangehensweise.

Ein Red Teamer muss kontinuierlich reflektieren, welche Spuren das eigene Handeln hinterlässt und wie ein Verteidiger darauf reagieren könnte. Jede Aktion sollte bewusst hinterfragt werden, insbesondere im Hinblick auf ihre Sichtbarkeit.

Operational Security (OPSEC) wird damit zu einem zentralen Element. Es geht nicht primär darum, ein Ziel möglichst schnell zu erreichen, sondern ein realistisches Angriffsszenario abzubilden. In der Praxis bedeutet das häufig, bewusst auf den vermeintlich einfacheren oder direkteren Weg zu verzichten und stattdessen einen Ansatz zu wählen, der besser zur angenommenen Angreiferperspektive passt.

Dieses Umdenken erfordert Zeit und entsteht nicht allein durch Theorie oder Zertifizierungen, sondern vor allem durch praktische Erfahrung.

Kontinuierliches Lernen als Grundvoraussetzung

Red Teaming ist ein Bereich mit kurzer Halbwertszeit. Erkennungsmechanismen entwickeln sich stetig weiter und Standard-Tools werden zunehmend zuverlässig erkannt.

Wer sich nicht kontinuierlich weiterbildet, wird zwangsläufig sichtbar.

Deshalb ist aus unserer Sicht die Lernbereitschaft einer der wichtigsten Faktoren. Eigenständiges Einarbeiten in neue Themen, das Verfolgen aktueller Entwicklungen und ein generelles Interesse an der Materie sind entscheidend.

Diese Eigenschaft ist im Red Teaming oft wichtiger als im klassischen Penetrationstest, da sich die Anforderungen deutlich schneller verändern und die Konsequenzen von Erkennung eine andere Tragweite haben. Während in klassischen Penetrationstest auch ältere Tools oder bekannte Techniken häufig weiterhin zuverlässig funktionieren und eine Erkennung für das Ergebnis meist weniger kritisch ist, kann im Red Teaming eine Entdeckung das gesamte Szenario beeinflussen oder vorzeitig beenden.

Sinnvolle Zertifizierungen und Trainings

Zertifizierungen können beim Einstieg helfen, sollten aber nicht als Selbstzweck verstanden werden.

Als besonders praxisnah haben sich die Trainings von ZeroPoint Security erwiesen. Insbesondere der CRTO (Certified Red Team Operator) und CRTL (Certified Red Team Lead) vermitteln ein gutes Grundverständnis für Red-Team-Operationen, Operational Security und strukturierte Vorgehensweisen.

Sie eignen sich daher gut, um ein erstes Gefühl für die Denkweise im Red-Teaming zu entwickeln.

Ergänzend können weitere Trainings sinnvoll sein (beispielweise „wie baue ich eine sichere Red Team Infrastruktur auf“, „wie entwickle ich eigene Malware“ oder Weiterbildungen im Bereich Social Engineering oder physische Pentests), wobei der Fokus weniger auf der Menge an Zertifikaten liegen sollte, sondern auf deren inhaltlichem Mehrwert und darauf abgestimmt sein sollte, welche Skills im Team noch fehlen.

Programmierkenntnisse als Multiplikator

Ein oft unterschätzter Aspekt im Red Teaming ist die Fähigkeit, Code zu verstehen und anzupassen.

Kenntnisse in Programmiersprachen wie C sind besonders hilfreich, um bestehende Tools zu modifizieren und deren Erkennung zu erschweren. Viele Sicherheitslösungen arbeiten unter anderem mit statischen Signaturen, die sich durch kleinere Anpassungen im Code umgehen lassen.

Wer in der Lage ist, Werkzeuge selbst anzupassen oder neue Artefakte zu entwickeln, erweitert seine Möglichkeiten erheblich und reduziert die Abhängigkeit von bekannten Tools.

Dies ist häufig ein entscheidender Unterschied zwischen reinem Tool-Einsatz und einem tieferen technischen Verständnis.

Lernen durch Fehler: Der Moment, der alles verändert

Ein Aspekt, der in der Ausbildung von Red Teamern oft unterschätzt wird, ist der Umgang mit Fehlern.

Früher oder später wird es passieren, dass eine Aktion unmittelbar zur Erkennung führt. Dieser Moment ist unangenehm, aber gleichzeitig äußerst lehrreich.

Er zwingt dazu, das eigene Vorgehen kritisch zu hinterfragen und verändert nachhaltig die eigene Perspektive auf Angriffe und deren mögliche Erkennungsmechanismen.

Statt nur zu überlegen, ob eine Technik funktioniert, rücken andere Fragen in den Vordergrund: Warum wird dieser Befehl ausgeführt? Woran könnte ein Verteidiger diese Aktivität erkennen? Welche Telemetrie entsteht dabei? Wie hoch ist das Risiko und ist es vertretbar?

Genau diese Überlegungen sind zentral für das Red-Teaming. Fehler sind dabei kein Rückschritt, sondern ein notwendiger Teil des Lernprozesses.

Aus unserer Erfahrung sind es häufig genau diese Situationen, in denen sich das notwendige Mindset nachhaltig entwickelt.

Fazit

Der Weg vom Penetrationstest zum Red Teaming ist kein reiner Ausbau bestehender Fähigkeiten, sondern erfordert ein Umdenken.

Eine solide technische Grundlage, insbesondere im Bereich Active Directory, bleibt essenziell. Gleichzeitig gewinnen Themen wie Operational Security, kontinuierliches Lernen und technisches Tiefenverständnis deutlich an Bedeutung.

Zertifizierungen können dabei unterstützen, ersetzen jedoch nicht die praktische Erfahrung und die Bereitschaft, sich stetig weiterzuentwickeln.

Entscheidend ist letztlich die Fähigkeit, das eigene Handeln kritisch zu reflektieren und sich kontinuierlich an veränderte Rahmenbedingungen anzupassen.