Servidores sin parche para la vulnerabilidad GitLab CVE-2023-7028
- La vulnerabilidad crítica CVE-2023-7028 de GitLab seguía sin parchearse en más de 5,300 servidores hasta el martes, lo que podría permitir el secuestro remoto de cuentas de desarrolladores de software.
- Este bug recibió la puntuación máxima de CVSS de 10 puntos, y GitLab lo divulgó y parchó por primera vez el 11 de enero.
- Debido a una falla en el sistema de inicio de sesión de GitLab, un atacante puede enviar un enlace de restablecimiento de contraseña a una dirección de correo no autenticada sin interacción de la víctima.
Información del parche y resultados de pruebas de la vulnerabilidad
- Se publicaron actualizaciones de seguridad para las versiones 16.5.6, 16.6.4 y 16.7.2 de GitLab, y también se hicieron backports a las versiones 16.1.6, 16.2.9, 16.3.7 y 16.4.5.
- Un investigador probó el bug en GitLab Community Edition versión 16.6.1 y compartió en AttackerKB que era "muy efectivo y fácil de explotar".
Detección de instancias vulnerables y tendencia a la baja
- Casi dos semanas después de que el parche estuviera disponible, la Shadowserver Foundation detectó 5,379 instancias vulnerables de GitLab en todo el mundo.
- Estados Unidos y Alemania tenían la mayor cantidad de instancias vulnerables, con 964 y 730 respectivamente.
- La herramienta de panel de Shadowserver mostró que el 24 de enero las instancias vulnerables se redujeron a 4,652.
- Un vocero de Shadowserver comentó a SC Media que la disminución de instancias vulnerables es un avance positivo, pero que se necesita más tiempo para determinar si se trata de una tendencia o de una simple fluctuación.
Indicadores de compromiso de GitLab CVE-2023-7028
- Los clientes de GitLab con instancias autogestionadas de GitLab Community Edition y GitLab Enterprise Edition deben revisar los logs para verificar si CVE-2023-7028 fue explotada.
- Deben revisar las solicitudes HTTP hacia la ruta /users/password en
gitlab-rails/production_json.log y comprobar si params.value.email está compuesto por un arreglo JSON con varias direcciones de correo.
- También deben revisar en
gitlabs-rails/audit_json.log las entradas donde meta.caller.id sea PasswordsController#create y target_Details esté compuesto por un arreglo JSON con varias direcciones de correo.
- No se detectó explotación de este bug en GitLab.com ni en instancias dedicadas de GitLab.
- GitLab también recomienda habilitar la autenticación de dos factores (2FA), que evita la toma de cuentas mediante CVE-2023-7028, aunque los usuarios de instancias sin parche siguen corriendo el riesgo de quedar bloqueados fuera de sus cuentas si un atacante explota la vulnerabilidad para restablecer la contraseña.
Opinión de GN⁺
- Este artículo ofrece información importante relacionada con una vulnerabilidad de seguridad crítica en GitLab. CVE-2023-7028 puede representar una amenaza directa para la seguridad de las cuentas de desarrolladores de software, por lo que se requieren medidas adecuadas.
- Aunque ya existe un parche, una gran cantidad de servidores en todo el mundo sigue en estado vulnerable, lo que subraya la importancia de la conciencia en seguridad y de aplicar actualizaciones a tiempo.
- También destaca la importancia de la autenticación de dos factores (2FA) y promueve una mayor conciencia de seguridad al recomendar a los usuarios aprovechar medidas adicionales de protección.
1 comentarios
Comentarios de Hacker News
"Quiero hablar sobre el riesgo de la funcionalidad de 'vincular una dirección de correo con una cuenta' en aplicaciones web basadas en cuentas. Es una de las primeras cosas que los pentesters intentan manipular de inmediato, y se han encontrado vulnerabilidades desde principios de los 2000. Este problema también se repitió en GitLab. GitLab tiene un excelente equipo de seguridad, pero parece que es difícil evitar este tipo de errores. Si eres un lector común de Hacker News interesado en esta historia, te recomendaría revisar tu propia función de restablecimiento de contraseña, en especial la lógica de vinculación de correo electrónico."
"Comparto el enlace al commit donde se encontró esta vulnerabilidad en el codebase de Rails: enlace al commit de GitLab"
"Me vi afectado por este bug. El ataque requiere conocer el correo del usuario, pero existe una dirección de correo oculta vinculada al ID de usuario de GitLab (un número que incrementa desde 1). Es probable que los ID 1 o 2 sean administradores, así que son buenos objetivos. El formato del correo es '1-user@mail.noreply.<gitlabhost>'. Parecía un ataque automatizado, y 2FA nos salvó."
"El restablecimiento de contraseña por correo electrónico es una pesadilla de seguridad incluso cuando está implementado correctamente. En la mayoría de los servicios no se puede desactivar esta función, y la alternativa suele ser solo SSO empresarial. En algunos servicios puedes configurar un número telefónico para tokens por SMS, pero nunca he visto una opción que exija tanto correo electrónico como token por SMS."
"Una vez encontré un bug que permitía hacer un ataque de fuerza bruta contra cuentas ingresando un arreglo de contraseñas en el formulario de inicio de sesión. Era una interfaz web bastante chapucera para un appliance antispam, y no estoy seguro de si era intencional o si el código lo escribió un principiante en PHP. Lo descubrió un usuario que en ese momento usaba una contraseña con caracteres especiales."
"Esto recuerda que los servicios internos como GitLab conviene operarlos detrás de una VPN a la que solo puedan acceder usuarios de confianza."
"Automatizar las actualizaciones de GitLab es muy fácil. Basta con usar GitLab en Docker+Compose y actualizarlo diariamente con Watchtower o algo similar. Llevo más de 7 años operando servidores GitLab de esta forma y no he tenido problemas. Si miras alrededor, hay muchos GitLab en versiones antiguas; ¿qué están haciendo los administradores?"
"Tengo la regla de no exponer a internet pública ningún tipo de servidor interno. Solo permito el acceso a través de VPN para construir una segunda línea de defensa."
"Otro recordatorio de que siempre hay que usar SSO y no olvidar 2FA."
"Dejemos de pensar que Ruby/Rails es una opción adecuada para software que debe ser seguro. Entiendo por qué GitLab tiene que lidiar con esto, pero hacia adelante debemos reconocer que algo más simple es mejor que lenguajes y frameworks que priorizan flujos de control inteligentes y ocultos. Trabajo en un codebase de Ruby en producción, y claramente puedo ver la posibilidad de que surjan problemas similares por culpa de alguien que pensó que múltiples capas de abstracción hacían que el código fuera muy extensible."