Mucho ya os he hablado del bug de IIS Shortname que permite hacer un ataque de booleanización para listar los nombres en formato 8:3 en un servidor Windows con IIS. Hemos visto que este bug está en sitios como windows.microsoft.com y recientemente en un dominio de Apple, además de ver que en muchos sitios aún se puede explotar por medio del método Options. Hoy aún así, quiero contaros un caso que tenemos implementado en el entorno de demo que utilizamos para pasar los test de QA de nuestra plataforma de pentesting persistente Faast.
 |
| Figura 1: Acceder a archivos con nombres en formato 8:3 en servidores Apache sobre Windows |
Ejemplo de acceso a archivos 8:3 en Apache sobre Windows
En ese entorno, uno de los servidores es un Apache corriendo sobre un servidor Microsoft Windows. Entre la lista de archivos que hay existen dos ficheros con nombres largos y que comienzan por la cadena password, pero que tienen diferentes extensiones, tal y como se puede ver en la imagen siguiente.
 |
| Figura 2: Lista de archivos disponibles en el servidor Apache sobre Windows |
El comportamiento de Apache cuando se solicita un fichero en formato 8:3 es totalmente correcto, y como se puede ver, si pedimos passwo~1.txt el servidor web nos devuelve el contenido del fichero de nombre largo asociado a él.
 |
| Figura 3: Con el nombre corto se accede al fichero de nombre largo asociado |
El comportamiento es similar si pedimos la misma cadena, pero cambiamos la extensión TXT por ZIP. En este caso llegamos a la descarga del fichero asociado a ese nombre acortado.
 |
| Figura 4: Con el nombre acortado se consigue la descarga del fichero de nombre largo |
Es decir, los nombres cortos en formato 8:3 son totalmente funcionales en los servidores Apache sobre sistemas Microsoft Windows.
Mismo bug, dos explotaciones distintas
La explotación de esta característica en servidores Apache sobre Windows no es igual que la de IIS sobre servidores Windows, ya que mientras que en este último se puede hacer un ataque de booleanización para ir descubriendo carácter a carácter el nombre del fichero, en el caso de Apache no es posible.
 |
| Figura 5: Diferencia entre IIS y Apache con ficheros 8:3 |
Por otro lado, cuando en IIS se consigue el nombre en formato 8:3 no se puede obtener el fichero completo asociado a ese nombre acortado, mientras que en Apache, si se hace una ataque de diccionario con nombres de 6 caracteres y extensiones, sí que sería posible acceder al archivo asociado.
Saludos Malignos!
Menuda mierda que cutre...
ResponderEliminar@ivan de la Jara, relaja tu efusividad, friend! }XD
ResponderEliminarSaludos!
Una pregunta que no tiene que ver con el post.
ResponderEliminar¿Sus libros de 0xword los venden en formato digital?
Saludos
@Anónimo, por ahora no.
ResponderEliminarBuenas Maloso,
ResponderEliminarPor lo que he podido comprobar, esto no funciona (o al menos a mi no) cuando tenemos una directiva tipo "UrlRewrite" aplicada por .htaccess ya sea al directorio de destino o a un directorio padre, ¿Me equivoco?
Es decir, esto en una instalación común de Wordpress por ejemplo no serviría si se utiliza el ficherito .htaccess...
¡Saludos!
Viendo que el bug en ambos sistemas funciona el ataque por diccionario podríamos mezclarlo con mi generador de diccionarios en python (con algunas modificaciones) :-) http://www.blogx86.net/?p=73
ResponderEliminarSaludos!
@Christian Prieto, no sé exactamente si tu código pretende eso, intuyo que es lo mismo para lo que sirve el que hice yo en PHP para un robot que generaba hashes en múltiples (md5, sha1, sha256, etc...) y los guardaba en una base de datos para luego "desencriptar" (o sea, "fuerza brutaza") dichos hashes:
ResponderEliminar$c = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789ªº\\|!@"#~$%&/()=\'?';
$k = strlen($c);
function c($n)
{
global $k, $c;
$s = '';
$r = 1;
$b = $n;
while($b > pow($k, $r))
$b -= pow($k, $r++);
for($i = 0; $r > $i; $i++)
$s = substr($c, ($n/pow($k,$i)-1)%$k, 1) . $s;
return $s;
}
Ya que me has dado la idea a lo mejor escribo un artículo en mi blog de como realizar este robot sencillo para que todos puedan hacerlo y a ver quien se monta la DB más grande, lo bueno es que añadir caracteres es tan fácil como ponerlos en el string de arriba.
Saludos :P
P.D: Buen artículo chema!!
@porketero, lo que propones de la base de datos con almacenamiento de hashes ya existe para MD5, de hecho ya tengo mi propia base de datos con claves de hasta 6 dígitos de longitud y ocupa más de 400GB. Agregué mi servidor a las consultas de "fang", que es un programa destinado a obtener la clave del hash MD5 que se le consulta. Aunque en este caso, por ahora, mi servidor es de uso personal para pruebas.
ResponderEliminarLo que propones de generar una super base de datos, con este tipo de diccionario, para más de 6 ò 7 dígitos es impensable, ya que sería brutal lo que ocuparía (una base de datos con más digitos que esos, por ejemplo 12, ocuparía miles de teras), y la limitación física de acceso al dato también sería un problema, ya que existe un ĺímite de ram y de velocidad de acceso a disco, aparte de la capacidad como hemos dicho. Pero existir, ya existe, aunque solo sirve para claves cortas y diccionarios de claves más usadas.
Osea que lo que sacamos de aquí, es que todos los servidores que almacenen claves de sus usuarios, deberían de obligarles a usar en las contraseñas, mayúsculas, minúsculas, números y catacteres no alfanuméricos, así como una longitud igual o superior a 8 dígitos.
Un saludo.