Curso MIT "Segurança de sistemas de computadores". Aula 8: Modelo de Segurança de Rede, Parte 3

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

Público-alvo: por que um token aleatório sempre é incluído no URL e não no corpo da solicitação?

Professor: HTTPS é usado dessa maneira, mas não há um bom motivo para não incluir variáveis ​​aleatórias no corpo da solicitação. Apenas algumas formas de herança funcionam dessa maneira através do URL. Mas, na prática, você pode colocar essas informações em outro lugar na solicitação HTTPS, exceto no cabeçalho.

No entanto, observe que simplesmente mover essas informações para o corpo da solicitação é potencialmente inseguro se houver algo que o invasor possa adivinhar. Em seguida, o invasor ainda pode, de alguma forma, chamar os URLs de que precisa. Por exemplo, quando faço uma solicitação XML XML e, em seguida, coloco explicitamente algum conteúdo no corpo que o invasor pode adivinhar.



Se você simplesmente definir o quadro no URL, o invasor poderá controlá-lo. Mas se você usar uma solicitação XML HTTP HTTP e um invasor puder gerar uma delas, a interface HTTP XML permitirá que você defina o corpo da solicitação. Uma solicitação XML XML é limitada à mesma origem. No entanto, se um invasor puder fazer algo como:

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

Em seguida, ele poderá implementar a solicitação HTTP XML, que será executada com a autoridade da página incorporada.

Tudo depende do que o atacante tem acesso. Se forçar a página a executar um script não verificado, como mostrado acima, poderá usar a propriedade JavaScript chamada HTML interno e obter todo o conteúdo HTML da página. Se um invasor pode ou não pode gerar uma solicitação AJAX, isso é uma coisa, se ele pode ou não pode ver o código HTML correto, isso é outra, e assim por diante. Em resumo, esse token gerado aleatoriamente é capaz de impedir ataques de CSRF.

Há mais uma coisa que você precisa prestar atenção nos endereços de rede. Eles se relacionam com a parte da nossa conversa que disse quem o invasor não pôde se comunicar por meio de uma solicitação XML HTTP.

Em relação aos endereços de rede, o quadro pode enviar solicitações HTTP e HTTPS para (host + porta) correspondentes à sua origem. Observe que a segurança da mesma política da mesma fonte está intimamente relacionada à segurança da infraestrutura DNS, porque todas as políticas desse tipo são baseadas no que você chama.

Portanto, se você pode controlar o que eles me chamam, pode fazer alguns ataques mal-intencionados, por exemplo, um ataque de re-ligação ao DNS. O objetivo desse ataque é iniciar um JavaScript controlado por um invasor com a autoridade (ou em nome do) site da vítima, vamos chamá-lo de vítima.com. Nesse caso, o invasor usa as regras da mesma política de origem e, de alguma forma, inicia o código que ele escreveu com a permissão de outro site.

Isso é feito da seguinte maneira. Primeiro, um invasor registra um nome de domínio, por exemplo, attacker.com. É muito simples, basta pagar alguns dólares - e em movimento, você tem seu próprio nome de domínio. O invasor também deve configurar o servidor DNS para responder a solicitações que vêm com o nome de objetos localizados em attacker.com.



A segunda coisa que deve acontecer é que o usuário deve visitar o attacker.com. Em particular, ele deve visitar algum site que dependa desse nome de domínio. Também não há nada complicado nessa parte do ataque.

Veja se você pode criar uma campanha publicitária, por exemplo, oferecer um iPad grátis. Todo mundo quer um iPad grátis, embora eu não conheça ninguém que já ganhou um iPad grátis. Então, clicando nessa mensagem em um email de phishing, e você já está no site do invasor. Nada de especial, esta parte não é complicada.

Então, o que vai acontecer depois disso? O navegador começará a gerar consultas DNS para o attacker.com porque a página que você visitou contém objetos vinculados a objetos localizados no attacker.com. Mas o navegador dirá: "Eu nunca vi esse domínio antes, então deixe-me enviar uma solicitação de permissão de DNS para entrar em contato com attacker.com"!



E o servidor DNS do invasor responde a essa solicitação, mas sua resposta contém uma vida útil TTL muito curta, o que impede que a resposta seja armazenada em cache. Portanto, o navegador pensará que é válido apenas por um período muito curto antes de precisar sair e confirmar isso, o que realmente significa proibir o armazenamento em cache.

