Cours MIT "Sécurité des systèmes informatiques". Conférence 8: Modèle de sécurité réseau, partie 3

Institut de technologie du Massachusetts. Cours magistral # 6.858. "Sécurité des systèmes informatiques." Nikolai Zeldovich, James Mickens. 2014 année

Computer Systems Security est un cours sur le développement et la mise en œuvre de systèmes informatiques sécurisés. Les conférences couvrent les modèles de menace, les attaques qui compromettent la sécurité et les techniques de sécurité basées sur des travaux scientifiques récents. Les sujets incluent la sécurité du système d'exploitation (OS), les fonctionnalités, la gestion du flux d'informations, la sécurité des langues, les protocoles réseau, la sécurité matérielle et la sécurité des applications Web.

Cours 1: «Introduction: modèles de menace» Partie 1 / Partie 2 / Partie 3
Conférence 2: «Contrôle des attaques de pirates» Partie 1 / Partie 2 / Partie 3
Conférence 3: «Débordements de tampon: exploits et protection» Partie 1 / Partie 2 / Partie 3
Conférence 4: «Séparation des privilèges» Partie 1 / Partie 2 / Partie 3
Conférence 5: «D'où viennent les systèmes de sécurité?» Partie 1 / Partie 2
Conférence 6: «Opportunités» Partie 1 / Partie 2 / Partie 3
Conférence 7: «Native Client Sandbox» Partie 1 / Partie 2 / Partie 3
Conférence 8: «Modèle de sécurité réseau» Partie 1 / Partie 2 / Partie 3

Public: pourquoi un jeton aléatoire est-il toujours inclus dans l'URL et non dans le corps de la demande?

Professeur: HTTPS est utilisé de cette manière, mais il n'y a aucune bonne raison de ne pas inclure de variables aléatoires dans le corps de la demande. C'est simplement qu'il existe des formes d'héritage qui fonctionnent de cette façon via l'URL. Mais en pratique, vous pouvez mettre ces informations ailleurs dans la demande HTTPS, à l'exception de l'en-tête.

Cependant, notez que le simple fait de déplacer ces informations dans le corps de la demande est potentiellement dangereux s'il y a quelque chose que l'attaquant peut deviner. Ensuite, l'attaquant peut toujours appeler les URL dont il a besoin. Par exemple, lorsque je fais une requête HTTP XML, puis que je mets explicitement du contenu dans le corps que l'attaquant peut deviner.



Si vous définissez simplement le cadre dans l'URL, l'attaquant peut le contrôler. Mais si vous utilisez une requête HTTP XML et qu'un attaquant peut en générer une, alors l'interface XML HTTP vous permet de définir le corps de la requête. Une requête XML HTTP est limitée à la même origine. Cependant, si un attaquant peut faire quelque chose comme:

<script> var x = “ntrusted”; </script> 

Il pourra ensuite implémenter la requête XML HTTP, qui sera exécutée avec l'autorisation de la page embarquée.

Tout dépend de ce à quoi l'attaquant a accès. S'il peut forcer la page à exécuter un script non contrôlé, comme indiqué ci-dessus, il peut utiliser la propriété JavaScript appelée HTML interne et obtenir tout le contenu HTML de la page. Si un attaquant peut ou ne peut pas générer une requête AJAX, c'est une chose, s'il peut ou ne peut pas voir le bon code HTML, c'est une autre, et ainsi de suite. En bref, ce jeton généré de manière aléatoire est capable d'empêcher les attaques CSRF.

Il y a encore une chose à laquelle vous devez faire attention: les adresses réseau. Ils concernent la partie de notre conversation qui a indiqué qui l'attaquant ne pouvait pas communiquer via une requête HTTP XML.

Concernant les adresses réseau, la trame peut envoyer des requêtes HTTP et HTTPS à (hôte + port) correspondant à son origine. Notez que la sécurité de la même stratégie de la même source est très étroitement liée à la sécurité de l'infrastructure DNS, car toutes les stratégies de ce type sont basées sur ce que vous êtes appelé.

Donc, si vous pouvez contrôler ce qu'ils m'appellent, vous pouvez faire des attaques plutôt malveillantes, par exemple, une attaque de re-liaison DNS. Le but de cette attaque est de lancer un JavaScript contrôlé par un attaquant avec l'autorité (ou au nom de) le site de la victime, appelons-le victim.com. Dans ce cas, l'attaquant utilise les règles de la même politique source et va en quelque sorte lancer le code qu'il a écrit avec la permission d'un autre site.

