JSP File Browser en Kali Linux

https://www.onlinetis.com/es/

JSP File Browser en Kali Linux

¿Qué es un JSP File Browser?

Es un archivo con extensión .jsp que, una vez ejecutado en el servidor, proporciona una interfaz gráfica en el navegador para:

Listar, copiar, mover y borrar archivos.
Subir y descargar herramientas o datos.
Editar archivos de configuración directamente en el servidor.
Ejecutar comandos del sistema (dependiendo de la versión).

Cómo encontrarlo en Kali Linux

Kali Linux ya viene con una colección de webshells preinstaladas. No necesitas descargarlas de sitios dudosos; están en tu sistema:

Abre la terminal.
Ve al directorio de webshells:
cd /usr/share/webshells/jsp/
Allí encontrarás archivos como jsp-reverse-shell.jsp o exploradores básicos.

Si buscas uno específico con interfaz completa (como el popular de Tomcat), es posible que debas buscar repositorios de confianza en GitHub, ya que los que vienen por defecto en Kali suelen ser scripts simples de una sola función.

Cómo usarlo (Paso a paso)

Si estás realizando una auditoría de seguridad autorizada:

Identifica el objetivo: Asegúrate de que el servidor soporte Java (usualmente puerto 8080 con Tomcat).
Sube el archivo: Utiliza una vulnerabilidad de subida de archivos o el panel de administración de Tomcat (si tienes credenciales).
Accede desde el navegador: Visita la URL donde subiste el archivo, por ejemplo:
http://[IP-OBJETIVO]:8080/nombre-de-tu-archivo.jsp
Interfaz en español: La mayoría de estos scripts están en inglés, pero al ser exploradores de archivos, los iconos y la estructura de carpetas son universales. Si necesitas traducción, puedes usar el traductor integrado de Chrome/Firefox sobre la página.

¡Cuidado! (Nota de Seguridad)

El uso de JSP File Browsers en servidores ajenos sin autorización es ilegal. Además, muchos scripts JSP que circulan por internet contienen "backdoors" (puertas traseras) que permiten que el autor original del script también tenga acceso a tu objetivo. Usa siempre los que vienen en Kali o revisa el código fuente.

Desde el punto de vista defensivo (Blue Teaming), detectar un JSP File Browser es crucial, ya que suelen ser el primer paso para una escalada de privilegios o la exfiltración de datos.

Aquí tienes los métodos más efectivos para encontrarlos y neutralizarlos:

1. Búsqueda de Archivos Sospechosos (Análisis Estático)

Si tienes acceso al servidor, puedes buscar archivos .jsp que no deberían estar allí. Los atacantes suelen esconderlos en directorios de librerías o carpetas temporales.

Usa este comando en Linux para buscar archivos JSP modificados recientemente o con nombres sospechosos:

Bash

find /var/lib/tomcat/webapps -name "*.jsp" -mtime -7

(Busca archivos creados o modificados en los últimos 7 días).

Palabras Clave en el Código

Los exploradores de archivos JSP necesitan funciones específicas para manejar el sistema. Puedes usar grep para buscar archivos que contengan funciones peligrosas:

java.io.File: Para manipular archivos.
Runtime.getRuntime().exec: Para ejecutar comandos de consola.
FileOutputStream: Para escribir archivos nuevos.

2. Análisis de Logs (Logs de Acceso)

Un indicio claro de un JSP File Browser es el tráfico inusual hacia un solo archivo JSP que recibe muchos parámetros GET o POST (como nombres de rutas o comandos).

Revisa los logs de acceso de Tomcat (usualmente en /var/log/tomcat/localhost_access_log...):

Patrón sospechoso: POST /uploads/cmd.jsp?dir=/etc/&cmd=cat+passwd
Frecuencia: Muchas peticiones seguidas al mismo archivo .jsp por parte de una sola IP externa.

3. Monitorización de Procesos

Si el "File Browser" permite ejecutar comandos, verás procesos hijos naciendo desde el proceso principal de Java.

Puedes monitorear esto en tiempo real con:

Bash

ps -efj | grep java

Si ves que el usuario tomcat o www-data está ejecutando comandos como whoami, ls -la /root, o nc (netcat), es una señal clara de compromiso.

