SMBv2 Exploit Video

http://www.immunityinc.com/documentation/smb2.html

Quelques commentaires:

• Cet exploit releve de la magie noire plus que d'autre chose. Il est vraiment beau. Vraiment. J'en pleurerais tellement il est beau.
• Le coup du RDTSC n'est pas une blague. On verifie l'uptime de la machine via une requete Negotiate SMBv2 standard, la reponse inclut le BootTime et CurrentTime du serveur. En fonction, on lance l'exploit. Si le RDTSC est trop haut, reboot et zou.
• Ca fait plaisir de bosser avec des gens comme Skylar et Toto, ca rend la vie plus facile.
• Pourquoi SP2 seulement? Parceque dans le SP1 une des structures dont nous avons besoin n'est pas alignee sur 8 octets, et ca fout en l'air la technique. Mais on travaille a une solution :)
• Il reste du boulot sur cet exploit, mais je suis sur un PenTest pour le reste de la semaine :(

Edit: Dave va refaire une video parcequ'il trouve la mienne toute pourrie. La faute au multimedia sous Ubuntu! Ca droppe des frames a gogo.

Exploit SMBv2 distant pour Vista!

On a un int3 fiable sur un Vista SP2 :) Et ca passe au travers de l'ASLR, etc. Reste a caser un shellcode dedans. Et a rooter du 2008 Server en attendant qu'un patch sorte un jour, peut-etre. Le prochain MS Tuesday est dans 3 semaines++, donc s'il font pas un out-of-band, ca va saigner! Ah, si seulement j'etais un pirate... Enfin bon, on arrive en fin de journee ici, donc on finira ca demain.

Gros bravo a Nicolas P. qui a reussi a comprendre mon code :)

Un peu plus pres du remote

Maintenant on transforme le call srv2!ValidateRoutines[i] en call x (avec ici x=0x42424242) en remote (un seul paquet). Le probleme c'est l'ASLR. C'est sympa de pouvoir appeler quelque chose qui va toujours etre au meme endroit, mais ca ne sert pas a grand chose dans Vista++. Le progres par rapport au Local, c'est qu'on est plus oblige d'appeler 0x00000000. C'est beau. Mais c'est pas gagne encore.

Quelques pensees en vrac sur la vulnerabilite SMBv2

• Il est dommage de poster une vulnerabilite de ce type au grand public sans vraiment savoir quelles en sont les consequences. Si vous ne savez pas quoi faire de vos vulnerabilites, je peux vous en racheter les "droits", surtout qu'avec un peu de temps dessus, on peut en faire quelque chose de beau.
• Pourquoi pas un Local et pourquoi ce n'est pas boiteux? Il s'avere que contrairement a la plupart des bugs qui aboutissent a une elevation de privileges, l'utilisateur ici ne controle pas la memoire du processus userspace qui joue a touche-pipi avec srv2.sys. Ie.: pas possible d'allouer a 0 et de sauter a 0. Tout le monde doit maintenant connaitre la primitive du bug (call srv2!ValidateRoutines[i] avec 0<=i<=65535), et tout le monde a du penser a un moment qu'il etait facile d'avoir un pointeur vers 0 dans la section .data. Oui c'est facile, non c'est pas exploitable de la sorte vu que vous ne controllez pas ce qui est 0 (qui sera non mappe). Et pareil pour toute adresse du userland. ALSR = pas gagne.
• ASLR noyau, ASLR en espace utilisateur, ca vous rend la vie compliquee. Tres. Et meme si vous avez des vulnerabilites a la con comme celle-la dans Vista, ca sera toujours mieux que d'avoir XP. Vraiment. Le seul truc qui manque, c'est le NX noyau.
• Au final il aura fallu ~2 jours (2*8h) de boulot pour faire un local (et oui je faisais le guignol a NY quand c'est sorti), le remote probablement le triple, si tant est que cela soit possible.

Edit: le lien vers le site de CEU: http://www.immunityinc.com/ceu-index.shtml

Exploitation de la vulnerabilite SMBv2

Cela faisait un moment que je n'avais pas eu l'occasion de me faire les dents sur une chouette vulnerabilite. Quelque chose qui resiste, mais qui finit par casser, apres suffisamment d'efforts. De nos jours, soit on tombe sur quelque chose d'infaisable, soit sur une injection de commande version 1992AD.

L'exploitation de la vulnerabilite est extremement interessante, car elle requiert une facon de penser completement differente. Alors que certains s'interessent a des techniques plus "classiques", je me suis brise les synapses sur un autre moyen, mais qui se revele plutot lucratif au final. Le resultat est un local fiable (sur Vista SP1 a jour, SP2), et peut-etre un distant dans les jours qui viennent :) (Si on me colle pas sur du consulting!)

