I

nernet to wodospad cieknących danych. W mojej pierwszej serii Necronomicon ( część I oraz II) mogliśmy się o tym przekonać na przykładzie skracarek adresów URL. Dzisiaj zajmiemy się serwisami oferującymi miejsce na repozytoria kodu. Ale od początku. Jakieś dziesięć lat temu powstał ruch DevOps – przechodząc przez różne etapy rozwoju dołączono do niego kolejny człon – DevSecOps. Upraszczając: jest to ruch, który osadza w cykl życia oprogramowania procesy bezpieczeństwa. Jego braki lub luki proceduralne są częstym i w dużej mierze niedocenianym wektorem zagrożeń dla wielu firm i organizacji.

Bez odpowiedniej polityki i zautomatyzowanego procesu bezpieczeństwa nieświadomi twórcy oprogramowania dość często doprowadzają do przypadkowego wycieku poufnych danych – szczególnie w firmach będących na poziomie startupów tajne informacje (np. klucze API, SSH itd.) do usług stron trzecich są umieszczane na platformach hostingowych kodu takich, jak: GitHub, GitLab i BitBucket. Te wrażliwe dane – w tym dane, które mają chronić często trafiają w ręce cyberprzestępców, co ostatecznie prowadzi do poważnych wycieków danych, jak w przypadku kanadyjskiego giganta bankowego Scotiabank.

Przeszukiwanie GitHub’a pod kątem wrażliwych informacji nie jest nowym zjawiskiem. Istnieje wiele narzędzi open source, które pomagają w tym procesie. W zależności od tego, po której stronie się opowiadamy mamy do dyspozycji (od strony atakującego): gitrob, truffleHog, surch, czy gittyleaks – koncentrujące się na kopaniu w historii, aby znaleźć tajne tokeny; od strony obrońcy: git-secrets, secret-bridge, gitleaks, repo-supervisor, git-hound, czy detect-secrets – używane jako hooki czy jeden z etapów ciągłej integracji przed wysłaniem zmian kodu do głównego repozytorium. Zresztą sam GitHub aktywnie skanuje projekty w poszukiwaniu “sekretów” poprzez swoje narzędzie do skanowania tokenów. Jego celem jest identyfikacja wrażliwych tokenów w ramach zatwierdzonego kodu repozytorium w czasie rzeczywistym i powiadomienie o tym dostawcy, który automatycznie unieważni token, aby zapobiec nadużyciom za jego pomocą. W trakcie pisania tego artykułu obsługiwanych jest 20 dostawców m.in. Google Cloud, AWS, Azure, Dropbox, Slack.

W teorii, jeśli przypadkowo puścimy commit do GitHub z kluczami do usługi AWS, Amazon zostanie powiadomiony i automatycznie je unieważni. Czy temu procesowi można ufać? Czy możemy robić to samo, ale w sposób kontradyktoryjny? Ostatnie badania z Uniwersytetu Stanowego Północnej Karoliny wykazały, że wiele wrażliwych informacji przypadkowo opublikowanych na GitHub zostało usuniętych w ciągu 24 godzin, co czyni w/w narzędzia typu offline mało efektywnymi w praktyce. Na szczęście wszystkie trzy platformy (GitHub, GitLab i BitBucket) zapewniają publiczny interfejs API dla zdarzeń (który wyszczególnia różne strumienie aktywności, w tym zatwierdzania [ ang. commit ] kodu) dzięki czemu można monitorować je w czasie rzeczywistym (w praktyce z kilkuminutowym opóźnieniem).

Paul Price zainspirowany wspomnianym narzędziem gitrob stworzył shhgit, które obserwuje strumienie zatwierdzanych kodów w czasie rzeczywistym i wyciąga z nich wszelkie przypadkowo wypuszczone sekrety. Dane te są porównywalne z 120 sygnaturami, na które mogą składać się: nazwa pliku, rozszerzenie i zawartość. Jak sam autor zauważył w średnio 7 minut można znaleźć i zweryfikować przesłane klucze. W zależności od ich rodzaju (np. klucze do AWS) koło 50% z nich jest poprawnych, co oznacza, że można uzyskać dostęp do odpowiedniej usługi przy użyciu przechwyconych poświadczeń / kluczy. Może to sugerować, że albo usługa skanowania tokenów GitHub nie jest wystarczająco szybka lub jej wzorce nie wychwytują wszystkiego. W celu demonstracji tego zagrożenia na żywo dostępna jest strona przykrywająca narzędzie shhgit GUI. Poprzez prowadzenie obserwacji przez blisko godzinę udało się złapać naprawdę ciekawe rzeczy, jakie zostają przesłane do publicznie dostępnych repozytoriów kodu.

Więcej informacji: Ahh shhgit!, Grabienie rozproszonych systemów zarządzania wersjami dla zabawy i zysku