Vulnerabilidad en el plugin WPTouch para WordPress
Hace unos días los chicos de Sucuri informaban a cerca de una grave vulnerabilidad en el script TimThumb y días más tarde reportaban otro fallo de seguridad en el plugin MailPoet para WordPress. Pues parece que estos chicos no descansan y han reportado una nueva vulnerabilidad en el plugin WPTouch para WordPress.
El plugin WPTouch permite disponer de una versión móvil de nuestro sitio WordPress de forma automática y sin complicaciones. Este plugin tiene más de cinco millones de descargas, lo que demuestra la gravedad del asunto. Por si fuese poco, la vulnerabilidad descubierta permite subir un archivo con código malicioso y que el atacante se haga con el control de nuestro WordPress. El error de seguridad ha sido corregido hace unos días con el lanzamiento de la versión WPTouch 3.4.3 que ya soluciona el problema. Debido a la gravedad del tema es recomendable actualizar cuanto antes.
Análisis de la vulnerabilidad en el plugin WPTouch para WordPress
El problema de seguridad permite subir archivos con extensión PHP y así ejecutar código en el servidor remoto. El único requisito es que el blog WordPress permita los registros públicos.
Esta vulnerabilidad guarda mucha relación con el fallo descubierto en el plugin MailPoet y en el que ya informábamos que emplear el hook admin_init para determinar si un usuario puede o no subir archivos no es una forma segura.
El fallo de seguridad nos lo encontramos en el archivo core/class-wptouchpro.php en el que se hace una llamada al método admin_initialize() a través del hook admin_init.
Si analizamos el código vemos que se genera un nonce para determinar si el usuario puede o no subir archivos, lo cual resulta insuficiente. El usuario atcante sólo tiene que seguir dos pasos para subir un archivo sin autorización:
- Acceder a
wp-adminpara obtener unnonceválido (de aquí que el bug sólo afecte a blogs que permiten los registros publicos). - Enviar una petición AJAX para subir un archivo empleando el
nonceque conseguimos en el paso anterior.
De esto sacamos en limpio que el uso de nonces tampoco es seguro para determinar los permisos de un usuario ya que para este propósito lo más recomendable es emplear la función current_user_can().