4. Medidas de Prevención (Hardening)

Para evitar que estos archivos funcionen aunque logren subirlos:

Medida	Descripción
Principio de Menor Privilegio	Ejecuta Tomcat con un usuario sin permisos de shell (ej. `nologin`) y limita su escritura solo a carpetas específicas.
Read-Only File System	Monta los directorios de aplicaciones como "solo lectura" una vez desplegados.
WAF (Web Application Firewall)	Configura reglas para bloquear peticiones con palabras como `cmd=`, `exec(`, o rutas de sistema en la URL.
Deshabilitar la carga automática	En `server.xml`, asegúrate de que `autoDeploy="false"` y `deployOnStartup="false"` si no son necesarios.

Dato curioso: Muchos atacantes renombran sus archivos como index.jsp o error404.jsp dentro de subcarpetas profundas para que pasen desapercibidos en una revisión rápida.

Vamos a crear un script sencillo pero potente que puedes dejar programado (mediante un cronjob) o ejecutar manualmente para vigilar la salud de tu servidor.

Este script en Bash busca tres cosas críticas: archivos .jsp creados recientemente, palabras clave sospechosas dentro de ellos y procesos de shell ejecutados por el usuario de la web.

Script de Auditoría Rápida (`detect_jsp.sh`)

Bash
#!/bin/bash

# Configuración: Ruta de las aplicaciones web (ajusta según tu sistema)
WEBAPP_DIR="/var/lib/tomcat9/webapps"
LOG_FILE="/var/log/jsp_audit.log"

echo "--- Iniciando Escaneo de Seguridad $(date) ---" | tee -a $LOG_FILE

# 1. Buscar archivos JSP modificados en las últimas 24 horas
echo "[!] Archivos JSP nuevos o modificados recientemente:" | tee -a $LOG_FILE
find $WEBAPP_DIR -name "*.jsp" -mtime -1 >> $LOG_FILE

# 2. Buscar funciones de ejecución de comandos (RCE) en archivos JSP
echo "[!] Escaneando contenido sospechoso (Runtime.exec, ProcessBuilder):" | tee -a $LOG_FILE
grep -rnE "Runtime\.getRuntime\(\)\.exec|ProcessBuilder|FileOutputStream" $WEBAPP_DIR --include="*.jsp" >> $LOG_FILE

# 3. Verificar si el usuario tomcat está ejecutando procesos de shell
echo "[!] Verificando procesos de shell activos bajo el usuario tomcat:" | tee -a $LOG_FILE
ps -ef | grep -E "tomcat|www-data" | grep -E "sh|bash|cmd|python|perl" | grep -v grep >> $LOG_FILE

echo "--- Escaneo Finalizado ---" | tee -a $LOG_FILE

Cómo implementarlo correctamente

Crea el archivo: nano detect_jsp.sh
Pega el código anterior y guarda (Ctrl+O, Enter, Ctrl+X).
Dale permisos de ejecución:
chmod +x detect_jsp.sh
Ejecútalo con privilegios:
sudo ./detect_jsp.sh

¿Qué hacer si encuentras algo?

Si el script te devuelve resultados, no entres en pánico, pero actúa rápido:

Aísla el archivo: No lo borres de inmediato si necesitas investigar la procedencia, pero muévelo fuera del directorio web:
mv /ruta/al/archivo.jsp /root/quarantine/
Revisa los Logs de Red: Mira qué IP accedió a ese archivo específico en los logs de Tomcat para identificar al atacante.
Cierra el punto de entrada: Un JSP File Browser no aparece por arte de magia; suele entrar por una vulnerabilidad de File Upload o una consola de administración con contraseña débil.

Vamos a darle "músculos" a ese script para que no solo detecte, sino que te avise al instante. Para esto, utilizaremos la utilidad mail (o ssmtp) de Linux.

1. Preparar el sistema de alertas

Primero, asegúrate de tener instalado el paquete para enviar correos. En sistemas basados en Debian/Ubuntu/Kali:

Bash

sudo apt update && sudo apt install mailutils

2. Script con Alerta Automática (`jsp_guard.sh`)

