Laboratoire de recherche CVE-2025-53770

Ce dépôt semble être un projet de recherche de preuve de concept pour valider un problème de désérialisation et de traitement de volet d’outils de type SharePoint dans un laboratoire contrôlé. Il comprend un pilote Python, une application vulnérable simulée et des ressources conteneurisées pour des tests isolés.

[!WARNING] Ce projet ne doit être utilisé que sur des systèmes, conteneurs ou réseaux que vous possédez ou pour lesquels vous êtes explicitement autorisé à effectuer des tests. N’exécutez pas ce code contre une infrastructure publique, des services tiers, des environnements de production ou toute cible sans autorisation écrite. Les tests de sécurité non autorisés peuvent violer la loi, un contrat, une politique ou des conditions d’utilisation.

Le contenu de ce dépôt doit être considéré comme un matériel de recherche sensible en matière de sécurité. Si vous utilisez ce projet dans le cadre d’un travail d’évaluation, gardez l’exécution isolée, enregistrez toute activité et coordonnez-vous avec le propriétaire du système avant de tester.

Périmètre du projet

Le dépôt contient actuellement :

• sploit.py : pilote asynchrone Python qui envoie des requêtes conçues à un point de terminaison ToolPane.
• lab/mock_vulnerable_app.cs : application ASP.NET simulée qui renvoie un marqueur de validation et, dans sa forme actuelle, peut exécuter une commande fournie à l’intérieur du conteneur du laboratoire.
• lab/docker-compose.yml : laboratoire local à deux conteneurs qui sépare la cible simulée du terminal de l’attaquant.
• lab/Dockerfile : construction .NET multi-étapes qui publie l’application vulnérable simulée dans une image d’exécution ASP.NET plus petite et l’exécute en tant qu’utilisateur non-root.
• lab/attacker.Dockerfile : définition du conteneur attaquant Python qui préinstalle l’ensemble des dépendances de script nécessaires pour le terminal du laboratoire.
• lab/vulnerable.csproj : fichier de projet web .NET 6 pour l’application vulnérable simulée.
• lab/genGadget.py : script auxiliaire pour générer une charge utile Base64 compressée pour les tests de désérialisation réservés au laboratoire.

Configuration et utilisation

Ce workflow est destiné uniquement au laboratoire local.

Prérequis :

• Moteur Docker avec prise en charge de Compose
• Un interpréteur local avec l’autorisation d’exécuter des commandes Docker

Démarrez le laboratoire depuis le répertoire lab/ :

cd lab
docker-compose up --build -d

Si votre configuration Docker nécessite des privilèges élevés, exécutez les mêmes commandes avec sudo.

Confirmez que les deux conteneurs sont en cours d’exécution :

docker-compose ps

Journalisation en cas de problème ou de validation d’exploit :

docker logs sp_attacker
docker logs sp_vulnerable_lab

Le laboratoire est intentionnellement isolé :

• le conteneur cible s’exécute sur le réseau interne lab_net ;
• aucun port n’est publié vers l’hôte ;
• le conteneur attaquant est fourni comme terminal jetable dans le même réseau privé.

Ouvrez un interpréteur dans le conteneur attaquant :

docker exec -it sp_attacker bash

Depuis l’intérieur du conteneur attaquant, vous pouvez effectuer des vérifications sans danger pour le laboratoire, telles que confirmer que la cible est joignable et tester le script en mode de vérification contre la cible simulée :

python3 sploit.py http://sp_vulnerable_lab/
# Si la résolution DNS du nom de service échoue dans votre environnement, utilisez l’IP du laboratoire :
# python3 sploit.py http://10.10.10.5
# Si vous souhaitez aller au-delà de la validation de base, vous pouvez inclure les commandes souhaitées.
python3 sploit.py http://sp_vulnerable_lab whoami

Comportement attendu dans l’environnement simulé local :

• la cible doit être joignable en tant que http://sharepoint-target depuis le conteneur attaquant ;
• l’application simulée renvoie un marqueur déterministe pour la vérification ;
• les artefacts de résultat produits par le script restent à l’intérieur de l’espace de travail monté du laboratoire.

Notes opérationnelles :

• gardez le laboratoire déconnecté des réseaux externes et ne publiez pas le service cible vers l’hôte ;
• ne réutilisez pas cet environnement pour une évaluation en production ;
• si vous modifiez l’application simulée ou les définitions de conteneur, reconstruisez les images avant de retester.

Nettoyage

Arrêtez et supprimez les conteneurs et le réseau du laboratoire :

cd lab
docker-compose down

Si vous souhaitez également supprimer les images construites :

docker-compose down --rmi local

Si vous souhaitez une réinitialisation complète des artefacts de l’espace de travail du laboratoire, supprimez tous les fichiers de résultat générés après l’arrêt :

rm -f vuln.lst

Pratique de nettoyage recommandée après chaque exercice :

1. arrêter le laboratoire avec docker-compose down ;
2. supprimer les artefacts de résultat qui ne doivent pas persister ;
3. reconstruire le laboratoire avant l’exécution suivante si vous avez modifié le code, les dépendances ou les paramètres du conteneur.

Résumé de validation

Le projet est structurellement valide en tant que laboratoire de recherche local, mais il ne doit pas être traité comme un validateur sûr en production dans sa forme actuelle.

Ce qui fonctionne :

• La topologie du laboratoire est simple et reproductible.
• Le pilote Python peut tester une cible ou une liste de cibles.
• L’application simulée fournit des indicateurs de succès déterministes pour la vérification en laboratoire.

Ce qui nécessite de la prudence :

• Le script principal inclut un comportement explicite d’exécution de commande lorsqu’un second argument est fourni.
• La vérification TLS est désactivée dans les requêtes sortantes.
• Les résultats positifs sont écrits dans vuln.lst, ce qui peut créer des données sensibles résiduelles inutiles.
• L’application simulée exécute directement l’entrée de l’interpréteur et ne doit jamais être exposée en dehors d’un laboratoire isolé.

Méthodologie

Utilisez ce projet uniquement pour une validation contrôlée de la détection et de l’exposition, et non pour une exploitation opérationnelle.

Méthodologie recommandée :

1. Construire un environnement de laboratoire isolé sans exposition externe.
2. Valider les limites du réseau afin que seul le chercheur puisse atteindre le service simulé.
3. Exécuter la cible du laboratoire et confirmer que l’application répond au point de terminaison prévu.
4. Utiliser le pilote uniquement en mode de vérification non destructif pour confirmer si la cible reflète le marqueur attendu.
5. Capturer les artefacts de requête et de réponse pour la documentation, puis détruire l’environnement du laboratoire après les tests.

Pour les travaux d’évaluation réels, la norme plus sûre consiste à remplacer la validation de type exploitation par une ou plusieurs des méthodes suivantes :

• vérification de la version et du niveau de correctif ;
• examen de configuration authentifié ;
• analyse des journaux de la couche web ;
• examen de la télémétrie EDR, SIEM et WAF ;
• indicateurs de compromission et contrôles de santé fournis par le fournisseur.

Impact

Si une cible est réellement vulnérable à une faille de désérialisation dans un composant d’application privilégié, l’impact potentiel peut être grave :