1. Sécurité des applications Web [7 sous-questions ; 18 points] Après avoir fini vos études à Polytechnique, vous décidez de créer sur le Web une radio de musique alternative en ligne. Pour avoir le contrôle complet sur le fonctionnement du site Web, vous décidez d héberger le site sur votre propre serveur qui se trouve dans une armoire à la maison. Vous décidez d implanter le site en PHP/MySQL sous Linux avec le serveur de page Web Apache. Comme vous ne pouvez pas être en ondes tout le temps, vous avez embauché quelques amis en tant qu'animateurs d'émission (des DJ). Vous avez programmé une petite application en PHP qui gère le contenu des émissions et permet de les modifier. Les DJ préparent le contenu de leurs émissions à l'avance avec cette application, en accédant au serveur Web à partir de chez eux. Pour éviter que n'importe qui puisse changer le contenu des émissions, vous avez activé les fonctionnalités d'authentification d'usager de Apache et donné à chaque animateur son propre nom d'usager et mot de passe. Comme certains des animateurs sont très compétitifs entre eux, vous avez configuré votre application de façon à ce que chaque animateur puisse seulement changer le contenu de sa propre émission. a) [3 pts] Apache garde la base de données de hachés cryptographiques de mot de passe dans un fichier qui contient le nom d'usager, une indication de la fonction utilisée pour calculer le haché cryptographique, et ce haché lui-même. Voici un exemple d'un fichier de mot de passe où nous avons utilisé SHA1 (pour rose, david et jean), MD5 (pour louise) et la fonction crypt (valeur par défaut, pour charles) pour calculer le haché du mot de passe : charles:dtw.1xbgg34z2 rose:{sha}+pvrmeqcmtwmyvoz57uuitvghrm= david:{sha}o1w3zxjfh0rfqhjqpxf1yj7jjfk= louise:$apr1$u/n/a/..$rmvqyo2sncy0mvpdbg0ar0 jean:{sha}+pvrmeqcmtwmyvoz57uuitvghrm= Vous vous êtes trompé dans la configuration d'apache et le fichier ci-haut est devenu visible à tout usager qui arrive à se loguer sur le système avec un compte d'animateur. Est-ce que ceci cause réellement un problème de sécurité? Si oui, décrivez un scénario et une menace plausible, si non expliquez pourquoi. En tout premier lieu, si les mots de passe ont été mal choisis (mots du dictionnaire), un outil de recherche exhaustive (tel que John the Ripper) pourrait être utilisé pour retrouver ces mots de passe. Deuxièmement, la fonction crypt n'est pas sécuritaire et relativement facile à inverser. Donc, le mot de passe de charles pourrait être facilement découvert même s'il n'est pas "facile". Troisièmement, étant donné qu Apache n'utilise pas de "salt", les hachés de mots de passe identiques sont aussi identiques. C'est le cas des mots de passe de rose et de jean. En regardant ce fichier, jean pourrait se rendre compte de ceci et utiliser ce même mot de passe pour se loguer comme "rose" et effacer son émission, ou encore pire remplacer ses clips audio par de la musique classique!!! b) [3 pts] Vous êtes au courant de la technique d exploitation d injection SQL (SQL Injection) et pour se protéger contre cela, dans le code PHP vous filtrez les données entrées par les utilisateurs dans la page d authentification pour ne pas permettre le caractère apostrophe ( ). Cette mesure est-elle suffisante pour s assurer que votre site n est pas vulnérable à l injection SQL? Si oui, pourquoi? Si non, pourquoi et que devriez-vous faire à la place? Quoique cette mesure pourrait bloquer certaines attaques d injection SQL, elle n est pas suffisante parce que : Une attaque d injection peut toujours être possible à cause des guillemets ("). D autres pages sur le site, en plus de la page d authentification, peuvent être vulnérables. À la place, on devrait faire au moins deux des choses suivantes : Page 1 de 7
Au lieu de filtrer les caractères connus comme problématiques, accepter seulement les caractères attendus (par exemple, lettre majuscule et minuscule et espace pour le nom d usager et lettre et chiffre pour le mot de passe) sur toutes les pages du site web. Utiliser les SQL Stored Procedures Utiliser les fonctions PHP pour commenter automatiquement les caractères spéciaux Vérifier à l aide des outils automatisés que le site n est pas vulnérable. c) [3 pts] Vous avez décidé de faire affaire avec BigAddy un des plus grands revendeurs de publicité Internet. Vous avez intégré dans votre application du code javascript permettant à BigAddy d'afficher des "bannières" publicitaires sur les fureteurs de vos clients. Vous recevez de BigAddy des redevances de quelques sous pour chaque annonce affichée, et même de quelques dollars pour chaque "click" de l'utilisateur sur une de ces bannières qui l'amène vers le site d'un des clients de BigAddy. Vous éprouves des difficultés financières et, vous considérez brièvement l'option de faire de la fraude publicitaire et de générer des faux affichages et des faux "click" pour vous faire payer par BigAddy. Vous mettez, bien sûr, cette idée de côté car ceci n'est pas légal ni éthique. Néanmoins, et théoriquement, quelles méthodes auriez-vous pu utiliser pour faire ceci, sachant que BigAddy a quand même des systèmes anti-fraude qui limitent le nombre d'annonces et de «clicks» crédités attribuables à une même adresse IP (celle du client Web) pour une certaine période de temps (p.ex. une annonce par seconde et un click par minute)? La méthode la plus couramment utilisée par les criminels pour réaliser de la fraude publicitaire est d'utiliser des machines qui ont été infectées et qui font partie d'un botnet. On installe sur ces machines des scripts qui vont automatiser la connexion sur des serveurs Web, de façon à imiter des utilisateurs légitimes, en initiant de fausses sessions HTTP (ce qui va aller chercher des bannières sur le serveur de publicité) et en initiant de fausses sessions HTTP avec les annonceurs, en faisant le fureteur "cliquer" sur ces annonces. Pour éviter d'être détectée, chaque machine initiera un nombre limité de fausses sessions. Si toutes les machines envoient quelques requêtes par minutes, un botnet de quelques dizaines de millier de machines peut générer facilement des milliers de dollars par jour... d) [3 pts] Un autre ancien étudiant de Polytechnique, qui est devenu votre ennemi juré lors de vos études (après que vous ayez eu un différent lorsque vous étiez partenaires de laboratoire dans le cours de sécurité...), devient très jaloux de votre succès et décide de vous nuire. Il construit un "faux" de votre site Web, qui ressemble exactement au vôtre, afin de vous voler vos revenus de publicité. Les clients ne s'en rendent même pas compte car son site est identique et en réalité le système de facturation de BigAddy n'est pas en mesure de vérifier que les bannières de sécurité sont envoyées à un faux site. Seul petit problème technique : comment peut-il convaincre les utilisateurs de votre système (ou leur ordinateurs) d'aller sur son site plutôt que sur le vôtre? Décrivez deux méthodes qu'il pourrait utiliser dans ce contexte. La technique la plus répandue est probablement le hameçonnage par courriel. Dans ce cas, il commencerait une campagne de spam où il inciterait les utilisateurs à suivre un lien HTML dans le texte du courriel, dont l'url pointerait vers son site mais dont le texte affiché semblerait indiquer que le lien va vers le vrai site. Pour ce faire, on utilise souvent la cupidité des utilisateurs, p.ex. "Gagnez un voyage en Floride en venant écouter de la musique sur notre Site", etc. Une autre possibilité est le "Google hacking", où le pirate arrive à déjouer les algorithmes de "ranking" de pages Web (ordonnancement) du moteur de recherche en s'arrangeant pour que son site soit listé avant le votre lors de la recherche. Pour se faire, il utilise soit des araignées Web (Web crawlers) ou des bots dans un botnet qui vont générés pleins de faux liens pointant vers son site à lui, ce qui va augmenter son ranking. Il peut aussi utiliser du "DNS cache poisoning" ce qui lui permettrait d'émettre des fausses réponses aux requêtes DNS faites sur votre nom de domaine, de façon à que ceux qui reçoivent ces fausses réponses aillent sur votre site même s'ils ont utilisés le bon URL. e) [2 pts] Afin de mieux protéger les communications entre vos clients et le site Web, vous décidez de sécuriser la connexion avec votre serveur Web en utilisant le protocole sécurisé de couche application HTTPS. Pour cela, il vous faut obtenir un certificat de clé publique, qui sera envoyé au fureteur de ceux qui se connecteront sur votre Page 2 de 7
site. En premier lieu, on vous recommande de faire affaire avec l'autorité de certification MuchoSign, qui, pour la modique somme de 1 500$, vous signe un certificat contenant votre clé publique valable pour un an. Décrivez en détails quelles sont les étapes de la vérification de ce certificat lors de l établissement de la connexion sécurisée réalisée par le fureteur, et ce, jusqu'à l'affichage du petit icône de cadenas sur la barre de statut. En particulier, décrivez les conditions qui permettent que cette vérification soit possible. Lors de l'établissement de la connexion, le serveur fourni au fureteur une copie du certificat de clé publique, signé par MuchoSign. Comme le fureteur contient déjà dans ses fichiers de configuration une copie du certificat auto signé de MuchoSign, il peut en extraire la clé publique pour vérifier la signature du certificat qu'il vient de recevoir, celui-ci contenant toutes les informations nécessaires pour le faire (haché cryptographique signé de la clé publique du serveur, avec indications des fonctions de hachage et de signature utilisées). f) [2 pts] Est-ce que l'utilisation de HTTPS rend plus difficile à votre ennemi juré de faire passer son "faux" site pour le vôtre? Expliquez votre réponse. En plus de vérifier l'authenticité de la clé publique contenue dans un certificat, le fureteur vérifie également que le "nom" contenu dans le certificat fourni par le serveur Web correspondant vraiment au nom de domaine du serveur Web. Ceci empêche donc un faux site d'utiliser tout bêtement le certificat à clé publique d'un autre site Web (le vrai). D'autre part il ne peut pas utiliser son propre certificat (associé à son nom de domaine à lui), car même s'il était capable de rediriger le trafic de votre site vers le sien (en utilisant une attaque à niveau réseau, tel que le DNS cache poisoning ou du «session hijacking», voir question 1.d), l'utilisateur serait averti que le nom de domaine "affiché" de l'url ne correspond pas à celui du certificat. Ceci dit, pour que cela "marche", il faut que l'utilisateur vérifie le nom de domaine de l'url. Si non, il suffit de l'envoyer à une fausse URL et lui fournir un certificat correspondant à cet URL pour que la session HTTPS soit établie avec le faux site et que le cadenas s'affiche... g) [2 pts] Malheureusement, la compagnie MuchoSign n'a pas une politique de vérification des identités très poussée, et votre ennemi juré a réussi à obtenir un certificat signé de MuchoSign qui contient une clé publique qui lui appartient. De plus, et en se faisant passer pour un employé de votre compagnie (vous n'avez même pas d'employés!!), il a réussi à faire en sorte que ce certificat soit associé à votre nom de domaine. En quoi (dans quel scénario) ceci pourrait constituer une menace pour vous? À part rectifier ses politiques, quelles actions la compagnie MuchoSign devrait-elle prendre pour rectifier son erreur et en mitiger les conséquences? Le problème est qu'avec l'accès à ce certificat, votre ennemi est en mesure de faire passer son site pour le votre, en autant qu'il soit capable de diriger le trafic de votre site vers le sien (par exemple par une des techniques de la question 1.d). Pour rectifier la situation, MuchoSign peut émettre un certificat de révocation, signé par eux, dans lequel ils indiquent que le certificat qu ils avaient préalablement signé (celui de votre ennemi juré), n est plus valide, ni non plus aucune signature émise avec la clé publique correspondante. Ce certificat de révocation peut alors être inclus dans la liste de certificat de révocation (Certificate Revokation List, ou CRL) du fureteur lors de la prochaine mise à jour du logiciel du fureteur. 2. Bastionnage de réseaux [3 sous-questions ; 12 points] Quelques années plus tard, votre business de radio en ligne va bon train et s est agrandi. Vous avez maintenant plusieurs employés qui travaillent dans vos nouveaux bureaux dans le Vieux Montréal. Certains d entre eux sont des employés administratifs qui gèrent les comptes avec vos clients, s occupent de vos impôts, etc. Ils ont donc besoin d accéder à l Internet pour envoyer et recevoir des courriels, transiger sur les sites bancaires et du gouvernement, etc. Les DJ, par contre, préparent le contenu des émissions qui sont rediffusées à partir de votre serveur Web; pour ce faire, ils continuent à utiliser votre bonne vieille application Web interne (en PHP) qui roule sur le serveur Apache. Cependant, cette application est accessible seulement via le port 8088 du serveur Web. Le serveur Web se trouve également dans vos bureaux et il est connecté via une connexion de très haute bande passante à Audiotron qui est votre fournisseur de service Internet. Les clients de votre station peuvent accéder au contenu audio et HTML via le port HTTP standard (80). Afin de mieux protéger vos données corporatives, y compris votre base de données de fichiers mp3 utilisée pour la confection des émissions, vous avez décidé de protéger votre réseau interne en installant une DMZ entre l Internet et Page 3 de 7
le réseau interne de la compagnie. Au début, vous songiez à utiliser des adresses privées pour les machines dans la DMZ, mais après avoir négocié avec Audiotron, vous avez réussi à avoir des adresses IP statiques à bon prix dans la plage 123.45.67.*, en assez grand nombre pour chaque machine que vous voulez placer dans la DMZ. Ceci vous simplifie grandement la tâche de configuration du réseau, car il n y aura pas de NAT sur le routeur/pare-feu externe, mais seulement sur le routeur/pare-feu interne. Les adresses IP dans la zone interne seront donc dans la plage 192.168.*.*. a) [4 pts] Faites le schéma du réseau en y plaçant les éléments suivants : Les machines des employés ; un serveur de courriel Internet (pour le courrier entrant) ; le serveur de fichiers mp3, le serveur Web pour les pages des émissions et la rediffusion, et un serveur mandataire (proxy) pour l accès HTTP sur Internet par les employés. Voici le schéma de réseau : LAN avec adresses 192.168.* DMZ avec adresses 123.45.67.* Machine employé Web courriel Internet BD Mp3 Proxy b) [4 pts] Vous décidez d appliquer une politique de blocage par défaut pour le routeur/pare-feu interne séparant votre réseau et la DMZ. Quelles sont les règles qui devraient être appliquées sur le pare-feu pour que tous les services nécessaires au fonctionnement de l entreprise soient disponibles? (Pour les connexions TCP, indiquez le sens de la connexion permise). Les règles suivantes devraient être activées : - Connexion sortante entre machine(s) employé et le serveur proxy sur le port 80 - Connexion sortante entre machine employé et le serveur Web sur 8088 - Connexion sortante entre machines employé et serveur courriel sur le port POP3 ou IMAP. c) [4 pts] Après un pénible conflit de travail, vous avez accepté que les DJ puissent travailler hors du bureau sur leurs émissions (par exemple, de la maison ou d un café Internet, comme dans le bon vieux temps quand vous n aviez pas encore de bureau ). Pour que cela puisse se faire, vous avez décidé d installer un serveur de passerelle VPN dans votre réseau. Pour que le travail à distance soit le plus transparent possible pour les DJs, il est décidé que les adresses IP virtuelles attribuées aux connections VPN de leurs machines seront dans la même plage d adresse générale comme s ils étaient au bureau, soit dans 192.168.*.* Cependant, et pour faciliter la tâche de configuration du réseau, on place les machines connectées en VPN dans une plage d adresse spéciale soit 192.168.99.* Dans ces circonstances, et en tenant compte que le trafic pour ces adresses transigera par le serveur VPN, où devrait-on placer ce serveur VPN selon vous? Étant donné votre choix, sera-t-il nécessaire d ajuster les paramètres de routage ou les règles des routeurs/pare-feu internes et externes? Si oui, quels ajustements devront être faits? Si non, expliquez pourquoi. Deux choix sont possibles : 1) Placer le serveur VPN dans la DMZ. Ceci à l avantage que la configuration du pare-feu interne n a pas besoin d être «ouverte» pour que du trafic venant directement de l extérieur (celui diriger vers le serveur VPN) puisse pénétrer jusque dans le réseau interne. Cependant, il faut alors s assurer que le trafic entre le serveur VPN et le réseau interne puisse passer à travers le pare-feu interne et il faut aussi s assurer que le trafic pour les machines dans le VPN soit rediriger au serveur VPN. Ceci peut être accompli par les règles suivantes : Page 4 de 7
Sur le pare-feu interne : laisser passer tout trafic entrant et sortant entre le serveur VPN (e.g. 123.45.67.99) et le réseau interne 192.168.*.* Pour diriger le trafic du VPN vers le serveur VPN : Soit changer manuellement les tables de routages sur tous les serveurs de la DMZ pour router tout le trafic 192.168.99.* vers 123.45.67.99 ; ou Sur le pare-feu interne, changer manuellement la table de routage pour router tout le trafic 192.168.99.* vers 123.45.67.99. (la première option est plus difficile à gérer, mais est plus performante) LAN avec adresses 192.168.* DMZ avec adresses 123.45.67.* Machine employé VPN Web courriel Internet BD Mp3 Proxy 2) Placer le serveur VPN dans le réseau interne. Ceci à l avantage qu aucun ajustement à besoin d être fait dans les règles du pare-feu interne ou dans la DMZ, mais le désavantage que du trafic non filtré de l Internet peut se diriger vers le réseau interne. Il faut donc ajouter cette règle sur le pare-feu interne : Laisser passer du trafic VPN entrant et sortant entre l adresse du serveur VPN (p.ex. 192.168.99.1) et l Internet (via la passerelle routeur externe). LAN avec adresses 192.168.* DMZ avec adresses 123.45.67.* Machine employé Web courriel Internet BD Mp3 Proxy VPN 3. Principes de base en sécurité [3 sous-questions ; 10 points] a) [4 pts] Décrivez dans vos propres mots le principe de «défense en profondeur», tel qu il est appliqué en sécurité informatique, ainsi que ses avantages principaux. Donnez deux exemples d application de ce principe dans le contexte de la sécurité des réseaux informatiques en expliquant brièvement pour chaque exemple comment son utilisation permet de diminuer le risque. Le principe de défense en profondeur consiste à l application de contre-mesures de sécurité à plusieurs niveaux ou endroits dans un système informatique, chacune de ces contre-mesures opérant de manière indépendante mais complémentaire. Nous l avons décrite en cours avec la maxime «Mieux vaut neuf murs de un pied, que un mur de neuf pieds» (on parle ici d épaisseur du mur, bien sûr, et non pas de sa hauteur ). L avantage principal de son utilisation est d un côté la redondance des moyens déployés, mais aussi le fait qu il est souvent plus facile d adapter les paramètres des contre-mesures à chacun des contextes où elles seront utilisées, ce qui permet d avoir une gestion plus facile et une performance supérieure de ces contre-mesures (autant en termes de réduction de risque mais aussi en termes d un impact moindre sur la performance des systèmes qu on vise à protéger). Voici quelques exemples de défense en profondeur dans les réseaux : Page 5 de 7
L utilisation de cryptographie pour assurer la confidentialité des transmissions autant au niveau de la couche 2 (p.ex. WEP et WPA sur le standard sans-fil 802.11), de la couche 3 (p.ex. IPSEC) et de la couche 7 (SSL, SSH, etc.). Comme nous avons vu dans le cours, il faut souvent ajuster les paramètres de chiffrement en fonction du type d information à transmettre (les caractéristiques de la source), afin d assurer la confidentialité contre certains types d attaques cryptanalytiques. Ceci peut seulement être fait au niveau de la couche application, d où la nécessité du chiffrement à ce niveau. D autre part, le chiffrement au niveau des couches inférieures permet de chiffrer certaines des entêtes des paquets et protège la confidentialité de la nature du trafic, p.ex. qui parle avec qui (analyse de trafic). Le déploiement de règles de pare-feu différentes pour chacune des passerelles entre les différents sousréseaux (et choisies selon le type de trafic qu on espère y transigera) en combinaison à l utilisation de pare-feu individuel de machines, où les règles peuvent être ajustés en fonction des applications installés et de l utilisation espérée de cette machine. Dans ce cas, les règles à niveau de la machine peuvent être plus «raffinées» et adaptées au contexte, car il n y aura pas d impact sur d autres machines. Cependant, l utilisation de protection et de règles à niveau du réseau protège contre une configuration mauvaise, incomplète ou absente à niveau des machines. Un autre exemple similaire est le déploiement de d IDS, ou on peut combiner un détecteur qui capte tout le trafic d un réseau ou d un sous-réseau et fait l analyse de ce trafic dans sa globalité (les «networkbased»), et des détecteurs déployés sur les machines qui analyse le trafic dirigé particulièrement à cette machine («host-based»), et ce en tenant compte du contexte de la machine (quelles applications roulent, quelles sont les tendances d utilisation locale, etc.). b) [4 pts] Décrivez le concept de «segmentation» tel qu il est appliqué à la sécurité informatique en décrivant ses avantages principaux. Décrivez un exemple dans le domaine de la cryptographie et un autre dans le domaine de la sécurité des systèmes d exploitation ou du logiciel en expliquant pourquoi son application permet de diminuer le risque. Le principe de segmentation consiste à diviser les biens informatiques en parties, ou en «segments», qui seront protégées de façon indépendante. L avantage principal est qu ainsi si un des moyens de protection est compromis ou est rendu inefficace, seulement une partie des biens est compromise. Il s agit donc ultimement d une stratégie de gestion du risque, qui peut être traduite par la maxime: «on ne met pas tous les œufs dans le même panier». Dans le domaine de la cryptographie, l exemple principal est le principe de segmentation de clé, où l on utilise différentes clés cryptographiques pour protéger différentes partitions des données, par exemple une clé pour chaque jour, ou pour par exemple différentes parties d un réseau ou différents documents ou types de documents. On peut donc segmenter dans le «temps» ou dans l «espace» (réseau, BD de documents, etc.). L avantage est qu ainsi si une clé est compromise, seulement les documents du même type, données de ce sousréseau, ou les données envoyées cette journée là sont compromis. Voici quelques exemples dans le domaine de la sécurité des SE ou du logiciel : La segmentation de l espace mémoire et des ressources dans le SE, entre l espace usager («user space») et l espace noyau («kernel space»). L attribution de permissions d accès différentes sur des répertoires différentes du système de fichiers dans un SE. La séparation à niveau du matériel (différentes machines) entre le serveur de page Web, le serveur transactionnel exécutant le code de l application (PHP,.net, PERL, etc.) et le serveur de base de données. L utilisation de fichiers de mot de haché de mot de passe différents pour différentes machines. Dans tous ces cas, la segmentation permet que si quelqu un gagne l accès à une des composantes (user space, répertoire non critique, 0wné le serveur de pages Web), les autres composantes critiques du système ne sont pas compromises. Page 6 de 7
c) [2 pts] Quelle est la relation entre la segmentation et la défense en profondeur? Selon vous, existe-t-il une différence entre les deux ou s agit-il de la même chose? L un est le précurseur de l autre. C est la segmentation du système qui permet que l on puisse déployer des contre-mesures, potentiellement différentes, sur les différentes parties du système. La différence est que quoique la segmentation implique une séparation des biens informatiques pour des raisons de sécurité, elle n implique pas nécessairement le déploiement de moyens de sécurité différents pour chacun des segments, et lorsque oui, en général ils sont appliqués de façon homogène (les mêmes protections pour chaque segment). Le concept de défense en profondeur implique en général que les moyens déployés sont hétérogènes, étant adaptés ou optimisés pour le contexte (segment) où ils sont déployés. Page 7 de 7