Curso MIT "Segurança de sistemas de computadores". Aula 13: Protocolos de Rede, Parte 2

Instituto de Tecnologia de Massachusetts. Curso de Aula nº 6.858. "Segurança de sistemas de computador". Nikolai Zeldovich, James Mickens. 2014 ano

Computer Systems Security é um curso sobre o desenvolvimento e implementação de sistemas de computador seguros. As palestras abrangem modelos de ameaças, ataques que comprometem a segurança e técnicas de segurança baseadas em trabalhos científicos recentes. Os tópicos incluem segurança do sistema operacional (SO), recursos, gerenciamento de fluxo de informações, segurança de idiomas, protocolos de rede, segurança de hardware e segurança de aplicativos da web.

Palestra 1: “Introdução: modelos de ameaças” Parte 1 / Parte 2 / Parte 3
Palestra 2: “Controle de ataques de hackers” Parte 1 / Parte 2 / Parte 3
Aula 3: “Estouros de Buffer: Explorações e Proteção” Parte 1 / Parte 2 / Parte 3
Palestra 4: “Separação de Privilégios” Parte 1 / Parte 2 / Parte 3
Palestra 5: “De onde vêm os sistemas de segurança?” Parte 1 / Parte 2
Palestra 6: “Oportunidades” Parte 1 / Parte 2 / Parte 3
Palestra 7: “Sandbox do Cliente Nativo” Parte 1 / Parte 2 / Parte 3
Aula 8: “Modelo de Segurança de Rede” Parte 1 / Parte 2 / Parte 3
Aula 9: “Segurança de aplicativos da Web” Parte 1 / Parte 2 / Parte 3
Palestra 10: “Execução Simbólica” Parte 1 / Parte 2 / Parte 3
Aula 11: “Linguagem de Programação Ur / Web” Parte 1 / Parte 2 / Parte 3
Aula 12: Segurança de rede Parte 1 / Parte 2 / Parte 3
Aula 13: “Protocolos de Rede” Parte 1 / Parte 2 / Parte 3

Aluno: o cliente não pode descriptografar esse ticket porque ele é criptografado usando a chave de serviço.

Professor: sim, isso é realmente inteligente, não é? Temos a chave Kc, s que o cliente pode receber, mas aqui, no ticket Tc, s, há outra cópia dessa chave, criptografada com Ks.



O motivo disso é que o servidor Kerberos está realmente tentando proteger a comunicação do cliente com o outro cara. Portanto, o Kerberos cria uma chave aleatória Kc, se fornece uma cópia para o cliente e outra para o servidor com o qual o cliente irá conversar. Imagine que o Kerberos simplesmente chamasse o serviço com as palavras: “ei, serviço, esse cara quer falar com você, esta é a chave para isso!” Isso seria lamentável, porque o servidor Kerberos acessaria o serviço repetidamente em todas as solicitações. Portanto, o KDS cria duas cópias da chave da sessão: uma para o cliente e outra para o TGS.

Portanto, em vez disso, os desenvolvedores criaram um bom truque, onde eles fornecem esse ticket ao cliente, e ele não pode fazer nada com ele, exceto entrar em contato com o serviço certo. E se este serviço tiver a chave Ks correta, ele será descriptografado e dirá: "Sim, é a mesma chave que devo usar para conversar com esse cliente". Assim, os dois participantes da conexão, o cliente e o serviço, estabelecerão uma chave comum para proteger sua conexão.

Estudante: então o que é TGS?

Professor: Existem duas visões sobre o que é TGS. Do ponto de vista do cliente, este é apenas mais um serviço para o qual você pode obter um ticket. Quanto mais recursos esse serviço fornece, mais tickets ele oferece. Este é realmente um serviço de bilheteria.

Aluno: desculpe, eu quis dizer que temos um ingresso chamado TGS.

Professor: ah, sim, desculpe, a inscrição tgs sob a seta neste diagrama é apenas uma abreviação para todo o bloco de gravação, exceto os índices s no parâmetro Tc, s, que significa que o nome real desse serviço é TGS. Você pode imaginar que temos um servidor Kerberos, existe esse serviço TGS e existe um serviço real que você deseja acessar. Então, primeiro você precisa solicitar ao Kerberos um ticket para obter acesso a um serviço específico.



Você pode solicitar ao Kerberos que lhe forneça um ticket diretamente para o servidor de arquivos, e isso pode funcionar. Mas para isso, você precisaria do seu Kc para descriptografia e pelo resto do tempo usando o servidor. Em vez disso, você recebe um ingresso para o serviço TGS especial. Parece o mesmo que outros serviços, exceto que é colocado em uma caixa separada. E ele ficará feliz em fornecer a você mais ingressos posteriormente, sem fornecer novamente sua chave de cliente Kc original.

