Esta semana de forma segura: DNS DDOS, venganza del error de hace 15 años y más

Recientemente, se dio a conocer otra técnica de mejora de DDOS, NXNSAttack (documento técnico aquí), que podría usarse contra servidores DNS.

Anteriormente nos hemos ocupado de los ataques de refuerzo. La breve explicación es que algunos servicios UDP, como DNS, se pueden utilizar incorrectamente para ganar más kilometraje con un ataque DDoS. El maquinista atacante envía mensajes como este: "Hola DNS de Google, este es el servidor de La-Tecnologia. ¿Me pueden enviar un paquete DNS de respuesta realmente grande?" Si la respuesta del DNS es mayor que la solicitud, entonces el ataque general es más grande como resultado. La medida de la eficacia es el factor de refuerzo. Por cada byte de DDoS enviado por las máquinas atacantes, ¿cuántos bytes se envían realmente a la máquina víctima? Mirai, por ejemplo, tenía un factor de fortalecimiento de aproximadamente 2.6.

NXNSAttack tiene un factor de amplificación teórico por byte de 163. Ese no es un punto decimal faltante, este puede ser un problema bastante desagradable.

Para detener el ataque, el villano necesita controlar un servidor de dominio que autorice su propio dominio: evil.com. A continuación, se le solicita a un DNS inocente la dirección IP de una máquina aleatoria en el subdominio malicioso. Debido a que el DNS inocente nunca ha visto el nombre antes, le ruega a la raíz .com servidor para la dirección IP del servidor DNS incorrecto (ns1.evil.com) y luego va a preguntar allí.

Normalmente, el servidor DNS defectuoso respondería con la dirección IP de la máquina en su propio dominio, y la historia terminaría felizmente. Pero aquí el servidor de nombres incorrectos responde con las direcciones de muchos "servidores de nombres" en el dominio de destino, todos inventados simplemente para generar tráfico, y le dice al servidor DNS inocente que vaya a preguntarles:nslgb7vX.sucker.com y nseHOiF.sucker.com y así. Aquí está el refuerzo.

Muchos servidores DNS buscarán la dirección IP para cada "servidor de nombres" que reciben, y lo harán en paralelo, porque en circunstancias normales estas IP se almacenan en caché y pueden escanear un servidor DNS completo de un dominio a la vez y nunca tienen que preguntar. Entonces el DNS inocente le pregunta a la raíz .comservidor para la dirección IP de la autoridad del servidor de destino ns1.sucker.com, donde buscará todas las direcciones IP de los servidores de nombres falsos.

Pero dado que todos los nombres de los servidores de nombres son aleatorios y falsos, el solucionador inocente hace trampa en el martilleo. ns1.sucker.com con solicitudes de la dirección IP de cada uno de estos servidores de nombres falsos. Prácticamente esto multiplica las solicitudes de DNS varias veces: 10-20 veces creíble. El ataque completo utiliza dos etapas de redireccionamientos del servidor de nombres incorrectos para cuadrar esencialmente el número de solicitudes, que es como terminan con un factor de 163 en la práctica. En este escenario, el tráfico de solo unas pocas máquinas maliciosas puede abrumar rápidamente la infraestructura de la víctima.

NXNSAttack se ha revelado de forma privada a un puñado de proveedores de DNS, por lo que ya se encuentran disponibles mitigaciones limitadas. Ejecutar un servidor DNS recursivo ya ha sido una tarea difícil, pero ahora hay una desventaja más a la que prestar atención.

Vulnerabilidad de 15 años finalmente explotada

Algunas vulnerabilidades son obviamente explotables y se corrigen lo antes posible. En otros casos, el código puede ser técnicamente vulnerable, pero de una manera que parece extremadamente improbable que sea prácticamente explotable. Es fácil descartarlos como si no fueran problemas y nunca hacer el trabajo para solucionarlos. Qmail ha tenido un tercio de fallas durante al menos 15 años y sirve como un buen ejemplo de por qué es importante solucionar problemas "inutilizables".

