¿Alguna vez te has preguntado qué tan seguro es realmente un sitio web que visitas a diario?, ¡Pues estas en el Lugar Correcto!. En el marco de la asignatura Hacking Ético de la Universidad Central, un equipo de estudiantes de Ingeniería de Sistemas realizó una auditoría de seguridad completa sobre un sitio e-commerce montado en WordPress, alojado en Hostinger, con el único propósito de identificar vulnerabilidades reales, documentarlas y aprender a corregirlas. Este artículo resume ese laboratorio de pentesting paso a paso, desde el contrato de autorización hasta el análisis de las 10 categorías del OWASP Top 10 2021.
Si te interesa la ciberseguridad, el desarrollo web o simplemente quieres saber qué tan expuesto puede estar un sitio en WordPress, sigue leyendo. Lo que encontramos puede sorprenderte.
¿Qué es el Hacking Ético y por qué es Obligatorio Tener un Contrato?
El hacking ético, también conocido como pentesting o prueba de penetración, consiste en simular ataques informáticos reales sobre un sistema, con permiso explícito del propietario, para identificar y corregir vulnerabilidades antes de que un atacante malicioso lo haga. La diferencia entre un auditor ético y un ciberdelincuente no está en las herramientas que usan, sino en un único documento: el contrato de autorización.
En Colombia, la Ley 1273 de 2009 tipifica como delito el acceso no autorizado a sistemas informáticos, con penas de hasta ocho años de prisión. Escanear o intentar vulnerar un sistema sin autorización escrita viola las buenas prácticas del sector, recogidas en estándares como PTES, NIST SP 800-115 y la OWASP Testing Guide, independientemente de que el sistema sea propio o de terceros.
Por esta razón, antes de ejecutar cualquier prueba, el equipo firmó un contrato de autorización formal que detallaba el alcance de las pruebas, las restricciones, las responsabilidades de cada parte y las ventanas de tiempo autorizadas para el trabajo.
El objetivo del laboratorio fue un sitio e-commerce construido y administrado por el propio equipo auditor, lo que garantizó que todas las pruebas se realizaran en un entorno controlado sin afectar sistemas de terceros. El sitio presentaba la siguiente configuración técnica:
Plataforma: WordPress 6.9.4 con WooCommerce 10.6.1
Tema: Flash Pro v2.4.17 de ThemeGrill
Hosting: Hostinger con servidor LiteSpeed
Backend: PHP 8.3.30 y MariaDB 11.8.6
Plugins activos: 19
Productos en tienda: 20 (simples y variables)
Páginas: tienda, checkout, catálogo, blog, acerca de nosotros, PQR y
La auditoría se estructuró en tres grandes fases: (1) Reconocimiento de Red, (2) Análisis DNS, WHOIS y Certificados SSL/TLS, y (3) Evaluación de Vulnerabilidades basada en el OWASP Top 10 2021.
El reconocimiento es la primera etapa de cualquier pentesting profesional. Consiste en recopilar la mayor cantidad posible de información sobre el objetivo antes de ejecutar pruebas intrusivas. Existen dos tipos: el reconocimiento pasivo, que utiliza fuentes de información pública (OSINT) sin generar tráfico directo al servidor; y el reconocimiento activo, que sí establece contacto directo con el sistema mediante herramientas como ping, traceroute o escaneos de puertos.
Prueba de Conectividad con Ping
La herramienta ping utiliza el protocolo ICMP para verificar si un servidor está en línea. Más allá de confirmar la conectividad, en pentesting permite identificar la dirección IP que resuelve el dominio, la latencia y la posible presencia de un CDN.
Al ejecutar el comando sobre el sitio auditado, se identificaron dos direcciones IP de respuesta distintas en tres ejecuciones consecutivas: 191.101.104.113 y 191.96.144.240. Este comportamiento confirmó el uso de balanceo de carga dentro de la red CDN de Hostinger, lo que oculta la IP real del servidor de origen y dificulta los ataques directos de denegación de servicio (DoS/DDoS). La latencia promedio fue inferior a 100 ms, con 0 % de pérdida de paquetes.
Resultado obtenido:
Trazado de Ruta con Traceroute
El traceroute mapea los saltos de red entre el equipo del auditor y el servidor destino. Se utilizó la variante TCP con el flag -T -p 80 para atravesar los filtros de firewall corporativo, ya que muchos dispositivos bloquean ICMP pero permiten TCP en el puerto 80 para no interrumpir el tráfico web. El resultado confirmó que el CDN hcdn de Hostinger actúa como proxy inverso, ocultando por completo la ruta interna y la IP de producción: una fortaleza importante frente a atacantes externos.
Resultados Explicación comandos realizados:
Primer comando: asteriscos (* * *) después del primer salto (10.0.2.2).
Segundo comando: (TCP en puerto 80): se logra llegar a 191.101.104.121 pero sin mostrar los saltos intermedios.
Análisis:
La falta de respuestas se debe a que los routers intermedios (y el CDN) están configurados para no responder a traceroute. Esto es una buena práctica defensiva que dificulta el mapeo de la red por parte de atacantes. Solo se confirma que el tráfico sale de la máquina virtual y llega al datacenter de Hostinger.
Hallazgo obtenido:
El traceroute ICMP estándar mostró únicamente la puerta de enlace local (10.0.2.2 de la VM) y luego todos los saltos como * * *, indicando que los routers del CDN están configurados para no responder a ICMP Time Exceeded medida de seguridad estándar. Con el protocolo TCP (-T -p 80) se logró identificar el primer salto público: 191.101.104.121, perteneciente a la infraestructura CDN de Hostinger. La ruta completa permanece oculta por diseño , lo que constituye una FORTALEZA de la infraestructura.
Obtención de la IP Pública:
En Pentesting es fundamental conocer tanto la IP pública del atacante (para verificar cuál identidad tiene en internet) como la IP pública del objetivo (para saber a qué dirección apunta el dominio).
IP pública del equipo pentester:
Este comando hace una solicitud HTTP a un servicio externo que devuelve la IP pública desde la que se está enviando la petición, es decir, la IP pública del equipo pentester. Útil para verificar si el equipo está usando VPN o proxy.
IP pública del dominio objetivo:
Escaneo de Puertos con Nmap
El escaneo de puertos identificó qué servicios estaba exponiendo el servidor. Se ejecutaron tres variantes progresivas:
nmap -F: escaneo rápido de los 100 puertos más comunes. Resultado: únicamente los puertos 80 (HTTP) y 443 (HTTPS) aparecieron abiertos.
nmap -sV: detección de versiones de servicios.
Resultado: servidor web nginx identificado con sus versiones de HTTP soportadas. La exposición de la versión exacta de nginx representa una vulnerabilidad de A05 (Security Misconfiguration), pues un atacante puede buscar CVEs específicos de esa versión.
nmap -A: escaneo completo que incluye detección de sistema operativo, scripts NSE y traceroute. Confirmó el uso de CDN hcdn y balanceo de carga activo.
Fortaleza Identificada:
En cuanto al análisis de los puertos, se evidencia la correlación de los puertos abiertos con sus servicios. El puerto 80 (HTTP) redirige al 443, mientras que el 443 (HTTPS) es el que realmente sirve el contenido. Un sitio bien configurado no debería tener otros puertos abiertos, por lo que esto nos indica que vamos bien. Adicionalmente, la detección de nginx es un hallazgo de seguridad en sí mismo. Explica que exponer la versión del servidor web (por ejemplo, nginx/1.18.0) ayuda a un atacante a buscar exploits específicos. La mejor práctica es ocultar la versión del servidor.
Fase 2: Análisis DNS, WHOIS y Certificados SSL/TLS
La segunda fase aplicó técnicas de reconocimiento pasivo mediante OSINT para analizar la infraestructura pública del dominio sin generar tráfico intrusivo al servidor.
Consultas DNS: Mapeando la Infraestructura
Los registros DNS son la agenda telefónica de internet. Al consultarlos se puede obtener información valiosa sobre la arquitectura de un sitio:
Registro A: el dominio auditado no apuntaba directamente a un servidor, sino a un alias CNAME que redirigía hacia la infraestructura CDN de Hostinger (free.cdn.hstgr.net), con dos IPs de balanceo simultáneas.
Registro MX: la ausencia de servidores de correo tradicionales expuestos confirmó la delegación total de la gestión DNS a Cloudflare (emily.ns.cloudflare.com y terin.ns.cloudflare.com).
Registro TXT: reveló la política SPF configurada como “v=spf1 -all” (Hard Fail), lo que significa que ninguna dirección IP está autorizada para enviar correos usando el dominio, bloqueando el spoofing de correo electrónico.
Análisis WHOIS: Privacidad del Dominio Verificada
La consulta WHOIS confirmó que los datos personales del propietario están protegidos mediante WHOIS Privacy, cumpliendo con los estándares de privacidad en internet. El registrante identificado fue HOSTINGER operations, UAB. El dominio contaba con el estado clientTransferProhibited activo, lo que bloquea transferencias no autorizadas y previene el secuestro del dominio (domain hijacking).
Análisis de Mejores Prácticas:
¿La información está protegida por Privacidad de Dominio?: Sí. La base de datos WHOIS de VeriSign no expone datos personales de contacto (nombre, teléfono o correo) del propietario real del sitio web. Solo exhibe la información corporativa del registrador base (Hostinger), cumpliendo con estándares actuales de privacidad en internet y dificultando labores de ingeniería social.
Análisis de Certificados SSL/TLS
SSL (Secure Sockets Layer) y su sucesor TLS (Transport Layer Security) son protocolos criptográficos que garantizan la confidencialidad, integridad y autenticidad de las comunicaciones entre el navegador del usuario y el servidor web. La presencia del candado verde y el prefijo HTTPS en la URL indica que la comunicación está cifrada.
Un certificado SSL contiene: el nombre del dominio para el cual fue emitido (CN – Common Name), el nombre de la autoridad certificadora (CA) que lo emitió, la clave pública del servidor, las fechas de validez (inicio y expiración), y la firma digital de la CA.
Mediante el comando openssl s_client se analizó la cadena completa del certificado. Los hallazgos fueron positivos:
Protocolo: TLSv1.3 (el más moderno y seguro según el RFC 8446)
Cifrador: TLS_AES_256_GCM_SHA384 (estándar de alta seguridad)
Tipo: Wildcard (*.hostingersite.com, cubre todos los subdominios)
Autoridad Certificadora: DigiCert Inc → RapidSSL TLS RSA CA G1
Vigencia: 26 de marzo de 2026 al 10 de octubre de 2026
Sin embargo, se detectó una advertencia importante: la compresión HTTP activa (‘deflate’) junto con HTTPS activa la vulnerabilidad BREACH (CVE-2013-3587), que podría permitir a un atacante con posición Man-in-the-Middle deducir tokens CSRF midiendo el tamaño de las respuestas comprimidas.
Fortaleza criptográfica confirmada:
TLSv1.3 con AES-256-GCM-SHA384 es el estándar de cifrado más seguro disponible. La CA emisora DigiCert/RapidSSL es de máxima confianza global. El certificado Wildcard con vigencia corta (6 meses) reduce la ventana de exposición ante una eventual compromisión de la clave privada.
Identificar Subdominios y Servicios Asociados (NS)
Los subdominios pueden revelar servicios adicionales de la organización: paneles de administración (admin.dominio.com), entornos de desarrollo o staging (dev.dominio.com, test.dominio.com), servicios de correo (mail.dominio.com), o aplicaciones secundarias que pueden tener menos medidas de seguridad que el sitio principal. En nuestro caso, el profesor indicó que se montó un subdominio adicional para la práctica.
Este comando revela las direcciones de los “Name Servers” (Servidores de Nombre de Dominio) que tienen la autoridad técnica para indicar a dónde debe ir el tráfico de la web.
Hallazgo: Los servidores NS son EMILY.NS.CLOUDFLARE.COM y TERIN.NS.CLOUDFLARE.COM. Cloudflare actúa como capa de protección DNS adicional, enrutando el tráfico a través de su red global antes de llegar a Hostinger.
Fase 3: Vulnerabilidades OWASP Top 10 2021 — Los Hallazgos Más Críticos
La tercera fase fue la más técnica e impactante. OWASP (Open Web Application Security Project) es una fundación sin ánimo de lucro que publica la lista de las 10 vulnerabilidades web más críticas y frecuentes. La versión 2021 fue la que se aplicó sobre el sitio auditado.
A01: Broken Access Control — El Archivo que No Debería Verse
Ocurre cuando los usuarios acceden a recursos o funciones fuera de sus permisos, incluyendo: ver datos de otros usuarios, funciones administrativas sin autorización ni autenticación, o archivos de configuración sensibles y críticos expuestos públicamente. Por ejemplo, un usuario no administrador accediendo al panel de WordPress, o cualquier usuario pudiendo ver pedidos de otros clientes. Es la vulnerabilidad #1 de OWASP 2021 por su alta prevalencia en aplicaciones web reales.
El archivo wp-config.php es el más crítico de cualquier instalación WordPress: contiene las credenciales de la base de datos, las claves secretas de autenticación y los parámetros de configuración central. Al ejecutar una petición HTTP HEAD sobre este archivo con el comando curl -I, el servidor respondió con HTTP 200, lo que significó que cualquier usuario de internet podía acceder a él sin ningún tipo de autenticación. Este hallazgo tiene un CVSS v3 estimado de 9.8 (CRÍTICO) y comprometería absolutamente todos los datos del sitio: usuarios, transacciones y claves secretas.
Adicionalmente, el panel de administración /wp-admin no tenía protección adicional más allá del formulario de login, el cual no presentaba límite de intentos fallidos, exponiendo el sistema a ataques de fuerza bruta.
A02: Fallos Criptográficos — TLS 1.3 como Fortaleza, BREACH como Advertencia
Antes conocida como ‘Exposición de Datos Sensibles’. Se centra en fallas en el cifrado de datos en tránsito (comunicaciones sin cifrar o con cifrado débil) y en reposo (contraseñas en texto plano, claves expuestas). Incluye: uso de algoritmos obsoletos (MD5, SHA1, RC4), certificados expirados o autofirmados,protocolo TLS desactualizado (1.0/1.1), y ausencia de cifrado y transmisión de datos sensibles sin cifrar.
El escaneo con el script NSE ssl-enum-ciphers de Nmap confirmó que el servidor soporta TLS 1.2 y TLS 1.3, sin cipher suites inseguros. Sin embargo, la compresión HTTP activa mantuvo la vulnerabilidad BREACH catalogada en severidad media.
A03: Inyección SQL y XSS — El WAF como Primera Línea de Defensa
Los ataques de inyección ocurren cuando datos no confiables son enviados a un intérprete como parte de un comando o consulta. SQL Injection manipula consultas a la base de datos. Mientras que Cross-Site Scripting (XSS) inyecta scripts maliciosos en páginas web vistas por otros usuarios. En OWASP 2021, XSS quedó incluido dentro de A03, junto con SQL, NoSQL, LDAP, OS command injection y otras formas de inyección.
WordPress tiene múltiples puntos de entrada de datos: buscador interno (?s=), ¿parámetros de productos (?product_id=), campos de formularios de contacto/PQR (Everest Forms), y el formulario de login (/wp-login.php).
Estos se probaron en: ¿campo de búsqueda (?s=), campos del formulario de contacto y PQR (Everest Forms), y campos del checkout de WooCommerce. Los payloads deben ingresarse en cada campo y verificar si el script se ejecuta (alert box aparece en el navegador = XSS confirmado) o si el contenido se codifica/escapa correctamente. WordPress sanitiza la mayoría de las entradas con funciones como sanitize_text_field() y esc_html(), pero plugins de terceros pueden omitir esta sanitización.
Segunda Forma SQL Injection – SQLMap
Las pruebas con SQLMap sobre el formulario de PQR (Peticiones, Quejas y Reclamos) resultaron en una respuesta HTTP 403 desde el primer intento, indicando que el WAF de Hostinger y Cloudflare detectó y bloqueó automáticamente los patrones de escaneo automatizado. Si bien esto es una fortaleza, los WAFs no son protección absoluta: técnicas de evasión como codificación URL o payloads polimórficos pueden sortearlos. La protección real contra inyección debe implementarse a nivel de código con consultas parametrizadas (prepared statements).
A04: Diseño Inseguro — Login sin Límite de Intentos
Categoría nueva en OWASP 2021 que se enfoca en riesgos derivados de decisiones de diseño arquitectónico incorrectas, no de errores de implementación. Un sistema puede estar bien codificado, pero mal diseñado, desde el inicio. La clave es que estos problemas no pueden ser corregidos sólo con mejor código: requieren rediseño de la solución.
Se realizaron más de cinco intentos de login fallidos consecutivos en /wp-login.php con credenciales incorrectas. El sistema no bloqueó el acceso, no mostró CAPTCHA, no activó ningún lockout temporal y no alertó al administrador. Esto expone el sitio a ataques automatizados con diccionarios como rockyou.txt (14 millones de contraseñas), usando herramientas como Hydra o Burp Suite Intruder. La URL estándar /wp-login.php es conocida por todos los atacantes y ninguna capa adicional de protección la resguardaba.
La ausencia de bloqueo de intentos de login expone el sitio a ataques de fuerza bruta y diccionario. Un atacante puede automatizar miles de intentos por segundo con herramientas como Hydra o Burp Suite Intruder, probando contraseñas comunes (admin/123456, admin/password) o diccionarios como rockyou.txt (14 millones de contraseñas) usando comandos comohydra -l admin -P /usr/share/wordlists/rockyou.txt palevioletred-wildcat-394676.hostingersite.com http-post-form ‘/wp-login.php:log=^USER^&pwd=^PASS^:ERROR’. La falta de bloqueo es una falla de diseño que debió corregirse desde la configuración inicial del sitio.
A05: Configuración Incorrecta de Seguridad — Cuatro Vulnerabilidades en los Headers
Incluye: uso de configuraciones por defecto inseguras, permisos mal configurados, mensajes de error demasiado detallados que revelan información del sistema, funcionalidades habilitadas innecesariamente, y falta de headers (encabezados) HTTP de seguridad faltantes, versiones de software expuestas, funcionalidades habilitadas innecesariamente, y mensajes de error demasiado detallados. Absorbe la categoría anterior de XXE (Entidades Externas XML).
¿Qué es Nikto?: Nikto es un escáner de servidores web open source que verifica más de 6,700 archivos potencialmente peligrosos, versiones desactualizadas de servidores, y problemas de configuración. Genera un informe detallado de: headers de seguridad faltantes, archivos/directorios sensibles accesibles, versiones de software expuestas, y posibles vectores de ataque.
El escáner Nikto identificó cuatro vulnerabilidades derivadas de headers HTTP ausentes o mal configurados:
Clickjacking: ausencia de X-Frame-Options. El sitio puede ser embebido en iframes maliciosos para engañar a usuarios y robar datos de pago.
MIME Sniffing: ausencia de X-Content-Type-Options. Un archivo malicioso podría ser ejecutado como script por el navegador.
SSL Stripping: ausencia de HSTS (HTTP Strict Transport Security). Un atacante MitM puede interceptar la conexión antes de la redirección a HTTPS.
compresión HTTP activa (deflate) junto con HTTPS, que permite deducir tokens CSRF midiendo el tamaño de las respuestas. Adicionalmente, las versiones de PHP (8.3.30) y nginx estaban expuestas en los headers del servidor.
Uso de bibliotecas, frameworks, plugins, temas o cualquier componente de software con versiones desactualizadas que tienen vulnerabilidades conocidas (CVEs) o que ya no reciben soporte de seguridad. El 97% de las aplicaciones web tiene al menos un componente vulnerable según el OWASP Top 10 2021.4
IDENTIFICACIÓN DE PLUGINS CON WPSCAN
¿Qué es WPScan? WPScan es el escáner de seguridad más especializado del mundo para sitios WordPress. Detecta plugins instalados y sus versiones, temas WordPress y sus versiones, usuarios registrados, configuraciones inseguras específicas de WordPress, y vulnerabilidades conocidas (CVEs) usando su base de datos actualizada diariamente.
WPScan identificó que Font Awesome 5.1.4 ya no recibe actualizaciones de seguridad y que WooCommerce tenía disponible una versión más reciente. La carga de Font Awesome desde un CDN externo representa además un riesgo de supply chain attack. La verificación en el NVD (National Vulnerability Database) de nvd.nist.gov es la práctica recomendada para cada componente instalado.
A07: Fallos de Autenticación — xmlrpc.php, la Puerta Trasera de WordPress
Debilidades en los mecanismos de autenticación y gestión de sesiones que permiten a atacantes suplantar identidades. Incluye: contraseñas débiles, ausencia de MFA, gestión insegura de sesiones, exposición de identificadores de sesión, y endpoints de autenticación alternativos no protegidos como xmlrpc.php.
Este fue uno de los hallazgos más críticos del laboratorio. El archivo xmlrpc.php, una API heredada de WordPress, estaba activo y exponía el método system.multicall, que permite enviar hasta 500 intentos de autenticación en UN SOLO request HTTP. Esto elude completamente los límites de intentos configurados en /wp-login.php, ya que los plugins de seguridad protegen la ruta de login estándar, pero no esta API alternativa. Adicionalmente, el método pingback.ping habilitado puede usarse como vector de amplificación para ataques DDoS.
A08: Integridad del Software — El Repositorio Git Expuesto
Cubre situaciones donde el código o los datos no tienen verificación de integridad. Incluye exposición de repositorios Git (.git/config), pipelines CI/CD sin protección, actualizaciones sin verificación de firma, y deserialización insegura de objetos La exposición de. git permite reconstruir el código fuente completo. Incluye, en el contexto de WordPress, la instalación de plugins desde fuentes no verificadas, actualizaciones automáticas sin control, y posible manipulación de plugins/temas.
Prueba Ejecutada (Git Bash):
El servidor retorna HTTP 403 (Forbidden) a las peticiones de. git/config y .git/HEAD, confirmando que el directorio. git no es accesible públicamente. El sitio NO es vulnerable a este vector de ataque, está correctamente protegido contra este vector de ataque.Indicando que la infraestructura protege proactivamente los directorios sensibles.
prueba de enumeración de repositorios Git expuestos.
El resultado obtenido nos permite reconocer que el dominio existe, responde correctamente y tiene conectividad; el servidor acepta conexiones TLS y HTTPS funciona correctamente La conexión se realiza de forma segura mediante SSL/TLS
Prueba verificación de exposición de archivos internos Git
La respuesta obtenida, CRYPT_E_NO_REVOCATION_CHECK, nos indica que Windows (Git Bash usa Schannel) intentó resolver el dominio. establecer conexión HTTPS y validar el certificado SSL/TLS, pero falló porque no pudo verificar el estado de revocación del certificado. En pocas palabras, el equipo sí logró encontrar al servidor, iniciar conexión HTTPS, contactar al sitio, pero no pudo validar completamente el certificado SSL.
Prueba para verificar si un servidor expone archivos internos del repositori
El resultado obtenido nos indicó una resolución DNS exitosa,El dominio responde correctamente, Conexión HTTPS exitosa lo que indica que el TLS/SSL funciona correctamente. Negociación HTTP exitosa al comando GET /.git/HEAD HTTP/1.1 el servidor responde HTTP/1.1 403 Forbidden, esto significa que el servidor reconoció la ruta .git/HEAD, procesó correctamente la solicitud y decidió bloquear el acceso.
Esto es muy importante porque es lo que nos indica que el recurso está protegido. Desde OWASP esto es una mitigación correcta ya que el servidor está evitando exposición del repositorio, fuga de código fuente y acceso a archivos internos Git.
prueba de la conexión HTTPS y obtener una respuesta HTTP real del servidor.
El resultado nos muestra que la descarga fue exitosa, el repositorio quedó correctamente instalado en nuestro equipo. Lo que representa un riesgo potencial ya que Si el sitio expusiera. git, GitTools el atacante podría: descargar el repositorio, reconstruir commits y recuperar archivos eliminados. Lo que comprometería la confidencialidad, integridad y seguridad del software.
Prueba para Verificar configuración SSL externamente
El resultado CONNECTED (00000228) nos indica que el cliente logró conectarse correctamente al servidor HTTPS. Con el resultado depth=2 C=GB, O=Sectigo Limited…
verify return:1
Se verificó que el certificado era válido,confiables, no ha expirado y está firmado por una CA reconocida.
A09: Registro y Monitoreo — Evidencia Indirecta de Vigilancia Activa
Esta categoría no puede evaluarse directamente sin acceso al servidor. Sin embargo, la evidencia de las pruebas A03 permite inferir el estado del monitoreo: cuando SQLMap ejecutó sus primeras peticiones de escaneo automatizado, el servidor respondió automáticamente con HTTP 403 desde el primer request, sin intervención manual. Esto indica que el WAF de la infraestructura está monitoreando activamente el tráfico, detecta patrones de herramientas de escaneo conocidas (SQLMap tiene firmas reconocibles) y responde en tiempo real.
Pruebas realizadas desde el Cliente Git Bash para realizar una evaluación INDIRECTA del monitoreo
PRUEBA 1 — Detectar monitoreo de User-Agent malicioso
El resultado nos dice que el servidor NO bloqueó inmediatamente el User-Agent sqlmap, Permitió la conexión normal y Respondió correctamente con HTTP 200, lo cuál es un resultado muy bueno. Sin embargo, Esto NO significa ausencia de monitoreo , ya que muchas soluciones WAF modernas analizan payloads, parámetros maliciosos, patrones de inyección, frecuencia, comportamiento y reputación IP;NO solamente el User-Agent.
PRUEBA 2 — Detectar monitoreo de User-Agent malicioso
Este comando envía múltiples peticiones rápidas. Lo que se busca al ejecutarlo es determinar si el servidor detecta tráfico anómalo y si existen controles anti-bot, generando bloqueos automáticos para detenerlos. Mediante este se busca evaluar: monitoreo de accesos repetitivos, detección de fuerza bruta, respuestas automáticas,rate limiting y logging de eventos
PRUEBA 3 — Verificar monitoreo de rutas sensibles
Con esto se realiza el intentó de acceder al panel administrativo WordPress, ante esto, WordPress nos dirige automáticamente a: /wp-admin → /wp-admin/. Internamente esto hace que el sistema registre acceso a /wp-admin, detecte accesos repetitivos, correlacione IP y generar alertas
PRUEBA 4 — Verificar protección contra escaneo automatizado
Esto simula la herramienta Nikto mediante el User-Agent. El resultado obtenido nos permite evidenciar que el WAF NO bloqueó inmediatamente el User-Agent Nikto y permitió la petición. Esto puede indicar: monitoreo basado en comportamiento, falta de reglas específicas para scanners y logging pasivo sin respuesta automática
A10: SSRF — El Servidor Intentando Hablar con Sí Mismoo Server-Side Request Forgery (SSRF)
SSRF permite a un atacante forzar al servidor web a realizar peticiones HTTP hacia destinos arbitrarios (internos o externos). Puede usarse para: acceder a servicios internos no expuestos, escanear la red interna desde el servidor, acceder a metadatos de instancias cloud (AWS IMDS: http://169.254.169.254/)), o exfiltrar información interna.
Prueba ejecutada: SSRF via xmlrpc.php (método pingback.ping)
PRUEBA para Verificar si xmlrpc.php sigue accesible
Todo lo anterior nos indica que el archivo xmlrpc.php EXISTE y está activo La respuesta 405 Method Not Allowed. El servidor encontró el recurso xmlrpc.php,el endpoint está habilitado y el servidor reconoce la solicitud: pero no permite el método HEAD/GET. La razón por la que devuelve 405 es porque WordPress XML-RPC solo acepta POST y el comando ingresado es HEAD (inducido por -I).
PRUEBA 2 — Detectar métodos XML-RPC habilitados
A través de los ítems dados en la respuesta se confirmó que XML-RPC está habilitado, El servidor WordPress acepta solicitudes XML-RPC y Se pueden enumerar métodos internos del sistema
PRUEBA — Intentar localhost (SSRF interno)
Al ejecutarlo se obtiene como resultado <faultCode>0</faultCode>. Esta respuesta es anormal puesto que implica que el servidor: NO devolvió un rechazo claro, NO indicó “invalid host” y NO bloqueó explícitamente localhost.
Esto puede indicar que hay un posible SSRF parcial, El servidor intentó procesar la URL interna:http://127.0.0.1. Eso es peligroso porque un atacante podría intentar acceder a: servicios internos, bases de datos, paneles privados y APIs internas.
PRUEBA — Metadata Cloud (AWS)
Al ejecutarse se obtiene como resultado <faultCode>0</faultCode>, esto indica que se intentó acceder al endpoint típico de metadata cloud:169.254.169.254/latest/metadata/, usado comúnmente por AWS, Azure y GCP.
PRUEBA — Verificar redirecciones externas
Este resultado nos indica que el servidor rechaza GET, bloquear GET es una buena práctica, pero no es suficiente) y que está protegido parcialmente.XML-RPC sigue expuesto y aunque niega el GET acepta POSTy justamente los ataques XML-RPC usan POST.
PRUEBA — Validar protocolos peligrosos
El servidor NO confirmó lectura exitosa; pero tampoco bloqueó explícitamente el esquema file://. Esto es un riesgo puesto que deja la puerta abierta a que XML-RPC procesa esquemas locales Local File Inclusion, lectura arbitraria y SSRF avanzado.
PRUEBA — Enumerar endpoints REST
La REST API de WordPress está excesivamente expuesta
La prueba de Server-Side Request Forgery (SSRF) utilizó el método pingback.ping de xmlrpc.php para intentar forzar al servidor a realizar peticiones hacia destinos externos (google.com), internos (127.0.0.1) y de metadata cloud (169.254.169.254/latest/meta-data/). Las pruebas con localhost y el endpoint de metadata de AWS retornaron faultCode 0, una respuesta ambigua que indicó que el servidor no rechazó explícitamente las solicitudes, representando un posible SSRF parcial. La prueba con file:///etc/passwd tampoco arrojó un bloqueo explícito del esquema, dejando la puerta abierta a lectura arbitraria de archivos.
Conclusiones: ¿Qué Aprendimos de esta Auditoría?
El laboratorio demostró que un sitio WordPress puede presentar simultáneamente fortalezas importantes —como TLS 1.3, balanceo de carga CDN y WAF activo— y vulnerabilidades críticas derivadas de configuraciones insuficientes, no de errores de programación complejos.
Los hallazgos más urgentes para remediar son:
Restringir el acceso a wp-config.php desde el servidor web.
Deshabilitar xmlrpc.php mediante nginx.conf o un plugin especializado.
Agregar los headers HTTP faltantes: X-Frame-Options, HSTS y X-Content-Type-Options.
Implementar CAPTCHA y lockout de intentos en el formulario de login.
Eliminar directorios .git del entorno de producción.
Actualizar todos los componentes desactualizados, especialmente Font Awesome.
La seguridad web no es un estado definitivo, sino un proceso continuo. Este laboratorio aplicó el ciclo fundamental de gestión de vulnerabilidades (identificar → analizar → documentar → remediar), alineado con estándares internacionales como OWASP SAMM, el NIST Cybersecurity Framework e ISO/IEC 27001.
Herramientas Utilizadas en este Laboratorio
A continuación, las herramientas principales empleadas durante la auditoría, todas de uso libre y disponibles para la comunidad de ciberseguridad:
Nmap — Escáner de red y puertos de referencia mundial. 🔗 nmap.org
Nikto — Escáner de configuraciones inseguras en servidores web.
WPScan — Escáner especializado en vulnerabilidades de WordPress. 🔗 wpscan.com
SQLMap — Herramienta automatizada de detección de inyección SQL.
OpenSSL — Análisis y validación de certificados SSL/TLS.
Bhatt, C., Dey, N., & Ashour, A. (2017). Internet of Things and Big Data Technologies for Next Generation Healthcare. En Studies in big data. https://doi.org/10.1007/978-3-319-49736-5 Biblioteca UTP. (2025, septiembre 24). 4 Normas APA 7ma edición contraportada [Vídeo]. YouTube. https://www.youtube.com/watch?v=WzfTLc7YfFk Brian Mancera. (2017, junio 5). Portada y contraportada Normas APA [Vídeo]. YouTube. https://www.youtube.com/watch?v=oERYMjfL0AY Client challenge. (s. f.). https://es.scribd.com/document/660764435/02-Contratos-Reglas-de-Compromisos-Clausula-de-No-Competencia CramTech. (2020b, octubre 27). Insertar archivo PDF en documento WORD *MUY FACIL* [Vídeo]. YouTube. https://www.youtube.com/watch?v=33CQFXIHk9A Docs_Manager. (2023, 5 diciembre). Flash Advanced Documentation: Go beyond basics. Flash Documentation. https://docs.themegrill.com/flash/ Fernández, A. B., & Fernández, A. B. (2023, 7 mayo). Cómo redactar un contrato de pentesting. Términos y Condiciones. https://terminosycondiciones.es/2019/04/23/como-redactar-un-contrato-de-pentesting/ Latam, T. (2025, 27 octubre). Pentesting: guía, tipos y beneficios. https://latam.tivit.com/blog/guia-pentesting Mcaudibert. (2026, 29 abril). Limit login attempts reloaded – login Security, 2FA, brute force protection & firewall. WordPress.org. https://wordpress.org/plugins/limit-login-attempts-reloaded/ Nmap Network Scanning—The Official Nmap Project Guide to Network Discovery and Security Scanning. (s. f.). https://nmap.org/book Online-Convert. (s. f.). Convertir imágenes a WebP. online-convert.com. https://imagen.online-convert.com/es/convertir-a-webp Pentest-Tools.com. (2026, 31 marzo). Pentest-Tools.com. https://pentest-tools.com/ Rosello, P. (2025b, diciembre 23). Te contamos cómo hacer la portada y contraportada con normas APA. Tesis y Másters Colombia. https://tesisymasters.com.co/contraportada-normas-apa/ 2013 Registrar Accreditation Agreement. (2013b, septiembre 17). 2013 Registrar Accreditation Agreement. https://www.icann.org/resources/pages/approved-with-specs-2013-09-17-en Service Name and Transport Protocol Port Number Registry. (s. f.). https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml Williams, L. (2025, 10 diciembre). ️Penetration Testing Services Agreement (Beginner-Friendly Guide + Open Template). DEV Community. https://dev.to/ldwit/penetration-testing-services-agreement-beginner-friendly-guide-open-template-2in
