Esquema de vazamento de dados através da descoberta automática de proxy da web (WPAD) em caso de colisão de nomes (neste caso, uma colisão entre um domínio interno e o nome de um novo gTLD, mas a essência é a mesma). Fonte: , 2016
Mike O’Connor, um dos investidores mais antigos em nomes de domínio, o lote mais perigoso e polêmico de sua coleção: o domínio corp.com por $1,7 milhões. Em 1994, O’Connor comprou muitos nomes de domínio simples, como grill.com, place.com, pub.com e outros. Entre eles estava o corp.com, que Mike manteve por 26 anos. O investidor já tem 70 anos e decidiu monetizar seus investimentos antigos.
O problema é que o corp.com é potencialmente perigoso para pelo menos 375.000 computadores corporativos devido à configuração descuidada do Active Directory durante a criação de intranets corporativas no início dos anos 2000, com base no Windows Server 2000, quando a raiz interna era simplesmente especificada como "corp". Até o início de 2010, isso não era um problema, mas com o aumento do número de laptops no ambiente de trabalho, cada vez mais funcionários começaram a levar seus computadores de trabalho para fora da rede corporativa. As características da implementação do Active Directory fazem com que, mesmo sem uma solicitação direta do usuário para \/\/corp, várias aplicações (como e-mail) acessem esse endereço familiar por conta própria. Mas, em caso de conexão externa à rede em um café na esquina, isso resulta em um fluxo de dados e solicitações direcionadas a corp.com.
Agora, O’Connor espera que o domínio seja adquirido pela própria Microsoft e que, seguindo as melhores tradições do Google, o coloque em algum lugar escuro e inacessível para resolver o problema de uma vulnerabilidade tão fundamental nas redes Windows.
Active Directory e colisão de nomes
Em redes corporativas baseadas em Windows, utiliza-se o serviço de diretórios Active Directory. Ele permite que os administradores apliquem políticas de grupo para garantir a uniformidade na configuração do ambiente de trabalho do usuário, implantem software em vários computadores através de políticas de grupo, realizem autenticação, etc.
O serviço Active Directory está integrado ao DNS e funciona sobre TCP\/IP. Para localizar nós dentro da rede, utiliza-se o protocolo de descoberta automática de proxy da Web (WAPD) e a função (integrado ao Cliente DNS do Windows). Esta função facilita a localização de outros computadores ou servidores sem a necessidade de especificar o nome de domínio completo.
Por exemplo, se uma empresa gerencia uma rede interna chamada internalnetwork.example.com, e um funcionário deseja acessar um disco compartilhado chamado drive1, não é necessário digitar drive1.internalnetwork.example.com no Explorador, basta digitar \drive1 — e o cliente Windows DNS completará o nome automaticamente.
Nas versões anteriores do Active Directory — por exemplo, no Windows 2000 Server — o segundo nível do domínio corporativo foi definido por padrão como corp. E muitas empresas mantiveram o valor padrão para seu domínio interno. Pior ainda, muitas começaram a construir redes extensas em cima dessa configuração errônea.
Na era dos desktops, isso não representava um grande problema de segurança, pois ninguém levava esses computadores para fora da rede corporativa. Mas o que acontece quando um funcionário que trabalha em uma empresa com um caminho de rede corp no serviço Active Directory pega um laptop corporativo — e entra em uma Starbucks local? Então, entra em ação o protocolo de configuração automática de proxy Web Proxy Auto-Discovery (WPAD) e a função de devolução de nome DNS.
É muito provável que alguns serviços no laptop continuem tentando acessar o domínio interno corp, mas não o encontrem, e em vez disso, as solicitações sejam resolvidas para o domínio corp.com da internet pública.
Na prática, isso significa que o proprietário do corp.com pode interceptar passivamente solicitações privadas de centenas de milhares de computadores que, acidentalmente, saem do ambiente corporativo que utiliza a corp para seu domínio no Active Directory.
Vazamento de solicitações WPAD no tráfego dos EUA. De um estudo da Universidade de Michigan em 2016,
Por que o domínio ainda não foi vendido
Em 2014, especialistas da ICANN publicaram sobre colisões de nomes no DNS. O estudo foi parcialmente financiado pelo Departamento de Segurança Interna dos EUA, pois vazamentos de informações de redes internas ameaçam não apenas empresas comerciais, mas também organizações governamentais, incluindo serviços secretos, agências de inteligência e unidades militares.
Mike queria vender corp.com no ano passado, mas o pesquisador Jeff Schmidt o convenceu a adiar a venda com base no relatório mencionado acima. Durante a pesquisa, foi descoberto que diariamente 375.000 computadores tentam se conectar ao corp.com sem o conhecimento dos proprietários. As solicitações incluíam tentativas de acessar intranets corporativas, redes ou recursos de arquivos.
Como parte de seu próprio experimento, Schmidt, junto com a JAS Global, simulou no corp.com um método de processamento de arquivos e solicitações usado em redes locais do Windows. Isso, de fato, abriu um portal ao inferno para qualquer profissional de segurança da informação:
Foi horrível. Paramos o experimento após 15 minutos e destruímos [todos os dados coletados]. Um testador bem conhecido, que aconselhou a JAS nesse assunto, observou que o experimento parecia uma "chuva de informações confidenciais" e que ele nunca havia visto nada parecido.
[Nós configuramos a recepção de e-mails no corp.com] e cerca de uma hora depois recebemos mais de 12 milhões de e-mails, após o que interrompemos o experimento. Embora a esmagadora maioria dos e-mails fosse automatizada, descobrimos que alguns deles eram sensíveis [à segurança] e, portanto, destruímos todo o conjunto de dados sem análise adicional.
Schmidt acredita que administradores em todo o mundo, durante décadas, sem saber, prepararam a botnet mais perigosa da história. Centenas de milhares de computadores de trabalho em todo o mundo estão prontos não apenas para se tornarem parte de uma botnet, mas também para fornecer dados confidenciais sobre seus proprietários e empresas. Tudo o que é necessário para aproveitá-la é controlar o corp.com. Qualquer máquina que tenha sido conectada uma vez à rede corporativa, cuja Active Directory foi configurada através de //corp, torna-se parte da botnet.
A Microsoft 'desconsiderou' o problema há 25 anos
Se você acha que a MS não estava ciente da balbúrdia em torno do corp.com, está muito enganado. com uma página como esta, onde usuários da versão beta do FrontPage ’97 eram direcionados, na qual o corp.com era listado como URL padrão:
Quando Mike ficou completamente farto disso, corp.com começou a redirecionar usuários para um site de sex shop. Em resposta, ele recebeu milhares de e-mails furiosos de usuários que foram redirecionados através de uma cópia de Bill Gates.
Aliás, Mike também, por curiosidade, levantou um servidor de e-mail e recebeu correspondências confidenciais em corp.com. Ele tentou resolver esses problemas por conta própria, entrando em contato com as empresas, mas elas simplesmente não sabiam como corrigir a situação:
Imediatamente comecei a receber e-mails eletrônicos confidenciais, incluindo rascunhos de relatórios financeiros corporativos para a Comissão de Valores Mobiliários dos EUA, relatórios de recursos humanos e outras coisas assustadoras. Por um tempo, tentei me corresponder com as corporações, mas a maioria delas não sabia o que fazer com isso. Assim, acabei simplesmente desligando [o servidor de e-mail].
Do lado da MS, nenhuma ação ativa foi tomada, e a empresa se recusa a comentar sobre a situação. Sim, a Microsoft lançou várias atualizações do Active Directory ao longo dos anos que parcialmente solucionam o problema de colisão de nomes de domínio, no entanto, elas apresentam uma série de problemas. A empresa também lançou recomendações guia sobre a configuração de nomes de domínio internos, recomendações sobre propriedade de domínios de segundo nível para evitar colisões e outros tutoriais que geralmente não são lidos.
Mas o mais importante está nas atualizações. Primeiro: para aplicá-las, é necessário desligar completamente a intranet da empresa. Segundo: alguns aplicativos podem começar a funcionar mais lentamente, de forma inadequada ou podem parar de funcionar completamente após essas atualizações. É claro que a maioria das empresas com uma rede corporativa estabelecida a curto prazo não assumirá tais riscos. Além disso, muitas delas nem sequer percebem a extensão da ameaça que representa o redirecionamento de tudo e de todos para corp.com ao remover a máquina dos limites da rede interna.
O máximo de ironia é alcançado quando você visualiza . Assim, de acordo com seus dados, algumas solicitações para corp.com vêm da própria intranet da Microsoft.
E o que acontecerá a seguir?
Pareceria que a solução para essa situação está à vista e foi descrita no início do artigo: que a Microsoft compre o domínio de Mike e proíba-o em algum canto esquecido para sempre.
Mas nem tudo é tão simples. A Microsoft ofereceu a O’Connor a compra de seu domínio tóxico para empresas em todo o mundo há alguns anos. A questão é que o gigante propôs para fechar essa lacuna em suas redes apenas $20 mil.
Agora o domínio está à venda por $1,7 milhões. E mesmo que a Microsoft decida comprar no último momento — será que vão conseguir a tempo?
Apenas usuários registrados podem participar da pesquisa. , por favor.
E como você agiria no lugar de O’Connor?
59,6%Deixaria a Microsoft comprar o domínio por $1,7 milhões, ou seria adquirido por outra pessoa.
3,4%Eu o venderia por $20 mil, não quero ser lembrado como a pessoa que deixou escapar um domínio assim para alguém desconhecido.
3,3%Eu o enterraria para sempre, se a Microsoft não consegue tomar a decisão certa.
21,2%Vendia intencionalmente o domínio para hackers com a condição de que eles destruíssem a reputação da Microsoft no ambiente corporativo. Eles sabiam do problema desde 1997!
12,4%Eu levantaria um botnet e um servidor de e-mail e passaria a dominar os destinos do mundo.
840 usuários votaram. 131 usuários se abstiveram.
Fonte: habr.com
