Filtracions de secrets: Un pas cap a la disaster

Donar les claus de casa teva a delinqüents definitivament no és la millor idea. Però això és el que passa sovint a la majoria d'organitzacions que desenvolupen programari modern.

En aquesta primera publicació sobre les filtracions de secrets, analitzarem per què això passa tan sovint, quines són les conseqüències i quines accions cal prendre per prevenir o mitigar el problema i gestionar els incidents de filtracions de secrets.

Déu meu! He enviat les meves claus d'accés al núvol a un repositori públic.

Secrets codificats de manera rígida al codi font o als fitxers de configuració de les eines DevOps pot acabar en males mans. Si el secret és commitSi esteu en un repositori de fonts públiques, esteu condemnats. Però fins i tot els repositoris privats no són segurs, ja que els secrets també es filtren a través de binaris d'aplicacions, registres o codi font robat.

En retrospectiva, és inquietant amb quina freqüència un simple descuit ha provocat una greu violació de la seguretat. Només cal que busqueu a Google "Filtracions de claus d'AWS","Filtracions de tokens d'accés de GitHub", etc. No prengueu aquests exemples com a recomanacions ocultes per a aquest o aquell proveïdor. Feu servir els vostres propis!"

Per exemple, el (in)famós Atac de Codecov de l'abril de 2021 va ser possible perquè la imatge de Docker de Codecov contenia credencials de git que permetien a un atacant obtenir accés als repositoris git privats de Codecov i afegir una sola línia a l'script de càrrega bash de Codecov per a les variables d'entorn de la col·lecció i les URL del repositori git.

Recordeu que part de la recompensa dels atacs són els secrets per obtenir accés a sistemes addicionals, i molts atacs inverteixen molt en credencials, claus criptogràfiques i exfiltració de tokens. 

El problema és que Els secrets codificats són habitualsEl març de 2022, el Lapsus$ APT 189 GB filtrats del codi font de Samsung i altres fitxers sensibles. L'anàlisi va revelar que contenia alguns 6,600 secrets codificats90% per a sistemes interns, però 10% per a serveis i eines externes com GitHub, AWS o Google. Aquests secrets incloïen claus API d'AWS/Twilio/Google, cadenes de connexió de bases de dades i altra informació sensible. Aquest és l'estat de la tècnica a la majoria de bases de codi.

Les filtracions de secrets són el camí més fàcil cap als atacs a la cadena de subministrament

Les dependències de paquets són actualment l'objectiu més freqüent, tot i que no és l'únic, dels atacs a la cadena de subministrament. Els delinqüents podrien crear un nou paquet que acabi instal·lat al programari de les víctimes (utilitzant mecanografia tipogràfica i altres tècniques), però normalment intenten infectar un paquet existent afegint modificacions al codi font dels repositoris de programari (SCM) com ara GitHub, GitLab o BitBucket, o afegint versions malicioses a registres públics com ara NPM, PyPI, RubyGems, Maven Central.

Però injectar codi maliciós o una dependència maliciosa amagada en un gràfic de dependències complex requereix login credencials com ara nom d'usuari/contrasenya, tokens o claus d'accés (anomenem-les "claus" per abreujar), per al repositori d'origen o el registre públic de destinació, respectivament. 

Els dolents de vegades obtenen les claus a través de Enginyeria social. La atac a l' event-stream el popular paquet NPM n'ofereix un bon exemple. Però la cerca de filtracions login Les credencials o les claus d'accés són la tècnica d'atac més freqüent per als atacs a la cadena de subministrament de programari.

Els repositoris de codi font i els registres de paquets són dos sistemes essencials en la compilació de programari. pipelinePerò hi ha moltes eines a DevOps: CI/CD sistemes, eines per executar proves, automatització de configuració i aprovisionament, o desplegament i llançament. Tots ells es poden utilitzar de manera abusiva per injectar codi maliciós al programari. La filtració de claus vàlides per a aquestes eines condueix directament a la misèria i l'agonia. Imagineu-vos filtrar claus d'accés root amb control total sobre els vostres recursos del núvol públic...

Les recomanacions habituals

No diem res de nou aquí, tots ho sabeu. Però actueu! Recordeu que els bots escanegen regularment tot el públic. SCM repositoris. Algunes recomanacions, sense cap ordre en particular.

