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”.
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