"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.

Skillz

Les mecs auraient du choisir un autre metier...

Et un 42e bug dans xxxCreateWindowEx

Celui merite le detour dans la mesure ou il etait connu depuis 2007:

http://social.msdn.microsoft.com/Forums/en-US/windowsgeneraldevelopmentissues/thread/57c3783b-dd38-4a57-9217-61a920541ad0

En retournant un pseudo handle HWND_TOPMOST dans le champ hwndInsertAfter d'un hook WH_CBT, on aboutit a une violation d'acces, exploitable si l'on mappe l'espace a NULL (difficilement, mais Ronald a fait quelque chose de plus ou moins stable).

Les personnes susceptibles de Googler "windows bluescreen" auront eu un local 0day pendant 3 ans 1/2. Malheureusement, Core Security l'a tue(r), et a ete credite a la place de "JonnyDeep" qui a fait l'effort de le reporter mais n'a pas ete ecoute par MS (ils devraient lire leurs propres forums de temps en temps!).

C'est dingue ce que l'on trouve sur le Windows Developer Center :)

Edit: Et aussi, contrairement a la precedente, la vulnerabilite n'est pas specifiee comme ayant ete connue du public. Duree de vie: 1301 jours (pour ceux qui veulent faire des slides sur les 0days).

"It does on CSI: Miami"

MS10-032, ou pourquoi c'est mal de changer de parent lors de la creation d'un enfant

Dans le bulletin MS10-032, trois vulnerabilites ont ete corrigees: CVE-2010-0485, CVE-2010-0484, CVE-2010-1255. Mais seule la premiere a un indice d'exploitabilite de 1. Il est interessant de constater que personne n'est credite pour la decouverte de cette vulnerabilite, decrite comme etant "Win32k Window Creation vulnerability". De plus, le bulletin specifie que la vulnerabilite a ete portee a la connaissance du public, mais il n'y a pas d'exploit circulant. Etrange.

Une rapide analyse differentielle du binaire (win32k.sys) mettra en evidence le rajout d'un "UnlinkWindow" dans une branche du code qui n'est atteinte que si WM_NCCREATE rate. Les fonctions "LinkWindow" et "UnlinkWindow" sont utilisees pour lier parents et enfants entre eux, pour la transmission de messages, le "Z-ordering", etc. Cependant, la liaison d'un enfant fraichement cree avec son parent n'a lieu qu'apres un WM_NCCREATE ayant reussi. Quel est donc l'interet de de-lier un enfant dont la creation a echoue, a un parent qu'il n'a pas? Tout simplement parceque dans le gestionnaire de WM_NCCREATE, il est possible de faire appel a SetParent() et donc de changer le parent d'un enfant en cours de creation.

Faire appel a SetParent() dans le gestionnaire de WM_NCCREATE et retourner 0, entrainera un cas singulier ou le parent pense qu'il a un enfant mais l'enfant a en fait ete detruit par un xxxFreeWindow(). Certains penseront de suite a un cas d'utilisation apres liberation, mais c'est en fait un chouillat plus complique. Le lien qui existe fait que lors de sa destruction, l'enfant est marque comme detruit mais pas libere. C'est moche, ca nous aurait facilite la tache. On se retrouve alors avec un enfant invisble, marque comme detruit, et qui ne repond a aucun message. Seule specificite de l'enfant, son parent est NULL. Il n'est pas facile de referencer le parent d'un enfant qui n'accepte aucun message. Il faut donc trouver un message a envoyer au parent, qui va etre diffuse a ses enfants, dont le traitement devra entrainer un referencement du parent. Il s'avere que deplacer le parent mettra en branle cette chaine d'evenements et se terminera en ecran bleu.

Quelques commentaires. Je pense que j'ai du rater quelque chose, parceque l'exploitation du chemin que j'ai trouve ne merite clairement pas un "1", c'est plus un 1.5 - 2. Certes on dipose de toutes les informations necessaires localement, mais la primitive que l'on obtient, une addition dans une boucle qui va finir par crasher, est difficilement exploitable. Je reviens maintenant sur le fait que cette vulnerabilite etait connue du public. Il faut remonter jusqu'en 2004 pour trouver une trace de ce bug:

http://www.tech-archive.net/Archive/Development/microsoft.public.win32.programmer.kernel/2004-03/0602.html

microsoft.public.win32.programmer.kernel n'etait probablement pas le bon endroit pour signaler une faille de securite. Neanmoins certaines personnes attentives auront pu beneficier d'une elevation de privileges dans TOUTES les versions de Windows pendant ces 6 dernieres annees...

Edit: Un lien envoye par ivanlef0u sur un doc de taviso sur les parents des fenetres: https://docs.google.com/View?id=dfqd62nk_228h28szgz. Interessant!