Cómo proteger WordPress de la «vulnerabilidad Pingback»

Recientemente se ha detectado una vulnerabilidad de XML-RPC en WordPress, o «vulnerabilidad Pingback», por la cual un atacante tendría 4 formas potenciales de provocar daños a través de xmlrpc.php, el archivo incluído en WordPress para dar soporte al protocolo XML-RPC (que se ocupa, por ejemplo, de los “pingbacks”).

Me refiero, a ese protocolo que viene activo por defecto en WordPress 3.5 y sin modo aparente de desactivarlo.

Pero, antes de nada …

¿Qué es la «vulnerabilidad Pingback»?

Según este artículo hay 4 maneras en que la API XML-RPC de WordPress (y en particular el método pingback.ping) puede ser atacada por  un hacker:

• Recolección interna: El atacante puede probar puertos específicos en la red interna objetivo. WordPress trata de resolver la URL de origen y devuelve distintos mensajes de error si la URL de origen existe (si existe el host) o no. Esto lo pueden usar los atacantes para tratar de acceder a hosts dentro de la red interna. De este modo, los atacantes podrían usar URLs como http://subversion/ o http://bugzilla/ o http://dev/ para ver si el host existe en la red interna.
• Escaneo de puertos: El atacante puede escanear hosts en la red interna. Si se detecta la URL original, WordPress tratará de conectar con el puerto específico en esa URL. Por tanto, si un atacante usa una URL del tipo http://subversion:22/ WordPress tratará de conectarse al host subversion en el puerto 22. Las respuestas serán diferentes si el puerto está cerrado o abierto, y precisamente por eso esta funcionalidad puede usarse para escanear hosts dentro de la red interna.
• Ataques DoS (denegación de servicio: El atacante puede hacer pingback desde una enorme cantidad de sitios, o pedírselo a blogueros compinches, o usar PCs zombies, para hacerte un ataque DoS
• Hackeo del router: El atacante puede reconfigurar un router interno de la red. Y es que WordPress soporta URLs con credenciales. O sea, que un atacante puede usar una URL del tipo para reconfigurar el router interno, ahí es nada.

Como ves no es para tomárselo a la ligera, la vulnerabilidad es de aupa.

Cómo protegerse de la «vulnerabilidad Pingback» de WordPress

Si no usas en absoluto el protocolo XML-RPC y quieres protegerte de cualquier vulnerabilidad de su API puedes bloquearlo con unas simples líneas en el archivo .htaccess.

Vamos a ver una técnica sencilla de .htaccess para protegernos frente a vulnerabilidades del archivo xmlrpc.php. Ahora bien, si usas pingbacks o cualquier otro servicio que use el protocolo XML-RPC con este truco dejará de funcionar:

# proteger xmlrpc
<IfModule mod_alias.c>
	RedirectMatch 403 /xmlrpc.php
</IfModule>

Incluye esas líneas después de cualesquiera otras que estés usando en el archivo .htaccess de la carpeta raíz de tu web y te puedes olvidar de esta vulnerabilidad, pues desactivas completamente XML-RPC.

Si quieres, para asegurarte que funciona, trata de acceder al archivo xmlrpc.php desde tu navegador. Si funciona verás un mensaje del tipo “403 – Forbidden”.

Truco adicional: si quieres redirigir las peticiones al archivo xmlrpc.php hacia una página personalizada modifica la línea RedirectMatch así:

# proteger xmlrpc
<IfModule mod_alias.c>
	Redirect 301 /xmlrpc.php 
</IfModule>

Por supuesto, tendrás que crear la página a tu gusto, y una copia de 404.php de tu tema sería una buena opción.

Método alternativo de .htaccess

Otro modo de denegar todo tipo de acceso al archivo xmlrpc.php desde .htaccess sería añadirle estas líneas:

# proteger xmlrpc
<Files xmlrpc.php>
	Order Deny,Allow
	Deny from all
</Files>

Lo bueno de este método, menos radical, es que te permite acceder al archivo xmlrpc.php para direcciones IP específicas. Por ejemplo, si sabes las IPs de tu Blogger o MovableType puedes añadirlas a la lista blanca mediante una línea de «Allow» para cada una, de este modo:

# proteger xmlrpc
<Files xmlrpc.php>
	Order Deny,Allow
	Deny from all
	Allow from 012.355.666
	Allow from 987.654.321
</Files>

Nota: Si usas alguno de estos métodos de .htaccess recuerda quitarlos una vez esta vulnerabilidad se solucione en una futura versión de WordPress. Mientras tanto ya estás tardando.

Fuente: Acunetix, vía Perishable Press

¿Te gustó este artículo? ¡Ni te imaginas lo que te estás perdiendo en YouTube!

AVISO: Esta publicación es de hace 3 años o más. Si es un código o un plugin podría no funcionar en las últimas versiones de WordPress, y si es una noticia podría estar ya obsoleta. Luego no digas que no te hemos avisado.