Cela se fait comme suit. Tout d'abord, un attaquant enregistre un nom de domaine, par exemple attacker.com. C'est très simple, il suffit de payer quelques dollars - et en déplacement, vous avez votre propre nom de domaine. L'attaquant doit également configurer le serveur DNS pour répondre aux demandes qui viennent au nom des objets situés sur attacker.com.



La deuxième chose qui devrait se produire est que l'utilisateur doit visiter attacker.com. En particulier, il doit visiter un site qui dépend de ce nom de domaine. Il n'y a rien de compliqué non plus dans cette partie de l'attaque.

Voyez si vous pouvez créer une campagne publicitaire, par exemple, offrir un iPad gratuit. Tout le monde veut un iPad gratuit, bien que je ne connaisse personne qui ait jamais gagné un iPad gratuit. Donc, en cliquant sur un tel message dans un e-mail de phishing, et vous êtes déjà sur le site de l'attaquant. Rien de spécial, cette partie n'est pas compliquée.

Que va-t-il se passer ensuite? Le navigateur commencera à générer des requêtes DNS pour attacker.com car la page que vous avez visitée contient des objets qui pointent vers des objets situés sur attacker.com. Mais le navigateur va dire: "Je n'ai jamais vu ce domaine auparavant, alors laissez-moi envoyer une demande DNS pour pouvoir contacter attacker.com"!



Et le serveur DNS de l'attaquant répond à cette demande, mais sa réponse contient une durée de vie TTL très courte, ce qui empêche la mise en cache de la réponse. Par conséquent, le navigateur pensera qu'il n'est valide que pendant une très courte période de temps avant de devoir quitter et confirmer cela, ce qui signifie en fait interdire la mise en cache.

Il s'avère que dès que l'utilisateur accède au domaine du pirate, le serveur DNS de l'attaquant renvoie d'abord la véritable adresse IP du serveur Web qui a fourni à l'utilisateur du code malveillant. Ce code côté client accède à attacker.com car la stratégie d'origine autorise de telles demandes. L'utilisateur reçoit une réponse, et maintenant le site Web malveillant s'exécute côté client.

Pendant ce temps, l'attaquant va configurer le serveur DNS, qu'il contrôle, pour lier le nom attacker.com et l'adresse IP de victim.com. Cela signifie que si le navigateur de l'utilisateur demande une résolution de nom de domaine pour quelque chose à l'intérieur de attacker.com, il obtiendra en fait une sorte d'adresse interne victim.com.



Pourquoi un attaquant DNS peut-il faire cela? Parce que le pirate informatique le configure pour cela et que le serveur DNS de l'intrus n'a pas besoin de consulter pour se reconnecter à victim.com.

De plus, si notre site veut faire passer un nouvel objet, disons AJAX, il considérera que cette demande AJAX va à attacker.com quelque part à l'extérieur, mais en fait cette demande AJAX va à l'intérieur, à victim.com. C'est mauvais, car nous avons maintenant ce code du côté sur lequel se trouve la page Web attacker.com, qui accède en fait aux données de victim.com avec une source d'origine différente.



En termes simples, lorsqu'un script est exécuté dans le navigateur de la victime en raison de l'obsolescence de la réponse DNS précédente, une nouvelle requête DNS est effectuée pour ce domaine qui, en raison de l'interdiction de la mise en cache, est envoyée au serveur DNS de l'attaquant. Il répond que l'attaquant.com semble maintenant avoir une nouvelle adresse IP d'un autre site Web, et la demande va à un autre serveur. Et puis, pour renvoyer les informations recueillies par le code, l'attaquant fournit son adresse IP correcte dans l'une des requêtes DNS suivantes.

Public: Ne serait-il pas plus sage de faire une attaque contraire, de victim.com pour obtenir tous les cookies de l'attaquant et autres?

Professeur: oui, cette option fonctionnera aussi. Cela vous permettra de faire de bonnes choses comme l'analyse des ports. Je veux dire, votre approche fonctionnera correctement. Parce que vous pouvez, étape par étape, réaffecter constamment attacker.com à différents noms d'ordinateurs et différents ports du réseau victim.com. En d'autres termes, la page Web attacker.com pensera toujours qu'elle va sur attacker.com et reçoit une demande AJAX de là.

