Vulnerabilidades en las interfaces de programación de la herramienta de administración de alojamiento web parcheados.
La API REST de Plesk era vulnerable a la falsificación de solicitudes del lado del cliente (CSRF) lo que podría generar múltiples ataques potenciales, incluida la carga de archivos maliciosos y la toma de control del servidor.
Plesk es una herramienta de administración muy popular para proveedores de alojamiento web y centros de datos. Los usuarios suelen utilizar su interfaz web para administrar sus sitios web y servidores de archivos. Esta interfaz ha sido exhaustivamente probada y parcheada contra agujeros de seguridad.
Sin embargo según los hallazgos de Adrian Tiron investigador de seguridad en Fortbridge, la API REST que permite que los programas de terceros accedan a la funcionalidad de Plesk no era tan sólida como su contraparte de la interfaz de usuario web.
Falsificación de solicitud del lado del cliente
Mientras investigaba Plesk durante un proyecto para uno de sus clientes, Tiron descubrió que cuando se llama a la API REST desde el navegador de un administrador conectado, no hay defensas contra CSRF. Esta deficiencia significaba que si un atacante atrae al administrador de Plesk para que visite una página maliciosa, podría realizar ataques CSRF sin cookies contra el servidor.
Varios puntos finales de API podrían ser atacados a través del exploit CSRF sin cookies. Lo más interesante dijo Tiron fue un punto final que admitía diferentes comandos, incluido el cambio de la contraseña del administrador. Usando este punto final, el investigador pudo secuestrar la cuenta de usuario administrador y obtener el control total del host.
“El acceso de administrador en Plesk es muy potente. Es idéntico a tener acceso raíz porque Plesk se usa para administrar completamente los hosts a través de la interfaz web”, comento.
Otros puntos finales podrían explotarse a través de otros ataques CSRF, incluidos los exploits que permitieron la creación de usuarios de MySQL y FTP en el servidor Plesk.
Dado que el puerto MySQL está bloqueado externamente de forma predeterminada, agregar un usuario de base de datos tendría un impacto limitado.
“Sin embargo, si MySQL está mal configurado, puede dar RCE [ejecución remota de código] en el servidor como un usuario limitado; estimamos que este sería un escenario raro”, dijo Tiron.
El usuario de FTP le daría al atacante “RCE como un usuario limitado (al menos) porque el atacante puede cargar un shell web”, comento.
¿Qué salió mal?
La interfaz web de Plesk utiliza el encabezado Autorización que impide el acceso no autenticado a las páginas de la herramienta de administración. Una vez que un usuario ingresa sus credenciales el navegador agrega automáticamente los encabezados apropiados a las solicitudes, lo que permite que el servidor distinga a los usuarios autenticados.
Los encabezados de autorización también impidieron el acceso aleatorio no autenticado a los puntos finales de la API REST. Pero todo esto puede eludirse potencialmente a través de ataques CSRF basados en HTML.
“Los desarrolladores probablemente pensaron que estaban protegidos contra CSRF porque estaban usando el encabezado de Autorización”, dijo Tiron. “Si bien esto es cierto para las solicitudes creadas con XHR (el atacante necesitaría conocer este encabezado para agregarlo a la solicitud), esto no es cierto si está utilizando formularios HTML; en este caso el navegador adjunta el encabezado de Autorización automáticamente por diseño.”
Plesk ha reparado la vulnerabilidad. Según la empresa el 98,4% de los servidores Plesk se actualizaron automáticamente y, por lo tanto, no se vieron afectados.
Tiron recomendó que los desarrolladores se aseguren de que todas las solicitudes POST que cambien el estado del servidor implementen la mitigación de CSRF utilizando el patrón de token sincronizador o el patrón de cookie de envío doble. “Según nuestra experiencia, recomendamos la primera”, concluyó Tiron.
Fuente: https://portswigger.net/daily-swig/csrf-in-plesk-api-enabled-server-takeover
Es un conocido experto en seguridad móvil y análisis de malware. Estudió Ciencias de la Computación en la NYU y comenzó a trabajar como analista de seguridad cibernética en 2003. Trabaja activamente como experto en antimalware. También trabajó para empresas de seguridad como Kaspersky Lab. Su trabajo diario incluye investigar sobre nuevos incidentes de malware y ciberseguridad. También tiene un profundo nivel de conocimiento en seguridad móvil y vulnerabilidades móviles.