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
rdpscan — Un scanner rapide pour la vulnérabilité CVE-2019-0708 "BlueKeep". | Kitploit
Outils/GitHubGitHub/robertdavidgraham/rdpscan
Scanners de VulnérabilitésExploitationSécurité Réseau
GitHubrobertdavidgraham/rdpscan

rdpscan

Un scanner rapide pour la vulnérabilité CVE-2019-0708 "BlueKeep".

Voir le dépôt
921237il y a 7 ansVérifié par Kitploit

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

Windows download macOS download Linux download Follow Build

rdpscan pour la vulnérabilité BlueKeep CVE-2019-0708

Il s'agit d'un scanner rapide et rudimentaire pour la vulnérabilité CVE-2019-0708 dans le Bureau à distance Microsoft. Actuellement, environ 900 000 machines sur l'Internet public sont vulnérables à cette vulnérabilité, on s'attend donc à voir bientôt un ver comme WannaCry et notPetya. Par conséquent, scannez vos réseaux et mettez à jour (ou au moins, activez NLA) sur les systèmes vulnérables.

C'est un outil en ligne de commande. Vous pouvez télécharger le source et le compiler vous-même, ou télécharger l'un des binaires pré-compilés pour Windows ou macOS depuis le lien ci-dessus.

Cet outil est entièrement basé sur le patch rdesktop de https://github.com/zerosum0x0/CVE-2019-0708. J'ai simplement réduit le code pour pouvoir le compiler facilement sur macOS et Windows, et j'ai ajouté la possibilité de scanner plusieurs cibles.

Statut

