Múltiples vulnerabilidades XSS en WordPress y el plugin Akismet

Actualización (09/03/2007): Finalmente ya existe un parche oficial para el problema reportado el lunes pasado (Secunia Advisory SA24430, Ticket WordPress), como había comentado estos fallos afectaban a la rama 2.x y a la última versión de desarrollo, adicionalmente se han hecho correcciones en otros archivos más:

  • Rama 2.0
    • wp-admin/admin-functions.php (equivale al problema reportado en wp-admin/import/mt.php)
  • Rama 2.1
    • wp-admin/admin-functions.php
    • wp-admin/custom-header.php
    • wp-admin/upload-functions.php (no reportado previamente)
    • wp-includes/script-loader.php (no reportado previamente)
  • Versión en desarrollo
    • wp-admin/admin-functions.php
    • wp-admin/custom-header.php
    • wp-admin/upload-functions.php (no reportado previamente)
    • wp-includes/script-loader.php (no reportado previamente)

El fallo todavía persiste en el plugin akismet, hasta que lo solucionen pueden usar la versión modificada que puse hace unos días.


Desde los casi tres años que vengo usando WordPress, es la primera vez que veo que se reportan con mayor frecuencia fallos de seguridad en este CMS, imagino que esto se debe a la popularidad que alcanzó y también a nuevas características que se añaden en cada versión mayor.

Por otro lado, uno de los aspectos que hace de WordPress una aplicación muy extensible y a la vez bastante insegura son los plugins, puesto que los que alguna vez desarrollamos uno de éstos, probablemente hayamos introducido algún fallo de tipo SQL Injection, XSS o el menos tomado en cuenta CSRF, que entre otras cosas van a comprometer la instalación principal de WordPress e inclusive el servidor donde se aloja éste.

Me parece que alguien debería evangelizar la escritura de plugins seguros por el daño que pueden causar sin son mal programados -de nada sirve que los desarrolladores de este CMS se "rompan el lomo" añadiendo características para hacer más seguro el core, si en los plugins casi nadie más las usa por desconocimiento o falta de documentación.

En fin, hago el comentario anterior, puesto gran parte de los plugins que actualmente estoy usando, tienen problemas de seguridad* (XSS y CSRF principalmente), que en la medida de lo posible, intentaré reportarlo a sus autores.

Luego de la larga y aburrida queja, paso a comentar que existen vulnerabilidades de tipo XSS en los siguientes archivos.

  1. wp-admin/edit-comments.php: no se escapan parámetros arbitrarios al momento de realizar la paginación. Prueba de concepto.
  2. wp-admin/import/mt.php: no se escapa la url que se genera para el atributo action del formulario para importar un blog del tipo Movable Type. Prueba de concepto.
  3. wp-admin/custom-header.php: el mismo problema de validación de datos, no pongo una prueba de concepto porque no se puede acceder directamente a esta página.
  4. wp-content/plugins/akismet/akismet.php: el mismo problema del punto 1 al momento de paginar los comentarios de tipo spam, la prueba de concepto es parecida, sólo hay que agregar el parámetro page=akismet-admin.

Al momento de publicar esta entrada programada, seguramente ya habrá un parche oficial en la página de reporte de incidencias de WordPress (aunque hice el reporte a través de security@wordpress.org), pero para los impacientes pongo una solución temporal (**).

Actualización (06/03/2007): Los fallos en wp-admin/edit-comments.php y wp-admin/custom-header.php sólo se pueden reproducir a partir de la rama 2.1.x, el de wp-admin/import/mt.php y akismet me parece que a partir de la rama 2.0.x.

*: Si, también los plugins que desarrollé tienen estos problemas :D , pero estoy aprendiendo.
**: Los archivos modificados corresponden a la versión 2.1.2 (ver diferencias), úsenlo bajo vuestra responsabilidad.

11 thoughts on “Múltiples vulnerabilidades XSS en WordPress y el plugin Akismet”

  1. Pingback: SigT
  2. Acabo de instalar tu variante parcheada del Akismet. Al borrar el spam se genera una página de no encontrado. Eso sí, los borra.

    En WP 2.0.10

  3. Hmm, no probé con la versión de WordPress que mencionas, pero lo único que tienes que hacer para corregir ese problema, es aplicar la función clean_url o attribute_escape a toda salida de add_query_arg que encuentres.

    Saludos

  4. Acabo de probar la versión que publiqué en WordPress 2.0.10 y no puedo reproducir el problema que mencionas.

    Por cierto, gracias por las recomendaciones ;)

Comments are closed.