Pentesting con OWASP en un Sitio WordPress: Hallazgos Reales de un Ejercicio de Hacking Ético

Un recorrido práctico por las fases de reconocimiento, análisis de infraestructura DNS y evaluación de vulnerabilidades aplicando la metodología OWASP Top 10 sobre un sitio web real, en un entorno controlado y autorizado.

Introducción: por qué hacer pentesting en WordPress con OWASP

WordPress es el gestor de contenidos más utilizado del mundo y, precisamente por esa razón, también es uno de los más atacados. Plugins desactualizados, contraseñas débiles, configuraciones por defecto y endpoints expuestos suelen convertir a un sitio aparentemente inocente en un objetivo sencillo para un atacante. La buena noticia es que la mayoría de estos riesgos son predecibles, identificables y mitigables si se aplica una metodología clara.

En este artículo compartimos el resultado de un taller académico de hacking ético realizado bajo un entorno controlado, sobre un sitio WordPress montado por nosotros mismos en un hosting compartido (InfinityFree). La meta no fue romper nada, sino ofrecer una guía práctica de pentesting en WordPress con OWASP que permita entender qué tan expuesto está un sitio típico y cómo aplicar el OWASP Top 10 para evaluarlo de forma sistemática.

Declaración ética: todas las pruebas se realizaron sobre un sitio propio creado para fines académicos. No se vulneraron sistemas de terceros ni se realizaron pruebas sin autorización explícita.

Fase 1: Reconocimiento de red

El reconocimiento es la fase inicial de cualquier ejercicio de pentesting. Su objetivo es recolectar información pública del objetivo sin generar todavía actividad intrusiva. En esta fase utilizamos cuatro herramientas clásicas: ping, tracert, nslookup y nmap.

Ping: ¿está vivo el servidor?

Al ejecutar ping suzuki-motos-la13.wuaze.com obtuvimos un 100% de pérdida de paquetes. A primera vista podría pensarse que el servidor está caído, pero el sitio cargaba sin problemas en el navegador. La explicación es que el proveedor (InfinityFree) bloquea el protocolo ICMP como medida de seguridad para prevenir ataques de reconocimiento y denegación de servicio. Esto es algo común en hosting compartido y no implica indisponibilidad.

Traceroute: la ruta hasta el servidor

Con tracert mapeamos la ruta de los paquetes desde nuestra máquina hasta el servidor destino (185.27.134.130). El análisis nos reveló datos interesantes:

• Salto 1: 10.242.244.100 (gateway local, latencia < 5 ms).
• Saltos 7–9: direcciones públicas del ISP (190.98.141.28, 94.142.118.231).
• Saltos 11–12: nodos internacionales como edge3.man2.neo.colt.net y Manchester.Level3.net con latencias cercanas a 200 ms.
• Saltos finales: sin respuesta — bloqueados por el firewall del hosting.

La conclusión es que el sitio está alojado físicamente en el Reino Unido, una información valiosa cuando se evalúa la jurisdicción legal y el cumplimiento de regulaciones como el GDPR.

Escaneo de puertos con Nmap

Aplicamos el comando nmap -sS -Pn suzuki-motos-la13.wuaze.com y obtuvimos:

• 80/tcp — abierto (HTTP)
• 443/tcp — abierto (HTTPS)
• 2049/tcp — abierto (NFS)
• 778 puertos filtrados y 219 cerrados

La presencia del puerto 2049 (Network File System) en un host de uso web llamó nuestra atención: aunque pertenece a la infraestructura interna del hosting compartido y no al sitio en sí, su exposición pública supone una superficie de ataque adicional que el proveedor debería revisar.

Fase 2: DNS, WHOIS y certificados SSL/TLS

Una vez confirmada la conectividad, profundizamos en la infraestructura del dominio. Esta fase suele revelar pistas que un atacante puede aprovechar para construir un mapa completo del entorno.

Registros DNS

Mediante nslookup -type=A/MX/TXT/NS reconstruimos el árbol DNS del dominio:

• Registro A: 185.27.134.130 (servidor compartido).
• Registros NS: ns1–ns5.byet.org, propios de la red InfinityFree.
• Registro MX: sv62.ifastnet11.org, prioridad 10.
• Registros TXT: sin SPF ni DKIM configurados.

La ausencia de registros SPF y DKIM es un hallazgo importante: el dominio queda expuesto a suplantación de correo electrónico (email spoofing). Para un sitio comercial real esto sería inaceptable.

Consulta WHOIS

El registro WHOIS confirmó que el dominio está gestionado por NameCheap, Inc., fue creado el 16/08/2023 y vence el 16/08/2027. Los datos personales del propietario están protegidos con WHOIS privacy, una buena práctica básica que evita la exposición innecesaria de información personal.

Análisis del certificado SSL/TLS

Conectamos al puerto 443 con Test-NetConnection y validamos el certificado en SSL Labs. El resultado fue una calificación A, con soporte para TLS 1.3 y TLS 1.2 (y desactivación correcta de TLS 1.0/1.1 y SSL 2/3). El certificado, emitido por ZeroSSL ECC Domain Secure Site CA, es una credencial EC de 256 bits válida y no revocada.

Este es uno de los pocos puntos verdaderamente sólidos del sitio.

Fase 3: pentesting en WordPress con OWASP Top 10

El núcleo del taller fue evaluar el sitio frente a las diez categorías más críticas de riesgo según OWASP. Resumimos los hallazgos a continuación.

A01 – Broken Access Control

