Blog Posts on MOGWAI LABS

Melde- und Offenlegungspflichten im Cyber Resilience Act

Thu, 22 Jan 2026 17:00:35 +0200

TL;DR: Ab dem 11. September 2026 verpflichtet der Cyber Resilience Act Hersteller dazu, ausgenutzte Schwachstellen und schwerwiegende Vorfälle über eine zentrale Meldeplattform an die ENISA zu melden. Die Meldefristen sind knapp bemessen, daher müssen Hersteller ihre Prozesse zum Umgang mit Schwachstellen und Vorfällen entsprechend verbessern. Außerdem sollten sie sich mit dem CSAF-Standard vertraut machen, da dieser wahrscheinlich zum primären Format für die Meldung von Schwachstellen an die ENISA werden wird.

Ist das up2date?

Tue, 16 Sep 2025 17:00:35 +0200

In den letzten Wochen musste ich mehrfach erklären, warum man sich nicht auf Versionsnummern in HTTP-Headern verlassen kann, um den Patch-Level eines Systems zu bestimmen. Ich ging davon aus, dass dies allgemein bekannt ist – aber jeden Tag wird jemand geboren, der noch nie „die Feuersteins“ gesehen hat.

Dieser Beitrag verwendet Ubuntu als Beispiel, aber das Prinzip gilt für alle Linux-Distributionen, die Long Term Support (LTS)-Versionen anbieten. Der Fokus liegt hier auf dem Patchen; auf weitere Faktoren, die darüber entscheiden können, ob ein System verwundbar ist (zum Beispel eine bestimmte Konfiguration), wird nicht eingegangen.

c3p0, du kleiner Schlingel

Fri, 28 Feb 2025 09:40:35 +0200

Seit der Einführung des Java Module System in Java 16 sind Deserialisierungs-Gadget-Chains, die das direkte Ausführen von Remote-Code ermöglichen, immer seltener geworden. Eine nennenswerte Ausnahme ist das Gadget aus der JDBC-Verbindungspool-Bibliothek c3p0.

c3p0 (zusammen mit der Dependency mchange-commons-java) bietet mehrere Funktionen, die bei der Ausnutzung von Schwachstellen von Java-Anwendungen nützlich sein können. Die beste Primitive ist Möglichkeit, eigenen Code per Remote Class Loading zu laden und auszuführen. c3p0 ist jedoch in vielen Deserialisierungsscannern nicht enthalten, vermutlich weil die Verwendung nicht so einfach wie bei anderen Gadgets ist.

JNDI Mind Tricks

Wed, 18 Dec 2024 13:56:00 +0100

Injection-Angriffe, die über das Java Naming and Directory Interface (JNDI) ausgeführt werden können, sind seit Jahren bekannt. Die meisten Sicherheitsexperten kamen mit JNDI in Kontakt, als sie sich mit der berüchtigten Log4Shell-Schwachstelle befassen mussten. Diese basiert drauf, die log4j-Bibliothek dazu zu bringen, einen JNDI-Aufruf an ein vom Angreifer kontrolliertes System zu senden.

Im Laufe der Jahre war der Missbrauch von JNDI ein wichtiger Bestandteil des Java-Exploit-Toolkits. Dies gilt umso mehr, nachdem die üblichen Deserialisierungs-Angriffspunkte in Java 16/17 entfernt wurden (siehe JEP 396).

Schwachstellenanalyse: CVE-2023-0264

Wed, 19 Apr 2023 12:45:00 +0200

Keycloak is an open source identity and access management solution […] [to] secure services with minimum effort

Bei Keycloak handelt es sich um einen verbreiteten Authentifizierungsserver, der von vielen unserer Kunden verwendet wird. Als Teil unserer Arbeit analysieren wir regelmäßig aktuelle Meldungen zu Schwachstellen, um unseren Kunden notfalls auf wichtige Sicherheitsupdates hinweisen zu können. Im Zuge dessen schauten wir uns auch die Keycloak-Schwachstelle CVE-2023-0265 (CVSS Bewertung8.3) im Detail an.

In diesem Blogpost analysieren wir diese Schwachstelle, die (unter bestimmten Voraussetzungen) die Impersonierung eines anderen Keycloak-Benutzers erlaubt. Im Internet finden sich hierzu nur sehr wenige Informationen, wir wollen daher die Schwachstellen-ursache analysieren und die Ausnutzung an einer ungepatchte Keycloak Instanz demonstrieren.

Schau mal Mama, kein TemplatesImpl

Tue, 11 Apr 2023 17:00:35 +0200

Eine Reihe von Änderungen in Java 16 macht das erfolgreiche Exploiten von Deserialisierungsschwachstellen deutlich schwerer. Dieses Post bietet eine Übersicht über die Hintergründe und liefert ein paar Ideen wie Angreifer dennoch in der Lage sein können ein System erfolgreich zu kompromittieren.

