Incluye larga lista de herramientas de seguridad listas para usar, entre las que destacan numerosos scanners de puertos y vulnerabilidades, archivos de exploits, sniffers, herramientas de análisis forense y herramientas para la auditoría Wireless.
Fue incluida en la famosa lista Top 100 Network Security Tools del 2006 disponible en SecTools.Org
Web Oficial de BackTrack

Lista de herramientas incluídas en BackTrack

El proceso de instalación o puesta en marcha de este LiveCD es un tema que ya ha sido cubierto en diferentes ocasiones en Labs DragonJAR. Veamos algunos enlaces de como llevar a cabo este procedimiento:

Ejecución / Instalación de BackTrack

BackTrack Portable

Instalar Back | Track en el HD de tú PC

Instalar BackTrack en una llave USB

Review BackTrack

Como Instalar Back|Track 3

1. Imágen ISO / LiveCD USB / Appliance de BackTrack
2. Software de virtualización (VMWare WorkStation, VMWare Player, Qemu, Virtual BOX, MOKA5, etc.)
3. PC de mediana capacidad.
4. Conexión a internet (algunos ejercicios, referencias)

Contenido temático:

1. Conceptos básicos de BackTrack
2. Servicios básicos (DHCP, IP, Apache, SSHD, Tftp, VNC)
3. Entorno básico Bash
4. NetCat
5. Wireshark
6. Nmap
7. Técnicas de recolección de información
8. Recursos Web
9. Reconocimiento DNS
10. Reconocimiento SNMP
11. Reconocimiento SMTP
12. Recolección de información Microsoft Netbios
13. Escaneo de puertos
14. ARP Spoofing
15. Explotación de Buffer overflow en Windows
16. Fuzzing
17. Trabajando con Exploits
18. Transferencia de archivos
19. Frameworks de explotación
20. Ataques del lado del cliente
21. Redirección
22. Ataques a contraseñas
23. Vectores de ataques a aplicaciones Web
24. Troyanos
25. NTFS Alternate Data Streams
26. Rootkits

Palabras clave: BackTrack, Test de Penetración, Distribución, LiveCD, scanner de puertos, Vulnerabilidades, exploits, sniffers, SQL Injection, Troyanos, RootKits, NTFS Alternate Data Streams, Fuerza Bruta, Redirección, Fuzzing, Spoofing, NetCat, Bash, Nmap.

Este nuevo recurso estará basado en el sistema de entrenamiento ofrecido por los propios desarrolladores y colaboradores del proyecto BackTrack (Remote-Exploit) Offensive-security.com.

Comencemos entonces por definir los conceptos de Test de Penetración y BackTrack:

Test de penetración:
Test de Penetración, también llamado a veces “hacking ético” es una evaluación activa de las medidas de seguridad de la información.
En los entornos de red complejos actuales, la exposición potencial al riesgo es cada vez mayor y securizar los sistemas se convierten en un auténtico reto.
A través del Test de Penetración es posible detectar el nivel de Seguridad Interna y Externa de los Sistemas de Información de la empresa, determinando el grado de acceso que tendría un atacante con intenciones maliciosas. Además, el servicio chequea las vulnerabilidades que pueden ser vistas y explotadas por individuos no autorizados, “crackers”, agentes de información, ladrones, antiguos empleados, competidores, etc.

Los servicios de Test de Penetración permiten:
- Evaluar vulnerabilidades por medio de la identificación de debilidades de configuración que puedan ser explotadas.
- Analizar y categorizar las debilidades explotables basadas en el impacto potencial y posibilidad de ocurrencia.
- Proveer recomendaciones prioritizadas para mitigar y eliminar las debilidades.

El Test de Penetración está dirigido a la búsqueda de agujeros de seguridad de forma focalizada en uno o varios recursos críticos, como puede ser el firewall o el servidor Web.

BackTrack:
BackTrack es una distribución GNU/Linux en formato LiveCD pensada y diseñada para la auditoría de seguridad y relacionada con la seguridad informática en general. Actualmente tiene una gran popularidad y aceptación en la comunidad que se mueve en torno a la seguridad informática.
Deriva de la unión de dos grandes distribuciones orientadas a la seguridad, el Auditor + WHAX.
WHAX es la evolución del Whoppix,(WhiteHat Knoppix) el cual pasó a basarse en SLAX en lugar de en Knoppix.
Incluye larga lista de herramientas de seguridad listas para usar, entre las que destacan numerosos scanners de puertos y vulnerabilidades, archivos de exploits, sniffers, herramientas de análisis forense y herramientas para la auditoría Wireless.
Fue incluida en la famosa lista Top 100 Network Security Tools del 2006 disponible en SecTools.Org
Web Oficial de BackTrack

Luego de tener claro las anteriores definiciones podemos entender que la finalidad de nuestro Laboratorio de Test de Penetración con BackTrack, será el ofrecer las técnicas, procesos y procedimientos necesarios para llevar a cabo un Test de Penetración haciendo uso de la Multi-Herramienta BackTrack.

Esto conllevará entonces a aprender y prácticar con ejemplos claros, sobre el uso de esta máginifica distribución. Además de las metodologías necesarias en un Test de Penetración.

Palabras clave: BackTrack, Test de Penetración, Distribución, LiveCD, scanner de puertos, Vulnerabilidades, exploits, sniffers, análisis forense, Wireless.

En el próximo Laboratorio, definiré los recursos necesarios y el contenido temático del Laboratorio.

Los grupos se irán conformando desde el foro destinado para ello y aquí se plantearán los temas y se llevará registro de los mismos.

