Des pirates exploitent activement deux failles Windows, dont l’une n’est pas corrigée

Entre pas de correctif et deux correctifs

Des pirates exploitent activement deux failles Windows, dont l’une n’est pas corrigée

Deux vulnérabilités de Windows, dont l’une critique, sont activement exploitées. Les pirates s’en prennent particulièrement aux installations Windows Server sur site, dans l’objectif de dérober des informations.

Le 04 novembre à 11h16

Commentaires (25)

votre avatar
En l’absence de correctif pour l’instant, la mesure recommandée consiste à verrouiller les fonctions des fichiers LNK.
A quel niveau ? Du serveur et/ou des postes clients ? Comment on verrouille cela ?
votre avatar
LinkResolveIgnoreLinkInfo ?
votre avatar
A priori LinkResolveIgnoreLinkInfo ne fonctionne plus sous Windows 10 :
How to disable automatic resolution of shortcuts (.lnk files) in Windows 10? Group policies not working
votre avatar
Ah mince.

Et en relisant la CVE, je ne pense pas que ca aurait servi a qqc. La faille n'a pas l'air liée au roaming. De ce que je comprend, le LNK contient plusieurs commandes mais seule la première est visible quand on inspecte les propriétés... les autres commandes sont hors champs (à coups d'espaces).
votre avatar
Quand je pense que j'ai des clients avec des serveurs Windows en directe sur internet avec une IP publique...
votre avatar
Il faut savoir vivre dangereusement :D
votre avatar
Après WSUS ne sert que pour balancer des mises à jours à d'autres ressources, c'est pas une application métier ou une BDD.
15-30 min de coupure pour pousser le patch c'est quoi le soucis pour pas l'avoir déjà fait ?
votre avatar
"Selon l’entreprise de sécurité, une preuve de concept avait été envoyée à Microsoft, mais l’éditeur aurait refusé de corriger la faille, sans que l’on sache pourquoi."

Hum, l'impression que MS ne se dépêche pas car c'est utilisé par des services US ?
votre avatar
Tout simplement car ce n'est pas un bug, c'est une fonctionnalité, dixit la doc du format .LNK:
learn.microsoft.com Microsoft
votre avatar
Selon l’entreprise de sécurité, une preuve de concept avait été envoyée à Microsoft, mais l’éditeur aurait refusé de corriger la faille, sans que l’on sache pourquoi.
Sérieusement, cette sale pub ... Et cette connerie ... (si avéré pour le "aurait")
votre avatar
Du coup, première faille majeure pour Windows 10 qui va lui survivre ad vitaem eternam.

That was fast!

Et donc un foutage de gueule monumental et irresponsable de la part de M$ qui la connait depuis des mois, mais qui ne fait rien, et qui termine tranquilou le support sécurité gratuit de W10, la fleur au fusil....
votre avatar
La faille sera bien entendue patchée pour Windows 10 via le programme de mises à jour de sécurité étendues, et pour les éditions LTSC et IoT LTSC encore supportées.
votre avatar
That was pas fast du tout, la faille est connue depuis déjà un an, visiblement Microsoft ne veut pas la corriger et semble plutôt considérer que c'est au logiciel de sécurité d'y veiller (leur Defender ou un autre) plutôt qu'à l'OS.

Et vu qu'aucun communiqué ne semble préciser de version de Windows concernées, il semble que Windows 11 le soit aussi, ainsi que les versions LTSC de Windows 10, et sans correction prévue non plus.
votre avatar
Les choses ne sont pas si simple. Est-ce qu'il y a un vecteur d'attaque via un fichier .lnk ? La réponse est oui.

Est-ce exploitable facilement ? Non. Déjà, il faut que :
- l'utilisateur télécharge le fichier .lnk (1er redflag)
- l'utilisateur "exécute" le fichier .lnk (2e redflag)
- l'utilisateur passe outre les différents avertissements (fichiers téléchargés depuis internet, etc.) (3e redflag)

En gros, ce n'est pas différent que de télécharger directement un .exe. Bref, .exe/.lnk, c'est la même chose. Que la réponse apportée soit la même n'est donc pas choquant (sécurisé via antivirus et non au niveau de l'OS).
votre avatar
Si on avait eu tôt un équivalent des liens symboliques implémenté au niveau système de fichier, on n'aurait pas la possibilité évoquée de "fichier LNK malveillants contenant des commandes cachées pour déclencher des actions", permise par cet emplâtre sur jambe de bois qui participe à faire de windows un cas d'école de tout ce qu'il ne faudrait pas faire. Les liens soft/hard existant depuis la nuit des temps Unix ont certes été ajoutés (époque XP, venant probablement de NT), mais ils ne semblent guère utilisés... et même pas proposés par défaut depuis quand on veut créer un raccourci.
votre avatar
Les liens symboliques n'autorisent pas la définition du path, le passage d'arguments...
votre avatar
Un lien symbolique/soft pointe directement sur la cible du lien comme si de rien n'était. Donc pas vraiment de limite en terme d'utilisation vs le fichier (exécutable ou non) ou répertoire cible. On n'a même pas la contrainte d'être sur la même partition comme en lien hard (ou on est plutôt dans un alias de nom).