2005 fue la época en la que las máquinas x86-64 se pusieron por primera vez a disposición del público en general. No debería sorprendernos que algunas suposiciones de programación sean seguras de realizar en la plataforma de 32 bits y ya no sean válidas en una máquina de 64 bits. Qmail se escribió asumiendo que una matriz nunca se asignaría para más de 4 GB de memoria, lo cual es seguro en la era de los 32 bits. Se informó y rechazó CVE-2005-1513,1514 y 1515, ya que se consideraba imposible alcanzar el límite de 4 GB en cualquier implementación predeterminada o prudente.

Avance rápido hasta el 19 de mayo de 2020 y finalmente se encontró una forma de explotar estos errores. El código vulnerable también se utiliza en el qmail-local un servicio que por defecto no está limitado a una cierta cantidad de memoria. Un correo electrónico de 4 GB especialmente diseñado puede desencadenar el desbordamiento de enteros y provocar la ejecución remota de código. Hay muchos detalles jugosos en la entrada completa, así que échale un vistazo para obtener más información.

300.000 dispositivos QNAP vulnerables

QNAP produce un dispositivo NAS bastante popular entre los usuarios. Superando el almacenamiento de archivos simple, estos dispositivos QNAP tienen características como un organizador de fotos integrado, reproductor de música, etc. [Henry Huang] descubrió tres vulnerabilidades distintas que se pueden encadenar para obtener un shell de Internet raíz. Entonces, primero, cualquier usuario de QNAP, ¡busque actualizaciones!

Ahora que está actualizado, echemos un vistazo a la cadena de explotación. Primero, se puede acceder a una API remota diseñada para interactuar con álbumes de muestra sin autenticación. El atacante puede crear un álbum de muestra y devolver una ID de álbum. La información de ID de muestra creada se utiliza para crear una solicitud que pueda leer cualquier archivo en el sistema de archivos, incluso si los nombres de archivo no tratados contienen "../../”Personajes de estilo. Se utiliza para leer el signo de inicio de sesión de una aplicación.

Este token se usa para iniciar sesión y otro par de vulnerabilidades permite a un atacante colocar código PHP en el directorio en línea. Todo lo que queda es acceder a la nueva página en un navegador y se ejecuta el código PHP inyectado. Debido a que el servidor web en estos dispositivos actúa como raíz, inyectar un shell remoto significa un compromiso total del dispositivo.

¿El desafío del millón de dólares?

La red social Houseparty, dirigida por Epic Games, ha puesto un desafío en Twitter: dar pruebas de una mala campaña en temas de seguridad en Houseparty, y pagarían un millón de dólares.

Estamos investigando indicios de que los recientes rumores de piratería se difundieron mediante una campaña de daños comerciales pagada para dañar Houseparty. Estamos ofreciendo un premio de $ 1,000,000 para la primera persona que proporcione prueba de dicha campaña a [email protected]

- Domfesto (@domfesto) 31 de marzo de 2020

Esa oferta llamó la atención de [Zach Edwards], quien comenzó a investigar la seguridad de Houseparty. Lo que encontró no fue hermoso. La página de inicio de sesión no utiliza ninguna Política de seguridad de contenido (CSP). Entre otras cosas, esto significa que podría estar incrustado en una página de phishing.

[Zach] Continuó investigando y descubrió una serie de subdominios "thehousepartyapp.com" secuestrados. Parece haber una campaña compleja sobre el fraude con tarjetas de crédito utilizando estos subdominios. Toda la historia es compleja y probablemente hay más en la historia. Desafortunadamente, parece que Epic Games no se está tomando el descubrimiento tan en serio como cabría esperar.

Probabilidades

