Esquema de fuga de datos mediante Web Proxy Auto-Discovery (WPAD) debido á colisión de nomes (neste caso, unha colisión dun dominio interno co nome dun dos novos gTLD, pero a esencia é a mesma). Fonte: , 2016
Mike O'Connor, un dos investidores máis antigos en nomes de dominio, o lote máis perigoso e controvertido da súa colección: o dominio corp.com por 1,7 millóns de dólares En 1994, O'Connor comprou moitos nomes de dominio sinxelos, como grill.com, place.com, pub.com e outros. Entre eles estaba corp.com, que Mike mantivo durante 26 anos. O investidor xa tiña 70 anos e decidiu monetizar os seus antigos investimentos.
O problema é que corp.com é potencialmente perigoso para polo menos 375 ordenadores corporativos debido á descoidada configuración de Active Directory durante a construción de intranets corporativas a principios da década de 000 baseadas en Windows Server 2000, cando a raíz interna simplemente se especificaba como "corp". ”. Ata principios da década de 2010, isto non era un problema, pero co aumento dos portátiles nos entornos empresariais, cada vez máis empregados comezaron a mover os seus ordenadores de traballo fóra da rede corporativa. As características da implementación de Active Directory levan ao feito de que aínda sen unha solicitude directa do usuario a //corp, unha serie de aplicacións (por exemplo, correo) chaman por si mesmas a un enderezo coñecido. Pero no caso dunha conexión externa á rede nun café convencional á volta da esquina, isto leva a un fluxo de datos e solicitudes corp.com.
Agora O'Connor realmente espera que a propia Microsoft compre o dominio e, segundo as mellores tradicións de Google, o podre nalgún lugar escuro e inaccesible para os estraños, resolverase o problema cunha vulnerabilidade tan fundamental das redes de Windows.
Active Directory e colisión de nomes
As redes corporativas que executan Windows usan o servizo de directorio de Active Directory. Permite aos administradores utilizar políticas de grupo para garantir a configuración uniforme do contorno de traballo do usuario, implementar software en varios equipos mediante políticas de grupo, realizar autorizacións, etc.
Active Directory está integrado con DNS e execútase enriba de TCP/IP. Para buscar hosts dentro da rede, o protocolo Web Proxy Auto-Discovery (WAPD) e a función (integrado en Windows DNS Client). Esta función fai que sexa fácil atopar outros ordenadores ou servidores sen ter que proporcionar un nome de dominio totalmente cualificado.
Por exemplo, se unha empresa opera unha rede interna denominada internalnetwork.example.com, e o empregado quere acceder a unha unidade compartida chamada drive1, non fai falta entrar drive1.internalnetwork.example.com no Explorador, simplemente escriba \drive1 - e o cliente DNS de Windows completará o propio nome.
Nas versións anteriores de Active Directory, por exemplo, Windows 2000 Server, o dominio predeterminado para o dominio corporativo de segundo nivel era corp. E moitas empresas mantiveron o predeterminado para o seu dominio interno. Aínda peor, moitos comezaron a construír redes amplas sobre esta configuración defectuosa.
Na época dos ordenadores de sobremesa, isto non era un gran problema de seguridade porque ninguén levou estes ordenadores fóra da rede corporativa. Pero que pasa cando un empregado traballa nunha empresa cunha ruta de rede corp en Active Directory colle un portátil corporativo e vai ao Starbucks local? Despois entran en vigor o protocolo de detección automática de proxy web (WPAD) e a función de transferencia de nomes DNS.
Hai unha alta probabilidade de que algúns servizos do portátil continúen golpeando o dominio interno corp, pero non o atopará e, en cambio, as solicitudes resolveranse ao dominio corp.com desde Internet aberta.
Na práctica, isto significa que o propietario de corp.com pode interceptar de forma pasiva solicitudes privadas de centos de miles de ordenadores que abandonan accidentalmente o ambiente corporativo usando a designación. corp para o teu dominio en Active Directory.
Fuga de solicitudes WPAD no tráfico estadounidense. A partir dun estudo da Universidade de Michigan de 2016,
Por que aínda non se vende o dominio?
En 2014, os expertos da ICANN publicaron colisións de nomes en DNS. O estudo foi financiado en parte polo Departamento de Seguridade Nacional dos Estados Unidos porque as filtracións de información das redes internas ameazan non só ás empresas comerciais, senón tamén ás organizacións gobernamentais, incluíndo o Servizo Secreto, axencias de intelixencia e ramas militares.
Mike quería vender corp.com o ano pasado, pero o investigador Jeff Schmidt convenceuno para que atrasase a venda en función do informe mencionado anteriormente. O estudo tamén descubriu que 375 ordenadores intentan contactar a corp.com todos os días sen que os seus propietarios o saiban. As solicitudes contiñan intentos de iniciar sesión en intranets corporativas, redes de acceso ou recursos compartidos de ficheiros.
Como parte do seu propio experimento, Schmidt, xunto con JAS Global, imitaron en corp.com a forma en que Windows LAN procesa ficheiros e solicitudes. Ao facelo, de feito, abriron un portal ao inferno para calquera especialista en seguridade da información:
Foi terrible. Paramos o experimento despois de 15 minutos e destruímos [todos os datos obtidos]. Un coñecido probador que aconsellou a JAS neste tema sinalou que o experimento foi como "unha choiva de información confidencial" e que nunca vira nada semellante.
[Configuramos a recepción de correo en corp.com] e despois de aproximadamente unha hora recibimos máis de 12 millóns de correos electrónicos, despois do cal paramos o experimento. Aínda que a gran maioría dos correos electrónicos estaban automatizados, descubrimos que algúns eran sensibles á [seguridade] e, polo tanto, destruímos todo o conxunto de datos sen máis análises.
Schmidt cre que os administradores de todo o mundo levan décadas preparando sen sabelo a botnet máis perigosa da historia. Centos de miles de ordenadores que funcionan en todo o mundo están preparados non só para formar parte dunha botnet, senón tamén para proporcionar datos confidenciais sobre os seus propietarios e empresas. Todo o que tes que facer para aproveitalo é controlar corp.com. Neste caso, calquera máquina que estea unha vez conectada á rede corporativa, cuxo Active Directory foi configurado a través de //corp, pasa a formar parte da botnet.
Microsoft renunciou ao problema hai 25 anos
Se pensas que MS descoñecía dalgunha maneira a bacanal en curso arredor de corp.com, entón estás moi equivocado. Esta é a páxina na que chegaron os usuarios da versión beta de FrontPage ’97, con corp.com listado como URL predeterminado:
Cando Mike se cansou moito disto, corp.com comezou a redirixir aos usuarios ao sitio web da tenda de sexo. En resposta, recibiu miles de cartas de rabia de usuarios, que redirixiu mediante copia a Bill Gates.
Por certo, o propio Mike, por curiosidade, creou un servidor de correo e recibiu cartas confidenciais en corp.com. Intentou resolver estes problemas por si mesmo contactando con empresas, pero simplemente non sabían como corrixir a situación:
Inmediatamente, comecei a recibir correos electrónicos confidenciais, incluíndo versións preliminares de informes financeiros corporativos á Comisión de Bolsa e Valores dos Estados Unidos, informes de recursos humanos e outras cousas de medo. Tentei manter correspondencia con corporacións durante un tempo, pero a maioría delas non sabían que facer con iso. Entón, finalmente acabei de apagalo [o servidor de correo].
MS non tomou ningunha acción activa e a empresa négase a comentar a situación. Si, Microsoft lanzou varias actualizacións de Active Directory ao longo dos anos que abordan parcialmente o problema de colisión de nomes de dominio, pero teñen unha serie de problemas. A empresa tamén produciu recomendacións sobre a configuración de nomes de dominio internos, recomendacións para posuír un dominio de segundo nivel para evitar conflitos e outros titoriais que normalmente non se len.
Pero o máis importante está nas actualizacións. Primeiro: para aplicalos, cómpre deixar completamente a intranet da empresa. Segundo: despois de tales actualizacións, algunhas aplicacións poden comezar a funcionar máis lentamente, de forma incorrecta ou deixar de funcionar por completo. Está claro que a maioría das empresas cunha rede corporativa construída non asumirán tales riscos a curto prazo. Ademais, moitos deles nin sequera se dan conta da escala total da ameaza que está chea de redirección de todo a corp.com cando a máquina é levada fóra da rede interna.
A máxima ironía conséguese ao ver . Así, segundo os seus datos, algunhas solicitudes a corp.com veñen da propia intranet de Microsoft.
E que pasará despois?
Parece que a solución a esta situación está na superficie e foi descrita ao comezo do artigo: deixe que Microsoft lle compre o dominio de Mike e prohíbao para sempre nalgún lugar dun armario remoto.
Pero non é tan sinxelo. Microsoft ofreceulle a O'Connor comprar o seu dominio tóxico para empresas de todo o mundo hai varios anos. Iso é só O xigante ofreceu só 20 mil dólares por pechar tal buraco nas súas propias redes.
Agora o dominio ofrécese por 1,7 millóns de dólares, e aínda que Microsoft decide compralo no último momento, terán tempo?
Só os usuarios rexistrados poden participar na enquisa. , por favor.
Que farías se foses O'Connor?
-
59,6%Deixa que Microsoft compre o dominio por 1,7 millóns de dólares ou que outra persoa o compre.501
-
3,4%Venderíao por 20 mil dólares, non quero pasar á historia como a persoa que filtrou tal dominio a alguén descoñecido.29
-
3,3%Enterraríao eu mesmo para sempre se Microsoft non pode tomar a decisión correcta.28
-
21,2%Venderíalle específicamente o dominio a hackers coa condición de que destrúan a reputación de Microsoft no ámbito corporativo. Coñecen o problema dende 1997!178
-
12,4%Configuraría eu mesmo unha botnet + servidor de correo e comezaría a decidir o destino do mundo.104
Votaron 840 usuarios. 131 usuario abstívose.
Fonte: www.habr.com