Cet outil est expérimental et n'a que quelques jours. Cependant, je le teste en scannant tout l'Internet (avec l'aide de masscan), donc je résous pas mal de problèmes assez rapidement. Vous pouvez me contacter sur Twitter (@erratarob) pour de l'aide ou des commentaires.

  • 2019-05-38 - Meilleures descriptions des résultats, ainsi qu'une documentation sur leur signification (voir ci-dessous).
  • 2019-05-27 - Binaires Windows et macOS publiés (cliquez sur les badges ci-dessus).
  • 2019-05-26 - Correction des problèmes réseau Windows
  • 2019-05-25 - Linux et macOS fonctionnent bien, Windows a quelques erreurs réseau
  • 2019-05-24 - Fonctionne sur Linux et macOS, Windows a quelques bugs de compilation
  • 2019-05-23 - Fonctionne actuellement sur macOS dans XCode

Utilisation principale

Pour scanner un réseau, exécutez-le comme suit :

root@kitploit:~
rdpscan 192.168.1.1-192.168.1.255

Cela produit l'un des 3 résultats pour chaque adresse :

  • SAFE (SÉCURISÉ) - si la cible a été déterminée comme patchée ou nécessitant au moins CredSSP/NLA
  • VULNERABLE - si la cible a été confirmée vulnérable
  • UNKNOWN (INCONNU) - si la cible ne répond pas ou a une erreur de protocole

Lorsqu'il n'y a rien à une adresse IP cible, les versions plus anciennes affichaient le message "UNKNOWN - connection timed out". Lors du scan de grands réseaux, cela produit une surabondance d'informations sur des systèmes qui ne vous intéressent pas. Par conséquent, la nouvelle version n'affiche pas ces informations par défaut, sauf si vous ajoutez -v (verbose) sur la ligne de commande.

Vous pouvez augmenter la vitesse de scan des grands réseaux en augmentant le nombre de workers :

root@kitploit:~
rdpscan --workers 10000 10.0.0.0/8

Cependant, sur mon ordinateur, cela ne produit qu'environ 1500 workers, à cause des limitations système, quelle que soit la valeur configurée pour ce paramètre.

Vous pouvez encore augmenter la vitesse en utilisant cet outil conjointement avec masscan, comme décrit ci-dessous.

Interprétation des résultats

Il y a trois réponses générales :

  • SAFE (SÉCURISÉ) - la cible est probablement patchée ou sinon non vulnérable au bug.
  • VULNERABLE - nous avons confirmé que la cible est vulnérable à ce bug, et qu'elle sera probablement infectée lorsque le ver frappera.
  • UNKNOWN (INCONNU) - nous ne pouvons confirmer ni l'un ni l'autre, généralement parce que la cible ne répond pas ou n'exécute pas RDP, ce qui est la grande majorité des réponses. Aussi, lorsque les cibles manquent de ressources ou rencontrent des problèmes réseau, nous obtenons beaucoup de ces réponses. Enfin, les erreurs de protocole en sont responsables dans de nombreux cas. Bien que les trois réponses principales soient SAFE, VULNERABLE et UNKNOWN, elles contiennent un texte supplémentaire expliquant le diagnostic. Cette section décrit les différentes chaînes que vous verrez.

SAFE

Il y a trois raisons principales pour lesquelles nous pensons qu'une cible est sécurisée :

  • SAFE - Target appears patched (SÉCURISÉ - La cible semble patchée) Cela se produit lorsque la cible ne répond pas à la requête déclencheur. Cela signifie que c'est un système Windows qui a été patché, ou un système qui n'était pas vulnérable au départ, comme Windows 10 ou Unix.
  • SAFE - CredSSP/NLA required (SÉCURISÉ - CredSSP/NLA requis) Cela signifie que la cible nécessite d'abord une authentification au niveau réseau avant que la connexion RDP puisse être établie. L'outil ne peut pas dépasser ce point sans des identifiants légitimes, donc il ne peut pas déterminer si la cible a été patchée. Cependant, les hackers ne peuvent pas non plus continuer au-delà de ce point pour exploiter des systèmes vulnérables, donc vous êtes probablement "sécurisé". Cependant, lorsque des exploits apparaîtront, des initiés disposant d'identifiants valides pourront exploiter le système s'il n'est pas patché.
  • SAFE - not RDP (SÉCURISÉ - pas du RDP) Cela signifie que le système n'est pas RDP, mais offre un autre service qui utilise le même port, et produit une réponse clairement non RDP. Les exemples courants sont HTTP et SSH. Notez cependant qu'au lieu d'un protocole identifiable, un serveur peut répondre avec un paquet RST ou FIN. Ceux-ci sont identifiés comme UNKNOWN au lieu de SAFE.

VULNERABLE

Cela signifie que nous avons confirmé que le système est vulnérable au bug.

  • VULNERABLE - got appid (VULNÉRABLE - appid obtenu) Il n'y a qu'une seule réponse lorsque le système est vulnérable, celle-ci.

UNKNOWN

Il existe d'innombrables variations pour "inconnu" :

  • UNKNOWN - no connection - timeout (INCONNU - pas de connexion - délai expiré) C'est de loin la réponse la plus courante, et se produit lorsque l'adresse IP cible ne fait absolument aucune réponse. En fait, c'est tellement courant que lors du scan de grandes plages d'adresses, elle est généralement omise. Vous devez ajouter le drapeau -v (verbose) pour l'activer.
  • UNKNOWN - no connection - refused (RST) (INCONNU - pas de connexion - refusé (RST)) C'est de loin la deuxième réponse la plus courante, et se produit lorsque la cible existe et répond au trafic réseau, mais n'exécute pas RDP, donc refuse la connexion avec un paquet TCP RST.
  • UNKNOWN - RDP protocol error - receive timeout (INCONNU - erreur de protocole RDP - délai de réception expiré) C'est la troisième réponse la plus courante, et se produit lorsque nous avons établi une connexion RDP avec succès, mais que le serveur cesse de répondre. Cela est dû à des erreurs réseau ou lorsque le système cible est surchargé pour une raison quelconque. Cela pourrait aussi être des erreurs réseau de votre côté, par exemple si vous êtes derrière un NAT et que vous le surchargez avec trop de connexions.
  • UNKNOWN - no connection - connection closed (INCONNU - pas de connexion - connexion fermée) Cela signifie que nous avons établi une connexion (SYN-ACK TCP), mais que la connexion est immédiatement fermée (avec un RST ou FIN). Il y a de nombreuses raisons pour lesquelles cela se produit, que nous ne pouvons pas distinguer :
    • Le système exécute RDP, mais ferme la connexion pour une raison quelconque, peut-être parce qu'il manque de ressources.
    • Ce n'est pas du RDP, et il n'aime pas la requête RDP que nous lui envoyons, donc au lieu de nous envoyer un message d'erreur (ce qui déclencherait SAFE - not RDP), il ferme brusquement la connexion.
    • Un équipement intermédiaire, comme un IPS, un pare-feu ou un NAT, a fermé la connexion parce qu'il a identifié cela comme hostile, ou a manqué de ressources.
    • Une autre raison que je n'ai pas identifiée, il se passe beaucoup de choses étranges lorsque je scanne l'Internet.
  • UNKNOWN - no connection - host unreachable (ICMP error) (INCONNU - pas de connexion - hôte inaccessible (erreur ICMP)) Le réseau distant signale que l'hôte ne peut pas être atteint ou n'est pas en fonctionnement. Réessayez plus tard si vous pensez que cet hôte devrait être actif.
  • UNKNOWN - no connection - network unreachable (ICMP error) (INCONNU - pas de connexion - réseau inaccessible (erreur ICMP)) Il y a une erreur réseau (transitoire) à l'autre bout, réessayez plus tard si vous pensez que ce réseau devrait fonctionner.
  • UNKNOWN - RDP protocol error (INCONNU - erreur de protocole RDP) Cela signifie qu'une corruption s'est produite dans le protocole RDP, soit parce que le côté distant l'implémente mal (pas un système Windows), parce qu'il gère mal une erreur réseau transitoire, ou autre chose.

Utilisation avec masscan

Cet outil rdpscan est assez lent, ne scannant que quelques centaines de cibles par seconde. Vous pouvez plutôt utiliser masscan pour accélérer les choses. L'outil masscan est environ 1000 fois plus rapide, mais ne donne que des informations limitées sur la cible.

Les étapes sont :

  • D'abord, scannez les plages d'adresses avec masscan pour trouver rapidement les hôtes qui répondent sur le port 3389 (ou tout autre port que vous utilisez).
  • Ensuite, fournissez la sortie de masscan à rdpscan, afin qu'il n'ait à scanner que les cibles que nous savons actives.

La façon simple de procéder est de les combiner sur la ligne de commande :

root@kitploit:~
masscan 10.0.0.0/8 -p3389 | rdpscan --file -

La façon dont je procède est en deux étapes :

root@kitploit:~
masscan 10.0.0.0/8 -p3389 > ips.txt
rdpscan --file ips.txt --workers 10000 >results.txt

Compilation

La partie difficile est d'installer les bibliothèques OpenSSL, sans qu'elles n'entrent en conflit avec d'autres versions sur le système. Voici quelques exemples pour les versions de Linux sur lesquelles j'ai testé, mais les noms des paquets changent d'une distribution à l'autre. Il existe également de nombreuses options pour une API compatible OpenSSL, comme BoringSSL et LibreSSL.

root@kitploit:~
$ sudo apt install libssl-dev
$ sudo yum install openssl-devel

Une fois ce problème résolu, il vous suffit de compiler tous les fichiers .c ensemble comme ceci :

root@kitploit:~
$ gcc *.c -lssl -lcrypto -o rdpscan

J'ai mis un Makefile dans le répertoire qui fait cela, donc vous pouvez probablement simplement faire :

root@kitploit:~
$ make

Le code est écrit en C, donc nécessite un compilateur C installé, par exemple en faisant :

root@kitploit:~
$ sudo apt install build-essential

Erreurs de compilation courantes

Cette section décrit les erreurs de compilation les plus évidentes.

root@kitploit:~
ssl.h:24:25: fatal error: openssl/rc4.h: No such file or directory

Cela signifie que vous n'avez pas les en-têtes OpenSSL installés, ou qu'ils ne se trouvent pas dans un chemin d'accès. N'oubliez pas que même si vous avez les binaires OpenSSL installés, cela ne signifie pas que vous avez les fichiers de développement installés. Vous avez besoin à la fois des en-têtes et des bibliothèques installés.

Pour installer ces éléments sur Debian, faites :

root@kitploit:~
$ sudo apt install libssl-dev

Pour corriger le problème de chemin, ajoutez un drapeau de compilation -I/usr/local/include, ou quelque chose de similaire.

Un exemple de problème d'édition de liens est le suivant :

root@kitploit:~
Undefined symbols for architecture x86_64:
"_OPENSSL_init_ssl", referenced from:
    _tcp_tls_connect in tcp-fac73c.o
"_RSA_get0_key", referenced from:
    _rdssl_rkey_get_exp_mod in ssl-d5fdf5.o
"_SSL_CTX_set_options", referenced from:
    _tcp_tls_connect in tcp-fac73c.o
"_X509_get_X509_PUBKEY", referenced from:
    _rdssl_cert_to_rkey in ssl-d5fdf5.o

Je reçois cela sur macOS car il existe plusieurs versions d'OpenSSL. Je corrige cela en codant en dur les chemins :

root@kitploit:~
$ gcc *.c -lssl -lcrypto -I/usr/local/include -L/usr/local/lib -o rdpscan

Selon les commentaires d'autres utilisateurs, la ligne de commande suivante pourrait fonctionner sur macOS si vous avez utilisé Homebrew pour installer les choses. J'obtiens toujours les erreurs de liaison ci-dessus, cependant, car j'ai installé d'autres composants OpenSSL qui entrent en conflit.

root@kitploit:~
gcc $(brew --prefix)/opt/openssl/lib/libssl.a $(brew --prefix)/opt/openssl/lib/libcrypto.a -o rdpscan *.c

Exécution

La section ci-dessus donne des conseils de démarrage rapide pour exécuter le programme. Cette section fournit une aide plus détaillée.

Pour scanner une seule cible, passez simplement l'adresse de la cible :

root@kitploit:~
./rdpscan 192.168.10.101

Vous pouvez passer des adresses IPv6 et des noms DNS. Vous pouvez passer plusieurs cibles. Un exemple serait :

root@kitploit:~
./rdpscan 192.168.10.101 exchange.example.com 2001:0db8:85a3::1

Vous pouvez également scanner des plages d'adresses, en utilisant des adresses IPv4 début-fin, ou une spécification CIDR IPv4. Les plages IPv6 ne sont pas prises en charge car elles sont trop vastes.

root@kitploit:~
./rdpscan 10.0.0.1-10.0.0.25 192.168.0.0/16

Par défaut, il ne scanne que 100 cibles à la fois. Vous pouvez augmenter ce nombre avec le paramètre --workers. Cependant, quelle que soit la valeur élevée de ce paramètre, en pratique, vous obtiendrez un maximum d'environ 500 à 1500 workers s'exécutant simultanément, selon votre système.

root@kitploit:~
./rdpscan --workers 1000 10.0.0.0/24

Au lieu de spécifier des cibles sur la ligne de commande, vous pouvez les charger depuis un fichier, en utilisant le paramètre bien nommé --file :

root@kitploit:~
./rdpscan --file ips.txt

Le format du fichier est une adresse, un nom ou une plage par ligne. Il peut également consommer le texte généré par masscan. Les espaces supplémentaires sont supprimés, les lignes vides ignorées, et toute ligne de commentaire est ignorée. Un commentaire est une ligne commençant par le caractère #, ou les caractères //.

La sortie est envoyée sur stdout donnant le statut VULNERABLE, SAFE, ou UNKNOWN. Il peut y avoir des raisons supplémentaires pour chacun. Ces raisons sont décrites ci-dessus.

root@kitploit:~
211.101.37.250 - SAFE - CredSSP/NLA required
185.11.124.79 - SAFE - not RDP - SSH response seen
125.121.137.42 - UNKNOWN - no connection - refused (RST)
40.117.191.215 - SAFE - CredSSP/NLA required
121.204.186.182 - SAFE - CredSSP/NLA required
99.8.11.148 - SAFE - CredSSP/NLA required
121.204.186.114 - SAFE - CredSSP/NLA required
49.50.145.236 - SAFE - CredSSP/NLA required
106.12.74.155 - VULNERABLE - got appid
222.84.253.26 - SAFE - CredSSP/NLA required
144.35.133.109 - UNKNOWN - RDP protocol error - receive timeout
199.212.226.196 - UNKNOWN - RDP protocol error - receive timeout
183.134.58.152 - UNKNOWN - no connection - refused (RST)
83.162.246.149 - VULNERABLE - got appid

Vous pouvez traiter cela avec des commandes unix supplémentaires comme grep et cut. Pour obtenir une liste des machines vulnérables uniquement :

root@kitploit:~
./rdpscan 10.0.0.0/8 | grep 'VULN' | cut -f1 -d'-'

Le paramètre -dddd signifie informations diagnostiques, où plus vous ajoutez de d, plus les détails sont imprimés. Ceci est envoyé vers stderr au lieu de stdout afin que vous puissiez séparer les flux. Avec bash, cela se fait comme ceci :

root@kitploit:~
./rdpscan --file myips.txt -ddd 2> diag.txt 1> results.txt

Informations de diagnostic

L'ajout du paramètre -d envoie des informations de diagnostic sur les connexions vers stderr.

root@kitploit:~
./rdpscan 62.15.34.157 -d

[+] [62.15.34.157]:3389 - connecting...
[+] [62.15.34.157]:3389 - connected from [10.1.10.133]:49211
[+] [62.15.34.157]:3389 - SSL connection
[+] [62.15.34.157]:3389 - version = v4.8
[+] [62.15.34.157]:3389 - Sending MS_T120 check packet
[-] [62.15.34.157]:3389 - Max sends reached, waiting...
62.15.34.157    - SAFE - Target appears patched

Sous macOS/Linux, vous pouvez rediriger stdout et stderr séparément vers différents fichiers de la manière habituelle :

root@kitploit:~
./rdpscan --file ips.txt 2> diag.txt 1> results.txt

SOCKS5 et Tor pour le plaisir

L'outil inclut le support SOCKS5 :

root@kitploit:~
./rdpscan --file ips.txt --socks5 localhost --socks5port 9050

Cela aggrave les problèmes de connexion, vous obtiendrez donc beaucoup plus de résultats "UNKNOWN".

Lier statiquement OpenSSL

Pour publier les binaires Windows et macOS joints en tant que releases à ce projet, je lie statiquement OpenSSL, afin qu'il n'ait pas besoin d'être inclus séparément et que les programmes fonctionnent simplement. Cette section contient quelques notes sur la façon de procéder, d'autant plus que la description sur la propre page d'OpenSSL semble obsolète.

Ces deux étapes commencent par télécharger le source d'OpenSSL et le placer à côté du répertoire rdpscan :

root@kitploit:~
git clone https://github.com/openssl/openssl

Windows

Sous Windows, vous devez d'abord installer une version de Perl. J'utilise celle d'ActiveState.

Ensuite, vous aurez besoin d'un "assembleur" spécial. J'utilise celui recommandé, NASM.

Ensuite, vous aurez besoin d'un compilateur. J'utilise VisualStudio 2010. Vous pouvez télécharger la dernière "Visual Studio Community Edition" (qui est 2019) à la place depuis Microsoft.

Maintenant, vous devez construire le makefile. Pour cela, allez dans le répertoire OpenSSL et exécutez le programme Perl Configure :

root@kitploit:~
perl Configure VC-WIN32

J'ai choisi 32 bits pour Windows car il existe beaucoup de vieux Windows, et je veux rendre le programme aussi compatible que possible avec les anciennes versions.

Je veux une construction entièrement statique, y compris le runtime C. Pour ce faire, j'ai ouvert le makefile résultant dans un éditeur et j'ai changé le drapeau de compilation C de /MD (qui signifie utiliser des DLL) à /MT. Pendant que j'y étais, j'ai ajouté ce qui suit à CPPFLAGS : -D_WIN32_WINNT=0x501, ce qui restreint OpenSSL aux fonctionnalités qui fonctionnent sur Windows XP et Server 2003. Sinon, vous obtiendrez des erreurs indiquant que bcrypt.dll est introuvable si vous exécutez sur ces anciens systèmes.

Maintenant, assurez-vous que tout est dans votre PATH. J'ai copié nasm.exe dans un répertoire du PATH. Pour Visual Studio 2010, j'ai exécuté le programme vcvars32.bat pour configurer les variables d'environnement pour le compilateur.

À ce stade, dans la ligne de commande, j'ai tapé :

root@kitploit:~
nmake

Cela crée les bibliothèques. Les versions statiques sont libssl_static.lib et libcrypto_static.lib, que j'utilise pour lier dans rdpscan.

macOS

Tout d'abord, vous devez installer un compilateur. J'utilise les outils de développement d'Apple, en installant XCode et le compilateur. Je pense que vous pouvez utiliser Homebrew pour installer gcc à la place.

Ensuite, allez dans le répertoire source d'OpenSSL et créez un makefile :

root@kitploit:~
perl Configure darwin64-x86_64-cc

Maintenant, construisez-le simplement :

root@kitploit:~
make depend
make

À ce stade, il a créé à la fois des bibliothèques dynamiques (.dylib) et statiques (.lib). J'ai supprimé les bibliothèques dynamiques pour qu'il utilise les bibliothèques statiques par défaut.

Maintenant, dans rdpscan, construisez simplement le makefile macOS :

root@kitploit:~
make -f Makefile.macos

Cela compilera tous les fichiers source de rdpscan, puis les liera aux bibliothèques OpenSSL dans le répertoire ../openssl que vous venez de construire.

Cela devrait produire un exécutable de 3 mégaoctets. Si vous n'obtenez à la place qu'un exécutable de 200 kilo-octets, vous avez fait une erreur et lié aux bibliothèques dynamiques à la place.

Télécharger l’outil
  • UNKNOWN - SSL protocol error (INCONNU - erreur de protocole SSL) Depuis Windows Vista, RDP utilise le protocole STARTTLS pour fonctionner via SSL. Cette couche a ses propres problèmes comme ci-dessus, notamment la gestion erronée des erreurs réseau sous-jacentes, ou la tentative de communication avec des systèmes qui présentent une incompatibilité. Si vous obtenez un message d'erreur très long ici (comme SSL3_GET_RECORD:wrong version), c'est parce que l'autre côté a un bug dans SSL, ou que votre propre bibliothèque SSL que vous utilisez a un bug.