En fait, chaque fois que le serveur DNS se reconnecte à attacker.com, il envoie des demandes à une autre adresse IP à l'intérieur du réseau victim.com. De cette façon, il peut simplement «parcourir» les adresses IP une par une et voir si quelqu'un répond à ces demandes.

Public: mais l'utilisateur que vous attaquez n'a pas nécessairement un accès interne au réseau victim.com.

Professeur: en règle générale, cette attaque est qu'il existe certaines règles de pare-feu qui pourraient empêcher le site externe attacker.com de visualiser les adresses IP à l'intérieur du réseau victim.com. Cependant, si vous êtes à l'intérieur d'un réseau d'entreprise tel que corp.net derrière un pare-feu d'entreprise, les ordinateurs ont souvent la possibilité de se connecter à des machines en dehors de leur réseau.

Public: cette méthode d'attaque fonctionne-t-elle via HTTPS?

Professeur: c'est une question intéressante! Le fait est que HTTPS utilise des clés. Si vous utilisez HTTPS, lors de l'envoi d'une demande AJAX, la machine de la victime ne disposera pas des clés HTTPS de l'attaquant et la vérification du chiffrement sur victim.com montrera la non-concordance des clés. Par conséquent, je pense que HTTPS exclut la possibilité de ce type d'attaque.

Public: que se passe-t-il si la victime utilise uniquement HTTPS?

Professeur: Je pense que cela arrêtera l'attaquant.

Public: pourquoi un attaquant répond-il principalement à l'ordinateur de la victime avec son adresse IP?

Professeur: parce que l'attaquant doit en quelque sorte exécuter son propre code sur la machine de la victime avant de pouvoir prendre d'autres mesures pour trouver quelque chose à l'intérieur du réseau de la victime. Mais ne perdons pas de temps, donc, si vous avez des questions sur la réaffectation de DNS, venez me voir après la conférence.

Alors, comment pouvez-vous résoudre ce problème? Une façon de corriger cette vulnérabilité consiste à modifier le résolveur de client DNS afin que les noms d'hôtes externes ne soient jamais autorisés à accéder aux adresses IP internes.

Il est assez stupide qu'une personne extérieure à votre réseau puisse créer un DNS lié à quelque chose à l'intérieur de votre réseau. C'est la solution la plus simple.



Vous pouvez imaginer que le navigateur peut faire quelque chose appelé «épinglage DNS» ou épinglage DNS. Par conséquent, si le navigateur reçoit un enregistrement de DNS résolu, il considérera toujours cet enregistrement comme acceptable, par exemple, pour une interaction dans les 30 minutes, quel que soit le TTL que l'attaquant attribue, et de cette manière peut résister à l'attaque.
Cette solution est un peu compliquée, car il existe des sites qui utilisent intentionnellement le DNS dynamique pour des choses comme l'équilibrage de la charge du serveur, etc. Ainsi, la première solution avec épinglage DNS est la meilleure option.

Et maintenant, nous allons voir ce que la même politique source protège. Et les pixels? Comment la politique d'origine protège-t-elle les pixels?

Il s'est avéré que les pixels n'avaient en fait aucune origine. Ainsi, chaque cadre obtient son propre petit cadre de délimitation, essentiellement juste un carré, et le cadre peut dessiner n'importe où dans cette zone.

Il s'agit en fait d'un problème car cela signifie que le cadre parent peut dessiner sur le cadre enfant. Et cela, à son tour, peut conduire à des attaques très insidieuses.

Supposons qu'un attaquant crée une page qui dit: «Cliquez ici pour gagner un iPad». La même astuce standard. Ceci est le cadre parent.



Et ce cadre parent peut créer un cadre enfant, qui est en fait le cadre du bouton J'aime sur un site Facebook. Ainsi, Facebook vous permet d'exécuter ce petit morceau de code Facebook que vous pouvez mettre sur votre page.

Vous savez que si un utilisateur clique sur «J'aime», cela signifie qu'il ira sur Facebook et dira: «Hé, j'aime cette page en particulier»! Nous avons donc maintenant ce cadre enfant du bouton J'aime.



Désormais, un attaquant peut superposer ce cadre sur la zone de l'écran sur laquelle l'utilisateur doit cliquer pour obtenir un iPad gratuit, et également rendre ce cadre invisible, CSS le permet.

