Dyrk

Salutation très fidèle Dyrknaute !
Je suis ravi de te revoir pour te présenter une nouvelle astuce !
Travaillant désormais depuis quelques années dans la sécu, j'ai pour ainsi dire
développé quelques habitudes, un peu à la façon d'un cuisinier qui mettrait préalablement en place son plan de travail, organisant ses outils, et développant au fil des années, sa propre méthode.

Aussi, avant toute chose lorsque j'arrive sur une application web, plutôt que directement attaquer dans le dur, avec des approches ultra sophistiquée, des techniques requérants une bonne expertise, je vais simplement me contenter en préambule de gratter en surface, afin de monter progressivement en puissance.

La sécurité, c'est d'abord se mettre dans la peau de l'attaquant.
Si étiez à la place d'un cambrioleur à la recherche d'un trousseau de clé ...
Commenceriez-vous par sortir tous les meubles de la maison, afin de voir si les clés ne sont pas cachées derrière
l'un d'entre eux ... puis de prendre le nécessaire de bricolage pour les démonter un par un ... ne sait-on jamais ..
Les clés pourrait être dans un tiroire à double fond ?!?
Ou alors, commenceriez vous par regarder quelques évidences : sous le tapis ? Dans les tiroirs ? Dans les petits boites
à "bordel organisé"  ?

Fichiers sensibles

Mon approche consiste à faire de même sur un site Web.
Avant de sortir les grands moyens, je vais d'abord m'attarder à faire les choses élémentaires.
Comme l'énumération de fichiers sensibles ...

.git
.svn
.CVS
.bashrc
.bash_history
thumbs.db
.DS_Store
... etc ....

En essayant de les détecter à la racine des sites :

https://example.com/.git
https://example.com/.svn

https://example.com/ ....

ou bien selon le site, dans des sous arborescence 

https://example.com/forum/.git
https://example.com/forum/.svn

https://example.com/forum/ ....

Il me semble avoir déjà évoqué par le passé, comment un simple petit fichier exposé pouvait finalement mettre à nu toutes votre applications et ses données sensibles {Git} Le côté Obscure de la force

Dans cet article j'y avais expliqué qu'un simple repertoire  .git exposé,  permettait d'identifier la structure d'un site,
d'exposer son code source, y compris des parties non visibles publiquement, telle que des fichiers de configuration avec
des identifiants, ou encore, au travers de commentaires lors des "commits".

Même combat pour les .DS_Store

A l'époque de mon article sur le .git exposé, j'avais écrit tout un script permettant directement depuis la console de votre navigateur de faire ressortir tout ce qu'il pouvait contenir comme informations.

L'idée étant qu'un attaquant ne dispose pas forcément de l'équipement dernier cri ...  ou bien de la suite logicielle miraculeuse où il vous suffit d'appuyer sur un bouton et hop une batterie de 10.000 tests vont permettre de mettre en évidence sans le moindre effort de votre part, les vulnérabilités détectées et renvoyer en même temps toutes les informations sensibles, personnelles,
confidentielles, ...

Mais qu'à défaut de cela, il devrait en revanche, pouvoir assez facilement se procurer l'accès à un ordinateur avec un navigateur web (et donc
implicitement de la console développeur associé au navigateur).

Ainsi donc parlons du .DS_Store ...
Ce petit fichier un peu trop collant qui souvent se retrouvent malgré lui
dans des applications développées sur Mac. 

En effet, le .DS_Store est un fichier généré par Mac OS dans vos répertoires et qui permet au système d'exploitation de stocker et d'utiliser des informations sur les différents fichiers / dossiers  à des fins d'affichage (position des icones, vue sélectionnée, ...).
C'est l'équivalent du Desktop.ini ou du Thumbs.db sur le système d'exploitation Windows.
Ces fichiers ne sont pas indispensables au bon fonctionnement du système,
ainsi n'ayez pas peur des les supprimer, ça ne sera pas catastrophique !

Par contre, ils contiennent des données qui pourraient en dire beaucoup sur votre application (des nom de dossiers, de fichiers, des arborescences, etc ...)

En principe lorsque vous arrivez sur une application Web (plus basiquement un site web).
Vous arrivez sur une première "page"  :

Cette page est (la plupart du temps), un fichier à l'intérieur d'une arborescence qui contient d'autres fichiers utilisés par le site.

Néanmoins, ces autres fichiers sont rarement visibles pour des raisons d'ergonomie mais aussi de sécurité.

