Zagrożenia bezpieczeństwa związane z używaniem systemu kontroli wersji git

Git, czyli narzędzie do systemu kontroli wersji używane niemalże przez każdego, kto pracuje z kodem. Mimo swoich zalet w postaci łatwości użytkowania, szybkości i przejrzystości, wprowadza szereg zagrożeń dla bezpieczeństwa aplikacji.

Katalog .git

Z problemem związanym z przechowywaniem katalogu .git mogliśmy spotkać się już w poprzednim poście. Z kolei z artykułu udostępniego w 2018 roku możemy dowiedzieć się, że niepoprawnie zabezpieczone katalogi .git powodują, że 390 tysięcy stron może być podatnych na ataki. Obrazuje to niewyobrażalną skalę problemu, której niesposób zignorować.

Co między innymi znajduje się w katalogu .git? Historia commitów oraz wszystkie logi wszystkich wykonanych lokalnie commitów (w tym zmiany typu revert). Należy zatem pamiętać, aby folder .git (notabene tworzony przy inicjalizacji repozytorium) dodać w pierwszej kolejności do pliku .gitignore.

Ujawnienie danych wrażliwych

Przechowywanie danych uwierzytelniających, kluczów API czy też sekretów szyfrujących bezpośrednio w kodzie jest bardzo wygodną praktyką programistyczną. Nie ma potrzeby przechowywania i importowania ich w osobnym pliku. Ponadto, nie trzeba aktualizować i przekazywać osobnych plików do każdego z członków zespołu. Personalnie z problemem spotkałem się najczęściej na przykładzie aplikacji mobilnych. O skali problemu może świadczyć poniższy film.

Istnieje szereg narzędzi skanujących katalogi w poszukiwaniu danych wrażliwych. Należą do nich min.:

Unsigned commits

W przypadku robieniu commitów, możemy w prosty sposób sprawdzić autora zmian w kodzie. Niewiele osób jednak wie, że istnieje coś takiego jak kryptograficzny klucz GPG. Dopóki commit nie został nim podpisany, nie możemy mieć pewności, kto zrobił commit. Może okazać się, że inny programista przypisał commit do swojego współpracownika celem sprytnego wstrzyknięcia backdoora. Commity i tagi podpisane kluczem GPG są oznaczane przez Github jako „Verified” lub „Partially Verified”.

Przykład zweryfikowanego commita z oficjalnej dokumentacji githuba.

Jak możemy podpisać nasz commit? Do standardowego commita należy dodać argument „-S„.

git commit -S -m 'your commit message'

Jak tworzyć sam klucz GPG dowiecie się z oficjalnej dokumentacji.

Błędna konfiguracja

Mimo że powinno być to kwestią oczywistą, nie jest. Za przykład może posłużyć nam Samsung i ich wyciek kodu źródłowego aplikacji SmartThings. Były w nim przetrzymywane dane wrażliwe, dane uwierzytelniające oraz tajne klucze. W plikach znajdywały się między innymi dane potrzebne do zalogowania się na konto AWS zawierające ponad 100 S3 storage buckets, które przetrzymywały logi oraz dane potrzebne do analiz. Ponadto, w projekcie były udostępnione w plaintexcie tokeny do gitlaba, co pozwoliło uzyskać dostęp do 93 prywatnych repozytoriów.

Źródła

https://spectralops.io/blog/8-top-git-security-issues-what-to-do-about-them/
https://www.whitesourcesoftware.com/resources/blog/top-5-git-security-mistakes/
https://techcrunch.com/2019/05/08/samsung-source-code-leak/?guccounter=1&guce_referrer=aHR0cHM6Ly9ibHVicmFja2V0LmNvbS9naXQtaXQtcmlnaHQtaG93LWhhY2tlcnMtZXhwbG9pdC1naXQtbWlzY29uZmlndXJhdGlvbnMtd2hhdC10by1kby1hYm91dC1pdC8&guce_referrer_sig=AQAAALgUE12K7UkehGRvhJBScVRESdd5xk1-USNw3zol4ox5YuHHuOAteaGswkrqMC6CbiUgg9qB1bNHyJiAUnV59cj9gNk3W3Iah27ZoRPW_tP9XT96ZGV6Us38-Ko_GcSCnUHexuT305rag4-CL12hZ6BPKTt02_BZoF_LL6B61gGf
https://github.com/knowyourdata/data-scanner
https://github.com/SAP/credential-digger
https://github.com/zricethezav/gitleaks
https://threatpost.com/open-git-directories-leave-390k-websites-vulnerable/137299/
https://docs.github.com/en/github/authenticating-to-github/managing-commit-signature-verification/generating-a-new-gpg-key


Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *