"Cyber guerre", 42e edition, et fichiers MOF

Ces derniers deux derniers jours, les medias americains grand public (a savoir les journaux televises que je regarde) ont consacre une part non negligeable de leurs efforts journalistiques a Stuxnet. La raison: le NY Times donne la paternite du ver aux Israeliens (ou pas du tout si on lit l'article). L'attrait du commun des mortels pour les histoires d'espionnage fait le reste. Trois jours plus tot on trouvait une information similaire sur des blogs eclaires. Sur Le Monde, l'hypothese de l'operation marketing surgit aussi.

Meme si je n'ai pas d'information sur l'instigateur de l'operation, je peux cependant offrir quelques details techniques sur l'aspect exploitation du ver. Nicolas a passe cette derniere semaine a jouer avec Stuxnet, et a extrait et reecrit les deux 0days restant, non encore publies (disponibles aux clients Early Update de CANVAS). Des details sur ces vulnerabilites sont publics, le 1er utilise un fichier de "keyboard layout" specialement concu pour aboutir a l'execution de code en Ring0 sous Windows 2000 et XP, le 2nd utilise une vulnerabilite du "Task Scheduler" sous Vista et 7 pour elever les privileges d'un utilisateur local. Ajoutons a cela un faux 0day du Spooler d'impresssion de Windows, et celui des fichiers .LNK, et nous obtenons un bon cyber arsenal au format .exe. C'est d'autant plus beau que les auteurs de Stuxnet l'ont lache dans la nature, reduisant considerablement la duree de vie potentielle de leurs 0days. C'est culote, mais le jeu devait en valoir la chandelle.

Dans un post precedent, j'evoquais un moyen d'executer du code en deposant un fichier dans un repertoire privilegie de Windows. Lors de l'ecriture de l'exploit MS10-061, je ne savais pas quelle technique utilisait Stuxnet - une lecture posterieure des divers documents disponibles m'apprendra que nous utilisons la meme: les fichiers MOF. Le "Managed Object Format" est documente sur le MSDN, et permet entre autres d'instrumenter WMI. Usuellement, pour executer un MOF, un utilisateur devra faire appel a mofcomp.exe. Cependant Windows offre une fonctionalite interessante: un sous repertoire de system32 est surveille, et tout fichier depose dedans sera automatiquement compile (system32\wbem\mof). Un des avantages de MOF est la possibilite d'y inclure du VBscript, et d'executer le dit script en tant que LOCALSYSTEM. Differents exemples de fichiers MOF peuvent etre recuperes sur le MSDN. On melange le tout, et on obtient la transformation d'une primitive d'ecriture de fichier dans un repertoire privilegie en execution de code immediate.

C'est beau la cyber guerre.

MS10-068: indice a 1, mais pas vraiment?

Apres en avoir plus ou moins fini avec la vulnerabilite du Spooler de Windows, je me suis attaque a celle de LSASS/AD, MS10-068. En regardant le resume des bulletins de Septembre, on peut voir que cette vulnerabilite a ete credite d'un indice d'exploitabilite de 1. Lorsque l'on regarde la FAQ du bulletin on peut lire:

Most attempts to exploit this vulnerability will cause an affected system to stop responding and restart.

Ca sonne plus comme une exploitabilite de 2+. Une analyze differentielle de ntdsa.dll montre plusieurs fonctions modifiees, dont 2 semblent correspondre a la description de la faille donnee dans le bulletin (encore une fois, peut-etre ne faut-il pas s'y fier): LDAP_REQUEST::GetSealHeaderField et LDAP_REQUEST::DecryptSignedOrSealedMessage. Il faut effectivement etre authentifie pour pouvoir sceller un message LDAP (une sorte de chiffrement MS qui se base sur une clee derivee de la negotiation NTLM). Le correctif est simple pour ces fonctions: verifier que le champ longueur du buffer SASL ne deborde pas lorsqu'on lui ajoute 4.

Un test avec une longueur de 0xfffffffc entraine une corruption du tas, et une violation d'acces en lecture lorsque la fonction de dechiffrement en atteint la fin. Cela merite plus de recherches, mais a premiere vue, je ne suis pas persuade que ce soit tres exploitable.

Stuxnet et ses quatre 0days

Je n'ai personnellement pas regarde Stuxnet, je me contente de reporter le nombre tel qu'on a pu le voir sur certains sites. Outre les fichiers .lnk qui ont fait coule de l'encre le mois dernier, on apprend ce mois ci que Stuxnet exploitait aussi une vulnerabilite 0day du Spooler de Windows pour se propager sur le reseau (local?). Un article du blog de Kaspersky illustre cela. Quatre 0days, backdoor industrielle, ca ne deconne plus. Quelqu'un (je prends les paris quant au gouvernement concerne) a du perdre beaucoup lorsque son petit prodige a ete porte a l'attention du public.

J'ai pu travailler ces deux derniers jours sur MS10-061, et bien que la vulnerabilite soit relativement simple, elle n'en est pas moins efficace. Etant donne un acces a une imprimante partagee (soit anonymenent, soit via un compte Guest ou des imprimantes antediluviennes), il est possible d'entrainer la creation arbitraire d'un fichier sur le disque systeme en tant qu'utilisateur privilegie. Il est aussi possible d'en maitriser le contenu. Maintenant la problematique d'ou et quoi ecrire se pose. Comment obtenir execution de code (ou d'une commande shell) de facon quasi immediate en deposant un fichier, tout en faisant preuvre d'un tant soit peu de finesse (eviter de remplacer un executable ou une bibliotheque)? L'immediatete recherchee exclut l'utilisation des repertoires lies au demarage de l'OS (bien que cela reste une solution valable pour le long terme).

En cherchant a droite et a gauche, je suis tombe sur le Task Scheduler de Windows. Chose que je ne savais pas, il est possible de deposer des fichiers .job directement dans %WINDIR%\Tasks, et ils seront pris en compte par le service de CRON de Windows. Le format des fichiers .job est definit dans le MSDN. J'ai tente de deposer des fichiers crees par mes soins (mais non signes) via la vulnerabilite Spooler, et l'execution a toujours echoue (probleme de droits d'acces que je n'ai pas pu resoudre dans le fenetre temporelle impartie). Un petit soucis de synchronisation se pose aussi.

La solution retenue pour l'exploit CANVAS utilise un autre format de fichier, a un autre endroit, et j'en dois la connaissance a Sinan - plus d'information sans doute plus tard. Je ne sais pas quelle technique Stuxnet utilise pour cet exploit, toujours est-il que ce ver place la barre assez haut en terme de technologie offensive.