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 :

• exécution de code à distance dans le contexte de sécurité du service affecté ;
• perte de confidentialité pour les données de l’application, les identifiants et les secrets ;
• perte d’intégrité par falsification de contenu ou de configuration ;
• dégradation de la disponibilité par des commandes destructrices ou des actions ultérieures ;
• opportunités de mouvement latéral si l’hôte dispose de privilèges réseau ou d’identité étendus.

Même dans un laboratoire, la sémantique d’exécution de commande augmente considérablement le risque car elle normalise des workflows qui devraient être réservés à des enquêtes autorisées et strictement contrôlées.

Mesures d’atténuation

La voie d’atténuation appropriée est défensive et en couches.

Actions immédiates :

1. Appliquer les mises à jour de sécurité et les recommandations d’urgence du fournisseur pour la version concernée du produit.
2. Supprimer l’exposition publique ou restreindre l’accès à la surface d’application vulnérable.
3. Renouveler les identifiants et examiner les comptes de service privilégiés en cas de suspicion de compromission.
4. Inspecter les journaux, les tâches planifiées, les processus enfants et les connexions sortantes pour détecter toute activité post-exploitation.
5. Préserver les preuves avant le nettoyage si l’environnement peut déjà être compromis.

Actions de durcissement :

1. Imposer une segmentation réseau autour de SharePoint ou des couches d’application équivalentes.
2. Placer le service derrière un proxy inverse, un WAF ou un contrôle de filtrage équivalent.
3. Réduire autant que possible les privilèges des comptes de service et les capacités d’exécution locales.
4. Activer la journalisation centralisée et les alertes pour les requêtes suspectes vers /_layouts/15/ToolPane.aspx et les chemins administratifs adjacents.
5. Surveiller la création inattendue de processus à partir du contexte du travailleur d’application.

Mesures d’atténuation spécifiques au laboratoire de recherche :

1. Garder le laboratoire sur un réseau ponté isolé sans publication de port hôte.
2. Supprimer le code d’exécution de commande de l’application simulée sauf s’il est strictement nécessaire pour une démonstration contrôlée.
3. Séparer la validation inoffensive de toute fonctionnalité dangereuse dans différents scripts ou branches.
4. Éviter de stocker des listes de cibles positives sauf s’il existe un besoin documenté de conservation.
5. Détruire et reconstruire le laboratoire après chaque exercice.

Avertissement

Ce README ne fournit pas d’instructions pour exploiter des systèmes en production. Il documente le dépôt en tant qu’artefact de recherche contrôlé et décrit des pratiques plus sûres de validation et d’atténuation.

Références

• CVE.org : CVE-2025-53770 - enregistrement CVE canonique avec métadonnées CNA, plages de versions affectées, CVSS et références liées.
• NVD : Détail CVE-2025-53770 - enrichissement NIST, couverture CPE, mappage CWE et agrégation de références.
• Guide de mise à jour de sécurité Microsoft : CVE-2025-53770 - avis principal du fournisseur avec impact, exploitabilité, mesures d’atténuation et informations sur les mises à jour de sécurité.
• Microsoft Learn : Configurer l’intégration AMSI avec SharePoint Server - guide de durcissement Microsoft référencé par l’avis du fournisseur pour l’atténuation et la validation.
• Blog MSRC de Microsoft : Conseils aux clients pour la vulnérabilité SharePoint CVE-2025-53770 - contexte de réponse et conseils du fournisseur pour l’exploitation active.
• Alerte CISA : Microsoft publie des conseils pour l’exploitation de la vulnérabilité SharePoint CVE-2025-53770 - alerte du gouvernement américain et conseils opérationnels de réponse.
• Entrée du catalogue des vulnérabilités exploitées connues de la CISA pour CVE-2025-53770 - confirmation que la vulnérabilité a été ajoutée à KEV avec les délais de correction et les actions recommandées.

Auteur

• J4ck3LSyN
• github