Aluno: ou seja, a ideia dele é que, assim que você receber um bilhete TGS, você possa se livrar da sua chave Kc?

Professor: sim, o mais interessante é que, assim que você recebe este bilhete Tc, s do serviço TGS, você se livra da senha e da chave Kc. Assim, assim que você efetua login na estação de trabalho do Athena e após alguns segundos recebe um ticket T, s, sua senha é excluída da memória. Portanto, mesmo que alguém o agarre, selecione o computador e saia com ele, tudo o que ele tem é o seu bilhete. É bom que ele possa acessar suas informações por 10 horas ou pela duração do ticket, mas não mais, porque a senha não foi salva e na próxima vez que você digitar "Athena", será necessário digitá-las novamente.

A única vez em que você precisa de uma senha é quando envia uma solicitação ao servidor Kerberos, recebe essa resposta com um ticket e descriptografa-a. Depois disso, você pode esquecer a senha. Mas é claro que você não pode soltar a senha antes de usá-la para descriptografar.
Assim, a primeira interface superior C em nosso esquema é usada para obter um ticket com a chave inicial Kc, e a segunda interface inferior S é usada para acessar serviços, mas sem a necessidade de obter a chave inicial Kc.



Portanto, já falamos sobre dois problemas específicos do protocolo Kerberos, que foram incorporados a ele, o que causou alguns inconvenientes. Primeiro, os criadores assumiram que a criptografia também forneceria autenticação ou integridade da mensagem, mas isso não aconteceu. Essa falha foi corrigida no Kerberos versão 5, onde a autenticação explícita de mensagens é realizada. Em segundo lugar, para clientes arbitrários, eles tiveram a oportunidade de adivinhar as senhas de outras pessoas.

Como isso pode ser corrigido? Como evitar ataques adivinhando a senha em protocolos desse tipo? O que podemos tentar?

Aluno: Não tenho certeza, mas você pode tentar "salgar" a senha.

Professor: “salgar” significa simplesmente que o cliente pode ter que hash a senha de maneiras diferentes. Mas isso não custa tentar pegá-lo. Portanto, pode ser mais caro construir um dicionário.

Aluno: você pode tentar complicar a função de calcular a senha.

Professor: sim, outra boa idéia é tornar o processo de hash muito caro. Talvez isso seja razoável. Portanto, se essa função hash demorar um segundo no tempo computacional, como vocês fizeram no segundo laboratório, nesse caso, selecionar senhas seria uma tarefa muito cara. Portanto, este parece ser um plano razoável - usar uma combinação de “salga” e complicar o processo de adivinhação.

Outra defesa pode ser complicar a resposta. Você ouviu dizer que, nas primeiras versões do protocolo, o servidor Kerberos não fazia ideia se o cliente correto estava acessando ou não. O que você poderia fazer é fornecer evidências de que você é o cliente certo, ou seja, criptografar o carimbo de data / hora atual com um hash de senha ou algo assim. Em seguida, o servidor Kerberos pode apenas verificar se essas coisas estão corretas e, se elas corresponderem, fornecer um ticket.

Você provavelmente não deseja adicionar mais etapas de teste, mas isso pode funcionar. Por enquanto, suponha que você possa pegar um carimbo de data e hora e hash junto com a tecla Kc, além de adicionar um carimbo de data e hora.



Nesse caso, o servidor pode ver que possui sua chave Kc e também pode fazer o hash do carimbo de data / hora atual. Se ele receber o mesmo valor, provavelmente a solicitação será feita pelo usuário correto para quem o ticket pode ser enviado. Caso contrário, era a senha errada.

Aluno: você pode simplesmente limitar a emissão de tickets se os servidores registrarem muitos pedidos de provisão.

Professor: muito bem, podemos introduzir uma restrição. No entanto, não há razão para um hacker solicitar um ticket no servidor mais de uma vez. Ele simplesmente pede um usuário específico, recebe esse bloco criptografado dele e pode tentar descriptografá-lo offline quantas vezes quiser, com senhas diferentes sem uma segunda solicitação. Portanto, acho que o ponto principal da proteção é que o servidor reaja de alguma forma ao número de chamadas se o invasor solicitar repetidamente o servidor, tentando entrar no sistema com senhas diferentes. Nesse caso, o limite de consulta pode ser atingido, o que fornecerá melhor proteção contra hackers.

