
Une tentative de portage du PoC BlueKeep de @Ekultek vers de véritables exploits.
Ce projet a été archivé car des exploits réels ont été développés ailleurs avec un meilleur succès.
https://blog.rapid7.com/2019/09/06/initial-metasploit-exploit-module-for-bluekeep-cve-2019-0708/
bluekeep_CVE-2019-0708_poc_to_exploit
Veuillez lire les problèmes (à la fois fermés et ouverts) avant de poster des choses comme « Ça ne marche pas », « Rien ne s’est produit après avoir exécuté le script », ou « Erreur (sans être précis), aidez-moi s’il vous plaît ».
============================================================================
============================================================================
============================================================================ Ce ne sont pas des exploits prêts à l’emploi que vous pouvez simplement prendre et essayer.
De plus, les méthodes de livraison sont également importantes pour s’assurer que vos codes s’exécuteront sur la machine distante.
Jusqu’à présent, nous ne sommes toujours pas capables d’ouvrir un shell avec succès et d’obtenir une RCE.
La plupart des scanners et PoC disponibles fonctionnent en analysant uniquement les réponses des hôtes ciblés et déterminent si les hôtes sont vulnérables ou non. (Comme vous devriez tous le savoir, les versions patchées et non patchées renvoient des réponses différentes, ainsi que les systèmes d’exploitation non concernés). Ils n’exploitent pas réellement les hôtes ciblés. Pour parvenir à une RCE, nous devons d’abord essayer de déclencher la vulnérabilité en envoyant des paquets spécialement conçus (référez-vous à la spécification MSDN RDP pour les protocoles). Une fois la vulnérabilité déclenchée, la deuxième étape consiste à analyser les crashs ou les dumps mémoire pour comprendre comment nos codes peuvent s’insérer. Ce n’est pas aussi simple que la plupart d’entre nous le pensent.
Quelques ressources utiles :
Vous pouvez utiliser le Magic Unicorn de @trustedsec pour générer des shellcodes. https://github.com/trustedsec/unicorn
Remarque : Veuillez utiliser Python 3
Le client RDP initie la connexion lorsque l’utilisateur fournit le nom du bureau distant auquel se connecter. Le client RDP initie une connexion à l’hôte de session RD en envoyant une unité de données de protocole (PDU) de demande de connexion X.224.
L’hôte de session RD répond avec une PDU de confirmation de connexion X.224.
Le client RDP envoie une PDU initiale de connexion MCS (Multipoint Communication Service) avec une demande de création de conférence GCC. --> La vulnérabilité est liée à cette demande.
L’hôte de session RD répond avec une PDU de réponse de connexion MCS avec une réponse de création de conférence GCC.
Le client RDP envoie une PDU de demande de domaine Erect MCS.
Le client RDP envoie une PDU de demande d’attachement d’utilisateur MCS.
L’hôte de session RD répond avec une PDU de confirmation d’attachement d’utilisateur MCS.
Le client RDP envoie plusieurs (dans ce cas six) PDU de demande de jonction de canal MCS.
L’hôte de session RD envoie plusieurs (dans ce cas six) PDU de confirmation de jonction de canal MCS.
Le client RDP envoie une PDU d’échange de sécurité.
Le client RDP envoie une PDU d’informations client.
L’hôte de session RD envoie une PDU d’erreur de licence - Client valide.
L’hôte de session RD envoie une PDU de demande active.
Le client RDP répond avec une PDU de confirmation active.
Le client RDP envoie une PDU de synchronisation.
Le client RDP envoie une PDU de contrôle - Coopérer.
Le client RDP envoie une PDU de contrôle - Demande de contrôle.
Le client RDP envoie zéro ou plusieurs PDU de liste de clés persistantes. Dans ce cas, zéro PDU sont envoyés.
Le client RDP envoie une PDU de liste de polices.
L’hôte de session RD envoie une PDU de synchronisation.
L’hôte de session RD envoie une PDU de contrôle - Coopérer.
L’hôte de session RD envoie une PDU de contrôle - Contrôle accordé.
L’hôte de session RD envoie une PDU de mappage de polices..