A mediados de marzo se descubrieron varias vulnerabilidades en el plugin Siteground Security, instalado en más de 400.000 sitios web.
Contenido
El primer fallo es un: Autentication Bypass
El primer fallo provoca que los atacantes obtengan permisos de usuario administrativo en sitios vulnerables cuando la autenticación de dos factores (2FA) esta habilitada pero sin configurar.
Los sitios alojados en la plataforma de SiteGround han sido actualizados automáticamente a la versión parcheada, mientras que los alojados en otros lugares requerirán una actualización manual, si las actualizaciones automáticas no están habilitadas para el plugin. Recomendamos encarecidamente que se asegure de que su sitio ha sido actualizado a la última versión parcheada de «SiteGround Security», que es la versión 1.2.6 en el momento de esta publicación.
- Descripcion: Authentication Bypass via 2-Factor Authentication Setup
- Plugin: SiteGround Security
- Plugin Slug: sg-security
- Plugin Developer: SiteGround
- Affected Versions: <= 1.2.5
- CVE ID: CVE-2022-0992
- CVSS Score: 9.8 (Critical)
- CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
- Fully Patched Version: 1.2.6
SiteGround Security es un plugin diseñado para mejorar la seguridad de las instalaciones de WordPress a través de varias características como la seguridad de inicio de sesión, incluyendo 2FA, el endurecimiento general de WordPress, la supervisión de la actividad, y más. También vale la pena señalar que viene preinstalado en todos los sitios de WordPress alojados en SiteGround. Desafortunadamente, la funcionalidad 2FA del plugin fue implementada de manera insegura, haciendo posible que atacantes no autenticados obtengan acceso a cuentas privilegiadas.
Cuando la autenticación de dos factores está activada, requiere que todos los usuarios administrativos y editores configuren la autenticación de dos factores. Este requisito se activa cuando los usuarios administrativos y editores del sitio se conectan por primera vez después de que se haya habilitado el 2FA, momento en el que se les pide que configuren el 2FA para su cuenta. Esto significa que habrá un período de tiempo entre la habilitación de la 2FA en un sitio y la configuración de cada usuario para la cuenta.
Durante este período intermedio, los atacantes podrían secuestrar el proceso de configuración de la 2FA. El plugin tenía un fallo que hacía que los atacantes pudieran saltarse completamente el primer paso de la autenticación, que requiere un nombre de usuario y una contraseña, y acceder a la página de configuración de 2FA para los usuarios que aún no habían configurado 2FA.
Era tan sencillo como suministrar el ID de usuario que querían comprometer a través del sg-user-id junto con algunos otros parámetros para indicar que desean activar el proceso de configuración inicial de 2FA.
La siguiente función validate_2fa_login() muestra el proceso por el que se valida un ID proporcionado por el usuario. Si los resultados de la función check_authentication_code() y la meta sg_security_2fa_configured user devuelven false, lo que indica que 2FA aún no ha sido configurado para ese usuario, entonces el plugin cargaría la plantilla 2fa-initial-setup-form.php que muestra el código QR y el secreto 2FA necesarios para configurar la aplicación autenticadora para el ID suministrado por el usuario.
El código QR devuelto y la clave secreta son lo único que se necesita para conectar la cuenta de usuario con un mecanismo de autenticación, como Google Authenticator. Los atacantes fueron capaces de utilizar esto para conectar su aplicación de autenticación con la cuenta y utilizar con éxito un código para pasar el «segundo factor de autenticación». Esta función establecería entonces las cookies de autenticación del usuario a través de la función wp_set_auth_cookie() utilizando el ID suministrado por el usuario desde el parámetro sg-user-id, que efectivamente inicia la sesión del atacante como ese usuario. Debido a la configuración por defecto del plugin, esta cuenta sería probablemente un usuario privilegiado como un administrador o editor. También vale la pena señalar que la función devuelve los códigos de respaldo que podrían ser utilizados a través de la debilidad descrita en la siguiente sección.
En resumen, no había validación en la función validate_2fa_login() de que la identidad que un usuario estaba reclamando era de hecho legítima. Por lo tanto, los atacantes podían eludir el primer mecanismo de autenticación, un par de nombre de usuario/contraseña, que está destinado a probar la identidad y a iniciar sesión con éxito, debido a una debilidad en el segundo mecanismo de autenticación, el proceso 2FA. Si tiene éxito, un atacante podría infectar completamente un sitio explotando esta vulnerabilidad.
Otro fallo de authentication bypass
Además de la vulnerabilidad mencionada anteriormente, el método en el que se manejaba la autenticación del código de respaldo 2FA hacía posible que los atacantes pudieran iniciar sesión si eran capaces de forzar un código de respaldo para un usuario o comprometerlo a través de otros medios como la inyección SQL.
- Descripcion: Authorization Weakness to Authentication Bypass via 2-Factor Authentication Back-up Codes
- Plugin: SiteGround Security
- Plugin Slug: sg-security
- Plugin Developer: SiteGround
- Affected Versions: <= 1.2.4
- CVE ID: CVE-2022-0993
- CVSS Score: 8.1 (High)
- CVSS Vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
- Fully Patched Version: 1.2.6
Profundizando, el plugin registró la función validate_2fabc_login() que validaba el código de respaldo suministrado a través de la función validate_backup_login() utilizando el ID de usuario suministrado por el parámetro sg-user-id junto con el código de respaldo suministrado a través del parámetro sgc2fabackupcode. Si el código de respaldo se encuentra en la matriz de códigos de respaldo almacenados para ese usuario, entonces la función utilizará la función wp_set_auth_cookie() para establecer las cookies de autenticación para el ID de usuario suministrado. Si ese ID de usuario pertenecía a un administrador, el atacante se conectaría efectivamente como un administrador.
Al igual que en la vulnerabilidad anterior, el problema aquí es que no había una verdadera validación de la identidad para la autenticación, lo que indica una debilidad de autorización. La función no realizaba comprobaciones para verificar que un usuario se había autenticado previamente antes de introducir el código de respaldo 2FA, y como tal no necesitaba iniciar sesión legítimamente antes de iniciar sesión mientras se utilizaba un código de respaldo. Esto significa que no había comprobaciones para validar que un usuario estaba autorizado a utilizar un código de reserva para realizar el segundo factor de autenticación que le permitiría iniciar la sesión.
Aunque el riesgo en este caso es menor, los códigos de respaldo tenían 8 dígitos y eran totalmente numéricos, por lo que un atacante podría forzar uno de los 8 códigos de respaldo y acceder automáticamente sin conocer la combinación de nombre de usuario y contraseña de un usuario administrativo.
Aunque esto podría no ser práctico para intentar en la mayoría de los servidores, un adversario paciente atacando un servidor bien aprovisionado capaz de procesar un gran número de solicitudes a la vez tendría una alta probabilidad de eventualmente obtener acceso a menos que los intentos de fuerza bruta fueran detenidos por otro mecanismo, como la protección de fuerza bruta incorporada en el plugins como el plugin Wordfence o reglas de limitación de velocidad.
Además, esta vulnerabilidad podría utilizarse junto con otra, como la inyección SQL, en la que un atacante podría comprometer los códigos de respaldo de 2FA que se almacenan en la base de datos y luego utilizarlos para iniciar sesión sin necesidad de descifrar la contraseña de un usuario administrativo, que probablemente sería mucho más fuerte. En ambos casos, el impacto sería significativo, ya que un atacante podría obtener acceso administrativo al sitio de WordPress comprometido, que podría ser utilizado para la infección completa del sitio.
Conclusión
Te recomendamos encarecidamente que te asegures de que su sitio ha sido actualizado a la última versión parcheada de «SiteGround Security», que es la versión 1.2.6 en el momento de esta publicación.
También es importante desactivar las cuentas de usuario que no estén en uso y hay que realizar configuraciones de los plugins instalados, y si no se utilizan desinstalarlos.