Secretos en el Código Fuente - Cómo tu Código JS Expone tus Credenciales

Un buen lugar para comenzar es entender qué son los secretos. Cuando hablo de secretos, me refiero a credenciales de autenticación digital. Estos suelen ser cosas como tus claves de API, tus pares de credenciales, como tus credenciales de base de datos, certificados de seguridad, cualquier cosa que otorgue acceso a servicios o permita la ingestión o escritura de datos. Realmente, estos son los tesoros más preciados de cualquier organización, porque un atacante irá tras ellos de inmediato cuando obtenga acceso a cualquier cosa, lo que le permita persistir su acceso o moverse lateralmente hacia diferentes sistemas, elevar sus privilegios y hacer todo eso sin ser detectado porque están debidamente autenticados en los servicios.

Para entender cómo usamos los secretos, demos un paso atrás y veamos cómo construimos una aplicación. Ya no construimos monolitos. Nuestras aplicaciones son más o menos una colección de diferentes servicios. Por ejemplo, podemos usar Okta para autenticar a los usuarios en nuestros sistemas. Tal vez estemos usando Stripe para procesar tarjetas de crédito. MongoDB es una base de datos administrada. Así que muy rápidamente, nuestras aplicaciones pueden convertirse en una colección de todos estos diferentes sistemas.

Una de las cosas que hacemos en GitGuardian es escanear código en diferentes lugares para tratar de identificar dónde se encuentran estos secretos. Y lo publicamos en un informe cada año llamado Estado de los Secretos para Todos. Uno de los lugares que escaneamos es github.com. Probablemente estés familiarizado con él. Muchos desarrolladores lo están. De hecho, en 2022, según GitHub, 94 millones de desarrolladores estaban usando GitHub. Y ya hemos superado los 100 millones de desarrolladores. Y el año pasado, solo el año pasado, se realizaron más de mil millones de confirmaciones en repositorios de código público. Solo repositorios de código público. Así que eso es una enorme cantidad dedata. Se crearon 84 millones de nuevos repositorios. Nuevamente, solo públicos. Así que esto es una verdadera avalancha de información. Puedes encontrar cualquier cosa y todo en GitHub en repositorios públicos, incluidos secretos. Así que hay mil millones de confirmaciones.

GitGuardian escaneó cada uno de ellos el año pasado. Los escaneamos en busca de secretos. De hecho, buscamos casi 400 tipos diferentes de secretos. ¿Y qué encontramos? Encontramos más de 10 millones de secretos detectados en repositorios públicos en GitHub. 10 millones. Esto representa un gran aumento con respecto a años anteriores. El primer año en que publicamos este informe fue en 2020, cuando encontramos 3 millones, y ahora puedes ver la progresión hasta los 10 millones.

En parte, esto se explica por la presencia de más desarrolladores en GitHub, pero también se debe a que cada año utilizamos más y más secretos. Ahora tenemos cosas como Infrastructure as Code, que es el segmento de más rápido crecimiento en GitHub. Ahora gestionamos nuestra infraestructura de forma programática, por lo que necesitamos utilizar secretos para hacerlo. Más secretos significa más secretos filtrados en GitHub. Hay una gran cantidad de información que podemos encontrar en GitHub. Buscamos secretos específicos y los validamos cuando los encontramos. Algunas de las cosas más interesantes que encontramos son, por ejemplo, que el 20% de los secretos que encontramos eran para proveedores de servicios en la nube, como Google Cloud Services o AWS. Y nuevamente, estas son credenciales válidas. Encontramos 2 millones de claves de proveedores de servicios en la nube válidas en lugares públicos de GitHub. Incluso encontramos diferentes cosas como sistemas de mensajería, claves de bases de datos e incluso claves para tu plataforma de control de versiones. Esto significa acceso a tus repositorios privados que has puesto en un repositorio público.

En cuanto a los lenguajes de programación, Python fue el lenguaje más común para los secretos filtrados, pero JavaScript es el segundo lenguaje cuando excluimos los archivos JSON y ENV, que son archivos independientes del lenguaje. Aquí nos estamos enfocando en las extensiones de archivos JavaScript. No es sorprendente que app.js o index.js sean las aplicaciones más comunes. Estos son archivos principales donde los desarrolladores han codificado sus credenciales en el código fuente. Esta es una práctica muy mala, pero no es una sorpresa en general. Sin embargo, podemos encontrar cosas interesantes a medida que revisamos estos datos. Por ejemplo, tenemos archivos de configuración para servicios específicos. Docosaurus es una especie de marco preconfigurado para construir sitios web. Viene con un archivo de configuración. Simplemente puedes reemplazar el texto de ejemplo y poner tus propias claves aquí, y hacer commit de esto en GitHub. Y ahora has expuesto tus claves. ¿Es esto realmente un riesgo de seguridad? ¿Los hackers realmente monitorean GitHub en busca de estas credenciales? La respuesta es sí.

