Error de restablecimiento de contraseña en GitLab pone en riesgo a más de 5,300 servidores

 (scmagazine.com)
1 puntos por GN⁺ 2024-01-29 | 1 comentarios | Compartir por WhatsApp
  • La vulnerabilidad CVE-2023-7028 de GitLab seguía presente en 5,379 servidores de todo el mundo casi dos semanas después de publicarse el parche, lo que podría derivar en el secuestro remoto de cuentas de desarrolladores
  • El problema está en el flujo de restablecimiento de contraseña del sistema de inicio de sesión, y permite que un atacante haga que el enlace de restablecimiento se envíe a su propia dirección de correo no verificada sin interacción de la víctima
  • GitLab divulgó el 11 de enero de 2024 la vulnerabilidad con CVSS 10 y publicó actualizaciones de seguridad para las versiones 16.5.6, 16.6.4, 16.7.2 y las versiones con backport 16.1.6~16.4.5
  • Shadowserver Foundation detectó 5,379 instancias vulnerables el 23 de enero; Estados Unidos con 964 y Alemania con 730 fueron los países con más casos, y el 24 de enero la cifra bajó a 4,652
  • Los operadores de GitLab Community Edition y Enterprise Edition self-managed deben revisar en los logs solicitudes de restablecimiento con forma de arreglo de múltiples correos electrónicos y activar 2FA para reducir el riesgo de secuestro de cuentas

Riesgo de CVE-2023-7028

  • CVE-2023-7028 es una vulnerabilidad del sistema de inicio de sesión de GitLab que puede derivar en el secuestro remoto de cuentas en servidores GitLab sin parchar
  • GitLab divulgó y parchó por primera vez esta vulnerabilidad el 11 de enero de 2024
  • La vulnerabilidad tiene una puntuación CVSS de 10, la severidad máxima
  • Un atacante puede enviar el correo de restablecimiento de contraseña a su propia dirección de correo no verificada, sin interacción de la víctima, mediante una solicitud HTTP especialmente construida
  • Un investigador que la probó en GitLab Community Edition 16.6.1 evaluó en AttackerKB que CVE-2023-7028 es “muy efectiva y fácil de explotar”

Versiones afectadas y parches

  • GitLab proporcionó actualizaciones de seguridad para las siguientes versiones
    • 16.5.6
    • 16.6.4
    • 16.7.2
  • Los parches también se aplicaron como backport a las siguientes versiones
    • 16.1.6
    • 16.2.9
    • 16.3.7
    • 16.4.5

Resultados de detección de Shadowserver

  • Shadowserver Foundation detectó el 23 de enero, casi dos semanas después de publicarse el parche, 5,379 instancias de GitLab vulnerables en todo el mundo
  • Por país, Estados Unidos y Alemania tenían la mayor cantidad de instancias vulnerables
    • Estados Unidos: 964
    • Alemania: 730
  • El 24 de enero, la cantidad de instancias vulnerables en el dashboard de Shadowserver bajó a 4,652
  • Shadowserver confirmó que la disminución en sí es positiva, pero que se necesita más tiempo para determinar si es una tendencia real o una fluctuación temporal del escaneo

Cómo verificar indicadores de compromiso

  • Los clientes de GitLab Community Edition y GitLab Enterprise Edition self-managed deben revisar los logs en busca de rastros de explotación de CVE-2023-7028
  • Los logs y condiciones a revisar son los siguientes
    • gitlab-rails/production_json.log: cuando, entre las solicitudes HTTP entrantes a la ruta /users/password, params.value.email es un arreglo JSON que contiene varias direcciones de correo electrónico
    • gitlabs-rails/audit_json.log: cuando meta.caller.id es PasswordsController#create y target_Details es un arreglo JSON que contiene varias direcciones de correo electrónico

