El mes pasado me dio por retomar un pasatiempo que me entretiene bastante, es la búsqueda de bug o fallos de seguridad en aplicaciones y recursos web. Esto me lo tomo con bastante calma y a diferencia de lo que son los programas de Bug Bounty y las competiciones de CTF, aquí no hay carrera por llegar el primero. Además también me lo tomo como un modo más de entrenamiento en mi continua formación. Ahora bien, hay que tener mucho cuidado con lo que se intenta evaluar ya que aquí podemos fácilmente cruzar la línea de la legalidad. Partimos desde la lógica de estar tocando un sistema o un activo que nadie nos ha pedido evaluar, por tanto esto siempre puede llevar a mal entendidos y situaciones adversas para nosotros como evaluadores. Para no tener que estar ganándome problemas innecesarios, yo me centro por lo general en la evaluación de aplicativos de software libre; En los plugins de WordPress tenemos bastante terreno por recorrer. ¿Qué nos hace falta para arrancar con todo esto? Pues básicamente el plugin y un entorno donde desplegar nuestro laboratorio con este CMS WordPress.

Vulnerabilidad CVE-2020-13426

Lo que vengo a presentar hoy es una vulnerabilidad básica de Cross-Site Request Forgery, también ubicada con las siglas CSRF en el plugin Multi-Scheduler de WordPress.

Básicamente podríamos definir CSRF como un ataque a través del cual podemos forzar al usuario autenticado a realizar una acción peligrosa y/o no deseada sobre el aplicativo web. Para esta vulnerabilidad concreta y como prueba de concepto (PoC) se evidencia como es posible eliminar registros (de la tabla “professional”) en el aplicativo web, sin el consentimiento expreso del usuario final.

Multi-Scheduler se trata de un plugin que permite gestionar reservas de eventos (citas, reuniones, entrevistas…), manejando para ello un calendario de fechas, un listado de usuarios, listado de direcciones y la generación de reportes.

En la evaluación se evidencio que los formularios que permiten la eliminación y la creación de usuarios no cuenta con mecanismos anti-CSRF, es decir existe carencia en el uso de tokens para estos propósitos, depositando toda la confianza en la acción del usuario final, una acción que puede desatar terribles consecuencia como se observa en la PoC.

Prueba de concepto (PoC)

Para poder demostrar la vulnerabilidad y su impacto se realizó la siguiente PoC que fue enviada al proveedor, en la cual se observa como es posible generar un formulario especialmente diseñado que puede ser enviado a la víctima para que la acción maliciosa (la eliminación de usuario) sea ejecutada en el aplicativo web.

Timeline

  • 2020/05/21: Descubrimiento de la vulnerabilidad
  • 2020/05/22: Notificación al proveedor
  • 2020/05/23: Solicitud de CVE a MITRE
  • 2020/05/23: Obtención del CVE por parte de MITRE
  • 2020/06/20: Publicación de la vulnerabilidad

Referencias