#hzv 1 released !

#Hzv 1 est enfin out !
Après plusieurs mois d'attente, le voici enfin sortit.
J'y ai publié mon plus gros article concernant l'exploitation des stacks overflows sous windows.
Je reprends un des articles publié sur mon blog, en le peaufinant, en ajoutant des illustrations des jolies phrases :D . De tous cela découle bien sur un contenu bien plus riche.
Un article qui m'a pris énormément de temps à écrire enfin bref j'y ai mis du coeur :)).

Maintenant je vous laisse en compagnie du premier opus : Hzv#1.
Je remercie donc tous le staff pour leur travail (même si dans le sommaire se sont plantés dans mon pseudo :p).
Je posterais un petit feedback des articles une fois que je les aurais lu :).
Bonne soirée à tous !

Après demande de certains, je mets à disposition l'archive de mon paper contenant, les illustrations, et les codes ;).
En espérant qu'ils vous plaisent :
-Stack Overflow.rar

Je vous parlais d'un petit feedback quant aux écrits ; le voici celui-ci à été rédigé conjointement avec sh4ka :

• 1ère article) Le codage des données par celelibi.

Un article clair, concernant ce qui se cache vraiment derrière toutes nos variables ; car c'est bien jolie de savoir coder en C mais savoir comment est codé notre information peu s'avérer très utile voir fondamentale.
Il explique très bien l'abstraction (par rapport au codage de ces données) que nous fournissent les langages de programmation avec les types de variables par exemple.
Autrement dit qu'un long c'est pareil qu'un int ou qu'un DWORD : c'est 4 octets d'informations !
Je le recommande donc à ceux qui ne s'y sont jamais intéressé.

• 2ème article) Exploitation avancée de débordement de tampon par camille bertrand.

Cette article plutôt technique va nous parler de débordement de tampon ; mais aussi de shellcodes.
En effet, j'ai l'impression que l'auteur se centre plus sur l'élaboration de shellcode générique / polymorphisme que sur l'exploitation avancée de la faille.
Il nous explique clairement les étapes essentiels à l'élaboration d'un shellcode capable de se débrouiller seul (dit générique) dans un environnement windows.
Les codes sont clair ; très commentés ; bien illustrés..il nous propose même un petit exercice d'application en fin d'article.
Conclusion l'article est très didactique, un bon papier.

• 3ème article) Redirection de flux en C sous windows par Cocowebman.

Encore un article pour windows (décidément :)), il illustre un type de communication inter processus : les pipes (prononcé à l'anglaise).
Il redirige les sorties standard dans le tuyau dans lequel il va lire par exemple ; très utile dans un bind/reverse shell par exemple.
L'article est encore une fois agréable à lire ; des illustrations ; c'est mimi en tout cas.

• 4ème article) La toile à nue face au renard par FaSm et SnAkE.

Un article décevant, le contenu est plutôt très classique et donc n'apprenant pas grand chose au lecteur.

• 5ème article) Nintendo DS Le wifi Ultra Portable par Virtualabs.

Alors cette article c'est vraiment mon coup de cœur ; moi qui attendait une espèce de compte rendu de sa conférence à la nuit du hack ..et bien me voilà gâter.
Une superbe aventure en fait ; il nous explique un peu son cheminement, ces objectifs, ce qu'il a réussit à faire (impressionnant :o) enfin j'en dévoile pas plus lisez le ! merci virtualabs.

• 6ème article) Attaque d'un serveur, Prise d'empreinte par Floux.

Article de Floux présentant l'étape préliminaire à un audit,et non des moindres, la prise d'empreinte. L'article survole (peut être un peu trop) les principes classique de ce domaine, sans trop entrer dans les détails(Whois,traceroute,dns,transfert de zone,scan de port,..).Un article plus poussé sur le sujet aurait été apprécié.

PS:"La prise d’empreinte (ou pentest pour les intimes ;))"

Prise d'empreinte=Fingerprinting pas pentesting

• 7ème article) Démystification d'exploits visant des applications web par Apophis.

Derrière ce titre se cache l'explication d'apophis, concernant une vulnérabilité touchant punbb au travers de la récupération du "cookie_seed" ; afin de calculer le mot de passe aléatoire ainsi que le lien d'activation généré par punbb lors de la réinitialisation d'un compte (suite à l'utilisation de l'option "mot de passe oublié").Par l'étude de cette faille et la programmation de l'exploit, l'auteur nous montre les vulnérabilités touchant au web sous une autre forme que les classiques injections sql,xss,include et cie.

• 8ème article) Les réseaux de robots, action et prevention par Valéry RASPLUS.