Impacto en GitLab.com, GitLab Dedicated y 2FA

  • GitLab afirmó que no detectó casos de explotación de este bug en instancias de GitLab.com o GitLab Dedicated
  • Se recomienda a los clientes activar 2FA
  • 2FA impide el secuestro de cuentas mediante CVE-2023-7028, pero en instancias sin parchar un atacante aún puede restablecer la contraseña y dejar al usuario bloqueado fuera de su cuenta

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-01-29
Comentarios de Hacker News

  • La función de vincular una dirección de correo electrónico a una cuenta en una webapp basada en cuentas me parece realmente aterradora
    No conozco el historial de este bug, pero es una zona que los pentesters tocan de inmediato, y es un tipo de vulnerabilidad antigua que se remonta incluso a fallas en implementaciones estándar de Unix MTA de principios de los 2000 que permitían engañar al sistema para enviar correos de restablecimiento de contraseña a varias direcciones
    Da la impresión de que, en GitLab, un framework web con muchas funciones revivió esa superficie de ataque, y si algún lector común de HN se interesó en esto, le convendría revisar su función de restablecimiento de contraseña, en especial la lógica de vinculación de correo electrónico
    Tengo entendido que el equipo de seguridad de GitLab es bastante bueno, así que el hecho de que haya salido un bug así muestra lo difícil que es evitar esta familia de errores

    • Viendo el comportamiento que explicaron en otro comentario, este bug parece muy fácil de evitar
      Si hubieran usado un lenguaje de tipado estático, sería difícil que apareciera a menos que alguien lo hiciera así a propósito, y en una revisión de código habría sido tan evidente que hasta parecería que un compañero estaba intentando meter una puerta trasera
    • No creo que sea justo decir que el equipo de seguridad de GitLab es excelente
      La función de vincular direcciones de correo secundarias se agregó hace poco y no era una función original, así que parece que tomaron atajos sin hacer pruebas serias de abuso sobre una función nueva relacionada con la seguridad de cuentas
      Además, creo que también hubo un CVE con CVSS 9.6 donde una integración podía ejecutar comandos con permisos de otro usuario
      Desde afuera, parece que la velocidad de lanzamiento de funciones está superando la velocidad a la que pueden probarlas con seguridad, y tal vez tenga que ver con lo difícil que es monetizar
      Desde el punto de vista del negocio es entendible hasta cierto punto, pero si el núcleo de una solución Git autoalojada es básicamente la gestión de cuentas, este tipo de problemas de seguridad puede hundir el negocio entero
    • Es una postura rara
      Si no fuera al correo electrónico, ¿a qué habría que vincularlo? He operado sitios con grandes bases de usuarios durante más de 20 años, y al principio usábamos nombres de usuario, pero fue un desastre
      Todo el mundo conocía los nombres de usuario de los demás, así que era fácil intentar fuerza bruta o restablecimientos de contraseña
      El problema no es usar correo electrónico en sí, sino hacer demasiado complejas la lógica de inicio de sesión y recuperación de contraseña, abusar de las abstracciones, sobreingenierizar, y meter código en áreas sensibles de seguridad sin validarlo como corresponde
      También hay que revisar el historial de seguridad de GitLab. Varias veces al año aparecían exploits críticos y había que hacer upgrades de emergencia en despliegues de GitLab; en términos de seguridad, GitLab fue lo peor que he usado
    • Cada vez que recibo un correo raro de restablecimiento de contraseña, me preocupa que alguien haya agregado a escondidas una dirección de correo de recuperación fuera de mi control para secuestrar mi cuenta
      Todavía no me ha pasado, pero por desgracia, como muestra este caso, es totalmente posible
    • ¿Cómo funciona este exploit? Me interesaría si hay algún enlace a una explicación bien resumida

  • Si quieren ver la parte del codebase de Rails que llevó a este exploit, el commit de corrección está aquí
    https://gitlab.com/gitlab-org/gitlab/-/commit/c571840ba2f0e9...

    • Esto parece más un refactor posterior que una corrección real
      La corrección parece estar aquí: https://gitlab.com/gitlab-org/gitlab/-/commit/abe79e4ec43798...
      Cambia de recoverable.send_reset_password_instructions(to: email) if recoverable&.persisted? a recoverable.send_reset_password_instructions if recoverable&.persisted?
    • # Concern that overrides the Devise methods / # to send reset password instructions to any verified user email / module RecoverableByAnyEmail: ¿eso quiere decir que esto era una función?
      Pero incluso en la versión corregida sigue llamándose RecoverableByAnyEmail. ¿La gente no lee el código alrededor de lo que está cambiando?
    • No conozco bien Ruby, ¿alguien puede señalar exactamente dónde está el error?

  • Nosotros también sufrimos este ataque, y vimos que se usaba junto con una segunda “función” que ampliaba aún más la exposición
    Básicamente, para este ataque necesitas conocer el correo del usuario cuya contraseña quieres restablecer, pero existe una dirección de correo oculta vinculada al ID de usuario de GitLab. Ese ID es un número que va incrementando desde 1
    Es muy probable que el ID 1 o 2 sea un administrador, así que son buenos objetivos, y el correo tiene una forma como 1-user@mail.noreply..
    Fue realmente malo y parecía automatizado. Aquí nos salvó el 2FA

  • El restablecimiento de contraseña por correo electrónico es una pesadilla de seguridad incluso cuando está bien implementado
    Peor aún, en la mayoría de los servicios no se puede desactivar, y por lo general la única forma de evitarlo es con Enterprise SSO
    Algunos servicios te dejan configurar un número de teléfono para tokens por SMS, pero nunca he visto que exijan tanto correo como token por SMS

    • Me da curiosidad por qué lo consideras una pesadilla de seguridad

  • Me recordó a un bug donde se podía hacer fuerza bruta a cuentas metiendo un arreglo de contraseñas en el formulario de login
    Encima era la interfaz web cutre de un equipo de spam, y no sé si era intencional o si era código hecho por un principiante en PHP
    Lo descubrió un usuario cuya contraseña incluía un carácter especial, algo poco común en esa época

    • Ruby on Rails trata los arreglos pasados como parámetro a .where(...) del ORM como una condición OR entre los valores del arreglo
      Así que, si el código era algo como User.where(name: name, password: password), parece totalmente posible que ocurriera algo así

  • Es un buen recordatorio de que los servicios internos como GitLab deben estar detrás de una VPN, accesibles solo para usuarios de confianza.

    • De verdad no entiendo por qué pondrías el control de versiones interno y el CI/CD en el internet público.
      Justo para eso existe una VPN.
    • Sí, a nosotros también nos salvó por eso, y además teníamos algunas otras medidas.
      Trabajo en una gran empresa estatal de telecomunicaciones, y el equipo de redes es realmente excelente. Se aseguran de que el equipo de servidores no se pase de la raya.
      Expusimos GitLab hasta cierto punto para ciertos proyectos externos y consultores, pero aun así no se puede acceder libremente desde internet.
      Los usuarios también se gestionan desde AD, así que ni siquiera existe una conexión SMTP para el restablecimiento de contraseñas.
      Aun así, hay que reforzar más la obligatoriedad de 2FA. En este momento, cada proyecto puede definir sus propias reglas de 2FA.

  • Honestamente, no pondría ningún servidor interno en el internet público.
    Es mejor hacer que solo se acceda por VPN y tener una segunda línea de defensa.

    • Especialmente con algo como GitLab, hay muchas ventajas para las integraciones externas que necesitan llamar a la API de GitLab.
      También sería posible permitir en lista blanca exactamente solo esas solicitudes, pero puede ser bastante engorroso.
    • GitLab es mi opción favorita para operar una forja de código: git.drk.sc
      En entornos de alta seguridad estoy de acuerdo en usar tácticas más defensivas, pero creo que el software debe diseñarse para poder resistir incluso en la web pública.
    • Sí, sobre todo si en la empresa usan un GitLab autoalojado, siempre debería estar detrás de la VPN corporativa.

  • Automatizar las actualizaciones de GitLab es realmente fácil.
    Con solo ver una opción, si usas GitLab con Docker+Compose, es muy estable, y una herramienta como Watchtower puede actualizarlo todos los días.
    Tengo dos servidores GitLab funcionando así desde hace más de 7 años y nunca he tenido problemas.
    Cuando veo alrededor, hay demasiados GitLab viejos; no sé qué están haciendo los administradores.

  • Ya basta de fingir que Ruby/Rails es una buena elección para software que debe ser seguro.
    Entiendo que GitLab ya quedó así y hay que lidiar con ello, pero de aquí en adelante hay que dejar de fingir que los lenguajes y frameworks que priorizan la astucia y el flujo de control oculto son mejores que alternativas más aburridas.
    Si sueno demasiado molesto, es porque tengo que lidiar con bases de código Ruby reales en producción.
    Se ven bastantes escenarios esperando a que se exploten problemas parecidos, porque alguien pensó que 17 capas de abstracción hacían que el código fuera súper extensible.

    • Creo que conviene evitar lenguajes o frameworks que permitan que quien hace la llamada pueda especificar algún parámetro como cadena o arreglo de cadenas.
      Es muy probable que el costo de este solo error supere todo el valor obtenido por usar esa función.

  • Otro recordatorio de que siempre hay que usar SSO y 2FA.