He modificado el script para que guarde los hallazgos en una variable. Si esa variable tiene contenido, te enviará un correo con el reporte detallado.

Bash
#!/bin/bash

# --- CONFIGURACIÓN ---
WEBAPP_DIR="/var/lib/tomcat9/webapps"
EMAIL_DESTINO="tu-correo@ejemplo.com"
HOSTNAME=$(hostname)
REPORTE_TEMP="/tmp/reporte_seguridad.txt"

# Limpiar reporte anterior
echo "Reporte de Seguridad - Servidor: $HOSTNAME" > $REPORTE_TEMP
echo "Fecha: $(date)" >> $REPORTE_TEMP
echo "--------------------------------------" >> $REPORTE_TEMP

# 1. Buscar archivos JSP sospechosos (nuevos o con funciones peligrosas)
HALLAZGOS=$(find $WEBAPP_DIR -name "*.jsp" -mtime -1)
HALLAZGOS_CONTENIDO=$(grep -lRE "Runtime\.getRuntime\(\)\.exec|ProcessBuilder|FileOutputStream" $WEBAPP_DIR --include="*.jsp")

# 2. Consolidar hallazgos
if [ -n "$HALLAZGOS" ] || [ -n "$HALLAZGOS_CONTENIDO" ]; then
    echo "[ALERTA] Se detectaron archivos JSP sospechosos:" >> $REPORTE_TEMP
    echo "$HALLAZGOS" >> $REPORTE_TEMP
    echo "$HALLAZGOS_CONTENIDO" >> $REPORTE_TEMP
    
    # Enviar el correo
    cat $REPORTE_TEMP | mail -s "ALERTA DE SEGURIDAD: JSP Detectado en $HOSTNAME" $EMAIL_DESTINO
    echo "Alerta enviada a $EMAIL_DESTINO"
else
    echo "Todo limpio. No se detectaron anomalías."
fi

3. Automatización total con Cron

Para que no tengas que ejecutarlo tú, vamos a decirle al sistema que lo haga cada hora.

Abre el editor de tareas programadas:
sudo crontab -e
Elige tu editor favorito (nano es el más fácil) y añade esta línea al final del archivo:
0 * * * * /ruta/completa/al/script/jsp_guard.sh

¿Cómo funciona el flujo de protección?

El siguiente esquema resume cómo este sistema protege tu servidor frente a la subida de un JSP File Browser:

Un último consejo de "pro":

Si quieres ir un paso más allá, puedes cambiar la línea del correo por una acción defensiva real. Por ejemplo, que el script cambie los permisos del archivo detectado a 000 automáticamente:

chmod 000 $ARCHIVO_SOSPECHOSO

Esto "congela" el archivo para que el atacante no pueda ejecutarlo mientras tú llegas a revisar.

Vamos a convertir el script de un simple "vigilante" a un "sistema de respuesta activa". Con esta modificación, el script no solo te avisará, sino que quitará todos los permisos de ejecución y lectura al archivo sospechoso de inmediato, neutralizando la amenaza en milisegundos.

Aquí tienes la versión mejorada con Auto-Bloqueo:

Script de Respuesta Activa (`jsp_sentinel.sh`)

Bash
#!/bin/bash

# --- CONFIGURACIÓN ---
WEBAPP_DIR="/var/lib/tomcat9/webapps"
EMAIL_DESTINO="tu-correo@ejemplo.com"
REPORTE_TEMP="/tmp/jsp_active_response.txt"
QUARANTINE_DIR="/root/quarantine_jsp"

# Crear directorio de cuarentena si no existe
mkdir -p $QUARANTINE_DIR

echo "Iniciando Escaneo y Auto-Bloqueo: $(date)" > $REPORTE_TEMP

# 1. Identificar archivos con funciones peligrosas (RCE/File Browser)
# Buscamos archivos .jsp que contengan funciones de ejecución o escritura
ARCHIVOS_PELIGROSOS=$(grep -rE "Runtime\.getRuntime\(\)\.exec|ProcessBuilder|FileOutputStream|java\.io\.File" $WEBAPP_DIR --include="*.jsp" | cut -d: -f1 | sort -u)

