+- N-PN White-Hat Project (https://dev.n-pn.fr/forum)
+-- Forum : Questions (https://dev.n-pn.fr/forum/forumdisplay.php?fid=11)
+--- Forum : Security (https://dev.n-pn.fr/forum/forumdisplay.php?fid=24)
+--- Sujet : scripts & mots de passe en clair (/showthread.php?tid=3595)
scripts & mots de passe en clair - gruik - 12-03-2014
alors voilà le problème est assez simple à énoncer; sur un serveur Linux on a classiquement tout un tas de scripts (php, perl, bash, python etc.) qui ont besoin d'avoir accès aux services, lesquels sont protégés par des mots de passe
pour prendre un exemple concret prenons le cas de mysql, on a forcément un moment donné quelque part sur le disque un fichier qui contient le user et le mot de passe pour se connecter à la db, si un pirate parvenait à exploiter au moins en partie une faille (LFI par exemple) il pourrait lire directement ces identifiants, et ça quand on parle de sécu, ben ça fait mal au cul.
le problème est le même pour les scripts des administrateurs
comment faire pour que si le pirate arrive à mettre les pieds sur la machine (avec plus ou moins de possibilités pour lui, ça va de la LFI au shell root carrément en passant par seulement un shell www-data par exemple), comment faire donc pour qu'il ne puisse rien trouver ou au moins être sacrément ralentis ?
RE: scripts & mots de passe en clair - b0fh - 12-03-2014
Je pense que pour bien répondre à cette question, il faut préciser le contexte de l'attaque et le modèle de sécurité.
De manière générale, on ne peut pas demander au système de se protéger contre un attaquant, tout en supposant que l'attaquant a déja compromis le système. Il faut donc supposer qu'une partie du système est encore intègre, et donc il faut déterminer laquelle.
De manière générale, on ne peut pas non plus demander à un système de fonctionner correctement dans tous les cas alors qu'il est buggé. Il faut donc, soit supposer que le système est parfait (et il n'y a jamais de failles), soit supposer que n'importe quoi peut être buggé (et l'attaquant gagnera toujours), soit supposer qu'une partie du système est saine (par exemple le kernel-land), et lui demander de se protéger contre la partie buggée (ici l'userland).
Le problème du mot de passe, c'est qu'il peut se transmettre, volontairement ou non. Comme un ordinateur est un système fait pour traiter et transmettre de l'information, on peut supposer qu'a partir du moment ou on stocke un mot de passe comme n'importe quelle autre donnée, on permet aux utilisateurs du système de se transmettre leurs droits, donc la responsabilité de protéger ces droits incombe a notre userland potentiellement buggé.
Conclusion temporaire: les mots de passe c'est de la merde...
Il y a des modèles de sécurité (les capabilités, par exemples) dans lesquels les token d'accès ne sont pas des données génériques, ne sont pas accessibles directement par l'userland. Mais sinon, de manière générale, la solution sera de décider ce qu'on considère inaccessible à l'attaquant, et se baser dessus pour enforcer la sécurité.
Pour le cas de ton exemple concret: un SGDB sérieux permettra par exemple de recevoir une connexion sur un socket unix, et d'identifier l'utilisateur de l'autre côté de la socket, sans mot de passe. Si chaque application web tourne sous un utilisateur séparé (elles devraient), il est possible de simplement dire au SGDB que tel utilisateur peut accéder a telle base, sans le forcer a fournir un mot de passe, ce qui règle un certain nombre de problèmes (mais pas tous.)
RE: scripts & mots de passe en clair - gruik - 12-03-2014
(12-03-2014, 13h25)b0fh a écrit : Il faut donc supposer qu'une partie du système est encore intègre, et donc il faut déterminer laquelle.
on admet qu'ici la partie intègre c'est un serveur externe
Citation :Si chaque application web tourne sous un utilisateur séparé (elles devraient)
en pratique c'est totalement infaisable (ou jamais fait comme ça disons), pour un même site web tous les scripts php tournent en www-data et basta ;(
RE: scripts & mots de passe en clair - b0fh - 12-03-2014
(12-03-2014, 13h34)gruik a écrit : on admet qu'ici la partie intègre c'est un serveur externe
Well, dans ce cas, y'a Kerberos. Mais ça ne résout pas le problème, dans la mesure ou si un attaquant a pris le contrôle d'un service, rien ne permet de distinguer les requêtes légitimes de celles de l'attaquant.
gruik a écrit :en pratique c'est totalement infaisable (ou jamais fait comme ça disons), pour un même site web tous les scripts php tournent en www-data et basta ;(
Ben, y'a bien le mpm-peruser d'apache, pour le caca PHP. Et sinon, il y a toutes les techniques (wsgi, fcgi, etc...) qui font tourner l'appli dans un process séparé. Oui, c'est lent, la sécurité ça n'est pas gratuit
