Un serveur troué qui gère l'interface d'admin des comptes ainsi
que leurs clefs ssh et toi tu vois pas où est le problème ?
Le serveur est juste un client ldap élaboré. Donc si jamais tu prends le contrôle du dit serveur, tu va pas avoir plus de contrôle que si tu attaques le ldap directement. Tu va avoir en effet une vue sur ce qui se passe, mais c'est autre chose.
Au hasard ? Une petite modif dans le code de l'appli de
gestion de comptes utilisateurs pour logger les
logins/password, ne reste plus qu'à attendre qu'un admin se
connecte et le tour est joué
Puppet va reverter le changement (déploiement auto depuis git/svn), et/ou le signaler. Tu devrais pas faire tes attaques au hasard, ça a pas l'air de marcher dans la vraie vie.
Ok, on modifie la conf apache pour logger les données POST, et
voila.
Puppet va reverter le changement, et/ou le signaler (c'est le but de puppet).
Bien sur, tu peux couper puppet, mais dans ce cas, ça va lancer une alerte assez vite sur le monitoring pour dire que "tel client n'a plus puppet qui tourne"
Donc la fenêtre de tir est assez courte (grosso modo, puppet se lance toutes les heures), il faut que tu fasses une attaque et que dans l'heure, un des 5 ou 6 admins se connecte pour changer sa clé sur l'interface (et pas ldapvi).
Ou que tu attaques de façon plus spécifique pour pas te faire choper (ce qui est faisable, même si j'ai plus les détails en tête, j'ai tenté de fermer ça autant que possible).
Je ne dit pas que c'est impossible, mais on sort très clairement des attaques de script kiddies. De mon expérience (ie, à dealer avec des vraies attaques et à faire du forensic), puppet est déjà au delà des capacités des admins moyens (sinon, je pense qu'il y aurait eu plus de patch), et donc du script kiddie moyen. J'ai eu à dealer avec des serveurs compromis, et en général, la ligne de commande classique est souvent déjà au delà des capacités de l'attaquant lambda, comme n'importe qui qui a pu lire un .bash_history d'un serveur compromis ou d'un honeypot a pu le constater.
Soit tu tombes sur des gens motivés et avec des ressources, et c'est globalement foutu si tu as pas autant de ressources en face (une équipe legere d'attaquant, ça se chiffre dans les 2 millions par an, cf https://medium.com/@thegrugq/cyber-ignore-the-penetration-testers-900e76a49500 ). Soit tu va tomber sur des attaquants moins staffés, et en général, c'est des boulets qui vont faire du bruteforce classique. Il y a fort peu de cas entre les 2 (ou personne n'en parle, mais c'est un autre débat).
Donc si le but est de rajouter une backdoor, c'est infiniment plus sur et plus rapide de juste devenir packageur et de rajouter ça dans la distribution. Genre en changeant un tarball d'un soft utilisé partout mais pas signé (y en a un paquet). Ça ne serait pas pérenne, mais sans doute discret.
Ou voir même, de devenir admin. Il y a tellement besoin d'aide que je suis sur qu'une personne en 2 mois peut devenir root.
Et quand j'étais admin sur le projet, j'avais fini par abandonner l'idée de sécuriser quoi que ce soit contre moi même au vue du manque de ressources chroniques. Et encore une fois, mon expérience montre que c'est globalement pareil partout (vu que j'ai fini par faire de l'admin pour projet libre mon activité professionnel, parce que j'estime qu'il vaut mieux bosser pour corriger un problème que de chouiner sur linuxfr, ce qui n'est pas le cas de tout le monde).
[^] # Re: Tu ne sais pas
Posté par Misc (site web personnel) . En réponse au journal Pas de mises à jour de sécurité depuis 5 ans sur l’infrastructure Mageia. Est‐ce bien raisonnable ?. Évalué à 10.
Le serveur est juste un client ldap élaboré. Donc si jamais tu prends le contrôle du dit serveur, tu va pas avoir plus de contrôle que si tu attaques le ldap directement. Tu va avoir en effet une vue sur ce qui se passe, mais c'est autre chose.
Puppet va reverter le changement (déploiement auto depuis git/svn), et/ou le signaler. Tu devrais pas faire tes attaques au hasard, ça a pas l'air de marcher dans la vraie vie.
Puppet va reverter le changement, et/ou le signaler (c'est le but de puppet).
Bien sur, tu peux couper puppet, mais dans ce cas, ça va lancer une alerte assez vite sur le monitoring pour dire que "tel client n'a plus puppet qui tourne"
Donc la fenêtre de tir est assez courte (grosso modo, puppet se lance toutes les heures), il faut que tu fasses une attaque et que dans l'heure, un des 5 ou 6 admins se connecte pour changer sa clé sur l'interface (et pas ldapvi).
Ou que tu attaques de façon plus spécifique pour pas te faire choper (ce qui est faisable, même si j'ai plus les détails en tête, j'ai tenté de fermer ça autant que possible).
Je ne dit pas que c'est impossible, mais on sort très clairement des attaques de script kiddies. De mon expérience (ie, à dealer avec des vraies attaques et à faire du forensic), puppet est déjà au delà des capacités des admins moyens (sinon, je pense qu'il y aurait eu plus de patch), et donc du script kiddie moyen. J'ai eu à dealer avec des serveurs compromis, et en général, la ligne de commande classique est souvent déjà au delà des capacités de l'attaquant lambda, comme n'importe qui qui a pu lire un .bash_history d'un serveur compromis ou d'un honeypot a pu le constater.
Soit tu tombes sur des gens motivés et avec des ressources, et c'est globalement foutu si tu as pas autant de ressources en face (une équipe legere d'attaquant, ça se chiffre dans les 2 millions par an, cf https://medium.com/@thegrugq/cyber-ignore-the-penetration-testers-900e76a49500 ). Soit tu va tomber sur des attaquants moins staffés, et en général, c'est des boulets qui vont faire du bruteforce classique. Il y a fort peu de cas entre les 2 (ou personne n'en parle, mais c'est un autre débat).
Donc si le but est de rajouter une backdoor, c'est infiniment plus sur et plus rapide de juste devenir packageur et de rajouter ça dans la distribution. Genre en changeant un tarball d'un soft utilisé partout mais pas signé (y en a un paquet). Ça ne serait pas pérenne, mais sans doute discret.
Ou voir même, de devenir admin. Il y a tellement besoin d'aide que je suis sur qu'une personne en 2 mois peut devenir root.
Et quand j'étais admin sur le projet, j'avais fini par abandonner l'idée de sécuriser quoi que ce soit contre moi même au vue du manque de ressources chroniques. Et encore une fois, mon expérience montre que c'est globalement pareil partout (vu que j'ai fini par faire de l'admin pour projet libre mon activité professionnel, parce que j'estime qu'il vaut mieux bosser pour corriger un problème que de chouiner sur linuxfr, ce qui n'est pas le cas de tout le monde).