Ubuntu-fr

abecidofugy

Linux, *BSD, Unix... des millions de serveurs vulnérables ?

Salut,

Je viens de regarder cette vidéo : https://www.youtube.com/watch?v=0HnC0l0xFXA

À vrai dire, même si les commandes sont compréhensibles, bien entendu, je ne vois pas trop comment quelqu’un de malveillant pourrait prendre le contrôle d’un serveur en amont de cette démonstration.

Par contre, j’attends les éventuelles solutions pour s’en prémunir. Cette vidéo aurait sans doute une suite.

Bonne soirée

bruno

Re : Linux, *BSD, Unix... des millions de serveurs vulnérables ?

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

environnements 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.

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.

Dernière modification par bruno (Le 19/11/2020, à 09:50)

krodelabestiole

Re : Linux, *BSD, Unix... des millions de serveurs vulnérables ?

une autre faille (de gdm) permettant l'escalade de privilège, en l'occurrence sous ubuntu : https://www.youtube.com/watch?v=h-E0tFvXmJE

bon il faut déjà a priori un accès physique à la machine.

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

et pour se protéger de ça le mieux est déjà de garder ses scripts à jour (surtout ne pas utiliser de solutions abandonnées), et de désactiver les fonctionnalités dangereuses si elles sont inutiles (exec, shell_exec, popen, proc_open, pcntl_exec).

disable_functions =exec,passthru,shell_exec,system,popen,proc_open,pcntl_exec,curl_exec,curl_multi_exec,parse_ini_file,show_source
allow_url_fopen=Off
allow_url_include=Off

---

nouveau forum ubuntu-fr on en parle là : refonte du site / nouveau design
profil - sujets récurrents - sources du site

metalux

Re : Linux, *BSD, Unix... des millions de serveurs vulnérables ?

Salut,

Le titre de ce sujet est alarmiste, mais quand je lis les explications de Bruno, ça fait quand même beaucoup de "si":

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.

Je suis certainement très naïf sur le sujet ne maîtrisant pas les aspects sécurité, même si en pratique je fais certainement plus attention aux droits accordés avant de m'intéresser aux "rustines" apportées par les solutions de sécurisation tels que portsentry, F2B et Cie. Cependant celles-ci ne me semblent pas complètement inutiles, ne serait-ce que pour éviter de surcharger le serveurs de requêtes inutiles et de surcharger en même temps les fichiers Logs. Merci de me corriger si ma réflexion est erronée.

Par défaut, les droits et accès ne sont-ils pas correctement définis sur une distribution Linux? Quant à la séparation de privilèges, qu'est-ce que c'est exactement? Est-ce la notion de droits accordés aux utilisateurs (rwx) et d'accès aux commandes (type sudo pour la plus risquée me semble-t-il)?

@krodelabestiole
Tu abordes le côté technique, or, en tant qu'amateur, je ne maîtrise pas du tout cet aspect. Lors de l'installation d'une application en php, celle-ci n'est-elle pas correctement configurée? Et si non, dans l'exemple donné d'un CMS, comment et où désactives-tu ces fonctionnalités?
Vu la complexité apparente pour un amateur, on aurait tendance à faire demi-tour en courant! Et pourtant c'est grâce à ce forum et particulièrement vous 2 @bruno et @krodelabestiole que j'ai fini par auto-héberger quelques services Je me pose toujours la question entre "Faut-il être parano et penser que son serveur sera piraté à la moindre occasion quand on est pas informaticien" et "bah, prenons le risque (pas trop quand même en ne faisant pas n'importe quoi) et savourons l'expérience de l'auto-hébergement". Mais il ne faudrait pas que la seconde devienne un véritable cauchemar, ce que le sujet laisserait entendre.

---

Faîtes la mise à jour de vos P.P.A. automatiquement

bruno

Re : Linux, *BSD, Unix... des millions de serveurs vulnérables ?