Aluno: como um invasor pode enviar uma solicitação ao servidor Kerberos?

Professor: Eu acho que ele poderia reproduzir a mensagem do usuário correto, ou seja, vê-la, copiá-la, enviá-la e também receber uma resposta do servidor Kerberos. Se um hacker verifica a rede, ele pode interceptar a mensagem durante a transmissão. Portanto, limitar o número de solicitações é uma medida temporária que aumenta apenas ligeiramente a segurança. Mas, é claro, se você estiver olhando para a rede de outra pessoa, verá como esse pacote é retornado do servidor, independentemente do que aconteceu no estágio de formação de Tc, s. Assim, o hacker pode ver a resposta do servidor ao cliente e tentar atacá-lo.

Provavelmente existem esquemas mais complexos que você poderia desenvolver, mas não acho que o Kerberos 5 implemente algo mais complicado do que o plano que analisamos, o que parece bom o suficiente para impedir que pessoas aleatórias tentem quebrar algo ou usar brutalidade. forçar a decifrar uma senha.

Aluno: suponha que você possa fornecer autenticação ou outra coisa para estabelecer uma chave compartilhada. E então você pode criptografar essa coisa e a chave compartilhada com o Kc.

Professor: sim, é. Se você realmente fizer isso corretamente, existe um protocolo chamado Exchange Authenticated Key Exchange, PAKE, que executa a autenticação por senha. É exatamente o que acontece no Kerberos.



Você pode olhar para o Google para que servem os protocolos SRP ou PAKE. Esses protocolos e seus elementos associados se saem muito melhor com sua tarefa, na qual você deve provar a ambas as partes que instalou uma nova chave. Nesse caso, as duas partes devem estar convencidas da exatidão uma da outra e de que não há como adivinhar essa senha offline e atacar o conjunto de pacotes de rede que você está observando, e assim por diante.

Estes são protocolos que dependem muito da criptografia, por isso é difícil explicar no quadro por que eles funcionam.

Aluno: Uma das razões pelas quais os desenvolvedores fizeram isso foi porque eles queriam oferecer suporte à capacidade de enviar apenas uma senha. E os protocolos permitem enviar apenas uma coisa como autenticador.

Professor: sim, existem muitos requisitos estranhos que esses caras levaram em conta. Obviamente, na prática, esses servidores podem aceitar conexões Kerberos e não-Kerberos. E para conexões não-Kerberos, você obtém a imagem como se alguém estivesse se conectando a um servidor de correio, mas não usando uma estação de trabalho Athena. Ele só quer enviar sua senha.



E então o cliente de email aqui, digamos, vai pegar essa senha e obter um ticket em seu nome apenas para verificá-la, o que permitirá que você use esse cliente de email. Portanto, você provavelmente ainda deseja que o próprio Kerberos verifique as senhas do Kerberos. Eu não acho que isso esteja fora de questão, porque é claro que o Kerberos 5 implementa esses hashes de carimbo de data e hora e tudo mais.

Acho que mais uma coisa que você deve prestar atenção nos materiais das palestras é que os desenvolvedores do Kerberos 4 escolheram um esquema de criptografia - DES, o algoritmo de criptografia mais popular da época. Esta é uma cifra de bloco simétrica, bem rápida. Naquele momento, ele fornecia segurança suficiente e eles simplesmente o incorporaram ao protocolo.

Tudo no Kerberos deveria usar apenas DES, ou pelo menos tudo na versão 4. do Kerberos. Isso se tornou problemático, porque agora, 25 a 30 anos depois, a criptografia do DES pode ser facilmente quebrada usando o método de força bruta, uma vez que as chaves de criptografia têm tamanho muito pequeno - apenas 56 bits.

Portanto, você pode simplesmente criar algum tipo de equipamento de usuário que calculará de 2 a 56 graus de combinação e descobrirá a senha real. É isso que você deseja evitar em qualquer protocolo desenvolvido atualmente.

O Kerberos versão 5 suporta vários esquemas de criptografia diferentes, incluindo AES e outros algoritmos criptográficos. Portanto, essa parece ser uma maneira muito melhor de garantir a segurança. Por outro lado, o MIT continuou a apoiar o DES há dois anos, mas agora o recusou, então hoje seu reitor está protegido, pelo menos contra esse tipo de ataque. Agora, vamos ver o que acontece no serviço TGS do qual você recebe um ticket. A interação com este serviço parece um pouco diferente.

