Exploits, Vulnerabilidades y Payloads Introducción Práctica
Exploits, Vulnerabilidades y Payloads Introducción Práctica

Exploits, Vulnerabilidades y Payloads: Introducción Práctica

Como evaluadores de penetración, a menudo debemos utilizar explotaciones para demostrar vulnerabilidades a nuestros clientes. Pero, ¿dónde las conseguimos? ¿Cómo las usamos? ¿Y qué debemos tener en cuenta al usarlas? Las explotaciones son pequeños fragmentos de código peligrosos, por lo que una buena dosis de precaución siempre es una práctica recomendable.

Introducción al exploit y payload
Introducción al exploit y payload

Exploit vs. Vulnerabilidad

En la industria de la ciberseguridad, a veces podemos presenciar largos debates sobre qué es exactamente una vulnerabilidad, una explotación (o exploit) o un error de software, y dónde comienza un término y termina el otro.

No compliquemos demasiado las cosas y enfoquémonos en lo esencial.

Los errores de software son donde todo comienza. Son simplemente errores de programación y, por lo general, están muy bien definidos y nombrados. Por supuesto, no tienen que estar solo en el software; también pueden estar en el hardware.

Algunos ejemplos de errores de software son:

  • Desbordamiento de búfer
  • Condición de carrera (race condition)
  • Violación de acceso
  • Bucle infinito
  • División por cero
  • Error de desbordamiento por uno (Off-by-one error)
  • Desreferencia de puntero nulo (Null pointer dereference)
  • Error de validación de entrada
  • Fuga de recursos

Los errores de software pueden llevar a vulnerabilidades. No siempre, pero a veces lo hacen.

Las vulnerabilidades son algo exacto, pero a veces tienen nombres curiosos. Básicamente, son errores de software que pueden aprovecharse para lograr un comportamiento no deseado o no anticipado.

Algunos ejemplos de vulnerabilidades son:

  • BlueKeep
  • Shellshock
  • Dirty COW
  • Heartbleed
  • EternalBlue
  • Inyección SQL
  • Inyección de código
  • Directory traversal (o salto de directorio)
  • XSS, CSRF, SSRF

Y luego está el Riesgo (Amenaza) que puede materializarse si alguien decide aprovechar una vulnerabilidad y explotarla.

Algunos ejemplos de riesgos de seguridad son:

  • Ejecución remota de código
  • Evitación de autenticación
  • Divulgación de información sensible
  • Denegación de servicio
  • Escalada de privilegios
  • Evitación de características de seguridad
  • Toma de control de la sesión del usuario
  • Carga maliciosa de archivos
  • Hombre en el medio (Man-in-the-middle)

Así es como los errores de software, las vulnerabilidades y los riesgos de seguridad se relacionan entre sí:

Error de software vs vulnerabilidad vs riesgo o amenaza
Error de software vs vulnerabilidad vs riesgo o amenaza

Una explotación representaría entonces una verdadera conjunción entre los tres términos, materializando el riesgo en realidad.

En definición, una explotación es un fragmento de código, un programa o unos datos cuidadosamente elaborados que aprovechan una vulnerabilidad para lograr un comportamiento no deseado o no anticipado (materializando el riesgo) en el software que contiene un error.

Local vs. Remoto

Una forma de categorizar las explotaciones en la industria de la ciberseguridad es dividiéndolas en 2 grandes grupos: explotaciones locales y remotas.

Las explotaciones locales son códigos cuyo propósito es explotar una vulnerabilidad localmente en el sistema donde ya tenemos acceso (limitado).

Estas explotaciones son casi siempre de escalada de privilegios, con el objetivo de aumentar nuestros privilegios a un nivel superior (idealmente administrativo/raíz/anillo 0) para tener un control completo sobre los recursos del sistema objetivo.

Las explotaciones remotas son códigos cuyo propósito es explotar una vulnerabilidad en un sistema remoto sin tener acceso previo a él.

