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 3Conférence 2: «Contrôle des attaques de pirates»
Partie 1 /
Partie 2 /
Partie 3Conférence 3: «Débordements de tampon: exploits et protection»
Partie 1 /
Partie 2 /
Partie 3Conférence 4: «Séparation des privilèges»
Partie 1 /
Partie 2 /
Partie 3Conférence 5: «D'où viennent les systèmes de sécurité?»
Partie 1 /
Partie 2Conférence 6: «Opportunités»
Partie 1 /
Partie 2 /
Partie 3Conférence 7: «Native Client Sandbox»
Partie 1 /
Partie 2 /
Partie 3Conférence 8: «Modèle de sécurité réseau»
Partie 1 /
Partie 2 /
Partie 3Conférence 9: «Sécurité des applications Web»,
partie 1 /
partie 2 /
partie 3Conférence 10: «Exécution symbolique»
Partie 1 /
Partie 2 /
Partie 3Conférence 11: «Ur / Web Programming Language»
Partie 1 /
Partie 2 /
Partie 3Conférence 12: Sécurité du réseau,
partie 1 /
partie 2 /
partie 3Conférence 13: «Protocoles réseau»,
partie 1 /
partie 2 /
partie 3 Supposons qu'un client émette une demande pour recevoir un message spécifique, par exemple, "donnez-moi le message n ° 7", et cryptez cette chose avec la clé Kc, mail. Tout semble merveilleux.
Le serveur de messagerie possède une clé partagée qui déchiffrera ce message, après quoi le serveur renverra au client le corps de ce message électronique, également chiffré avec Kc, mail. Quelqu'un voit-il cela comme un problème? Pourquoi cela peut-il être mauvais?
Étudiant: il existe une possibilité lorsqu'un pirate peut remplacer un message ou le truquer.
Professeur: oui, c'est troublant car je peux vous envoyer n'importe quel email que je veux. Supposons que j'ai l'intention de supprimer un message qui se trouve dans votre boîte de réception, car je ne veux pas que vous le lisiez. Supposons que cette lettre soit au numéro 23.
Par conséquent, je vais vous envoyer une lettre qui dit: "supprimer le numéro 23", et vous allez le lire. Vous allez le recevoir, et la réponse provenant du serveur de messagerie avec la commande "supprimer n ° 23" sera cryptée avec cette clé Kc, mail. Et jusqu'à présent, il n'a pas été envoyé au serveur de messagerie.
Mais si j'analyse le réseau au bon moment et que je valide ce paquet, je peux le renvoyer au serveur de messagerie. Il ressemblera au message «supprimer le numéro 23», chiffré à l'aide de la clé. Dans ce cas, le serveur de messagerie dira: "Oh oui, bien sûr, vous voulez supprimer ce message, et je le ferai!"
Il y a donc un problème ici parce que nous permettons à l'adversaire de confondre le serveur de messagerie pour savoir si notre message a été généré par lui ou envoyé en premier lieu.
C'est ce qui est communément appelé dans la description de la cryptographie et du protocole une «attaque par réflexion». Avez-vous des suggestions sur la façon d'éviter ce problème?
Étudiant: est- il possible d'inclure simplement un en-tête de message qui parle de son origine?
Professeur: oui, en règle générale, vous voulez avoir une sorte de façon non ambiguë de dire ce qui se passe. Une façon consiste à avoir un en-tête dans chaque message qui dit: «du client au serveur» ou «du serveur au client». Une manière encore meilleure dans la pratique consiste simplement à utiliser deux clés distinctes.
Parce que vous voudrez peut-être avoir un long flux de données qui pourrait ne pas avoir de place pour les bits d'en-tête. Ainsi, chaque fois que vous établissez une connexion avec un service, Kerberos 5 négocie l'utilisation de deux clés au lieu d'une. La première clé sera utilisée pour crypter les données du client vers le serveur, et la seconde pour crypter les données du serveur vers le client. Il s'agit de la méthode de protection la plus optimale pour une utilisation pratique.
Parlons maintenant de ce qui se passe avec KDC. Le serveur Kerberos est très important pour le système, mais que se passe-t-il si ce KDC se bloque? À quel point est-ce mauvais pour notre système? Comment la «chute» de KDC affectera-t-elle votre vie si vous utilisez Athena?
Étudiant: vous ne pouvez probablement pas vous connecter?
Professeur: oui, ça l'est. Deuxièmement, vous ne pourrez pas non plus obtenir de billets pour de nouvelles demandes. Mais ce qui est cool, c'est que KDC est à peu près hors du chemin critique pour une connexion existante. Par conséquent, aucune donnée ne passe par le KDC. Et si vous avez déjà un ticket pour quelque chose, vous pouvez continuer à l'utiliser et garder l'entrée de certains services du réseau. C'est en fait assez bien mis en cache. Je pense que la deuxième bonne chose que les développeurs ont envisagée est la possibilité de répliquer KDC. Par conséquent, le système possède un serveur Kerberos principal, qui stocke la copie initiale de la base de données entière. Cela vous permet de lire uniquement les réplicas qui contiennent une copie de la base de données initiale. Il n'autorise aucune mise à jour, comme l'enregistrement des utilisateurs ou les mises à jour de clés, mais vous permet de répondre aux demandes de connexion et de TGS.
Ainsi, l'enregistrement «clone» de la base de données Kerberos vous permet de continuer à vous connecter et à communiquer avec les services, même si KDC échoue, jusqu'à ce qu'il soit éliminé et que toutes ses fonctionnalités soient restaurées.
Étudiant: est-il difficile de compromettre le serveur KDC et le système dans son ensemble?
Professeur: KDC est l'épine dorsale de tout système qui exécute Kerberos. Si ce service est compromis, l'attaquant aura un contrôle total sur le système. Il sera en mesure d'obtenir des billets pour n'importe quel service que vous souhaitez, en faisant semblant d'être le bon client, donc c'est assez mauvais. Nous voulons vraiment garder KDC en sécurité, mais c'est difficile. Bien que je ne connaisse pas un seul cas où le KDC MIT aurait été vraiment compromis pendant environ 20 ans. Mais, apparemment, ce qui vaut vraiment la peine d'être inquiété, c'est l'implémentation logicielle de la sécurité des choses que ces deux services échangent, Kerberos et TGS. Parce que si un débordement de tampon se produit ou si une autre vulnérabilité similaire survient, c'est vraiment mauvais.

