Tixlegeek's DevBlog Code, Gringo, Silicium

Salutations!

Si vous êtes dans le milieu de la sécu, vous devez sans-doute connaitre ce sentiment particulier de mépris envers un technicien, quand, après un scan d'arborescence par bruteforce (Dirbuster, etc..) ou tout simplement après un DORK lors de la phase de recon, vous tombez sur un dossier en directory listing, sur un serveur publique, avec des mots de passe, des clefs ssh, ou des dumps SQL dedans.

Effectivement, ça peut être utile (mais, pas en prod! D:) sur un httpd perso mutu, de pouvoir stoquer des choses de temps en temps (photos, documents sans importance stratégique, tool php bien sécurisé...) et bien je vais vous apprendre à le faire correctement!

La bonne pratique

La bonne pratique, c'est de ne rien laisser traîner. Mais, ça, si vous êtes des gens sérieux, vous le savez déjà. Si vous laissez traîner des choses, alors vous devez savoir comment des gens peuvent tenter d'y avoir accès.

Le Dork

Le Dork, c'est une technique de reconnaissance passive qui utilise un moteur de recherche pour rechercher des fichiers en fonction de certains critères. Basiquement, on injecte des commandes dans le champ de recherche. Par exemple: intitle: , intext: , filetype: etc....

Du coup, la première chose à faire, c'est de s'assurer que le dossier ne sera pas indexé par un moteur de recherche. Pour ça, vous pouvez jouer avec votre robots.txt, un .htaccess, ou avec du php, au choix.

Le scan d'arborescence actif / bruteforce

Je vais dire le brutefoce à partir de maintenant, parce que c'est plus court, mais, je ferai spécifiquement référence au "scan d'arborescence actif par bruteforce" en disant ça.

Basiquement, cette technique repose sur des outils automatisés, qui font des requetes http vers un serveur, et loguent la réponse. Ils essayent d'atteindre chaque dossier ou fichier, en se basant sur un dictionnaire. Si la requete renvoie un code d'erreur 200 (=pas d'erreur) il considère que le fichier existe. Sinon, il passe au suivant. Si le fichier existe, et que c'est un dossier, il pourra tenter d'appliquer la même technique récursivement.

Parfois, le dictionnaire sert de base, et plusieurs variation de chacun des terme est testé.Exemple: "/upload.php","./Upload.php","upload.asp",etc...

Cette technique est un peu sale (facile à détecter, et à bloquer avec fail2ban par exemple, ou un IDS digne de ce nom) mais permet de dresser potentiellement l'arborescence complète d'un serveur WEB. Il faut préciser que les dictionnaires utilisés pour ces techniques sont alimentés avec les arborescences connues de systèmes courant. Par exemple, il contient forcément "wp-admin", ou "*.swp *.bak *.old" (qui sont les extensions ajoutées aux sauvegardes dans certains éditeurs un peu crades)

Bref, vous êtes mal barrés. Mais, il existe des tas de techniques pour l'éviter, on en verra quelques unes.

La bonne pratique, du coup, c'est quoi?

Et-bien, je vous l'ai dit. La bonne pratique, c'est de ne rien laisser traîner. Mais vous pourrez toujours tenter l'une des solutions ci-dessous, si vous êtes sur de vous!

La base: index.php

Bah, oui. Vous n'avez pas à laisser tout le monde voir ce qu'il se passe chez vous. Si vous voulez laisser toute l'arborescence visible, activez le directory listing dans votre vhost (ou .htaccess?), mais, si vous êtes sérieux, vous désactivez ça, et vous mettez des index.php vide partout ou le risque subsiste. Votre Httpd va ainsi ouvrir le fichier d'index en priorité (attention à la configuration de votre directory Index dans vos vhosts!) et n'affichera pas l'arborescence, même en cas de magie offensive de l'autre côté.

La technique de Patrick, l'admin-sys

Patrick l'admin sys sait ce qu'il fait, alors du coup:

• il n'a rien laissé trainer
• il a duement configuré ses vhosts et htaccess
• il met en place une authentification basique, mais, que sur des vhosts SSL (https) si il en a besoin.
• il utilise des softs dédiés, comme un owncloud, ou autre, quand il peut.
• pour partager des secrets avec sa team, il utilise sshuttle, ou un VFS, pas un truc dégueu à base de php/http.

Patrick est quelqu'un de factuel et compétent, bravo Patrick.

La technique de voyou cryptoanarchiste

 

 Attention! Lisez bien l'article jusqu'a la fin. C'est important!

Bon, la première des sécurité, c'est encore qu'il n'y ait rien à pirater. Bah, oui, qui s'intéressera à vos fichiers, s'ils n'existent pas? Enfin, si, ils sont là, mais, si je vous disait que vous pouvez les rendre complètement invisibles?

Mettons que sur la racine de votre serveur, vous ayez un dossier "PhotosWE" contenant des photos outrageusement personnelles. Vous rigolez, mais, c'est beaucoup moins débile qu'utiliser facebook! Bref, vous ne voulez pas que tout le monde puisse voir vos... photos de pêche.

Premier stade, la conf.

Si vous voulez du directory-listing, activez-le, mais ATTENTION! Uniquement là ou ça vous intéresse. Pour ça, il faut créer une directive dans la configuration de votre vhost. Ensuite, vous mettes un fichier index.php à la racine de votre dossier "PhotosWE"

Second stade: la disparition.

On va écrire un peu de code php, pour faire en sorte que votre index.php renvoie une erreur 404. Pour ça, on va s'inspirer des pages 404 déjà en place sur le système pour ne pas éveiller les soupçons;

<?php
http_response_code(404);
?>
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL <?php echo basename(__DIR__)."/"; ?> was not found on this server.</p>
</body></html>

A partir de ce moment, à chaque fois qu'on fera appel au chemin "/PhotosWE", tout ce qu'on verra, ce sera une erreur 404 crédible à tous les niveaux. Si par contre, on sait ce qu'on cherche, alors, on y a acces. Si on cherche la photo "/PhotosWE/JeanMichelToutNu.png", elle s'affichera.

Troisième étape, le owncloud du pauvre

Alors, en admettant que vous avez la tête dure, et que vous ayez activé le Directory Listing, la technique précédente vous empêche d'en profiter. Mettons que vous avez une raison, mettons aussi que vous avez une bonne raison de ne pas utiliser une Basic Auth minimale. Dans ce cas, vous pouvez tester cette technique qui offre de bons résultat, avec un investissement en temps et en technologie minime:

1. Créer un répertoire avec un sale nom.

Le but, ici, c'est de rendre la tache compliquée à un éventuel bruteforcer, qui essayerait de trouver votre dossier caché. Il se trouvera à la racine de "PhotosWE", et contiendra les fichiers que vous voulez partager avec Patrick. Je vous conseille de générer un sha256, et de l'utiliser comme nom de fichier:

$ # Créer un hash sha512 de la chaine "MonDossierCache"
$ echo "MonDossierCache" | sha256sum
b859eb27216b3c63824c2c7aa7c6f677c10f3990c4c8a0204ae278f579b83f18

 Autant vous dire que trouver un dictionnaire contenant la chaîne "b859eb27216b3c63824c2c7aa7c6f677c10f3990c4c8a0204ae278f579b83f18", c'est compliqué.

2. Donner accès à ce dossier, uniquement à ceux qui possèdent le sésame.

On va utiliser un peu de PHP pour faire ça. On va reprendre notre fausse page 404 du début, et la modifier pour en faire une "porte secrète":

<?php
/**
    ATTENTION! :Comme vous le voyez, dans cet exemple, je ne hache pas le mot de passe.
    La bonne pratique, ici, serait de comparer l'entrée utilisateur, avec un hash de "caca".
    Un hash de caca salé de préférence, parce que caca est dans les rainbow-table depuis
    l'invention de la blague scato.
*/
if(!(isset($_GET['starwars']) && ($_GET['starwars'] == "caca")))
{
/**
    La page 404 par défaut.
*/
http_response_code(404);
?>
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html>
   <head>
      <title>404 Not Found</title>
   </head>
   <body>
      <h1>Not Found</h1>
      <p>The requested URL <?php echo basename(__DIR__)."/"; ?> was not found on this server.</p>
   </body>
</html>
<?php
exit(0); // on est sûr de bien quitter le script, pour éviter que la suite ne se déroule.
}
/**
    Comme le mot de passe est validé, on peu rediriger vers notre dossier chiant:
*/
 header('Location: ./b859eb27216b3c63824c2c7aa7c6f677c10f3990c4c8a0204ae278f579b83f18/');
?>

 

3. Copiez vos fichier dans votre dossier chiant.

Quand ça sera fait, vous pourrez accéder à votre dossier depuis l'extérieur. Mais, bien entendu, vous ne verrez qu'une erreur 404. Votre scanner d'arborescence, aussi. Il sera trompé par notre page, et, nous laissera surement tranquille (puis-ce que la page n'existe pas)

