Last updated
Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
Podstawowa struktura środowiska github w dużej firmie polega na posiadaniu przedsiębiorstwa, które posiada kilka organizacji, a każda z nich może zawierać kilka repozytoriów i kilka zespołów. Mniejsze firmy mogą posiadać tylko jedną organizację i żadnych przedsiębiorstw.
Z punktu widzenia użytkownika, użytkownik może być członkiem różnych przedsiębiorstw i organizacji. W ramach nich użytkownik może mieć różne role w przedsiębiorstwie, organizacji i repozytorium.
Ponadto, użytkownik może być częścią różnych zespołów z różnymi rolami w przedsiębiorstwie, organizacji lub repozytorium.
I w końcu repozytoria mogą mieć specjalne mechanizmy ochrony.
Właściciel przedsiębiorstwa: Osoby z tą rolą mogą zarządzać administratorami, zarządzać organizacjami w ramach przedsiębiorstwa, zarządzać ustawieniami przedsiębiorstwa, egzekwować polityki w organizacjach. Jednak nie mogą uzyskać dostępu do ustawień organizacji ani treści, chyba że zostaną właścicielem organizacji lub otrzymają bezpośredni dostęp do repozytorium należącego do organizacji.
Członkowie przedsiębiorstwa: Członkowie organizacji należących do twojego przedsiębiorstwa są również automatycznie członkami przedsiębiorstwa.
W organizacji użytkownicy mogą mieć różne role:
Właściciele organizacji: Właściciele organizacji mają pełny dostęp administracyjny do twojej organizacji. Ta rola powinna być ograniczona, ale nie mniej niż do dwóch osób w twojej organizacji.
Członkowie organizacji: Domyślna, nieadministracyjna rola dla osób w organizacji to członek organizacji. Domyślnie członkowie organizacji mają szereg uprawnień.
Menedżerowie ds. rozliczeń: Menedżerowie ds. rozliczeń to użytkownicy, którzy mogą zarządzać ustawieniami rozliczeń dla twojej organizacji, takimi jak informacje o płatności.
Menedżerowie ds. bezpieczeństwa: To rola, którą właściciele organizacji mogą przypisać dowolnemu zespołowi w organizacji. Po zastosowaniu, daje każdemu członkowi zespołu uprawnienia do zarządzania alertami bezpieczeństwa i ustawieniami w całej organizacji, a także uprawnienia do odczytu dla wszystkich repozytoriów w organizacji.
Jeśli twoja organizacja ma zespół ds. bezpieczeństwa, możesz użyć roli menedżera ds. bezpieczeństwa, aby dać członkom zespołu minimalny dostęp, którego potrzebują do organizacji.
Menedżerowie aplikacji Github: Aby umożliwić dodatkowym użytkownikom zarządzanie aplikacjami GitHub należącymi do organizacji, właściciel może przyznać im uprawnienia menedżera aplikacji GitHub.
Zewnętrzni współpracownicy: Zewnętrzny współpracownik to osoba, która ma dostęp do jednego lub więcej repozytoriów organizacji, ale nie jest wyraźnie członkiem organizacji.
Możesz porównać uprawnienia tych ról w tej tabeli: https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles
W https://github.com/organizations/<org_name>/settings/member_privileges możesz zobaczyć uprawnienia, które użytkownicy będą mieli tylko za bycie częścią organizacji.
Ustawienia skonfigurowane tutaj wskażą następujące uprawnienia członków organizacji:
Bycie administratorem, pisarzem, czytelnikiem lub brakiem uprawnień do wszystkich repozytoriów organizacji.
Czy członkowie mogą tworzyć prywatne, wewnętrzne lub publiczne repozytoria.
Czy możliwe jest forkowanie repozytoriów.
Czy możliwe jest zapraszanie zewnętrznych współpracowników.
Czy publiczne lub prywatne strony mogą być publikowane.
Uprawnienia, jakie mają administratorzy nad repozytoriami.
Czy członkowie mogą tworzyć nowe zespoły.
Domyślnie tworzone są role w repozytorium:
Odczyt: Zalecane dla współpracowników, którzy chcą przeglądać lub omawiać twój projekt.
Triage: Zalecane dla współpracowników, którzy muszą proaktywnie zarządzać problemami i pull requestami bez dostępu do zapisu.
Zapis: Zalecane dla współpracowników, którzy aktywnie wprowadzają zmiany do twojego projektu.
Zarządzanie: Zalecane dla menedżerów projektów, którzy muszą zarządzać repozytorium bez dostępu do wrażliwych lub destrukcyjnych działań.
Administrator: Zalecane dla osób, które potrzebują pełnego dostępu do projektu, w tym wrażliwych i destrukcyjnych działań, takich jak zarządzanie bezpieczeństwem lub usuwanie repozytoriów.
Możesz porównać uprawnienia każdej roli w tej tabeli https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role
Możesz również utworzyć własne role w https://github.com/organizations/<org_name>/settings/roles
Możesz wylistować zespoły utworzone w organizacji w https://github.com/orgs/<org_name>/teams. Zauważ, że aby zobaczyć zespoły, które są dziećmi innych zespołów, musisz uzyskać dostęp do każdego zespołu nadrzędnego.
Użytkownicy organizacji mogą być wylistowani w https://github.com/orgs/<org_name>/people.
W informacji o każdym użytkowniku możesz zobaczyć zespoły, których członkiem jest użytkownik, oraz repozytoria, do których użytkownik ma dostęp.
Github oferuje różne sposoby uwierzytelniania do twojego konta i wykonywania działań w twoim imieniu.
Uzyskując dostęp do github.com, możesz zalogować się używając swojego nazwa użytkownika i hasła (oraz potencjalnie 2FA).
Możesz skonfigurować swoje konto z jednym lub kilkoma kluczami publicznymi, pozwalając powiązanemu kluczowi prywatnemu na wykonywanie działań w twoim imieniu. https://github.com/settings/keys
Nie możesz podszywać się pod użytkownika za pomocą tych kluczy, ale jeśli ich nie używasz, może być możliwe, że zostaniesz odkryty za wysyłanie commitów bez podpisu. Dowiedz się więcej o trybie czujności tutaj.
Możesz wygenerować token dostępu osobistego, aby dać aplikacji dostęp do twojego konta. Podczas tworzenia tokena dostępu osobistego użytkownik musi określić uprawnienia, które token będzie miał. https://github.com/settings/tokens
Aplikacje Oauth mogą prosić o uprawnienia do uzyskania dostępu do części twoich informacji github lub do podszywania się pod ciebie w celu wykonania niektórych działań. Typowym przykładem tej funkcjonalności jest przycisk logowania z githubem, który możesz znaleźć na niektórych platformach.
Możesz utworzyć własne aplikacje Oauth w https://github.com/settings/developers
Możesz zobaczyć wszystkie aplikacje Oauth, które mają dostęp do twojego konta w https://github.com/settings/applications
Możesz zobaczyć zakresy, o które mogą prosić aplikacje Oauth w https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps
Możesz zobaczyć dostęp aplikacji stron trzecich w organizacji w https://github.com/organizations/<org_name>/settings/oauth_application_policy
Kilka zalecenia dotyczące bezpieczeństwa:
Aplikacja OAuth powinna zawsze działać jako uwierzytelniony użytkownik GitHub we wszystkich aspektach GitHub (na przykład, gdy dostarcza powiadomienia użytkownikowi) i mieć dostęp tylko do określonych zakresów.
Aplikacja OAuth może być używana jako dostawca tożsamości, włączając "Logowanie z GitHub" dla uwierzytelnionego użytkownika.
Nie buduj aplikacji OAuth, jeśli chcesz, aby twoja aplikacja działała na pojedynczym repozytorium. Z zakresem repo, aplikacje OAuth mogą działać na wszystkich repozytoriach uwierzytelnionego użytkownika.
Nie buduj aplikacji OAuth, aby działała jako aplikacja dla twojego zespołu lub firmy. Aplikacje OAuth uwierzytelniają się jako pojedynczy użytkownik, więc jeśli jedna osoba stworzy aplikację OAuth dla firmy, a potem odejdzie z firmy, nikt inny nie będzie miał do niej dostępu.
Więcej tutaj tutaj.
Aplikacje Github mogą prosić o uprawnienia do uzyskania dostępu do twoich informacji github lub podszywania się pod ciebie w celu wykonania określonych działań nad określonymi zasobami. W aplikacjach Github musisz określić repozytoria, do których aplikacja będzie miała dostęp.
Aby zainstalować aplikację GitHub, musisz być właścicielem organizacji lub mieć uprawnienia administratora w repozytorium.
Aplikacja GitHub powinna łączyć się z osobistym kontem lub organizacją.
Możesz stworzyć własną aplikację Github w https://github.com/settings/apps
Możesz zobaczyć wszystkie aplikacje Github, które mają dostęp do twojego konta w https://github.com/settings/apps/authorizations
Oto punkty końcowe API dla aplikacji Github https://docs.github.com/en/rest/overview/endpoints-available-for-github-app. W zależności od uprawnień aplikacji, będzie mogła uzyskać dostęp do niektórych z nich.
Możesz zobaczyć zainstalowane aplikacje w organizacji w https://github.com/organizations/<org_name>/settings/installations
Kilka zaleceń dotyczących bezpieczeństwa:
Aplikacja GitHub powinna podejmować działania niezależnie od użytkownika (chyba że aplikacja używa tokena user-to-server). Aby zachować większe bezpieczeństwo tokenów dostępu user-to-server, możesz użyć tokenów dostępu, które wygasną po 8 godzinach, oraz tokena odświeżającego, który można wymienić na nowy token dostępu. Więcej informacji znajdziesz w "Odświeżanie tokenów dostępu user-to-server."
Upewnij się, że aplikacja GitHub integruje się z określonymi repozytoriami.
Aplikacja GitHub powinna łączyć się z osobistym kontem lub organizacją.
Nie oczekuj, że aplikacja GitHub będzie wiedziała i robiła wszystko, co może użytkownik.
Nie używaj aplikacji GitHub, jeśli potrzebujesz tylko usługi "Logowanie z GitHub". Ale aplikacja GitHub może użyć przepływu identyfikacji użytkownika do logowania użytkowników i wykonywania innych działań.
Nie buduj aplikacji GitHub, jeśli tylko chcesz działać jako użytkownik GitHub i robić wszystko, co ten użytkownik może zrobić.
Jeśli używasz swojej aplikacji z GitHub Actions i chcesz modyfikować pliki robocze, musisz uwierzytelnić się w imieniu użytkownika za pomocą tokena OAuth, który zawiera zakres workflow. Użytkownik musi mieć uprawnienia administratora lub zapisu do repozytorium, które zawiera plik roboczy. Więcej informacji znajdziesz w "Zrozumienie zakresów dla aplikacji OAuth."
Więcej tutaj tutaj.
To nie jest sposób na uwierzytelnienie w githubie, ale złośliwa akcja Github mogłaby uzyskać nieautoryzowany dostęp do githuba i w zależności od uprawnień nadanych akcji, mogłyby zostać przeprowadzone różne ataki. Zobacz poniżej więcej informacji.
Akcje Git pozwalają na automatyzację wykonywania kodu, gdy wystąpi zdarzenie. Zwykle wykonywany kod jest w jakiś sposób związany z kodem repozytorium (może budować kontener docker lub sprawdzać, czy PR nie zawiera sekretów).
W https://github.com/organizations/<org_name>/settings/actions można sprawdzić konfigurację akcji github dla organizacji.
Możliwe jest całkowite zablokowanie użycia akcji github, zezwolenie na wszystkie akcje github lub zezwolenie tylko na niektóre akcje.
Możliwe jest również skonfigurowanie kto potrzebuje zatwierdzenia do uruchomienia akcji Github oraz uprawnienia GITHUB_TOKEN akcji Github, gdy jest uruchamiana.
Akcje Github zazwyczaj potrzebują jakiegoś rodzaju sekretów do interakcji z githubem lub aplikacjami stron trzecich. Aby uniknąć umieszczania ich w postaci jawnej w repozytorium, github pozwala na umieszczanie ich jako Sekrety.
Te sekrety mogą być skonfigurowane dla repozytorium lub dla całej organizacji. Następnie, aby Akcja mogła uzyskać dostęp do sekretu, musisz zadeklarować go w ten sposób:
Sekrety mogą być dostępne tylko z Github Actions, które je zadeklarowały.
Po skonfigurowaniu w repozytorium lub organizacjach użytkownicy githuba nie będą mogli uzyskać do nich ponownie dostępu, będą mogli jedynie je zmieniać.
Dlatego jedynym sposobem na kradzież sekretów githuba jest uzyskanie dostępu do maszyny, która wykonuje Github Action (w tym scenariuszu będziesz mógł uzyskać dostęp tylko do sekretów zadeklarowanych dla tej Akcji).
Github pozwala na tworzenie środowisk, w których możesz przechowywać sekrety. Następnie możesz dać github action dostęp do sekretów w środowisku za pomocą czegoś takiego jak:
Możesz skonfigurować środowisko, aby było dostępne dla wszystkich gałęzi (domyślnie), tylko chronionych gałęzi lub określić, które gałęzie mogą uzyskać do niego dostęp. Można również ustawić liczbę wymaganych recenzji przed wykonaniem akcji przy użyciu środowiska lub czekać przez czas, zanim pozwoli się na kontynuację wdrożeń.
Akcja Github może być wykonywana w środowisku github lub może być wykonywana w infrastrukturze zewnętrznej skonfigurowanej przez użytkownika.
Wiele organizacji pozwala na uruchamianie Akcji Github w infrastrukturze zewnętrznej, ponieważ zazwyczaj jest to tańsze.
Możesz wymienić samodzielnie hostowane runner'y organizacji w https://github.com/organizations/<org_name>/settings/actions/runners
Sposobem na znalezienie, które Akcje Github są wykonywane w infrastrukturze nie-github jest wyszukiwanie runs-on: self-hosted w konfiguracji yaml Akcji Github.
Nie jest możliwe uruchomienie Akcji Github organizacji w samodzielnie hostowanej maszynie innej organizacji, ponieważ generowany jest unikalny token dla Runner'a podczas jego konfiguracji, aby wiedzieć, do której organizacji należy.
Jeśli niestandardowy Github Runner jest skonfigurowany na maszynie w AWS lub GCP, na przykład, Akcja może mieć dostęp do punktu końcowego metadanych i ukraść token konta usługi, z którym działa maszyna.
Jeśli wszystkie akcje (lub złośliwa akcja) są dozwolone, użytkownik mógłby użyć Akcji Github, która jest złośliwa i kompromituje kontener, w którym jest wykonywana.
Uruchomienie złośliwej Akcji Github mogłoby być wykorzystane przez atakującego do:
Kradzieży wszystkich sekretów, do których Akcja ma dostęp
Poruszania się lateralnie, jeśli Akcja jest wykonywana w infrastrukturze zewnętrznej, gdzie token SA użyty do uruchomienia maszyny może być dostępny (prawdopodobnie za pośrednictwem usługi metadanych)
Wykorzystania tokena używanego przez workflow do kradzieży kodu repozytorium, w którym Akcja jest wykonywana lub nawet jego modyfikacji.
Ochrona gałęzi ma na celu nieprzekazywanie pełnej kontroli nad repozytorium użytkownikom. Celem jest wprowadzenie kilku metod ochrony przed możliwością pisania kodu w niektórej gałęzi.
Ochrona gałęzi repozytorium może być znaleziona w https://github.com/<orgname>/<reponame>/settings/branches
Nie jest możliwe ustawienie ochrony gałęzi na poziomie organizacji. Wszystkie muszą być zadeklarowane w każdym repozytorium.
Różne ochrony mogą być stosowane do gałęzi (jak do master):
Możesz wymagać PR przed scaleniem (więc nie możesz bezpośrednio scalać kodu w gałęzi). Jeśli to jest wybrane, mogą być wprowadzone różne inne zabezpieczenia:
Wymagaj liczby zatwierdzeń. Bardzo często wymaga się, aby 1 lub 2 inne osoby zatwierdziły Twój PR, aby pojedynczy użytkownik nie mógł bezpośrednio scalać kodu.
Odrzuć zatwierdzenia, gdy nowe commity są przesyłane. W przeciwnym razie użytkownik może zatwierdzić legalny kod, a następnie dodać złośliwy kod i go scalić.
Wymagaj recenzji od Właścicieli Kodu. Co najmniej 1 właściciel kodu repozytorium musi zatwierdzić PR (więc "przypadkowi" użytkownicy nie mogą go zatwierdzić)
Ogranicz, kto może odrzucać recenzje pull requestów. Możesz określić osoby lub zespoły, które mogą odrzucać recenzje pull requestów.
Pozwól określonym aktorom na ominięcie wymagań pull requestów. Ci użytkownicy będą mogli ominąć wcześniejsze ograniczenia.
Wymagaj, aby kontrole statusu przeszły przed scaleniem. Niektóre kontrole muszą przejść przed możliwością scalania commita (jak akcja github sprawdzająca, czy nie ma żadnych jawnych sekretów).
Wymagaj rozwiązania rozmowy przed scaleniem. Wszystkie komentarze dotyczące kodu muszą być rozwiązane przed scaleniem PR.
Wymagaj podpisanych commitów. Commity muszą być podpisane.
Wymagaj liniowej historii. Zapobiegaj przesyłaniu commitów scalających do pasujących gałęzi.
Uwzględnij administratorów. Jeśli to nie jest ustawione, administratorzy mogą ominąć ograniczenia.
Ogranicz, kto może przesyłać do pasujących gałęzi. Ogranicz, kto może wysłać PR.
Jak widać, nawet jeśli udało Ci się uzyskać jakieś dane uwierzytelniające użytkownika, repozytoria mogą być chronione, co uniemożliwia Ci przesyłanie kodu do master na przykład, aby skompromitować pipeline CI/CD.
Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