Medellin

Pereira

Manizales

Popayán

Neiva

Cali

Bogotá

Ibagué

Perú

Guatemala

Venezuela

Mexico

Argentina

En la ciudad de Medellín se llevó a cabo el primer HackTaller de la Comunidad (Registro del primer HAckTaller en Medellín). Así mismo en la ciudad de Cali varios usuarios de la comunidad llevaron con éxito un laboratorio de seguridad.

La Criptología (del griego criptos=oculto y logos=tratado, ciencia) es el nombre genérico con el que se designan dos disciplinas opuestas y la vez complementarias: Criptografía y Criptoanálisis. La Criptografía se ocupa del diseño de procedimientos para cifrar, es decir, para enmascarar una determinada información de carácter confidencial. El Criptoanálisis, por su parte, se ocupa de romper esos procedimientos de cifrado para así recuperar la información original. Ambas disciplinas siempre se han desarrollado de forma paralela, pues cualquier método de cifrado lleva siempre emparejado su Criptoanálisis correspondiente.

La Criptografía como medio para proteger la información personal es un arte tan antiguo como la propia escritura. Como tal, permaneció durante siglos vinculada muy estrechamente a los círculos militares y diplomáticos, puesto que eran los únicos que en principio tenían auténtica necesidad de ella.

En la actualidad la situación ha cambiado drásticamente: el desarrollo de las comunicaciones electrónicas, unido al uso masivo y generalizado de los computadores, hace posible la transmisión y almacenamiento de grandes flujos de información confidencial que es necesario proteger. Es entonces cuando la Criptografía pasa de ser una exigencia de minorías a convertirse en una necesidad real del hombre de la calle, que ve esta falta de protección de sus datos privados una amenaza para su propia intimidad.

A y B son, respectivamente, el emisor y receptor de un determinado mensaje. A transforma el mensaje original (texto claro o texto fuente), mediante un determinado procedimiento de cifrado controlado por una clave, en un mensaje cifrado (criptograma) que se envía por un canal público. En recepción, B con conocimiento de la clave transforma ese criptograma en el texto fuente, recuperando así la información original.

En el proceso de transmisión, el criptograma puede ser interceptado por un enemigo criptoanalista que lleva a cabo una labor de desencriptado; es decir, intenta, a partir del criptograma y sin conocimiento de la clave, recuperar el mensaje original. Un buen sistema criptográfico será, por tanto, aquel que ofrezca un descifrado sencillo pero un desencriptado imposible o, en su defecto, muy difícil.

La finalidad de la Criptografía es múltiple: primeramente, mantener la confidencialidad del mensaje; es decir, que la información allí contenida permanezca secreta; a continuación, garantizar la autenticidad tanto del criptograma (integridad) como del par remitente/destinatario. En efecto, el criptograma recibido da de ser realmente el enviado (evitando así manipulaciones o alteraciones en el proceso de transmisión), a la vez que el remitente y destinatario han de ser realmente quienes dicen ser, y no remitentes y/o destinatarios fraudulentos. La Criptografía clásica se ocupaba únicamente del primer aspecto, mientras que la Criptografía de hoy en día, basada en el concepto de comunicaciones seguras, ha de garantizar conjuntamente todas ellas.

El tipo particular de transmisión aplicada al texto claro o las características de las claves utilizadas marcan la diferencia entre los diversos métodos criptográficos. Una primera clasificación en base a las claves utilizadas puede desglosarse tal y como sigue:

• Métodos simétricos: son aquellos en los que la clave de cifrado coincide con la de descifrado. Lógicamente, dicha clave tiene que permanecer secreta, lo que presupone que emisor y receptor se han puesto de acuerdo previamente en la determinación de la misma, o bien que existe un centro de distribución de claves que se la ha hecho llegar a ambos por un canal seguro.

• Métodos asimétricos: son aquellos en los que la clave de cifrado es diferente a la de descifrado. En general, la clave de cifrado es conocida libremente por el público, mientras que la de descifrado es conocida únicamente por el usuario.

Los métodos simétricos son propios de la Criptografía clásica o Criptografía de clave secreta, mientras que los métodos asimétricos corresponden a la Criptografía de clave pública, introducida por Difie y Hellman en 1976.

Una de las diferencias fundamentales entre la Criptografía clásica y la Criptografía de hoy en día radica en el concepto de seguridad. Antes, los procedimientos de cifrado tenían una seguridad probable; hoy, los procedimientos de cifrado han de tener una seguridad matemáticamente demostrable. Esto lleva a una primera clasificación de seguridad criptográfica:

• Seguridad incondicional (teórica): el sistema es seguir frente a un atacante con tiempo y recursos computacionales ilimitados (ej. Cifrado Vernam).

• Seguridad computacional (práctica): el sistema es seguro frente a un atacante con tiempo y recursos computacionales limitados (ej. Sistemas de clave pública basados en problemas de alta complejidad de cálculo).

• Seguridad probable: no se puede demostrar su integridad, pero el sistema no ha sido violado (ej. DES).

• Seguridad condicional: todos los demás sistemas, seguros en tanto que el enemigo carece de medios para atacarlos.

Con los antiguos procedimientos manuales y lentos de Criptoanálisis era suficiente la seguridad condicional, pues en la mayoría de los casis se obtenía el desencriptado del mensaje cuando la información del documento había perdido validez. Si el criptoanálisis tuvo éxitos de importancia fue sólo porque, al igual que era lento el proceso de análisis, lo era también el de cambio de claves. En la actualidad, con el uso de potentes computadores para el Criptoanálisis, los operadores criptográficos tienen que tener propiedades matemáticas que los hagan invulnerables no sólo en el presente, con nuestros conocimientos actuales de matemáticas y el estado actual de desarrollo de los computadores, sino también en un futuro a corto y medio plazo.