Pour voir nos fichiers, il faudra ajouter le paramêtre "?starwars=caca" dans votre url. À ce moment là, la requête GET sera reconnue, et traitée, invalidant le test, et, ainsi, donnant accès a vos documents.

Oui, mais attention.

Je le répeterai sans cesse chaque jours s'il le faut, mais, faire ce que je décrit, c'est le minimum quand on a pas le choix (accès limité au serveur, pas d'autre plateforme disponible, motivation moribonde...) mais, ici, la bonne pratique, c'est de ne pas le faire.

On peut pointer du doigt plusieurs choses importantes:

• ici, le HTTPS est aussi important que les documents que vous partagez. Si vous vous en foutez, et, que vous voulez juste partager des conneries innocentes avec des collègues, vous pourrez le faire en HTTP, mais, tout sera visible de l'extérieur. Du coup, pas dutout sécure en réseau local/publique.
• Votre historique permettra d'acceder au dossier chiant, parce que rien n'empechera un visiteur d'y acceder. La seule sécurité apportée est celle qui dit que "le dossier est chiant à trouver", mais, rien de plus.
• Faites le ménage après votre partage. Si vous n'avez plus besoin de conserver votre CV, vos photos, ou autre, sur votre serveur, enlevez les!
• Trouvez vite une solution qui vous permettra de résoudre ce problème une bonne foi pour toute. Pourquoi pas, un Owncloud sur un VPS à la con à 3$?

Voilà. J'espère que ça vous aura été utile, d'une manière ou d'une autre. En tous cas si un jour vous décidez de laisser trainer quelquechose sur un serveur, vous aurez les bases pour ne pas passer pour un connard quand un type tombera dessus!

Attention à ce que vous laissez trainer, lisez la doc, et, HppHcking!