Pour l'instant je ne vais pas rentrer dans les détails. Pour rassurer @metalux je précise bien, si ce n'était pas encore assez clair, que pour exploiter les défauts de configuration mis en avant dans la démonstration de la vidéo il faut d'abord obtenir un shell utilisateur.  Dans le cadre d'un serveur web cela signifie que le site doit présenter une faille et qu'elle soit exploitée pour obtenir un shell.
J'ai déjà vu pas mal de sites WordPress compromis et je t'assure que ce genre de manipulation n'est pas la priorité de ceux qui en prennent le contrôle Le plus couramment il s'agit de phishing, liens malveillants ou publicitaires, spam, mineur de cryptomonnaie et autres joyeusetés susceptibles de rapporte de l'argent.

S'il y a deux choses à retenir pour un auto-hébergement web avec la configuration la plus courante, c'est à dire apache avec mod_php et donc une exécution des scripts par www-data, c'est :
- ne pas rendre www-data propriétaire du dossier /var/www qui est son $HOME. Ce dossier doit appartenir à root.
- ne pas mettre de scripts appartenant à root dans un dossier utilisateur.
J'en ajoute une troisième parce que je l'ai déjà vu plus d'une fois sur des serveurs :
- ne jamais appeler un script situé dans un dossier web (ou plus généralement un dossier utilisateur) avec une tâche cron exécutée par root.

@krodelabestiole : +1 pour la désactivation des fonctions inutiles et dangereuses. Mais certaines applications en ont besoin et d'autre part une des manipulations de la vidéo pourrait être utilisée pour outrepasser les directives du php.ini (écriture dans un .htaccess, un .user.ini, etc.)

Dernière modification par bruno (Le 19/11/2020, à 14:10)

bruno

Re : Linux, *BSD, Unix... des millions de serveurs vulnérables ?

Par défaut, les droits et accès ne sont-ils pas correctement définis sur une distribution Linux?

Ils le sont. Mais tout dépend des cas d'usage. Par exemple je considère que le umask par défaut sur Debian/Ubuntu n'est pas suffisant sur un serveur, ni même sur une station de travail multi-utilisateurs. Il est à 022 (ou 002 si l'UID et le GID sont les mêmes) ce qui signifie que les fichiers et dossiers d'un utilisateur sont accessibles en lecture à tous. Un umask à 027 convient mieux à mon cas d'usage sur un serveur ou j'ai plusieurs utilisateur correspond à plusieurs sites web et comptes SFTP, ous sur un poste de trvail ou les utilisateurs non privilégiés ne doivent pas pouvoir lire les fichiers des autres.

Quant à la séparation de privilèges, qu'est-ce que c'est exactement?

J'aurais dû parler plutôt de principe de moindre privilège :

une tâche ne devrait avoir la possibilité de mener à bien que les actions dont l'utilité fonctionnelle est avérée.

Si un utilisateur n'a pas besoin d'effectuer de tâches d'administration on ne lui accorde aucun privilège. Concrètement sur Ubuntu, il n'est pas dans le groupe sudo qui peut acquérir tous les droits. S'il a besoin d'effectuer certaines tâches on le place dans un groupe qui le lui permet. Par exemple dans le groupe adm pour pouvoir lire les logs. Ou on lui accorde via sudoers l'accès à certaines commandes, et uniquement celles absolument nécessaires.
Autre exemple pour en revenir au serveur web, si j’héberge plusieurs sites en PHP sur le même serveur je devrais avoir un utilisateur spécifique à chaque site (via les pools PHP-FPM par exemple). Ainsi si un site est compromis cela ne doit pas pouvoir affecter les autres.

krodelabestiole

Re : Linux, *BSD, Unix... des millions de serveurs vulnérables ?

comment et où désactives-tu ces fonctionnalités?

les directives que j'ai indiquées sont à coller dans le fichier php.ini. attention elles sont restrictives : certains scripts peuvent avoir besoin de les utiliser, dans ce cas ils ne fonctionneront pas (et tu devrais avoir un message d'erreur explicite quant à la fonction à réactiver).
mais je ne vois aucune raison pour laquelle WordPress aurait besoin d'exécuter des commandes shell sur le système par ex.

