C’est quoi le problème ?

Une très, très mau­vaise évo­lu­tion du modèle de sécu­ri­té de Windows. 

Les réseaux ont changé

Dans une autre vie, Win­dows était clai­re­ment scin­dé en deux :

• les envi­ron­ne­ments de bureau, où les ordi­na­teurs étaient atta­chés entre eux en vase clos, et où le risque était plus ou moins facile à contrôler
• les envi­ron­ne­ments rési­den­tiels, où le type de connexion à un réseau externe était très limi­té, typi­que­ment sur un lien télé­pho­nique via modem, lien via lequel les infor­ma­tions tran­si­geaient via des sys­tèmes très limi­tés – les Bul­le­tin Board Systems

Bref, la menace venait plu­tôt de tatas qui télé­char­geaient des logi­ciels pira­tés et les exé­cu­taient direc­te­ment sur leur PC.

Lais­ser l’u­ti­li­sa­teur être maître chez lui et tout bou­siller n’é­tait pas si catas­tro­phique. Win­dows ne se pré­oc­cu­pait donc pas de res­treindre les droits utilisateurs.

Mais aujourd’­hui, l’an­cien réseau en vase close est main­te­nant un réseau mon­dial connec­té en per­ma­nence, et ce même au niveau rési­den­tiel. Les com­mu­ni­ca­tions se passent entre des machines direc­te­ment et non par l’en­tre­mise d’un sys­tème hyper-limité.

Accé­der à un site web, c’est éta­blir une com­mu­ni­ca­tion directe entre son PC et un ser­veur quelque part, duquel on ne connaît abso­lu­ment rien.

Sans par­ler du pour­riel, du mal­ware, ran­som­ware et autres cochon­ne­ries qui se pro­mènent sur ce fameux Inter­net.

La menace est directe

Un rap­port indique que 80% des vul­né­ra­bi­li­tés Win­dows dis­pa­raissent si l’u­ti­li­sa­teur n’a plus de droits admi­nis­tra­teurs.

Il est pra­tique cou­rante dans les envi­ron­ne­ments d’en­tre­prise de reti­rer les droits uni­ver­sels des uti­li­sa­teurs de base dans Windows :

• l’ac­cès à la base de registre
• la capa­ci­té de créer des fichiers, des dos­siers un peu partout
• la liber­té d’ins­tal­ler des logi­ciels de n’im­porte où

Le pou­voir abso­lu sur son PC per­met de faire tout ce qu’on veut, moyen­nant un écran acha­lant de Win­dows qui nous demande de lui don­ner des autorisations.

Ça devrait suf­fire, non ?

Le pro­blème, c’est que cet écran-là, ben il se contourne. L’ap­proche pré­co­ni­sée par Win­dows est de lan­cer un uti­li­sa­teur avec tous les droits mais de ten­ter de les contrô­ler pour empê­cher les pas fins de s’en ser­vir pour tout bousiller.

Ce qui n’est pas sans rap­pe­ler une cer­taine tech­nique de ges­tion du par­ti répu­bli­cain amé­ri­cain qui a mal tour­né récemment…

Alors, ta solution ?

Faut tout d’a­bord ré-acti­ver l’u­ti­li­sa­teur Admi­nis­tra­teur qui est four­ni avec Win­dows, mais désac­ti­vé. Beurk.

On uti­lise donc alors deux uti­li­sa­teurs ; notre uti­li­sa­teur régu­lier (qui n’a plus tous les pou­voirs) et l’u­ti­li­sa­teur admi­nis­tra­teur de Win­dows, qui lui les garde.

Bah, ça fait déjà ça !

Eh, ben, non. Rap­pe­lons-nous que la tech­nique actuelle de Win­dows est de fonc­tion­ner avec les capa­ci­tés admi­nis­tra­tives acces­sibles en per­ma­nence, ce qui per­met aux pas fins de contour­ner les limites arti­fi­cielles de Win­dows et de rou­ler du code en admi­nis­tra­teur, afin d’ins­tal­ler des cochon­ne­ries en sour­dine.

Ok, on fait quoi alors ?

On réactive l’utilisateur administrateur

Via power­shell (ver­sion anglaise de Win­dows – le nom de l’u­ti­li­sa­teur varie selon la langue):

Enable-LocalUser -Name Administrator
Set-LocalUser -Name -Password (Get-Credential) -PasswordNeverExpires $True

… faut main­te­nant four­nir un mot de passe dif­fé­rent de celui de l’u­ti­li­sa­teur prin­ci­pal, com­plexe (8 carac­tères ou plus, lettres, chiffres, etc) mais facile à retenir.

Ensuite, on retire son uti­li­sa­teur des administrateurs :

Remove-LocalGroupMember -Name Administrators -Member {{notre_utilisateur}}

Et … voi­là ! Un tas, tas, tas de vul­né­ra­bi­li­té de sécu­ri­té de reti­rées de Win­dows, et un mode d’o­pé­ra­tion beau­coup plus près du modèle *nix qui marche depuis des lunes…

Cependant…

Ayant for­ti­fié notre envi­ron­ne­ment Win­dows, y’a quelques impacts :

• Deman­der une élé­va­tion va exi­ger l’u­tilli­sa­teur admi­nis­tra­teur et son mot de passe (Win­dows est gen­til et trouve l’u­ti­li­sa­teur admin tout seul, nous faut que four­nir le mot de passe)
• Ce ne sont pas tous les logi­ciels qui sont écrits de manière à deman­der une élé­va­tion lors de leur exé­cu­tion ; si vous uti­li­sez, comme moi, Cai­ro Desk­top en mode shell, fau­dra par­fois lan­cer une copie de l’in­vite de com­mande en admi­nis­tra­teur, en rou­lant : runas /user:Administrator pwsh ou (plus sim­ple­ment, si vous avez l’ou­til) nircmd elevate pwsh.

Voi­là ! Je roule de cette manière sur toutes mes machines per­son­nelles depuis quelques années, et j’y suis plus qu’­ha­bi­tué ; ça limite énor­mé­ment la por­tée de virus et autres pour­ri­gi­ciels poten­tiels, puis­qu’il leur est pres­qu’im­pos­sible de prendre le contrôle du sys­tème à par­tir de mon compte uti­li­sa­teur (sans, bien sûr, exploi­ter une faille directe du sys­tème, et puisque mes mises à jour Win­dows Update sont immé­diates à leur sor­tie, je ne crois pas pou­voir faire beau­coup plus à part ne pas connec­ter ni d’é­cran, ni de réseau, ni de cla­vier à mon PC).