Si una palabra pudiera resumir el a\u00f1o de la infoseguridad 2021 (bueno, en realidad tres), ser\u00edan estas: “ataque a la cadena de suministro”. <\/p>\n
Un ataque a la cadena de suministro de software ocurre cuando los piratas inform\u00e1ticos manipulan el c\u00f3digo en los componentes de software de terceros para comprometer las aplicaciones ‘descendentes’ que los utilizan. En 2021, hemos visto un aumento dram\u00e1tico en este tipo de ataques: incidentes de seguridad de alto perfil como SolarWinds, Kaseya y c\u00f3digocov<\/a> las violaciones de datos han sacudido la confianza de las empresas en las pr\u00e1cticas de seguridad de los proveedores de servicios de terceros.<\/p>\n \u00bfQu\u00e9 tiene esto que ver con los secretos, podr\u00edas preguntar? En resumen, mucho. Tome el caso de Codecov (regresaremos a \u00e9l r\u00e1pidamente): es un ejemplo de libro de texto para ilustrar c\u00f3mo los piratas inform\u00e1ticos aprovechan las credenciales codificadas para obtener acceso inicial a los sistemas de sus v\u00edctimas y recolectar m\u00e1s secretos en la cadena. <\/p>\n Los secretos en el c\u00f3digo siguen siendo una de las vulnerabilidades m\u00e1s 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\u00e1ticos. En este art\u00edculo, hablaremos sobre los secretos y c\u00f3mo mantenerlos fuera del c\u00f3digo fuente es la prioridad n\u00famero uno de hoy para asegurar el ciclo de vida del desarrollo de software.<\/p>\n Los secretos son credenciales de autenticaci\u00f3n digital (claves API, certificados, tokens, etc.) que se utilizan en aplicaciones, servicios o infraestructuras. Al igual que se usa una contrase\u00f1a (m\u00e1s 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\u00f1as, los secretos est\u00e1n destinados a ser distribuidos. <\/p>\n Para ofrecer continuamente nuevas funciones, los equipos de ingenier\u00eda de software necesitan interconectar m\u00e1s y m\u00e1s componentes b\u00e1sicos. Las organizaciones est\u00e1n viendo c\u00f3mo explota la cantidad de credenciales en uso en varios equipos (escuadr\u00f3n de desarrollo, SRE, DevOps, seguridad, etc.). A veces, los desarrolladores mantendr\u00e1n las claves en una ubicaci\u00f3n insegura para que sea m\u00e1s f\u00e1cil cambiar el c\u00f3digo, pero al hacerlo, a menudo la informaci\u00f3n se olvida por error y se publica sin darse cuenta.<\/p>\n 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\u00f3digo fuente es un activo con muchas fugas, destinado a ser clonado, verificado y bifurcado en m\u00faltiples m\u00e1quinas con mucha frecuencia, los secretos tambi\u00e9n tienen fugas. Pero, lo que es m\u00e1s preocupante, no olvidemos que el c\u00f3digo tambi\u00e9n tiene memoria. <\/p>\n Cualquier c\u00f3digo base se administra con alg\u00fan tipo de sistema de control de versiones (VCS), manteniendo una l\u00ednea de tiempo hist\u00f3rica de todas las modificaciones que se le han hecho, a veces durante d\u00e9cadas. El problema es que los secretos a\u00fan v\u00e1lidos pueden estar escondidos en cualquier parte de esta l\u00ednea de tiempo, abriendo una nueva dimensi\u00f3n a la superficie de ataque. Desafortunadamente, la mayor\u00eda de los an\u00e1lisis de seguridad solo se realizan en el estado actual, listo para ser implementado, de una base de c\u00f3digo. En otras palabras, cuando se trata de credenciales que viven en una confirmaci\u00f3n anterior o incluso en una rama que nunca se implement\u00f3, estas herramientas son totalmente ciegas.<\/p>\n El a\u00f1o pasado, al monitorear las confirmaciones enviadas a GitHub en tiempo real, GitGuardian detect\u00f3 m\u00e1s de 6 millones de secretos filtrados<\/a>duplicando el n\u00famero de 2020. En promedio, 3 confirmaciones de 1,000 conten\u00edan una credencial, que es un cincuenta por ciento m\u00e1s que el a\u00f1o pasado. <\/p>\n Una gran parte de esos secretos estaba dando acceso a los recursos corporativos. No es de extra\u00f1ar entonces que un atacante que busca afianzarse en un sistema empresarial primero mire sus repositorios p\u00fablicos 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 (\u00a1s\u00ed, sucede regularmente!). <\/p>\n Con credenciales corporativas v\u00e1lidas, los atacantes operan como usuarios autorizados y la detecci\u00f3n de abusos se vuelve dif\u00edcil. El tiempo para que una credencial se vea comprometida despu\u00e9s 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\u00f3n. Por culpa, o por falta de conocimiento t\u00e9cnico, podemos ver por qu\u00e9 la gente a menudo toma el camino equivocado<\/a> para salir de esta situaci\u00f3n.<\/p>\n Otro error grave para las empresas ser\u00eda tolerar la presencia de secretos dentro de repositorios no p\u00fablicos. El informe State of Secrets Sprawl de GitGuardian destaca el hecho de que los repositorios privados ocultan muchos m\u00e1s secretos que su equivalente p\u00fablico. La hip\u00f3tesis aqu\u00ed es que los repositorios privados dan a los propietarios una falsa sensaci\u00f3n de seguridad, haci\u00e9ndolos un poco menos preocupados por los posibles secretos que acechan en el c\u00f3digo base.<\/p>\n Eso es ignorar el hecho de que estos secretos olvidados alg\u00fan d\u00eda podr\u00edan tener un impacto devastador si los piratas inform\u00e1ticos los recopilan. <\/p>\n 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\u00e9s de a\u00f1os de territorio desconocido, es simplemente abrumadora.<\/p>\n Sin embargo, hay una urgencia. Los piratas inform\u00e1ticos buscan activamente “idiotas” en GitHub, que son patrones f\u00e1cilmente reconocibles para identificar secretos filtrados. Y GitHub no es el \u00fanico lugar donde pueden estar activos, cualquier registro (como Docker Hub) o cualquier fuga de c\u00f3digo fuente puede convertirse potencialmente en una mina de oro para encontrar vectores de explotaci\u00f3n.<\/p>\n Como evidencia, solo tiene que mirar las infracciones reveladas recientemente: un favorito de muchos proyectos de c\u00f3digo abierto, Codecov es una herramienta de cobertura de c\u00f3digo. El a\u00f1o pasado, se vio comprometida por atacantes que obtuvieron acceso al extraer una credencial de cuenta de nube est\u00e1tica de su imagen oficial de Docker. Despu\u00e9s de haber accedido con \u00e9xito al repositorio oficial del c\u00f3digo fuente, pudieron manipular un script de CI y recopilar cientos de secretos de la base de usuarios de Codecov. <\/p>\n\u00bfQu\u00e9 es un secreto?<\/h2>\n
Seis millones de secretos enviados a GitHub<\/h2>\n
Incumplimiento de titulares… y el resto<\/h2>\n