Acontece que, assim que o usuário entra no domínio do hacker, o servidor DNS do invasor retorna primeiro o endereço IP real do servidor da Web que forneceu ao usuário código malicioso. Esse código do lado do cliente acessa attacker.com porque a política de origem permite tais solicitações. O usuário recebe uma resposta e agora o site malicioso é executado no lado do cliente.

Enquanto isso, o invasor irá configurar o servidor DNS, que ele controla, para vincular o nome attacker.com e o endereço IP da vítima.com. Isso significa que, se o navegador do usuário solicitar uma resolução de nome de domínio para algo dentro do attacker.com, ele realmente obterá algum tipo de endereço interno no site vítima.com.



Por que um DNS atacante pode fazer isso? Como o hacker o configura para isso, o servidor DNS do invasor não precisa consultar para se reconectar ao site vítima.com.

Além disso, se nosso site quiser obter um novo objeto, digamos, AJAX, ele considerará que essa solicitação AJAX vai para o attacker.com em algum lugar externo, mas, na verdade, essa solicitação AJAX vai para a vítima.com. Isso é ruim, porque agora temos esse código no lado em que está localizada a página do atacante.com, que na verdade obtém acesso aos dados do site vítima.com com uma fonte de origem diferente.



Simplificando, quando um script é executado no navegador da vítima devido à obsolescência da resposta DNS anterior, é feita uma nova consulta DNS para esse domínio, que, devido à proibição de armazenamento em cache, é enviado ao servidor DNS do invasor. Ele responde que agora o attacker.com parece ter um novo endereço IP de outro site, e a solicitação vai para outro servidor. E então, para retornar as informações coletadas pelo código, o invasor fornece seu endereço IP correto em uma das seguintes consultas DNS.

Público: não seria mais prudente fazer um ataque do contrário.com, para obter todos os cookies do invasor e coisas do gênero?

Professor: sim, essa opção também funcionará. Isso permitirá que você faça coisas boas como a verificação de portas. Quero dizer, sua abordagem funcionará corretamente. Como você pode, passo a passo, reatribuir constantemente o attacker.com a vários nomes de computadores e portas diferentes na rede vítima.com. Em outras palavras, a página da web attacker.com sempre pensa que vai para o attacker.com e recebe uma solicitação AJAX de lá.

De fato, toda vez que o servidor DNS se reconecta ao attacker.com, ele envia solicitações para outro endereço IP dentro da rede vítima.com. Dessa forma, ele pode simplesmente "percorrer" os endereços IP um por um e ver se alguém está respondendo a essas solicitações.

Público-alvo: mas o usuário que você está atacando não tem necessariamente acesso interno à rede vítima.com.

Professor: como regra geral, este ataque é que existem certas regras de firewall que podem impedir o site externo attacker.com de exibir endereços IP dentro da rede vítima.com. No entanto, se você estiver dentro de uma rede corporativa, como corp.net, atrás de um firewall corporativo, os computadores geralmente poderão se conectar a máquinas fora da rede.

Público-alvo: esse método de ataque funciona via HTTPS?

Professor: essa é uma pergunta interessante! O fato é que o HTTPS usa chaves. Se você usa HTTPS, ao enviar uma solicitação AJAX, a máquina da vítima não terá as chaves HTTPS do invasor e a verificação de criptografia no site vítima.com mostrará a incompatibilidade de chave. Portanto, acho que o HTTPS descarta a possibilidade desse tipo de ataque.

Público: e se a vítima usar apenas HTTPS?

Professor: Eu acho que isso vai parar o atacante.

Público-alvo: por que um invasor responde principalmente ao computador da vítima com seu endereço IP?

Professor: porque o invasor deve, de alguma forma, executar seu próprio código na máquina da vítima antes de poder executar outras ações para encontrar algo dentro da rede da vítima. Mas não vamos perder tempo, portanto, se você tiver dúvidas sobre a reatribuição do DNS, procure-me após a palestra.

Então, como você pode consertar isso? Uma maneira de corrigir essa vulnerabilidade é modificar o resolvedor de clientes DNS para que nomes de host externos nunca tenham permissão para acessar endereços IP internos.

É meio estúpido que alguém fora da sua rede consiga criar um DNS vinculado a algo dentro da sua rede. Esta é a solução mais simples.



Você pode imaginar que o navegador pode fazer algo chamado "fixação de DNS" ou fixação de DNS. Como resultado, se o navegador receber um registro de DNS resolvido, ele sempre considerará esse registro válido, por exemplo, para interação em 30 minutos, independentemente de qual TTL o invasor atribuir e, dessa forma, possa resistir ao ataque.
Essa solução é um pouco complicada, porque existem sites que usam intencionalmente DNS dinâmico para coisas como balancear a carga do servidor e similares. Portanto, a primeira solução com fixação de DNS é a melhor opção.

E agora veremos o que a mesma política de origem protege. E os pixels? Como a política de origem protege pixels?

Como se viu, os pixels realmente não têm origem. Assim, cada quadro recebe sua própria caixa delimitadora, basicamente apenas um quadrado, e o quadro pode desenhar em qualquer lugar dentro dessa área.

Na verdade, isso é um problema, porque significa que o quadro pai pode desenhar sobre o quadro filho. E isso, por sua vez, pode levar a ataques muito insidiosos.

Digamos que um invasor crie uma página que diz: "clique aqui para ganhar um iPad". O mesmo truque padrão. Este é o quadro pai.



E esse quadro pai pode criar um quadro filho, que na verdade é o quadro do botão Curtir em um site do Facebook. Assim, o Facebook permite que você execute esse pequeno pedaço de código do Facebook que você pode colocar em sua página.

Você sabe que se um usuário clicar em "curtir", significa que ele irá ao Facebook e dirá: "Ei, eu gosto dessa página em particular"! Portanto, agora temos esse quadro filho do botão Curtir.



Agora, um invasor pode sobrepor esse quadro na área da tela em que o usuário deve clicar para obter um iPad grátis e também tornar esse quadro invisível, o CSS permite isso.

Então o que vai acontecer? Como já instalamos, todo mundo quer obter um iPad grátis. O usuário acessará este site clicando nesta área da tela, certificando-se de que clica exatamente no que o iPad gratuito fornecerá a ele. Mas, na verdade, ele clica no botão invisível Curtir. É como colocar camadas no topo do índice C.

Isso significa que agora, talvez, o usuário termine em um perfil no Facebook, onde observa que gostou do attacker.com. Você sabe, ele nem se lembra como isso aconteceu. Portanto, isso é chamado de ataque de click jacking - suporte para um ataque de clique. Da mesma forma, você pode fazer muitas coisas ruins - roubar senhas, obter dados pessoais, enfim, isso é loucura. Eu enfatizo - isso é possível devido ao fato de que o quadro pai é capaz de desenhar qualquer coisa dentro dessa caixa delimitadora.

Portanto, o quadro pai é o que você vê na página, a chamada para obter um tablet gratuito e o quadro filho é o botão like, que é sobreposto de forma transparente ao quadro pai.

Existem várias soluções para esse problema. O primeiro é usar o código de interrupção de quadros. Dessa forma, você pode usar expressões JavaScript para descobrir se alguém incorporou seu próprio quadro ao seu quadro. Por exemplo, um desses testes é uma comparação do seguinte formato: if (self! = Top).

Aqui, a declaração própria refere-se à parte superior do quadro superior, que é comparada com a hierarquia de todo o quadro. Portanto, se você fizer esse teste e descobrir que o self não é igual à parte superior do quadro pai, entenderá que possui um quadro filho. Nesse caso, você pode recusar o download.

Isso acontece se você tentar criar um quadro, por exemplo, para o CNN.com. Se você procurar o código-fonte em JavaScript, poderá ver que ele realiza esse teste porque o CNN.com não deseja que outras pessoas usem seu conteúdo. Portanto, esse quadro sempre ocupa a posição mais alta. Portanto, esta é uma das soluções que podem ser usadas aqui.

A segunda solução é o servidor da Web enviar um cabeçalho HTTP chamado opções x-Frame em resposta. Portanto, quando o servidor da web retorna uma resposta, ele pode definir esse cabeçalho, que dirá: “ei, navegador, não deixe ninguém colocar meu conteúdo dentro do quadro!”. Esta solução permite que o navegador execute ações de imposição.

Então é bem simples. Mas ainda existem muitos outros ataques malucos que você pode organizar.

Como mencionei anteriormente, o fato de agora vivermos na Internet internacional cria problemas usando um domínio ou nome de host.

Suponha que tenhamos a letra C. Mas em que idioma? De que alfabeto é esta letra do latim ASCII ou é C em cirílico? Isso permite que você organize ataques que usam interpretações diferentes e usam letras diferentes, mas aparentemente semelhantes. Por exemplo, um invasor registrará um nome de domínio cats.com. E os usuários irão para esse domínio, pensando que visitarão o site "cats. Com", mas, na realidade, chegarão ao site do atacante "sats.com", porque a primeira letra aqui não é latina, mas cirílica.

