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. Aplicamos Pentesting en WordPress con 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. Por esa razón, también es uno de los más atacados. Más del 40% de todos los sitios web activos en internet corren sobre WordPress. Esto lo convierte en un objetivo de alto valor para atacantes automatizados y manuales por igual.
Plugins sin actualizar, contraseñas débiles y configuraciones por defecto suelen convertir a un sitio normal en un blanco fácil. La buena noticia es que la mayoría de estos riesgos son predecibles, detectables y corregibles si se aplica una metodología clara.
OWASP Top 10 es el estándar más usado para evaluar la seguridad de aplicaciones web. La Open Web Application Security Project Foundation publica esta lista con las diez categorías de riesgo más críticas. Se construye a partir de datos reales de cientos de organizaciones en todo el mundo. No es una lista de vulnerabilidades puntuales, sino un marco que permite a equipos de seguridad y desarrolladores priorizar esfuerzos juntos.
En este artículo compartimos los resultados de un taller académico de hacking ético. Lo realizamos en un entorno controlado, sobre un sitio WordPress propio alojado en InfinityFree. La meta no fue romper nada. El objetivo fue mostrar qué tan expuesto puede estar un sitio típico y cómo evaluarlo con el OWASP Top 10 paso a paso.
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 hicieron pruebas sin autorización explícita.
Fase 1: Reconocimiento de red
El reconocimiento es la primera fase de cualquier ejercicio de pentesting. Su objetivo es recolectar información pública del objetivo sin generar actividad intrusiva. Usamos cuatro herramientas clásicas: ping, tracert, nslookup y nmap. Cada una responde una pregunta distinta y, en conjunto, construyen un mapa inicial del entorno.
Ping: ¿está activo el servidor?
Al ejecutar ping suzuki-motos-la13.wuaze.com obtuvimos un 100% de pérdida de paquetes. A primera vista parece que el servidor está caído. Sin embargo, el sitio cargaba sin problemas en el navegador. La razón es que InfinityFree bloquea el protocolo ICMP para evitar ataques de reconocimiento y de denegación de servicio. Este comportamiento es común en hosting compartido y no significa que el servidor esté fuera de línea.
Aquí hay una lección clave para cualquier analista: la falta de respuesta ICMP no equivale a la ausencia del host. Un pentester que abandona el análisis ante un ping fallido puede llegar a conclusiones equivocadas. La regla es siempre combinar varias técnicas antes de sacar conclusiones.
Traceroute: el camino hasta el servidor
Con tracert mapeamos la ruta de los paquetes desde nuestra máquina hasta el servidor (185.27.134.130). El análisis mostró lo siguiente:
El primer salto (10.242.244.100) es el gateway local, con latencias menores a 5 ms. Los saltos 2 al 6 muestran asteriscos, lo que indica routers que no responden a TTL expirado. Esto es una práctica normal de seguridad en los ISPs. Los saltos 7 al 9 revelan IPs públicas del proveedor de internet, con latencias de 50 a 120 ms. Los saltos 11 y 12 identifican nodos en Manchester, Reino Unido, con latencias cercanas a 200 ms. Desde el salto 13 en adelante, el firewall del hosting bloquea las respuestas.
El dato más relevante es que el sitio está alojado en el Reino Unido. Para un sitio comercial que maneje datos de usuarios europeos, esto tiene implicaciones directas con el cumplimiento del GDPR.
Escaneo de puertos con Nmap
Usamos 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
Los puertos 80 y 443 son los esperados en cualquier servidor web. El puerto 2049 (Network File System) fue el que llamó nuestra atención. NFS sirve para compartir archivos entre equipos en red. Su exposición en un servidor web es llamativa. Aunque probablemente pertenece a la infraestructura interna del hosting, en entornos mal configurados puede permitir el acceso no autorizado a archivos del servidor.
La gran cantidad de puertos filtrados es una señal positiva. Indica que hay un firewall activo que limita el acceso a lo estrictamente necesario.
Fase 2: DNS, WHOIS y certificados SSL/TLS
Con la conectividad confirmada, analizamos la infraestructura del dominio. Esta fase revela información que un atacante puede usar para mapear el entorno: proveedores de hosting, configuración de correo, fechas de vencimiento del dominio y calidad del cifrado.
Registros DNS
Con nslookup consultamos los registros del dominio y obtuvimos lo siguiente:
- Registro A: 185.27.134.130 (servidor compartido).
- Registros NS: ns1 a ns5.byet.org, propios de InfinityFree. Toda la resolución DNS depende de este proveedor.
- Registro MX: sv62.ifastnet11.org con prioridad 10. El correo lo gestiona el propio hosting.
- Registros TXT: sin SPF ni DKIM configurados.
Por qué importa la falta de SPF y DKIM
SPF (Sender Policy Framework) permite verificar que un correo viene de un servidor autorizado por el dominio. DKIM añade una firma digital que garantiza que el mensaje no fue alterado en tránsito. Sin estos registros, cualquier persona puede enviar correos que parezcan venir del dominio. Los servidores de destino no tienen forma de rechazarlos de forma automática. Para un sitio comercial que se comunica con clientes, esto es un problema serio.
Consulta WHOIS
El registro WHOIS confirmó que el dominio está en NameCheap, Inc. Fue creado el 16/08/2023 y vence el 16/08/2027. Los datos del propietario están protegidos con privacidad WHOIS. Esta es una buena práctica: los registros WHOIS son públicos y cualquiera puede consultarlos para obtener información de contacto.
Para un pentester, el WHOIS también permite saber si el dominio está por vencer (lo que facilita un posible secuestro de dominio) y si el registrador ofrece bloqueo de transferencia.
Certificado SSL/TLS
Probamos la conexión al puerto 443 con Test-NetConnection y validamos el certificado en SSL Labs. El resultado fue una calificación A. El servidor soporta TLS 1.3 y TLS 1.2, y tiene desactivados los protocolos obsoletos (TLS 1.0, TLS 1.1, SSL 2 y SSL 3). El certificado fue emitido por ZeroSSL ECC Domain Secure Site CA y está vigente y sin revocar.
Este es uno de los pocos puntos bien resueltos del sitio. TLS 1.3 es especialmente valioso porque ofrece Perfect Forward Secrecy por defecto. Esto significa que, aunque alguien capture el tráfico cifrado hoy, no podrá descifrarlo en el futuro aunque obtenga la clave privada del servidor.
Aun así, las pruebas con curl -v mostraron que el servidor acepta conexiones HTTP sin cifrar. Además, la sesión TLS se cierra de forma abrupta con el error missing close_notify. Estos problemas pueden ser aprovechados en ataques de tipo man-in-the-middle.
Fase 3: Pentesting en WordPress con OWASP Top 10
La parte central del taller fue evaluar el sitio frente a las diez de un Pentesting en WordPress con OWASP Top 10. Presentamos a continuación los hallazgos de cada una, con el contexto necesario para entender por qué importan en la práctica.
A01 – Broken Access Control
Accedimos manualmente al endpoint /wp-json/wp/v2/users. El servidor devolvió un JSON con el usuario administrador (admin) sin pedir ninguna credencial. La respuesta incluía nombre de usuario, slug, URLs de avatar y datos de WooCommerce, todo visible para cualquiera.
Este endpoint es parte de la API REST de WordPress y está activo por defecto desde la versión 4.7. Sin restricciones, cualquier persona puede obtener el nombre exacto del administrador. Combinado con un formulario de login sin protección, esto crea una ruta directa hacia un ataque de fuerza bruta.
Mitigación: bloquear el acceso a /wp-json/wp/v2/users para usuarios sin sesión. Se puede hacer con Wordfence o con reglas en .htaccess. También conviene renombrar la cuenta admin y usar contraseñas generadas por un gestor.
A02 – Cryptographic Failures
Las pruebas con curl -v encontraron dos problemas. Primero, el servidor acepta conexiones HTTP sin redirigir a HTTPS. Segundo, la sesión TLS termina con missing close_notify, lo que indica un cierre incorrecto de la conexión.
El acceso HTTP sin cifrar es el problema más grave. Un usuario en una red pública puede tener su tráfico interceptado. Si el login o el checkout de WooCommerce funcionan por HTTP, las contraseñas y datos de pago viajan en texto plano.
Mitigación: forzar HTTPS con una redirección 301 y activar la cabecera HSTS. También hay que corregir el cierre de sesiones TLS en la configuración de OpenResty.
A03 – Injection
Ejecutamos un Active Scan con OWASP ZAP. La herramienta probó múltiples cargas de inyección SQL, XPath y de comandos sobre formularios y parámetros de URL. No se encontró ninguna vulnerabilidad de inyección. Esto indica que las consultas de WordPress y WooCommerce están bien protegidas con la clase wpdb.
Es un resultado positivo. Sin embargo, la ausencia de problemas hoy no garantiza seguridad en el futuro. Plugins nuevos o personalizados pueden introducir código vulnerable. Los escaneos periódicos son la única forma de mantener este control.
Mitigación: usar siempre consultas parametrizadas en código propio. Nunca concatenar variables directamente en sentencias SQL. Mantener todos los plugins actualizados.
A04 – Insecure Design
El formulario de login (/wp-login.php) no tiene CAPTCHA, no limita los intentos fallidos y no ofrece autenticación en dos pasos (MFA). Hicimos varios intentos de acceso con el usuario admin obtenido en A01 y el sistema no bloqueó ni alertó en ningún momento.
El riesgo combinado más crítico del análisis
Este hallazgo, unido a la enumeración de usuarios de A01, forma la cadena de ataque más peligrosa del informe. Un atacante conoce el nombre de usuario exacto y puede probar contraseñas sin límite. Herramientas como Hydra o WPScan pueden hacer miles de intentos por minuto de forma automática.
Mitigación: instalar un plugin que añada CAPTCHA al login y bloquee intentos fallidos (por ejemplo, Login LockDown). Habilitar MFA con Google Authenticator. Valorar restringir el acceso al panel de administración por IP.
A05 – Security Misconfiguration
OWASP ZAP detectó que el servidor no envía varias cabeceras de seguridad HTTP básicas:
- Content-Security-Policy (CSP): sin configurar. El navegador ejecutará scripts de cualquier origen, lo que facilita ataques XSS e inyección de contenido.
- X-Frame-Options: ausente. El sitio puede cargarse dentro de un iframe invisible, lo que abre la puerta al clickjacking.
- X-Content-Type-Options: no enviada. Navegadores viejos pueden interpretar el contenido de formas no esperadas.
- Referrer-Policy: sin configurar. Las URLs internas pueden filtrarse hacia sitios externos.
Estas cabeceras no afectan el rendimiento del sitio. Añadirlas solo requiere configurar el servidor o instalar un plugin. Su ausencia es una señal clara de que la seguridad no se tuvo en cuenta al momento del despliegue.
Mitigación: configurar las cabeceras en OpenResty o con un plugin específico. Validar el resultado en securityheaders.com.
A06 – Vulnerable Components
Identificamos WordPress, WooCommerce y el servidor OpenResty en las respuestas HTTP. Intentamos un análisis más profundo con WPScan, pero la herramienta falló por un error de dependencias de libcurl en el entorno local. No pudimos obtener información sobre versiones específicas de plugins o temas.
Aun sin esa información, la existencia de muchos componentes de terceros es un riesgo en sí mismo. La mayoría de los ataques exitosos contra WordPress no van al núcleo del CMS. Van a los plugins desactualizados. Cada plugin instalado es una posible puerta de entrada.
Mitigación: mantener WordPress y todos sus plugins y temas siempre actualizados. Borrar los plugins que no se usen. Ocultar la versión del servidor en las cabeceras HTTP. Hacer escaneos regulares con WPScan en un entorno correctamente configurado.
A07 – Identification and Authentication Failures
Probamos varios payloads XSS en el formulario de contacto y en parámetros de URL. También enviamos solicitudes desde consola con curl para ver si el servidor devolvía las entradas maliciosas en sus respuestas. Ningún payload se ejecutó. La validación de entradas funciona bien en los puntos evaluados.
La falta de XSS reflejado indica que el sitio usa escape de salida correcto. Funciones como esc_html() y wp_kses() del núcleo de WordPress hacen bien su trabajo. Aun así, plugins o temas con código propio pueden introducir este tipo de fallo sin que se detecte en un análisis general.
Mitigación: mantener la validación de entradas activa. Revisar el código de cualquier desarrollo personalizado. Complementar con un WAF que bloquee patrones XSS conocidos.
A08 – Software and Data Integrity Failures
Revisamos los scripts que carga la aplicación con las herramientas del navegador y con Pentesting en WordPress con OWASP ZAP. Ninguno de los scripts externos usa Subresource Integrity (SRI). SRI es un mecanismo que permite al navegador verificar que un archivo descargado desde un CDN no fue modificado.
El riesgo de los ataques a la cadena de suministro
Sin SRI, si un CDN externo es comprometido, el sitio cargará y ejecutará código malicioso sin ninguna defensa. Este tipo de ataque se llama supply chain attack. Un caso real fue el de Polyfill.io en 2024, que afectó a cientos de miles de sitios. La falta de CSP (mencionada en A05) hace que este riesgo sea aún mayor.
Mitigación: añadir el atributo integrity a todos los scripts externos. Configurar una CSP estricta. Revisar periódicamente las dependencias de terceros.
A09 – Security Logging and Monitoring Failures
Hicimos varios intentos fallidos de login y de envío de formularios con datos inválidos. El sistema no mostró ninguna señal de alerta, bloqueo ni registro visible. Un atacante podría lanzar una campaña sostenida y no dejar rastro.
Esta categoría suele subestimarse porque no permite acceso directo al sistema. Sin embargo, la falta de registros es lo que convierte un incidente menor en una brecha grave. Sin logs, es imposible saber cuándo empezó el ataque, qué datos fueron tocados o si el problema ya fue resuelto. Para un sitio de comercio electrónico, esto es un riesgo especialmente alto.
Mitigación: activar registros para eventos críticos como logins, errores 404 en rutas sensibles y cambios de configuración. Centralizar los logs en un servicio externo (Papertrail, Logtail). Configurar alertas automáticas ante actividad sospechosa.
A10 – Server-Side Request Forgery (SSRF)
Revisamos manualmente todas las funcionalidades visibles: formulario de contacto, tienda WooCommerce, navegación general y parámetros de URL detectados con OWASP ZAP. No encontramos ningún punto que permita al usuario forzar peticiones del servidor hacia recursos externos.
Es un resultado positivo. Aun así, funcionalidades menos visibles como webhooks de WooCommerce o plugins de importación de contenido podrían tener este tipo de fallo. La recomendación es validar todas las URLs que el usuario pueda introducir y limitar las conexiones salientes del servidor.
Resumen de hallazgos y prioridades de remediación
De las diez categorías evaluadas, seis mostraron hallazgos relevantes. Las otras cuatro no presentaron vulnerabilidades evidentes. A continuación, el orden de acción recomendado:
Prioridad crítica — A01 + A04: la enumeración de usuarios y el login sin protección forman la cadena de ataque más urgente. Corregir uno sin el otro reduce, pero no elimina, el riesgo. Hay que abordar ambos al mismo tiempo.
Prioridad alta — A02 + A09: la falta de redirección HTTPS afecta la privacidad de los datos en tránsito. La ausencia de logs limita la capacidad de responder ante un incidente. Ambos problemas tienen solución directa y rápida.
Prioridad media — A05 + A08: las cabeceras de seguridad ausentes y la falta de SRI son configuraciones que se corrigen en poco tiempo. Aportan una capa de defensa importante con bajo esfuerzo.
Sin hallazgo directo — A03, A06, A07, A10: no se encontraron vulnerabilidades en los puntos evaluados. Aun así, se recomienda mantener controles activos y hacer evaluaciones periódicas.
Video Explciativo
Conclusión: lo que todo administrador de WordPress debería revisar hoy
Este ejercicio confirma algo que se repite en casi todos los sitios WordPress: los problemas no están en el código del CMS, sino en su configuración. Endpoints sin protección, formularios sin CAPTCHA, cabeceras de seguridad ausentes y falta de monitoreo son errores de configuración, no de programación.
Por lo tanto hacer Pentesting en WordPress con OWASP Top 10 ofrece un marco claro para evaluarlo todo de forma ordenada. No se necesitan herramientas costosas. Con Nmap, OWASP ZAP, nslookup y curl se pueden encontrar hallazgos críticos en pocas horas.
Cinco acciones inmediatas para cualquier administrador
Si quieres aplicar las lecciones de este análisis hoy mismo, este es el orden recomendado:
- Bloquear el endpoint
/wp-json/wp/v2/usersy renombrar el usuarioadmin. - Instalar un plugin que limite intentos de login e implemente MFA.
- Forzar HTTPS con redirección 301 y activar HSTS.
- Configurar las cabeceras de seguridad HTTP.
- Activar algún sistema de logging centralizado.
Estas cinco acciones no requieren más de una tarde de trabajo. Con ellas se eliminan los hallazgos más críticos de este análisis.
Si usas hosting compartido como InfinityFree, recuerda que el proveedor cubre la seguridad de la infraestructura base. La configuración de la aplicación siempre es responsabilidad del propietario del sitio. La seguridad no se alcanza una sola vez: es un proceso continuo de revisión, actualización y monitoreo.
Aplicar esta metodología al menos una vez al año, o tras cambios importantes en el sitio, permite detectar los problemas antes de que lo haga un atacante. En seguridad, siempre gana quien actúa primero.
Documento
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/
Autores: Brayan Camilo Miranda, Nicolás Buitrago Bogotá, Luis Fernando Martínez.
Asignatura: Hacking Ético — Código 43391427.
Docente: Carlos Pinzón.
Universidad Central — Facultad de Ingeniería, Programa de Ingeniería de Sistemas. Bogotá, Colombia. 2026.