Par exemple, si un serveur SSH s'exécute sur KDC Kerberos et que quelqu'un devine le mot de passe racine de ce serveur SSH, il se connectera simplement et copiera la base de données. Je pense donc que vous voulez vraiment minimiser la surface d'attaque ici, alors soyez très prudent lorsque vous écrivez du code KDC. Ne laissez personne accéder directement à ce service. Bien sûr, il existe certains endroits pour lesquels vous devriez être considéré comme paranoïaque à propos de la sécurité, mais ce n'est pas si important pour les serveurs. Bien sûr, ils stockent des données, mais si quelqu'un s'introduit dans un serveur de messagerie ou un serveur d'impression, ils peuvent être restaurés.
Voici une question intéressante. Supposons que quelqu'un pirate un serveur de messagerie. Que devez-vous faire pour vous remettre de cette attaque? Par exemple, si quelqu'un a volé votre courrier, c'est mauvais. Mais que faire pour empêcher un attaquant d'accéder à votre messagerie à l'avenir?
Kerberos n'a pas d'opération d'annulation, mais vous pouvez générer une nouvelle clé pour le serveur de messagerie et la coller dans la base de données KDC. Ensuite, vous installez un nouveau serveur de messagerie, lui donnez une nouvelle clé, puis un attaquant qui possède une ancienne clé du serveur de messagerie ne peut en aucun cas l'influencer.
Par contre, supposons que vous ne modifiez pas la clé du serveur de messagerie, Kmail. À quoi cela mènera-t-il?
Étudiant: la clé ne s'adaptera pas au nouveau serveur.
Professeur: eh bien, supposons que vous installiez un nouveau serveur de messagerie, corrigeant l'erreur utilisée par le pirate. Mais il a toujours une clé Kmail. La récupération du serveur a peut-être duré une journée entière, de sorte que tous les tickets ont expiré. Ce pirate peut-il faire quelque chose d'intéressant avec le système? Si vous fournissez l'ancien Kmail au nouveau serveur de messagerie - est-ce mauvais?
Étudiant: un attaquant peut infiltrer un serveur de messagerie car il peut décrypter le premier ticket.
Professeur: c'est certain, c'est pourquoi Kmail est en fait très important. Vous dites que vous pouvez décrypter tout ce qui se passe sur le serveur de messagerie. Supposons que le client se connecte au serveur de messagerie après l'avoir corrigé, mais l'attaquant connaît toujours Kmail, qui est resté depuis le dernier piratage du système. Par conséquent, il peut décrypter ce ticket Kmail, regarder à l'intérieur du ticket et obtenir une clé de session. Avec lui, il pourra décrypter tous les messages que vous envoyez, toutes les réponses que vous recevez, etc. Par conséquent, après avoir restauré le serveur de messagerie, il est très important de modifier ce Kmail.
À bien des égards, cela est encore pire que le simple suivi du trafic, car si un attaquant connaît cette clé Kmail, il peut synthétiser de nouveaux tickets pour le serveur de messagerie sans contacter KDC. Supposons que je connaisse Kmail et que je veuille lire le courrier d'un serveur de messagerie. Je vais simplement émettre ce ticket, je vais collecter tous ces cinq champs dans le bon ordre, générer une nouvelle clé et la crypter en utilisant Kmail. Cela ressemblera à la vraie chose générée par KDC.
Par conséquent, je me connecte simplement au serveur de messagerie, il déchiffrera correctement le message et pensera qu'il s'agit d'un utilisateur spécifique, afin que vous puissiez lui fournir du courrier, partager une clé partagée avec lui, etc. Par conséquent, il est essentiel que personne ne reconnaisse la clé secrète de ce service, car sinon vous pouvez non seulement rendre le trafic déchiffrable et visible, mais aussi imiter n'importe qui dans ce service.
Etudiant: si le serveur de messagerie est restauré après un échec, vous devrez probablement changer sa clé dans la base de données?
Professeur: oui, après avoir restauré le serveur de messagerie après l'échec, vous devez appeler le gars qui travaille avec ce KDC et dire: "notre serveur de messagerie a été piraté, alors supprimez son ancienne clé Ks de la base de données et insérez-en une nouvelle!" Vous voudrez donc probablement avoir une sorte de mécanisme en dehors de la base de données pour prouver que vous êtes vraiment un serveur de messagerie.
Parce que nous verrons dans une seconde comment changer les clés, par exemple, en utilisant le protocole de changement de mot de passe. Vous pouvez utiliser des mots de passe dans le protocole Kerberos, car si vous connaissez l'ancien mot de passe, vous pouvez remplacer le mot de passe utilisateur par le nouveau mot de passe dans KDC. Mais comme le pirate peut intercepter le mot de passe envoyé par courrier, vous devrez probablement contacter le bureau d'enregistrement du compte et lui demander de changer votre mot de passe sur le serveur de messagerie. Ils vont générer une nouvelle clé et vous la donner afin que le pirate ne puisse pas la reconnaître.

