Abuso de la infraestructura de Go

Problema

• Anoche, mientras exploraba el contenido de la base de datos de checksums de Go, encontré un resultado interesante.
• Al ejecutar el comando sqlite> select path, count(path) from modules group by path order by count(path) desc;, el resultado fue:
  • github.com/homebrew/homebrew-core|39438
  • github.com/Homebrew/homebrew-core|30896
  • github.com/concourse/concourse|25372
  • github.com/openshift/release|24065
  • github.com/cilium/cilium|22138
• Se sabe que Homebrew usa Ruby, así que su conexión con Go resultaba extraña.
• Las estadísticas de lenguaje de GitHub también lo confirmaban.
• Cloné el repositorio para buscar archivos relacionados con Go (go.mod o archivos fuente de Go), pero no encontré nada.

Investigación

• Comenzó un nuevo día y la curiosidad exigía una respuesta.
• Si el repositorio Git no estaba relacionado con código Go, surgía la duda de cómo aparecía en la base de datos de checksums de Go.
• Descubrí que proxy.golang.org es el proxy de módulos predeterminado y que sum.golang.org es la base de datos de checksums.
• Al leer la documentación de Go, entendí que, si una versión de un módulo aún no está registrada en el log, la base de datos de checksums intenta obtener el módulo desde el servidor de origen.
• Para verificar si un nuevo repositorio de módulos Go se agregaba a la base de datos de checksums y al proxy, probé el endpoint lookup.
• Después de crear un nuevo módulo Go y subirlo a mi cuenta de GitHub, intenté el comando lookup en dos formatos, pero ambos devolvieron error.
• Generé la pseudoversión correcta y volví a consultar la base de datos de checksums para verificar si el módulo había sido descargado.
• Consulté el proxy y descargué el zip del módulo, demostrando que es posible almacenar datos arbitrarios en la infraestructura de Go.

Posibilidades de abuso

• Podría usarse para evadir restricciones de descarga en máquinas de desarrolladores y servidores de CI/CD.
• Un malware podría almacenar su payload y recuperarlo del proxy cuando lo necesite.
• Podría ser posible realizar un ataque de denegación de servicio (DoS) contra proxy.golang.org.
• Se puede implementar fácilmente un sistema de comando y control (C2).

Conclusión

• Ahora entiendo cómo funciona el proceso de la base de datos de checksums.
• Por ahora no parece ser un problema grave en la infraestructura de Go, pero existe potencial de abuso.
• Quedan más preguntas sobre por qué hay proyectos no relacionados con Go dentro de la base de datos.
• Esta investigación me dio muchas ideas y planeo seguir explorándolas.

Opinión de GN⁺

1. Vulnerabilidad de seguridad: Este artículo señala una vulnerabilidad de seguridad en la base de datos de checksums de Go, que permite almacenar datos arbitrarios. Esto podría abrir una vía para distribuir malware con facilidad.
2. Necesidad de mejoras: Es necesario mejorar el control de acceso de la base de datos de checksums y de los servidores proxy para reforzar la seguridad y la integridad de la infraestructura de Go.
3. Integración con otros lenguajes: Hace falta aclarar por qué proyectos no relacionados con Go están incluidos en la base de datos de checksums, y se necesitan procedimientos de verificación adicionales para evitarlo.
4. Capacitación para desarrolladores: Es importante capacitar a los desarrolladores para que reconozcan estas vulnerabilidades de seguridad y comprendan las mejores prácticas para prevenirlas.
5. Soluciones alternativas: Se pueden comparar bases de datos de checksums y servidores proxy de otros lenguajes que ofrecen funciones similares, y usarlos como referencia para mejorar la infraestructura de Go.

[GN⁺]

Opiniones de Hacker News

Resumen de comentarios de Hacker News

• Posibilidad de abuso de los servicios en línea

  • Al final, cualquier servicio en línea puede ser abusado para mando y control, infracción de derechos de autor o alojamiento de CSAM. Ya existen casos así con Twitter, Telegram, la infraestructura de claves PGP y otros.

• Problema de alojamiento de archivos en Google

  • Google lidia con frecuencia con el problema del alojamiento de archivos maliciosos, así que es posible que el equipo de Go haya colaborado con GCP y Drive. Esto no es muy distinto de otros endpoints que Google ya permite.

• Comparación con GitHub

  • Hay quien opina que no hay una gran diferencia con subir archivos a GitHub. GitHub también permite almacenar datos arbitrarios mientras tengas una cuenta.

• Proyectos no escritos en Python en PyPI

  • En PyPI también hay proyectos que no son de Python, y se necesita la posibilidad de distribuir wheels (binarios compilados) para cuando los usuarios no pueden compilar el código de una librería. Esto también aplica a código escrito en C y Golang.

• Proxy de Golang y registro de checksums

  • Alguien comentó que intentó la idea de registrar de forma transparente checksums de URLs arbitrarias usando el proxy de Golang y sumdb.

• Exploración de dominios

  • Al explorar cierto dominio, contenía en su mayoría lo que se esperaba encontrar.

• Problema conocido

  • Se compartió un enlace sobre un problema conocido de Golang.

• Sistema de módulos de CUE

  • El sistema de módulos de CUE está en proceso de lanzamiento; aunque les gusta el MVS de Go, está construido sobre infraestructura OCI. Si te interesan los sistemas de gestión de dependencias, vale la pena revisar el enlace relacionado.

• Problema de caché web

  • El W3C hizo que todo en la web pudiera ser cacheable, pero surge la duda de por qué casi no existen cachés proxy de propósito general. Se preguntan si los publicadores envían respuestas innecesariamente cortas como Cache-Control: max-age o Vary: Cookie, o si demasiados ISP están pagando costos de tránsito.

• Problema de caché proxy

  • Puede ser un desperdicio que un proxy almacene en caché repositorios que no son de Go, pero si se hace que almacene repositorios de Go, entonces se pueden guardar datos arbitrarios. No parece un gran problema.