daniel_diaz_bardillo / Pixabay
Estamos viviendo días un poco convulsos en el mundo de WordPress: dos actualizaciones en un plazo de 24 horas, la 4.9.3 y 4.9.4, esta última para solucionar un bug generado en la actualización automática por la versión previa. Y ahora nos enteramos vía el boletín «Una al día» de Hispasec que hay un ataque DoS (siglas en inglés de denegación de servicio) que no ha sido parcheado en esta última versión, a pesar de haber sido reportado por Barak Tawily y que nos puede tumbar, de forma relativamente sencilla, temporalmente un servidor web. Vamos a copypastear el interesante artículo de Hispasec y luego os proponemos un par de soluciones:
El lunes negro de WordPress: actualizaciones con fallos y vulnerabilidades que no se solucionan
Definitivamente esta semana no es la mejor para el CMS que, dicen, supone casi el 30% de sitios de Internet. Un fallo introducido en la ultima actualización impide actualizar automáticamente, y una vulnerabilidad que tiene como impacto la denegación de servicio no será solucionada.
El lunes se publicaba la versión 4.9.3, solucionando un total de 43 fallos, aunque ninguno de ellos de seguridad. Como es habitual cada vez que hay una actualización, el anuncio de la nueva versión al final rezaba:
Sites that support automatic background updates are already beginning to update automatically.
Pero esto nunca llego a suceder. Irónicamente, la actualización se publicó con un fallo que impide al sistema de actualizaciones automáticas seguir funcionando, o lo que es lo mismo: tras esta instalación, WordPress dejará de actualizarse automáticamente. Esta funcionalidad se implementó en la versión 3.7, precisamente para dar respuesta a la gran cantidad instalaciones vulnerables (algunos estudios afirmaban que suponían el 70% del total). Para solucionar la situación, el mismo martes se publicó la versión 4.9.4. Sin embargo, al haber quedado el sistema inservible, para actualizar se requieren operaciones manuales por parte del usuario:
Unfortunately yesterdays 4.9.3 release contained a severe bug which was only discovered after release. The bug will cause WordPress to encounter an error when it attempts to update itself to WordPress 4.9.4, and will require an update to be performed through the WordPress dashboard or hosts update tools.
Esto podría suponer que muchos sitios queden estancados en la versión 4.9.3 hasta que sus administradores ejecuten la operación.Más malas noticias: una denegación de servicio que no se solucionará
Por si esto fuera poco, el mismo lunes el investigador Barak Tawily publicaba un artículo donde describía una vulnerabilidad que afecta a casi cualquier instalación de WordPress, provocando una denegación de servicio.La vulnerabilidad se encuentra en el fichero ‘load-scripts.php’. Este se utiliza para pedir al servidor varios ficheros estáticos en una sola petición, reduciendo así el número total de peticiones.Como parámetro se pasa al fichero un array llamado load[] que contendrá nombres de ficheros estáticos. No todos los estáticos pueden servirse a través de esta petición, solo los definidos en el listado interno $wp_scripts, y nunca se servirán repetidos, aunque ni falta que hace: en ese listado hay un total de 181 ficheros que suponen un número similar de acciones de I/O y un peso del fichero de respuesta de casi 4MB.Dado que esta petición es muy pesada, una repetición constante de la misma puede provocar la sobrecarga del servidor, llevando finalmente a la denegación de servicio. Y peor aún, el fichero ‘load-scripts.php’ no requiere autenticación para ser llamado ya que, aunque forma parte de la zona de administración, es también accesible desde la pantalla de entrada ‘wp-login.php’.A pesar de la facilidad de explotación, WordPress no ha aceptado la vulnerabilidad, ya que según responden a Tawily:
«This kind of thing should really be mitigated at the server or network level rather than the application level, which is outside of WordPress’s control.»
Aun así, Tawily ha publicado su propio parche y un script que soluciona la vulnerabilidad.
Soluciones.
Te ofrezco 3 soluciones, aunque te recomiendo la número 3:
1.- Como ya avanza el artículo, Barak Tawily ha publicado un script que permite solucionar la vulnerabilidad y que lo único que hay que hacer es ejecutarlo en el directorio raíz de nuestro WordPress. Para ello has de copiar el script en un fichero en blanco (puedes usar un editor tipo Sublime Text, Atom o equivalente) y nombrarlo con extensión .sh, (el autor lo ha denominado wp-dos-patch.sh, nombre que puedes usar también) subirlo vía ftp/sftp al root de tu hosting, acceder vía SSH al mismo, darle permisos como root: chmod +x nombredelarchivo.sh y ejecutarlo (habitualmente con la instrucción sh nombredelarchivo.sh). Recuerda hacer un backup de toda la web y base de datos, por si acaso y yo, personalmente, no lo usaría en una web en producción.
2.- Si no tienes todavía instalado WordPress pero quieres instalar una versión con, entre otras, esta vulnerabilidad corregida, puedes hacer una instalación desde 0 usando el fork de WordPress que el mismo Barak Tawily tiene en github.
3.- La opción que os recomiendo, un buen plugin de seguridad gratuito llamado Cerber Security & Antispam que tiene la opción de proteger esa vulnerabilidad en la pestaña Endurecimiento –> Protect admin scripts.
