Hola a todos! Hoy nos gustaría hablar sobre un ataque viejo y casi olvidado llamado enlace DNS. La primera charla comenzó en 2007, pero luego los expertos en el campo de la seguridad práctica de la información no le prestaron la debida atención en relación con las peculiaridades del funcionamiento de este ataque, así como con pocas consecuencias tangibles, como parecía entonces. Hoy trataremos de convencerlos de lo contrario, y usted, en particular, demostrando que en el mundo moderno este ataque ha encontrado un segundo viento y ya no parece tan inofensivo.
¿Qué es el enlace DNS?
Considere el siguiente esquema:
Tenemos la computadora de una víctima con IP 192.168.0.2 en la red local, y también tiene un enrutador con la dirección IP 192.168.0.1. El objetivo del atacante que administra el servidor con la dirección 13.37.13.37 y el nombre de dominio hacker.com (también, nuestro propio servidor DNS que contiene información sobre el dominio está girando en el ip-shnik) es obtener acceso al enrutador en la red local.
Para usar la técnica de enlace DNS, debemos atraer a la víctima a nuestro sitio malicioso. Supongamos que lo logramos.
Ahora examinemos en detalle cómo funciona el ataque.
En primer lugar, el navegador accede a los servidores DNS con una solicitud de registro A:
La cadena de servidores DNS conduce a nuestro servidor, que, a su vez, da una respuesta estándar que contiene la verdadera dirección IP del sitio malicioso, y también indica el TTL que necesitamos, en este caso 59.
A continuación, el navegador realiza una solicitud HTTP estándar para la IP recibida.
En la siguiente etapa, el servidor responde con una página HTML con código javascript que accede a nuestro propio dominio.
Ahora, hasta que caduque el TTL y el usuario esté en el sitio, se ejecutará el javascript recibido anteriormente. Una vez que termine el TTL, el navegador solicitará nuevamente un registro A.
En este momento, nuestro javascript continúa ejecutándose, y el servidor DNS que administramos responderá con un registro A con una dirección IP de la red local donde el atacante quiere llegar.
Dado que el dominio, el puerto y el protocolo permanecen sin cambios, SOP no se viola y, como resultado, el navegador accede al dominio pew.hacker.com, sin embargo, ya tocará el codiciado e inalcanzable enrutador.
Como resultado, recibimos con calma una respuesta del enrutador y la redirigimos a nosotros incorporando la funcionalidad correspondiente en el código JavaScript cargado anteriormente.
Entonces, resumamos lo anterior:
- El usuario visita el sitio, recibe una dirección IP real y un TTL corto
- Mientras está en el sitio, el navegador realiza llamadas al mismo dominio donde se encuentra el usuario. Tan pronto como la caché caduca, el navegador vuelve a solicitar la IP del dominio.
- Además, nuestro servidor DNS emite en lugar de la dirección real, la dirección IP del servicio interno (en nuestro caso, el enrutador)
- Después de que la solicitud pasa por el dominio al enrutador, y el javascript precargado por el usuario nos envía el resultado de antemano.
¡Lo descubrimos! Muchos pueden tener una pregunta razonable: "¿Y qué?", Porque para la operación necesita conocer las direcciones IP internas de los servicios, mantener al usuario durante un tiempo determinado, etc.
Sí, sin embargo, con el advenimiento de los servicios de transmisión, alojamiento de videos, buenos sitios antiguos de pornografía y otras plataformas donde las personas permanecen mucho tiempo, el atacante tendrá tiempo suficiente para llevar a cabo el ataque. En cuanto a las direcciones, a menudo son estándar o fácilmente predecibles.
Pero todo esto es en teoría, pero ¿qué pasa en la práctica? Seleccionamos las 4 áreas más relevantes en 2019, donde hubo incidentes relacionados con el ataque de enlace DNS, estos son:
- IoT
- Crypto wallets
- Aplicaciones de escritorio
- Nubes
Miremos cada tema en orden y descubramos si todo es realmente tan inofensivo.
Iot
Google home
Google home es un asistente inteligente de Google. Este dispositivo tiene (o tenía en el pasado) una API que no requiere ninguna autenticación para controlar el dispositivo. Proporciona una serie de características, como:
- Reproducción de contenido
- Escanear
- Reiniciar
- Conexión a redes WIFI, etc.
Ejemplo de escenario de ataque: un atacante puede desanonimizar a un usuario al obtener las coordenadas de los puntos WIFI más cercanos. Obviamente, ninguna VPN puede salvarte.
Sonos altavoces wifi
Estas columnas de Sonos generan un servidor web en la red local UPnP, que da acceso a varias páginas interesantes:
- 192.168.1.76:1400/support/review: escupe la salida de algunos comandos UNIX
- 192.168.1.76:1400/tools: le permite ejecutar algunos comandos UNIX
En este caso, el atacante tiene la capacidad de ejecutar el comando traceroute para escanear la topología de la red interna.
Termostato de radio CT50
Este es uno de nuestros casos favoritos. Este modelo de termostato también tiene una API sin autorización y le permite cambiar:
- Modo climático
- Temperatura
- Modo de luz de fondo y otras configuraciones
Como resultado, un atacante puede sudar mucho a su víctima, pero hablando en serio, tal ataque a un termostato, por ejemplo, en una instalación médica puede tener consecuencias bastante desagradables.
Roku tv
Los televisores Roku todavía tienen la misma dolencia: una API sin autenticación.
La API te permite:
- Ejecuta varias aplicaciones
- Reproducir contenido
- Realizar consultas de búsqueda en el sistema, etc.
En este caso, lo máximo que amenaza al usuario es la pérdida de datos confidenciales, que también es desagradable.
Cualquier enrutador WIFI
Casi todos tienen este dispositivo IoT hoy. No es ningún secreto que muchos usuarios comunes no cambian las contraseñas estándar de los paneles de administración de sus enrutadores. Con la ayuda del enlace DNS, nada nos impide intentar iniciar sesión con credenciales estándar y obtener acceso al panel de administración. Si no se puede encontrar la IP local, WebRTC viene al rescate.
Resumen de IoT
Destacamos algunas de las características que proporciona el enlace DNS cuando se trabaja con IoT:
- Capacidad para desanonimizar al usuario
- Capacidad para escanear una red local
- Usuario simulado
- Cualquier cosa, dependiendo de la funcionalidad del dispositivo IoT
Crypto wallets
Geth
Ahora hablemos de las billeteras de criptomonedas. El primer caso examinado es un cliente para carteras de ethereum llamado Geth. Aquí la caja de Pandora está en el servicio JSON-RPC. Para comenzar, descubramos qué es. JSON-RPC es un protocolo de llamada a procedimiento remoto en formato JSON. Todo se parece a esto:
La mayoría de los clientes ejecutan este servicio en localhost: 8545 y, a su vez, proporciona un conjunto de funciones interesantes, como eth_sendTransaction etc.
Ahora, un ejemplo de cómo puede obtener su saldo y la dirección de la billetera sin el conocimiento del usuario y utilizando el ataque de enlace DNS:
Billetera keosd EOSIO
A continuación tenemos un cliente para billeteras EOSIO. Keosd se inicia en localhost: 8900 y firma automáticamente cualquier acción de la aplicación durante 15 minutos después de ingresar los datos de autorización. Habiendo profundizado en la API, nuevamente puede encontrar funcionalidades interesantes. Para mayor claridad, utilizando la solicitud que se muestra a continuación, puede obtener la clave pública del usuario:
Resumen de billeteras Crypto:
- un atacante puede robar dinero del usuario
- un atacante puede modificar varias configuraciones de usuario
- la capacidad de desanonimizar al usuario
Aplicaciones de escritorio
Cliente de transmisión
Me gustaría comenzar el bloque de incidentes relacionados con las aplicaciones de escritorio con una vulnerabilidad relativamente sensacional en el cliente de transmisión torrent.
Aquí el problema radica en el mismo JSON-RPC, que examinamos un poco más arriba. En este caso, le permite cambiar la configuración del usuario, por ejemplo, cambiar la carpeta para descargar archivos:
Por un lado, parece no ser nada serio, pero si especifica el recurso compartido smb controlado por el atacante en lugar de la carpeta (si el cliente usa el cliente de Windows), puede interceptar el hash del usuario, que puede usarse en el futuro.
Cliente web uTorrent
Este compañero tiene en su arsenal el mismo servicio JSON-RPC que le permite cambiar los archivos de configuración del usuario, así como descargar archivos.
En este caso, se requiere autenticación, pero las credenciales están disponibles en http://localhost:19575/users.conf . ¿Cómo se puede usar esto?
Primero, haga la siguiente solicitud:
Después de recibir el token, cambiamos la carpeta de descarga a la carpeta donde se encuentran los programas que se ejecutan cuando se inicia el sistema:
Y finalmente, le damos el comando para descargar la carga útil necesaria:
Como resultado, evil.exe se lanzará después del próximo reinicio.
Minikube
Minikube es una utilidad de línea de comandos para configurar y ejecutar un clúster Kubernetes de modo único en una máquina virtual en la computadora local.
Siempre se cuelga en 192.168.99.100, y la interfaz basada en web está disponible en el puerto 3000. Como resultado, un atacante tiene la oportunidad de crear un contenedor malicioso con una carpeta compartida con el sistema principal.
En primer lugar, debe obtener el token csrf.
A continuación, debe crear un contenedor y, para ello, enviar la siguiente solicitud:
Veamos que hace. En él, indicamos que al iniciar el contenedor debemos reenviar el shell inverso y también montar la carpeta Usuarios desde el sistema principal:
Ruby on Rails
Hay una gema para el marco de Ruby on Rails que le permite ejecutar el código de Ruby directamente en el navegador.
Tratemos de descubrir qué necesitamos para esto.
Primero tenemos que ir a una página inexistente:
A continuación, intentamos acceder a la consola a través del navegador:
Bueno, finalmente, formulamos una solicitud para iniciar la aplicación de la calculadora (en este ejemplo, el vector para MAC OS X):
Aplicación de escritorio de Blizzard
No solo los desarrolladores y usuarios habituales son susceptibles a un ataque como el enlace DNS, sino también los jugadores. Aquí nuevamente encontramos un problema de servicio JSON-RPC que sobresale en este caso en localhost en el puerto 1120. El servicio permite realizar actualizaciones, cambiar configuraciones y otras opciones de servicio.
En este caso, la autenticación es compatible, pero pasarla haciendo solicitudes desde localhost no es difícil:
Como resultado, puede lograr algo similar:
Más detalles se pueden encontrar aquí .
Resumen de la aplicación de escritorio:
- un atacante puede obtener RCE en el sistema principal (tampoco se olvide de VM Escape)
- un atacante podría obtener acceso a datos confidenciales, etc.
Nubes
Bueno, y finalmente, lo más interesante permanece: las nubes. La conclusión es que los servicios en la nube a menudo se utilizan para alojar software que analiza a los usuarios que visitan el sitio. Por ejemplo, al hacer clic en el enlace del encabezado Referer con un navegador sin cabeza para garabatear el recurso desde el cual el cliente fue al sitio. Este vector de ataque también se puede usar, porque en esencia un navegador sin cabeza es un navegador web completo sin una interfaz gráfica, pero con soporte para DOM, JS y todo lo demás.
Volviendo a nuestros carneros, ¿qué podemos hacer en este caso? De hecho, para un ataque, necesitamos retrasar al usuario (en este caso, el bot) en la página. Bueno, para esto podemos usar una imagen en la página que tiene una longitud de contenido una más de lo que realmente es. Como resultado, el bot pensará que la imagen aún no se ha cargado y permanecerá en nuestra página, y luego usaremos nuestra técnica estándar de enlace DNS.
Como resultado, ya que enviaremos solicitudes desde un proxy, podemos hacer muchas cosas divertidas. Por ejemplo:
- escanear red interna
- iniciar sesión en servicios internos (teóricamente)
- robar datos de autorización de otros servicios, etc.
Vayamos directamente a Amazon. AWS EC2 tiene características como el Servicio de metadatos de instancia. Permite que cualquier entidad EC2 use la API REST ubicada en 169.254.169.254, que revela información sobre la instancia.
Por ejemplo, aquí hay una breve lista de servicios similares para varias nubes:
Ahora veamos un caso en el que nos entregamos a AWS.
Primero, deje que el bot haga una solicitud a la API:
En la respuesta, podemos obtener información confidencial, por ejemplo, créditos en un script que se ejecuta cuando se inicia la máquina:
A continuación, podemos extraer el nombre del nodo con el que continuaremos trabajando:
A continuación, haremos la siguiente apelación por el nombre ya conocido y ¡bingo!
Recibimos diversa información del usuario, como AccessKeyId, SecretAccessKey, Token, etc.
Una vez recibidos estos datos, podemos usarlos para la autorización a través del cliente de la consola:
El resultado total:
Destaquemos los puntos débiles comunes que notamos cuando usamos un ataque de enlace DNS:
- API sin autenticación
- Servicios locales sin autenticación.
- Ignorando el parámetro Host para solicitar
- Usando http en lugar de https
Por lo tanto, a pesar de varios argumentos de expertos en el campo de la seguridad práctica de la información, un ataque de este tipo nace de nuevo en la era de IoT, servicios en la nube, criptomonedas, etc., incluso a pesar de la necesidad de retrasar al cliente del lado del atacante, porque en el mundo de los cines en línea, Hosting de video y otros servicios que proporcionan contenido al usuario, no es difícil hacer esto. Por lo tanto, tenga cuidado al viajar en el mundo en línea, al comprar otro asistente inteligente y al desarrollar, por supuesto.
Fuentes: