Se han encontrado múltiples vulnerabilidades en Plone que podrían ser aprovechadas por un atacante remoto para conducir ataques de CSRF, acceder a información sensible o incluso comprometer un sistema vulnerable.
* La primera vulnerabilidad es un Cross-site request forgery causado porque Plone no crea tokens de peticiones HTTP. Esto podría ser aprovechado para predecir las peticiones HTTP, siendo la aplicación vulnerable a ataques de CSRF que permitirían la creación de una cuenta de administración nueva si el administrador visita una página web maliciosa mientras se ha hecho login.
La versión 3.0.5 es vulnerable y es posible que otras anteriores también lo sean.
* Existe otra vulnerabilidad que podría ser aprovechada por un atacante para acceder a información sensible que esté almacenada en cookies, como el nombre de usuario, contraseña y la sesión que están almacenadas en la cookie “__ac”.
Las cookies de todas las cuentas creadas en la versión 2.5 son vulnerables. En la versión 3.0 solo es vulnerable la cuenta admin creada después de la instalación.
Como contramedida para solventar estas dos primeras vulnerabilidades se recomienda no usar la cuenta admin y crear una cuenta con los mismos permisos para sustituirla. Además es recomendable actualizar a la versión 3.x de Plone o realizar conexiones HTTP encriptadas.
* Un tercer problema reside en que las cookies de sesión no cambian nunca lo que podría ser aprovechado para comprometer la aplicación si un atacante es capaz de capturar cualquier cookie de autenticación, ya sea nueva o antigua.
Son vulnerables las versiones 3.x. Como contramedida para solventar este problema se recomienda usar el mecanismo crontab para rotar los secretos usados para crear y validar las cookies de sesión, invalidando así las cookies generadas previamente.
* Por último, un problema que afecta a todas las versiones de Plone, reside en una falta del estado de la autenticación por parte del servidor. Por lo tanto, Plone no sabe si un usuario dado debería estar autenticado (habiendo iniciado la sesión) o no en un momento dado. Esto podría ser aprovechado por un atacante, que robara una cookie de autenticación válida, para comprometer de forma permanente la cuenta de un usuario sin importar si éste ha iniciado la sesión o no. Como contramedida se recomienda usar SessionCrumbler.
laboratorio@hispasec.com
Más información:
Plone CMS Security Research
The Art of Plowning
http://www.procheckup.com/Hacking_Plone_CMS.pdf
Deja una respuesta