Projekt Jigsaw und das Java Modul-System

Um das Grundproblem zu verstehen, müssen wir uns zunächst ein wenig mit dem Java Modul-System sowie Java-Reflection befassen. Wir erklären hier nur die für das Verständnis notwendigen Grundlagen, eine detaillierte Erklärung findet sich im Java Magazine.

Kompromittierung Laravel-basierender Applikationen durch geleakte APP_KEYS

Fri, 26 Aug 2022 06:40:35 +0200

Laravel ist ein gängiges Framework zum Erstellen von PHP basierten Webanwendungen. Es erlaubt eine recht einfache Erstellung von komplexen Webapplikationen und dient daher als Grundlage vieler populärer Projekte.

Bei einem kürzlich durchgeführten Penetrationstest einer solchen Applikation waren wir in der Lage die “Environment-Datei” der Anwendung auszulesen. Diese Datei beinhaltet mehrere, zum Teil sensible Konfigurationseinstellungen, insbesondere des APP_KEY .

Dieser APP_KEY wird von mehreren, sicherheitsrelevanten Funktionen verwendet, beispielsweise zur Signatur von Objekten um diese vor einer möglichen Manipulation zu schützen. In der Vergangenheit war die Kompromittierung des APP_KEYS ein zuverlässiger Weg um eigenen Code auf dem System ausführen zu können, da hiermit auch XSRF Tokens wurden der Applikation signiert verwendet wurde. Angreifer mit Zugriff auf den APP_KEY waren in diesem Fall in Lage einen beliebige PHP Objekte zu signieren, was wiederum das Ausführen von eigenem Code per Deserialisierung über eine bekannte Gagetchain erlaubt (CVE-2018-15133).

Schwachstellenanalyse: RCE in Ajax.NET Professional

Tue, 18 Jan 2022 12:30:35 +0000

Im Herbst 2021 führte MOGWAI LABS einen Penetrationstest für einen Kunden durch. Dabei stieß unser Team auf eine Anwendung, die das Framework “Ajax.NET Professional” verwendete. Bei einer kurzen Analyse des Framworks-Quellcodes fanden wir eine Deserialisierungsschwachstelle, welche wir an den Entwickler meldeten (CVE-2021-23758).

Dieser Blog-Beitrag enthält auch Findings von Markus Wulftange (Code White GmbH), der die Bibliothek im Rahmen eines anderen Projekt analysierte und uns in einer Diskussion auf einige weitere Schwachstellen aufmerksam machte.

Schwachstellenanalyse: Log4Shell

Fri, 10 Dec 2021 06:40:35 +0200

“Log4Shell” (CVE-2021-44228) ist eine kritische Sicherheitslücke in der Java-Loggingbibliothek “Log4j”. Dieser Blog-Beitrag enthält (hoffentlich) alles, was man über diese Schwachstelle wissen muss und wie sie behen kann. Aufgrund des Zeitaufwands wurde er in Eile geschrieben, wir werden vorraussichtlich in den nächsten Tagen weitere Details und Anmerkungen hinzufügen.

Einführung

Log4j ist ein in der Java-Welt gängiges Framework zum Erstellen von Logdateien. Log4j tut, was man von einer solchenBibliothek erwartet, ist schnell und lässt sich gut in bestehende Java Applikationsserver integrieren. Hier ein einfaches Beispiel, das aus den übergebenen Benutzereingaben einen Logeintrag erstellt.

Schwachstellensuche mit CodeQL

Mon, 13 Sep 2021 14:15:35 +0200

Einleitung

CodeQL ist ein semantisches Code-Analyse-Tool von GitHub, welches zur Schwachstellensuche in verschiedenen Sprachen verwendet werden kann. CodeQL erlaubt es Code abzufragen als wären es Daten. Es hilft dabei, unsichere Codepatterns zu beschreiben und in weiteren Programmen zu finden. Besonders beeindruckend ist die Fähigkeit, Programmflüsse von einer Quelle (Source) zu einer Senke (Sink) nachzuverfolgen, selbst wenn beispielsweise Variablen mehrfach neu zugewiesen oder geändert werden. In den letzten zwei Jahren wurden diverse Blogbeiträge und Schwachstellenanalysen veröffentlicht, die eindrucksvoll die Leistungsfähigkeit dieses Ansatzes demonstrieren.

Ausnutzung von ungesicherten RCCMD-Installationen

Fri, 18 Jun 2021 07:00:35 +0200

