Dát klíče od svého domu zločincům rozhodně není nejlepší nápad. Ale přesně to se ve většině organizací vyvíjejících moderní software často stává.
V tomto prvním příspěvku o únicích tajných informací si rozebereme, proč se to stává tak často, jaké jsou důsledky a jaké kroky podniknout k prevenci nebo zmírnění problému a k řešení incidentů úniku tajných informací.
Bože! Odeslal jsem své cloudové přístupové klíče do veřejného repozitáře.
Pevně zakódovaná tajemství ve zdrojovém kódu nebo konfiguračních souborech v DevOps nástrojích se může dostat do špatných rukou. Pokud je tajemství commitPokud jsou uloženy ve veřejném repozitáři zdrojů, jste zcela jistě odsouzeni k zániku. Ale ani soukromé repozitáře nejsou bezpečné, protože tajné informace mohou být vyzrazeny i prostřednictvím binárních souborů aplikací, protokolů nebo ukradeného zdrojového kódu.
Při zpětném pohledu je to znepokojivé jak často jednoduché přehlédnutí vedlo k vážnému narušení bezpečnosti. Stačí vygooglit „Úniky klíčů AWS","Úniky přístupových tokenů GitHubu„A tak dále. Neberte tyto příklady jako skrytá doporučení pro toho či onoho dodavatele. Použijte své vlastní!“
Například (ne)slavný Útok Codecovu z dubna 2021 bylo možné, protože obraz Dockeru Codecov obsahoval přihlašovací údaje Git, které útočníkovi umožňovaly získat přístup k soukromým repozitářům Git Codecov a přidat jeden řádek do skriptu bash uploader Codecov pro proměnné prostředí kolekce a URL adresy repozitářů Git.
Připomeňme, že součástí odměny za útoky jsou tajné informace pro získání přístupu k dalším systémům a mnoho útoků investuje značné prostředky do krádeže přihlašovacích údajů, krypto klíčů a tokenů.
Problém je v tom, že pevně zakódovaná tajemství jsou běžnou záležitostíV březnu 2022 byl v Lapsus$ APT uniklo 189 GB zdrojového kódu společnosti Samsung a dalších citlivých souborů. Analýza odhalila, že obsahoval některé 6 600 pevně zakódovaných tajných kódů90 % pro interní systémy, ale 10 % pro externí služby a nástroje jako GitHub, AWS nebo Google. Mezi tato tajná data patřily klíče API AWS / Twilio / Google, řetězce pro připojení k databázi a další citlivé informace. Toto je nejmodernější technologie ve většině kódových bází.
Úniky tajných informací jsou nejjednodušší cestou k útokům na dodavatelský řetězec
Závislosti balíčků jsou v současnosti nejčastějším, i když ne jediným cílem útoků v dodavatelském řetězci. Zločinci by mohli vytvořit nový balíček, který se nakonec nainstaluje do softwaru obětí (pomocí překlepy a další techniky), ale obvykle se snaží infikovat existující balíček buď přidáním úprav zdrojového kódu v softwarových repozitářích (SCM) jako GitHub, GitLab nebo BitBucket, nebo přidáním škodlivých verzí do veřejných registrů jako NPM, PyPI, RubyGems, Maven Central.
Ale vložení škodlivého kódu nebo škodlivé závislosti skryté v složitém grafu závislostí vyžaduje login přihlašovací údaje jako uživatelské jméno/heslo, tokeny nebo přístupové klíče (říkejme jim „klíče„zkráceně „“) pro cílové zdrojové úložiště, respektive veřejný registr.
Zlí hoši někdy získají klíče prostřednictvím sociální inženýrství, útok na event-stream Populární balíček NPM poskytuje pěkný příklad. Ale hledání uniklých informací login přihlašovací údaje nebo přístupové klíče jsou nejčastější útočnou technikou pro útoky na dodavatelský řetězec softwaru.
Zdrojové repozitáře a registry balíčků jsou dva základní systémy při sestavování softwaru. pipelineAle v DevOps existuje mnoho nástrojů: CI/CD systémy, nástroje pro spouštění testů, automatizaci konfigurace a zřizování nebo nasazení a vydání. Všechny tyto nástroje lze zneužít k vkládání škodlivého kódu do softwaru. Únik platných klíčů pro tyto nástroje vede přímo k neštěstí a agónii. Představte si únik klíčů pro přístup root s plnou kontrolou nad vašimi veřejnými cloudovými zdroji…
Obvyklá doporučení
Neříkáme tu nic nového, všichni to víte. Ale jednejte! Nezapomeňte, že boti pravidelně prohledávají všechny veřejné SCM repozitáře. Několik doporučení, v náhodném pořadí.
- Pokud máte zodpovědnost za řízení IT bezpečnosti, definovat, jak by se mělo zacházet s tajnými informacemi v bezpečnostní politice. Politiky jsou však jen tak dobré, jak je vynucují: zajistěte, aby ve vaší organizaci byly vynucovány směrnice pro nakládání s tajnými informacemi – a to nejen pro vaše DevOps týmy, ale i pro dodavatele softwaru – a aby plán reakce na incidenty vaší organizace obsahoval ustanovení pro případy úniku tajných informací.
- Implementovat a prosazovat multifaktorová autentizace (MFA, 2FA nebo jakákoli jiná zkratka). A žádné omezení zabezpečení: bezpečnostní USB klíč má cenu pár dolarů, které stojí. Musíte pomocí gitpushu odeslat libovolný ze svých tisíců přihlašovacích údajů (což je snadné) a pak se opít a nechat klíče v baru s něčím, co na vás odkazuje (pravděpodobnost je o něco menší, zvláště pokud jste abstinent).
- Používejte správce hesel se silným, neuloženým heslem. Pro práci s tajnými hesly v systémech používejte Tajné trezory. CI/CD systémy, poskytovatelé cloudových služeb, SCMTuto službu poskytují i další DevOps nástroje, ale můžete se rozhodnout pro generické řešení Secret Vault.
- Preferujte krátkodobé tokeny na dlouhodobé přístupové klíče. Snazší je zrušit a zkaženým lidem vystavují omezenější prostor.
- Omezit opakované použití přihlašovacích údajůÚtočníci budou znovu používat získané přihlašovací údaje pro cíl v jiných systémech, což je další důvod pro použití správce hesel. Správci hesel a tajné trezory by měly opětovné použití přihlašovacích údajů učinit minulostí.
- Omezte a sledujte používání administrátor hesla. Jsou dostatečně silná, aby si zasloužila zvláštní sledování.
- Nářadí silné hashování a šifrováníZpět k USB (kryptografickým) klíčům, přísným postupům pro přenos přihlašovacích údajů s partnery a spolupracovníky a tak dále.
- Použití skener tajných informací, například spustit v pre-commit háček aby se zabránilo únikům v systémech správy verzí, jako bezpečnostní brána. Před tou věcí je zde důležité. Alternativně použijte post-hoc skenování k odhalení uniklých tajemství, například jako kontrolu před pull request slučování. Poznámka: Naše platforma Xygeni obsahuje skener tajných kódů, který umožňuje oba režimy provozu.
- Manuální alternativa použití recenze kódu Hledání pevně zakódovaných tajných kódů má vyšší náklady a funguje až pocommit (ale doufejme, že alespoň dříve, než bude tajemství dostupné pro cizince). Kontroly však mohou odhalit nekonvenční tajemství, která by mohla skenerům tajných informací uniknout.
- Vyhněte se náhodnému commitpřiřazení běžných souborů s tajnými kódy do systému správy verzí s příslušnými vyloučit vzory (jako šablona `gitignore`), s ohledem na soubory jako
.env,.npmrc,.pypirc, dočasné soubory… Vskutku další vrstva zabezpečení. - A poslední v tomto dlouhém seznamu: nechte poskytovatele cloudových služeb provádět skenování úniků jejich klíčů, pokud je to možné. Alespoň toto smět dáme vám vědět o úniku, kdy k němu došlo, ale zabezpečení je pro poskytovatele cloudových služeb nutností. Toto post-hoc Tajné skenování není příliš transparentní ohledně toho, kde a jak často se skenování provádí, a často vyžaduje explicitní nastavení, ale rozhodně je poslední možností, když všechno ostatní selže.
Bože! Odeslal jsem své cloudové přístupové klíče do veřejného repozitáře, druhý pokus.
To se může stát i těm nejlepším z nás. Vyhrňte si rukávy!
Okamžitě obnovte / zrušte / deaktivujte uniklý tajný klíč! Pokud má účet slušnou vícefaktorovou autentizaci (MFA), je riziko mnohem nižší. To by mohlo být obtížnější např. u soukromých klíčů na webových stránkách (musíte vydat nový certifikát pro nový soukromý klíč a stávající zrušit), ale moderní nástroje mají rychlý způsob, jak obnovit přihlašovací údaje nebo zrušit tokeny.
Pokud jsou k dispozici, postupujte podle kroků doporučených poskytovatelem, například AWS v tomto příkladu.
Identifikujte příčinu úniku. Vědět, jak k němu došlo, je nezbytné pro odhalení, analýzu, omezení a aktivity zaměřené na vyvození poznatků.
Poté únik nahlaste dotčeným stranám a vysvětlete, jaké kroky podnikáte k jeho utěsnění a snížení škod. Neexistuje způsob, jak zvrátit způsobené škody, co uniklo, to uniklo. Buďte transparentní a informujte ostatní, aby mohli podniknout kroky.
Pak začněte s forenzní, expoziční okno je doba mezi únikem a dobou, kdy tajný kód nebyl platný. Buďte připraveni číst protokoly a sledovat neobvyklou aktivitu s postiženým účtem během tohoto období. Odeberte účty a klíče vygenerované pomocí postiženého účtu. Nezapomeňte, že pokud má postižený účet administrátorská oprávnění, je oprava mnohem složitější.
Přepisování historie (správa verzí) je složité. I totalitní státy se o to marně pokoušejí (slovní hříčka úmyslná). A pravděpodobně irelevantní: hackeři nebo boti na veřejných repozitářích mohli repozitář naklonovat nebo už zlato extrahovat, zejména pokud je expoziční okno dostatečně velké.
Pokud jste dobrodružní a chcete se na vlastní oči přesvědčit, jak dlouho trvá, než botové odhalí uniklé tajemství, můžete využít triplewires jako… Kanárské žetony vám umožní experimentovat. Nezapomeňte, že boti dávají na černou listinu výchozí canarytokens.org doména…
| Chcete-li si přečíst víceKovacs, E.Tisíce tajných klíčů nalezeny v uniklém zdrojovém kódu Samsungu„. Týden bezpečnosti, březen 2022. Dyjak, A.“Před pár dny jsem provedl malý experiment s WRT Secrets. commitukládáno do veřejných git repozitářů…". Tweet vlákno, listopad 2020. Rzepa, P."Únik přístupových klíčů AWS v repozitáři GitHub a některá vylepšení v Amazon Reaction„. Medium, listopad 2020.“ |