Por um lado, como cliente, você conversará com ele como se estivesse conversando com qualquer outro serviço habilitado para Kerberos. Considere como você executa sua própria autenticação com um ticket para uma máquina. Mas a resposta que você retornará é apenas um tíquete para outro princípio, com base no qual você se comunicará, por exemplo, com um servidor de arquivos.

Portanto, as mensagens no nível do protocolo ficarão assim - à direita, desenharei o TGS e à esquerda - o cliente. O cliente já possui um ticket para o TGS, obtido usando o protocolo mostrado na parte superior.



Agora, o cliente enviará uma combinação de mensagens que provam que ele é o cliente certo, e essas mensagens estão relacionadas à emissão de uma solicitação em um princípio específico por meio do TGS.

Portanto, o cliente enviará a seguinte mensagem para o TGS: S é o serviço com o qual ele se comunicará mais, pode ser um servidor de correio ou de arquivos; isso inclui o ticket do cliente Tc que ele recebeu para tgs, criptografado usando a chave K tgs e um autenticador criptografado com a chave Kc, tgs comum ao cliente e ao serviço TGS. É assim que a mensagem que você vai enviar para o TGS se parece - ela diz: “olhe para esta mensagem, faça algo com ela e responda com um ticket para este novo serviço S.” A resposta aqui parece quase a mesma da figura acima e, de fato, é a mesma - esse é um ticket entre o cliente e esse novo serviço, criptografado usando Ks. Mas agora ficou um pouco diferente.



Em vez de criptografar com a chave Kc, que o cliente deve ter esquecido desde então, agora a criptografia é realizada usando a chave comum Kc, tgs entre o cliente e o serviço TGS.

Como o servidor descobre o que o cliente deseja e como o autentica? O servidor TGS conhece sua própria chave Ktgs; portanto, primeiro ele descriptografa essa mensagem Tc, tgs, olha dentro do ticket e descobre o que acontece. Por que precisamos de todos esses campos no ticket? Por que é importante ter o nome do servidor S no ticket? O que daria errado se não tivéssemos S?

Aluno: se não houver, você poderá obter permissão para usar qualquer servidor.

Professor: sim, é. Em geral, é uma boa idéia criar os protocolos de rede para que você possa dizer exatamente o que essa mensagem significa. No caso de você omitir S, você pode confiar no fato de que, se usar um ticket para o S errado, talvez tenha outra chave Ks e ela não será capaz de descriptografar ou algo assim. Portanto, parece uma boa ideia incluir o nome do serviço para garantir que o servidor que recebe esses tickets os descriptografa e verifique se esse é um ticket para mim ou para outra pessoa?

Aluno: o que o cliente faz com a chave Ktgs recebida?

Professor: boa pergunta! O cliente não tem idéia do que é. Porque é uma chave extremamente secreta. Se você soubesse, seria capaz de decifrar todo o Kerberos. Portanto, o cliente não tem idéia do que é Ktgs.

Estudante: de onde vem esse Ktgs?

Professor: o próprio servidor Kerberos gera para você toda essa mensagem, que já possui Tc, tgs e Ktgs, você não a cria, mas simplesmente copia-a daqui.

Então, por que o nome do cliente é tão importante? É fácil descobrir isso. Se você não colocar o nome do cliente no ticket, o servidor receberá essa mensagem, mas não fará ideia de quem ele está tentando conversar. Ele não sabe para quem deve emitir um ingresso - para você ou para outra pessoa.

E os outros campos? Por que os desenvolvedores inserem o endereço addr no ticket Tc, s? É apenas o endereço IP do cliente. Por que não usá-lo diretamente?



Penso que o significado desta solução é o desejo dos desenvolvedores de aumentar a segurança. Eles queriam garantir que, se o cliente efetuasse login a partir de algum endereço IP, tudo o mais no mesmo ticket venha do mesmo endereço IP. Por exemplo, se você estiver conectado a partir de algum endereço IP, por exemplo 18.26.4.9, cada conexão com um servidor de arquivos ou correio deverá ser do mesmo endereço IP. Caso contrário, o servidor deve rejeitar sua conexão, pois isso pode sugerir que alguém roubou seu ticket. Assim, nos protegemos aqui contra o uso de bilhetes roubados. Se você ainda tiver o mesmo ticket, tudo bem, mas se você não usar o mesmo endereço IP, não terá êxito.

Isso parece um equívoco no momento, e o Kerberos 5 ainda usa uma abordagem semelhante, embora isso não seja necessário. Na verdade, você deve simplesmente confiar na criptografia em vez de proteger o endereço IP.

