¿Denegación de Servicio en Wordpress?
En el sitio de Hispasec se ha publicado una vulnerabilidad que afecta a WordPress y que podría permitir que un atacante remoto llevara a cabo una denegación de servicio. Esta vulnerabilidad ha sido publicada por un usuario que se hace llamar "MustLive". La vulnerabilidad es de tipo abuso de funcionalidad (AoF) en WordPress. El abuso de funcionalidad es una técnica de ataque en el que se utilizan las propias funcionalidades de un sitio para atacarlo. Un atacante remoto podría causar una denegación de servicio mediante un ataque de este tipo. Según se entiende, esta vulnerabilidad fue descubierta en 2009 pero no fue correctamente corregida.
La vulnerabilidad se encuentra en las funcionalidades "Reparar la base de datos" y "Reparar y optimizar la base de datos" ("Repair Database" y "Repair and Optimize Database") en "wp-admin/maint/repair.php". Enviando múltiples peticiones a este script se consigue aumentar el consumo de recursos, pudiendo causar una denegación de servicio que afectara a todo el servidor. Como ejemplo el ataque sería:
Para que la vulnerabilidad pueda ser explotada es necesario que la opción ‘WP_ALLOW_REPAIR‘ esté habilitada en el archivo de configuración 'wp-config.php'.
Aún no tiene asignado ningún identificador CVE. Son vulnerables las versiones de WordPress desde la 2.9 a la 3.3.1
Ahora bien, si se trata de realizar este ataque en una versión actual de WordPress (como la 3.3.1) no se conseguirá nada ya que lo único que se mostrará es un mensaje que alerta al usuario que debe habilitar WP_ALLOW_REPAIR para poder continuar con la reparación/optimización de la base de datos, y por supuesto que esto solo lo podría hacer un usuario autorizado y con acceso a los archivos de WordPress.
Si el sitio Web de WordPress que se intenta “atacar” tiene técnicas que lo protejan, como archivos .htaccess correctamente configurados, sencillamente bloqueará la petición ya que la página solicitada (repair.php) solo podría ser accedida por un usuario autenticado.
Desde mi humilde punto de vista esto no es una vulnerabilidad, es simplemente una opción de WordPress que si bien podría ser explotada por una configuración errónea, no deja de ser solo eso: una opción más de WordPress. Pero entonces ¿hay algún riesgo? La respuesta es sencilla, si tienes una correcta configuración del sitio, control de errores 404 y seguridad (aunque sea básica) no me parece que se pueda hacer mucho con esta “técnica de ataque”. Además, de forma predeterminada esta opción no está habilitada en el archivo de configuración de WordPress, así que, la opción podría ser “explotada” pero para ello se necesitaría agregar define('WP_ALLOW_REPAIR', true).
No se que otras opiniones pueden haber, pero en mi caso, no veo peligro en esto.
Si el usuario que reporta la "vulnerabilidad" esta pensando en que realizando múltiples peticiones al archivo mencionado conseguirá un DoS….pues me parece una tontería. Eso sería como tratar de hacer lo mismo con cada archivo en una instalación de WordPress y declarar que todos son vulnerables a ataques DoS.
Pero en fin es mi opinión, estaremos al tanto de cualquier novedad en esté caso.
Fuente: Expresión Binaria
La vulnerabilidad se encuentra en las funcionalidades "Reparar la base de datos" y "Reparar y optimizar la base de datos" ("Repair Database" y "Repair and Optimize Database") en "wp-admin/maint/repair.php". Enviando múltiples peticiones a este script se consigue aumentar el consumo de recursos, pudiendo causar una denegación de servicio que afectara a todo el servidor. Como ejemplo el ataque sería:
http://SITIO_WEB/wp-admin/maint/repair.php?repair=1&_wpnonce=a4ca36d5ff
http://SITIO_WEB/wp-admin/maint/repair.php?repair=2&_wpnonce=a4ca36d5ff
Para que la vulnerabilidad pueda ser explotada es necesario que la opción ‘WP_ALLOW_REPAIR‘ esté habilitada en el archivo de configuración 'wp-config.php'.
Aún no tiene asignado ningún identificador CVE. Son vulnerables las versiones de WordPress desde la 2.9 a la 3.3.1
Ahora bien, si se trata de realizar este ataque en una versión actual de WordPress (como la 3.3.1) no se conseguirá nada ya que lo único que se mostrará es un mensaje que alerta al usuario que debe habilitar WP_ALLOW_REPAIR para poder continuar con la reparación/optimización de la base de datos, y por supuesto que esto solo lo podría hacer un usuario autorizado y con acceso a los archivos de WordPress.
Si el sitio Web de WordPress que se intenta “atacar” tiene técnicas que lo protejan, como archivos .htaccess correctamente configurados, sencillamente bloqueará la petición ya que la página solicitada (repair.php) solo podría ser accedida por un usuario autenticado.
Desde mi humilde punto de vista esto no es una vulnerabilidad, es simplemente una opción de WordPress que si bien podría ser explotada por una configuración errónea, no deja de ser solo eso: una opción más de WordPress. Pero entonces ¿hay algún riesgo? La respuesta es sencilla, si tienes una correcta configuración del sitio, control de errores 404 y seguridad (aunque sea básica) no me parece que se pueda hacer mucho con esta “técnica de ataque”. Además, de forma predeterminada esta opción no está habilitada en el archivo de configuración de WordPress, así que, la opción podría ser “explotada” pero para ello se necesitaría agregar define('WP_ALLOW_REPAIR', true).
No se que otras opiniones pueden haber, pero en mi caso, no veo peligro en esto.
Si el usuario que reporta la "vulnerabilidad" esta pensando en que realizando múltiples peticiones al archivo mencionado conseguirá un DoS….pues me parece una tontería. Eso sería como tratar de hacer lo mismo con cada archivo en una instalación de WordPress y declarar que todos son vulnerables a ataques DoS.
Pero en fin es mi opinión, estaremos al tanto de cualquier novedad en esté caso.
Fuente: Expresión Binaria
0 Comments:
Publicar un comentario
Gracias por dejar un comentario en Segu-Info.
Gracias por comentar!