Un chercheur trouve un moyen de contourner « Controlled Folder Access »
Une protection anti rancongiciel intégrée à Windows Defender

Le , par Patrick Ruiz, Chroniqueur Actualités
Un chercheur en sécurité a trouvé un moyen de contourner « Controlled Folder Access », une fonctionnalité de Windows Defender présentée pour la première fois au public au mois de juillet dans le cadre du programme Insider. Microsoft a présenté la fonctionnalité comme une protection contre les menaces de type ransomware.

Les utilisateurs qui ont migré vers la Fall Creators Update ont en principe reçu une mise à jour qui installe la fonctionnalité au sein de Windows Defender. Elle permet d’empêcher toute modification de fichiers contenus dans des répertoires désignés. L’utilisateur est responsable de la prise en charge manuelle des configurations nécessaires pour donner l’autorisation à une application d’accéder à des fichiers contenus dans l’espace protégé. À cet effet, ce dernier est muni d’une liste d’exclusion que l’on peut configurer au travers d’une interface similaire à celle qui suit.


La firme de Redmond précise que les logiciels que Microsoft ne considère pas comme un danger sont automatiquement ajoutés à la liste d’exclusions. C’est donc sans surprise que les applications de la suite Office s’y retrouvent. Yago Jesus de la firme SecurityByDefault a fait le même constat et s’appuie sur ce dernier pour pointer du doigt une faille dans la protection antirançongiciel.

Le chercheur explique qu’il suffit d’invoquer un programme de la suite Office comme objet OLE pour contourner la protection. « L’accès est autorisé même si un attaquant se sert d’objets OLE/COM pour piloter des exécutables par voie de programme. Ainsi, un développeur de rançongiciels peut adapter son logiciel pour tirer profit des objets OLE afin de modifier, supprimer ou chiffrer des fichiers en toute furtivité », explique-t-il. Yago a publié un exemple de code Python utilisé pour atteindre cet objectif.

Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
import win32com.client
filetoberansom = r'C:/Users/YJ/Documents/test.docx'
word = win32com.client.Dispatch("Word.Application")
word.visible = 0
doc = word.Documents.Open(filetoberansom)
word.Documents.Item(1).Password= '12345678'
word.Documents.Item(1).Save()
word.Documents.Item(1).Close()
word.Application.Quit()
Microsoft a été notifiée en date du 23 janvier par le chercheur qui a profité pour faire des propositions de correction de la vulnérabilité. Si l’on s’appuie sur les développements du chercheur en sécurité, il vient que le schéma d’exploitation le plus évident de la vulnérabilité requiert un accès au poste cible ; condition pas évidente à réaliser. Il devient plus aisé de comprendre la réaction de la firme de Redmond qui, en date du 31 janvier 2018, a rétorqué au chercheur qu’elle ne considère pas vraiment sa trouvaille comme une faille à proprement parler. Microsoft a néanmoins promis d’apporter des améliorations à son conteneur sécurisé.

Source

Billet Yago Jesus

Votre opinion

Quel commentaire faites-vous du positionnement de Microsoft dans ce cas ?

Voir aussi

Windows : une faille zero-day supposée affecter toutes les versions de l'OS, de Windows 2000 à Windows 10 est en vente à 90 000 dollars US


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de MikeRowSoft MikeRowSoft - I.A. en bêta-test https://www.developpez.com
le 07/02/2018 à 17:47
.bat existera toujours...
Avatar de BufferBob BufferBob - Expert éminent https://www.developpez.com
le 07/02/2018 à 18:36
Citation Envoyé par Patrick Ruiz Voir le message
Un chercheur trouve un moyen de contourner « Controlled Folder Access »
non sans dec ?? alors ça, ça me troue l'oignon ma bonne dame
Avatar de Volgaan Volgaan - Membre averti https://www.developpez.com
le 08/02/2018 à 13:53
Citation Envoyé par MikeRowSoft Voir le message
.bat existera toujours...
Quel est le rapport avec l'actualité ?
Avatar de MikeRowSoft MikeRowSoft - I.A. en bêta-test https://www.developpez.com
le 08/02/2018 à 19:05
Cela n'affecte normalement que le compte de l'utilisateur.
En plus en voyant le script ainsi écrit, je me suis dis que DOS était belle et bien présent sous Windows NT...