Alors que va-t-il se passer? Comme nous l'avons déjà installé, tout le monde veut obtenir un iPad gratuit. L'utilisateur va se rendre sur ce site en cliquant sur cette zone de l'écran, en étant sûr qu'il clique exactement sur ce que l'iPad gratuit lui donnera. Mais en fait, il clique sur le bouton Like invisible. C'est comme superposer l'index C.

Cela signifie que maintenant, peut-être, l'utilisateur se retrouve sur un profil Facebook, où il note qu'il aimait attacker.com. Vous savez, il ne se souvient même pas comment cela s'est produit. C'est donc en fait ce qu'on appelle une attaque par détournement de clics - prise en charge d'une attaque par clics. De la même manière, vous pouvez faire beaucoup de mauvaises choses - voler des mots de passe, obtenir des données personnelles, bref, c'est fou. Je souligne - cela est possible du fait que le cadre parent est capable de dessiner n'importe quoi dans ce cadre de sélection.

Ainsi, le cadre parent est ce que vous voyez sur la page, l'appel pour obtenir une tablette gratuite, et le cadre enfant est le bouton similaire, qui est superposé de manière transparente sur le cadre parent.

Il existe différentes solutions à ce problème. La première consiste à utiliser le code de contournement de trame. De cette façon, vous pouvez utiliser des expressions JavaScript pour savoir si quelqu'un a incorporé son propre cadre dans votre cadre. Par exemple, l'un de ces tests est une comparaison de la forme suivante: if (self! = Top).

Ici, l'auto-instruction fait référence au haut du cadre supérieur, qui est comparé à la hiérarchie de l'ensemble du cadre. Par conséquent, si vous effectuez ce test et constatez que self n'est pas égal au sommet du cadre parent, vous comprendrez que vous avez un cadre enfant. Dans ce cas, vous pouvez refuser de le télécharger.

Cela se produit si vous essayez de créer un cadre, par exemple, pour CNN.com. Si vous regardez le code source de JavaScript, vous pouvez voir qu'il effectue ce test car CNN.com ne veut pas que d'autres personnes utilisent son contenu. Par conséquent, ce cadre occupe toujours la position la plus élevée. Donc, c'est l'une des solutions qui peuvent être utilisées ici.

La deuxième solution consiste pour votre serveur Web à envoyer un en-tête HTTP appelé options x-Frame en réponse. Par conséquent, lorsque le serveur Web renvoie une réponse, il peut définir cet en-tête, qui indiquera: "Hé, navigateur, ne laissez personne mettre mon contenu dans le cadre!". Cette solution permet au navigateur d'effectuer des actions d'application.

C'est donc assez simple. Mais il y a encore un tas d'autres attaques folles que vous pouvez organiser.

Comme je l'ai mentionné plus tôt, le fait que nous vivons maintenant sur Internet international crée des problèmes d'utilisation d'un domaine ou d'un nom d'hôte.

Supposons que nous ayons la lettre C. Mais dans quelle langue? De quel alphabet vient cette lettre du latin ASCII ou est-ce C en cyrillique? Cela vous permet d'organiser des attaques qui utilisent une interprétation différente et l'utilisation de lettres différentes, mais apparemment similaires. Par exemple, un attaquant enregistrera un nom de domaine cats.com. Et les utilisateurs iront sur ce domaine, pensant qu'ils visiteront le site "cats.com", mais en réalité ils arriveront sur le site de l'attaquant "sats.com", car la première lettre ici n'est pas latine, mais cyrillique.

Un attaquant peut enregistrer le domaine fcebook.com, mais les gens sont inattentifs, ils le prendront comme facebook.com et y iront. Donc, si vous contrôlez Facebook.com, vous obtiendrez une tonne de trafic de personnes qui pensent s'être connectées à Facebook.



Il y a un tas d'attaques farfelues différentes que vous pouvez lancer via le système d'enregistrement de nom de domaine qui sont difficiles à défendre, car comment pouvez-vous empêcher les utilisateurs de faire des fautes de frappe? Ou comment le navigateur indique-t-il à l'utilisateur: "Hé, c'est cyrillique, pas latin"!?

Si le navigateur avertit l'utilisateur à chaque fois que les polices cyrilliques sont activées, il va énerver les personnes qui utilisent réellement le cyrillique comme police native. Il n'est donc pas tout à fait clair comment ces problèmes peuvent être résolus d'un point de vue technique, c'est pourquoi des problèmes de sécurité très sensibles se posent ici.

