La pandémie du virus COVID-19 a radicalement changé le modèle de travail du personnel de nombreuses organisations sur une base volontaire-obligatoire, «récompensant» la plupart d'entre eux avec le statut de «distant», et certains, même de «travailleur à distance».
Si, avant la «méga-épidémie», les employés exécutaient leurs tâches depuis le bureau en utilisant l'infrastructure d'entreprise contrôlée par le service informatique de l'entreprise, alors pendant l'auto-isolement, la part du «lion» du travail de bureau commençait à être effectuée à partir d'appareils à domicile utilisant le protocole RDP (Remote Desktop Protocol). Populaire, comme le système d'exploitation lui-même de MS, mais, comme le suggère la liste des vulnérabilités, ce n'est pas le protocole le plus sécurisé. Nous parlerons de la manière de protéger votre RDP contre les attaques extérieures.
Malheureusement, pour considérer les caractéristiques de chacune des vulnérabilités sur lesquelles je voudrais attirer votre attention, un article ne me suffit certainement pas, donc dans celui-ci je me limiterai aux détails du cycle de vie de l'un des derniers.
RDP vice versa
En 2018, dans le cadre de recherches sur la sécurité du protocole de bureau à distance, les spécialistes de Check Point Research ont découvert plusieurs vulnérabilités dans trois clients populaires conçus pour fonctionner avec:
- Client RDP de Microsoft / Mstsc.exe
- rdesktop
- FreeRDP
Au total, 25 vulnérabilités ont été découvertes, y compris des vulnérabilités critiques, y compris celles qui permettent à un attaquant de changer le sens habituel de communication et d'attaquer un ordinateur client, c'est-à-dire de mener une attaque en utilisant une connexion RDP inversée (attaque RDP inversée).
Dans le client RDP de Microsoft, cette vulnérabilité se cachait dans le presse-papiers partagé entre le client et le serveur. Ce qui, lors de l'utilisation du tampon lors de la connexion, permettait au serveur avec l'exploit «d'inclure» ses propres fichiers dans le processus d'échange initié par l'utilisateur. Et la fonctionnalité de l'attaque par traversée de chemin est de déterminer la «destination finale» du fichier à n'importe quel endroit de l'ordinateur client. Par exemple, sans notifications inutiles, envoyez un fichier exécutable (mineur, programme de cryptage) dans le dossier de démarrage de l'ordinateur de l'utilisateur pour le lancer au prochain redémarrage du système.
Démonstration de la vulnérabilité de Check Point Research dont
le fait a été signalé à Microsoft (MSRC) le 16 octobre 2018. En réponse à laquelle, le 17 décembre 2018, le destinataire a répondu:
«Merci pour votre soumission. Nous avons déterminé que votre constatation est valide mais ne correspond pas à notre barre de service. Pour plus d'informations, consultez les critères de maintenance de Microsoft pour Windows (https://aka.ms/windowscriteria). "
«Merci d'avoir soumis votre candidature. Nous avons déterminé que votre trouvaille est valide mais ne répond pas à notre niveau de service. Pour plus d'informations, consultez Critères de maintenance Microsoft pour Windows (https://aka.ms/windowscriteria) ».
En conséquence, cette vulnérabilité n'a pas reçu son ID et son correctif pour son correctif. une source
HyperRDP
Après la publication d'informations sur cette vulnérabilité, les employés de Check Point Research ont commencé à recevoir de nombreux commentaires et questions, dont l'un a suscité un réel intérêt et les a incités à revenir à des recherches plus poussées et à examiner la vulnérabilité sous un «angle différent», à savoir: la vulnérabilité du client Microsoft RDP être utilisé dans Microsoft Hyper-V?
À la suite d'une étude plus approfondie, il s'est avéré qu'au cœur de l'interface graphique de gestion de VM - Hyper-V manager, la technologie RDP est utilisée en coulisses, dans des sessions étendues dont, ainsi que dans les propriétés du bureau distant, il est possible d'activer un presse-papiers partagé. Et par conséquent, la même vulnérabilité est présente!
Démonstration d'une vulnérabilité dans Hyper-V par Check Point Research
À ce sujet, le personnel de Check Point Research s'est exprimé dans leur blog, ainsi qu'à la conférence Black Hat USA 2019 .
Présentation de la vulnérabilité à Black Hat USA 2019
Et, bien sûr, MSRC a rapporté . Cette fois, Microsoft a ouvert un ticket et en octobre 2019 a publié un correctif pour corriger cette vulnérabilité, qui a reçu l'ID: CVE-2019-0887 . une source
Des moyens insignifiants
Après avoir analysé l'efficacité du correctif, lorsque les experts de Check Point Research étaient sur le point d'attribuer à la vulnérabilité le statut «fermé», ils ont été contactés par un utilisateur du client Mac OS RDP avec des informations sur les caractéristiques du comportement du client après l'installation du correctif à partir de MS.
Lors du prototypage du modèle de connexion RDP à l'aide de ce client, il est devenu clair que le correctif lui-même présentait des failles de sécurité qui vous permettent de contourner la protection et de recréer l'exploit d'origine. Cela a été signalé au MSRC .
En février 2020, Microsoft s'est rallié et a publié un correctif pour corriger cette vulnérabilité CVE-2020-0655., qui, selon les experts de Check Point Research, n'a pas totalement résolu le problème des attaques par traversée de chemin, en particulier pour l'API Windows. Microsoft a annoncé à propos de ce "joint" n'a pas encore commenté cette situation. une source
Et alors…
Comme le lecteur avisé peut le remarquer, un serveur RDP compromis est nécessaire pour mener à bien ce type d'attaque. Et vous pouvez "l'obtenir" de trois manières:
- Créez le vôtre et faites-le passer pour légitime
- Accédez à l'existant et compromettez-le
- Hybride
Une option relativement sûre et optimale de coût et de vitesse de provisionnement dans les réalités d'aujourd'hui serait de «reprendre» un serveur cloud ou VPS / VDS loué à un fournisseur de services. Et il y a trois raisons principales à cela:
- Chaque serveur virtuel loué exécutant Windows est déjà un serveur RDP par défaut
- Chaque serveur virtuel loué exécutant Windows, en règle générale, dispose déjà d'un compte RDP avec des droits d'administrateur et une connexion unique pour tous les utilisateurs.
- En règle générale, l'accès RDP au serveur virtuel s'effectue via le port TCP disponible sur l'adresse IP publique: 3389.
En fait, ce port "sortant" est probablement le "chiffon rouge" pour un cyber-attaquant qui veut prendre le contrôle d'un serveur virtuel, en récupérant un mot de passe pour lui en utilisant une simple méthode automatisée de force brute. Ou comme on l'appelle aussi une attaque par force brute.
Pour référence: Un exemple d'augmentation du nombre d'attaques de la famille Bruteforce.Generic.RDP, février - avril 2020 de Kaspersky Lab.
une source
… Plus loin
Afin de ne pas devenir victime des situations ci-dessus, vous pouvez bien sûr modifier les paramètres de compte et les ports RDP standard, bloquer les tentatives de connexion non autorisées à l'aide du pare-feu Windows ou de programmes tiers tels que IPBAN , utiliser le cryptage et les certificats, et bien plus encore. Mais pour moi, le moyen le plus simple et le plus rapide de sécuriser une connexion RDP à un serveur nouvellement créé est d'autoriser l'accès RDP uniquement à partir des hôtes d'un réseau de confiance.
Dans RUVDS, cela nécessite trois étapes simples:
- Combinez un serveur virtuel avec des ordinateurs qui doivent y accéder via RDP avec un réseau privé virtuel. J'utilise - ZeroTier
- :
.
:
—
— . — ZeroTier.
— RDP- . . - RDP- IP- .
Sur ce, je veux prendre un congé et vous conseiller de surveiller la "santé" de la connexion RDP de votre serveur virtuel. Car, depuis CVE-2020-0655, trois autres vulnérabilités avec fonctionnalité d'attaque RDP inversée sont apparues .