Mais bon, de toutes manières, quand on voit les possibilités offertes niveau montages/fonctionnalités des systèmes de fichier Unices vs Windows, yapaphoto comme on dit.
votre avatar
Je ne suis pas sûr que Microsoft offre moins de possibilité entre les symlinks, junctions, hardlinks et d'une façon générale les reparse points. "Out of the box" tu as sûrement raison.
votre avatar
C'est pas la même utilisation. Les liens symboliques sont là pour qu'un même fichier apparaisse plusieurs fois dans une arborescence, pas pour lancer des commandes prédéfinies.

Quand on crée un raccourci sur un bureau Linux, c'est pareil que sous Windows, on ne crée pas un lien symbolique, on crée un raccourci avec une commande, des arguments, un chemins d'exécution, des paramètres d'exécution divers...

Peut-être que le format LNK de Windows fait un peu trop de choses, mais un lien symbolique n'en ferait pas assez pour cette utilisation, en dehors du simple raccourci vers un dossier.
votre avatar
C'est pas l'utilisation majoritaire... et pour l'utilisation que tu cites, il y a les scripts.
votre avatar
Bien sur que si c'est l'utilisation majoritaire, rien que pour le chemin d'exécution déjà. Et quant à utiliser les scripts à la place, c'est encore pire niveau sécurité car on peut mettre n'importe quoi dedans sans contrainte.
votre avatar
Les scripts ne diffèrent pas à ce niveau des commandes que peut lancer un utilisateur à la main, selon ses droits.
votre avatar
Si c'est l'utilisation majoritaire. Le lien provoque un appel à ShellExecute sur la cible, qui "ouvre" la cible (exécution pour un exécutable). Si tu fais un lien symbolique à la place et que le programme a besoin de fichiers situés dans son répertoire (dll par exemple), ça ne marchera pas (il faudrait au moins que le path soit changé, ou le répertoire courant, et même avec ça ça peut échouer).
votre avatar
OK, j'avais pas compris le truc ainsi (j'ai pas fait bcp de dev Windows... et ca remonte à NT/95!!! Depuis VxWorks puis Linux et aucune envie d'y revenir)... Maintenant, si les applis ne sont pas fichues au besoin de récupérer un path physique (pwd -P sur Unices ; ou via getcwd() de la libc dans un programme compilé) pour ces besoins c'est à mon sens un 2nd pb de conception... qui résulte de ne même pas, à la base, envisager d'être lancé via un lien symbolique arrivé sur le tard chez Microsoft.
votre avatar
pwd -P, oui, parce que getcwd aurait le même problème que le reste, ne pas te donner le répertoire courant.
Bien sûr que les applis n'envisagent pas d'être lancées via un lien symbolique quand il y a un mécanisme dédié depuis Windows 95, et encore une fois, un lien symbolique ne permet pas de passer de paramètres.

Perso sous Linux, je n'utilise pas de symlinks dans le but de faire un raccourci. Pour ça y'a les fichiers desktops, qui permettent de passer des paramètres, définir une icône, le chemin d'exécution (en fait... comme les liens sous Windows).
Pour ça que Inodemus faisait cette comparaison, qui est la bonne.

Des pirates exploitent activement deux failles Windows, dont l’une n’est pas corrigée

  • Une campagne depuis des mois, une exploitation depuis des années

  • Une faille critique corrigée deux fois

Fermer