Puesto que las comunicaciones electrónicas se usan hoy en día para casi todas las actividades de interés social, están expuestas a todos los trucos y manipulaciones, consecuencia de las flaquezas humanas. Si en el mundo existieran honradez y confianza mutua, no habría necesidad de la Criptografía (afortunadamente no es así); pero, a falta de aquéllas, la Criptografía trata de suplirlas con protocolos y algoritmos matemáticos de seguridad demostrable.

Para comenzar y a manera de introducción, enumero el contenido temático de este nuevo apartado:

Contenido Temático

La Criptología

• Introducción
• Procedimientos clásicos de cifrado
• Introducción al Criptoanálisis
• Criptoanálisis básico

Criptográfia de clave secreta: Métodos de cifrado en flujo

• Generadores pseudoaleatorios de secuencia cifrante
• Estructuras básicas para la generación de secuencias cifrantes
• Filtrado no lineal
• Combinadores no lineales

Criptografía de clave secreta: Métodos de cifrado en bloque

• Arquitectura del cifrado en bloque
• Cifrados de Feistel
• DES
• Modos de implementación de los cifrados en bloque
• Cifrado múltiple
• IDEA
• RC5
• Un algoritmo de cifrado con “llave maestra”: el Skipjack
• Ataques especializados a los cifrados en bloque

Gestión de claves simétricas

• Introducción
• Clave maestra y almacenamiento de claves
• Generación de claves maestras
• Predistribución de claves maestras
• Vida de una clave de cliente
• Protocolos de comunicación

Aplicaciones y arquitecturas con cifrado simétrico

• Autenticación de mensajes (MAC)
• Firma digital
• Identificación personal
• Tarjetas electrónicas
• Configuraciones de cifrado

Criptosistemas de clave pública

• Definiciones
• Cambio de clave de Diffie-Hellman
• Criptosistemas de clave pública
• Criptosistemas RSA
• Ataquea al criptosistema RSA
• Criptosistema de ElGamal
• Ataque al criptosistema de ElGamal
• Criptosistemas de curvas elípticas
• Criptosistema de la mochila tramposa

Protocolos criptográficos y firmas digitales

• Firma digital
• Firma digital del criptosistema RSA
• Firma digital del criptosistema de ElGamal
• Funciones hash

Aplicaciones de la Criptografía de clave pública

• Autenticación de un mensaje
• Identificación del usuario
• Lanzamiento de una moneda por teléfono
• Póquer por teléfono
• Secreto dividido
• Descubrimiento parcial de secretos. Problema del millonario
• Transferencia inconsciente
• Venta de secretos
• Esquema electoral
• Descubrimiento mínimo
• Intercambio de secretos
• Firma de un contrato
• Correo con acuse de recibo
• Computación con datos encriptados
• Canales subliminales
• Protección de software

Aplicaciones criptográficas en redes de comunicaciones

• Introducción
• Principios de seguridad en redes de comunicaciones
• Aplicaciones de seguridad en redes de comunicaciones
• Sistema de autenticación
• Seguridad en Internet
• Seguridad en la Web
• Correo electrónico seguro
• Aplicaciones bancarias y comercio electrónico
• ISO 8730
• SWIFT (Society for Worldwide Interbank Financial Telecommunication)
• ETEBAC 5
• Comercio electrónico

Métodos matemáticos utilizados en Criptografía

Nociones básicas sobre la Teoría de la Complejidad Computacional

Criptografía visual y criptosistemas hiperelípticos

Normativa sobre seguridad

Problemas de Criptología

Bibliografía sobre Criptografía

Para este nuevo recurso utilizaremos como guía, el material bibliográfico ofrecido por el libro: Técnicas Criptográficas de protección de datos, de los autores Amparo Fuster, Dolores de la Guía Martínez, Luis Hernández Encinas, Fausto Montoya Vitini y Jaime Muñoz Masqué.

El taller pretende recoger de manera práctica los apartados más importantes de este recurso.

Para este primer anuncio del recurso prefiero citar una excelente guía a modo de introducción del tema, desarrollada por el Licenciado Cristian Borghello, seguido por unas definiciones básicas ofrecidas por la Wikipedia :

Criptología (Cristian Borghello)

Definiciones

Netmania Media Group cuenta con los sistemas virtualizados de intrusión utilizados en el HackTaller 01, además encontrarás las herramientas y material bibliográfico necesario para llevar a cabo las prácticas del mismo.

De esta manera quienes no pudieron asistir al Hacktaller 01 de la Comunidad pueden hacer uso del espacio y estar al día para los próximos Talleres de la Comunidad DragonJAR.

Recuerda: Netmania Media Group está ubicado en la calle 43 #68-60 local 104, Medellín tel 230-4308

Este video tutorial fué desarrollado haciendo uso del solucionario en texto número 2 publicado por SG6 Labs:

Descargar video tutorial de resolución del HackTaller 01 de la Comunidad DragonJAR (SecGame: Sauron)(password: www.dragonjar.org)

Herramientas necesarias:

NetCat

Palabras claves (Documentos de interés, Definiciones):

NetCat - Servidor Web - Apache - PHP - Vulnerabilidades - Tamper Data - Proxy - Paros Proxy - Perl - .HTACCESS - Peticiones