if [ -n "$ARCHIVOS_PELIGROSOS" ]; then
    echo "[!!!] AMENAZA DETECTADA. Iniciando protocolos de bloqueo:" >> $REPORTE_TEMP
    
    for archivo in $ARCHIVOS_PELIGROSOS; do
        echo " - Bloqueando: $archivo" >> $REPORTE_TEMP
        
        # ACCIÓN DE BLOQUEO: Quitar todos los permisos (Lectura, Escritura, Ejecución)
        chmod 000 "$archivo"
        
        # OPCIONAL: Cambiar el dueño a root para que el usuario web no pueda recuperarlo
        chown root:root "$archivo"
        
        # Registrar el evento en el log del sistema
        logger "SEGURIDAD: JSP sospechoso bloqueado en $archivo"
    done

    # Enviar alerta urgente
    cat $REPORTE_TEMP | mail -s "URGENTE: Ataque JSP Neutralizado en $(hostname)" $EMAIL_DESTINO
    echo "Respuesta activa ejecutada. Revisa tu correo."
else
    echo "Sistema íntegro. No se requiere acción."
fi

¿Cómo funciona la arquitectura de este bloqueo?

El script actúa como una barrera entre el atacante y el sistema operativo. Una vez que el atacante sube su "JSP File Browser", el flujo es el siguiente:

Por qué esta configuración es efectiva:

chmod 000: Esto hace que el archivo sea invisible e inútil para el servidor web (Tomcat/Apache). Si el atacante intenta acceder a la URL, recibirá un error 403 Forbidden o 404.
chown root:root: Al cambiar el dueño, el proceso de Tomcat (que suele correr como un usuario limitado) no puede volver a cambiar los permisos del archivo para "arreglarlo".
logger: Envía el evento a /var/log/syslog, lo cual es genial si después quieres analizar el ataque con herramientas como Splunk o ELK.

Esta es la jugada maestra del "Gato y el Ratón". Vamos a configurar un Honeypot de Archivo (trampa).

La idea es dejar un archivo con un nombre tentador (como config_backup.jsp o admin_panel.jsp) que en realidad es un script que no hace nada malicioso, pero que registra la dirección IP, el navegador y la ubicación de quien intente abrirlo.

1. El Script de la "Trampa" (`honey_trap.jsp`)

Crea este archivo y colócalo en una carpeta pública de tu servidor Tomcat (por ejemplo, en /var/lib/tomcat9/webapps/ROOT/).

Java
<%@ page import="java.io.*,java.util.*" %>
<%
    // 1. Capturar datos del atacante
    String ip = request.getRemoteAddr();
    String userAgent = request.getHeader("User-Agent");
    String fecha = new Date().toString();
    
    // 2. Guardar el "log de captura" en un archivo oculto
    try {
        FileWriter fw = new FileWriter("/tmp/intruder_log.txt", true);
        fw.write("--- INTRUSO DETECTADO ---\n");
        fw.write("Fecha: " + fecha + "\n");
        fw.write("IP: " + ip + "\n");
        fw.write("Navegador: " + userAgent + "\n");
        fw.write("-------------------------\n\n");
        fw.close();
    } catch (Exception e) {}

    // 3. Mostrar un error falso para que el atacante no sospeche
    response.sendError(HttpServletResponse.SC_NOT_FOUND); 
%>

2. Por qué funciona este Honeypot

El Engaño: El atacante ve un archivo .jsp con un nombre interesante y trata de acceder.
La Captura: Antes de que cargue nada, el servidor ejecuta el código Java, guarda su IP en /tmp/intruder_log.txt y le envía un correo de alerta (si combinamos esto con el script anterior).
La Salida: El atacante recibe un error 404 Not Found. Pensará: "Vaya, el archivo no existe o lo borraron", pero tú ya tienes su IP.

3. Integración Total (Alerta en Tiempo Real)

Podemos modificar tu script de Bash anterior para que vigile específicamente este archivo de log de la trampa. Si alguien "muerde el anzuelo", el script te enviará un mensaje urgente.

Bash
#!/bin/bash
# Vigilante del Honeypot

LOG_TRAMPA="/tmp/intruder_log.txt"
ULTIMA_LINEA="/tmp/last_honeypot_line.txt"

