FIC Challenge Writeup

Pour le troisième challenge du FIC 2015, Sogeti nous promettait un challenge résolument orienté hacking. Voici un essai de solution.

Le challenge se déroule de la manière suivante: chaque participant vient avec son propre matériel, et doit configurer une adresse IP statique associée à son emplacement physique dans l'Espace Challenge (le sous-réseau privé 192.168.0.0/24 est utilisé). A 11h00 le challenge démarre avec comme indication une simple adresse IP: http://192.168.0.35/

Un serveur Web est disponible à cette adresse. Il sert une image statique avec la musique de NyanCat en arrière-plan.

On imagine assez facilement que ceci n'est qu'un leurre et qu'il nous revient la charge de découvrir l'étape suivante. Deux hypothèses sont envisageables: soit le challenge se trouve sur le serveur Web (un scan "à la Nikto" devrait révéler une page cachée) ; soit le challenge se trouve sur un autre service.

Pour l'instant difficile de conclure car les deux pistes fonctionnent. Un scan Nmap révèle une configuration bien connue des pentesters, dite "arbre de Noël":

Port	Service
80/tcp	Apache 2.0.54 (Win32)
135/tcp	MS-RPC Endpoint Locator
139/tcp	MS-SMB
445/tcp	MS-CIFS
902/tcp	VMWare client
912/tcp	VMWare client
1025/tcp	MS-RPC (port dynamique)
1026/tcp	MS-RPC (port dynamique)
1027/tcp	MS-RPC (port dynamique)
1030/tcp	MS-RPC (port dynamique)
1031/tcp	MS-RPC (port dynamique)
1032/tcp	MS-RPC (port dynamique)
2048/tcp	?
2701/tcp	MS-SCCM
3306/tcp	MySQL
3389/tcp	MS-RDP
5357/tcp	?
6129/tcp	DameWare
8081/tcp	?

Le système lui-même est un Windows 7 x64 SP1 ; un grand classique compatible avec les outils de type Metasploit. On peut supposer que les organisateurs ne veulent pas nous faire perdre de temps à ajuster des offsets exotiques dans nos payloads.

Il est temps de lancer un scan Nessus. Malheureusement nous sommes confrontés à la crise du riche:

· La machine n'est pas à jour de MS14-066 (et donc probablement de MS14-068).

· D'après la bannière du serveur Web, Apache (2.0.54) et PHP (5.2.3) sont vulnérables à des dizaines de failles connues et non corrigées, puisque ces versions ne sont plus maintenues.

· La version de MySQL (4.1.22) est elle-même antédiluvienne.

A ce stade, on peut noter une propriété intéressante (et rare) de ce challenge: chacun peut y trouver son compte. Les fans de stack overflow peuvent tenter d'exploiter les failles de PHP, tandis que les pentesters expérimentés vont exploiter l'injection de commandes dans PHP-CGI (CVE-2012-1823) par exemple.

Le scan Nessus lancé en mode "no limit" (unsafe checks, probe all services on all ports, Web scan, etc.) va révéler également un fichier /phpinfo et un répertoire /phpmyadmin (version 2.11.0) sur le serveur Web. Ce dernier autorise le login root avec un mot de passe vide !

(Pour en avoir discuté avec les autres équipes à la fin du challenge, il semblerait que ce n'était pas la configuration par défaut mais qu'une équipe plus rapide que nous ait supprimé le mot de passe).

La combinaison de phpinfo + MySQL 4 + phpmyadmin sans mot de passe est une solution simple et élégante pour permettre aux étudiants de ne pas rester bloqués dans le challenge. En effet:

· phpinfo permet de récupérer le chemin absolu d'installation du serveur Web: W:\var\www (et W:\home\phpinfo pour le répertoire /phpinfo).

· Connaissant le chemin absolu, il est désormais possible d'utiliser la commande SQL "SELECT INTO DUMPFILE / OUTFILE" pour créer des fichiers lisibles au travers du serveur Web.

· MySQL 4 autorise également la création de bibliothèques binaires qui pourront être chargées en tant qu'UDF (User-Defined Functions) dans MySQL – cette option est disponible avec SQLMap ou Metasploit.

En ce qui nous concerne, nous avons opté pour une solution simple (donc fiable): créer un fichier "fuu.php" qui n'est qu'un Webshell minimaliste: <?php system($_GET[cmd]); ?>

En effet, la configuration PHP obtenue au travers de phpinfo révèle que la commande system() n'a pas été désactivée. Et ça marche !

Il reste à trouver la suite du challenge. Essayons le disque C:

Plusieurs emplacements s'annoncent intéressants: "Private", "Security" et "Sogeti".

Mais avant tout, essayons de voir sous quelle identité tourne le serveur Web. Il serait loisible de récupérer un shell complet au travers de PsExec par exemple, mais ceci nécessite d'être administrateur local. Une élévation locale de privilèges sera peut-être nécessaire.

On sent que la suite du challenge va être tout aussi intéressante, car la machine appartient à un domaine Active Directory. Il faudra peut-être rebondir dans le domaine, effectuer un mouvement latéral, passer par un VPN ou un OWA …

Avoir appelé le domaine "SOGLU" c'est quand même pousser le réalisme assez loin. C'est peut-être à ce moment qu'un participant a demandé aux organisateurs s'il était sur la bonne piste. Malheureusement, non: le challenge de hacking consistait à identifier de la stéganographie dans l'image publiée initialement sur le serveur Web. Du coup personne n'a eû le temps de finir le challenge malgré les indices distribués en abondance par l'organisation, et les gagnants ont été désignés en fonction de l'avancement des équipes. Je pense que la plupart des participants ont été déçus par la fin de cette histoire. Mais on essaiera de faire mieux la prochaine fois !