La seguridad como gestión de riesgos

La seguridad siempre ha sido un juego de gestión de riesgos, no de eliminación de riesgos. Cada decisión de abordar una amenaza implica potencialmente dejar otra desatendida. Decidir qué amenaza abordar y en qué orden es la clave del proceso. En este proceso de triaje, las vulnerabilidades de abuso, es decir, la explotación de funciones legítimas de una plataforma de formas no previstas para llevar a cabo actividades maliciosas como campañas de phishing, pueden quedar relegadas en la lista de prioridades de seguridad. Sostengo que es hora de dejar de separar el concepto de vulnerabilidades de abuso y vulnerabilidades de seguridad.

A diferencia de las vulnerabilidades de seguridad, que son esencialmente lagunas o errores en el código explotables, las correcciones para las vulnerabilidades de abuso pueden ser lentas en llegar. Sin embargo, estas brechas para el abuso pueden conducir fácilmente a un desastre si se dejan desatendidas. Cifras recientes muestran que el 68% de las violaciones de datos se originan en este tipo exacto de explotaciones que involucran el factor humano cometiendo un error, como intentos de phishing o vulnerabilidades de abuso.

¿Qué es GitHub?

GitHub es una popular plataforma de alojamiento de código propiedad de Microsoft. Permite a los desarrolladores colaborar, compartir código y gestionar proyectos de manera efectiva. Con su amplia adopción e integración en los flujos de trabajo modernos de desarrollo, GitHub se ha convertido en una herramienta crucial para muchas organizaciones, especialmente en el desarrollo de software y la producción. A su vez, esta adopción generalizada ha llevado a que los actores de amenazas lo ataquen cada vez más para obtener acceso a código propietario, claves/ acceso a sistemas y más.

Resumen de la vulnerabilidad de abuso en GitHub

Si bien GitHub ofrece potentes funciones de colaboración, descubrimos una forma de abusar de su funcionalidad y eludir las configuraciones de seguridad para dirigir a los usuarios de una organización con correos de phishing selectivo. Estos son algunos de los aspectos destacados de este problema:

  • Mecanismo de mención: Al intentar mencionar a un usuario con el signo "@", GitHub sugiere nombres de usuario. Sin embargo, si se conoce el nombre de usuario de un usuario específico (incluso dentro de una organización), mencionarlo lo notificará a través de su método de notificación configurado, que suele ser el correo electrónico por defecto. Esto brinda a los actores de amenazas la capacidad de usar la notificación de GitHub como una forma de enviar correos electrónicos y contactar a usuarios en una organización que no serán detectados por los mecanismos de seguridad del correo electrónico.
  • Falta de controles de privacidad: GitHub no permite a los usuarios establecer controles de privacidad granulares sobre quién puede mencionarlos o etiquetarlos. Esta falta de control significa que cualquiera puede potencialmente mencionar a un usuario, incluso si no forma parte de la misma organización o proyecto.
  • Configuración global de notificaciones: GitHub solo permite a los usuarios establecer sus preferencias de notificación de forma global, sin políticas detalladas ni mecanismos de listas blancas.
  • Persistencia del abuso: Si bien GitHub permite a los usuarios bloquear y reportar a los actores de amenazas y sus problemas, el atacante puede simplemente crear una nueva cuenta de usuario, repositorio y problema para reiniciar el ataque. Esto se facilita infinitamente con IA y otros bots que hacen que este proceso sea trivial para los actores de amenazas.
  • Sin validación de contenido: GitHub no realiza ninguna validación de sintaxis ni utiliza modelos de lenguaje para revisar el contenido, lo que potencialmente permite que cargas maliciosas se cuelen.

La cadena de ataque

