Comment les hébergeurs empêchent-ils la compromission d'un site Web de provoquer la compromission d'un autre?

Question

Peut-on créer un site Web vulnérable dans le but d'attaquer un serveur d'un hébergeur?

Donc, dans la question ci-dessus que j'ai récemment posée, nous sommes arrivés à la conclusion que d'empêcher un site Web vulnérable d'ouvrir les portes à tous les autres sites Web sur le même serveur doit être fait d'une manière ou d'une autre en contrôlant les privilèges des utilisateurs.

Par conséquent, je me demandais comment cela se réalisait dans l'hébergement Web partagé. Ce système d'exploitation est-il basé sur l'UAC sous Windows ou comment cela fonctionne-t-il conceptuellement?

Je comprends que cela peut différer d'un serveur à l'autre mais je voudrais comprendre les options de défense d'un hébergeur afin de comprendre l'ampleur de ce fil.

Conor Mancone · Accepted Answer

Cette question est un peu large, mais je pense qu'une réponse un peu large sera toujours utile. La réponse dépend du "type" d'hébergement dont vous parlez. Il y a trois types principaux que je décrirai ci-dessous, mais juste pour info les noms que j'utilise ne sont pas nécessairement des noms standard de l'industrie. Les concepts sont cependant assez communs dans tous les domaines:

Hébergement mutualisé (c'est le type d'hébergement dont Jeroen parle dans sa réponse)
Hébergement VPS (alias serveurs privés virtuels)
Hébergement dédié

Hébergement partagé