Lo primero que corresponde es analizar el comportamiento de un acceso a dicho directorio bajo unos cuantos supuestos. Cada cual lo puede hacer como más le guste, desde Mozilla con Tamper Data, con un proxy intermedio como Paros, o directamente con un nc desde la línea de comandos, aquí usaremos esta última.

> nc www.blindware.inc 80
GET /data/stats HTTP/1.0

HTTP/1.1 302 Found
Date: Tue, 17 Jul 2007 09:56:15 GMT
Server: Apache/2.2.4 (Fedora)
Location: http://www.blindware.inc/data/error-stats.html
Content-Length: 312
Connection: close
Content-Type: text/html; charset=iso-8859-1

> nc www.blindware.inc 80
GET /data/stats/index.html HTTP/1.0

HTTP/1.1 302 Found
Date: Tue, 17 Jul 2007 09:56:15 GMT
Server: Apache/2.2.4 (Fedora)
Location: http://www.blindware.inc/data/error-stats.html
Content-Length: 312
Connection: close
Content-Type: text/html; charset=iso-8859-1

> nc www.blindware.inc 80
GET /data/stats/ficherocualquiera HTTP/1.0

HTTP/1.1 302 Found
Date: Tue, 17 Jul 2007 09:56:15 GMT
Server: Apache/2.2.4 (Fedora)
Location: http://www.blindware.inc/data/error-stats.html
Content-Length: 312
Connection: close
Content-Type: text/html; charset=iso-8859-1

Primera Idea: De esta primera prueba nos debemos percatar que incluso con ficheros aleatorios, cuya probabilidad de existir en esa ruta es prácticamente 0%, nos sigue dando la misma respuesta, por tanto podemos deducir que existe un control de acceso a ese directorio por parte del propio Apache, que fuerza una redirección a la URL: http://www.blindware.inc/data/error-stats.html, o dicho de otra forma, que solicitemos el fichero que solicitemos Apache nos va a mostrar la pagina de error-stats.html

Visto esto, veámos que información da el “error-stats.html”:

Access to “/var/www/blindware/htdocs/data/stats/” Forbidden
Your access isn’t allowed to this path
HTTP METHOD RESTRICTED TO 127.0.0.1

Esta web nos devuelve una información relevante sobre una denegación de acceso a la que somos redirigidos siempre, por tanto, y como consejo general a menos que estemos muy familiarizados con Apache, lo que haremos será documentar qué motivos pueden llevar a Apache a generar un mensaje de este tipo. Para ello bien nos puede servir buscar en Google: Access Forbidden Apache. Leyendo por encima los enlaces que aparecen, encontraremos como información relevante que es un error de Apache numerado con el número 403 y que se produce bajo ciertas circunstancias:

• Solicitar un directorio que no contiene índice ( index.html ) cuando la opción INDEXES está desactivada.
• Solicitar un directorio que tiene denegado el acceso bajo todas o alguna circunstancia.

Así mismo, vemos que mediante ficheros “.htaccess” o en la propia configuración de Apache, podemos configurar una directiva denominada ErrorDocument 403 que nos redirige a una página web concreta en caso de que se produzca un error 403. Es evidente, que en nuestro escenario no estamos solicitando un directorio que no contiene índice, sino que ante cualquier fichero que solicitemos, nos produce este resultado, por tanto, a priori, nos encontraremos en el caso en el que el directorio tiene denegado el acceso y se ha asociado una cláusula ErrorDocument a él.

Intentemos emular por tanto el escenario, y para ello qué mejor que dirigirse al howto para control de accesos que dispone Apache y ver qué habría que introducir en su configuración para obtener un comportamiento como el que vemos en este servidor. En esta web encontraremos algún que otro ejemplo, pero uno interesante por encima del resto:

Order deny,allow
Deny from all
Allow from W.X.Y.Z

Segunda Idea: de lo anterior podemos inducir que bien una cláusula bien un fichero .htaccess dentro del directorio data/stats están limitando el acceso. Y que su estructura será parecida a la siguiente:

ErrorDocument 403 http://www.blindware.inc/data/error-stats.html
Order deny,allow
Deny from all
Allow from 127.0.0.1

La primera línea es la que marca la redirección al fichero “error-stats.html” en caso de que se produzca un acceso no autorizado. Así mismo, la cláusula “Deny from all” deniega el acceso a todos los usuarios menos a los autorizados por una cláusula “Allow” que en este caso serán los provenientes de 127.0.0.1 (localhost).

Con esto hemos replicado el comportamiento del escenario del nivel, ¿qué podemos hacer ahora?. Siempre tenemos 2 opciones una vez hemos conseguido conocer la estructura y replicarla bajo nuestro total control: buscar una vulnerabilidad pública o descubrirla por nosotros mismos. Desde aquí recomendamos encarecidamente el no reinventar la rueda: las listas públicas de vulnerabilidades existen para algo y es para ser usadas. Es cierto, que no siempre las vulnerabilidades existentes, y los exploits desarrollados para ellas se adaptarán 100% a nuestras necesidades, pero con diferencia nos ahorrarán mucho trabajo. Por ello, para sobrepasar esta medida de protección recomendamos buscar en Google etiquetas como las siguientes: apache access bypass, htaccess bypass, o apache access weakness.

Estas búsquedas nos devolverán un importante número de referencias a vulnerabilidades públicas en el control de accesos por parte de Apache (R1, R2).

De la lectura de estas fuentes, podemos suponer que es posbile que exista una vulnerabilidad de configuración en el escenario propuesto para la segunda idea. ¿Cuál sería esta vulnerabilidad? Por ejemplo, una configuración como la siguiente:

