1. Introduction
Les entreprises qui ne disposaient pas de systèmes d’accès à distance les ont déployés en urgence il y a quelques mois. Tous les administrateurs n'étaient pas préparés à une telle « chaleur », qui a entraîné des failles de sécurité : configuration incorrecte des services ou même installation de versions obsolètes de logiciels présentant des vulnérabilités précédemment découvertes. Pour certains, ces omissions ont déjà eu un effet boomerang, d'autres ont eu plus de chance, mais chacun doit absolument en tirer des conclusions. La fidélité au travail à distance a augmenté de façon exponentielle et de plus en plus d'entreprises acceptent le travail à distance comme un format acceptable de manière continue.
Il existe donc de nombreuses options pour fournir un accès à distance : divers VPN, RDS et VNC, TeamViewer et autres. Les administrateurs ont l'embarras du choix, en fonction des spécificités de la construction d'un réseau d'entreprise et des appareils qu'il contient. Les solutions VPN restent les plus populaires, cependant, de nombreuses petites entreprises choisissent les RDS (Remote Desktop Services), elles sont plus simples et plus rapides à déployer.
Dans cet article, nous parlerons davantage de la sécurité RDS. Faisons un bref aperçu des vulnérabilités connues, et considérons également plusieurs scénarios pour lancer une attaque sur une infrastructure réseau basée sur Active Directory. Nous espérons que notre article aidera quelqu'un à travailler sur les bugs et à améliorer la sécurité.
2. Vulnérabilités RDS/RDP récentes
Tout logiciel contient des erreurs et des vulnérabilités qui peuvent être exploitées par des attaquants, et RDS ne fait pas exception. Microsoft a fréquemment signalé de nouvelles vulnérabilités ces derniers temps, nous avons donc décidé de leur donner un bref aperçu :
Cette vulnérabilité met en danger les utilisateurs qui se connectent à un serveur compromis. Un attaquant peut prendre le contrôle de l'appareil d'un utilisateur ou prendre pied dans le système pour disposer d'un accès à distance permanent.
- / /
Ce groupe de vulnérabilités permet à un attaquant non authentifié d'exécuter à distance du code arbitraire sur un serveur exécutant RDS à l'aide d'une requête spécialement conçue. Ils peuvent également être utilisés pour créer des vers, des logiciels malveillants qui infectent indépendamment les appareils voisins du réseau. Ainsi, ces vulnérabilités peuvent mettre en péril l’ensemble du réseau de l’entreprise, et seules des mises à jour opportunes peuvent les sauver.
Les logiciels d'accès à distance font l'objet d'une attention accrue de la part des chercheurs et des attaquants, nous pourrions donc bientôt entendre parler d'autres vulnérabilités similaires.
La bonne nouvelle est que toutes les vulnérabilités ne disposent pas d’exploits publics. La mauvaise nouvelle est qu'il ne sera pas difficile pour un attaquant expert d'écrire un exploit pour une vulnérabilité en se basant sur la description, ou en utilisant des techniques telles que le Patch Diffing (nos collègues en ont parlé dans ). Par conséquent, nous vous recommandons de mettre régulièrement à jour le logiciel et de surveiller l'apparition de nouveaux messages concernant les vulnérabilités découvertes.
3. Attaques
Passons à la deuxième partie de l'article, où nous montrerons comment commencent les attaques contre l'infrastructure réseau basée sur Active Directory.
Les méthodes décrites sont applicables au modèle d'attaquant suivant : un attaquant qui dispose d'un compte utilisateur et a accès à la passerelle Bureau à distance - un serveur de terminaux (il est souvent accessible, par exemple, depuis un réseau externe). En utilisant ces méthodes, l'attaquant pourra poursuivre l'attaque sur l'infrastructure et consolider sa présence sur le réseau.
La configuration du réseau dans chaque cas spécifique peut différer, mais les techniques décrites sont assez universelles.
Exemples de sortie d’un environnement restreint et d’augmentation des privilèges
Lors de l'accès à la passerelle Bureau à distance, un attaquant rencontrera probablement une sorte d'environnement restreint. Lorsque vous vous connectez à un serveur de terminaux, une application se lance sur celui-ci : une fenêtre de connexion via le protocole Remote Desktop pour les ressources internes, l'Explorateur, les packages bureautiques ou tout autre logiciel.
L'objectif de l'attaquant sera d'accéder pour exécuter des commandes, c'est-à-dire lancer cmd ou PowerShell. Plusieurs techniques classiques d’échappement du bac à sable Windows peuvent vous aider. Considérons-les plus en détail.
Option 1. L'attaquant a accès à la fenêtre de connexion Bureau à distance au sein de la passerelle Bureau à distance :
Le menu « Afficher les options » s'ouvre. Des options apparaissent pour manipuler les fichiers de configuration de connexion :
Depuis cette fenêtre, vous pouvez facilement accéder à l'Explorateur en cliquant sur l'un des boutons « Ouvrir » ou « Enregistrer » :
L'explorateur s'ouvre. Sa « barre d'adresse » permet de lancer les fichiers exécutables autorisés, ainsi que de lister le système de fichiers. Cela peut être utile pour un attaquant dans les cas où les lecteurs système sont masqués et ne sont pas directement accessibles :
→
Un scénario similaire peut être reproduit, par exemple, en utilisant Excel de la suite Microsoft Office comme logiciel distant.
→
De plus, n’oubliez pas les macros utilisées dans cette suite bureautique. Nos confrères se sont penchés sur le problème de la macro-sécurité dans ce .
Option 2. En utilisant les mêmes entrées que dans la version précédente, l'attaquant lance plusieurs connexions au bureau distant sous le même compte. Lorsque vous vous reconnecterez, le premier sera fermé et une fenêtre avec une notification d'erreur apparaîtra à l'écran. Le bouton d'aide dans cette fenêtre appellera Internet Explorer sur le serveur, après quoi l'attaquant pourra accéder à Explorer.
→
Option 3. Si des restrictions sur le lancement des fichiers exécutables sont configurées, un attaquant peut rencontrer une situation dans laquelle les stratégies de groupe interdisent à l'administrateur d'exécuter cmd.exe.
Il existe un moyen de contourner ce problème en exécutant un fichier bat sur le bureau distant avec un contenu tel que cmd.exe /K <command>. Une erreur lors du démarrage de cmd et un exemple réussi d'exécution d'un fichier bat sont présentés dans la figure ci-dessous.
Option 4. Interdire le lancement d'applications utilisant des listes noires basées sur le nom des fichiers exécutables n'est pas une panacée : elles peuvent être contournées.
Considérez le scénario suivant : nous avons désactivé l'accès à la ligne de commande, empêché le lancement d'Internet Explorer et de PowerShell à l'aide de stratégies de groupe. L'attaquant tente d'appeler à l'aide – sans réponse. Essayer de lancer PowerShell via le menu contextuel d'une fenêtre modale, appelée avec la touche Maj enfoncée - un message indiquant que le lancement est interdit par l'administrateur. Essaie de lancer PowerShell via la barre d'adresse - encore une fois, aucune réponse. Comment contourner la restriction ?
Il suffit de copier powershell.exe du dossier C:WindowsSystem32WindowsPowerShellv1.0 vers le dossier utilisateur, de changer le nom en autre chose que powershell.exe et l'option de lancement apparaîtra.
Par défaut, lors de la connexion à un poste de travail distant, l'accès aux disques locaux du client est fourni, à partir duquel un attaquant peut copier powershell.exe et l'exécuter après l'avoir renommé.
→
Nous n'avons donné que quelques façons de contourner les restrictions ; vous pouvez proposer de nombreux autres scénarios, mais ils ont tous un point commun : l'accès à l'Explorateur Windows. De nombreuses applications utilisent des outils de manipulation de fichiers Windows standard et, lorsqu'elles sont placées dans un environnement limité, des techniques similaires peuvent être utilisées.
4. Recommandations et conclusion
Comme nous pouvons le constater, même dans un environnement limité, il est possible de développer des attaques. Cependant, vous pouvez rendre la vie plus difficile à l’attaquant. Nous fournissons des recommandations générales qui seront utiles à la fois dans les options que nous avons envisagées et dans d'autres cas.
- Limitez les lancements de programmes aux listes noires/blanches à l’aide de stratégies de groupe.
Dans la plupart des cas, il reste cependant possible d’exécuter le code. Nous vous recommandons de vous familiariser avec le projet , pour avoir une idée des manières non documentées de manipuler des fichiers et d'exécuter du code sur le système.
Nous recommandons de combiner les deux types de restrictions : vous pouvez par exemple autoriser le lancement de fichiers exécutables signés par Microsoft, mais restreindre le lancement de cmd.exe. - Désactivez les onglets des paramètres d'Internet Explorer (peut être effectué localement dans le registre).
- Désactivez l'aide intégrée de Windows via regedit.
- Désactivez la possibilité de monter des disques locaux pour les connexions à distance si une telle limitation n'est pas critique pour les utilisateurs.
- Limitez l'accès aux lecteurs locaux de la machine distante, en ne laissant l'accès qu'aux dossiers utilisateur.
Nous espérons que vous l’avez trouvé au moins intéressant et qu’au maximum, cet article contribuera à rendre le travail à distance de votre entreprise plus sûr.
Source: habr.com