Et pourtant c'est grâce à ce forum et particulièrement vous 2 @bruno et @krodelabestiole que j'ai fini par auto-héberger quelques services

cool merci

"Faut-il être parano et penser que son serveur sera piraté à la moindre occasion quand on est pas informaticien" et "bah, prenons le risque (pas trop quand même en ne faisant pas n'importe quoi) et savourons l'expérience de l'auto-hébergement".

je pense qu'il faut avoir une dose raisonnable d'inquiétude à ce sujet en fonction du service proposé. si on propose un service d'hébergement pour d'autres structures, il faut avoir conscience qu'on est responsable de leur sécurité, donc de la confidentialité de leurs données, et du bon fonctionnement de leurs services, ainsi que de la sécurité de leurs partenaires (si une iframe malveillante pourrit l'ordi des clients d'un site de ecommerce, le vendeur va faire la gueule). ou si tu fais tourner un forum, une mauvaise sécurité peut permettre à un attaquant de récupérer les couples identifiant / mots de passe (les plus faibles) des utilisateurs. (d'où l'intérêt d'utiliser des mots de passe différents partout).

si ce que tu proposes est un site vitrine, qui n'a rien de politique / polémique / clivant / confidentiel, que tu n'as pas recours à une trentaine d'extensions exotiques, tu n'as a priori pas trop à t'inquiéter. au pire un bot de passage exploitera une vulnérabilité connue, ton site sera défacé par un kiddie ou ton serveur se mettra à envoyer du spam, rien de tragique (à condition d'avoir des backups) ! tu mets ton site hors ligne le temps de nettoyer et faire une mise à jour et puis c'est reparti (mieux vaut quand même piger l'exploit pour s'en prémunir).
idéalement on peut passer par un générateur de site statique plutôt qu'un CMS pour être tranquille.
et encore une fois si on tu utilise un CMS la première règle de sécurité est de maintenir ses scripts (core, extensions, thèmes) à jour.

bref tant que tu ne fais pas comme linux mint : proposer des données sensibles sur un serveur avec les solutions web les plus attaquées sans faire gaffe au b-a-ba de la sécurité (permissions restrictives), tu devrais pas avoir besoin d'être parano outre mesure.

Dernière modification par krodelabestiole (Le 19/11/2020, à 16:52)

---

nouveau forum ubuntu-fr on en parle là : refonte du site / nouveau design
profil - sujets récurrents - sources du site

MicP

Re : Linux, *BSD, Unix... des millions de serveurs vulnérables ?

Bonjour

Et puis, allez lire régulièrement les alertes de sécurités
publiées sur des pages web comme celle là : https://www.cert.ssi.gouv.fr/

=======
AMHA, traiter un administrateur réseau ou de site web (ou de tout ce qui touche à l'informatique) de "parano",
c'est lui faire un beau compliment.

Et très souvent, dans ces cas là,
on se rends compte que la personne ne sait pas du tout ce qu'est la paranoïa
et/ou encore moins comment fonctionne internet.

Dernière modification par MicP (Le 20/11/2020, à 20:47)

metalux

Re : Linux, *BSD, Unix... des millions de serveurs vulnérables ?

Merci pour tous ces compléments d'infos, encore de très bons conseils qui changent de ce qu'on a l'habitude de lire quand on recherche de l'info sur l'auto-hébergement.

---

Faîtes la mise à jour de vos P.P.A. automatiquement

bruno

Re : Linux, *BSD, Unix... des millions de serveurs vulnérables ?

Il me semble important d'ajouter que ce qui est montré n'est absolument pas une faille de sécurité mais une mauvaise pratique d'administration système.
Certains adminsys ou développeurs ignorent ou ont oublié que lorsqu'un utilisateur à les droits d'écriture sur un dossier, il peut y renommer ou supprimer n'importe quel fichier même s'il n'en est pas le propriétaire.

MicP

Re : Linux, *BSD, Unix... des millions de serveurs vulnérables ?

… ce qui est montré n'est absolument pas une faille de sécurité mais une mauvaise pratique d'administration système.

+1

Dernière modification par MicP (Le 22/11/2020, à 03:57)