Generex RCCMD (Remote Control Command) ist eine Software, die es der USV (unterbrechungsfreie Stromversorgung) erlaubt kritische Systeme rechtzeitig herunterzufahren, bevor der Strom ausgeht. RCCMD erfreut sich in Deutschland vor allem in kleinen und mittelständischen Unternehmen recht großer Beliebtheit. In den letzten Jahren hat MOGWAI LABS bei Penetrationstests mehrere unsicher konfigurierte RCCMDMInstallationen ausgenutzt um Systeme (inklusive Domain Controller) unserer Kunden zu kompromittieren.

RCCMD Übersicht

Eine typische Installation besteht normalerweise aus einem USV-Überwachungssystem (UPSMON) und mehreren “Client”-Systemen, auf denen der RCCMD-Dienst installiert ist. Wir werden uns hier auf den RCCMD-Dienst konzentrieren.

An Trinhs RMI Registry Filter Bypass

Sat, 08 Feb 2020 05:40:35 +0200

TL:DR: Dieser Blogeintrag analysiert das Gadget zum Umgehen des RMI Registry Filters, welches von An Trinh (@_tint0) gefunden wurde. Er behandelt einige grundlegende Konzepte, die bei der Erstellung von Deserialisierungs-Gadgets häufig verwendet werden. Mit Hilfe dieses Gadgets ist es möglich, Deserialisierungsschwachstellen in der RMI-Registry auszunutzen, selbst wenn auf dem Ziel eine aktuelle Java/OpenJDK-Version läuft.

Update: Die Schwachstelle wurde von Oracle in JDK8u241, welches am 14. Januar 2020 veröffentlicht wurde, behoben. Danke an MR_ME für den Hinweis.

Per Linux SNMP zu Remote Code Execution (RCE)

Wed, 30 Oct 2019 17:00:35 +0200

TL:DR: Wenn Angreifer über einen SNMP-Community mit Write-Berechtigungen für ein Linux-Ziel zugreifen können ist über die NET-SNMP-EXTEND-MIB-Erweiterung das Ausführen von eigenem Code möglich. Der SNMP-Diest läuft mit root Rechten, weshalb dies auch zur Erhöhung von lokalen Rechten genutzt werden kann.

Wir haben diese Funktion kürzlich bei einem Assessment verwendet, um uns Root-Rechte auf einem Zielsystem zu verschaffen. Das verwendete Linux-System wurde zuvor bereits mehrfach analysiert, weshalb wir annehmen, dass dieser Angriffsvektor bei anderen Penetrationstestern nicht so bekannt ist.

Angriffe auf RMI basierende JMX Dienste

Sun, 28 Apr 2019 06:40:35 +0200

TL:DR: In einem vorherigen Post haben wir verschiedene Möglichkeiten (primär Java-Deserialisierung) zur Kompromittierung von Java RMI Diensten erklärt. Während RMI wird nicht länger bei der Entwicklung neuer Anwendungen zum Einsatz kommt ist es nach wie vor zum Monitoring von Applikationen per JMX verwendet. Angriffe gegen JMX Dienste sind seit vielen Jahren bekannt, dennoch finden wir regelmäßig unsichere/kompromittierbare JMX Dineste in Penetrationstests.

Dieses Post gibt zunächst eine allgemeine Einführung zu JMX und beschreibt dann die bekannten Angriffstechniken. Zudem schauen wir uns an wie JMX Dienste per Java-Deserialisierung kompromittiert werden können.

Angriffe auf RMI Dienste nach JEP 290

Mon, 25 Mar 2019 06:40:35 +0200

TL:DR: Die Einführung von JEP 290 blockiert die Verwendung der bekannten RMI Exploits in ysoserial. Solange kein globaler Deserialisierungsfilter konfiguriert wurde ist es jedoch nach wie vor möglich entsprechende Schwachstellen auf Applikationsebene auszunutzen. Dieser Post zeigt wie Argumente für diese Methodenaufrufe zur Laufzeit (unter Verwendung des automatisierbaren Debuggers “youdebug”) ausgetauscht werden können.

Da Java RMI (Remote Method Invocation) auf Java Serialisierung basiert wurden entsprechende RMI Dienste zu einem der primären Ziele der “Java Deserialisierungs Appocalypse”. Dies hat sich durch die Einführung von JEP 290 in aktuellen JDK Releases geändert. Dieser Post beschreibt die entsprechenden Änderungen und wie es nach wie vor möglich ist, entsprechende Deserialisierungsschwachstellen auf Applikationsebene auszunutzen.

Modifikation von iOS Apps

Sat, 02 Mar 2019 09:40:35 +0200

TL:DR: Es ist per Cydia Impactor möglich, eine manipulierte iOS-Apps neu zu signieren. Das ist wesentlich einfacher als per XCode oder dem Codesign-Tool.

