Meu nome é Rob Stackle, sou consultor de segurança de Phoenix, Arizona e trabalho principalmente como pentester. Estou participando de conferências da DefCon desde 1996, gosto de fotografia em grandes altitudes e este fim de semana foi o décimo primeiro aniversário de nosso casamento. Quero agradecer à minha incrível e compreensiva esposa Linda, que não esperava que minha participação na DefCon signifique que todos os anos seremos obrigados a celebrar nosso aniversário de casamento em Las Vegas, o que sinto muito.
Vou falar com você sobre várias coisas relacionadas à pesquisa em que venho trabalhando nos últimos anos. Eles estão unidos por um tema comum - se você não monitorar seu tráfego DNS e não entender o que acontece lá, quando tudo estiver em ordem, provavelmente não prestará atenção quando coisas ruins começarem a acontecer. Eu "estuprei" o DNS por vários anos e esse sempre foi um dos meus vetores de ataque favoritos. Você pode gastar uma fortuna em fortalecer o perímetro da rede, mas se eu conseguir o controle de um de seus dispositivos, acredite, seu jogo acabou.
A ausência de vulnerabilidades no mercado para detectar configurações incorretas sempre me dá a oportunidade de "colocar o pé na porta". Hoje discutiremos vários tópicos nos quais falarei sobre minhas aventuras com o DNS e meus truques com pessoas relacionadas ao DNS.
Esses tópicos são dedicados a entender mal o comportamento do DNS pelos usuários finais da rede, falarei um pouco sobre pessoas que não registraram seus domínios e sobre a própria invasão de domínios.
Nas conferências da Black Hat e da DefCon em 2011, Artyom Daineberg falou sobre o que ele chamou de agachamento por batida, ou "dar uma batida". Aqueles que não estão familiarizados com este estudo, mas estão interessados neste problema no DNS de domínios populares, podem fazer o download dos materiais de sua apresentação usando os links fornecidos neste slide.
Página do Projeto /
Apresentação em Vídeo /
SlidesQuando li o anúncio de seu discurso, publicado antes mesmo do relatório sobre a Black Hat, fiquei imediatamente interessado em como isso pode ser usado para meus próprios fins. Sem entrar em detalhes, explicarei o que é agachamento por batida, por que acontece e o que afeta. Vou mostrar alguns exemplos do risco de virar acidentalmente um pouco na memória quando 1 passar para 0 e vice-versa. Os slides a seguir mostram como isso se parece com um exemplo de linha na memória que exibe um nome de domínio.
No meio dessa linha, a unidade se transforma em zero. Artyom investigou o fenômeno no qual um erro de bit único na parte correta da memória no momento certo obrigava o cliente a solicitar um nome de domínio completamente legítimo, porém incorreto.
Muito se falou sobre a probabilidade e as causas desse erro, mas comecei a estudar todas as maneiras que permitem que esse erro seja usado para fins maliciosos. Portanto, o agachamento de DNS permite distorcer os nomes de domínio, registrar esses domínios “errados” e enviar solicitações de usuários a eles.
O slide a seguir mostra que, como resultado do agachamento em bits do nome de domínio do Google, quando um próton de alta energia na memória "atinge" 1, que significa a letra g, o transforma em 0, o que significa a letra f e, como resultado, o usuário é redirecionado para goofle.com .
Portanto, seu navegador o redirecionará completamente para outro site e terá a resposta certa para você. Ao mesmo tempo, o DNS SEC não poderá ajudá-lo de nenhuma maneira e, de fato, existem muito poucas oportunidades para evitar esse erro de uma maneira completamente invisível, exceto pelo uso de memória ECC, que reconhece e corrige erros de bits automaticamente.
No entanto, esse tipo de memória não é muito comum e, mesmo que você tenha usado o ECC, ainda existem muitos locais onde o agachamento de bits pode ocorrer e onde a memória do ECC nunca é usada, por exemplo, em uma placa de rede ou no cache DRAM de um disco rígido.
Deineberg descreveu em detalhes as causas do problema, mas, em geral, pode-se dizer que ocorrem erros de memória, às vezes danificam a memória e às vezes isso afeta o DNS. Basicamente, a “inversão” de um bit deve-se a danos físicos à memória, superaquecimento, problemas elétricos, exposição a radiação e até radiação cósmica.
A apresentação é interrompida pela aparição no palco dos organizadores da DefCon, que felicitam o palestrante e sua esposa Linda, que está presente na conferência pela primeira vez, no décimo primeiro aniversário de casamento. Robert agradece os parabéns e continua a apresentação.
A radiação cósmica é um fator extremamente raro que afeta o agachamento de bits, mas o superaquecimento é uma causa muito comum de erros de memória. Notei que os smartphones são especialmente vulneráveis devido às condições operacionais extremas às quais estão expostos. O superaquecimento da bateria do smartphone é uma ocorrência bastante comum. A maioria dos outros dispositivos possui refrigeração, mas mesmo eles conseguem criar condições operacionais difíceis.
Há pouco tempo, o Google publicou informações sobre o trabalho de seus data centers. Uma das coisas interessantes que aprendi foi a mensagem de que, para economizar energia, eles operam seus data centers em condições que a maioria de nós consideraria irracionais. Se os data centers típicos operam a uma temperatura máxima de 15 a 20 ° C (60 a 70 graus Fahrenheit), os especialistas do Google recomendam que as empresas operem os data centers a uma temperatura de pelo menos 80 graus (27 ° C) e um data center belga Google operava seus servidores a uma temperatura de 95 graus (35 ° C).
Legenda: "Ouvi dizer que economiza dinheiro".
A Intel e a Microsoft alegam que seus servidores se comportam bem em altas temperaturas, e a Dell garante que seus servidores funcionem a 46 ° C (115 graus Fahrenheit). Acho que é uma péssima idéia, já que a temperatura é o principal fator para garantir uma operação estável da memória, e os data centers do Google operam em temperaturas de "fogo".
Comecei a estudar quais vantagens isso poderia oferecer e quais domínios eram mais vulneráveis ao agachamento de bits, ou seja, tentei encontrar os nomes solicitados com mais frequência para aumentar a probabilidade de encontrar esses erros. Comecei a coletar logs DNS de grandes empresas para encontrar os nomes de domínio mais comuns e descobri que o nome mais solicitado era gstatic.com. Esse é um dos domínios em que o Google serve para fornecer informações estáticas, como arquivos CSS, imagens, JavaScript e XML.
Escrevi um script para identificar possíveis "transtornos" de bits nesse nome de domínio gstatic.com e recebi uma lista de todas as variações desse nome no total de 34 partes. Cinco deles foram usados para fins legais, os 29 restantes estavam disponíveis, então eu comprei todos eles.
Eu imediatamente acertei o alvo. Alguém estava procurando imagens no Google e o conteúdo da solicitação retornou para eles de alguma forma danificado, porque seu navegador me pediu para exibir uma das imagens na solicitação. Eu vejo o endereço IP, o nome distorcido que eles solicitaram, o recurso que eles tentaram recuperar usando esta imagem, a página relacionada a esse conteúdo e o cliente que foi usado como navegador para enviar essa solicitação.
Na página, você pode ver um artefato interessante na forma de uma solicitação para um nome específico Trisha Jones.
Além disso, o número de solicitações aumentou, mais nomes distorcidos apareceram, mais solicitações de imagem e mais links para a solicitação original, como resultado da coleta de mais de 50.000 solicitações exclusivas, e isso, como se viu, era uma ocorrência comum.
O slide mostra um pedido de uma imagem "fotografada" da atriz Selena Gomez, que causa risadas no salão.
Às vezes, o agachamento por batida acontece no momento certo para corresponder a uma de suas solicitações e, se isso não acontecer com muita freqüência, você não precisa se preocupar. Mas às vezes isso acontece no exato momento em que há uma economia no disco rígido, o que já é mais interessante. Há chances de que o agachamento de bits ocorra em condições operacionais normais da memória, mas é muito provável que isso ocorra principalmente em data centers com temperatura de 95 graus.
Agora meus logs estão cheios de todo o ruído, recebo solicitações distorcidas todos os dias em uma quantidade que não consigo visualizá-los manualmente.
Portanto, escrevo scripts na tentativa de encontrar os mesmos padrões de consulta, e a maior que obtive foram muitas consultas da mesma imagem para o mesmo nome de domínio distorcido, e todas vieram de telefones celulares. Recebi esses pedidos a cada poucos segundos, pois todos esses telefones tentaram usar a página de pesquisa do site do Google e pediram para fornecer uma pequena imagem do logotipo da página original.
Encontrei um servidor Web de toda a nuvem do Google que exibia conteúdo e distorcia constantemente o nome de domínio, apontando para um dos meus servidores, onde o logotipo com esse nome era acidental e os clientes o usavam.
O slide mostra como o logotipo da página de pesquisa do Google na tela de um dispositivo móvel é substituído pelo logotipo Occupy, o que causa uma risada apreciativa no corredor.Por dois anos, centenas de milhares de solicitações para esse logotipo chegaram a esse servidor com um nome DNS distorcido, em vez daquele que o Google planejava usar. Um dia, eles pararam, pois o Google se recusou a alterar o conteúdo dos sites para celular e esse pedido foi cancelado.
Então, continuei estudando padrões de consulta e tentei descobrir outros padrões. Um deles apareceu regularmente e ocorreu obviamente de uma maneira natural, “invertendo um pouco” na memória, e não como resultado de um erro de agachamento de bits salvo.
Recebi as solicitações mostradas no próximo slide com uma frequência de uma por hora. Eles não pareciam familiares, todos usavam o cliente Google Feedfetcher, todos vinham de dispositivos na mesma rede e todas as solicitações estavam relacionadas a arquivos XML. Pesquisei um pouco e achei o Feedfetcher o mecanismo que o Google usa para capturar conteúdo atualizado para o iGoogle, e os endereços IP de origem estavam localizados na Bélgica.
Essas solicitações estão relacionadas aos servidores do Google, que são usados para receber conteúdo atualizado para vários widgets que personalizam a página inicial do iGoogle, um portal pessoal da Internet.
Cada widget é um arquivo XML que define o conteúdo, e o Google me pediu para fornecer esse conteúdo aos meus servidores de apresentação (aplausos e risadas da platéia).
Portanto, pensei que, se o Google quisesse acidentalmente conteúdo meu que pudesse fornecer aos usuários, ele o receberá. Peguei os arquivos XML que o Google me perguntou e os dividi em partes. Como você pode ver, existem duas seções: um cabeçalho que descreve o módulo e um bloco C de dados compactados no código HTML e CSS JavaScript que compõem o widget.
Então, mudei o link para a imagem de fundo, mudei o endereço de gstatic.com para grtatic.com e deixei o resto inalterado, coloquei os arquivos XML na linha de onde o Feedfetcher os obteve e esperei um pouco.
Quase imediatamente depois disso, o Feedfetcher solicitou arquivos XML, após o qual comecei imediatamente a receber solicitações de muitos endereços IP do Google para esta imagem de plano de fundo.
Portanto, excluí os arquivos XML modificados por mim e esperei até que as solicitações parassem, mas por 35 dias consecutivos, 61 dispositivos continuavam me perguntando sobre esta imagem todos os dias. E, mais interessante, cada um desses dispositivos era um cliente da Virgin Media no Reino Unido.
Portanto, esse arquivo XML do Google atendeu 61 pessoas e, no ano passado, 500 IPs únicos do Feedfetcher me pediram para fornecer esses módulos 15.000 vezes. Assim, eu poderia fornecer aos meus usuários algo mais prejudicial do que simplesmente substituir a imagem de plano de fundo.
Aqui estão mais alguns truques que você pode fazer com o Google. Se você não souber, o Postini é o serviço recente de proteção de spam, segurança e arquivamento de emails do Google.
Este serviço permite que você altere seu DNS para indicar seu registro MX em seu domínio e faça seu domínio alterando os 4 caracteres MX antes de psmtp.com. O mais interessante aqui é que o domínio é tão curto que você pode registrar facilmente todas as versões possíveis do nome com os bits "invertidos". Outro ponto interessante é que muitas empresas indicam seus registros MX para um único domínio e ninguém achou que era uma má idéia.
Portanto, registrei apenas três possíveis agachamentos para esse domínio, e o emprego do psmtp.com foi tão grande que os 4 slides seguintes mostram os pedidos que recebi em apenas um mês.
Portanto, se você usar o correio do Postini, sua solicitação chegará ao meu servidor em algum momento. Acho que ninguém pode dizer que o Google não fala sério sobre segurança na Internet. Mas se alguém se perguntasse a que problemas um superaquecimento que causa erros de memória poderia levar, ele seria capaz de levantar a questão de considerar a possibilidade de compensação por essas coisas. Portanto, não permita que seus nomes de domínio sejam tão curtos, pois isso afeta negativamente seus negócios, como o Postini, principalmente se o seu domínio for popular.
Eu recomendo fortemente que as pessoas apliquem uma política interna de gerenciamento de nomes de domínio que permita corrigir erros de distorção de nome e entender claramente como essas coisas podem afetá-lo. Se você possui o gstatic.com e um data center operando a uma temperatura de 95 graus, provavelmente deseja garantir que qualquer erro de agachamento de bits não permita que o cliente acesse uma rede externa maliciosa.
A propósito, entre todos os domínios que investiguei, a única empresa que registrou todas as possíveis distorções em meu próprio nome foi o Yahoo.
Na próxima parte da apresentação, vou demonstrar o comportamento do DNS, que muitas pessoas, como se vê, não entendem completamente.
Honestamente, a Microsoft fez um trabalho muito ruim de documentação, especialmente porque o comportamento do DNS geralmente muda. Isso leva a um mal-entendido do que está acontecendo pelos usuários finais, especialmente porque esse comportamento é muitas vezes contraditório.
Portanto, começarei com o fato de que todos devem entender como os dispositivos devem se comportar ao consultar o DNS e o que esperar deles. Depois, explicarei como esse comportamento se torna imprevisível ao usar os caminhos de pesquisa de sufixos DNS, como a documentação insuficiente afeta tudo isso e terminarei com uma breve visão geral das lições que podem ser aprendidas com tudo isso. Mas primeiro, demonstrarei como é perigoso para um usuário final entender mal o que está acontecendo com o DNS.
Assim, depois que você digitou
www.google.com na barra de endereços do seu navegador, seu computador envia uma solicitação ao servidor DNS local e o trabalho de encontrar o que você precisa, retornando a solicitação e a resposta agora está atribuído a ele. O servidor local chama o servidor raiz para acessar o servidor .com e o servidor raiz envia para o servidor .com. Ele verifica se o servidor local está autorizado para solicitações ao google.com e o envia ao servidor ns.google.com. Por fim, o servidor local recebe uma resposta com o endereço IP do recurso necessário e o envia para você.
Esse é o comportamento normal do DNS que todos esperam dele. Todo mundo pensa que basta enviar uma solicitação do dispositivo para o servidor DNS local para que ele faça todo o trabalho duro e, em seguida, obter uma resposta para sua solicitação. Mas nem todo mundo imagina que esse processo consiste em muitas etapas importantes.
Por exemplo, seu dispositivo está tentando encontrar a resposta em
www.google.com , mas todo o processo, que levou até oito slides, só acontecerá se você digitar exatamente esse endereço na barra de consultas do navegador -
www.google .com . Este é o nome de domínio totalmente qualificado associado ao DNS raiz. Muitas pessoas acreditam que o nome de domínio totalmente qualificado termina com um período, o que não é verdade. A presença de um ponto no final do nome completo ainda é assumida e, por isso, ocorrem problemas. Vamos tentar imprimir 4 variações do nome:
www.google.comgoogle.com
www
www.google.comcada um dos quais se comporta de maneira diferente em relação ao comportamento do DNS. Tudo isso é personalizável, mas geralmente ninguém o faz.
Vejamos o que realmente acontece nessas situações. Existem vários fatores que influenciam a tomada de decisão do cliente antes que eles decidam enviar uma consulta DNS. Dois deles são caminhos de pesquisa com sufixo e devolução de DNS.
Ambos têm muitos parâmetros personalizáveis que afetam seu comportamento e se comportam de maneira diferente em diferentes versões do Windows e em diferentes service packs.
É assim que a maioria das pessoas usa o sufixo do caminho de pesquisa. Se sua empresa se chama foo e você é o proprietário do domínio foo.com, e o nome do diretório ativo é ad.foo.com, você pode usar o sufixo dos caminhos de pesquisa ad.foo.com ou foo.com e "enviá-lo" para a parte cliente da montagem do sistema ou em política de grupo.
Se um de seus clientes tentar resolver o nome abreviado www, o comportamento padrão do Windows XP será assim. Primeiro, ela enviará uma consulta DNS pelo caminho
www.ad.foo.com , depois pelo caminho
www.foo.com e no final uma consulta NetBIOS seguirá - apenas www.
www.phx ,
www.phx , ,
www.phx.ad.foo.com ,
www.phx.foo.com . 15 , NetBIOS,
www.phx .
Windows, XP sp.3, DNS —
www.phx NetBIOS —
www.phx , , .
, , , , , . , , Microsoft DNS.
XP , Microsoft XP, DNS Windows DNS . , www, Windows , , , DHCP Active Directory.
www.phx.ad.foo.com , ,
www.ad.foo.com ,
www.foo.com , ,
www.com .
18:30
DEFCON 21. DNS . Parte 2, . ? ? ,
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 núcleos) 10 GB DDR4 240 GB SSD de 1 Gbps até dezembro de graça quando pagar por um período de seis meses, você pode fazer o pedido
aqui .
Dell R730xd 2 ? 2 Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 $249 ! . c Dell R730xd 5-2650 v4 9000 ?