La herramienta TrendMicro Rootkit Remover instala el controlador del módulo común TrendMicro. [Bill Demirkapi], que solo tiene 18 años, decidió buscar y descubrió algunas cosas extrañas. Entre ellos, este controlador detecta cuando está siendo inspeccionado por una herramienta como Driver Verifier y hace trampas para pasar la prueba WHQL. Para poner una cereza en su investigación, [Bill] describe un sistema raíz que secuestra el controlador TrendMicro.

Las supercomputadoras son aparentemente la próxima limitación del malware. Muchas máquinas se han visto comprometidas por lo que parece ser una campaña bastante compleja, una que deliberadamente lucha muy duro para limpiar la evidencia de sus actividades. No está claro cuál es exactamente el propósito de los ataques, pero es una conclusión razonable que, tan caras como las supercomputadoras modernas, los productos que ofrecen también podrían ser muy valiosos, en algunas situaciones. Como bono especial, el artículo evoca la similitud de esta situación con “El huevo de cuco” y el favorito de todos, Clifford Stoll. (Ofrezco una bebida Klein Bottle por cada mención de Stoll, que parece ser el chico favorito de todos).

Y, por último, aunque el escaneo de puertos no es un delito, es un poco descortés que un sitio web ejecute uno de sus navegadores solo porque lo ha visitado. Ebay es el ejemplo dado y, curiosamente, el escaneo solo funciona cuando se accede al sitio web desde una máquina con Windows. Se sugiere que el escaneo de puertos tiene como objetivo descubrir visitantes comprometidos.

  • Miseria dice:

    Hm ... No veo el escaneo del puerto cuando visito eBay desde una máquina con Windows. Sin embargo, es interesante. No sabía que existía tal tipo.

    • MG dice:

      Asegúrese de haber cerrado la sesión y vacíe la aplicación de almacenamiento local, ¡ya está!

      • Miseria dice:

        Me di cuenta de esto (es decir, la publicación no se registró en eBay) y me pregunté si me afectaría. Lo intentaré.

        Entonces, ¿cuál es la idea con este escaneo de puertos? Digamos que eBay o un sitio web bancario encontraron algunos puertos VNC o XWindows abiertos, ¿qué harían entonces? ¿Advertir al usuario que hay puertos sospechosos abiertos en su máquina? ¿Para provocar alguna mejora en la seguridad / autenticación de su parte?

        • notmyfault2000 dice:

          Supongo que marcar la cuenta para una verificación más cercana en caso de que puedan verse comprometidas, para permitir tiempos de respuesta más rápidos si la cuenta es secuestrada. Dudo mucho que lo utilicen como único indicador de un problema, sino más bien para ayudar a reducir el alcance de su seguimiento. Si termina siendo un falso positivo, todo lo que ha sucedido es eBay o el banco pierde el tiempo mirando una cuenta normal.

  • MG dice:

    Re: escaneo de puertos, me pregunto si Adblock es una forma sensata de responder a eso (como individuo).

    localhost / $ websocket, dominio = ~ localhost
    /(127.d+.d+.d+)/$websocket,domain=~127.0.0.1

  • Neil dice:

    ¿Cuál es el caso de uso para esto?

    var s = nuevo sitio web ("ws: //127.0.0.1: 8080")

    ..no someterse a la política de pares?

    • Jonathan Bennett dice:

      El escaneo de puertos se realizó a través de pruebas en el sitio. Intente abrir una extensión a 8080 en el host local, y cuánto tiempo tomará ese intento de conexión para fallar. Una falla inmediata implica un puerto a prueba de fuego, una falla rápida implica un servicio de escucha y una falla lenta implica que no hay servicio de escucha.

  • Gregg Eshelman dice:

    Para un NAS de QNAP antiguo, vea si hay alguna distracción para Linux. Tengo un TS-209 que ejecutará Debian 9 si alguna vez lo soluciono.

  • js dice:

    Recientemente me prohibieron acceder al sitio web de una empresa china; Me pregunto si se relacionaría con el hecho de que tendré puertos abiertos.

Miguel Vidal
Miguel Vidal

Deja una respuesta

Tu dirección de correo electrónico no será publicada.