Vor kurzem mussten wir im Rahmen eines Penetrationstests eine iOS-App für einen Kunden analysieren. Wie viele Geschäftsanwendungen haben die Entwickler eine Reihe zusätzlicher Schutzmechanismen implementiert, darunter eine Jailbreak-Erkennung sowie Zertifikatspinning. In diesen Fällen verwenden wir in der Regel ein Framework wie Frida, um diese Schutzmechanismen zu umgehen und besser mit der Anwendung interagieren sowie die Kommunikation mit dem serverseitigen Backend abfangen können.

jarjarbigs

Wed, 31 Oct 2018 20:40:35 +0000

Wenn es um die Analyse von Closed-Source-Java-Anwendungen geht, starten die meisten Forscher schnell einen Decompiler wie JD-GUI und beginnen mit der Analyse. Diese Tools sind gut, erlauben aber nur eine statische Analyse. Bei komplexem Code ist es oft sinnvoller, einen Debugger zu verwenden und die Anwendung während der Laufzeit zu analysieren.

Anders als dnspy (ein Decompiler für .NET-Anwendungen) bietet JD-GUI selbst keine Debugging-Funktionen. Es ist jedoch möglich, IDEs wie Intellij oder Eclipse mit einem Decompiler-Plugin zu erweitern.

Schwachstellenanalyse: CVE-2016-5072

Fri, 13 Jul 2018 09:40:35 +0200

Vor kurzem suchte ich nach bekannten Schwachstellen in der OpenSource Shopsoftware “OXID esShop” die sich in Deutschland großer Beliebtheit erfreut. Dabei weckte eine der dort gelisteten Schwachstellen OXID Security Bulletin 2016-001 (CVE-2016-5072), mein Interesse, primär wegen dem als “hoch” eingestuften Schadenspotenzials. Von der Schwachstellenbeschreibung des Herstellers:

An attacker can gain full administrative access to OXID eShop. This includes all shopping cart options, customer data and the database. They also can execute PHP code or inject malicious code into the system and the shop’s storefront. No interaction between the attacker and the victim is necessary.

Statischer JWT Key in dotCMS

Mon, 02 Jul 2018 09:40:35 +0200

Wir haben uns kürzlich dotCMS angesehen, ein in Java geschriebenes Open-Source Content Management System (CMS). Bei der Analyse des CMS-Quellcodes auf potenzielle Deserialisierungs-Schwachstellen stolperten wir über den folgenden Code:

@Override
public Key getKey() {
 final String hashKey = Config
 .getStringProperty(
 "json.web.token.hash.signing.key",
 "rO0ABXNyABRqYXZhLnNlY3VyaXR5LktleVJlcL35T7OImqVDAgAETAAJYWxnb3JpdGhtdAASTGphdmEvbGFuZy9TdHJpbmc7WwAHZW5jb2RlZHQAAltCTAAGZm9ybWF0cQB+AAFMAAR0eXBldAAbTGphdmEvc2VjdXJpdHkvS2V5UmVwJFR5cGU7eHB0AANERVN1cgACW0Ks8xf4BghU4AIAAHhwAAAACBksSlj3ReywdAADUkFXfnIAGWphdmEuc2VjdXJpdHkuS2V5UmVwJFR5cGUAAAAAAAAAABIAAHhyAA5qYXZhLmxhbmcuRW51bQAAAAAAAAAAEgAAeHB0AAZTRUNSRVQ=");
 return (Key) Base64.stringToObject(hashKey);
}

Da der Schlüssel während der dotCMS-Installation nicht geändert/regeneriert wird, verwendet jede Standardinstallation von dotCMS denselben Schlüssel, um Json Web Tokens (JWT) zu signieren. Dies machte uns stutzig, da JWTs in der Regel für die Benutzerauthentifizierung verwendet werden. Beim lsen der in der Dokumentation vorhanden “Security Best-Practices” stellten wir fest, dass das dotCMS-Team ebenfalls empfiehlt, diesen Schlüssel in Produktionsumgebungen zu ändern.

CANAPE Workshop Folien

Fri, 22 Jun 2018 09:40:35 +0200

Im April 2018 haben wir auf der BSides München zum ersten Mal unseren kostenlosen CANAPE-Workshop angeboten. CANAPE ist ein Tool, mit dem sich binäre Netzwerkprotokolle analysieren lassen,welche auch heute noch sehr verbreitet sind. CANAPE ist hier einmalig, da es das bekannte Paradigma des Testens von Webanwendungen auf beliebige Netzwerkprotokolle anwendet.

Dieser praxisorientierte Workshop basiert auf dem Workshop-Material von James Foreshaw (dem Autor von CANAPE) und beinhaltet einen kompletten Überblick über die wichtigsten CANAPE-Funktionen. Die Folien sind sehr detailliert, da wir versuchten, eine Art “fehlendes Handbuch” für dieses großartige Tool zu erstellen.