Sinon, si l'attaquant connaît cette clé Kmail, le serveur de messagerie n'a rien pour distinguer l'attaquant du bon client. En réalité, l'attaquant a probablement changé la clé, alors maintenant ils connaissent les nouveaux paramètres, et vous n'y êtes pas, comme si vous n'étiez plus sur le serveur de messagerie. Vous avez donc besoin de protocoles externes pour les principes de l'enregistrement initial dans la base de données et pour changer les clés si vous avez oublié votre mot de passe ou si quelqu'un a changé votre mot de passe afin que vous perdiez l'accès.
Par conséquent, il y a un groupe de personnes au MIT qui aident les utilisateurs à enregistrer des comptes et à changer leurs mots de passe. Pour ce faire, vous leur présentez votre ID MIT, et quoi qu'il arrive, ils pourront changer la clé pour vous.
Par conséquent, il est très important de bien faire les choses. Parce que si la personne qui vous permet de réinitialiser le mot de passe se trompe lors de la vérification de votre ID MIT, vous pouvez compromettre le système, non? Ces personnes de Kerberos font donc partie d'une base informatique de confiance.
Regardons une autre utilisation intéressante de Kerberos. Vous pouvez utiliser Kerberos pour vous connecter à un ordinateur distant via SSH. Et son fonctionnement est très similaire à celui d'un serveur de messagerie. Vous obtenez un ticket pour le serveur SSH et vous envoyez le ticket avec votre connexion SSH. Mais que se passe-t-il si vous vous connectez à Athena.dial-up et que vous n'avez pas de client Kerberos sur votre ordinateur? Vous voulez juste vous connecter à Athena.dial-up avec votre mot de passe habituel.
Alors, comment la connexion par modem Athena vous authentifie-t-elle si vous vous connectez à cette machine avec un mot de passe? Vous n'avez pas de mot de passe pour Athena.dial-up, c'est un mot de passe pour le serveur Kerberos. Alors, que doit faire un ordinateur commuté si vous vous connectez avec un mot de passe?
La connexion à distance fonctionne en utilisant le même protocole que la connexion. Il va donc envoyer une demande du client au serveur Kerberos avec une demande de donner un ticket, par exemple, au nom d'utilisateur «Alice». Et en retour, le client recevra une réponse chiffrée avec le mot de passe d'Alice. Ensuite, il essaiera d'appliquer le mot de passe et verra s'il déchiffre correctement. S'il déchiffre correctement, vous pouvez vous connecter au système.
Etudiant: vous n'avez même pas besoin d'envoyer votre clé au serveur SSH, car dans cette connexion, le serveur KDS peut renvoyer l'utilisateur Kc via la connexion SSH.
Professeur: il est possible que oui, mais cela nécessite une certaine imagination du client SSH, ce qui peut ne pas être le cas. Mais en principe, c'est vrai. Si vous souhaitez le faire correctement, vous souhaiterez probablement avoir un client Kerberos sur votre ordinateur et obtenir un ticket vous-même, ou peut-être utiliser un serveur SSH pour le transfert, tout en ne permettant pas au serveur SSH d'avoir votre clé.
C'est probablement un bon plan. Mais il s'avère qu'en fait, c'est une chose assez dangereuse qui permet à quiconque de se connecter au serveur SSH. Plus tôt, nous avons parlé d'un client essayant de se connecter. Ce client savait qu'en fournissant un mot de passe légal, il a reçu une réponse du bon serveur Kerberos, et s'il peut décrypter la réponse, alors le mot de passe fonctionne probablement correctement.
Cependant, il n'y a rien dans ce protocole qui confirme le fait que cette réponse provient du serveur Kerberos correct. Par conséquent, si j'essaie de me connecter à la machine simplement en entrant un mot de passe, la machine enverra cette demande au serveur. Ensuite, la réponse sera renvoyée à cette demande, qui semble être chiffrée avec le mot de passe que j'ai entré, mais cette réponse peut ne pas provenir du serveur Kerberos non plus.
Supposons que j'ai une machine avec laquelle je souhaite me connecter. J'entre le mot de passe X, puis la machine envoie cette demande de, s au serveur Kerberos.

