Bashware : le sous-système Linux menace la sécurité de Windows 10 ?

Le par  |  8 commentaire(s)
W10-Linux

Mise au jour par Check Point, une technique d'attaque est susceptible de berner des solutions de sécurité en s'appuyant sur la mécanique du Windows Subsystem for Linux.

Finalisé dans la préversion de Windows 10, le sous-système Linux pour Windows est une couche de compatibilité pour l'exécution native d'outils Linux en ligne de commande sur Windows 10. Il est possible d'exécuter un environnement Windows et Linux en même temps.

Le mois dernier, Microsoft a comblé des vulnérabilités de sécurité affectant Windows Subsystem for Linux (WSL). De quoi alors s'inquiéter d'une augmentation de la surface d'attaque de Windows…

En début de semaine, Check Point Research a alerté au sujet d'une nouvelle méthode d'infection permettant à un malware de contourner des solutions de sécurité sur Windows 10. Baptisée Bashware, cette technique tire parti de WSL et nécessite des droits administrateur. Bash fait référence au terminal bash utilisé avec WSL.

Selon Check Point, une attaque Bashware peut prendre à défaut jusqu'aux antivirus de nouvelle génération et outils d'inspection. Le problème réside dans des processus Pico qui ont été introduits pour permettre l'exécution de binaires Linux ELF sur Windows 10 dans un environnement isolé.

Microsoft-WLS
Microsoft : Windows Subsystem for Linux

Avec Bashware, la société israélienne de cybersécurité ne pointe pas tant du doigt une faille de WSL, mais le fait que des solutions de sécurité ne vont pas analyser les processus Pico. Un malware dans le sous-système Linux ne serait alors pas détecté.

Plus encore, Check Point présente Bashware comme une technique générique et multiplateforme qui utilise WSL pour permettre l'exécution insidieuse " à la fois de charges utiles malveillantes ELF et EXE. "

Dans une réaction obtenue par The Register, Microsoft minimise l'impact de WSL en tant que vecteur d'attaque, en soulignant notamment que le mode développeur de Windows 10 doit être activé (ce qui n'est pas le cas par défaut), puis il doit y avoir une installation et un redémarrage pour rendre WSL opérationnel.

A priori, rien d'insurmontable pour parvenir à ses fins d'après Check Point qui liste dans un billet de blog des moyens de tromper son monde. La société de cybersécurité note toutefois que Microsoft semble faire le nécessaire afin que les éditeurs de solutions de sécurité prennent en compte un risque potentiel avec WSL. Grâce à des API Pico proposées, il leur suffit de surveiller ces nouveaux types de processus.

Complément d'information

Vos commentaires

Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Le #1979895
Que dire, hormis : MDR
Le #1979901
ce que fait déjà bitdefender heureusement qu'ils n'attendent pas après ce genre de new ( je parle de la faille ! pas de l'article )
Le #1979942
C'est pour les profesionnels
Le #1979954
Ah tiens, on découvre un des trucs rigolos avec les containers (namely: sortir du container pour attaquer le système hôte) sur WSFL ?

Bon, ça nécessite les droits administrateur, et donc j'imagine de lancer WSFL en admin, ce qui équivaut à lancer un container en mode privilégié (lancé par root) sous GNU/Linux, ce qu'on ne fait normalement jamais (c'est pour ça que j'ai jamais mis de Docker en prod avant la version 1.10 qui introduisait - enfin! - le mode non-privilégié (lancé par un user lambda, en gros) et que je m'amusais à reconstruire les images docker en mode privilégié de mes chers devs en containers LXC non-privilégiés).

Du temps du chroot, il était possible de sortir du chroot et de taper dans le FS de l'hôte - c'est toujours possible d'ailleurs - c'est aussi la même dans le cas d'un container privilégié. Un container non privilégié "sortira" dans la session de l'utilisateur qui lance le container, ce qui permet d'isoler un chouia plus. Il est aussi possible de sortir d'une VM pour attaquer directement l'hyperviseur (XEN notamment (paravirt) mais aussi KVM ou HyperV, pas de jaloux) mais c'est nettement plus tricky.

Ça peut sembler vicelard, mais mon mode de déploiement classique sur du baremetal à partir du moment où des containers sont utilisés c'est: baremetal ->hyperviseur (XEN ou KVM) ->provisionner plusieurs VMs (genre une VM pour 4 cœurs) ->poper les containers sur les VMs, ça marche très bien en mode swarm et ça compartimente un chouilla plus tout en permettant un meilleur "fine-graining" de l'utilisation de l'hôte

D'ailleurs, je me demande pourquoi Microsoft n'a pas tout simplement produit une "VM light" pour WSFL plutôt que ce qui ressemble à un container. (Attention, hein, les containers c'est génial, c'est quand même bien sécurisé, mais ça n'est pas non plus une isolation parfaite)
Le #1980158
On nous aurait menti ?????
Linux serait un gruyère.... et aucun antivirus disponible ||||
Le #1980190
Magic2016 a écrit :

On nous aurait menti ?????
Linux serait un gruyère.... et aucun antivirus disponible ||||


Le problème ne viens pas de.linux mais de la manière dont windows l'a intégré
Le #1980191
Lucasd a écrit :

Magic2016 a écrit :

On nous aurait menti ?????
Linux serait un gruyère.... et aucun antivirus disponible ||||


Le problème ne viens pas de.linux mais de la manière dont windows l'a intégré


On est vendredi, faut lui laisser croire que c'est de la faute de Linux
Suivre les commentaires
Poster un commentaire
Anonyme
:) ;) :D ^^ 8) :| :lol: :p :-/ :o :w00t: :roll: :( :cry: :facepalm:
:andy: :annoyed: :bandit: :alien: :ninja: :agent: :doh: :@ :sick: :kiss: :love: :sleep: :whistle: =]