Estas explotaciones suelen estar dirigidas contra un servicio de red específico (de una versión vulnerable específica). El objetivo es obtener acceso no autorizado a la información o acceder a los recursos del sistema remoto.

Existen muchos tipos diferentes de explotaciones. Veamos cómo las categoriza la industria de la ciberseguridad.

Tipos de Explotaciones (Exploits)

Esta sección enumera los tipos más comunes de explotaciones con los que podemos encontrarnos en nuestra vida diaria en la ciberseguridad.

Denegación de Servicio (DoS)

El DoS es una explotación que causa la caída de un servicio/sistema.

Durante las pruebas de penetración profesionales, casi nunca hay una razón para usar una explotación DoS.

De hecho, causar una caída o una indisponibilidad de un sistema es un resultado altamente indeseado. Esto puede llevar a un tiempo de inactividad en los negocios y, en consecuencia, a conversaciones muy desagradables con el cliente. Como mínimo.

Pero podría ser mucho peor: podrían incluso haber pérdidas de ingresos, pérdidas de productividad y otras consecuencias financieras por las cuales podríamos ser responsables, nosotros o nuestro empleador. Asegúrate de tener la documentación en regla antes de realizar cualquier prueba de penetración.

En cualquier caso, siempre debemos evitar usar explotaciones DoS. No hay nada que ganar al usarlas de todas formas. A menos que, por supuesto, sea explícitamente deseado y autorizado por el cliente.

Escalada de Privilegios Local (LPE)

Como se mencionó anteriormente, las explotaciones de escalada de privilegios tienen como objetivo explotar vulnerabilidades localmente en el sistema donde ya tenemos acceso (limitado).

El objetivo es obtener privilegios administrativos, típicamente:

  • “Admin del Dominio” en Active Directory
  • “NT Authority\System” en sistemas Windows
  • Usuario “Root” en sistemas UNIX similares

Pero también hay muchas otras formas de escalar privilegios, no solo utilizando explotaciones. Aquí tienes uno de los mejores recursos sobre tácticas de escalada de privilegios:

https://attack.mitre.org/tactics/TA0004

Ejecución Remota de Código (RCE)

Concepto de ejecución remota de código
Concepto de ejecución remota de código

Estas son las explotaciones más populares. Nos permiten ejecutar código arbitrario en el sistema objetivo.

Sin embargo, a veces las explotaciones pueden causar la caída del objetivo.

Un ejemplo sería la infame vulnerabilidad EternalBlue (también conocida como MS17-010). Hay muchas explotaciones MS17-010 y algunas de ellas son de mala calidad, causando la caída del sistema operativo completo.

Por lo tanto, siempre debemos ser cautelosos al usar explotaciones RCE. A veces, los clientes pueden incluso pedirnos que los notifiquemos antes de realizar cualquier explotación activa.

De hecho, es bastante típico en la mayoría de los entornos maduros que el cliente nos pida que nos abstengamos de realizar cualquier explotación sin obtener autorización primero.

Aplicaciones Web (WebApps)

Existe todo un conjunto de explotaciones dirigidas a vulnerabilidades en aplicaciones web y tecnologías web en general.

Estas incluyen vulnerabilidades como:

  • Traversal de directorios
  • Inyección SQL (SQLi)
  • Evitación de autenticación
  • Cross-Site Scripting (XSS)
  • Cross-Site Request Forgery (CSRF)
  • Server-Side Request Forgery (SSRF)
  • Inyección de Entidad Externa XML (XXE)
  • Inclusión de archivos locales/remotos (LFI/RFI)
  • Y muchos más..

A medida que el mundo entero se desplaza hacia las tecnologías web, las explotaciones de aplicaciones web representan, con mucho, la mayor porción de explotaciones publicadas.

Explotaciones del Lado del Cliente