Ci-dessous un exemple de "site Web" ou l'arborescence est configurée pour être "accessible" et "visible".

Connaitre l'arborescence peut permettre à un attaquant de trouver des répertoires potentiellement mal configurés, mal sécurisés,
qui contiendraient (là encore au conditionnel), des données sensibles.

Ces données souvent mises bout à bout avec d'autres éléments permettront ainsi à un attaquant de mettre totalement ou partiellement la main
sur des données sensibles, sur l'administration du site, ou dans le pire des scénarios sur le serveur.

Reverse Engineering (à la hache)

Clairement le format du fichier .DS_Store n'est pas très explicité.
Je n'ai pas vraiment vu de doc officielle (mais rien ne vous dit que j'ai vraiment cherché).
Pour ce faire, et afin de me faire une idée de la façon dont on peut extraire les données de ce fichier, j'ai commencé par l'ouvrir en brut au bloc note.

Au moins ça donne une première idée de ce qui nous attends, et surtout si les données sont facilement accessibles.

Comment extraire les données :

On voit donc que chacune des lettres d'un nom de fichier et / ou de dossier, est précédée par un caractère spécial (le bloc note substitue ce dernier par un espace) .

Ainsi donc, en observant un peu le fichier on parvient à dissocier les noms de fichier et de dossier.
Ceux-ci sont suivis de 4 caractères qui sont des "attributs", puis  du type de données.
J'ai pu voir différent type, du "blob", du "comp", du "cstr".

En analysant plus finement les caractères spéciaux au travers d'un affichage hexadécimal on obtient ceci

Ce qui permet de voir qu'il ne s'agit non pas d'un espace mais d'un nullbyte (0x00) qui précède chacun des caractères du nom de fichier / dossier.

Bien évidemment, c'est assez minimaliste comme rétro-ingénierie, l'idée ici est avant tout de dégager un maximum d'information en utilisant le moins possible d'outils.

.DS_Store et arborescence de fichier

 De la même façon que 1 et 1 font 2, j'imagine qu'après avoir parcouru ces 2 précédentes rubriques, vous aurez compris qu'un .DS_Store dans une application Web, peut exposer des arborescences de fichier, et donc fournir autant d'éléments utiles à un attaquant.

Si vous disposez d'un ou plusieurs fichiers .DS_Store sur votre ordinateur, ou bien récupéré ici ou là, j'ai écrit un bout de Javascript qu'il vous suffira de jouer dans votre console développeur (toucher F12 de votre navigateur > onglet console, ou clic droit sur une page > Inspecter l'élément > Onglet console)

Copiez / Collez dans la console, et validez avec la touche "Entrée".
(1) vous devriez être invité à sélectionner un fichier
(2) Selectionnez votre DS_Store et vous devriez voir apparaitre les infos qu'il contient.

file = Object.assign(document.createElement('input'), {type:'file'});
file.addEventListener('change', (e)=>{
    dsStore = new FileReader();
    dsStore.addEventListener('load', (evt)=>{
        contents = evt.target.result;
        files = contents.match(/(\u0000[a-zA-Z0-9\.\_\-\(\)\[\]]{1})+[a-zA-Z]+(blob|ustr|bool|comp)/g)
            .map(function(e){
                e = e.replace(/[^a-zA-Z0-9\.\_\-\(\)\[\]]/g,'').match(/([a-zA-Z0-9\.\_\-\(\)\[\]]+)([a-zA-Z]{4})(blob|ustr|bool|comp)/);
                try {
                    return {  item : e[1], perms: e[2],  type : e[3] }
                } catch(e){
                    return {item : e}
                };
            })
            .filter((el, i, ar)=> el.item.length > 1 && ar.map(e=>e.item).lastIndexOf(el.item) == i);
        console.log(files);
    });
    dsStore.readAsText(e.target.files[0]);
});
file.click()

Conclusion 

Pensez, lorsque vous développez des applications Web, à vous assurer que ces derniers ne contiennent pas de fichiers sensibles.

Contrairement à des attaques sophistiquées, il existe de nombreux bots (robots virtuels) qui sont programmés pour scanner la présence de ce type de fichiers en continu 24 / 24 heures et 7 / 7 jours  les sites Web.
Un peu à la façon des moteurs de recherches, mais avec un objectif qui ne va pas à votre avantage.

Voilà, je vous remercie d'avoir pris le temps de lire cet article et vous dit à très bientôt pour de nouvelles aventures sur Dyrk !