Wyciek sekretów: Jeden krok do rozwiązaniasaster

Oddawanie kluczy do domu przestępcom zdecydowanie nie jest najlepszym pomysłem. Ale właśnie tak często dzieje się w większości organizacji tworzących nowoczesne oprogramowanie.

W tym pierwszym poście poświęconym wyciekom tajemnic przeanalizujemy, dlaczego zdarzają się one tak często, jakie są konsekwencje i jakie działania należy podjąć, aby zapobiec problemowi lub go złagodzić, a także jak sobie radzić z incydentami wycieku tajemnic.

O mój Boże! Przesłałem moje klucze dostępu do chmury do publicznego repozytorium

Zakodowane na stałe sekrety w kodzie źródłowym lub plikach konfiguracyjnych w narzędziach DevOps może trafić w niepowołane ręce. Jeśli sekret jest commitJeśli korzystasz z publicznego repozytorium źródeł, jesteś skazany na porażkę. Ale nawet prywatne repozytoria nie są bezpieczne, ponieważ poufne informacje wyciekają również poprzez pliki binarne aplikacji, logi lub skradziony kod źródłowy.

Z perspektywy czasu jest to niepokojące jak często proste niedopatrzenie prowadzi do poważnego naruszenia bezpieczeństwa. Wystarczy wpisać w Google „Wycieki kluczy AWS","Wycieki tokenów dostępowych GitHub„itp. Nie traktuj tych przykładów jako ukrytych rekomendacji dla tego czy innego sprzedawcy. Użyj własnych!

Na przykład (nie)sławny Atak Codecov kwietnia 2021 r. było możliwe, ponieważ obraz Docker Codecov zawierał dane uwierzytelniające git, które umożliwiały atakującemu uzyskanie dostępu do prywatnych repozytoriów git Codecov i dodanie pojedynczego wiersza do skryptu bash uploadera Codecov dla zmiennych środowiskowych kolekcji i adresów URL repozytoriów git.

Należy pamiętać, że część zysków z ataków stanowią sekrety umożliwiające dostęp do dodatkowych systemów, a wiele ataków opiera się na dużych nakładach na wykradanie danych uwierzytelniających, kluczy kryptograficznych i tokenów. 

Problemem jest to, że zakodowane na stałe sekrety są powszechneW marcu 2022 r. Lapsus$ APT wyciekło 189 GB kodu źródłowego Samsunga i innych poufnych plików. Analiza wykazała, że ​​zawierał on pewne 6,600 zakodowanych na stałe sekretów:90% dla systemów wewnętrznych, ale 10% dla usług i narzędzi zewnętrznych, takich jak GitHub, AWS czy Google. Tajemnice te obejmowały klucze API AWS/Twilio/Google, ciągi połączeń z bazą danych i inne poufne informacje. To najnowocześniejszy standard w większości baz kodu.

Wyciek tajemnic to najłatwiejsza droga do ataków na łańcuch dostaw

Zależności pakietów są obecnie najczęstszym, choć nie jedynym, celem ataków na łańcuchy dostaw. Cyberprzestępcy mogą stworzyć nowy pakiet, który zostanie zainstalowany w oprogramowaniu ofiary (używając typosquatting i innymi technikami), ale zazwyczaj próbują zainfekować istniejący pakiet, dodając modyfikacje do kodu źródłowego w repozytoriach oprogramowania (SCM) takich jak GitHub, GitLab czy BitBucket, lub dodając złośliwe wersje do publicznych rejestrów, takich jak NPM, PyPI, RubyGems, Maven Central.

Ale wstrzykiwanie złośliwego kodu lub złośliwej zależności ukrytej w złożonym grafie zależności wymaga login dane uwierzytelniające, takie jak nazwa użytkownika/hasło, tokeny lub klucze dostępu (nazwijmy je „Klawisze” w skrócie), odpowiednio dla docelowego repozytorium źródłowego lub rejestru publicznego. 

Złośliwcy czasami zdobywają klucze poprzez inżynieria społeczna,  atak na event-stream Popularny pakiet NPM stanowi dobry przykład. Ale wyszukiwanie wycieków login poświadczenia lub klucze dostępu to najczęstsza technika ataku stosowana w przypadku ataków na łańcuch dostaw oprogramowania.

Repozytoria źródeł i rejestry pakietów to dwa podstawowe systemy w procesie tworzenia oprogramowania pipeline. Ale w DevOps jest wiele narzędzi: CI/CD Systemy, narzędzia do przeprowadzania testów, automatyzacja konfiguracji i provisioningu, czy wdrażanie i wydawanie. Wszystkie te narzędzia mogą zostać wykorzystane do wstrzyknięcia złośliwego kodu do oprogramowania. Wyciek prawidłowych kluczy do tych narzędzi prowadzi bezpośrednio do cierpienia i cierpienia. Wyobraź sobie wyciek kluczy dostępu root z pełną kontrolą nad zasobami chmury publicznej…

Zwykłe zalecenia

Nie mówimy tu nic nowego, wszyscy o tym wiecie. Ale działajcie! Pamiętajcie, że boty regularnie skanują wszystkie publiczne SCM repozytoria. Kilka rekomendacji, w dowolnej kolejności.

• Jeżeli odpowiadasz za zarządzanie bezpieczeństwem IT, zdefiniuj sposób postępowania z sekretami w polityce bezpieczeństwa. Ale zasady są tak dobre, jak ich egzekwowanie: upewnij się, że w Twojej organizacji obowiązują wytyczne dotyczące postępowania z tajemnicami – obejmujące nie tylko zespoły DevOps, ale także dostawców oprogramowania – oraz że plan reagowania na incydenty w Twojej organizacji zawiera zapisy dotyczące incydentów wycieku tajemnic.
• Wdrażać i egzekwować wieloczynnikowe uwierzytelnianie (MFA, 2FA lub jakikolwiek inny akronim). I żadnych cięć w bezpieczeństwie: klucz bezpieczeństwa USB jest wart tych kilku dolarów, które kosztuje. Musisz wgrać dowolne z tysięcy swoich danych uwierzytelniających (łatwe), a potem upić się i zostawić klucze w barze z czymś, co do ciebie linkuje (szanse są nieco mniejsze, zwłaszcza jeśli jesteś abstynentem).
• Używaj menedżera haseł z silnym, niezapisanym hasłem. Do obsługi sekretów w systemach używaj Tajne Skarbce. CI/CD systemy, dostawcy chmury, SCMs i inne narzędzia DevOps udostępniają tę usługę, ale możesz zdecydować się na ogólne rozwiązanie Secret Vault.
• Woleć krótkotrwały tokeny na trwałe klucze dostępu. Są łatwiejsze do unieważnienia i otwierają bardziej ograniczone okno na zło.
• Ogranicz ponowne wykorzystanie poświadczeń:atakujący wykorzystają ponownie zdobyte dane uwierzytelniające celu w innych systemach, co stanowi kolejny argument za korzystaniem z menedżera haseł. Menedżery haseł i tajne sejfy powinny sprawić, że ponowne wykorzystywanie danych uwierzytelniających stanie się przeszłością.
• Ogranicz i monitoruj użycie Admin hasła. Są na tyle silne, że wymagają specjalnego śledzenia.
• Wdrożenie silne haszowanie i szyfrowanie. Powrót do kluczy USB (kryptograficznych), ścisłych procedur przesyłania danych uwierzytelniających partnerom i współpracownikom itd.
• Użyj skaner sekretówna przykład biegać w pre-commit hak w celu uniknięcia wycieków w systemach kontroli wersji, jako furtki bezpieczeństwa. Przed rzeczą jest tutaj ważne. Alternatywnie, użyj skanowania post-hoc, aby wykryć wyciekłe sekrety, na przykład jako kontrolę przed pull request scalania. Uwaga: nasza platforma Xygeni zawiera skaner sekretów, który umożliwia działanie w obu trybach. 
• Alternatywa ręczna polega na użyciu recenzje kodu wyszukiwanie zakodowanych na stałe sekretów wiąże się z wyższymi kosztami i działa po-commit (ale miejmy nadzieję, że przynajmniej zanim sekret stanie się dostępny dla osób z zewnątrz). Jednak recenzje mogą wykryć niekonwencjonalne sekrety, które mogłyby ominąć skanery sekretów.       
• Unikaj przypadkowego commitłączenie wspólnych plików z sekretami kontroli wersji za pomocą odpowiednich wyklucz wzorce (jak szablon `gitignore`), biorąc pod uwagę pliki takie jak .env, .npmrc, .pypirc, pliki tymczasowe… To rzeczywiście dodatkowa warstwa bezpieczeństwa.
• I ostatnia rzecz na tej długiej liście: pozwólmy dostawcom chmury przeprowadzać skanowanie w poszukiwaniu wycieków kluczy, gdy jest to możliwe. Przynajmniej to może poinformujemy Cię o wycieku, gdy nastąpi, ale bezpieczeństwo jest koniecznością dla dostawców chmury. To post-hoc tajne skanowanie nie jest zbyt przejrzyste, jeśli chodzi o to, gdzie i jak często jest przeprowadzane, i często wymaga wyraźnej konfiguracji, ale z pewnością stanowi ostatnią deskę ratunku, gdy wszystkie inne zawiodą.

