Scurgeri de secrete: Un pas spre disaster

A da cheile casei tale unor infractori nu este cu siguranță cea mai bună idee. Dar asta se întâmplă adesea în majoritatea organizațiilor care dezvoltă software modern.

În această primă postare despre scurgerile de secrete, vom analiza de ce se întâmplă acest lucru atât de des, care sunt consecințele și ce acțiuni trebuie întreprinse pentru a preveni sau atenua problema și a gestiona incidentele de scurgeri de secrete.

O, Doamne! Mi-am trimis cheile de acces la cloud către un depozit public.

Secrete codificate hard-coded din codul sursă sau din fișierele de configurare din instrumentele DevOps poate ajunge pe mâini proaste. Dacă secretul este commitDacă este stocat într-un depozit de surse publice, ești cu siguranță condamnat. Dar nici măcar depozitele private nu sunt sigure, deoarece secretele sunt, de asemenea, scurse prin fișiere binare ale aplicațiilor, jurnale sau cod sursă furat.

În retrospectivă, este tulburător cât de des o simplă omisiune a dus la o încălcare gravă a securității. Caută pe Google „Scurgeri de informații despre cheile AWS""Scurgeri de informații despre token-urile de acces GitHub„și așa mai departe. Nu luați aceste exemple ca pe niște recomandări ascunse pentru un furnizor sau altul. Folosiți-vă propriile exemple!

De exemplu, (in)faimosul Atac Codecov din aprilie 2021 a fost posibil deoarece imaginea Docker din Codecov conținea acreditări git care permiteau unui atacator să obțină acces la depozitele git private ale Codecov și să adauge o singură linie în scriptul de încărcare bash al Codecov pentru variabilele de mediu ale colecțiilor și adresele URL ale depozitului git.

Reamintim că o parte din recompensa atacurilor o reprezintă secretele pentru a obține acces la sisteme suplimentare, iar multe atacuri investesc masiv în acreditări, chei cripto și exfiltrarea de token-uri. 

Problema este că Secretele codificate sunt ceva obișnuitÎn martie 2022, Lapsus$ APT 189 GB scurși din codul sursă al Samsung și alte fișiere sensibile. Analiza a relevat că acesta conținea unele 6,600 de secrete codificate hard90% pentru sistemele interne, dar 10% pentru servicii și instrumente externe precum GitHub, AWS sau Google. Aceste secrete includeau chei API AWS / Twilio / Google, șiruri de conexiune la baza de date și alte informații sensibile. Aceasta este cea mai recentă tehnologie din majoritatea bazelor de cod.

Scurgerile de informații secrete sunt cea mai ușoară cale către atacurile în lanțul de aprovizionare

Dependențele de pachete sunt în prezent cele mai frecvente, deși nu singura țintă pentru atacurile din lanțul de aprovizionare. Infractorii ar putea crea un pachet nou care se instalează în software-ul victimelor (folosind tipografiere și alte tehnici), dar de obicei încearcă să infecteze un pachet existent fie prin adăugarea de modificări la codul sursă din depozitele de software (SCM) precum GitHub, GitLab sau BitBucket, sau prin adăugarea de versiuni malițioase în registre publice precum NPM, PyPI, RubyGems, Maven Central.

Însă injectarea de cod malițios sau a unei dependențe malițioase ascunse într-un graf complex de dependențe necesită login acreditări precum nume de utilizator/parolă, token-uri sau chei de acces (să le numim „chei„pe scurt), respectiv pentru depozitul sursă țintă sau registrul public. 

Uneori, răufăcătorii obțin cheile prin Inginerie sociala.  atac asupra event-stream pachetul NPM popular oferă un exemplu bun. Dar căutarea informațiilor scurse login Acreditările sau cheile de acces reprezintă cea mai frecventă tehnică de atac pentru atacurile în lanțul de aprovizionare software.

Depozitele sursă și registrele de pachete sunt două sisteme esențiale în construirea de software pipelineDar există multe instrumente în DevOps: CI/CD sisteme, instrumente pentru rularea testelor, automatizarea configurării și furnizării sau implementarea și lansarea. Toate acestea pot fi folosite în mod abuziv pentru injectarea de cod rău intenționat în software. Scurgerea de chei valide pentru aceste instrumente duce direct la suferință și agonie. Imaginați-vă scurgerea de chei de acces root cu control deplin asupra resurselor cloud-ului public...

Recomandările obișnuite

Nu spunem nimic nou aici, știți cu toții asta. Dar acționați! Nu uitați că boții scanează în mod regulat toate spațiile publice. SCM depozite. Câteva recomandări, fără o ordine anume.

