Hoy en AyudaWordPress.com

Vulnerabilidad XSS en JetPack ¡Urgente!
3.001 artículos sobre WordPress
Cómo proteger WordPress de la “vulnerabilidad Pingback”

Posted: 03 Jan 2013 11:22 AM PST

Parece ser que está confirmada una grave vulnerabilidad XSS (Cross Site Scripting) en el plugin JetPack, por la que tu sitio puede quedar expuesto a inyecciones de código.

Según se ha avisado en los foros de soporte, de lo que me ha avisado José Conti, el plugin JetPack está utilizando una versión vulnerable de CSSTidy, el módulo que permite la personalización de CSS, que utiliza para esta funcionalidad el archivo ‘tusitio.com/wp-content/plugins/jetpack/modules/custom-css/csstidy/css_optimiser.php‘, que estaría accesible directamente, y permitiendo inyectar código malicioso en tu sitio.

Si tienes dudas, y tienes JetPack instalado, simplemente sustituye en la URL de arriba “tusitio.com” por tu dominio para comprobarlo, y pegarte el susto del día al ver algo así …

Huelga decir que es absolutamente urgente poner remedio urgente a esta vulnerabilidad mientras no actualicen JetPack a una versión segura. Y lo peor del asunto es que no te valdrá añadir un fichero en blanco a la carpeta, ni siquiera añadir la directiva para evitar listados en .htaccess, y ni pienses que tener desactivado el módulo o incluso todo JetPack sirve para algo.

Lo único seguro es una de estas dos opciones:

Renombrar el archivo css_optimiser.php a lo que quieras, y rezar para que ningún hacker adivine el nuevo nombre.
Borrar el archivo css_optimiser.php, mucho más seguro, ni lo dudes.

Pues eso, que ya estás tardando. Y si querías una última excusa para desinstalar y borrar JetPack no la vas a encontrar mejor, al menos mientras no se solucione esta grave vulnerabilidad.

3.001 artículos sobre WordPress

Posted: 03 Jan 2013 03:06 AM PST

Lo reconozco, me gustan los números redondos, y como me acabo de dar cuenta que hace un rato he batido la cifra de los 3.000 artículos sobre WordPress pues eso, que este es el 3.002.

Cómo proteger WordPress de la “vulnerabilidad Pingback”

Posted: 03 Jan 2013 02:30 AM PST

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 http://admin:admin@192.168.0.1/changeDNS.asp?newDNS=aaaa 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 http://miweb.com/pagina-personalizada.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

AYUDA WORDPRESS

jueves, 3 de enero de 2013