Salut,
Habituellement je ne vais pas regarder les vidéos YT, mais là il s'agit de quelqu'un qui maîtrise le sujet et sa démonstration est assez didactique.
Il faut aussi lire les questions / réponses dans les commentaires.
Il y aurait beaucoup de choses à dire sur les principes de sécurité sous-jacents que cette démonstration ne fait qu'effleurer :
- la gestion des droits et la séparation de privilèges ;
- l'«isolation » des processus et des utilisateurs ;
- les efforts de sécurité qui devraient toujours d'abord porter sur le maillon le plus faible plutôt que de mettre en place des mesures généralistes (par-feu, IDS, etc.) souvent peu utiles et donnant un faux sentiment de sécurité ;
- l'utilisation d'interface de configuration de serveurs (panels) qui ne font que donner l'illusion de la maîtrise du système et qui souvent posent des problèmes de sécurité. C'est bien d'ailleurs un de ces logiciel qui est mis en cause par Christophe pour les 400 000 serveurs vulnérables :
L'exemple que je cite qui concerne notamment plus de 400.000 serveurs, est typiquement un soft utilisé par les webagency ou de petits hébergeurs pour proposer des
Christophe Casalegno a écritenvironnements mutualisés. Mais il y en a des usecase cas d'usage qui ne reposent pas du tout sur ce type de soft (j'ai testé une bonne quinzaine d'offres dans le monde, excluant les structures que j'avais pu auditer contractuellement) pour essayer d'estimer la présence de ce biais.
abecidofugy a écrit je ne vois pas trop comment quelqu’un de malveillant pourrait prendre le contrôle d’un serveur en amont de cette démonstration
Je ne suis pas sûr de comprendre ta question.
Si je reprends la cas de la démonstration, nous avons un serveur web qui héberge un site utilisant un CMS, par exemple WordPress. On va s'attaquer au maillon le plus faible c'est à dire WordPress et ses éventuelles extensions. Si une faille est trouvée dans le CMS permettant d'injecter du code PHP, alors on obtient facilement un shell, via la fonction shell_exec de PHP par exemple, sous l'identité de l'utilisateur qui exécute les scripts PHP du CMS. À savoir www-data dans le cas d'Apache avec son module PHP, ou l'utilisateur définit dans un pool avec PHP-FPM (Nginx, Apache). Si cet utilisateur n'est pas strictement confiné dans son dossier personnel et si les droits d'accès ne sont pas correctement définis les manipulations décrites, et bien d'autres, sont possibles.
