Cómo los secretos que acechan en el código fuente conducen a importantes infracciones


Si una palabra pudiera resumir el año de la infoseguridad 2021 (bueno, en realidad tres), serían estas: “ataque a la cadena de suministro”.

Un ataque a la cadena de suministro de software ocurre cuando los piratas informáticos manipulan el código en los componentes de software de terceros para comprometer las aplicaciones ‘descendentes’ que los utilizan. En 2021, hemos visto un aumento dramático en este tipo de ataques: incidentes de seguridad de alto perfil como SolarWinds, Kaseya y códigocov las violaciones de datos han sacudido la confianza de las empresas en las prácticas de seguridad de los proveedores de servicios de terceros.

¿Qué tiene esto que ver con los secretos, podrías preguntar? En resumen, mucho. Tome el caso de Codecov (regresaremos a él rápidamente): es un ejemplo de libro de texto para ilustrar cómo los piratas informáticos aprovechan las credenciales codificadas para obtener acceso inicial a los sistemas de sus víctimas y recolectar más secretos en la cadena.

Los secretos en el código siguen siendo una de las vulnerabilidades más ignoradas en el espacio de seguridad de las aplicaciones, a pesar de ser un objetivo prioritario en los libros de jugadas de los piratas informáticos. En este artículo, hablaremos sobre los secretos y cómo mantenerlos fuera del código fuente es la prioridad número uno de hoy para asegurar el ciclo de vida del desarrollo de software.

¿Qué es un secreto?

Los secretos son credenciales de autenticación digital (claves API, certificados, tokens, etc.) que se utilizan en aplicaciones, servicios o infraestructuras. Al igual que se usa una contraseña (más un dispositivo en el caso de 2FA) para autenticar a una persona, un secreto autentica los sistemas para permitir la interoperabilidad. Pero hay una trampa: a diferencia de las contraseñas, los secretos están destinados a ser distribuidos.

Para ofrecer continuamente nuevas funciones, los equipos de ingeniería de software necesitan interconectar más y más componentes básicos. Las organizaciones están viendo cómo explota la cantidad de credenciales en uso en varios equipos (escuadrón de desarrollo, SRE, DevOps, seguridad, etc.). A veces, los desarrolladores mantendrán las claves en una ubicación insegura para que sea más fácil cambiar el código, pero al hacerlo, a menudo la información se olvida por error y se publica sin darse cuenta.

En el panorama de la seguridad de las aplicaciones, los secretos codificados son realmente un tipo diferente de vulnerabilidad. En primer lugar, dado que el código fuente es un activo con muchas fugas, destinado a ser clonado, verificado y bifurcado en múltiples máquinas con mucha frecuencia, los secretos también tienen fugas. Pero, lo que es más preocupante, no olvidemos que el código también tiene memoria.

Cualquier código base se administra con algún tipo de sistema de control de versiones (VCS), manteniendo una línea de tiempo histórica de todas las modificaciones que se le han hecho, a veces durante décadas. El problema es que los secretos aún válidos pueden estar escondidos en cualquier parte de esta línea de tiempo, abriendo una nueva dimensión a la superficie de ataque. Desafortunadamente, la mayoría de los análisis de seguridad solo se realizan en el estado actual, listo para ser implementado, de una base de código. En otras palabras, cuando se trata de credenciales que viven en una confirmación anterior o incluso en una rama que nunca se implementó, estas herramientas son totalmente ciegas.

Seis millones de secretos enviados a GitHub

El año pasado, al monitorear las confirmaciones enviadas a GitHub en tiempo real, GitGuardian detectó más de 6 millones de secretos filtradosduplicando el número de 2020. En promedio, 3 confirmaciones de 1,000 contenían una credencial, que es un cincuenta por ciento más que el año pasado.

Una gran parte de esos secretos estaba dando acceso a los recursos corporativos. No es de extrañar entonces que un atacante que busca afianzarse en un sistema empresarial primero mire sus repositorios públicos en GitHub y luego los que son propiedad de sus empleados. Muchos desarrolladores usan GitHub para proyectos personales y pueden filtrar por error las credenciales corporativas (¡sí, sucede regularmente!).