# Si el log existe y ha crecido desde la última vez
if [ -f "$LOG_TRAMPA" ]; then
    NUM_LINEAS=$(wc -l < "$LOG_TRAMPA")
    ULTIMA=$(cat "$ULTIMA_LINEA" 2>/dev/null || echo 0)

    if [ "$NUM_LINEAS" -gt "$ULTIMA" ]; then
        echo "¡ALERTA! Alguien ha caído en la trampa JSP." | mail -s "Honeypot Activo: Intruso Detectado" tu-correo@ejemplo.com
        echo "$NUM_LINEAS" > "$ULTIMA_LINEA"
        
        # Opcional: Bloquear la IP del atacante automáticamente en el Firewall
        IP_ATACANTE=$(tail -n 5 "$LOG_TRAMPA" | grep "IP:" | cut -d' ' -f2)
        iptables -A INPUT -s "$IP_ATACANTE" -j DROP
    fi
fi

Resumen de tu Fortaleza Digital:

Vigilante: Escanea archivos modificados cada hora.
Escudo: Bloquea archivos sospechosos con chmod 000 al instante.
Trampa: Atrae al atacante a un archivo señuelo para obtener su IP.
Contraataque: Bloquea su IP en el Firewall (iptables) automáticamente.

Ahora vamos a pasar de la teoría a la práctica. Como administrador de seguridad, tu trabajo no termina al poner la alarma; tienes que probar si la alarma suena cuando alguien intenta entrar.

Para esto, usaremos Kali Linux como nuestro laboratorio de pruebas (Pentesting) contra tu propio servidor. Aquí tienes las tres herramientas clave para verificar tu nivel de protección:

1. Escaneo de Vulnerabilidades con Nikto

Nikto es un escáner de servidores web que busca archivos peligrosos, versiones desactualizadas y, curiosamente, buscó rutas comunes de shells JSP.

Comando en Kali:

Bash

nikto -h http://tu-ip-servidor:8080

Qué esperar: Nikto intentará encontrar archivos como cmd.jsp, shell.jsp o index.jsp en directorios comunes.
Prueba de fuego: Si creaste el Honeypot (honey_trap.jsp), Nikto lo detectará. Verás en tu archivo /tmp/intruder_log.txt que la IP de tu máquina Kali ha sido registrada inmediatamente.

2. Nmap: Buscando Puertas Abiertas

Nmap no solo ve puertos, tiene scripts (NSE) que pueden detectar si una consola de administración de Tomcat está expuesta, que es por donde suelen subirse los archivos JSP.

Comando en Kali:

Bash

nmap -p 8080 --script http-enum,http-tomcat-mgr-status tu-ip-servidor

Objetivo: Si Nmap encuentra /manager/html, significa que tu servidor es vulnerable a ataques de fuerza bruta. Si logran entrar ahí, pueden subir cualquier archivo JSP.

3. Verificación del Auto-Bloqueo (Simulación de Ataque)

Vamos a simular que un atacante logró subir un archivo malicioso.

En tu servidor (como atacante): Crea un archivo con una función prohibida:
echo '<% Runtime.getRuntime().exec(request.getParameter("cmd")); %>' > /var/lib/tomcat9/webapps/ROOT/ataque.jsp
Ejecuta tu script de protección:
sudo ./jsp_sentinel.sh
Comprueba el resultado:
Intenta leer el archivo: cat /var/lib/tomcat9/webapps/ROOT/ataque.jsp.
Si el script funcionó, verás que los permisos son ---------- (000) y no podrás ni leerlo ni ejecutarlo desde la web.

Resumen de Defensa en Capas

Para que visualices cómo has transformado un servidor vulnerable en una fortaleza, aquí tienes el esquema de tus nuevas capas de seguridad:

¿Qué hemos logrado?

Capa 1 (Prevención): Nmap y Nikto nos dicen qué cerrar.
Capa 2 (Detección): El Honeypot captura la IP del curioso.
Capa 3 (Respuesta): El script de Bash bloquea el archivo antes de que sea usado.
Capa 4 (Persistencia): El Firewall (iptables) expulsa al atacante definitivamente.

Buscar este blog