Categoría: Pruebas de seguridad (Testing)

  • Caso Práctico DS1: Análisis de Tráfico Web y Login con Wireshark (2)

    Caso Práctico DS1: Análisis de Tráfico Web y Login con Wireshark (2)

    Aprender a capturar y analizar tráfico de red con Wireshark, identificar credenciales transmitidas en claro, interpretar paquetes HTTP y localizar patrones que un pentester o analista usaría para detectar:

    • Credenciales expuestas
    • Cookies de sesión
    • Estructura de peticiones al servidor
    • Intentos de ataque (básico)
    • Fingerprinting indirecto del hosting

    1. Preparación del entorno

    1.1. Material necesario

    • Wireshark instalado
    • Navegador web
    • La URL de vuestra aplicación PHP en el hosting

    1.2. Configuración previa

    1. Abrir Wireshark
    2. Elegir la interfaz correcta:
      • En WiFi: suele ser wlan0 o similar
      • En cable: eth0
    3. Aplicad un filtro pre-captura opcional para no saturar: tcp port 80 or tcp port 443

    2. Captura del tráfico (la parte divertida)

    2.1. Comenzar la captura

    1. En Wireshark → seleccionad interfaz → botón azul Start capture.
    2. Dejad Wireshark escuchando en segundo plano.

    2.2. Generar tráfico real

    En vuestra aplicación PHP:

    1. Entrad en la página del login.
    2. Haced:
      • 1 intento fallido
      • 1 intento correcto
    3. Navegad un poco por el CRUD (listar, ver, editar).

    Esto genera tráfico muy fácil de reconocer.


    3. Filtrado y análisis del tráfico HTTP

    3.1. Filtrar solo HTTP

    En la barra de filtros de Wireshark:

    http
    

    Observad cómo aparecen las peticiones:

    • GET /login.php HTTP/1.1
    • POST /login.php HTTP/1.1
    • Peticiones a JS, CSS, etc.

    Entrega:

    • Captura del primer filtro HTTP mostrando al menos 8–10 paquetes.

    4. Análisis de un login (¡a por credenciales!)

    Vamos a buscar el POST del login.

    4.1. Filtro preciso del POST

    http.request.method == "POST"
    

    Seleccionad el paquete que corresponda a vuestro login.

    4.2. Abrir el contenido del POST

    En el panel inferior → Hypertext Transfer ProtocolForm-urlencoded.

    Deberíais ver algo como:

    username=juan
    password=1234
    

    (¡si la web no usa HTTPS y el hosting no lo fuerza!)

    4.3. Preguntas para entregar

    1. ¿El login viaja en claro o cifrado?
    2. Si viaja cifrado, ¿qué aparece en su lugar?
    3. Si viaja en claro, copiáis:
      • usuario
      • contraseña
      • parámetros adicionales

    💡 Esta parte impacta mucho: “Así de fácil es robar credenciales sin HTTPS.”


    5. Análisis de cookies y sesión

    5.1. Buscar cookies de sesión

    Filtro:

    http.set_cookie
    

    o:

    http.cookie
    

    Localizad:

    • PHPSESSID=xxxxxxx u otro identificador.

    5.2. Preguntas para entregar

    1. ¿La cookie tiene flags Secure, HttpOnly, SameSite?
    2. ¿Se envía en la misma petición del login?
    3. ¿Se reutiliza durante toda la sesión?
    4. ¿Podríais robarla si el tráfico no fuese HTTPS?

    6. Identificación de servidor y tecnologías mediante tráfico

    Aunque no usemos WhatWeb, Wireshark también revela cosas interesantes.

    6.1. Buscad cabeceras del servidor

    Filtro:

    http.server
    

    y:

    http.response
    

    Podéis encontrar:

    • Server: Apache/2.4.54
    • X-Powered-By: PHP/8.1.12

    7. Detectar patrones de ataque (mini-reto)

    Ahora vamos a “jugar” con el tráfico que vosotros mismos habéis generado.

    Hacer desde otra máquina:

    • un par de intentos de fuerza bruta
    • navegación rara
    • errores 404
    • probad rutas prohibidas

    7.1. Filtrar errores del servidor

    http.response.code >= 400
    

    7.2. Preguntas

    1. ¿Qué tipo de errores aparecen más?
    2. ¿Alguna IP destaca como “sospechosa”?
    3. ¿Puedes reconstruir qué intentaba hacer ese cliente?
      (por ejemplo: intentar acceder a /admin/ o /backup/)

    8. Bonus: reconstrucción de sesión (Follow TCP Stream)

    Seleccionad cualquier paquete HTTP → botón derecho:

    Follow → TCP Stream

    Miraréis la conversación completa entre cliente y servidor como si fuese un chat textual.

    Entrega:

    1. Captura del stream
    2. Comentad:
      • ¿Qué información sensible se ve?
      • ¿Podríais reproducir manualmente alguna petición?

    9. Conclusiones finales (informe corto)

    Cada alumno debe redactar:

    9.1. Hallazgos importantes

    • ¿Se ven credenciales?
    • ¿Se identifican cookies inseguras?
    • ¿Qué tecnologías se filtran?
    • ¿Alguna ruta interesante/extraña?

    9.2. Riesgos detectados

    3 riesgos mínimos (exposición de tecnología, falta de HTTPS, cookies inseguras…)

    9.3. Recomendaciones

    3 medidas de mejora:

    • Forzar HTTPS
    • Ocultar versión del servidor
    • Flag HttpOnly en cookies
    • Deshabilitar rutas innecesarias
  • Caso Práctico DS1: Fingerprinting y superficie de ataque (3)

    Caso Práctico DS1: Fingerprinting y superficie de ataque (3)

    enéis desplegada una pequeña aplicación PHP (CRUD + login) en un hosting compartido.

    En esta práctica vais a poneros en la piel de un analista de ciberseguridad que tiene permiso para auditar solo ese sitio web. El objetivo es:

    • Identificar tecnologías y versiones que usa la web (fingerprinting).
    • Descubrir rutas y ficheros interesantes (superficie de ataque).
    • Detectar posibles debilidades de configuración.

    ⚠️ Regla de oro: Solo podéis escanear el dominio/URL que os ha dado el profesor. Nada de escanear webs ajenas “por probar”.


    1. Preparación del entorno

    1.1. Datos que debes tener

    Anota en tu cuaderno o documento:

    • URL de la aplicación:
      Ejemplo: https://grupoX.miapp.ejemplo.com
    • (Opcional) IP del servidor si el profe la da:
      Ejemplo: 123.45.67.89

    1.2. Herramientas a usar

    En un Linux (real o máquina virtual) instalad, si no están:

    sudo apt update
    
    # WhatWeb (fingerprinting web)
    sudo apt install whatweb -y
    
    # Nikto (escáner de vulnerabilidades web)
    sudo apt install nikto -y
    
    # Gobuster (fuerza bruta de directorios)
    sudo apt install gobuster -y
    
    # Wordlist básica (si no la tenéis)
    sudo apt install wordlists -y
    

    Comprobad que funcionan:

    whatweb --version
    nikto -Version
    gobuster -h
    

    2. Fingerprinting básico del servidor web (WhatWeb + cabeceras)

    2.1. Resolver el dominio

    1. Desde la terminal, comprobad a qué IP resuelve vuestro dominio:
    ping -c 3 TU_DOMINIO
    

    Sustituye TU_DOMINIO por tu URL (sin https://).
    Ejemplo:

    ping -c 3 grupoX.miapp.ejemplo.com
    
    1. Anota:
      • IP a la que resuelve
      • Tiempo de respuesta aproximado

    Entrega: captura de pantalla o copia del comando y el resultado.


    2.2. Cabeceras HTTP con curl

    Queremos ver qué nos cuenta el servidor solo con las cabeceras.

    1. Ejecuta:
    curl -I https://TU_DOMINIO
    
    1. Fíjate en:
    • Server: (Apache, Nginx, etc., ¿con versión?)
    • X-Powered-By: (¿PHP con versión?)
    • Si hay algo como Set-Cookie:, etc.

    Entrega:

    • copia de las cabeceras
    • responde brevemente:
      • ¿Se está filtrando la versión exacta del servidor o PHP?

    2.3. Fingerprinting con WhatWeb

    Ahora usamos WhatWeb para identificar tecnologías:

    whatweb https://TU_DOMINIO
    

    Si quieres más detalle:

    whatweb -v https://TU_DOMINIO
    

    Analiza:

    • ¿Detecta CMS (WordPress, etc.)?
    • ¿Versiones de Apache/PHP?
    • ¿Librerías JS, frameworks?

    Entrega:

    • salida de WhatWeb (resumen)
    • lista de tecnologías detectadas
    • marca con un asterisco las que muestren versión concreta, ejemplo:
      • PHP 8.1.12 *
      • Apache 2.4.54 *

    3. Análisis de configuración con Nikto

    Nikto es un escáner de vulnerabilidades web orientado a configuración y ficheros por defecto.

    3.1. Lanzar un escaneo básico

    Ejecuta:

    nikto -h https://TU_DOMINIO
    

    Según el hosting puede tardar un poco.

    Mientras tanto, ve leyendo las líneas: muchas veces indican ficheros interesantes, redirecciones, opciones inseguras, etc.

    3.2. Interpretar resultados

    Cuando termine, revisa:

    • ¿Detecta archivos o directorios por defecto (ej: /phpinfo.php, /server-status, /test/)?
    • ¿Algún mensaje tipo “OSVDB”, “might be vulnerable to…”?
    • ¿Alguna recomendación de deshabilitar cosas?

    Entrega:

    1. Lista de 3–5 hallazgos relevantes de Nikto. Para cada uno:
      • Qué ha encontrado (ruta / mensaje).
      • Por qué podría ser un problema.
    2. Indica si crees que hay algo que debería deshabilitarse/eliminarse en el servidor.

    (Si el hosting está muy capado y Nikto no ve casi nada, eso también es un hallazgo: coméntalo.)


    4. Fuerza bruta de rutas y directorios con Gobuster

    Aquí empezamos a descubrir “piezas” ocultas de la aplicación: paneles, copias de seguridad, etc.

    4.1. Elección de wordlist

    Usaremos una wordlist relativamente pequeña para no machacar el hosting.

    Por ejemplo:

    ls /usr/share/wordlists/dirb/
    

    Una habitual:

    • /usr/share/wordlists/dirb/common.txt

    4.2. Lanzar Gobuster (modo dir)

    Comando base:

    gobuster dir \
      -u https://TU_DOMINIO \
      -w /usr/share/wordlists/dirb/common.txt \
      -t 30 \
      -x php,txt,html
    

    Explicación:

    • -u: URL objetivo
    • -w: wordlist
    • -t: hilos (no os flipéis, que es un hosting compartido)
    • -x: extensiones a probar (.php, .txt, .html)

    4.3. Analizar resultados

    Fíjate en entradas con códigos de estado interesantes:

    • 200 → existe y responde bien
    • 301/302 → redirecciones
    • 403 → existe pero está prohibido (¡ojo, puede haber algo interesante detrás!)

    Entrega:

    • Lista de rutas interesantes encontradas. Ejemplo:
      • /admin/ (200)
      • /backup/ (403)
      • /old/ (200)
    • Para cada una, explica:
      • ¿Crees que deberían ser accesibles?
      • ¿Podrían contener datos sensibles?

    5. Mini-conclusiones de seguridad

    Al final de la práctica, responde a estas preguntas en un pequeño informe (1–2 páginas):

    1. Fingerprinting
      • ¿Qué servidor web y versión usa vuestro hosting?
      • ¿Qué versión de PHP se expone (si es visible)?
      • ¿Se muestran cabeceras innecesarias (X-Powered-By, etc.)?
    2. Superficie de ataque
      • ¿Qué directorios ocultos/localizaciones interesantes habéis encontrado?
      • ¿Habéis visto algún archivo de configuración, backup, antiguo…?
    3. Riesgos
      • Señala al menos 3 riesgos potenciales que habéis identificado.
      • Para cada uno, describe:
        • Cómo lo habéis descubierto (herramienta + comando).
        • Qué podría hacer un atacante con ello.
    4. Recomendaciones
      • Escribe 3 medidas que propondrías al responsable del hosting:
        • Ejemplos: ocultar versión de servidor, borrar backups públicos, restringir /admin, etc.