Muy frecuentemente. Un ejemplo que tuvimos el año pasado fue con Toyota, donde un contratista que trabajaba para Toyota filtró accidentalmente claves públicas, hizo accidentalmente un repositorio privado público, lo que filtró claves a una base de datos que la aplicación móvil de Toyota estaba utilizando, una aplicación móvil llamada T-Connect. Estas son claves que dieron acceso a toda la información de los usuarios que estaban utilizando T-Connect y que estaban expuestas en un repositorio público. Este es solo un ejemplo, pero hay muchos, muchos más ejemplos donde claves reales pertenecientes a organizaciones y con consecuencias reales se han filtrado en lugares públicos.

Pero no solo debes preocuparte por los repositorios públicos. También debes preocuparte por tus repositorios privados. El código fuente que es privado siempre encuentra su camino hacia lugares públicos de forma accidental, o como yo lo llamo, de forma involuntariamente de código abierto. El Grupo Lapsus, por ejemplo, el año pasado publicó públicamente el código fuente de NVIDIA, Samsung, Microsoft y muchos, muchos más. Puedes preguntarte, ¿cómo obtuvieron acceso al código fuente privado? Bueno, hay muchas formas diferentes. El código fuente es un activo muy permeable, lo que significa que se encuentra en todas partes. Está en las máquinas de tus desarrolladores, se hace una copia de seguridad, está en wikis, se comparte a través de sistemas de mensajería y, por supuesto, está en tus repositorios Git. Además, muchas personas tienen acceso a tus repositorios Git. Y sé a ciencia cierta que Lapsus simplemente estaba pagando a empleados para que les otorgaran acceso al código fuente privado público. Por lo tanto, no es tan difícil para un actor de amenazas motivado acceder a tu código fuente privado. Entonces, si crees que estás seguro porque no tienes repositorios de código abierto, no lo estás. Los secretos definitivamente no deben estar en tu código, independientemente de dónde se encuentren.

Entonces, ¿por qué se exponen los secretos? Hay muchas formas diferentes. Tal vez estás cometiendo cosas y estás probando claves, por lo que las has codificado en el código sin darte cuenta de que esas claves estarán en tu historial para siempre. Incluso si haces algo en una rama de desarrollo, codificas credenciales, las eliminas rápidamente más tarde porque solo las estás probando, esas credenciales seguirán estando en tu historial de Git y estarán allí para siempre. Pueden imprimirse en archivos generados automáticamente como registros de depuración. Puedes incluir archivos sensibles en tus repositorios Git, como archivos .env o archivos .pem. Nunca deben estar en tu repositorio, así que asegúrate de usar un archivo .gitignore y también puedes enviar código accidentalmente al lugar equivocado. Entonces, ¿cómo evitas que esto suceda? Bueno, nunca debes codificar los secretos, nunca debes escribir directamente el secreto en tu aplicación. Esa es la regla número uno, no importa si es privado, público o en qué tipo de rama estás trabajando o durante cuánto tiempo esté allí. Estará allí para siempre en Git. También podemos usar herramientas para evitar que se filtren. Por lo tanto, podemos utilizar herramientas que nos permitan hacer esto. Queremos almacenar las claves en el backend. Si estás construyendo una aplicación React y la estás haciendo lucir bonita, queremos asegurarnos de que accedas a tus credenciales a través del backend y que este te pase los datos que necesitas y no los manejes directamente. No hay muchos escenarios en los que realmente necesites manejar esas claves en el frontend.

Si estás manejando claves, asegúrate de almacenarlas en un lugar centralizado. Por ejemplo, un archivo .env. Solo asegúrate de que este archivo .env se agregue a tu archivo .gitignore para que nunca se incluya en tu repositorio Git. Puedes utilizar excelentes herramientas como .env para JavaScript, que cargarán tus secretos y memoria local desde tu archivo .env en variables de entorno, lo que significa que tu aplicación no los y no será necesario que estén en tus repositorios Git.

Si quieres ir un paso más allá, definitivamente debemos utilizar bóvedas y gestores de secretos. Necesitamos rotar nuestras claves regularmente para que, incluso si una clave se filtra, estés en un programa de rotación para que no sea válida por mucho tiempo, y necesitamos restringir el acceso de la clave. Deberíamos limitarlo solo a los servicios que esperamos, para que si un actor de amenazas lo obtiene, no pueda hacer nada con la clave.

Para cosas sensibles, debemos firmar esas claves con un hash de la aplicación que las está utilizando para asegurarnos de que todo lo que se está utilizando sea solo para fines legítimos. Así que muchas gracias. Hay un par de códigos QR en la pantalla. Uno te llevará al informe del estado de los secretos para 2023, y el otro examinará un modelo de madurez de gestión de secretos de cómo puedes manejar correctamente tus secretos de diversas formas diferentes. Gracias por escuchar. Soy McKenzie, y nos vemos la próxima vez.