Mais avant que le serveur Kerberos n'envoie la vraie réponse au client, j'enverrai ma propre réponse, qui ressemble à la vraie réponse, chiffrée avec mon mot de passe X. Ensuite, le poste de travail auquel j'essaie de me connecter ou le serveur SSH essaiera de déchiffrer cette réponse avec mon faux mot de passe. Cela semblera bien, car cette réponse a été générée par moi au lieu du vrai serveur Kerberos. Par conséquent, je peux me connecter à votre place. Pourquoi cela se produit-il?
Étudiant: car il n'y a pas d'authentification à partir du serveur Kerberos.
Professeur: oui, il n'y a rien ici qui lierait cela à un vrai serveur Kerberos. La façon dont Kerberos corrige cet inconvénient pour les ordinateurs distants, comme Athena.dial-up, est que les ordinateurs commutés eux-mêmes ont une sorte de clé secrète qu'ils partagent avec KDC. Par conséquent, afin d'entrer dans la ligne commutée ou sur n'importe quel poste de travail qui se soucie vraiment de vérifier si vous êtes vraiment le bon utilisateur, deux choses sont faites.
La première connexion à Kerberos se produit comme indiqué dans le diagramme. Mais il ne fera confiance à personne simplement parce que cette réponse est déchiffrée correctement. Il essaiera d'obtenir un ticket de service pour lui-même en utilisant TGS, car cet ordinateur d'accès à distance possède sa propre clé secrète. À la première étape, il vous enregistre simplement, puis se tourne vers TGS, en disant: "donnez-moi s'il vous plaît un ticket de service selon mon propre principe, sur la base d'un accès commuté, pour ce client."
Il reçoit ensuite une réponse et vérifie s'il peut la déchiffrer correctement, car il connaît la clé d'accès à distance pour ce Ks. Et s'il déchiffre, cela signifie que l'ordinateur parlait au bon serveur Kerberos. Parce que seul le bon serveur Kerberos dans la deuxième étape peut m'envoyer un ticket chiffré avec ma clé secrète Kdial-up.
C'est donc très important. En règle générale, les postes de travail Athena n'effectuent pas cette étape supplémentaire car les postes de travail Athena n'ont pas de clé secrète qui y est stockée et partagée avec KDC. Pourquoi est-il considéré normal que les postes de travail Athena vous donnent la possibilité de vous connecter à la première étape, mais pas de donner une telle possibilité de connexion à distance?
Étudiant: c'est normal si vous n'avez accès à aucun service car l'attaquant n'a pas pu truquer un ticket.
Professeur: oui, c'est vrai, car il n'y a rien d'intéressant dans la station de travail d'accès à distance elle-même. Même si vous avez un accès root, ou si vous entrez dans un poste de travail avec un faux mot de passe, cela ne dérange personne. Ce n'est pas comme s'ils pouvaient faire autre chose en dehors de leur poste de travail. Au modem, tout est beaucoup plus intéressant. Peut-être que vous avez d'autres processus en cours d'exécution à partir d'autres sessions sur la station de travail d'accès à distance, et le fait que vous êtes connecté avec un UID spécifique à Unix, et qu'ils veulent vraiment vous assurer que vous êtes la bonne entité, sont importants là-bas. . C'est pourquoi ils font un tel processus en deux étapes pour entrer dans la machine, qui est simultanément utilisée par plusieurs utilisateurs.
La dernière chose dont je veux parler est de savoir comment remplacer les clés. Nous avons avancé l'idée que vous pouvez compromettre la clé du serveur de messagerie. Mais en tant qu'utilisateur, vous voudrez probablement aussi changer le mot de passe. Par exemple, vous pensiez que votre mot de passe n'était pas suffisamment sécurisé, vous l'avez écrit sur un morceau de papier, et quelqu'un pourrait l'avoir espionné, alors maintenant vous voulez le changer.
Dans un sens, c'est assez simple. En plus des services Kerberos et TGS, l'interface du serveur Kerberos dispose d'un service supplémentaire appelé Kpassword, qui vous permet de modifier votre mot de passe.