ErrorDocument 403 http://www.blindware.inc/data/error-stats.html
<LIMIT GET>
Order deny,allow
Deny from all
Allow from 127.0.0.1
</LIMIT>

Para verificarlo volvemos a hacer uso de nc desde la línea de comandos.

> nc www.blindware.inc 80
OPTIONS /data/stats/ HTTP/1.0

HTTP/1.1 200 OK
Date: Tue, 17 Jul 2007 12:29:51 GMT
Server: Apache/2.2.4 (Fedora)
Allow: GET,HEAD,POST,OPTIONS,TRACE
Content-Length: 0
Connection: close
Content-Type: text/html; charset=UTF-8

> nc www.blindware.inc 80
TRACE /data/stats/ HTTP/1.0

HTTP/1.1 200 OK
Date: Tue, 17 Jul 2007 12:30:19 GMT
Server: Apache/2.2.4 (Fedora)
Connection: close
Content-Type: message/http

TRACE /data/stats/ HTTP/1.0

> nc www.blindware.inc 80
PUT /data/stats/ HTTP/1.0

HTTP/1.1 405 Method Not Allowed
Date: Tue, 17 Jul 2007 12:30:49 GMT
Server: Apache/2.2.4 (Fedora)
Allow: GET,HEAD,POST,OPTIONS,TRACE
Content-Length: 324
Connection: close
Content-Type: text/html; charset=iso-8859-1

Efectivamente, existe una configuración incorrecta. Con sólo leer las respuestas del servidor vemos cómo únicamente es filtrado el método GET, mientras que por el contrario el método OPTIONS, TRACE o PUT son correctamente procesados por Apache. ¿Cómo se puede explotar esto?.

La explotación de este fallo de seguridad depende del fichero sobre el que hagamos la petición, en caso de ser un fichero procesable por un módulo de Apache, como puede ser PHP, PERL, etc, la explotación es mucho más sencilla porque los metodos OPTIONS o PUT devolverán exactamente lo mismo que un método GET en la inmensa mayoría de las ocasiones. Sin embargo, si el fichero lo procesa directamente Apache, como es el caso de los ficheros HTML con contenido estático, el único método diferente a GET que tiene el mismo resultado es POST. Por tanto, y dado que en este caso parece que lo que estamos buscando es el fichero “index.html” debemos hacer uso del método POST.

> nc www.blindware.inc 80
POST /data/stats/ HTTP/1.0

HTTP/1.1 200 OK
Date: Tue, 17 Jul 2007 12:31:57 GMT
Server: Apache/2.2.4 (Fedora)
Last-Modified: Tue, 08 May 2007 20:46:48 GMT
ETag: “a8023-4eed-8431de00?
Accept-Ranges: bytes
Content-Length: 20205
Connection: close
Content-Type: text/html; charset=UTF-8
<html>
<head>
<title>Web Server Statistics for Blindware Inc.</title>
<meta http-equiv=”Content-Type” content=”text/html; charset=ISO-8859-1? />
<meta name=”robots” content=”noindex,nofollow” />
<title>Server Statistics for Blindware Inc.</title>(..)

Efectivamente, nos devuelve el fichero index.html de forma correcta, por tanto podemos salvarlo a un fichero y leerlo localmente con cualquier navegador, viendo entre otros los siguientes datos:

Directory Report

This report lists the directories from which files were requested. (The figures for each directory include all of its subdirectories.)

/web/
[root directory]
/data/
/icons/
/_controlp/

En la sección destinada a directorios accedidos encontramos un directorio en el que no habíamos reparado y de nombre “_controlp/”.

Este video tutorial fué desarrollado haciendo uso del solucionario en texto número 1 publicado por SG6 Labs:

Descargar video tutorial de resolución del HackTaller 01 de la Comunidad DragonJAR (SecGame: Sauron)(password: www.dragonjar.org)

Herramientas necesarias:

NetCat
Nmap
Wikto
Wget
.Net Framework 2.0

Palabras claves (Documentos de interés, Definiciones):

Nmap - NetCat - Wikto - Wget - .Net Framework - ICMP - Clases de redes - Ping - Puertos - Subred - Escaneo - Servidor Web - Apache - PHP - Vulnerabilidades - JavaScript - HTTP - Robots.txt - Logs

En este primer nivel, que sirve como toma de contacto con el modelo de resolución, lo primero que haremos será marcar unos objetivos principales, que bien podrán servir tanto para afrontar este reto, como en general para el inicio de cualquier actividad que tenga como finalidad determinar posibles puntos de intrusión en un sistema.

Los objetivos son los siguientes:

• Conocer la estructura del sistema y de la red
• Conocer la estructura del aplicativo
• Buscar ficheros por defecto con información sensible
• Analizar la lógica del aplicativo
• Determinar los posibles puntos de intrusión
• Información sobre Red y Servicios

Vamos a comenzar delimitando los sistemas presentes en la red de clase C 192.168.200.0/24 . Para hacerlo, usamos nmap con su modificador –sP ( ICMP Ping ), aunque bien se puede dar la circunstancia de existir sistemas que no contesten a tráfico ICMP.

> nmap -sP 192.168.200.1-254

