Solución del HackTaller 01 DragonJAR (III de VIII)

Continuamos con la tercera entrega de la solución del HackTaller 01 de la Comunidad DragonJAR en formato de video.

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

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

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/”.

HackTaller 01 disponible en Netmania Media Group