Singularity of Origin es una herramienta para realizar ataques de re encuadernación de DNS . Incluye los componentes necesarios para volver a vincular la dirección IP del nombre DNS del servidor de ataque a la dirección IP de la máquina de destino y para servir las cargas útiles de ataque para explotar software vulnerable en la máquina de destino.

También se envía con cargas útiles de muestra para explotar varias versiones de software vulnerables, desde la simple captura de una página de inicio hasta la ejecución remota de código. Su objetivo es proporcionar un marco que facilite la explotación de software vulnerable a los ataques de re encuadernación de DNS y aumentar la conciencia sobre cómo funcionan y cómo protegerse de ellos.

 

¿Cómo funcionan los ataques de recuperación de DNS?

La renovación de DNS cambia la dirección IP de un nombre de máquina controlado por un atacante a la dirección IP de una aplicación de destino, omitiendo la política del  mismo origen  y permitiendo que el navegador realice solicitudes arbitrarias a la aplicación de destino y lea sus respuestas. El servidor DNS Singularity responde con registros de tiempo de vida corto (TTL), lo que minimiza el tiempo en que se almacena en caché la respuesta. Cuando la víctima navega a la interfaz del administrador de Singularity, el servidor DNS de Singularity responde primero con la dirección IP de Singularity donde se aloja el código del lado del cliente (carga útil). Cuando se agota el tiempo de espera del registro de DNS, el servidor DNS Singularity responde con la dirección IP del host de destino (por ejemplo, 127.0.0.1) y el navegador de la víctima puede acceder a la aplicación de destino, evitando la política del mismo origen del navegador.

También es posible activar el enlace de DNS antes de que caduque un registro de DNS en caché, dependiendo de la plataforma de destino y utilizando una combinación de técnicas que se describen en secciones posteriores.

 

Características

  • Singularity proporciona una pila completa de entrega de ataques de re enlace DNS:
    • Servidor DNS personalizado para volver a vincular el nombre DNS y la asignación de direcciones IP de la dirección del servidor web del atacante a la dirección de la máquina de destino
    • Servidor HTTP para servir páginas HTML y código JavaScript para objetivos y para administrar los ataques
    • Varias cargas útiles de ataque de muestra, que van desde la captura de la página de inicio de una aplicación de destino hasta la ejecución remota de código. Estas cargas útiles se pueden adaptar fácilmente para realizar ataques nuevos y personalizados.
  • Soporta usuarios concurrentes
  • Proporciona varias estrategias de re encuadernación de DNS, incluida la asignación secuencial del atacante a la dirección IP de destino y la asignación aleatoria, para minimizar el impacto de la interferencia de IDS / IPS con el ataque
  • Una serie de controles técnicos para maximizar la fiabilidad y la velocidad de los ataques:
    • Desactivación de HTTP mantener vivo, almacenamiento en caché, búsqueda previa de DNS
    • Respuesta de DNS agresiva TTLs
    • Opción de usar DNS CNAME en lugar de registros A para evadir varias soluciones de filtrado de DNS
    • Re conexión casi instantánea para varias combinaciones de navegador y sistema operativo, utilizando múltiples respuestas de DNS y bloqueo dinámico de puerto HTTP.
  • Capacidad para asignar servidores HTTP al inicio o dinámicamente a partir de entonces
    • Una característica conveniente para evitar reiniciar Singularity para escuchar en un puerto HTTP diferente.
    • Para sentar las bases para atacar los puertos vulnerables descubiertos después de un escaneo.

 

Requerimientos

  • Un nombre de dominio DNS de un registrador de dominios como  gandi  o  namecheap . Debe poder agregar y editar sus propios registros DNS para su dominio.
  • Una instancia de servidor Linux de un proveedor de alojamiento como  Linode ,  Amazon AWS ,  Google Cloud ,  Microsoft Azure,  etc.

 

Descripción de las cargas útiles

Singularity soporta las siguientes cargas útiles de ataque:

  • Solicitud de recuperación básica  ( payload-simple-fetch-get.html): esta carga útil de ejemplo realiza una solicitud GET al directorio raíz (‘/’) y muestra la respuesta del servidor utilizando la  fetch API. El objetivo de esta carga útil es funcionar como solicitud de ejemplo para hacer contribuciones adicionales lo más fácil posible.
  • Solicitud básica de XHR  ( payload-simple-xhr-get.html): Otra carga útil de muestra para realizar una solicitud GET al directorio raíz (‘/’) y mostrar la respuesta del servidor utilizando  XMLHttpRequest (XHR).
  • Chrome DevTools  ( payload-exposed-chrome-devtools.html): esta carga útil demuestra una vulnerabilidad de ejecución remota de código (RCE) en Microsoft VS Code corregida en la versión 1.19.3. Esta carga útil puede adaptarse para explotar cualquier software que exponga las Herramientas de desarrollo de Chrome  localhost.
  • etcd  ( payload-etcd.html): esta carga útil recupera las claves y los valores del  almacén  de valor-clave de etcd .
  • pyethapp  ( payload-pyethapp.html): Aproveche la implementación de Python en Pyethapp del cliente de Ethereum   para obtener la lista de direcciones de ets poseídas y recuperar el saldo de la primera dirección de etn.
  • Rails Web Console  ( payload-rails-webconsole.html): realiza un ataque de ejecución remota de código (RCE) en la  consola web de Rails .

 

Creación de sus propias cargas útiles

Crear sus propias cargas útiles es tan simple como copiar el archivo HTML de carga útil de muestra ( payload-simple-fetch-get.html) y modificarlo de acuerdo con sus necesidades. La carga útil de muestra realiza una única solicitud GET y muestra la respuesta. Comience copiando el contenido de este archivo en un .html archivo nuevo  y agregue su nombre a la  attackPayloads lista en el  manager-config.jsonarchivo. Luego modifique el nuevo archivo HTML para cambiar la URL de solicitud, por ejemplo.

 

Prevenir los ataques de rebinding de DNS

Los ataques de re encuadernación de DNS se pueden evitar mediante la validación del encabezado HTTP «Host» en el lado del servidor para permitir solo un conjunto de valores incluidos en la lista blanca. Para los servicios que se escuchan en la interfaz de bucle de retorno, este conjunto de valores de host incluidos en la lista blanca solo debe contener localhost y todas las direcciones numéricas reservadas para la interfaz de bucle de retorno, incluida 127.0.0.1.

Por ejemplo, digamos que un servicio está escuchando en la dirección 127.0.0.1, puerto TCP 3000. Luego, el servicio debe verificar que todos los valores de encabezado «Host» de la solicitud HTTP contengan estrictamente «127.0.0.1:3000» y / o «localhost: 3000 ”. Si el encabezado del host contiene algo más, entonces la solicitud debe ser denegada.

Dependiendo del modelo de implementación de la aplicación, es posible que tenga que agregar a la lista blanca otras direcciones o direcciones adicionales, como 127.0.0.2, otra dirección numérica reservada para la interfaz de loopback.

Para los servicios expuestos en la red (y para cualquier servicio en general), se debe requerir autenticación para evitar el acceso no autorizado.

El filtrado de respuestas DNS que contengan direcciones privadas, de enlace local o de bucle de retorno, tanto para IPv4 como para IPv6, no debe considerarse como un mecanismo de defensa principal contra los ataques de re enlace del DNS. La singularidad puede pasar por alto algunos filtros en ciertas condiciones, como responder con un registro CNAME de localhost cuando se dirige a una aplicación a través del navegador Google Chrome, por ejemplo.

Fuente: n0where.net

Compartir