Aquí hay un desglose paso a paso de cómo los actores de amenazas pueden explotar esta vulnerabilidad:

  • Configurar repositorio y problema: El atacante crea un nuevo repositorio o se aprovecha de uno existente, luego crea un nuevo problema dentro de él.
  • Dentro del problema, los actores de amenazas pueden crear un formato basado en Markdown. Incluso usamos un LLM para generar el siguiente texto como ejemplo de un actor de amenazas que crea un señuelo de aspecto oficial pidiendo al usuario que inicie sesión en su cuenta y cambie su contraseña.
  • Al reemplazar el nombre de usuario con el nombre de usuario correcto de la víctima, podemos asegurarnos de que el correo electrónico se entregue de manera segura, sin pasar por las medidas de seguridad del correo electrónico, porque estos mecanismos de seguridad del correo electrónico asumirán que un correo electrónico "de" GitHub alertando de una notificación, similar a otras notificaciones necesarias para que el desarrollador realice su trabajo.
  • Una vez enviado, la víctima recibirá el señuelo de phishing por correo electrónico.
  • Como se puede ver, el nombre para mostrar del remitente se deriva del nombre para mostrar del usuario abusador. El actor de amenazas podría incluso cambiarlo fácilmente a algo como "GitHub Security" cambiando el nombre para mostrar y no el nombre de usuario.
  • El remitente malicioso es notifications@github.com, lo que significa que es un remitente de confianza que está siendo abusado para entregar contenido malicioso.

Implicaciones de esta vulnerabilidad de abuso en GitHub

Esta vulnerabilidad plantea un riesgo significativo, ya que permite a los actores de amenazas eludir los controles de seguridad del correo electrónico y entregar contenido malicioso directamente a individuos específicos dentro de las organizaciones. Notará que nunca se implementó código malicioso. En cambio, todo esto se logró utilizando el propio producto de GitHub de formas no previstas. La naturaleza convincente de los correos electrónicos, junto con el abuso del dominio de confianza de GitHub, aumenta la probabilidad de ataques de phishing exitosos en desarrolladores ocupados.

Divulgación responsable y respuesta de GitHub

Divulgamos de manera responsable esta vulnerabilidad de abuso a GitHub a través de su programa de recompensas por errores en HackerOne. Su respuesta fue la siguiente:

Hola @dviros, Gracias por contactarnos. Somos conscientes del comportamiento que describes y lo consideramos un problema de abuso y no una vulnerabilidad de seguridad. Tomamos en serio el abuso y el spam y tenemos un equipo dedicado que rastrea a los usuarios que hacen spam. Saludos cordiales y ¡feliz hacking! @securabee

La respuesta de GitHub indicó que consideran este comportamiento como un problema de abuso en lugar de una vulnerabilidad de seguridad, a pesar de que este tipo de abusos representan la gran mayoría de las violaciones de datos. Reconocieron el potencial de spam y abuso y afirmaron que tienen un equipo dedicado para rastrear y abordar estos problemas. Si bien se agradece la respuesta de GitHub, creemos que se deben tomar medidas más proactivas para mitigar esta vulnerabilidad de manera efectiva. Algunas recomendaciones incluyen:

  • Habilitar controles de privacidad: Permitir a los usuarios, especialmente a los usuarios empresariales, establecer controles de privacidad granulares y listas blancas de personas u organizaciones que puedan mencionarlos o etiquetarlos.
  • Implementar validación de contenido: Aprovechar modelos de lenguaje u otras técnicas para validar el contenido de problemas, comentarios y menciones, particularmente cuando los usuarios intentan mencionar a otros por primera vez o cuando el repositorio no ha sido interactuado previamente por la víctima.
  • Monitorear correos salientes: Implementar mecanismos para monitorear los correos electrónicos salientes de notifications@github.com y bloquear cualquier contenido malicioso que se entregue.
  • Agilizar el proceso de desetiquetado: Proporcionar a los usuarios una forma rápida y fácil de "desetiquetarse" de ser mencionados en problemas, solicitudes de extracción o comentarios, en lugar de depender únicamente de la opción "cancelar suscripción".

Conclusión

Si bien GitHub es una plataforma potente y ampliamente adoptada, esta vulnerabilidad resalta la importancia de las vulnerabilidades de abuso como el primer paso que toman los actores de amenazas para perpetrar violaciones de datos. Simplemente clasificar automáticamente las vulnerabilidades de abuso como separadas de las vulnerabilidades de seguridad resta importancia a su papel en los ataques de los actores de amenazas.