Certains de nos spécialistes de la sécurité technique ont assisté à la conférence sur la sécurité Hack.lu du 16 au 18 octobre, afin d'acquérir des connaissances et d'apprendre de nouveaux trucs et outils.
Geert Smelt a rendu compte de l'exposé "Abusing Bash for Windows" d'Antoine Cervoise sur , qui expliquait comment utiliser bash sous Windows (Cygwin, WSL) pour l'escalade des privilèges et la post-exploitation.
Sous-système Windows pour Linux (WSL)
Avec le nouveau PDG de Microsoft Satya Nadella vient une toute nouvelle direction pour Windows. Nadella a exprimé son soutien à Linux et le premier résultat visible est la sortie du Windows Subsystem for Linux (WSL) -- communément appelé Bash for Windows. Il s'agit d'une couche de compatibilité pour l'exécution d'exécutables binaires Linux en mode natif sur Windows 10 et Windows Server 2019 et a été publié pour la première fois en août 2016 (1).
WSL fournit une interface de noyau compatible avec Linux développée par Microsoft (ne contenant aucun code de noyau Linux), qui peut ensuite exécuter un espace utilisateur GNU par-dessus, tel que celui d'Ubuntu, d'openSUSE, de SUSE Linux Enterprise Server, de Debian et de Kali Linux. Un tel espace utilisateur peut contenir un shell et un langage de commande Bash, avec des outils de ligne de commande natifs de GNU/Linux (sed, awk, etc.), des interpréteurs de langages de programmation (Ruby, Python, etc.), et même des applications graphiques (en utilisant un serveur X11 du côté de l'hôte). Il peut être considéré comme le pendant de Wine (2).
Vulnérabilités du WSL
Au départ, seule une image Ubuntu était disponible, mais avec la version 1709 de Windows 10, Fedora et SUSE ont été ajoutés. Maintenant que WSL a atteint une certaine maturité, nous examinons les vulnérabilités qu'il apporte. Antoine Cervoise nous présente les différentes faiblesses qui ont été découvertes dans WSL. La principale difficulté liée à la sécurisation du WSL est qu'il permet à un utilisateur d'exécuter des commandes Linux et Windows sur le même système de fichiers. Cela signifie que si un fichier n'est pas lisible sous Linux, il peut l'être sous Windows et vice versa. L'un de ces exemples est le fichier /etc/shadow sous Linux, qui stocke tous les hashs de mots de passe des utilisateurs ayant un compte sur le système. Ce fichier n'est généralement lisible que par l'utilisateur root, qui est l'équivalent de l'utilisateur Administrator sous Windows. Sur un système sur lequel WSL est installé, le fichier ne peut pas être lu par un utilisateur non root, mais lorsque vous naviguez vers le fichier shadow dans le système de fichiers Windows, son contenu peut être visualisé. La principale faiblesse de ce système est que les hachages correspondent à des mots de passe qui sont valides à la fois dans le système de fichiers Linux et dans le système de fichiers Windows. Il est évident que cela crée un autre vecteur d'attaque pour obtenir les mots de passe des systèmes qui ont été compromis.
Outre la lecture de fichiers, les exécutables Windows peuvent également être appelés à partir de Linux. Cela permet par exemple à l'utilisateur d'exécuter un processeur d'invite de commande dans l'environnement Linux. Il convient également de noter que la plupart des logiciels antivirus ne peuvent pas inspecter le WSL, ce qui ouvre un vecteur d'attaque permettant d'établir une persistance sur un système déjà compromis par le biais de logiciels malveillants exécutés à partir du WSL. Pour que ces logiciels malveillants réussissent, ils doivent avoir une architecture 64 bits. En outre, le gestionnaire de tâches de Windows indiquera que bash.exe est en cours d'exécution, mais pas le processus réel qui s'exécute au sein du WSL. Pour éviter que le processus ne s'arrête, il peut même être exécuté dans une session tmux (mais pas à l'écran).
Authentification SMB et fausse commande sudo
Une autre méthode pour obtenir des identifiants consiste à utiliser l'authentification SMB. Considérez par exemple l'inclusion d'une commande dans la configuration du shell Linux qui est exécutée chaque fois que l'utilisateur entre dans le shell. Si l'interpréteur de commandes tente de se connecter à un dossier partagé sur le réseau, la tentative d'authentification SMB de ce partage peut être écoutée à l'aide d'un outil appelé Responder. Le hachage qui est alors trouvé peut être craqué afin de récupérer le mot de passe en clair, ou peut être rejoué pour s'authentifier auprès d'un autre serveur sur le réseau au nom du système de la victime.
Une autre idée intéressante de Cervoise est l'utilisation d'une fausse commande sudo. Cervoise crée un script qui imite le comportement de sudo et le place dans la variable PATH de l'utilisateur, avant que le binaire sudo réel ne soit trouvé. Cela lui permet d'écraser le comportement par défaut et le mot de passe de l'utilisateur. Notez que cette attaque n'est pas limitée à WSL, mais qu'elle peut également être réalisée sur un système Linux classique.
Enfin, WSL peut être utilisé pour contourner AppLocker, l'élément de Windows qui empêche l'exécution de tout exécutable ne figurant pas sur la liste blanche. Cervoise n'entre cependant pas dans les détails.
Le WSL étant relativement récent, il est fort probable que les premières vulnérabilités commencent à apparaître. Il ne fait aucun doute que d'autres vulnérabilités seront découvertes et publiées dans un avenir proche, car de plus en plus de développeurs et d'administrateurs système commenceront à l'utiliser dans leur travail quotidien.
Chez Bureau Veritas Cybersecurity, nous suivons de près l'évolution de ces vulnérabilités afin de les intégrer à notre gamme d'outils, pour vous garantir le meilleur service possible. Cliquez ici si vous souhaitez approfondir vos connaissances sur le codage sécurisé.
1. https://docs.microsoft.com/en-us/windows/wsl/faq
2. https://mikegerwitz.com/2016/04/GNU-kWindows