Il s'agit d'un article survolant le monde des botnets, expliquant leurs principes, leurs méthodes, leurs buts et proposant aussi des pistes pour s'en protéger. L'auteur sans rentrer dans la partie technique, permet d'expliquer de façon simple et donc de sensibiliser l'utilisateur sur les dangers que peuvent apporter les botnets.

• 9ème article) La stéganographie de interger binary numbers par Thierry Crettol.

Un article qui je dois dire me laisse perplexe, l'auteur utilise un vocabulaire « spéciale ». Je cite: « les 54 premiers caractères sont réservés pour le cartouche de l'image bmp », ici cartouche signifie header? Ensuite d'après ce que j'ai pu comprendre, il s'agit en fait de steganographie utilisant la technique des LSB dans les images bmp. Malgré que ce sujet soit intéressant, ici le manque de clarté de l'explication et surtout d'exemple par la mise en place du procédé par la programmation, gâche un peu l'article.

Voilà, conclusion le mag reste intéressant malgré 2/3 bémols comme la qualités des images etc.

Bonne lecture, et espérons que ces bémols seront corrigés dans le prochain !

Feel the power with TDI !

N'avez vous jamais pensé à avoir un support réseau pour votre merveilleux rootkit ?
Avoir la main sur cette bête même à distance ?

Je vais aujourd'hui réaliser votre rêve :)), plus sérieusement ce post traitera de l'une des interfaces proposées par microsoft pour nous permettre de faire du réseau ; et celle-ci porte le doux nom de TDI acronyme de "Transport Driver Interface".
Je cite microsoft techNet :

"The Transport Driver Interface (TDI) is a common interface for drivers (such as the Windows 2000 redirector and server) to use to communicate with the various network transport protocols. This allows services to remain independent of transport protocols."


Il faut déjà savoir qu'il existe plusieurs manières d'accéder aux ressources réseaux du kerneland
; c'est différent moyens sont implémentés ou pas selon la version de windows :

• Avant les systèmes vista, nous avions à disposition TDI ainsi que NDIS acronyme de Network Driver Interface Specification.
• Sous vista nous avons à disposition TDI, NDIS et les Kernels Sockets.
• Et puis il est prévu de troquer TDI contre les Kernels Sockets pour les autres systèmes qui suivront vista ; autrement dit on ferra du reseau avec NDIS ou/et les Kernels Sockets.

J'ai donc choisis l'utilisation de TDI pour tout d'abord avoir une espèce de rétro-compatibilitée avec "l'avant vista" ; de plus l'utilisation de TDI est assez simple car les opérations à réaliser suivent un même schéma que je detaillerais plus bas.
L'utilisation de TDI est d'ailleurs très bien documentée ; non pas par la masse des écrits sur le sujet mais par la qualité des quelques papers trouvés.
Je veux bien sûr faire références à deux écrit :

• Subverting The Windows Kernel , chapitre "Kernel TCP/IP Support for Your Rootkit Using TDI"
• Audi-K - Nouvelles aventures en Kernel Land, paper parut dans le zine des blackclowns ; c'est un S.U.P.E.R.B.E article écrit par Tolwin ..pour couronner le tout c'est du français.Cette article est donc juste priceless, merci à lui.

Ces deux écrits permettent largement de se coder un petit Proof Of Concept quant à l'utilisation de TDI.
J'ai donc choisis de mettre en place une connexion à la manière d'un classique Reverse Shell ; autrement dit un serveur hébergé chez le h4ck3rz, le driver s'y connecte et propose des fonctions exécutées chez la victime tout cela sous forme d'un shell avec un jolie prompt toussa :D.
Seulement ce qui m'a intéressé dans ce code c'est l'implémentation de la partie reseau, vous comprendrez donc pourquoi je n'ai codé aucune fonction entrant dans le cadre du reverse shell ..c'est un travail on ne peux plus fastidieux ; de plus ce n'etait pas le but ! Au passage si quelques d'entre vous sortent leurs jolies IDEs avec comme objectif de rendre mon bout de code utilisable..ben qu'ils me previennent :D.


Entrons dans le vif du sujet ; chers passagers je vous prie de bien vouloir boucler vos ceintures, le voyage va bientôt commencer !

Comme je le disais un peu plus haut, TDI s'avère assez simple, peut-être un poil velus au départ mais au fur et à mesure que l'on code on se rend vite compte que les principales opérations sont redondantes.
Il faut aussi savoir que jouer avec TDI, c'est accepter de dealer avec le driver tcpip.sys.
Si on fouille dans les tools signé OSR, on peut tomber sur DeviceTree ; un outil assez pratique pour observer l'organisation des drivers, devices et autres :