O mój Boże! Przesłałem moje klucze dostępu do chmury do publicznego repozytorium, podejście nr 2

To może się przytrafić każdemu. Zakasajcie rękawy!

Natychmiast odnów/unieważnij/wyłącz wyciekły klucz tajny! Jeśli konto ma sprawne uwierzytelnianie wieloskładnikowe (MFA), ryzyko jest znacznie niższe. Może to być trudniejsze np. w przypadku kluczy prywatnych w witrynach internetowych (trzeba wystawić nowy certyfikat dla nowego klucza prywatnego i unieważnić istniejący), ale nowoczesne narzędzia oferują szybki sposób odnawiania poświadczeń lub unieważniania tokenów. 

Jeśli to możliwe, postępuj zgodnie z zaleceniami dostawcy, np. AWS w tym przykładzie.

Zidentyfikuj przyczynę wycieku. Wiedza o tym, jak do niego doszło, jest niezbędna do ujawnienia, analizy, ograniczenia wycieku i wyciągnięcia wniosków.

Następnie zgłoś wyciek poszkodowanym, wyjaśniając działania, które podejmujesz, aby go zatamować i ograniczyć szkody. Nie ma sposobu na odwrócenie wyrządzonych szkód, to, co wyciekło, wycieknie. Bądź transparentny i poinformuj innych, aby mogli podjąć działania. 

Następnie zacznij od kryminalistyki,  okno ekspozycji To czas między wyciekiem a momentem, w którym hasło było nieważne. Bądź gotowy do odczytania logów i śledzenia nietypowej aktywności na koncie, którego dotyczy problem, w tym czasie. Usuń konta i klucze wygenerowane za pomocą konta, którego dotyczy problem. Pamiętaj, że jeśli konto ma uprawnienia administratora, naprawa jest znacznie bardziej złożona. 

Przepisywanie historii (kontrola wersji) Jest to skomplikowane. Nawet państwa totalitarne próbują tego bezskutecznie (gra słów zamierzona). I prawdopodobnie nieistotne: hakerzy lub boty na publicznych repozytoriach mogli sklonować repozytorium lub już wydobyć złoto, zwłaszcza jeśli okno czasowe ekspozycji jest wystarczająco duże. 

Jeśli jesteś odważny i chcesz sprawdzić na własne oczy, ile czasu botom zajmuje wykrycie wyciekłego sekretu, pułapki takie jak Żetony kanaryjskie pozwala eksperymentować. Pamiętaj, boty blokują domyślne canarytokens.org domena…