Mas qual é o significado do carimbo de data e hora e do tempo de vida no ticket? Para que servem e para que servem?

Aluno: Eles são necessários para evitar ataques de repetição.
Professor: os ataques de repetição nos ajudam a impedir o autenticador, porque isso é gerado toda vez que você faz uma nova solicitação. Mas, por outro lado, o ticket permanece o mesmo, portanto, é claro, isso não interfere nos ataques de repetição.

Aluno: isso impede que alguém roube seu bilhete e depois o use para seus próprios fins.
Professor: sim, isso simplesmente limita o tempo durante o qual o ticket é válido, para que os danos causados ​​pelo roubo sejam reduzidos. O registro de data e hora é o horário em que você recebeu o ticket e a vida útil mostra quantas horas esse ticket é válido a partir do registro de data e hora inicial. Portanto, se você tentar usá-lo muito cedo ou muito tarde, qualquer servidor deverá rejeitar esse ticket usando o protocolo Kerberos. Isso significa que cada servidor deve sincronizar seu relógio.

Aluno: Você disse anteriormente que um cliente pode jogar fora sua chave inicial, descartar Kc, mas deve armazenar os Kc recebidos do TGS.

Professor: sim, o cliente descarta Kc após o login, mas deve manter Kc, s.

Aluno: então, se alguém rouba Kc, s, então ele tem acesso ...

Professor: sim, vamos considerar o quão ruim isso é? Por que é melhor para um hacker revelar esse Kc, tgs, do que Kc?

Aluno: se você pegar Kc, s, poderá simplesmente roubar uma sessão entre esses dois interlocutores, mas se você roubar Kc, poderá se passar por um cliente.



Professor: . , Kc,s — , , . , Tc,tgs, . , 56 Kc,s. . , Tc,tgs , Kc,s , - .

: , - — Tc,tgs, Kc,tgs, Kc,tgs, Kc — .

: , - , , , , 10 . Kc , .

, , , IP-, . - , , Kc,tgs, TGS. — , , , .

, , , . , , . TGS , , PO12, TGS PO12. , , Kc,s . , , . Kc,s.



, , Tc,mail, Kmail, , , , 5 – DELETE 5, Kc,mail.



, mail? Kmail, - , , Kc,s, Kerberos 5. : «, C , ».

: Kerberos Tc,tgs Kc,s. ?

: Ac . , Kc,s, , . , .



, Kerberos 4 , , , , , , , .

, , , , . , . , , . , , , , . , .
. Kerberos, , , Kerberos 4. , - .

, , , , , Kerberos 4, , , K,mail. , .



, , . , , . - : «, , DELETE 5, - ».

, Kerberos 5 -, . , , , , , .

: K,mail?

: .



, TGS , , S – mail, S Tc,s – mail, S Kc,s — mail. Kc,s K,mail. , .

: K,mail?

: , ? , , . K,mail ?

: ?

: , , ! Kmail, T,mail, , . , , .

, . . Kerberos , , 30 .
Portanto, é inevitável que tenhamos problemas que você deve resolver. Portanto, um problema interessante do Kerberos 4 diz respeito ao método de criptografar e autenticar mensagens para aplicativos. Consiste no fato de que a mesma chave é usada aqui para criptografar mensagens do cliente para o servidor e para mensagens de resposta do servidor para o cliente.

54:00 min

Curso do MIT "Computer Systems Security". Aula 13: Protocolos de Rede, Parte 3


A versão completa do curso está disponível aqui .

Obrigado por ficar conosco. Você gosta dos nossos artigos? Deseja ver materiais mais interessantes? Ajude-nos fazendo um pedido ou recomendando a seus amigos, um desconto de 30% para os usuários da Habr em um análogo exclusivo de servidores básicos que inventamos para você: Toda a verdade sobre o VPS (KVM) E5-2650 v4 (6 núcleos) 10GB DDR4 240GB SSD 1Gbps da US $ 20 ou como dividir o servidor? (as opções estão disponíveis com RAID1 e RAID10, até 24 núcleos e até 40GB DDR4).

VPS (KVM) E5-2650 v4 (6 núcleos) 10GB DDR4 240GB SSD de 1Gbps até dezembro de graça quando pagar por um período de seis meses, você pode fazer o pedido aqui .

Dell R730xd 2 vezes mais barato? Somente nós temos 2 TVs Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 a partir de US $ 249 na Holanda e nos EUA! Leia sobre Como criar um prédio de infraestrutura. classe usando servidores Dell R730xd E5-2650 v4 custando 9.000 euros por um centavo?