Vous vous doutez bien que nous allons nous occuper du driver tcp, seulement lui !
On remarque aussi au passage que le device est en mode IO_DIRECT ; autrement dit le buffer d'entré et de sortie sera le même ; aucun gaspillage quant à la manipulation/recopie de ceux ci etc.
Le code va donc se résoudre à de multiples échanges entres le driver, et le notre par le biais d'IRP.
En effet, notre code se résout à , préparer une requête (l'IRP), l'envoyer au driver, bloquer pendant que le driver traite notre requête, et puis agir en fonction du code de retour.
Tout cela est simplifié mais dans l'idée c'est exactement ce qu'il faut faire ; microsoft nous propose alors un lot de macro tel que :

• TdiBuildSend
• TdiBuildReceive
• TdiBuildConnect
• TdiBuildInternalDeviceControlIrp

Entrons un peu plus dans les détails maintenant.
Les deux premières étapes consistent en la création de deux objets, un "Connection Object" ainsi qu'un "Transport Object" l'un servant à stocker les informations relatives a l'host et au port (le TransportObject donc) ; et un second objet gérant la connection (le Connection Objet).

Ces objets seront créés grâce à la fonction ZwCreateFile ; pour mener à bien la construction de ces objets ont doit passer des paramètres à la fonction qui va gérer la construction des objets contenu dans le driver bien sur.
Ceux-ci seront passé par encapsulation dans une structure du type FILE_FULL_EA_INFORMATION ; dans l'avant dernier argument de ZwCreateFile "EaBuffer".
Voici la définition de la structure :

typedef struct _FILE_FULL_EA_INFORMATION
{
ULONG  NextEntryOffset;
UCHAR  Flags;
UCHAR  EaNameLength;
USHORT  EaValueLength;
CHAR  EaName[1];
} FILE_FULL_EA_INFORMATION, *PFILE_FULL_EA_INFORMATION;

Je m'explique quant à cette histoire d'encapsulation ; le but est de pouvoir passé plusieurs structures au driver.

1. On alloue la mémoire total, c'est l'addition des tailles des structures à faire passé en argument plus la structure de type FILE_FULL_EA_INFORMATION.
2. On remplis les premiers champs de la structure : NextEntryOffset, Flags etc.
3. On écrit à la suite du dernier champs (EaBuffer) le contenus de nos structures.

Voilà le principe, la structure de type FILE_FULL_EA_INFORMATION englobe les autres, c'est le principe.

Je noterais EA la structure qui sert d'encapsulation.
Pour le Connection Object nous avons le schéma suivant :

• [EA -> CONNECTION_CONTEXT]

Pour le Transport Object nous avons :

• [EA -> TA_IP_ADDRESS]

Je ne sais pas si j'ai réussi à comprendre, mais j'ai fais de mon mieux, c'est pas facile :].

Bon voilà c'est beau, c'est magique, de la véritable poudre de perlinpinpin mais notre voyage est loin d'être terminé.

Il faut ensuite associer ces deux handles..à partir de cette étape le chemin restera toujours le même :

1. Allocation de l'irp, grâce à la macro TdiBuildInternalDeviceControlIrp.
2. Construction de l'irp par le biais de la macro associée à l'action désirée (TdiBuildSend, TdiBuildReceive, TdiBuildAssociateAddress etc).
3. On transmet l'irp au driver en utilisant la fonction IoCallDriver.
4. On bloque tant que le traitement n'est pas terminé avec la fonction KeWaitForSingleObject.

C'est en fait le schéma dont je vous parlais plus haut, c'est celui-ci que vous allez répéter pour chacune de vos actions ; vous comprendrez alors pourquoi je ne détaillerais pas le reste :)).

Concernant mon petit code, il va se connecter sur une ip sur un port donné, il envoit alors un prompt à la manière d'un shell tout simplement.
J'ai d'ailleurs tout mis en place pour faciliter l'implémentation de fonctions ..si il y a des courageux comme je le disais :)).
Un petit screenshot:




Sinan dans le genre priceless, mon s1th vient de nous dégotter un OllyDbg customisé on ne peux plus cool :)).
Il est blindé de scripts/plugins, et possède un gestionnaire de raccourcis pour placer tous ces tools préférés :



On voit aussi qu'il possède une barre de commande immunityDbg like :) ; enfin bon à avoir d'urgence !
Ensuite je voulais vous parlez d'un ami, Squallsurf et son nouveau outil H.a.r.P.E (une espèce de plateforme de manipulation/visualisation du PE ; projet prometteur :)).
N'hésitez donc pas à lui rendre visite, ou encore lui rapporter bugs et/ou amélioration quant à son joujou :).

Les codes de mon Proof Of Concept :
Esrever.c

En espérant avoir intéressé quelques uns :), cya.
PS : petit coucou à securfrog o/ ; merci à baboon !