Le panneau de configuration en question prend état de tous le PC et pour tous les utilisateurs. Encore un bogue de modèle si il n'y a pas exclusivement un seul utilisateur...
Tu peux essayer avec l'ouverture de session, verrouille ton compte, ouvre en un autre pour lequel la chose affiché à l'écran de verrouillage n'est pas la même. Normalement la dernière session fermé (utilisateur) devrait l'emporté sur la session administrateur (la précédente)...

Profité pour savoir les bogues et défauts en tout genre, j'ai que cela à faire ici...

Windows 8.1 en a vraiment la palme et je comprend pourquoi le passage vers Windows 10 a été proposé gratuitement et aurait même du être mis sur le Windows Store en illimité comme le correctif vers Windows 8.1...
Avatar de Volgaan Volgaan - Membre averti https://www.developpez.com
le 09/02/2018 à 10:00
Citation Envoyé par MikeRowSoft Voir le message
En plus en voyant le script ainsi écrit, je me suis dis que DOS était belle et bien présent sous Windows NT...
Sauf qu'il s'agit de code Python et non de commandes "DOS"
Avatar de chrtophe chrtophe - Responsable Systèmes https://www.developpez.com
le 09/02/2018 à 12:01
OLE a toujours une source de problème pour la sécurité.

Normalement, Word ne devrait pas ouvrir les doc contenant ce type de charge (OLE) en mode protégé ?
Il faudra alors désactiver celui-ci pour que la charge se déclenche. Mais désactiver l'ouverture en mode protégé depuis un doc extérieur est dangereux.

En attendant, le processus de contournement est viable. Un cambrioleur n'attaquera pas une porte blindée si il peut rentrer par la fenêtre.
Avatar de MikeRowSoft MikeRowSoft - I.A. en bêta-test https://www.developpez.com
le 09/02/2018 à 22:12
Citation Envoyé par Volgaan Voir le message
Sauf qu'il s'agit de code Python et non de commandes "DOS"
Oui, c'est juste qu'en voyant le code cela m'a rappelé cette chose en DOS.

Donc l'analyse du code :

filetoberansom = r'C:/Users/YJ/Documents/test.docx' <- r c'est pour read only ? (1)

word.Documents.Item(1).Password= '12345678' <- je suppose qu'il n'y avait pas de mot de passe avant...

word.Documents.Item(1).Save() <- (1) quelque chose a changé ?
Avatar de BufferBob BufferBob - Expert éminent https://www.developpez.com
le 09/02/2018 à 23:54
Citation Envoyé par MikeRowSoft Voir le message
filetoberansom = r'C:/Users/YJ/Documents/test.docx' <- r c'est pour read only ?
non c'est pour une raw string, ce qui en fait n'est réellement utile que quand on met des antislashes dans le chemin, ça évite d'écrire C:\\Users\\YJ\\Documents\\etc., mais comme ici il utilise des slashes simples ça n'est pas très utile

Citation Envoyé par MikeRowSoft Voir le message
word.Documents.Item(1).Password= '12345678' <- je suppose qu'il n'y avait pas de mot de passe avant...
c'est surtout que classiquement un ransomware rend inutilisable les fichiers en les chiffrant, mais mettre un mot de passe dessus peut être une alternative

Citation Envoyé par MikeRowSoft Voir le message
word.Documents.Item(1).Save() <- (1) quelque chose a changé ?
ça montre surtout qu'en écrivant un document via Word on peut lire/écrire là où on veut (y compris dans les répertoires censés être protégés donc), c'est ça le contournement, le composant OLE ne sert qu'à invoquer Word finalement mais on doit pouvoir faire exactement la même chose à coups d'AutoIt par exemple

Citation Envoyé par chrtophe Voir le message
Un cambrioleur n'attaquera pas une porte blindée si il peut rentrer par la fenêtre.
oui, clairement.
Contacter le responsable de la rubrique Accueil