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

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).

<VirtualHost *:80>
ServerAdmin [email protected]
DocumentRoot /var/www/blindware/htdocs
ServerName www.blindware.inc
SuexecUserGroup blindware blindware
<Directory />
Options Indexes SymLinksIfOwnerMatch ExecCGI
AllowOverride All
</Directory>
</VirtualHost>

<VirtualHost *:80>
ServerAdmin [email protected]
DocumentRoot /var/www/intranet/htdocs
ServerName intranet.blindware.inc
SuexecUserGroup intranet intranet
<Directory />
Options Indexes SymLinksIfOwnerMatch ExecCGI
AllowOverride All
</Directory>
</VirtualHost>

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.