• Dacă aveți responsabilități privind managementul securității IT, definește cum ar trebui gestionate secretele în politica de securitate. Însă politicile sunt la fel de bune ca și aplicarea lor: asigurați-vă că în organizația dumneavoastră se aplică un ghid de gestionare a secretelor - inclusiv nu doar echipele DevOps, ci și furnizorii de software - și că planul de răspuns la incidente al organizației conține prevederi pentru incidentele de scurgere a secretelor.
• Implementați și aplicați autentificare multi-factor (MFA, 2FA sau orice acronim). Și fără reduceri la capitolul securitate: o cheie de securitate USB merită câțiva dolari pe care îi costă. Trebuie să introduci oricare dintre miile tale de acreditări (ușor) și apoi să te îmbeți și să-ți lași cheile într-un bar cu ceva care îți trimite linkul (șansele sunt puțin mai mici, mai ales dacă ești abstinent).
• Folosește un manager de parole cu o parolă puternică, nesalvată. Pentru gestionarea secretelor în sisteme, folosește Seifuri secrete. CI/CD sisteme, furnizori de cloud, SCMInstrumentele s și alte instrumente DevOps oferă acest serviciu, dar puteți opta pentru o soluție generică Secret Vault.
• Prefera de scurtă durată jetoane în chei de acces cu durată lungă de viață. Sunt mai ușor de revocat și expun o fereastră mai limitată răului.
• Limitați reutilizarea acreditărilorAtacatorii vor reutiliza acreditările colectate pentru o țintă în alte sisteme, un alt aspect important al utilizării unui manager de parole. Managerii de parole și seifurile secrete ar trebui să facă din reutilizarea acreditărilor un lucru de domeniul trecutului.
• Limitați și monitorizați utilizarea admin parole. Sunt suficient de puternice pentru a merita o urmărire specială.
• aplica hashing și criptare puterniceRevenim la cheile USB (criptografice), proceduri stricte pentru transmiterea acreditărilor către parteneri și colegi și așa mai departe.
• Folosi scaner de secrete, de exemplu, rulați într-un pre-commit cârlig pentru a evita scurgerile în sistemele de control al versiunilor, ca o poartă de securitate. Înainte de lucru este important aici. Alternativ, utilizați scanări post-hoc pentru a detecta secrete scurse, de exemplu, ca o verificare înainte pull request fuzionări. Notă: Platforma noastră Xygeni include un scaner de secrete care permite ambele moduri de operare. 
• Alternativa manuală de utilizare recenzii de cod căutarea secretelor codificate are costuri mai mari și funcționează ulteriorcommit (dar, sperăm, cel puțin înainte ca secretul să fie disponibil și altor persoane). Însă recenziile pot detecta secrete neconvenționale care ar putea evita scanerele de secrete.       
• Evitați accidental commitintroducerea secretelor în fișierele comune pentru controlul versiunilor cu ajutorul metodelor adecvate exclude modele (cum ar fi șablonul `gitignore`), luând în considerare fișiere precum .env, .npmrc, .pypirc, fișiere temporare… Într-adevăr, un strat suplimentar în ceapa de securitate.
• Și ultimul dintr-o listă lungă: permiteți furnizorilor de cloud să efectueze scanări pentru scurgerile de informații din cheile lor, atunci când sunt disponibile. Cel puțin, asta Mai te anunță despre scurgerea de informații când s-a întâmplat, dar securitatea este o necesitate pentru furnizorii de cloud. Acest lucru post-hoc Scanarea secretă nu este foarte transparentă în ceea ce privește locul și frecvența efectuării scanării și necesită adesea o configurare explicită, dar cu siguranță este ultima resursă atunci când toate celelalte eșuează.

O, Doamne! Mi-am trimis cheile de acces la cloud către un depozit public, varianta a doua.

Asta i s-ar putea întâmpla și celor mai buni dintre noi. Suflecă-ți mânecile!

Reînnoiți/revocați/dezactivați imediat secretul divulgat! Dacă contul are o autentificare multifactor (MFA) decentă, atunci riscul este mult mai mic. Acest lucru ar putea fi mai dificil, de exemplu, cu cheile private de pe site-uri web (trebuie să emiteți un nou certificat pentru o cheie privată nouă și să îl revocați pe cel existent), dar instrumentele moderne au o modalitate rapidă de a reînnoi acreditările sau de a revoca token-urile. 

Urmați pașii recomandați de furnizor atunci când sunt disponibili, cum ar fi AWS în acest exemplu.

Identificați cauza scurgerii. Cunoașterea modului în care s-a produs este esențială pentru dezvăluirea, analiza, izolarea și activitățile din lecțiile învățate.

Apoi raportați scurgerea părților afectate, explicând acțiunile pe care le luați pentru a astupa scurgerea și a reduce daunele. Nu există nicio modalitate de a inversa daunele produse, ceea ce s-a scurs este scurgere. Fiți transparenți și informați-i pe ceilalți pentru ca aceștia să poată lua măsuri. 

Apoi începeți cu criminalistica.  fereastră de expunere este timpul dintre scurgerea de informații și momentul în care secretul nu a fost valid. Fiți pregătiți să citiți jurnalele și să urmăriți activitățile neobișnuite ale contului afectat în acea fereastră. Eliminați conturile și cheile generate folosind contul afectat. Rețineți că, dacă contul afectat are privilegii de administrator, remedierea este mult mai complexă. 

Rescrierea istoricului (controlului versiunilor) este complex. Chiar și statele totalitare încearcă acest lucru fără succes (joc de cuvinte intenționat). Și probabil irelevant: hackerii sau boții din depozitele publice ar fi putut clona depozitul sau ar fi extras deja aurul, în special dacă fereastra de expunere este suficient de mare. 

Dacă ești aventuros și vrei să vezi singur cât timp le ia roboților să detecteze un secret divulgat, fire de capcană precum Jetoane Canare vă permit să experimentați. Rețineți că boții pun pe lista neagră datele implicite canarytokens.org domeniu…

Pentru a citi mai multe Kovacs, E. „Mii de chei secrete descoperite în codul sursă Samsung, scurs de informații„Săptămâna Securității, martie 2022. Dyjak, A.“Acum câteva zile am realizat un mic experiment cu secretele WRT. committrimise în depozite git publice…„. Tweet thread, nov 2020.Rzepa, P. “Scurgere de chei de acces AWS în depozitul GitHub și câteva îmbunătățiri în Amazon Reaction„Medium, noiembrie 2020.”