Kali Linux: Htshells y Seguridad Web
Kali Linux: Htshells y Seguridad Web
Entiendo que estás explorando las herramientas de Kali Linux, específicamente las htshells. Es un tema fascinante pero que requiere precisión, ya que estas herramientas son poderosas para las auditorías de seguridad.
En resumen, las htshells son una colección de archivos de configuración (como .htaccess) que permiten ejecutar código o realizar acciones de "shell" en servidores web mediante la manipulación de las reglas de configuración del servidor (generalmente Apache).
¿Qué son y para qué sirven las htshells?
Normalmente, un archivo .htaccess se usa para redirecciones o control de acceso. Sin embargo, en un entorno de Pentesting, las htshells se utilizan para:
Ejecución de código: Obligar al servidor a tratar un archivo de texto o una imagen como un script ejecutable (por ejemplo, PHP).
Evasión de restricciones: Saltar filtros de subida de archivos que bloquean extensiones comunes.
Persistencia: Mantener acceso a un servidor web de forma discreta.
Ubicación en Kali Linux
Si tienes instalado el paquete webshells en tu sistema, generalmente puedes encontrar estos recursos en el siguiente directorio:
/usr/share/webshells/htshells/
Ejemplo de funcionamiento
Imagina un servidor que solo permite subir imágenes (.jpg). Un atacante podría subir un archivo .htaccess modificado que le diga al servidor: "Cualquier archivo llamado 'foto.jpg' debe ser ejecutado como si fuera PHP".
Consideraciones de Seguridad
Uso Ético: Estas herramientas solo deben usarse en entornos controlados o bajo autorización explícita (contratos de Pentesting).
Detección: Los WAF (Web Application Firewalls) modernos y los sistemas de detección de intrusos suelen bloquear la carga de archivos
.htaccess.Remediación: Para proteger un servidor, se debe configurar la directiva
AllowOverride Nonepara evitar que los usuarios carguen sus propios archivos de configuración.Vamos a desglosar una Prueba de Concepto (PoC) básica para entender cómo un archivo
.htaccesspuede comprometer un servidor web.Imagina un escenario donde un servidor permite subir imágenes, pero prohíbe archivos
.php. El objetivo es "engañar" al servidor para que ejecute código PHP escondido en otro formato.Paso 1: El entorno de laboratorio
Para esto necesitarías:
Atacante: Kali Linux.
Víctima: Un servidor web (Apache) con
AllowOverride Allhabilitado (esta es la vulnerabilidad clave).Carpeta de subida: Un directorio donde tengas permisos de escritura.
Paso 2: Creación de la htshell
En tu terminal de Kali, crearías un archivo
.htaccesscon una instrucción específica. Esta instrucción le dice al servidor que trate los archivos.antrax(o cualquier extensión inventada) como ejecutables de PHP:Apache# Archivo .htaccess AddType application/x-httpd-php .antraxPaso 3: El "Payload" (La carga útil)
Ahora creas un archivo llamado
exploit.antrax. Dentro de él, pones código PHP real:PHP<?php // Esto ejecutará el comando 'whoami' en el servidor echo shell_exec('whoami'); ?>Paso 4: La ejecución
Subes el archivo
.htaccessal servidor.Subes el archivo
exploit.antrax.Accedes desde tu navegador a
http://servidor.com/uploads/exploit.antrax.
Resultado: En lugar de ver el código como texto o un error, el servidor te devolverá el nombre del usuario que ejecuta el servicio web (ej.
www-data), confirmando que tienes ejecución remota de comandos (RCE).¿Por qué funciona esto?
El servidor Apache lee el archivo
.htaccessen cada solicitud. Al redefinir elAddType, cambias las reglas del juego en ese directorio específico.¿Cómo prevenirlo? (La parte ética)
Para evitar que esto pase en un servidor real, debes configurar el archivo principal de Apache (
httpd.confoapache2.conf) de la siguiente manera:Desactivar overrides: Cambiar
AllowOverride AllaAllowOverride None.Restringir archivos: Impedir que se suban archivos que empiecen por punto (
.).
Dado que Apache y Nginx manejan la configuración de forma muy distinta (Apache usa
.htaccessy Nginx no), aquí tienes los pasos para ambos.1. Configuración en Apache (El más común para htshells)
En Apache, el objetivo es anular la jerarquía de archivos y endurecer los permisos de las carpetas de subida.
Paso A: Desactivar overrides globalmente
Edita tu archivo de configuración principal (ej.
/etc/apache2/apache2.confo/etc/httpd/conf/httpd.conf):Apache<Directory /var/www/> Options Indexes FollowSymLinks AllowOverride None Require all granted </Directory>Nota: Al poner
AllowOverride None, el servidor ignorará cualquier archivo.htaccessque un atacante logre subir.Paso B: Bloqueo específico en carpetas de subida
Si necesitas usar
.htaccessen otras partes del sitio, protege específicamente tu carpeta de imágenes o archivos:Apache<Directory "/var/www/html/uploads"> # Deshabilita la ejecución de cualquier script php_admin_value engine off Options -ExecCGI -Indexes # Denegar acceso a cualquier archivo con extensiones peligrosas <FilesMatch "\.(php|phtml|php3|php4|php5|phps|pl|py|jsp|asp|sh|cgi)$"> Require all denied </FilesMatch> </Directory>2. Configuración en Nginx (Más seguro por defecto)
Nginx es inherentemente más resistente a las htshells porque no lee archivos de configuración dentro de las carpetas de datos (no existe el concepto de
.htaccess). Sin embargo, un atacante podría intentar subir un.phpy ejecutarlo directamente.Bloqueo de ejecución en directorios
En tu archivo de sitio (ej.
/etc/nginx/sites-available/default), añade una regla para tus carpetas de contenido estático:Nginxlocation /uploads/ { # Evita que se procesen archivos PHP en esta ruta location ~ \.php$ { deny all; } }3. Verificación de Permisos (Hardening de sistema)
Independientemente del servidor, los permisos de archivos son tu última línea de defensa. El usuario
www-data(oapache) no debe ser el dueño de los archivos que sirve.Cambiar el dueño a root o a tu usuario de despliegue:
sudo chown -R usuario:www-data /var/www/htmlAsegurar que los archivos no sean editables por el servidor:
sudo find /var/www/html -type f -exec chmod 644 {} \;sudo find /var/www/html -type d -exec chmod 755 {} \;
Resumen de Seguridad
Apache: Usa
AllowOverride None.Nginx: Ya es seguro, pero bloquea
location ~ \.php$en carpetas de subida.Sistema: Mantén los archivos con permisos de solo lectura para el servidor web.