Starting Nmap 4.20 ( http://insecure.org ) at 2007-07-05 18:51 Hora estandar romance
Host 192.168.200.1 appears to be up.
Host www.blindware.inc (192.168.200.2) appears to be up.
MAC Address: 52:54:00:12:34:55 (QEMU virtual NIC)
Nmap finished: 254 IP addresses (2 hosts up) scanned in 17.016 seconds

Por ello, una comprobación también es interesante es verificar directamente algunos puertos típicos, haciendo uso de tráfico TCP, sin usar comprobación previa por ICMP. Por ejemplo lo podemos hacer con el modificador –P0 –p 80, indicando así que no se envíe un “ping” previo, y que se compruebe el puerto 80/tcp.

En nuestro caso concreto, y dado que directamente parece que no existe ningún otro host activo en esa subred, escanearemos la IP 192.168.200.2. Podremos escanear por defecto, eliminando el modificador “-p”, algunos puertos concretos o escanearlos todos “-p 1-65535”. Un detalle importante que siempre debemos recordar es que cuando marcamos un escaneo –sS o –sT, o sin tipo, únicamente escaneamos puertos TCP, los puertos UDP deben escanearse con el modificador –sU. En nuestro caso este ha sido el resultado.

> nmap -P0 -sS -p 22,23,25,80,110,443,3306 192.168.200.2

Starting Nmap 4.20 ( http://insecure.org ) at 2007-07-05 19:02 Hora estßndar romance
Interesting ports on www.blindware.inc (192.168.200.2):
PORT STATE SERVICE
22/tcp filtered ssh
23/tcp filtered telnet
25/tcp filtered smtp
80/tcp open http
110/tcp filtered pop3
443/tcp open https
3306/tcp filtered mysql
MAC Address: 52:54:00:12:34:55 (QEMU virtual NIC)

Nmap finished: 1 IP address (1 host up) scanned in 0.360 seconds

De esta verificación obtenemos que existen 2 puertos abiertos en ese sistema: 80 y 443, en un principio coorrespondientes a tráfico http y https. Existe otro modificador que nos puede dar más información sobre estos puertos: –sV

> nmap -sV -p 80,443 192.168.200.2

Starting Nmap 4.20 ( http://insecure.org ) at 2007-07-05 19:14 Hora estandar romance
Interesting ports on www.blindware.inc (192.168.200.2):
PORT STATE SERVICE VERSION
80/tcp open http Apache httpd 2.2.4 ((Fedora))
443/tcp open ssl OpenSSL
MAC Address: 52:54:00:12:34:55 (QEMU virtual NIC)

Nmap finished: 1 IP address (1 host up) scanned in 6.719 seconds

Llegados a este punto, podemos decir que si bien podemos seguir haciendo un uso más intensivo de herramientas de red, para nuestros propósitos hemos conseguido establecer la existencia de un sistema activo en la subred determinada, el cual cuenta con 2 puertos TCP abiertos, sobre los que ofrece servicio http y https.

Información sobre el Servidor Web

¿Cuál es nuestro segundo objetivo? Como dijimos inicialmente, familiarizarnos con toda la estructura del aplicativo web. ¿Por qué? Primero, porque en el sistema activo para la subred 192.168.200.0/24, no parecen existir otro tipo de servicios. Además de ello, debemos tener muy presente, que en la actualidad y de forma mayoritaria, la inseguridad se ha ido desplazando desde los servicios y elementos de red, a las aplicaciones web sobre el servicio http/https. Por tanto, a pesar de que pudieran existir otros servicios, sobre el aplicativo web, siempre que exista, incidiremos con especial detalle.

Una conexión directa haciendo uso de netcat, y una petición al servicio web nos muestra la siguiente información:

> nc 192.168.200.2 80
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Date: Thu, 05 Jul 2007 19:20:20 GMT
Server: Apache/2.2.4 (Fedora)
X-Powered-By: PHP/5.1.6
Connection: close
Content-Type: text/html; charset=UTF-8

A todos los efectos, esto nos sirve para comprobar que se tratan de versiones actualizadas de Apache y de PHP y que por tanto, las vulnerabilidades existentes, como suele ser común, no residen en los servicios de red, sino que deberemos buscarlas dentro del aplicativo web.

Lo siguiente que debemos hacer es obtener información sobre el árbol web. Desde aquí recomendamos que el spidering ( nombre que comúnmente recibe esta técnica ) se realice sin usar aplicativos integrados en el navegador, pues algunos tienen la mala costumbre de interpretar código javascript pudiendo hacer que obviemos detalles importantes debido a la automatización del proceso. Wget o httrack son unas herramientas muy válidas para la tarea.

> wget -r http://www.blindware.inc
–19:28:15– http://www.blindware.inc/
=> `www.blindware.inc/index.html’
Resolving www.blindware.inc… 192.168.200.2
Connecting to www.blindware.inc|192.168.200.2|:80… connected.
HTTP request sent, awaiting response… 200 OK
Length: unspecified [text/html]

[ <=> ] 24 –.–K/s

19:28:15 (1.02 MB/s) - `www.blindware.inc/index.html’ saved [24]

Loading robots.txt; please ignore errors.
–19:28:15– http://www.blindware.inc/robots.txt
=> `www.blindware.inc/robots.txt’
Connecting to www.blindware.inc|192.168.200.2|:80… connected.
HTTP request sent, awaiting response… 200 OK
Length: 33 [text/plain]

100%[====================================>] 33 –.–K/s

19:28:15 (1.12 MB/s) - `www.blindware.inc/robots.txt’ saved [33/33]

–19:28:15– http://www.blindware.inc/load.js
=> `www.blindware.inc/load.js’
Connecting to www.blindware.inc|192.168.200.2|:80… connected.
HTTP request sent, awaiting response… 200 OK
Length: 76 [application/x-javascript]

100%[====================================>] 76 –.–K/s

19:28:15 (2.30 MB/s) - `www.blindware.inc/load.js’ saved [76/76]

FINISHED –19:28:15–
Downloaded: 133 bytes in 3 files

Ese es el resultado inicial para http://www.blindware.inc. Si lo repetimos sobre http://intranet.blindware.inc no obtendremos nada porque nos pide autenticación, y por el momento la desconocemos. Por último, si lo llevamos a cabo sobre el servicio HTTPS, https://www.blindware.inc o https://intranet.blindware.inc obtenemos un index.html en blanco.

De esto concluimos que, al menos, se están sirviendo 3 escenarios diferentes. Uno por HTTP para www.blindware.inc, otro por HTTP para intranet.blindware.inc y por último, lo que parece uno común por HTTPS que sirve un index.html en blanco.

Vamos a verificar qué contienen los ficheros descargados:

> type index.html
script src=”load.js”>

> type load.js
// document.location.href=’data/0.html’
Document.location.href=’web/0.html’;

> type robots.txt
User-agent: *
Disallow: /data/

Como podemos comprobar desde el fichero index.html existe una llamada a un fichero con contenido javascript (load.js) el cual tiene como misión redirigir el tráfico hacia la web principal. Nos debemos percatar, que existe una línea comentada dentro de este fichero, la cual nos da información sobre una ruta diferente a la habitual data/0.html. Así mismo dentro del fichero robots.txt volvemos a encontrar una referencia a esta ruta. Si continuamos descargando contenidos desde web/0.html comprobamos que únicamente se descarga contenido estático en html.

Así que hasta el momento, y como conclusión, sabemos que existe una carpeta web/, la cual no parece contener nada reseñable, más que el contenido estático del site, y la carpeta data/, sobre la cual hablaremos más adelante.

Vulnerabilidades y Ficheros Sensibles

A continuación, debemos determinar ficheros, configuraciones, o posibles fallos conocidos en el servicio web. Para esta tarea existen numerosas aplicaciones, desde AppScan, a Nikto, o su port a Win32, Wikto. Nosotros vamos a utilizar este último, concretamente sus funciones destinadas a la exploración de contenido backend, cuya finalidad es extraer mediante una exploración por diccionario carpetas y ficheros ocultos, así como la propia utilidad Nikto, que nos escaneará la web buscando vulnerabilidades conocidas. Advertencia: El uso de herramientas automatizadas puede provocar falsos positivos, que debemos comprobar antes de emitir cualquier tipo de valoración.

Los resultados de la ejecución de Wikto son los siguientes:

BackEnd

#Directories
www.blindware.inc/
www.blindware.inc/cgi-bin/
www.blindware.inc/data/
www.blindware.inc/error/
www.blindware.inc/data/stats/
www.blindware.inc/error/include/
#Indexable
www.blindware.inc/data/
#Files
www.blindware.inc/index.php
www.blindware.inc/robots.txt

Nikto

/index.php?=PHPB8B5F2A0-3C92-11d3-A3A9-4C7B08C10000
/index.php?=PHPE9568F35-D428-11d2-A769-00AA001ACF42
/index.php?=PHPE9568F34-D428-11d2-A769-00AA001ACF42
/WS_FTP.LOG

De esta información podemos obtener los siguientes datos relevantes:

• La existencia de un directorio /data/stats
• La existencia de un fichero WS_FTP.LOG
• La existencia de un fichero robots.txt
• Información sobre PHP

Un paseo por la aplicación visible, podemos hacerlo con Paros por ejemplo, nos desvela que, a priori, los que vemos es un contenido pre-generado de forma estática y cuya única entrada de datos se encuentra en el formulario contacto. Podemos analizarlo, pero no vamos a encontrar ningún comportamiento anómalo, ya que si nos damos cuenta el campo “action” de ese formulario va en blanco. Esto nos debe hacer pensar, que en caso de existir partes vulnerables, no se encuentran accesibles al público directamente.

Como información adicional decir que muchos gestores de contenido, entre ellos los más robustos, generan el contenido de forma estática desde un aplicativo en backend, haciendo que la parte visible de la aplicación carezca, casi por completo, de contenido dinámico, y de entradas por parte del usuario. Existirán por el contrario, otros aplicativos, como foros, buscadores, o secciones de prensa, cuyo contenido utilice generación dinámica. En estos casos, deberemos probar la inclusión sobre sus parámetros de código SQL, código HTML, código PHP, etc. buscando un comportamiento extraño.

Busqueda de un Punto de Intrusión

Para buscar un punto de intrusión, debemos recopilar lo que sabemos hasta el momento, ordenar las ideas y tomar una decisión, que vaya por delante, no tiene porqué ser la correcta. Dicho de otra forma, todo lo realizado hasta el momento nos lleva a suposiciones plausibles, pero nada nos garantiza que estemos en lo cierto. Vamos a ver lo que sabemos:

1. Existen 3 contenidos diferentes servidos por el servidor web
1. http://www.blindware.inc ( En adelante www )
2. http://intranet.blindware.inc ( En adelante intranet )
3. https://www.blindware.inc y https://intranet.blindware.inc ( En adelante https )
2. El contenido de https que podemos revisar con Wikto no parece contener nada.
3. Intranet nos pide autenticación para acceder.
4. En www conocemos que:
1. Tanto por la información pública existente, como por Wikto, existen sendos directorios de nombre data/ y data/stats/
2. Wikto nos revela la existencia del fichero WS_FTP.LOG

Antes de continuar debemos revisar el fichero WS_FTP.LOG:

2007.05.08 12:55 B C:\data\logs\index.php <– hawking /htdocs/data/stats/index.php
2007.05.08 12:55 B C:\data\logs\index.php <– hawking /htdocs/data/stats/blnd0.log
2007.05.08 12:55 B C:\data\logs\index.php <– hawking /htdocs/data/stats/blnd1.log
2007.05.08 12:55 B C:\data\logs\index.php <– hawking /htdocs/data/stats/blnd2.log
2007.05.08 12:55 B C:\data\logs\index.php <– hawking /htdocs/data/stats/blnd3.log

Con lo cual, parece que tenemos 2 opciones:

1. Atacar la autenticación de intranet
2. Intentar acceder en WWW a data/stats/ ( y a lo que parecen ser logs )

Aquí hay que decidir, en este caso, sobre intranet no sabemos absolutamente nada, mientras que sobre data/stats/ al menos sabemos que el día 8 de Mayo de 2007, contenía algún tipo de fichero de logs.

Evidentemente cada uno puede buscar lo que prefiera, y dónde prefiera, pero en este caso, los LOGS pueden resultar una información de vital interés pues pueden desvelarnos partes ocultas del aplicativo, y otras áreas de las que no tenemos conocimiento, así como usuarios con los que se accede a ellas ( si el acceso se hace autenticado mediante apache ) y otros muchos detalles.

Por el contrario, atacar directamente una autenticación de Apache, salvo que esté incorrectamente configurada, es algo bastante poco probable de llevar a buen fin, porque a priori, únicamente podremos atacar por fuerza bruta.

Con esto podemos concluir el primer nivel, habiendo visto las siguientes vulnerabilidades relativas a la “publicación de información sensible”:

• En los comentarios del fichero “load.js” se filtra información
• El fichero robots.txt mal facilita información relativa a áreas del aplicativo no públicas
• Existen el WS_FTP.LOG conteniendo información sensible
• El servidor Apache, está incorrectamente configurado, permite, mediante la opción INDEXES, la navegación por aquellos directorios que no contienen un fichero índice.

Así mismo tenemos un objetivo para iniciar nuestro ataque: el directorio data/stats/ terminando así el primer nivel de Sauron. Este primer nivel es igual para ambos niveles de complejidad.

Ya muchos de los participantes están dejando sus comentarios y anécdotas del encuentro en el foro de la Comunidad (Foro HackTaller)

Aquí tenemos la primera galería de imágenes del HackTaller (ver galería)

Desde hoy empezaré a publicar los recursos utilizados para llevar a cabo este primer HackTaller de la Comunidad DragonJAR.

El ambiente virtualizado de intrusión utilizado para este HackTaller es el recurso que había publicado en la Web principal de la Comunidad (SecGame: Sauron)

Desde hoy publicaré cada nivel de solución en formato de video (sin sonido).
Para quienes quieran ir a un ritmo más rápido pueden hacer uso del documento en pdf del solucionario publicado por la gente de SG6 Labs.
A SG6 Labs muchas gracias por la publicación de este magnífico recurso.

SecGame es un proyecto diseñado por SG6 Labs para el desarrollo de entornos que permitan la simulación de test de intrusión adaptados a escenarios reales.
Estos entornos permiten no sólo la adquisición de habilidades, sino también la evaluación de las mismas, tanto dentro de los estrictamente conocimientos prácticos, como de las metodologías aplicadas al escenario.
Dentro de los entornos a desarrollar se recogerán las principales necesidades del campo de la auditoría técnica de seguridad informática: revisión de aplicativo web, revisión de servicios, revisión de código, revisión de sistemas de gestión de bases de datos, revisión de configuraciones y políticas de seguridad, entre otras, intentando en cada entorno que dentro de su completitud, focalice las problemáticas más típicas de cada uno de los escenarios.

Objetivos

• Proporcionar un entorno de simulación para la auditoria técnica de sistemas de información que permita el aprendizaje y la mejora de habilidades.
• Desarrollar un entorno de simulación basado en casos y escenarios reales de sistemas, sin que exista separación física de niveles, permitiendo un mayor realismo en la explotación de los entornos.
• Dotar de una relación extensa de escenarios bajo unos sistemas heterogéneos que permitan la revisión de un conjunto amplio de casos interrelacionados entre sí.
• Permitir la revisión de aplicativo web desarrollado en múltiples lenguajes, mostrando diversos errores en la codificación del mismo.
• Permitir la revisión de configuraciones de servicios, mostrando diferentes niveles de securizacion, y su impacto sobre los sistemas.
• Permitir la revisión de servicios inseguros, mostrando errores comunes y fallos de seguridad en los mismos.
• Permitir la revisión de código fuente inseguro, mostrando errores comunes y fallos de seguridad en el mismo.
• Permitir la revisión de sistemas de gestión de bases de datos, mostrando errores típicos en el acceso a los mismos, y errores de gestión y configuración.
• Innovar en el área de los aplicativos destinados a la preparación de test de intrusión haciendo uso de la vitalización y las posibilidades de red que ofrecen estos entornos.

Video tutorial de instalación del ambiente virtualizado de intrusión en Windows (Password: www.dragonjar.org).
Recursos necesarios:

• SecGame #1 Sauron: Máquinas virtuales (cualquiera de las dos versiones)
  • Descargar máquina virtual Sauron (530MB. Dificultad Normal)
  • Descargar máquina virtual Sauron (519MB. Dificultad Alta)
• Binarios para Windows
  • Qemu Manager 4.0
  • OpenVPN 2.0.9

Solucionario en formato pdf (password: www.dragonjar.org)
Documentación de interés - Guía de pruebas OWASP (password: www.dragonjar.org)
Virtualización
Qemu
VPN