Se filtran secretos: Un paso hacia la disaster

Dar las llaves de tu casa a delincuentes definitivamente no es la mejor idea. Pero eso es lo que suele ocurrir en la mayoría de las organizaciones que desarrollan software moderno.

En esta primera publicación sobre fugas de Secretos, analizaremos por qué esto sucede tan a menudo, cuáles son las consecuencias y qué acciones tomar para prevenir o mitigar el problema y manejar los incidentes de fugas de Secretos.

¡DIOS MÍO! Envié mis claves de acceso a la nube a un repositorio público

Secretos codificados en el código fuente o los archivos de configuración de las herramientas DevOps pueden acabar en malas manos. Si el secreto es... commitSi se almacena en un repositorio de fuentes públicas, está condenado al fracaso. Pero ni siquiera los repositorios privados son seguros, ya que los secretos también se filtran a través de binarios de aplicaciones, registros o código fuente robado.

En retrospectiva, es inquietante con qué frecuencia un simple descuido ha dado lugar a una grave violación de la seguridad. Solo busca en Google”Fugas de claves de AWS","Fugas de tokens de acceso a GitHub", etcétera. No tome estos ejemplos como recomendaciones ocultas para tal o cual proveedor. Usa los tuyos !

Por ejemplo, el (in)famoso Ataque de códec de abril de 2021 fue posible porque la imagen de Codecov Docker contenía credenciales de git que permitían a un atacante obtener acceso a los repositorios de git privados de Codecov y agregar una sola línea en el script de carga de bash de Codecov para las variables de entorno de recopilación y las URL del repositorio de git.

Recuerde que parte de la recompensa en los ataques son los secretos para obtener acceso a sistemas adicionales, y muchos ataques invierten fuertemente en credenciales, claves criptográficas y exfiltración de tokens. 

El problema es que Los secretos codificados son algo común. En marzo de 2022 el Lapsus$ APT filtrado 189GB del código fuente de Samsung y otros archivos confidenciales. El análisis reveló que contenía algunos 6,600 secretos codificados: 90% para sistemas internos, pero 10% para servicios y herramientas externas como GitHub, AWS o Google. Estos secretos incluían claves API de AWS/Twilio/Google, cadenas de conexión a bases de datos y otra información confidencial. Este es el estado del arte en la mayoría de las bases de código.

Las filtraciones de secretos son la vía más fácil para los ataques a la cadena de suministro

Las dependencias de paquetes son actualmente el objetivo más frecuente, aunque no el único, de los ataques a la cadena de suministro. Los malos podrían crear un nuevo paquete que termine instalado en el software de las víctimas (usando Typosquatting y otras técnicas), pero normalmente intentan infectar un paquete existente añadiendo modificaciones al código fuente en los repositorios de software (SCM) como GitHub, GitLab o BitBucket, o agregando versiones maliciosas a registros públicos como NPM, PyPI, RubyGems, Maven Central.

Pero inyectar código malicioso o una dependencia maliciosa oculta en un intrincado gráfico de dependencias requiere login credenciales como nombre de usuario/contraseña, tokens o claves de acceso (llamémoslas “claves”para abreviar), para el repositorio de origen de destino o el registro público, respectivamente. 

Los malos a veces obtienen las llaves a través de ingeniería social. La función de ataque a la event-stream El popular paquete NPM proporciona un buen ejemplo. Pero buscando información filtrada login Las credenciales o claves de acceso son la técnica de ataque más frecuente para los ataques a la cadena de suministro de software.

Los repositorios de código fuente y los registros de paquetes son dos sistemas esenciales en la construcción de software. pipelinePero hay muchas herramientas en DevOps: CI/CD Sistemas, herramientas para ejecutar pruebas, automatización de configuración y aprovisionamiento, o implementación y lanzamiento. Todos ellos pueden ser utilizados de forma abusiva para inyectar código malicioso en software. Filtrar claves válidas para estas herramientas conlleva directamente a problemas y sufrimiento. Imagine filtrar claves de acceso root con control total sobre sus recursos de nube pública...

Las recomendaciones habituales.

No decimos nada nuevo, ya lo saben. ¡Pero actúen! Recuerden que los bots escanean regularmente todos los sitios públicos. SCM Repositorios. Algunas recomendaciones, sin ningún orden en particular.