Las explotaciones del lado del cliente suelen explotar vulnerabilidades en aplicaciones cliente como:

  • Visores de PDF
  • Navegadores web
  • Clientes de chat/IM/email
  • Clientes FTP, SSH, DHCP
  • Y muchos más..

Este tipo de explotaciones se utilizan muy raramente durante una prueba de penetración, si es que alguna vez se usan. Por lo tanto, no las cubriremos aquí en detalle.

Solo mencionemos que ni siquiera nuestras herramientas de prueba de penetración, analizadores de paquetes o escáneres se salvan de tener vulnerabilidades (y explotaciones).

Explotaciones de Prueba de Concepto (PoC)

En el mundo de las explotaciones, a menudo podemos encontrarnos con una explotación PoC. ¿Qué es una explotación PoC?

Resulta que puede ser cualquier cosa. Desafortunadamente, la industria de la ciberseguridad no sigue pautas estrictas sobre lo que debe o no debe ser una explotación PoC.

Una explotación PoC podría ser un código de prueba para verificar si existe una vulnerabilidad particular en un sistema dado o no (sin explotarla).

Pero también podría ser una versión “sucia” o “inestable” de una explotación completamente potente.

Nunca lo sabemos. Por lo tanto, siempre debemos tratar las explotaciones PoC como cualquier otra explotación: un “PoC” es simplemente un sinónimo de “explotación”.

¿Dónde Encontrar Exploits?

Las siguientes secciones proporcionan una lista de fuentes generalmente aceptadas y recomendadas de explotaciones.

Exploit Database

Encontrar exploit en Exploit Database
Encontrar exploit en Exploit Database