Al acceder manualmente a /wp-json/wp/v2/users el servidor respondió con un JSON que expone el usuario administrador (admin) sin requerir autenticación. Esta enumeración de usuarios es uno de los hallazgos más graves del análisis: combinada con un formulario de login sin protección (ver A07), facilita ataques de fuerza bruta dirigidos.

Mitigación: bloquear el endpoint /wp-json/wp/v2/users para usuarios no autenticados, renombrar la cuenta admin y aplicar contraseñas robustas.

A02 – Cryptographic Failures

Las pruebas con curl -v mostraron que el servidor permite conexiones HTTP planas (puerto 80) sin redirección obligatoria a HTTPS, y la conexión TLS termina abruptamente con missing close_notify. La información transmitida puede ser interceptada en redes hostiles.

Mitigación: forzar HTTPS con cabecera HSTS, redirigir 301 desde el puerto 80 y corregir el cierre de sesiones TLS.

A03 – Injection

Ejecutamos un active scan con OWASP ZAP probando múltiples payloads de inyección sobre formularios y parámetros. No se encontraron vulnerabilidades de inyección SQL, lo que sugiere que las consultas internas de WordPress y WooCommerce están adecuadamente parametrizadas. Buen punto a favor.

A04 – Insecure Design

El formulario de login (/wp-login.php) está completamente expuesto: no hay CAPTCHA, no hay límite de intentos y no hay MFA. Combinado con la enumeración de usuarios de A01, esto es prácticamente una invitación al ataque de fuerza bruta.

A05 – Security Misconfiguration

El escaneo con OWASP ZAP detectó múltiples cabeceras de seguridad ausentes:

• Content-Security-Policy (CSP) no configurada.
• X-Frame-Options ausente (riesgo de clickjacking).
• X-Content-Type-Options no enviada.

A06 – Vulnerable Components

La identificación pasiva mostró el uso de WordPress + WooCommerce y servidor OpenResty. Intentamos un análisis más profundo con WPScan, pero falló por dependencias rotas de libcurl en el entorno local — un recordatorio de que las herramientas también requieren mantenimiento.

A07 – Identification and Authentication Failures

Probamos múltiples payloads XSS en el formulario de contacto (<script>alert(1)</script>, <img src=x onerror=alert(1)>) y en parámetros GET. Ninguno fue ejecutado: la validación de entradas funciona correctamente.

A08 – Software and Data Integrity Failures

Inspeccionamos los scripts cargados por la aplicación y encontramos que ninguno utiliza Subresource Integrity (SRI). Si algún CDN externo se viera comprometido, el sitio cargaría código malicioso sin oponer resistencia.

A09 – Security Logging and Monitoring Failures

Realizamos varios intentos fallidos de envío de formularios y de login. No detectamos ningún mecanismo de monitoreo, alerta o bloqueo. Si un atacante real iniciara una campaña sostenida, probablemente no quedaría registro alguno.

A10 – Server-Side Request Forgery (SSRF)

Tras revisar manualmente todas las funcionalidades expuestas (formulario de contacto, tienda WooCommerce, parámetros URL), no se detectaron vectores SSRF. El sitio no parece exponer funcionalidades que permitan al usuario forzar peticiones del lado servidor.

Resumen de hallazgos en el pentesting

De las diez categorías evaluadas, encontramos seis hallazgos relevantes y cuatro categorías sin vulnerabilidades evidentes. Las prioridades de remediación las clasificamos así:

• Crítico: A01 (enumeración de usuarios) + A04 (login sin protecciones) → riesgo combinado alto.
• Alto: A02 (cifrado mal configurado), A09 (sin logging).
• Medio: A05 (cabeceras), A08 (SRI ausente).
• Bajo / sin hallazgo: A03, A06, A07, A10.

Video complementario

Para quienes quieran profundizar en la metodología OWASP Top 10 desde su fuente, recomendamos esta presentación oficial:

Conclusión: lo que todo administrador de WordPress debería revisar hoy y por que el Pentesting en WordPress con OWASP

Este ejercicio reafirma una idea sencilla pero poderosa: la mayoría de las vulnerabilidades de un sitio WordPress no están en el código del CMS, sino en su configuración. Endpoints públicos que enumeran usuarios, formularios sin CAPTCHA, cabeceras de seguridad ausentes y falta de monitoreo son problemas que se resuelven con configuración, no con desarrollo.

Aplicar esta guía práctica de pentesting en WordPress con OWASP de forma periódica permite detectar estos puntos antes de que lo haga un atacante. Y si trabajas con hosting compartido, recuerda: el proveedor cubre cierta parte de la seguridad, pero la configuración aplicativa siempre es responsabilidad del propietario del sitio.

Referencias

ICANN. (s. f.). WHOIS lookup. https://lookup.icann.org/

OWASP Foundation. (2021). OWASP Top 10: The ten most critical web application security risks. https://owasp.org/www-project-top-ten/

OWASP Foundation. (2023). OWASP Web Security Testing Guide. https://owasp.org/www-project-web-security-testing-guide/

OWASP Foundation. (2023). OWASP Zed Attack Proxy (ZAP). https://owasp.org/www-project-zap/

Qualys, Inc. (s. f.). SSL Server Test. SSL Labs. https://www.ssllabs.com/ssltest/

WordPress Foundation. (2023). WordPress security white paper. https://wordpress.org/about/security/

Créditos

• Autores: Brayan Camilo Miranda, Nicolás Buitrago Bogotá, Luis Fernando Martínez.
• Editor: 
• Asignatura: Hacking Ético — Código 43391427.
• Docente: Carlos Pinzón.
• Universidad: Universidad Central — Facultad de Ingeniería, Programa de Ingeniería de Sistemas. Bogotá, Colombia. 2026.