• STATISTIQUES
  • Il y a eu un total de 0 membres et 28034 visiteurs sur le site dans les dernières 24h pour un total de 28 034 personnes!
    Membres: 2 605
    Discussions: 3 579
    Messages: 32 816
    Tutoriels: 78
    Téléchargements: 38
    Sites dans l'annuaire: 58


  • ANNUAIRE
  • [FR] Zenk-Security
    La communauté zenk-security a pour objet principal la sécurité informatique, nous sommes des tou...
    Hacking
    [EN] wechall
    Pour les gens n'étant pas familiers avec les sites de challenges, un site de challenges est un site propos...
    Hacking
    [EN] Defcon
    Lancé en 1992 par Dark Tangent, DEFCON est la plus ancienne et la plus grande conférence underground de...
    Hacking
    [FR] NewbieContest
    Nous vous proposons une série de challenges regroupant plusieurs domaines allant de l'exploitation de fail...
    Hacking
    [EN] phrack
    Lot's of stuff !
    Hacking
    [EN] Hack this site
    Basic: 11, Realistic: 17, Application: 18, Programming: 12, Extbasic: 14, Javascript: 7, Stego: 17
    Challenges
    [EN] Listbrain Version 3
    Site proposant 66 challenges présentés dans une liste mélangée.
    Challenges

  • DONATION
  • Si vous avez trouvé ce site internet utile, nous vous invitons à nous faire un don du montant de votre choix via Paypal. Ce don servira à financer notre hébergement.

    MERCI!




Note de ce sujet :
  • Moyenne : 0 (0 vote(s))
  • 1
  • 2
  • 3
  • 4
  • 5
scripts & mots de passe en clair
12-03-2014, 13h09
Message : #1
gruik Hors ligne
gouteur de savon
*



Messages : 757
Sujets : 44
Points: 482
Inscription : Oct 2012
scripts & mots de passe en clair
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 ?
+1 (2) -1 (1) Répondre
12-03-2014, 13h25
Message : #2
b0fh Hors ligne
Membre actif
*



Messages : 210
Sujets : 17
Points: 309
Inscription : Jul 2012
RE: scripts & mots de passe en clair
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.)
+1 (0) -1 (0) Répondre
12-03-2014, 13h34
Message : #3
gruik Hors ligne
gouteur de savon
*



Messages : 757
Sujets : 44
Points: 482
Inscription : Oct 2012
RE: scripts & mots de passe en clair
(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 ;(
+1 (0) -1 (1) Répondre
12-03-2014, 14h02 (Modification du message : 12-03-2014, 14h03 par b0fh.)
Message : #4
b0fh Hors ligne
Membre actif
*



Messages : 210
Sujets : 17
Points: 309
Inscription : Jul 2012
RE: scripts & mots de passe en clair
(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 Big Grin
+1 (4) -1 (0) Répondre


Sujets apparemment similaires…
Sujet Auteur Réponses Affichages Dernier message
  Gestion centralisée de mots de passe Booster2ooo 11 468 04-10-2017, 13h48
Dernier message: sakiir
  La sécurité des mots de passe InstinctHack 6 369 19-04-2013, 12h17
Dernier message: InstinctHack

Atteindre :


Utilisateur(s) parcourant ce sujet : 1 visiteur(s)
N-PN
Accueil | Challenges | Tutoriels | Téléchargements | Forum | Retourner en haut