Les plugins sont une autre chose intéressante. Comment les plugins interagissent-ils avec les politiques d'origine? Les plugins ont souvent une incompatibilité avec le reste du navigateur par rapport à la même source d'origine. Par exemple, si vous regardez le plug-in Java, il suppose que différents noms d'hôte qui ont la même adresse IP ont également la même origine.

En fait, il s'agit d'un écart assez important par rapport à l'interprétation standard des politiques de même origine. Cette approche signifie que si vous avez quelque chose comme xycom et zycom et qu'ils sont projetés sur la même adresse IP, Java supposera qu'ils ont la même source d'origine. Cela peut être un problème, car en réalité, un site a une source d'origine fiable, et l'autre non. Il existe de nombreuses autres difficultés associées aux plugins, que vous pouvez découvrir à partir de sources accessibles au public sur Internet ou à partir des notes de cours.

La dernière chose dont je veux discuter est une attaque de partage d'écran ou une attaque de partage d'écran.

HTML5 définit en fait une nouvelle API par laquelle une page Web peut partager tous ses bits à partager avec un autre navigateur ou serveur. Cela semble être une idée vraiment cool, car elle permet à plusieurs utilisateurs de travailler simultanément sur le même document. C'est super parce que nous vivons dans le futur.

Mais le plus drôle, c'est que lorsqu'ils ont développé cette nouvelle API, ils n'ont pas du tout pensé à une politique de source commune!

Supposons que vous ayez une page sur laquelle plusieurs cadres sont situés, et chacun d'eux a le droit de prendre une capture d'écran de l'ensemble de votre moniteur. Il peut prendre une capture d'écran de tous les cadres situés à l'écran et de tout le contenu, quelles que soient les sources dont ils proviennent.



Donc, en fait, c'est une faille plutôt destructrice dans la politique de la même source d'origine, vous devriez donc envisager de la corriger. Par exemple, si une personne du cadre droit a la possibilité de prendre des captures d'écran, elle sera en mesure de prendre une capture d'écran uniquement du cadre droit, et non de l'écran entier dans son ensemble.

Pourquoi les développeurs de navigateurs ne l'ont-ils pas implémenté de cette façon? Parce qu'ils subissent une pression concurrentielle et sont obligés de concentrer leurs efforts sur le développement de plus en plus de nouvelles fonctions, de nouvelles fonctionnalités, au lieu de prêter attention à l'amélioration de choses déjà développées.

Beaucoup de questions que les étudiants ont posées sur Internet à propos de cette conférence étaient: «pourquoi les développeurs n'ont-ils pas fait ce qu'ils pouvaient faire? N'est-ce pas clair? " ou: «Il semble que ce régime particulier soit mort. L'autre ne serait-il pas meilleur? et ainsi de suite.

Je vais vous dire honnêtement - oui, c'est sûr, presque tout serait mieux si les développeurs prenaient cela de manière responsable. J'ai donc honte d'être connecté à cela.

Mais le fait est que c'est ce que nous avions avant. Si vous regardez tous les éléments qui existaient auparavant, vous verrez que les navigateurs Web se développent et que les gens sont devenus un peu plus préoccupés par la sécurité. Mais pas dans le cas du partage d'écran, où les développeurs étaient tellement inquiets des capacités innovantes du navigateur qu'ils ont complètement oublié la possibilité d'une fuite.



Par conséquent, je vous demande de toujours prêter attention aux choses dont nous avons discuté aujourd'hui. Imaginez que nous partions de zéro, détruisions tout ce qui nous attendait et essayions de trouver une meilleure politique de sécurité, que pensez-vous, combien de sites fonctionneraient pour nous? Je pense que pas plus de 2%. Les utilisateurs se plaindraient donc probablement de nous.

Il existe une autre propriété intéressante liée à la sécurité.Une fois que vous avez donné une fonction aux utilisateurs, il est très difficile de la rappeler, même s'il n'est pas sûr de l'utiliser. Par conséquent, aujourd'hui, nous avons discuté de tant de choses liées à la politique d'origine, et nous continuerons à en parler dans la prochaine conférence.


.

, . ? ? , 30% entry-level , : VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps $20 ? ( RAID1 RAID10, 24 40GB DDR4).

VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps , .

Dell R730xd 2 ? 2 Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 $249 ! . c Dell R730xd 5-2650 v4 9000 ?