Mi nombre es Rob Stackle, soy consultor de seguridad de Phoenix, Arizona, y trabajo principalmente como pentester. He estado participando en las conferencias de DefCon desde 1996, soy aficionado a la fotografía a gran altitud, y este fin de semana fue el undécimo aniversario de nuestra boda. Quiero agradecer a mi increíble y comprensiva esposa Linda, que no esperaba que mi participación en DefCon significara que cada año me vería obligado a celebrar nuestro aniversario de bodas en Las Vegas, lo cual lo lamento mucho.
Voy a hablar con usted sobre varias cosas relacionadas con la investigación en las que he estado trabajando durante los últimos años. Están unidos por un tema común: si no controla su tráfico DNS y no comprende lo que sucede allí, cuando todo está en orden, entonces probablemente no prestará atención cuando empiecen a suceder cosas malas. "Violé" el DNS durante varios años y este siempre ha sido uno de mis vectores de ataque favoritos. Puede gastar una fortuna en fortalecer el perímetro de la red, pero si puedo obtener el control de uno de sus dispositivos, créame, su juego ha terminado.
La ausencia de vulnerabilidades en el mercado para detectar configuraciones incorrectas siempre me da la oportunidad de "poner mi pie en la puerta". Hoy discutiremos varios temas en los que hablaré sobre mis aventuras con DNS y mis trucos sobre personas relacionadas con DNS.
Estos temas están dedicados a malinterpretar el comportamiento del DNS por parte de los usuarios finales de la red, hablaré un poco sobre las personas que no han registrado sus dominios y sobre el pirateo de dominios.
En las conferencias de Black Hat y DefCon en 2011, Artyom Daineberg habló sobre lo que llamó ponerse en cuclillas, o "dar la vuelta". Aquellos que no estén familiarizados con este estudio, pero que estén interesados en este problema en el DNS de dominios populares, pueden descargar los materiales de su presentación utilizando los enlaces provistos en esta diapositiva.
Página del proyecto /
Presentación en video /
DiapositivasCuando leí el anuncio de su discurso, publicado incluso antes del informe sobre Black Hat, inmediatamente me interesé en cómo se puede usar para mis propios fines. Sin entrar en detalles, explicaré qué es la posición en cuclillas, por qué sucede y qué afecta. Le mostraré algunos ejemplos del riesgo de voltear accidentalmente un poco en la memoria cuando 1 se convierte en 0 y viceversa. Las siguientes diapositivas muestran cómo se ve esto como un ejemplo de una línea en la memoria que muestra un nombre de dominio.
En el medio de dicha línea, la unidad se convierte en cero. Artyom investigó el fenómeno en el que un error de un solo bit en la parte correcta de la memoria en el momento correcto obligó al cliente a solicitar un nombre de dominio completamente legítimo pero incorrecto.
Se habló mucho sobre la probabilidad y las causas de tal error, pero comencé a estudiar todas las formas que permiten que este error se use con fines maliciosos. Por lo tanto, la ocupación de DNS le permite distorsionar los nombres de dominio, luego registrar estos dominios "incorrectos" y enviarles las solicitudes de los usuarios.
La siguiente diapositiva muestra que, como resultado de una posición en cuclillas de bits del nombre de dominio de Google, cuando un protón de alta energía en la memoria "golpea" 1, lo que significa la letra g, lo convierte en 0, lo que significa la letra f, y como resultado, el usuario es redirigido a goofle.com .
Por lo tanto, su navegador lo redirigirá completamente a otro sitio y con gusto recogerá la respuesta por usted. Al mismo tiempo, DNS SEC no podrá ayudarlo de ninguna manera y, de hecho, hay muy pocas oportunidades para evitar este error de una manera completamente invisible, excepto por el uso de la memoria ECC, que reconoce y corrige automáticamente los errores de bits.
Sin embargo, este tipo de memoria no es muy común, e incluso si usó ECC, todavía hay muchos lugares en los que puede producirse la ocupación de bits y donde la memoria ECC nunca se usa, por ejemplo, en una tarjeta de red o en la memoria caché DRAM de un disco duro.
Deineberg describió en detalle las causas del problema, pero en general se puede decir que ocurren errores de memoria, algunas veces dañan la memoria y otras tienen un efecto en el DNS. Básicamente, el "giro" de un bit se debe a daños físicos en la memoria, sobrecalentamiento, problemas eléctricos, exposición a la radiación e incluso radiación cósmica.
La presentación se ve interrumpida por la aparición en el escenario de los organizadores de la DefCon, que felicitan al orador y a su esposa Linda, quien está presente en la conferencia por primera vez, en el undécimo aniversario de bodas. Robert les agradece las felicitaciones y continúa la presentación.
La radiación cósmica es un factor extremadamente raro que afecta la sentadilla de bits, pero el sobrecalentamiento es una causa muy común de errores de memoria. Noté que los teléfonos inteligentes son especialmente vulnerables debido a las condiciones de funcionamiento extremas a las que están expuestos. El sobrecalentamiento de la batería del teléfono inteligente es una ocurrencia bastante común. La mayoría de los otros dispositivos tienen refrigeración, pero incluso logran crear condiciones de operación difíciles.
No hace mucho tiempo, Google publicó información sobre el trabajo de sus centros de datos. Una de las cosas interesantes que aprendí fue el mensaje de que, para ahorrar energía, operan sus centros de datos en condiciones que la mayoría de nosotros consideraríamos irrazonables. Si los centros de datos típicos funcionan a una temperatura máxima de 60-70 grados Fahrenheit (15-20 ° C), los expertos de Google recomiendan que las empresas operen centros de datos a una temperatura de al menos 80 grados (27 ° C) y un centro de datos belga Google operaba sus servidores a una temperatura de 95 grados (35 ° C).
Leyenda: "Escuché que nos ahorra dinero".
Intel y Microsoft afirman que sus servidores se comportan bien a altas temperaturas, y Dell garantiza que sus servidores funcionarán a 115 grados Fahrenheit (46 ° C). Creo que es una mala idea, ya que la temperatura es el factor principal para garantizar un funcionamiento estable de la memoria, y los centros de datos de Google funcionan a temperaturas de "fuego".
Comencé a estudiar qué ventajas podría ofrecer esto y qué dominios eran más vulnerables a la posición en cuclillas de bits, es decir, intenté encontrar los nombres solicitados con mayor frecuencia para aumentar la probabilidad de encontrar tales errores. Comencé a recopilar registros de DNS de grandes empresas para encontrar los nombres de dominio más comunes y descubrí que el nombre más solicitado era gstatic.com. Este es uno de los dominios que Google sirve para proporcionar información estática como CSS, imágenes, JavaScript y archivos XML.
Escribí un script para identificar posibles "trastornos" de bits en este nombre de dominio de gstatic.com, y obtuve una lista de todas las variaciones de este nombre en la cantidad de 34 piezas. Cinco de ellos fueron utilizados con fines legales, los 29 restantes estaban disponibles, así que los compré todos.
Inmediatamente golpeé el objetivo. Alguien estaba buscando imágenes en Google y el contenido de la solicitud les regresó dañado de alguna manera, porque su navegador me pidió que sirviera una de las imágenes en la solicitud. Veo su dirección IP, el nombre distorsionado que solicitaron, el recurso que intentaron recuperar utilizando esta imagen, la página relacionada con este contenido y el cliente que se utilizó como navegador para enviar esta solicitud.
En la página puede ver un artefacto interesante en forma de solicitud de un nombre específico Trisha Jones.
Además, el número de solicitudes creció, aparecieron más nombres distorsionados, más solicitudes de imágenes y más enlaces a la solicitud original, como resultado de lo cual recolecté más de 50,000 solicitudes únicas, y resultó que esto era algo común.
La diapositiva muestra una solicitud de una imagen "fotografiada" de la actriz Selena Gómez, lo que provoca risas en el pasillo.
Por lo tanto, a veces, las sentadillas vencidas se producen justo en el momento adecuado para satisfacer una de sus solicitudes, y si esto no sucede con demasiada frecuencia, no tiene que preocuparse. Pero a veces esto sucede en el mismo momento en que hay un guardado en el disco duro, que ya es más interesante. Hay posibilidades de que se produzca una sentadilla de bits en condiciones normales de funcionamiento de la memoria, pero es muy probable que esto ocurra principalmente en centros de datos con una temperatura de 95 grados.
Ahora mis registros están llenos de todo ruido, recibo solicitudes distorsionadas todos los días en tal cantidad que no puedo verlas manualmente.
Por lo tanto, escribo scripts en un intento de encontrar los mismos patrones de consulta, y lo más grande que obtuve fue muchas consultas de la misma imagen para el mismo nombre de dominio distorsionado, y todas provenían de teléfonos móviles. Recibí estas solicitudes cada pocos segundos, ya que todos estos teléfonos intentaron usar la página de búsqueda del sitio web de Google y me pidieron que les proporcionara una pequeña imagen del logotipo de la página original.
Encontré un servidor web de toda la nube de Google que ofrecía contenido y distorsionaba constantemente el nombre de dominio, señalando a uno de mis servidores, donde el logotipo con ese nombre era accidental, y los clientes lo tomaron.
La diapositiva muestra cómo el logotipo de la página de búsqueda de Google en la pantalla de un dispositivo móvil se reemplaza por el logotipo de Ocupar, lo que provoca una risa apreciativa en el pasillo.Durante dos años, cientos de miles de solicitudes de este logotipo llegaron a este servidor con un nombre DNS distorsionado, en lugar del que Google planeaba usar. Entonces, un día se detuvieron, ya que Google se negó a cambiar el contenido de los sitios móviles, y este pedido fue cancelado.
Entonces, continué estudiando patrones de consulta e intenté descubrir otros patrones. Uno de ellos apareció regularmente y se llevó a cabo obviamente de forma natural al "voltear un poco" en la memoria, y no como resultado de un error de cuclillas de bits guardado.
Recibí las solicitudes que se muestran en la siguiente diapositiva con una frecuencia de una por hora. No parecían familiares, todos usaban el cliente Google Feedfetcher, todos provenían de dispositivos en la misma red y todas las solicitudes estaban relacionadas con archivos XML. Así que rebusqué un poco y descubrí que Feedfetcher era el mecanismo que utiliza Google para capturar contenido actualizado para iGoogle, y las direcciones IP de origen se encontraban en Bélgica.
Estas solicitudes se refieren a los propios servidores de Google, que se utilizan para recibir contenido actualizado para varios widgets que personalizan la página de inicio de iGoogle, un portal personal de Internet.
Cada widget es un archivo XML que define el contenido, y Google me pidió que proporcionara este contenido a mis servidores de presentación (aplausos y risas de la audiencia).
Por lo tanto, pensé que si Google accidentalmente quería contenido mío que pudiera proporcionar a sus usuarios, entonces lo recibirá. Tomé los archivos XML que Google me preguntó y los dividí en partes. Como puede ver, hay dos secciones: un encabezado que describe el módulo y un bloque C de datos empaquetados en el código HTML CSS y JavaScript que forman el widget.
Así que simplemente cambié el enlace a la imagen de fondo, cambié la dirección de gstatic.com a grtatic.com, y dejé el resto sin cambios, puse los archivos XML en la línea de donde Feedfetcher los obtuvo, y esperé un poco.
Casi inmediatamente después de eso, Feedfetcher me pidió archivos XML, después de lo cual comencé a recibir solicitudes de muchas direcciones IP de Google para esta imagen de fondo.
Por lo tanto, eliminé los archivos XML modificados por mí y esperé hasta que se detuvieron las solicitudes, pero durante 35 días consecutivos, 61 dispositivos me preguntaban sobre esta imagen todos los días. Y más interesante, cada uno de estos dispositivos era un cliente de Virgin Media en el Reino Unido.
Entonces, este archivo XML de Google sirvió a 61 personas, y durante el año pasado, 500 IPs únicas de Feedfetcher me han pedido que brinde estos módulos 15,000 veces. Entonces podría proporcionar a mis usuarios algo más dañino que simplemente reemplazar la imagen de fondo.
Aquí hay algunos trucos más que puedes hacer con Google. Si no lo sabe, Postini es el reciente servicio de correo electrónico de protección contra correo no deseado, seguridad web y archivo de correo electrónico de Google.
Este servicio le permite cambiar su DNS para indicar su registro MX en su dominio y crear su dominio cambiando los 4 caracteres MX antes de psmtp.com. Lo más interesante aquí es que el dominio es tan corto que puede registrar fácilmente todas las versiones posibles del nombre con los bits "invertidos". Otro punto interesante es que muchas compañías indican sus registros MX para un solo dominio y nadie pensó que fuera una mala idea.
Por lo tanto, registré solo tres bits posibles para este dominio, y el empleo de psmtp.com resultó ser tan grande que las siguientes 4 diapositivas muestran las solicitudes que recibí en solo un mes.
Entonces, si usa el correo de Postini, su solicitud llegará en algún momento a mi servidor. No creo que nadie pueda decir que Google no se toma en serio la seguridad de Internet. Pero si alguien se preguntara a qué problemas podría conducir un sobrecalentamiento que causa errores de memoria, podría plantear la cuestión de considerar la posibilidad de una compensación por tales cosas. Por lo tanto, no permita que sus nombres de dominio sean tan cortos, ya que afecta negativamente a su negocio, como Postini, especialmente si su dominio es popular.
Recomiendo encarecidamente que las personas apliquen una política interna de administración de nombres de dominio que les permita corregir errores de distorsión de nombres y comprender claramente cómo pueden afectarlo. Si tiene gstatic.com y un centro de datos que funciona a una temperatura de 95 grados, es probable que desee asegurarse de que cualquier error de okupación no permita que el cliente acceda a una red externa maliciosa.
Por cierto, entre todos los dominios que investigé, la única compañía que registró todas las posibles distorsiones de mi propio nombre fue Yahoo.
En la siguiente parte de la presentación, voy a demostrar el comportamiento del DNS, que muchas personas, como resultado, no entienden completamente.
Honestamente, Microsoft hizo un trabajo de documentación muy pobre, especialmente porque el comportamiento del DNS a menudo cambia. Esto lleva a un malentendido de lo que está sucediendo por parte de los usuarios finales, especialmente porque dicho comportamiento es a menudo contradictorio.
Por lo tanto, comenzaré con el hecho de que todos deben entender cómo deben comportarse los dispositivos al consultar DNS y qué esperar de ellos. Luego explicaré cómo este comportamiento se vuelve impredecible al usar las rutas de búsqueda de sufijos DNS, cómo la documentación insuficiente afecta todo esto, y terminaré con una breve descripción de las lecciones que se pueden aprender de todo esto. Pero primero, demostraré lo peligroso que puede ser para un usuario final entender mal lo que está sucediendo con DNS.
Entonces, después de escribir
www.google.com en la barra de direcciones de su navegador, su computadora envía una solicitud al servidor DNS local, y el trabajo de encontrar lo que necesita, devolver la solicitud y responder ahora se le asigna. El servidor local llama al servidor raíz para acceder al servidor .com, y el servidor raíz lo envía al servidor .com. Comprueba si el servidor local está autorizado para solicitudes a google.com y lo envía al servidor ns.google.com. Finalmente, el servidor local recibe una respuesta con la dirección IP del recurso que necesita y se la envía.
Este es el comportamiento DNS normal que todos esperan de él. Todos piensan que es suficiente simplemente enviar una solicitud desde el dispositivo a su servidor DNS local para que haga todo el trabajo duro, y luego obtener una respuesta a su solicitud. Pero no todos imaginan que este proceso consta de muchos pasos importantes.
Por ejemplo, su dispositivo está tratando de encontrar la respuesta en
www.google.com , pero todo el proceso, que nos llevó hasta 8 diapositivas, solo ocurrirá si escribe exactamente esa dirección en la barra de consultas del navegador:
www.google .com . Este es el nombre de dominio completo que está asociado con el DNS raíz. Muchas personas creen que el nombre de dominio completo termina con un punto, lo cual no es cierto. Todavía se supone la presencia de un punto al final del nombre completo, y debido a esto, se producen problemas. Intentemos imprimir 4 variaciones del nombre:
www.google.comgoogle.com
www
www.google.comcada uno de los cuales se comporta de manera diferente con respecto al comportamiento de DNS. Todo esto es personalizable, pero generalmente nadie lo hace.
Veamos lo que realmente sucede en tales situaciones. Hay varios factores que influyen en la toma de decisiones del cliente antes de que decidan enviar una consulta DNS. Dos de estos son rutas de búsqueda de sufijos y devolución de DNS.
Ambos tienen muchos parámetros personalizables que afectan su comportamiento y se comportan de manera diferente en diferentes versiones de Windows y en diferentes paquetes de servicio.
Así es como la mayoría de la gente usará el sufijo de ruta de búsqueda. Si su empresa se llama foo y es el propietario del dominio foo.com, y el nombre del directorio activo es ad.foo.com, puede usar el sufijo de las rutas de búsqueda ad.foo.com o foo.com y "insertarlo" en la parte del cliente del ensamblaje del sistema o en política de grupo.
Si uno de sus clientes intenta resolver el nombre corto www, el comportamiento predeterminado de Windows XP será así. Primero enviará una consulta DNS a lo largo de la ruta
www.ad.foo.com , luego a lo largo de la ruta
www.foo.com y al final seguirá una consulta NetBIOS, solo 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) 10GB DDR4 240GB SSD 1Gbps hasta diciembre de forma gratuita al pagar por un período de seis meses, puede ordenar
aquí .
Dell R730xd 2 ? 2 Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 $249 ! . c Dell R730xd 5-2650 v4 9000 ?