Vous obtenez un ticket pour utiliser ce service comme un ticket pour un serveur de messagerie ou tout autre serveur. Après cela, vous envoyez votre nouveau mot de passe à ce service Kpassword, crypté avec votre clé de session. Et puis, si toutes les vérifications réussissent, votre clé dans la base de données sera mise à jour avec une nouvelle clé.
Si vous vous souvenez, nous avions un objectif - si quelqu'un vole votre billet, il ne devrait pas être assez bon pour donner la possibilité de saisir complètement votre compte. Pour cette raison, le service Kpassword n'accepte aucun ticket, mais uniquement le ticket que vous recevez initialement du service Kerberos avec votre clé Kc. : , , , , – Kerberos TGS – . : Kerberos, , TGS, .
Kpassword, , , : «, Kerberos, . TGS, , , , - , . ».
, Kpassword , , , Kerberos. , Kpassword , Kerberos Kpassword.
Kpassword, - . , , Kerberos. Kerberos, ID , Kpassword.

Kerberos , Kpassword, Kpass, Kc,kpass Kpassword, Kc.
, – Kpassword, Tc,kpass, Kpass, , new pass Kc,pass, .
, , , , . - Athena, , , , . , , Gmail, , . , Kerberos TGS , - , .
, - Athena , , , . , . , . Tc,kpass, Kpassword, TGS, . , Kerberos Kc.
: , ?
: K . Kerberos , . , K. - K, .
: , ?
: , - , , . .
, , , , , , .
: , , .
: , , . , , Kerberos , , . , . . , , .
: K, ?
: , K – 56- DES, , , 56 , , 7 , . .
, , . , , , , . Kerberos?
: …
: , , , , , , . ?
: .
: , .
: - , , , , …
: , , Kerberos , , , . . , , , «» - , ! : „, Kc,pass, K. Kc,pass , Kpassword». , , KDC. , .
, , - , - . .
: , Kerberos ?
: , . « -», , , . , .
, Kerberos 5. , , , . , . , X, Kpassword - Y. , , . , g X , g Y.