Edit: Output de l'exploit local: http://pastebin.com/m6c7d30ce (ca sauve de la place)

"Exploitability Index" ou comment perdre son (mon) temps

Depuis quelques mois deja, Microsoft a rajoute un "Exploitability Index" a ses bulletins mensuels. Cet indice d'exploitabilite est decrit sur cette page. Il consiste en un simple chiffre:

1. Consistent exploit code likely
2. Inconsistent exploit code likely
3. Functionning exploit code unlikely

Le modele a fait l'objet d'un papier du sieur Bas Alberts (disponible ici). Et les gens de Microsoft se plantent rarement dans leur analyse. Un post du "Silver Surfer" Mike Reavey couvre le sujet en analysant un mois de bulletins et d'exploits.

Somme toute, il s'agit d'une bonne metrique si vous voulez prioriser un patch lors d'un Microsoft Tuesday, soit en tant qu'administrateur soucieux de securiser votre reseau, soit en tant que "differ" soucieux d'avoir un exploit fonctionnel au plus vite.

La ou le bat blaisse pour moi, c'est quand Microsoft se plante. L'erreur n'est pas dans la sous evaluation du risque, mais dans la surevaluation.

Prenons l'example du Microsoft Tuesday de Juin 2009. Plusieures failles interessantes (comprenez anonymes distantes), dont MS09-018 et MS09-022.

Le second bulletin, ciblant le service Spooler a ete boucle en moins de deux heures pour la version 2000 (XP n'est que local d'apres le bulletin).

Le premier touche Active Directory, comprend 2 failles, un free() invalide et une fuite de memoire. Un free() d'un pointeur sous votre controle, c'est exploitable sous Windows. Et l'indice d'exploitabilite pour cette faille etait de 1 (cf. blog du MSRC). Donc Toto se met au boulot histoire de voir de quoi il retourne. Apres quelques heures de lecture intensive de lignes d'assembleur et d'envoi de paquets LDAP, il annonce "Je ne vois pas comment ca peut etre exploitable ...". Je regarde, pas mieux.

La primitive du bug est un free(pointeur+X) avec 1<=X<=6, et le pointeur est fixe pointant sur des donnees sous votre controle. Un tel bug pourrait etre exploitable si X=8, 16 ou 24, etc. Par contre si (pointeur+X)&7!=0, RtlFreeHeap() vous envoie chier joyeusement et rien ne se passe. Pourquoi cet indice d'exploitabilite de 1?? C'est rageant, on continue a bosser dessus en pensant qu'on a rate quelque chose. Et puis aujourd'hui, on voit sur le bulletin:

V1.1 (June 10, 2009): Corrected the rating and key notes for CVE-2009-1138 in the Exploitability Index.

Alors la. L'indice de 1 est passe a 3, et une petite ligne a ete ajoutee:

However, due to additional checks on the heap, a functioning remote code execution exploit is very unlikely.

C'est moche :( Resultat je ne vais plus faire trop confiance a leur "Exploitability Index"...

Edit: extrait du bulletin iDefense:

06/05/2009 - Microsoft informs iDefense that the Bulletin was promoted
to potential Code Execution
06/08/2009 - iDefense requests clarification, offers further insight
06/10/2009 - iDefense reiterates request
06/10/2009 - MS Responds that they agree that code execution is very
unlikely and will change the Exploitability Index
06/11/2009 - MS Changes Exploitability Index from 1 to 3
06/11/2009 - Coordinated public disclosure

Les "Certifications"

Aujourd'hui je recois un mail d'un mec qui veut des informations a propos de VMware. La personne en question est CISSP, SANS GCIA, MCSE, CCSA, CCSE, CSA, CCNA, et CNA. Ca fait beaucoup. Les questions sont: Et votre exploit il fait quoi??? Et ca marche sous ESX???

Donc apparemment plus avez de certifications, moins vous savez utiliser Google. Et ca semble diminuer d'autant votre comprehension de l'Univers aussi. Et les questions (ou leurs reponses pour etre exactes) sont destinees a etre ajoutees a des slides pour une presentation ayant lieu dans 2 semaines a une grosse conference.

C'est pas mal de decouvrir ce qui se passe deux semaine avant. Ca doit etre ce qu'on appelle la veille.