• Si tens responsabilitats en la gestió de la seguretat informàtica, definir com s'han de gestionar els secrets en la política de seguretat. Però les polítiques només són tan bones com la seva aplicació: assegureu-vos que s'apliqui una guia de gestió de secrets a la vostra organització, incloent-hi no només els vostres equips de DevOps sinó també els vostres proveïdors de programari, i que el pla de resposta a incidents de la vostra organització contingui disposicions per a incidents de filtració de secrets.
• Implementar i fer complir autenticació multifactor (MFA, 2FA o qualsevol acrònim). I sense retallades en seguretat: una clau de seguretat USB val els pocs euros que costa. Has de fer git-push de qualsevol de les teves milers de credencials (fàcil) i després emborratxar-te i deixar les claus en un bar amb alguna cosa que enllaça amb tu (les probabilitats són una mica menors, sobretot si ets abstemi).
• Feu servir un gestor de contrasenyes amb una contrasenya forta i no desada. Per gestionar els secrets en sistemes, feu servir Voltes secretes. CI/CD sistemes, proveïdors de núvol, SCMs i altres eines DevOps ofereixen aquest servei, però podeu optar per una solució genèrica de Secret Vault.
• Preferir vida curta fitxes a claus d'accés de llarga durada. Són més fàcils de revocar i exposen una finestra més limitada al mal.
• Limitar la reutilització de credencials: els atacants reutilitzaran les credencials recollides per a un objectiu en altres sistemes, un altre punt per utilitzar un gestor de contrasenyes. Els gestors de contrasenyes i les voltes secretes haurien de fer que la reutilització de credencials sigui cosa del passat.
• Limitar i controlar l'ús de admin contrasenyes. Són prou potents com per merèixer un seguiment especial.
• Implementar hash i xifratge fortsTornada a les claus USB (criptogràfiques), procediments estrictes per a la transmissió de credencials amb socis i companys de feina, etc.
• Utilitzar escàner de secrets, per exemple, executar en un pre-commit ganxo per evitar fuites en sistemes de control de versions, com a porta de seguretat. Abans de la cosa és important aquí. Alternativament, utilitzeu escanejos post-hoc per detectar secrets filtrats, per exemple, com a comprovació abans pull request fusions. Nota: La nostra plataforma Xygeni inclou un escàner de secrets que permet ambdós modes d'operació. 
• L'alternativa manual d'utilitzar ressenyes de codi buscar secrets codificats té costos més elevats i funciona posteriormentcommit (però amb sort, almenys abans que el secret estigui disponible per a persones externes). Però les revisions poden detectar secrets no convencionals que podrien evadir els lectors de secrets.       
• Evitar accidentalment commitafegint secrets als fitxers comuns al control de versions amb la informació adequada excloure patrons (com la plantilla `gitignore`), tenint en compte fitxers com ara .env, .npmrc, .pypirc, fitxers temporals... Una capa addicional a la ceba de seguretat, sens dubte.
• I l'últim d'aquesta llarga llista: permetre que els proveïdors de núvol realitzin escanejos per detectar fuites de les seves claus, quan estiguin disponibles. Almenys, això pot t'avisarà de la filtració quan va passar, però la seguretat és imprescindible per als proveïdors de núvol. Això post hoc L'escaneig secret no és gaire transparent pel que fa a on i amb quina freqüència es realitza, i sovint necessita una configuració explícita, però sens dubte és l'últim recurs quan tot falla.

Déu meu! He enviat les meves claus d'accés al núvol a un repositori públic, prova número 2.

Això li podria passar a qualsevol de nosaltres. Arremanga't!

Renova / revoca / desactiva immediatament el secret filtrat! Si el compte té una MFA decent, el risc és molt menor. Això podria ser més difícil amb, per exemple, claus privades en llocs web (cal emetre un nou certificat per a una nova clau privada i revocar l'existent), però les eines modernes tenen una manera ràpida de renovar credencials o revocar tokens. 

Seguiu els passos recomanats pel proveïdor quan estiguin disponibles, com ara AWS en aquest exemple.

Identificar la causa de la fuita. Saber com va passar és essencial per a la divulgació, l'anàlisi, la contenció i les activitats basades en les lliçons apreses.

A continuació, informeu de la fuita a les parts afectades, explicant les accions que esteu prenent per tapar la fuita i reduir els danys. No hi ha manera de revertir el dany causat, el que es va filtrar ja s'ha filtrat. Sigueu transparents i informeu els altres perquè puguin prendre mesures. 

Aleshores comença amb el forense. La finestra d'exposició és el temps entre la filtració i el moment en què el secret no era vàlid. Estigueu preparats per llegir els registres i fer un seguiment de l'activitat inusual amb el compte afectat durant aquesta finestra. Elimineu els comptes i les claus generades amb el compte afectat. Recordeu que si el compte afectat té privilegis d'administrador, la solució és molt més complexa. 

Reescriptura de l'historial (control de versions) és complex. Fins i tot els estats totalitaris ho intenten sense èxit (joc de paraules intencionat). I probablement irrellevant: els pirates informàtics o els bots dels repositoris públics podrien haver clonat el repositori o ja haver extret l'or, en particular si la finestra d'exposició és prou gran. 

Si ets aventurer i vols veure pel teu compte quant triguen els bots a detectar un secret filtrat, cables trampa com... Fitxes canàries et permeten experimentar. Recorda, els bots inclouen a la llista negra els valors predeterminats canarytokens.org domini…