gy X, gxy, gx Y gxy. gxy , . , , gxy. , , - gxy, . , .
: - G.
: , . G — , Kerberos, . , -, Kerberos 5 . , - . , , Kerberos, SSL.
.
Merci de rester avec nous. ? Vous voulez voir des matériaux plus intéressants? Soutenez-nous en passant une commande ou en le recommandant à vos amis, une
réduction de 30% pour les utilisateurs Habr sur un analogue unique de serveurs d'entrée de gamme que nous avons inventés pour vous: Toute la vérité sur VPS (KVM) E5-2650 v4 (6 cœurs) 10 Go DDR4 240 Go SSD 1 Gbps à partir de 20 $ ou comment diviser le serveur? (les options sont disponibles avec RAID1 et RAID10, jusqu'à 24 cœurs et jusqu'à 40 Go de DDR4).
VPS (KVM) E5-2650 v4 (6 cœurs) 10 Go DDR4 240 Go SSD 1 Gbit / s jusqu'en décembre gratuitement en payant pour une période de six mois, vous pouvez commander
ici .
Dell R730xd 2 ? Nous avons seulement
2 x Intel Dodeca-Core Xeon E5-2650v4 128 Go DDR4 6x480 Go SSD 1 Gbps 100 TV à partir de 249 $ aux Pays-Bas et aux États-Unis! Pour en savoir plus sur la
création d'un bâtiment d'infrastructure. classe utilisant des serveurs Dell R730xd E5-2650 v4 coûtant 9 000 euros pour un sou?