Mozilla está tratando de proteger sus repositorios en GitHub de cambios maliciosos. Como mostró el reciente incidente de Gentoo , tales ataques son reales.


Mozilla originalmente usó GitHub como alojamiento de respaldo. Al igual que Gentoo, los repositorios originales se almacenaron en su propia infraestructura. Aunque la mayor parte del código de Firefox todavía se distribuye con su propia infraestructura, existen muchos proyectos solo en GitHub. Algunos son solo experimentos, mientras que otros se usan en producción (por ejemplo, cuentas de Firefox ). Dichos repositorios "sensibles" deben protegerse de ediciones maliciosas, sin complicar los compromisos para las personas normales.

Aquí se describen pasos reales contra la distribución (o implementación) de código desde un repositorio comprometido. Compartimos experiencia y algunas herramientas de auditoría. Dicha protección casi no interfiere con los flujos de trabajo normales en GitHub.

Aquí consideramos el riesgo de piratear una cuenta de GitHub a través de los mecanismos únicos de este sitio. Como el caso de Gentoo y otros incidentes han demostrado, en caso de un hack, todo el código al que el usuario tiene acceso está comprometido.

La esencia del problema

GitHub es un gran ecosistema con muchas extensiones o "aplicaciones" para simplificar flujos de trabajo específicos. Las aplicaciones reciben permiso del usuario para realizar acciones en su nombre. Pueden solicitar permisos, incluso cambiar o agregar cuentas adicionales. GitHub muestra claramente estas solicitudes: el usuario debe aprobarlas a través de la interfaz web, pero no todos están familiarizados con las consecuencias. Muchos no entienden que el permiso para acceder a un repositorio personal da el mismo acceso a cualquier repositorio en GitHub en nombre del usuario.

Los permisos excesivos ponen en peligro los repositorios con información confidencial, mientras que el administrador del repositorio no ve nada. Lo mejor que puede hacer es notar una confirmación maliciosa después del hecho. Ni GitHub ni Git se pueden configurar para prevenir o marcar este tipo de confirmación maliciosa. Solo monitoreo externo.

Implementación

Las siguientes recomendaciones se han tomado de nuestro sistema de seguridad , solo para este artículo se han eliminado las características específicas de Mozilla. En la medida de lo posible, tomamos prestadas las mejores prácticas de Internet, usamos las funciones de GitHub e intentamos no complicar demasiado la vida de los desarrolladores.

Recomendaciones para organizaciones

• Obligatorio 2FA para todos los empleados.
• Para todos o al menos usuarios con permisos más altos:
  
  • Proporcione contacto (correo electrónico, mensajería instantánea) a la organización o al administrador (GitHub le permite ocultar información de contacto para mayor privacidad).
  • Asegúrese de informar a la organización o al administrador sobre el posible compromiso de su cuenta (por ejemplo, sobre el robo de una computadora portátil).

Pautas para repositorios

• Los repositorios importantes solo deben alojarse en una organización que siga las recomendaciones anteriores.
• Definir y configurar ramas de producción:
  
  • Prohibición de empujar forzado.
  • Permiso para comprometerse solo con un pequeño número de usuarios.
  • Aplique estas restricciones también a administradores y propietarios.
  • Firme todas las confirmaciones con claves GPG previamente conocidas.

Recomendaciones de flujo de trabajo

• Las implementaciones, lanzamientos y otros eventos dignos de una auditoría deben anotarse con una etiqueta firmada con una clave GPG previamente conocida.
• Todas las implementaciones y versiones deben emitirse solo después de una auditoría de todas las confirmaciones y etiquetas firmadas para las claves correctas.

La implementación de estas medidas de protección implica ciertos costos, especialmente en relación con la firma de compromisos. Hemos desarrollado herramientas para auditar configuraciones y planeamos lanzar herramientas para auditar confirmaciones. Todos ellos están en nuestro repositorio .



Aquí hay un ejemplo de auditoría. Primero, obtenemos una copia local de los datos para la organización octo_org , y luego se compila un informe para cada repositorio:

 $ ./get_branch_protections.py octo_org 2018-07-06 13:52:40,584 INFO: Running as ms_octo_cat 2018-07-06 13:52:40,854 INFO: Gathering branch protection data. (calls remaining 4992). 2018-07-06 13:52:41,117 INFO: Starting on org octo_org. (calls remaining 4992). 2018-07-06 13:52:59,116 INFO: Finished gathering branch protection data (calls remaining 4947). 

Ahora con datos almacenados en caché local puede generar cualquier informe. Por ejemplo, un informe muestra el cumplimiento de las recomendaciones anteriores:

 $ ./report_branch_status.py --header octo_org.db.json name,protected,restricted,enforcement,signed,team_used octo_org/react-starter,True,False,False,False,False octo_org/node-starter,False,False,False,False,False 

Como puede ver, solo octo_org/react-starter incluía protección contra el empuje forzado en la rama de producción. El resultado está en formato CSV para insertarlo fácilmente en una hoja de cálculo.

Como puedes ayudar

Todavía estamos implementando estas recomendaciones y aprendiendo en el camino. Si cree que nuestras recomendaciones de seguridad de repositorio son adecuadas para usted, ayude a simplificar la implementación. Comparta su experiencia en la página de consejos o abra un ticket en el repositorio de GitHub-Audit .