Con credenciales corporativas válidas, los atacantes operan como usuarios autorizados y la detección de abusos se vuelve difícil. El tiempo para que una credencial se vea comprometida después de enviarse a GitHub es de solo 4 segundos, lo que significa que se debe revocar y rotar de inmediato para neutralizar el riesgo de vulneración. Por culpa, o por falta de conocimiento técnico, podemos ver por qué la gente a menudo toma el camino equivocado para salir de esta situación.

Otro error grave para las empresas sería tolerar la presencia de secretos dentro de repositorios no públicos. El informe State of Secrets Sprawl de GitGuardian destaca el hecho de que los repositorios privados ocultan muchos más secretos que su equivalente público. La hipótesis aquí es que los repositorios privados dan a los propietarios una falsa sensación de seguridad, haciéndolos un poco menos preocupados por los posibles secretos que acechan en el código base.

Eso es ignorar el hecho de que estos secretos olvidados algún día podrían tener un impacto devastador si los piratas informáticos los recopilan.

Para ser justos, los equipos de seguridad de aplicaciones son muy conscientes del problema. Pero la cantidad de trabajo por hacer para investigar, revocar y rotar los secretos cometidos cada semana, o cavar a través de años de territorio desconocido, es simplemente abrumadora.

Incumplimiento de titulares… y el resto

Sin embargo, hay una urgencia. Los piratas informáticos buscan activamente “idiotas” en GitHub, que son patrones fácilmente reconocibles para identificar secretos filtrados. Y GitHub no es el único lugar donde pueden estar activos, cualquier registro (como Docker Hub) o cualquier fuga de código fuente puede convertirse potencialmente en una mina de oro para encontrar vectores de explotación.

Como evidencia, solo tiene que mirar las infracciones reveladas recientemente: un favorito de muchos proyectos de código abierto, Codecov es una herramienta de cobertura de código. El año pasado, se vio comprometida por atacantes que obtuvieron acceso al extraer una credencial de cuenta de nube estática de su imagen oficial de Docker. Después de haber accedido con éxito al repositorio oficial del código fuente, pudieron manipular un script de CI y recopilar cientos de secretos de la base de usuarios de Codecov.

Más recientemente, se filtró todo el código base de Twitch, exponiendo más de 6000 repositorios Git y 3 millones de documentos. A pesar de la gran cantidad de evidencia que demuestra un cierto nivel de madurez de AppSec, casi 7,000 secretos podrían salir a la luz! Estamos hablando de cientos de claves de AWS, Google, Stripe y GitHub. Solo unos pocos de ellos serían suficientes para implementar un ataque a gran escala en los sistemas más críticos de la empresa. Esta vez no se filtraron datos de clientes, pero eso es principalmente suerte.

Hace unos años, Uber no tuvo tanta suerte. Un empleado publicó accidentalmente un código corporativo en un repositorio público de GitHub, ese era el suyo. Los piratas informáticos descubrieron y detectaron las claves de un proveedor de servicios en la nube que otorgan acceso a la infraestructura de Uber. Se produjo una brecha masiva.

La conclusión es que realmente no puede estar seguro de cuándo se explotará un secreto, pero lo que debe tener en cuenta es que los actores maliciosos están monitoreando a sus desarrolladores y están buscando su código. También tenga en cuenta que estos incidentes son solo la punta del iceberg, y que probablemente muchas más violaciones que involucran secretos no se divulgan públicamente.

Conclusión

Los secretos son un componente central de cualquier paquete de software y son especialmente poderosos, por lo que requieren una protección muy sólida. Su naturaleza distribuida y las prácticas modernas de desarrollo de software hacen que sea muy difícil controlar dónde terminan, ya sea el código fuente, los registros de producción, las imágenes de Docker o las aplicaciones de mensajería instantánea. La capacidad de detección y remediación de secretos es imprescindible porque incluso los secretos pueden explotarse en un ataque que conduzca a una infracción importante. Estos escenarios ocurren todas las semanas y, a medida que se utilizan más y más servicios e infraestructura en el mundo empresarial, la cantidad de fugas crece a un ritmo muy rápido. Cuanto antes se tomen medidas, más fácil será proteger el código fuente de futuras amenazas.

Nota – Este artículo está escrito por Thomas Segura, escritor de contenido técnico en GitGuardian. Thomas ha trabajado como analista y consultor de ingeniería de software para varias grandes empresas francesas.



ttn-es-57