Skip to content
KitploitKITPLOIT
OutilsBlog
Soumettre
OutilsBlog
Soumettre

Outils de Hacking, PenTest et Cybersécurité pour votre Arsenal de Sécurité !

Kitploit est un répertoire d'outils de hacking, de cybersécurité et de pentesting. Découvrez les dernières mises à jour des projets pour trouver des vulnérabilités, analyser des systèmes, automatiser les tests et renforcer votre sécurité.

··Flux·Contact·Confidentialité·© 2026 Kitploit

Répertoire d'outils

Catégories

Voir toutes les catégories
Loading categories
cve-2016-1000027-poc — PoC pour CVE-2016-1000027 | Kitploit
Outils/GitHubGitHub/artem-smotrakov/cve-2016-1000027-poc
Analyse des VulnérabilitésExploitationExploitation d'Applications WebApprentissage et ÉducationDéveloppement de Charges UtilesLabs et Pratique
GitHubartem-smotrakov/cve-2016-1000027-poc

cve-2016-1000027-poc

PoC pour CVE-2016-1000027

Voir le dépôt
128il y a 5 ansPas encore vérifié

Populaires

Voir tout →

Découvrez les outils les plus utilisés par notre communauté.

Explorer tous les outils

Parcourez notre collection d'outils

Voir tous les outils →
Partager

Preuve de concept pour CVE-2016-1000027

Ceci est une application de démonstration Spring Boolt qui est affectée par CVE-2016-1000027.

Étapes pour reproduire la vulnérabilité

  1. Démarrez un serveur vulnérable com.gypsyengineer.server.Server.
  2. Exécutez com.gypsyengineer.client.Exploit.

La classe Exploit lit payload.bin et l'envoie au serveur vulnérable. payload.bin contient une charge utile générée par ysoserial. Le payload.bin actuel est CommonsCollections5 qui exécute gedit :

Télécharger l’outil
root@kitploit:~
java -jar target/ysoserial-0.0.6-SNAPSHOT-all.jar CommonsCollections5 gedit > payload.bin

Comment corriger une application affectée par CVE-2016-1000027

Le problème n'a pas été corrigé dans Spring Framework. Voir https://github.com/spring-projects/spring-framework/issues/24434

Voici ce qui peut être fait du côté de l'application.

  1. La meilleure façon est de cesser d'utiliser les classes HttpInvokerServiceExporter et RemoteInvocationSerializingExporter. Elles sont déjà obsolètes et seront probablement supprimées dans les prochaines versions de Spring Framework.
  2. N'acceptez pas de données non fiables dans les points de terminaison basés sur ces classes vulnérables.
  3. Utilisez les filtres de sérialisation introduits par JEP 290.

Liens

  1. [R2] Méthode readRemoteInvocation de Pivotal Spring Framework HttpInvokerServiceExporter : désérialisation Java non fiable
  2. OWASP : Désérialisation de données non fiables
  3. L'application est basée sur ceci