Um invasor pode registrar o domínio fcebook.com, mas as pessoas não prestam atenção, o adotam como facebook.com e vão para lá. Portanto, se você controlar o Facebook.com, receberá muito tráfego de pessoas que pensam que estão conectadas ao Facebook.



Existem vários tipos de ataques malucos que você pode iniciar através do sistema de registro de nomes de domínio difíceis de defender, porque como impedir que os usuários cometam erros de digitação? Ou como o navegador indica ao usuário: "Ei, isso é cirílico, não latino"!?

Se o navegador avisar o usuário toda vez que as fontes cirílicas forem ativadas, irritará as pessoas que realmente usam cirílico como fonte nativa. Portanto, não está totalmente claro como esses problemas podem ser resolvidos do ponto de vista técnico, e é por isso que problemas de segurança muito sensíveis surgem aqui.

Outra coisa interessante são os plugins. Como os plug-ins interagem com as políticas de origem? Os plug-ins geralmente têm incompatibilidade com o restante do navegador em relação à mesma fonte de origem. Por exemplo, se você olhar para o plug-in Java, ele assume que diferentes nomes de host com o mesmo endereço IP também tenham a mesma origem.

De fato, esse é um desvio bastante grande da interpretação padrão de políticas da mesma origem. Essa abordagem significa que, se você tiver algo como xycom e zycom e eles forem projetados no mesmo endereço IP, o Java assumirá que eles têm a mesma fonte de origem. Isso pode ser um problema, pois, na realidade, um site tem uma fonte de origem confiável e o outro não. Existem muitas outras dificuldades associadas aos plug-ins, que você pode descobrir em fontes publicamente disponíveis na Internet ou nas notas da aula.

A última coisa que quero discutir é um ataque de compartilhamento de tela ou ataque de compartilhamento de tela.

O HTML5 realmente define uma nova API pela qual uma página da Web pode compartilhar todos os seus bits para compartilhar com outro navegador ou servidor. Parece uma ideia muito interessante, porque possibilita a vários usuários trabalhar simultaneamente no mesmo documento. Isso é ótimo porque vivemos no futuro.

Mas o mais engraçado é que, quando eles desenvolveram essa nova API, eles não pensaram em uma política de origem comum!

Suponha que você tenha uma página na qual vários quadros estejam localizados e cada um deles tenha o direito de capturar uma captura de tela de todo o monitor. Ele pode tirar uma captura de tela de todos os quadros localizados na tela e de todo o conteúdo, independentemente das fontes de origem.



Portanto, de fato, essa é uma falha bastante destrutiva na política da mesma fonte de origem, portanto, considere consertá-la. Por exemplo, se uma pessoa do quadro direito tiver a capacidade de capturar capturas de tela, poderá capturar apenas o quadro certo, e não a tela inteira como um todo.

Por que os desenvolvedores de navegadores não o implementaram dessa maneira? Porque eles estão sofrendo pressão competitiva e são forçados a concentrar seus esforços no desenvolvimento de mais e mais novas funções, novos recursos, em vez de prestar atenção na melhoria de coisas já desenvolvidas.

Muitas perguntas que os alunos fizeram na Internet sobre esta palestra foram: “por que os desenvolvedores não fizeram o que podiam? Isso não está claro? ou: “Parece que esse esquema em particular está morto. O outro não seria melhor? e assim por diante.

Vou lhe dizer honestamente - sim, com certeza, quase tudo seria melhor se os desenvolvedores aceitassem isso com responsabilidade. Então, eu tenho vergonha de estar conectado com isso.

Mas o fato é que é isso que tínhamos antes. Se você olhar para todos os elementos que existiam antes, verá que os navegadores da Web estão se desenvolvendo e as pessoas ficaram um pouco mais preocupadas com a segurança. Mas não no caso do compartilhamento de tela, onde os desenvolvedores estavam tão preocupados com os recursos inovadores do navegador que se esqueceram completamente da possibilidade de um pequeno vazamento.



Portanto, peço que você sempre preste atenção nas coisas que discutimos hoje. Imagine se começássemos do zero, destruíssemos tudo o que estava à nossa frente e tentássemos criar uma política de segurança melhor, o que você acha, quantos sites funcionariam para nós? Eu acho que não mais que 2%. Portanto, os usuários provavelmente reclamariam de nós.

Há outra propriedade interessante relacionada à segurança.Depois de atribuir uma função aos usuários, é muito difícil recuperá-la, mesmo que não seja seguro usá-la. Portanto, hoje discutimos muitas coisas relacionadas à política de origem e continuaremos falando sobre isso na próxima palestra.


.

, . ? ? , 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 ?