Exploit Database (https://www.exploit-db.com/) operada y mantenida por Offensive Security es uno de los mejores lugares donde conseguir explotaciones de buena calidad. Es un archivo de explotaciones públicas y avisos de seguridad.

Actualmente, hay más de 46,087 entradas de explotación en su base de datos al momento de escribir este artículo, y el número crece prácticamente todos los días.

También hay una utilidad de línea de comandos llamada searchsploit para acceder al archivo de explotaciones. Esta utilidad está preinstalada en Kali Linux por defecto y también está disponible para otros sistemas.

Aquí tienes un ejemplo de cómo usar la utilidad para buscar explotaciones de JBoss:

searchsploit jboss

Las explotaciones reales se pueden encontrar en el directorio /usr/share/exploitdb/exploits/.

Vulners CVE database

La Base de Datos CVE de Vulners (https://vulners.com/search) es otra gran fuente de exploits.

Agrega una gran cantidad de información de muchas fuentes diferentes, lo que les permite proporcionar detalles prácticamente sobre cualquier vulnerabilidad conocida públicamente.

La base de datos de Vulners incluso indexa información de escáneres de vulnerabilidades como Nessus u OpenVAS, lo que nos permite buscar entre el contenido de sus plugins. Esto puede revelar información muy interesante.

Cada entrada también contiene una sección de referencias con enlaces a los avisos reales y listas de correo. Esto también puede ser una gran fuente de información que posiblemente lleve a un exploit.

Repositorios de exploits en GitHub

También hay numerosos repositorios en GitHub que contienen exploits y códigos de PoC de CVE.

Aquí tienes algunos de los mejores repositorios de exploits:

https://github.com/offensive-security/exploit-database
https://github.com/offensive-security/exploit-database-bin-sploits
https://github.com/qazbnm456/awesome-cve-poc
https://github.com/Mr-xn/Penetration_Testing_POC
https://github.com/Medicean/VulApps
https://github.com/nixawk/labs
https://github.com/Coalfire-Research/java-deserialization-exploits
https://github.com/toolswatch/vFeed
https://github.com/Metnew/uxss-db (Browser vulns)
https://github.com/tunz/js-vuln-db (JavaScript vulns)

Ten en cuenta que estos repositorios deben usarse con la máxima precaución, ya que pueden contener contenido malicioso.

Asegúrate de seguir las pautas de seguridad descritas a continuación en la última parte de este artículo.

Frameworks de Exploits

Los frameworks de exploits son grandes paquetes de software que nos permiten automatizar una variedad de actividades de pruebas de penetración de manera estandarizada y a gran escala. También contienen un gran número de exploits que han sido probados y son seguros de usar.

Aquí tienes algunos de los frameworks de exploits más populares:

El Metasploit Framework es probablemente el más popular y también está preinstalado por defecto en Kali Linux.

Aquí tienes un ejemplo de cómo buscar exploits para ProFTPd en Metasploit:

msfconsole
msf5 > search proftpd

Los frameworks de exploits son extremadamente útiles porque nos permiten encadenar fácilmente la explotación con tareas relacionadas como:

  • Generación de payloads / shellcode
  • Pivoting y movimiento lateral
  • Tareas post-explotación

También contienen varios escáneres y un número de módulos auxiliares útiles para las pruebas de penetración.

Los frameworks de exploits son un tema enorme y hay libros enteros escritos sobre ellos.

NOTA IMPORTANTE: ¡No confundas los frameworks de exploits con los kits de exploits!

Los kits de exploits son herramientas utilizadas por ciberdelincuentes para automatizar ataques en las máquinas de los usuarios finales. Generalmente se utilizan para distribuir malware y ayudar a llevar a cabo actividades ilegales, a menudo relacionadas con el fraude y el robo.

Los kits de exploits pertenecen al ámbito de los virus informáticos y, aunque también contienen exploits, no hay lugar para usarlos durante una prueba de penetración.

¿Qué es un Payload?

Concepto de Payload
Concepto de Payload

Dado que estamos hablando de exploits, tenemos que mencionar los payloads, ya que son una parte inseparable de la mayoría de los exploits. Para entender por qué los exploits tienen payloads, déjame hacerte una pregunta:

¿Qué sucede después de que explotamos un error de software, digamos un desbordamiento de búfer?

Bueno, resulta que ¡lo que queramos! Ahí es donde entran en juego los payloads.

Los payloads básicamente definen una acción que queremos realizar después de explotar una vulnerabilidad. Por ejemplo:

  • Ejecutar un código
  • Generar un shell inverso
  • Crear una puerta trasera
  • Crear un usuario
  • Leer un archivo
  • Lo que queramos

Los payloads generalmente se escriben en forma de shellcode, pero no es una regla. Por ejemplo, los exploits de aplicaciones web tienen payloads en forma de texto.

¿Qué es un Shellcode?

Los shellcodes pertenecen al área de la explotación binaria. Un shellcode es básicamente una forma binaria de un payload, un fragmento de código que define la acción (instrucciones) que queremos ejecutar durante la explotación.

Típicamente, el shellcode se escribe en código máquina apropiado para la arquitectura del procesador objetivo y el sistema operativo. Por ejemplo:

  • x86 / Windows
  • Dalvik / Android

Aunque la codificación de shellcode implica programación, en realidad no necesitamos programar nada: todo está completamente automatizado por frameworks de exploits como Metasploit.

Aquí tienes un ejemplo de la utilidad msfvenom de Metasploit, que puede generar payloads prácticamente en cualquier plataforma y arquitectura imaginable:

msfvenom --list platforms
msfvenom --list archs

Msfvenom puede generar virtualmente cualquier payload que podamos desear, al tiempo que admite varios métodos de ofuscación y codificación.

Es una navaja suiza para la generación de payloads y sus características van más allá del alcance de este artículo.

¿Cómo Saber qué Exploit Usar?

Esto generalmente se reduce a una recopilación exhaustiva de información y a identificar qué versión particular del software se está ejecutando en nuestro objetivo. Una vez que tengamos la información exacta de la versión, podemos proceder a buscar un exploit.

También hay un pequeño truco que podríamos usar.

La utilidad searchsploit descrita anteriormente puede analizar la salida del escáner Nmap y recomendar exploits basados en las versiones detectadas.

Todo lo que tenemos que hacer es escanear nuestro objetivo usando la detección de servicios de Nmap (-sV) y guardar la salida en un archivo XML (-oX). Así:

nmap -sV -oX file.xml <objetivo>

Luego podemos proporcionar la salida file.xml a searchsploit así:

searchsploit --nmap file.xml

¿Cómo usar Exploits de Manera Segura?

Los exploits son peligrosos a priori y su mal manejo puede tener efectos desastrosos.

Debido a su naturaleza aparentemente críptica y oscura, generalmente son difíciles de entender. Y esto crea otro riesgo.

Por ejemplo, sería bastante fácil insertar alguna sorpresa desagradable en el exploit: un código oculto o una puerta trasera.

Por lo tanto, siempre se recomienda una dosis extra de precaución y esta sección proporciona algunos consejos sobre cómo minimizar esos riesgos.

Exploits verificados vs. no verificados

Antes de ejecutar cualquier exploit, deberíamos tener una idea de lo que hace.

No sugiero que debamos entender en detalle cómo funciona exactamente el exploit, pero al menos deberíamos tener algún nivel de certeza de que no hace algo más de lo que dice.

Uno de los indicadores de que un exploit es seguro es buscar la marca ‘EDB Verified’ en la interfaz web de la Exploit Database (https://www.exploit-db.com/):

Cuidado con blobs binarios desconocidos

Debemos ser especialmente cautelosos cuando veamos un blob binario desconocido en un exploit, como en este ejemplo:

¿Por qué está ahí este buffer y qué significa?

A menos que entendamos el lenguaje ensamblador, la ingeniería inversa y el análisis de archivos binarios, no hay mucho que podamos hacer aparte de probar el exploit en un entorno de prueba.

Pero aún podríamos intentar analizarlo utilizando los siguientes trucos.

Ver si hay algún carácter imprimible / ASCII:

echo -en "\x7f\x45\x4c\x46\x01....." | xxd

Ver si coincide con algún tipo de archivo conocido:

echo -en "\x7f\x45\x4c\x46\x01....." | file -s -

Otra forma de encontrar si contiene algún tipo de archivo conocido (también en su interior):

echo -en "\x7f\x45\x4c\x46\x01....." > blob.bin
binwalk blob.bin

Interpretar el blob como código máquina (instrucciones) y leer el código ensamblador:

echo -en "\x7f\x45\x4c\x46\x01....." | ndisasm -u -

Si no estamos seguros, lo mejor es probarlo en un entorno de prueba.

Pautas de Seguridad para Trabajar con Exploits

Aquí tienes una lista de pautas de seguridad fundamentales a tener en cuenta al usar exploits:

  • Asegúrate de utilizar solo fuentes de exploits confiables y reputadas
  • No descargues exploits de foros privados o de personas que no conoces
  • Haz un esfuerzo por probar el exploit antes de ejecutarlo en un objetivo
  • Inspecciona siempre cada exploit en un editor de texto
  • Ten cuidado con las inyecciones de escape de terminal

Conclusión

En este artículo hemos echado un vistazo al mundo de los exploits. Es un mundo grande con muchas cosas complicadas que aprender y conocer. Pero incluso si no somos ninjas binarios, aún deberíamos poder usar exploits de manera cómoda y segura durante nuestras pruebas de penetración.

Esperamos que este artículo haya proporcionado información suficiente sobre dónde conseguirlos, cómo usarlos y cómo minimizar los riesgos asociados con ellos.

Si te gustó este artículo y quieres más, suscríbete a nuestra lista de correo y síguenos en Twitter y Facebook para recibir notificaciones sobre nuevo contenido.

Mi Carro Close (×)

Tu carrito está vacío
Ver tienda