Re: Compléments

Ce que je voulais dire : c'est que le malware est assez malin et sait exploiter correctement les fonctionnalités d'administration de Windows. Je ne vois pas ce qu'il y a d'étonnant à ce qu'un admin puisse modifier des postes clients. Linux a des technologies similaires.

Le problème c'est la complexité des process de maj et l'historique du bazard Windows/AD.

NotPetya a plusieurs moyens de réplication :

• l'exploitation de MS17-10. Ca permet tranquillou de passer SYSTEM à distance et de propager l'infection d'une machine à une autre. Ca se règle par l'installation du patch kivabien. Sur un Windows normal, ça se met gentiment à jour chez MS, ça reboote et le problème est réglé, tout seul comme un grand. Dans les boîtes et les grands groupes ça ne se fait pas comme ça, pour plusieurs raisons : les boîtes essayent d'avoir des reportings qui tiennent la route pour nourrir les équipes opérationnels et le RSSI et être capable de gérer ce qui est déployé et quand (tient, là par exemple avec le dernier patch tuesday, outlook fait chier avec les PDF) pour savoir ce qui va se passer et ne pas déployer n'imp ; il est compliqué de forcer les utilisateurs à rebooter leur machine (si si), nécessaire pour que le patch soit actif. Ces machins sont souvent immondes (kikoo SCCM), et ce process rajoute du temps. Et il y a du déchet. X% de machines ne choppent pas les patchs. Go figure. Pas de bol, les admins sites ont autre chose à faire que courir après les machines qui n'obeissent pas au patch management.
• les partages d'admin, WMI/Psexec et consorts. Ca permet, lorsqu'un compte est compromis avec des droits suffisants sur une machine cible, de lancer l'infection avec des commandes légitimes (et très pratiques - je voudrais que ce ne soit pas possible, mais c'est un autre débat).
• la capacité de choper les crédentials de l'utilisateur, et des autres personnes connectées s'il en a les droits.

Dans le cas présent toute machine compromise par le premier moyen de réplication ayant un compte connecté ayant des privilèges d'admin sur le domaine ou l'OU locale permettait la réplication via le deuxième moyen sur toutes les machines, mêmes patchées.

Et on touche à un des problèmes intrinsèques de Windows, avec sa manie de cacher des trucs partout, à être capable de bien cloisonner les credentials d'admin. Sous Windows, dès que vous avez des droits d'admin locaux, il y a moyen de récupérer en clair les mdps des utilisateurs connectés, y compris de niveau domaine. Il me semble aussi qu'il y a moyen de récupérer des hashs (non salés) de mdp de gens qui se sont connectés précédemment.
Un de ces hashs d'admin est rejouable pour des raisons de compatibilité, donc si deux machines ont le même mdp sur ce compte, on peut se propager de machine en machine jusqu'à tomber sur un compte d'admin domaine (game over).

Du coup, comment on fait pour se protéger de ça ? Les solutions sont connues et poussées par MS :

• Un mot de passe différent pour chaque compte "Administrateur" et renommage de ce dernier;
• Interdiction aux admin domaine de se connecter en local et via le réseau sur des PDT pour sanctuariser ces comptes
• Interdiction des communications machine à machine.

Sauf que c'est compliqué à faire, surtout quand on parle de petites structures. (et par défaut, cela reste possible)