• Si tiene responsabilidad en la gestión de la seguridad de TI, definir cómo deben manejarse los secretos En la política de seguridad. Sin embargo, la eficacia de las políticas depende de su aplicación: asegúrese de que se aplique una directriz de gestión de Secretos en su organización, incluyendo no solo a sus equipos de DevOps, sino también a sus proveedores de software, y que el plan de respuesta a incidentes de su organización contenga disposiciones para incidentes de fuga de Secretos.
• Implementar y hacer cumplir autenticación de múltiples factores (MFA, 2FA o cualquier acrónimo). Y no hay recortes en seguridad: una llave de seguridad USB vale los pocos dólares que cuesta. Tienes que presionar cualquiera de tus miles de credenciales (fácil) y luego emborracharte y dejar tus llaves en un bar con algo vinculado a ti (las probabilidades son un poco menores, especialmente si eres abstemio).
• Utilice un administrador de contraseñas con una contraseña segura y sin guardar. Para gestionar secretos en los sistemas, utilice Bóvedas secretas. CI/CD sistemas, proveedores de nube, SCMs y otras herramientas DevOps brindan este servicio, pero usted puede optar por una solución genérica Secreto Vault.
• Utilice efímero tokens a claves de acceso de larga duración. Son más fáciles de revocar y exponen una ventana más limitada al mal.
• Limitar la reutilización de credencialesLos atacantes reutilizarán las credenciales obtenidas de un objetivo en otros sistemas, lo cual es otra ventaja para usar un administrador de contraseñas. Los administradores de contraseñas y las bóvedas de Secreto deberían eliminar la reutilización de credenciales.
• Limitar y controlar el uso de Admin contraseñas. Son lo suficientemente poderosos como para merecer un seguimiento especial.
• Implementar hash y cifrado fuertes. Volvamos a las claves USB (criptográficas), los procedimientos estrictos para transmitir credenciales con socios y compañeros de trabajo, etc.
• Usar un Escáner Secretos, por ejemplo ejecutar en un pre-commit Gancho. para evitar fugas en los sistemas de control de versiones, como puerta de seguridad. antes de la cosa es importante aquí. Alternativamente, utilice análisis post-hoc para detectar secretos filtrados, por ejemplo, como comprobación antes pull request Fusiones. Nota: Nuestra plataforma Xygeni incluye un escáner Secretos que permite ambos modos de operación. 
• La alternativa manual de usar revisiones de código Buscar secretos codificados tiene costos más altos y funciona despuéscommit (Pero ojalá, al menos antes de que el Secreto esté disponible para personas ajenas). Sin embargo, las revisiones podrían detectar Secretos no convencionales que podrían evadir los escáneres de Secretos.       
• evitar accidentalmente committing archivos comunes con Secretos para el control de versiones con el apropiado excluir patrones (como la plantilla `gitignore`), teniendo en cuenta archivos como .env, .npmrc, .pypirc, archivos temporales… De hecho, una capa adicional en la cebolla de seguridad.
• Y el último de esta larga lista: dejar que los proveedores de la nube realicen análisis en busca de fugas de claves, cuando estén disponibles. Al menos, esto pueden informarle sobre la filtración cuando ocurrió, pero la seguridad es una necesidad para los proveedores de la nube. Este post-hoc El escaneo secreto no es muy transparente en cuanto a dónde y con qué frecuencia se realiza, y a menudo necesita una configuración explícita, pero ciertamente es el último recurso cuando todo lo demás falla.

¡DIOS MÍO! Envié mis claves de acceso a la nube a un repositorio público, toma n.º 2

Eso podría pasarnos a todos. Arremangarse !

¡Renueve/revoque/desactive inmediatamente el Secreto filtrado! Si la cuenta tiene una MFA adecuada, el riesgo es mucho menor. Esto podría ser más difícil con, por ejemplo, las claves privadas en sitios web (es necesario emitir un nuevo certificado para una nueva clave privada y revocar el existente), pero las herramientas modernas ofrecen una forma rápida de renovar credenciales o revocar tokens. 

Siga los pasos recomendados por el proveedor cuando estén disponibles, como AWS en este ejemplo.

Identifique la causa de la fuga. Saber cómo sucedió es esencial para las actividades de divulgación, análisis, contención y lecciones aprendidas.

Luego informe la fuga a las partes afectadas, explicando las acciones que está tomando para tapar la fuga y reducir el daño. No hay manera de revertir el daño hecho, lo que se filtró, se filtró. Sea transparente e informe a los demás para que puedan tomar medidas. 

Luego comience con el forense. La función de ventana de exposición Es el tiempo transcurrido entre la fuga y el momento en que el secreto dejó de ser válido. Esté preparado para leer los registros y rastrear cualquier actividad inusual en la cuenta afectada durante ese periodo. Elimine las cuentas y las claves generadas con la cuenta afectada. Recuerde que si la cuenta afectada tiene privilegios de administrador, la solución es mucho más compleja. 

Historial de reescritura (control de versiones) es complejo. Incluso los estados totalitarios intentan esto sin éxito (juego de palabras). Y probablemente irrelevante: los piratas informáticos o los robots en los repositorios públicos podrían haber clonado el repositorio o ya haber extraído el oro, en particular si la ventana de exposición es lo suficientemente grande. 

Si eres aventurero y quieres ver por ti mismo cuánto tiempo tardan los bots en detectar un Secreto filtrado, existen trampas como Fichas Canarias Deja que experimentes. Recuerde, los bots incluyen en la lista negra el valor predeterminado canarytokens.org dominio…