Avec une configuration d'hébergement partagé, de nombreux sites Web s'exécutent sous la même instance du même système d'exploitation, et différents "sites Web" sont généralement séparés en ayant différents comptes d'utilisateurs sur le même système. cPanel et Plesk sont deux systèmes logiciels courants qui gèrent de telles configurations (bien que Plesk puisse également être utilisé pour gérer l'hébergement VPS). En conséquence, vous devez vous soucier de sécuriser deux aspects principaux de votre système: vous assurer que les comptes d'utilisateurs sont correctement isolés (voir l'excellente réponse de Jeoroen), et vous assurer que votre gestionnaire de conteneurs (Plesk, cPanel, etc ...) n'a pas de faiblesses. Ces outils ont parfois leurs propres vulnérabilités, et si quelqu'un parvient à s'introduire dans votre logiciel de gestion de conteneurs, ils se retrouvent généralement avec un accès root au serveur physique, ou dans le pire des cas, un accès root à tous les serveurs gérés par ce système. De plus, si vous donnez aux utilisateurs un accès en ligne de commande, vous devez vous soucier des vulnérabilités potentielles d’élévation de privilèges dans le système d’exploitation lui-même.

Hébergement VPS

Avec l'hébergement VPS (serveur privé virtuel), le serveur physique lui-même exécute une sorte de logiciel de virtualisation qui exécute ensuite un certain nombre de "machines virtuelles" qui exécutent un système d'exploitation complet et séparé. Quelques exemples d'outils qui gèrent ce type de configuration sont l'hyperviseur KVM ou l'hyperviseur XEN. L'avantage de ce type de configuration est qu'il donne à l'utilisateur final (alias le client de la société d'hébergement) ) un contrôle total sur leur propre système. Ils peuvent théoriquement installer le système d'exploitation de leur choix, disposer d'un accès root/administrateur complet et installer/gérer le logiciel de leur choix. L'hyperviseur maintient chaque système d'exploitation virtuel séparé des autres et complètement mis en bac à sable les uns des autres. . En théorie, il est impossible pour un hôte compromis d'avoir un impact sur les autres. En pratique, bien sûr, les choses ne sont pas toujours parfaites. Bien que (je crois) il soit plus rare et plus difficile à exploiter, les hyperviseurs eux-mêmes ont parfois leur propre vulnérabilités qui peuvent permettre à un attaquant malveillant de prendre le contrôle de l'ensemble du système (Spectre et Meltdown étaient pertinents pour les hyperviseurs - h/t phyrfox). Comme toute autre chose, la mise à jour de vos systèmes est la clé.

Hébergement dédié

Certains hébergeurs proposent un hébergement dédié, où ils gèrent simplement le matériel pour vous et fournissent un accès Internet. Ils installent un OS de votre choix sur un serveur et vous donnent essentiellement un accès root/admin. De toute évidence, cela n'est pas immédiatement pertinent pour votre question, car il ne s'agit plus d'un hébergement partagé - personne d'autre n'a d'impact. Cependant, ils sont toujours à l'intérieur de votre réseau, donc des contrôles d'accès réseau appropriés sont toujours un must (et cela est également vrai pour toutes les autres instances d'hébergement).

Gestion du résea

Modifier pour ajouter: ce dernier point sur la sécurité du réseau mérite sa propre mention. Que vous utilisiez l'hébergement de fragments, l'hébergement VPS ou l'hébergement dédié, une société d'hébergement donne intrinsèquement l'accès au réseau interne à un tiers. Sans contrôles d'accès clairs, cela signifie que toute personne utilisant vos services d'hébergement peut potentiellement analyser les autres systèmes du réseau pour détecter leurs propres vulnérabilités de système d'exploitation. Par exemple, peu importe si votre couche de virtualisation peut parfaitement isoler les serveurs virtuels qui y sont exécutés si l'une des instances VPS peut trouver d'autres instances sur le réseau et accéder via des vulnérabilités de niveau réseau dans le système d'exploitation (par exemple heartbleed/bleu éternel). De nombreuses grandes sociétés d'hébergement vous permettront (à la personne utilisant l'hébergement) de configurer un VPC - cloud privé virtuel - à l'intérieur de leur réseau pour isoler vos systèmes d'Internet et d'autres systèmes sur leur propre réseau. En supposant que leurs règles de réseau fonctionnent réellement comme promis, cela donne à l'utilisateur final des moyens supplémentaires de se protéger. Vraisemblablement, les plus grands fournisseurs de services disposent également d'une sécurité réseau active qui peut détecter le trafic réseau malveillant à l'intérieur de leur propre réseau et fermer les comptes de manière appropriée.

En bref, les types de vulnérabilités dont vous devez vous soucier dépendent beaucoup de votre configuration d'hébergement. Bien sûr, ces jours-ci, il existe une toute nouvelle série d'options d'hébergement des grands fournisseurs d'hébergement (aka infrastructure sans serveur) qui ont leur propre liste de préoccupations complètement distincte, mais je pense que ce qui précède décrit les principales préoccupations concernant les types d'hébergement que vous avez dans esprit.

Jeroen · Answer

Peut-on créer un site Web vulnérable à dessein pour attaquer un serveur d'un hébergeur?

Oui, c'est définitivement possible. Comme je n'ai vécu cela qu'avec des solutions d'hébergement basées sur Linux, je ne peux partager mon expérience que dans ce scénario.

À plusieurs reprises, j'ai réussi à compromettre un serveur d'hébergement partagé entier qui exécutait DirectAdmin/Plesk.

Cela était dû à des autorisations de fichiers et de dossiers insuffisantes, tout utilisateur du système avait un accès en lecture pour les répertoires personnels des autres utilisateurs (lisibles par tous) et donc leurs dossiers de domaine et public_html/private_html sous-dossiers.

Si l'un des domaines sur le serveur partagé exécute une application vulnérable qui, par exemple, permet aux utilisateurs de télécharger des fichiers de manière non sécurisée, il est possible de télécharger un shell Web.

Une fois que l'attaquant a accès au shell Web et que les autorisations de fichier/dossier ne sont pas correctement définies, l'attaquant peut parcourir l'intégralité du système de fichiers (tant que les dossiers sont lisibles par le monde, bien sûr).

Il est recommandé de configurer l'autorisation de fichier et de dossier aussi strictement que possible et de ne contenir la vulnérabilité que pour un domaine spécifique.

allo · Answer

C'est une question assez large et elle suppose que les hébergeurs vous protègent effectivement suffisamment contre ce problème.

L'hébergement Web partagé typique utilise:

Apache mod_suexec
mode sans échec PHP , open_basedir et des mesures similaires intégrées dans php. C'est l'une des raisons pour lesquelles presque toutes les offres d'hébergement partagé incluent le php, mais rarement Perl, python, Ruby et ainsi de suite.
Possibilité d'exécuter plusieurs instances de php-fpm à l'aide de fastcgi. Ceux-ci peuvent même fonctionner sur un autre hôte que le serveur Web tant qu'ils peuvent lire (et écrire) les fichiers de l'utilisateur correspondant.
Autorisations restrictives pour les foyers d'utilisateurs.

Cela a encore beaucoup de place pour les améliorations, qui sont faites par les meilleures offres et négligées par les pires.