![\"Pentesting](\"https:\/\/www.claudeusercontent.com\/img\/portada-pentesting-owasp.jpg\")
<\/figure>\n\n\n\nIntroducci\u00f3n: por qu\u00e9 hacer pentesting en WordPress con OWASP<\/h2>\n\n\n\n
WordPress es el gestor de contenidos m\u00e1s utilizado del mundo y, precisamente por esa raz\u00f3n, tambi\u00e9n es uno de los m\u00e1s atacados. Plugins desactualizados, contrase\u00f1as d\u00e9biles, 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\u00eda de estos riesgos son predecibles, identificables y mitigables<\/strong> si se aplica una metodolog\u00eda clara.<\/p>\n\n\n\n En este art\u00edculo compartimos el resultado de un taller acad\u00e9mico de hacking \u00e9tico<\/a> 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\u00eda pr\u00e1ctica de pentesting en WordPress con OWASP<\/strong> que permita entender qu\u00e9 tan expuesto est\u00e1 un sitio t\u00edpico y c\u00f3mo aplicar el OWASP Top 10<\/a> para evaluarlo de forma sistem\u00e1tica.<\/p>\n\n\n\n Declaraci\u00f3n \u00e9tica:<\/strong> todas las pruebas se realizaron sobre un sitio propio creado para fines acad\u00e9micos. No se vulneraron sistemas de terceros ni se realizaron pruebas sin autorizaci\u00f3n expl\u00edcita.<\/p>\n<\/blockquote>\n\n\n\n El reconocimiento es la fase inicial de cualquier ejercicio de pentesting. Su objetivo es recolectar informaci\u00f3n <\/a>p\u00fablica<\/strong> del objetivo sin generar todav\u00eda actividad intrusiva. En esta fase utilizamos cuatro herramientas cl\u00e1sicas: Al ejecutar Con La conclusi\u00f3n es que el sitio est\u00e1 alojado f\u00edsicamente en el Reino Unido<\/strong>, una informaci\u00f3n valiosa cuando se eval\u00faa la jurisdicci\u00f3n legal y el cumplimiento de regulaciones como el GDPR.<\/p>\n\n\n\n Aplicamos el comando La presencia del puerto 2049 (Network File System) en un host de uso web llam\u00f3 nuestra atenci\u00f3n: aunque pertenece a la infraestructura interna del hosting compartido y no al sitio en s\u00ed, su exposici\u00f3n p\u00fablica supone una superficie de ataque adicional que el proveedor deber\u00eda revisar.<\/p>\n\n\n\n Una vez confirmada la conectividad, profundizamos en la infraestructura del dominio<\/strong>. Esta fase suele revelar pistas que un atacante puede aprovechar para construir un mapa completo del entorno.<\/p>\n\n\n\n Mediante La ausencia de registros SPF<\/a> y DKIM es un hallazgo importante: el dominio queda expuesto a suplantaci\u00f3n de correo electr\u00f3nico<\/strong> (email spoofing). Para un sitio comercial real esto ser\u00eda inaceptable.<\/p>\n\n\n\n El registro WHOIS confirm\u00f3 que el dominio est\u00e1 gestionado por NameCheap, Inc.<\/strong>, fue creado el 16\/08\/2023 y vence el 16\/08\/2027. Los datos personales del propietario est\u00e1n protegidos con WHOIS privacy<\/em>, una buena pr\u00e1ctica b\u00e1sica que evita la exposici\u00f3n innecesaria de informaci\u00f3n personal.<\/p>\n\n\n\n Conectamos al puerto 443 con Este es uno de los pocos puntos verdaderamente s\u00f3lidos del sitio.<\/p>\n\n\n\n El n\u00facleo del taller fue evaluar el sitio frente a las diez categor\u00edas m\u00e1s cr\u00edticas de riesgo seg\u00fan OWASP. Resumimos los hallazgos a continuaci\u00f3n.<\/p>\n\n\n\n Al acceder manualmente a Mitigaci\u00f3n:<\/strong> bloquear el endpoint Las pruebas con Mitigaci\u00f3n:<\/strong> forzar HTTPS con cabecera HSTS, redirigir 301 desde el puerto 80 y corregir el cierre de sesiones TLS.<\/p>\n\n\n\n Ejecutamos un active scan<\/em> con OWASP ZAP<\/a> probando m\u00faltiples payloads de inyecci\u00f3n sobre formularios y par\u00e1metros. No se encontraron vulnerabilidades de inyecci\u00f3n SQL<\/strong>, lo que sugiere que las consultas internas de WordPress y WooCommerce est\u00e1n adecuadamente parametrizadas. Buen punto a favor.<\/p>\n\n\n\n El formulario de login ( El escaneo con OWASP ZAP detect\u00f3 m\u00faltiples cabeceras de seguridad ausentes:<\/p>\n\n\n\n <\/p>\n\n\n\n La identificaci\u00f3n pasiva mostr\u00f3 el uso de WordPress + WooCommerce y servidor OpenResty. Intentamos un an\u00e1lisis m\u00e1s profundo con\u00a0WPScan<\/strong>, pero fall\u00f3 por dependencias rotas de\u00a0 Probamos m\u00faltiples payloads XSS en el formulario de contacto ( Inspeccionamos los scripts cargados por la aplicaci\u00f3n y encontramos que ninguno utiliza Subresource Integrity (SRI)<\/strong>. Si alg\u00fan CDN externo se viera comprometido, el sitio cargar\u00eda c\u00f3digo malicioso sin oponer resistencia.<\/p>\n\n\n\n Realizamos varios intentos fallidos de env\u00edo de formularios y de login. No detectamos ning\u00fan mecanismo de monitoreo, alerta o bloqueo<\/strong>. Si un atacante real iniciara una campa\u00f1a sostenida, probablemente no quedar\u00eda registro alguno.<\/p>\n\n\n\n Tras revisar manualmente todas las funcionalidades expuestas (formulario de contacto, tienda WooCommerce, par\u00e1metros URL), no se detectaron vectores SSRF<\/strong>. El sitio no parece exponer funcionalidades que permitan al usuario forzar peticiones del lado servidor.<\/p>\n\n\n\n De las diez categor\u00edas evaluadas, encontramos seis hallazgos relevantes<\/strong> y cuatro categor\u00edas sin vulnerabilidades evidentes. Las prioridades de remediaci\u00f3n las clasificamos as\u00ed:<\/p>\n\n\n\n <\/p>\n\n\n\n Para quienes quieran profundizar en la metodolog\u00eda OWASP Top 10 desde su fuente, recomendamos esta presentaci\u00f3n oficial:<\/p>\n\n\n\n\n
Fase 1: Reconocimiento de red<\/h2>\n\n\n\n
ping<\/code>, tracert<\/code>, nslookup<\/code> y nmap<\/code>.<\/p>\n\n\n\nPing: \u00bfest\u00e1 vivo el servidor?<\/h3>\n\n\n\n
ping suzuki-motos-la13.wuaze.com<\/code> obtuvimos un 100% de p\u00e9rdida de paquetes. A primera vista podr\u00eda pensarse que el servidor est\u00e1 ca\u00eddo, pero el sitio cargaba sin problemas en el navegador. La explicaci\u00f3n es que el proveedor (InfinityFree) bloquea el protocolo ICMP<\/strong> como medida de seguridad para prevenir ataques de reconocimiento y denegaci\u00f3n de servicio. Esto es algo com\u00fan en hosting compartido y no<\/em> implica indisponibilidad.<\/p>\n\n\n\n![\"Resultado](\"https:\/\/www.claudeusercontent.com\/img\/02-ping-sin-respuesta.png\")
ping<\/code>: el servidor no responde ICMP, pero s\u00ed HTTP.<\/figcaption><\/figure>\n\n\n\nTraceroute: la ruta hasta el servidor<\/h3>\n\n\n\n
tracert<\/code> mapeamos la ruta de los paquetes desde nuestra m\u00e1quina hasta el servidor destino (185.27.134.130). El an\u00e1lisis nos revel\u00f3 datos interesantes:<\/p>\n\n\n\n\n
edge3.man2.neo.colt.net<\/code> y Manchester.Level3.net<\/code> con latencias cercanas a 200 ms.<\/li>\n\n\n\nEscaneo de puertos con Nmap<\/h3>\n\n\n\n
nmap -sS -Pn suzuki-motos-la13.wuaze.com<\/code> y obtuvimos:<\/p>\n\n\n\n\n
Fase 2: DNS, WHOIS y certificados SSL\/TLS<\/h2>\n\n\n\n
Registros DNS<\/h3>\n\n\n\n
nslookup -type=A\/MX\/TXT\/NS<\/code> reconstruimos el \u00e1rbol DNS del dominio:<\/p>\n\n\n\n\n
ns1\u2013ns5.byet.org<\/code>, propios de la red InfinityFree.<\/li>\n\n\n\nsv62.ifastnet11.org<\/code>, prioridad 10.<\/li>\n\n\n\nConsulta WHOIS<\/h3>\n\n\n\n
![\"Resultado](\"https:\/\/www.claudeusercontent.com\/img\/03-whois-resultado.png\")
An\u00e1lisis del certificado SSL\/TLS<\/h3>\n\n\n\n
Test-NetConnection<\/code> y validamos el certificado <\/a>en SSL Labs<\/a>. El resultado fue una calificaci\u00f3n A<\/strong>, con soporte para TLS 1.3 y TLS 1.2 (y desactivaci\u00f3n correcta de TLS 1.0\/1.1 y SSL 2\/3). El certificado, emitido por ZeroSSL ECC Domain Secure Site CA<\/em>, es una credencial EC de 256 bits v\u00e1lida y no revocada.<\/p>\n\n\n\nFase 3: pentesting en WordPress con OWASP Top 10<\/h2>\n\n\n\n
A01 \u2013 Broken Access Control<\/h3>\n\n\n\n
\/wp-json\/wp\/v2\/users<\/code> el servidor respondi\u00f3 con un JSON que expone el usuario administrador (admin<\/code>)<\/strong> sin requerir autenticaci\u00f3n. Esta enumeraci\u00f3n de usuarios es uno de los hallazgos m\u00e1s graves del an\u00e1lisis: combinada con un formulario de login sin protecci\u00f3n (ver A07), facilita ataques de fuerza bruta dirigidos.<\/p>\n\n\n\n\/wp-json\/wp\/v2\/users<\/code> para usuarios no autenticados, renombrar la cuenta admin<\/code> y aplicar contrase\u00f1as robustas.<\/p>\n\n\n\nA02 \u2013 Cryptographic Failures<\/h3>\n\n\n\n
curl -v<\/code> mostraron que el servidor permite conexiones HTTP planas (puerto 80) sin redirecci\u00f3n obligatoria a HTTPS, y la conexi\u00f3n TLS termina abruptamente con missing close_notify<\/code>. La informaci\u00f3n transmitida puede ser interceptada en redes hostiles.<\/p>\n\n\n\nA03 \u2013 Injection<\/h3>\n\n\n\n
A04 \u2013 Insecure Design<\/a><\/h3>\n\n\n\n
\/wp-login.php<\/code>) est\u00e1 completamente expuesto: no hay CAPTCHA, no hay l\u00edmite de intentos y no hay MFA<\/strong>. Combinado con la enumeraci\u00f3n de usuarios de A01, esto es pr\u00e1cticamente una invitaci\u00f3n al ataque de fuerza bruta.<\/p>\n\n\n\n![\"Formulario](\"https:\/\/www.claudeusercontent.com\/img\/04-login-expuesto.png\")
A05 \u2013 Security Misconfiguration<\/h3>\n\n\n\n
\n
A06 \u2013 Vulnerable Components<\/h3>\n\n\n\n
libcurl<\/code>\u00a0en el entorno local \u2014 un recordatorio de que las herramientas tambi\u00e9n requieren mantenimiento.<\/p>\n\n\n\nA07 \u2013 Identification and Authentication Failures<\/h3>\n\n\n\n
<script>alert(1)<\/script><\/code>, <img src=x onerror=alert(1)><\/code>) y en par\u00e1metros GET. Ninguno fue ejecutado<\/strong>: la validaci\u00f3n de entradas funciona correctamente.<\/p>\n\n\n\nA08 \u2013 Software and Data Integrity Failures<\/h3>\n\n\n\n
A09 \u2013 Security Logging and Monitoring Failures<\/h3>\n\n\n\n
A10 \u2013 Server-Side Request Forgery (SSRF)<\/h3>\n\n\n\n
Resumen de hallazgos en el pentesting<\/h2>\n\n\n\n
\n
Video complementario<\/h2>\n\n\n\n