Polish - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

Basic Github Information

Naucz się hakować AWS od zera do bohatera z htARTE (HackTricks AWS Red Team Expert)!

Inne sposoby wsparcia HackTricks:

Podstawowa struktura

Podstawowa struktura środowiska Github dla dużej firmy polega na posiadaniu przedsiębiorstwa, które posiada kilka organizacji, z których każda może zawierać kilka repozytoriów i kilka zespołów. Mniejsze firmy mogą po prostu posiadać jedną organizację i nie posiadać przedsiębiorstwa.

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 przedsiębiorstwa, organizacji i repozytorium.

Ponadto, użytkownik może być członkiem różnych zespołów o różnych rolach przedsiębiorstwa, organizacji lub repozytorium.

I wreszcie repozytoria mogą mieć specjalne mechanizmy ochrony.

Uprawnienia

Role przedsiębiorstwa

  • Właściciel przedsiębiorstwa: Osoby posiadające tę rolę mogą zarządzać administratorami, zarządzać organizacjami w ramach przedsiębiorstwa, zarządzać ustawieniami przedsiębiorstwa, egzekwować politykę we wszystkich organizacjach. Jednak nie mogą uzyskać dostępu do ustawień ani treści organizacji, chyba że zostaną uznani za właściciela 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.

Role organizacji

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ż dwie osoby, w twojej organizacji.

  • Członkowie organizacji: Domyślna, nieadministracyjna rola dla osób w organizacji to członek organizacji. Domyślnie członkowie organizacji posiadają wiele uprawnień.

  • Menedżerowie rozliczeń: Menedżerowie rozliczeń to użytkownicy, którzy mogą zarządzać ustawieniami rozliczeń dla twojej organizacji, takimi jak informacje o płatności.

  • Menedżerowie bezpieczeństwa: Jest to rola, którą właściciele organizacji mogą przypisać dowolnemu zespołowi w organizacji. Po jej zastosowaniu każdy członek zespołu otrzymuje uprawnienia do zarządzania alertami i ustawieniami bezpieczeństwa 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 bezpieczeństwa, aby dać członkom zespołu minimalny dostęp do organizacji.

  • Menedżerowie aplikacji Github: Aby umożliwić innym użytkownikom zarządzanie aplikacjami GitHub należącymi do organizacji, właściciel może przyznać im uprawnienia menedżera aplikacji GitHub.

  • Współpracownicy zewnętrzni: Współpracownik zewnętrzny to osoba, która ma dostęp do jednego lub więcej repozytoriów organizacji, ale nie jest bezpośrednio 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

Uprawnienia członków

W https://github.com/organizations/<org_name>/settings/member_privileges możesz zobaczyć uprawnienia, jakie będą miały członkowie organizacji.

Skonfigurowane tutaj ustawienia określają następujące uprawnienia członków organizacji:

  • Bycie administratorem, pisarzem, czytelnikiem lub brak uprawnień do wszystkich repozytoriów organizacji.

  • Czy członkowie mogą tworzyć repozytoria prywatne, wewnętrzne lub publiczne.

  • Czy możliwe jest kopiowanie repozytoriów.

  • Czy można zapraszać współpracowników zewnętrznych.

  • Czy można publikować strony publiczne lub prywatne.

  • Uprawnienia administratorów wobec repozytoriów.

  • Czy członkowie mogą tworzyć nowe zespoły.

Role repozytorium

Domyślnie tworzone są role repozytorium:

  • Odczyt: Rekomendowane dla osób niebędących programistami, które chcą przeglądać lub omawiać twój projekt.

  • Triage: Rekomendowane dla osób, które muszą aktywnie zarządzać problemami i żądaniami dotyczącymi kodu źródłowego bez dostępu do zapisu.

  • Zapis: Rekomendowane dla osób, które aktywnie przesyłają zmiany do twojego projektu.

  • Utrzymanie: Rekomendowane dla menedżerów projektu, którzy muszą zarządzać repozytorium bez dostępu do działań wrażliwych lub destrukcyjnych.

  • Admin: Rekomendowane dla osób, które potrzebują pełnego dostępu do projektu, w tym działań wrażliwych i destrukcyjnych, takich jak zarządzanie bezpieczeństwem lub usuwanie repozytorium.

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ż tworzyć własne role w https://github.com/organizations/<org_name>/settings/roles

Zespoły

Możesz wyświetlić listę utworzonych zespołów w organizacji w https://github.com/orgs/<org_name>/teams. Należy zauważyć, że aby zobaczyć zespoły będące dziećmi innych zespołów, należy uzyskać dostęp do każdego zespołu nadrzędnego.

Użytkownicy

Użytkownicy organizacji mogą być wyświetlani w https://github.com/orgs/<org_name>/people.

W informacjach o każdym użytkowniku można zobaczyć zespoły, do których użytkownik należy, oraz repozytoria, do których użytkownik ma dostęp.

Autentykacja w Githubie

Github oferuje różne sposoby uwierzytelniania w celu zalogowania

Aplikacje OAuth

Aplikacje OAuth mogą prosić o uprawnienia do dostępu do części Twoich informacji na GitHubie lub do udawania Ciebie w celu wykonania pewnych działań. Przykładem takiej funkcjonalności jest przycisk zaloguj się za pomocą GitHuba, który możesz znaleźć na niektórych platformach.

Następujące zalecenia dotyczące bezpieczeństwa:

  • Aplikacja OAuth powinna zawsze działać jako uwierzytelniony użytkownik GitHuba we wszystkich obszarach GitHuba (na przykład podczas dostarczania powiadomień użytkownikowi) i mieć dostęp tylko do określonych zakresów.

  • Aplikacja OAuth może być używana jako dostawca tożsamości, umożliwiając uwierzytelnianie użytkownika za pomocą "Zaloguj się za pomocą GitHuba".

  • Nie twórz aplikacji OAuth, jeśli chcesz, aby Twoja aplikacja działała na jednym repozytorium. Dzięki zakresowi repo, aplikacje OAuth mogą działać na wszystkich repozytoriach uwierzytelnionego użytkownika.

  • Nie twórz aplikacji OAuth, aby działała jako aplikacja dla Twojego zepołu lub firmy. Aplikacje OAuth uwierzytelniają się jako pojedynczy użytkownik, więc jeśli jedna osoba tworzy aplikację OAuth do użytku przez firmę, a następnie opuszcza firmę, nikt inny nie będzie miał do niej dostępu.

  • Więcej informacji znajdziesz tutaj.

Aplikacje GitHub

Aplikacje GitHub mogą prosić o uprawnienia do dostępu do Twoich informacji na GitHubie lub do udawania Ciebie w celu wykonania określonych działań na określonych zasobach. 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 połączyć się z kontem osobistym lub organizacją.

  • Możesz utworzyć swoją własną aplikację GitHub na stronie https://github.com/settings/apps

  • Możesz zobaczyć wszystkie aplikacje GitHub, które mają dostęp do Twojego konta na stronie 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 ona miała dostęp do niektórych z nich.

  • Możesz zobaczyć zainstalowane aplikacje w organizacji na stronie https://github.com/organizations/<org_name>/settings/installations

Następujące zalecenia dotyczące bezpieczeństwa:

  • Aplikacja GitHub powinna wykonywać działania niezależnie od użytkownika (chyba że aplikacja używa tokena użytkownik-do-serwera). Aby zwiększyć bezpieczeństwo tokenów dostępu użytkownik-do-serwera, można użyć tokenów dostępu, które wygasają po 8 godzinach, oraz tokenu odświeżania, który można wymienić na nowy token dostępu. Więcej informacji znajdziesz w artykule "Odświeżanie tokenów dostępu użytkownik-do-serwera."

  • Upewnij się, że aplikacja GitHub integruje się z konkretnymi repozytoriami.

  • Aplikacja GitHub powinna połączyć się z kontem osobistym lub organizacją.

  • Nie oczekuj, że aplikacja GitHub będzie wiedziała i robiła wszystko, czego może użytkownik.

  • Nie używaj aplikacji GitHub, jeśli potrzebujesz tylko usługi "Zaloguj się za pomocą GitHuba". Jednak aplikacja GitHub może używać procesu identyfikacji użytkownika do logowania użytkowników i wykonywania innych czynności.

  • Nie twórz aplikacji GitHub, jeśli chcesz działać tylko jako użytkownik GitHuba i robić wszystko, co może zrobić ten użytkownik.

  • Jeśli używasz swojej aplikacji z akcjami GitHub i chcesz modyfikować pliki workflow, musisz uwierzytelnić się w imieniu użytkownika za pomocą tokenu OAuth, który zawiera zakres workflow. Użytkownik musi mieć uprawnienia administratora lub zapisu do repozytorium, które zawiera plik workflow. Więcej informacji znajdziesz w artykule "Zrozumienie zakresów dla aplikacji OAuth."

  • Więcej informacji znajdziesz tutaj.

Akcje GitHub

To nie jest sposób uwierzytelniania w GitHubie, ale złośliwa akcja GitHub może uzyskać nieautoryzowany dostęp do GitHuba i w zależności od przyznanych uprawnień akcji można przeprowadzić różne ataki. Więcej informacji znajdziesz poniżej.

Akcje Git

Akcje Git umożliwiają automatyzację wykonywania kodu po wystąpieniu zdarzenia. Zazwyczaj wykonywany kod jest w jakiś sposób związany z kodem repozytorium (na przykład budowanie kontenera Docker lub sprawdzanie, czy PR nie zawiera poufnych informacji).

Konfiguracja

Na stronie https://github.com/organizations/<org_name>/settings/actions można sprawdzić konfigurację akcji GitHub dla organizacji.

Można całkowicie zablokować użycie akcji GitHub, zezwolić na wszystkie akcje GitHub lub po prostu zezwolić na określone akcje.

Można również skonfigurować, kto musi zatwierdzić uruchomienie akcji GitHub oraz uprawnienia tokenu GITHUB_TOKEN akcji GitHub podczas jej uruchamiania.

Sekrety Git

Akcje GitHub zazwyczaj wymagają pewnego rodzaju poufnych informacji do interakcji z GitHubem lub aplikacjami osób trzecich. Aby uniknąć umieszczania ich w tekście jawnym w repozytorium, GitHub umożliwia umieszczenie ich jako Sekrety.

Te sekrety można skonfigurować dla repozytorium lub dla całej organizacji. Następnie, aby akcja mogła uzyskać dostęp do sekretu, musisz go zadeklarować w następujący sposób:

steps:
- name: Hello world action
with: # Set the secret as an input
super_secret: ${{ secrets.SuperSecret }}
env: # Or as an environment variable
super_secret: ${{ secrets.SuperSecret }}

Przykład użycia Bash

steps:
- shell: bash
env:
SUPER_SECRET: ${{ secrets.SuperSecret }}
run: |
example-command "$SUPER_SECRET"

Tajemnice mogą być dostępne tylko z Github Actions, które je zadeklarowały.

Po skonfigurowaniu w repozytorium lub organizacji użytkownicy Github nie będą już miały do nich dostępu, będą mogli jedynie zmieniać je.

Dlatego jedynym sposobem na kradzież tajemnic Github jest zdobycie dostępu do maszyny, na której jest wykonywane Github Action (w takim scenariuszu będziesz mógł uzyskać dostęp tylko do tajemnic zadeklarowanych dla danej akcji).

Środowiska Git

Github umożliwia tworzenie środowisk, w których można przechowywać tajemnice. Następnie, można dać akcji Github dostęp do tajemnic wewnątrz środowiska za pomocą czegoś takiego jak:

jobs:
deployment:
runs-on: ubuntu-latest
environment: env_name

Można skonfigurować środowisko tak, aby było dostępne dla wszystkich gałęzi (domyślnie), tylko chronionych gałęzi lub określić, które gałęzie mają do niego dostęp. Można również ustawić liczbę wymaganych recenzji przed wykonaniem akcji przy użyciu środowiska lub oczekiwać pewnego czasu, zanim umożliwi się przeprowadzenie wdrożeń.

Git Action Runner

Akcja Github może być wykonana w środowisku githubowym lub może być wykonana w infrastrukturze osób trzecich skonfigurowanej przez użytkownika.

Wiele organizacji pozwoli na uruchamianie akcji Github w infrastrukturze osób trzecich, ponieważ jest to zazwyczaj tańsze.

Można wyświetlić listę hostowanych samodzielnie runnerów organizacji pod adresem https://github.com/organizations/<org_name>/settings/actions/runners

Sposobem na znalezienie, które Akcje Github są wykonywane w infrastrukturze niezwiązaną z Githubem, jest wyszukiwanie runs-on: self-hosted w konfiguracji yaml Akcji Github.

Nie jest możliwe uruchomienie Akcji Github organizacji w samodzielnie hostowanym kontenerze innej organizacji, ponieważ generowany jest unikalny token dla Runnera podczas jego konfiguracji, aby wiedzieć, do której organizacji należy.

Jeśli niestandardowy Runner Github 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.

Kompromitacja Git Action

Jeśli wszystkie akcje (lub złośliwa akcja) są dozwolone, użytkownik może użyć akcji Github, która jest złośliwa i skompromituje kontener, w którym jest wykonywana.

Złośliwa akcja Github może być wykorzystana przez atakującego do:

  • Ukradzenia wszystkich sekretów, do których akcja ma dostęp

  • Przesunięcia bocznego, jeśli akcja jest wykonywana w infrastrukturze osób trzecich, gdzie token SA używany do uruchomienia maszyny może być dostępny (prawdopodobnie za pośrednictwem usługi metadanych)

  • Wykorzystania tokenu używanego przez workflow do ukradzenia kodu repozytorium, w którym jest wykonywana akcja lub nawet jego modyfikacji.

Ochrona gałęzi

Ochrona gałęzi ma na celu nie dawanie użytkownikom pełnej kontroli nad repozytorium. Celem jest ustawienie kilku metod ochrony przed możliwością pisania kodu w niektórych gałęziach.

Ochrony gałęzi repozytorium można znaleźć pod adresem https://github.com/<orgname>/<reponame>/settings/branches

Nie jest możliwe ustawienie ochrony gałęzi na poziomie organizacji. Dlatego wszystkie zabezpieczenia muszą być zadeklarowane w każdym repozytorium.

Różne zabezpieczenia mogą być stosowane do gałęzi (np. do gałęzi master):

  • Można wymagać PR przed scaleniem (więc nie można bezpośrednio scalać kodu z gałęzi). Jeśli to jest wybrane, można zastosować różne inne zabezpieczenia:

  • Wymagać określonej liczby zatwierdzeń. Bardzo często wymaga się, aby 1 lub 2 inne osoby zatwierdziły PR, aby pojedynczy użytkownik nie mógł bezpośrednio scalać kodu.

  • Odrzucać zatwierdzenia, gdy są dodawane nowe commity. Jeśli tego nie zrobić, użytkownik może zatwierdzić prawidłowy kod, a następnie dodać złośliwy kod i scalić go.

  • Wymagać recenzji od właścicieli kodu. Przynajmniej 1 właściciel kodu repozytorium musi zatwierdzić PR (aby "losowi" użytkownicy nie mogli go zatwierdzić)

  • Ograniczyć, kto może odrzucać recenzje żądania pull. Można określić osoby lub zespoły uprawnione do odrzucania recenzji żądań pull.

  • Zezwolić określonym podmiotom na pominięcie wymagań żądania pull. Użytkownicy ci będą mogli ominąć wcześniejsze ograniczenia.

  • Wymagać zaliczenia sprawdzeń stanu przed scaleniem. Niektóre sprawdzenia muszą zaliczyć przed możliwością scalenia commita (np. sprawdzenie github action, czy nie ma żadnych jawnych sekretów).

  • Wymagać rozwiązania rozmowy przed scaleniem. Wszystkie komentarze dotyczące kodu muszą być rozwiązane przed scaleniem PR.

  • Wymagać podpisanych commitów. Commity muszą być podpisane.

  • Wymagać liniowej historii. Zapobiega przesyłaniu commitów scalenia do pasujących gałęzi.

  • Uwzględnij administratorów. Jeśli tego nie ustawisz, administratorzy mogą ominąć ograniczenia.

  • Ograniczyć, 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ć pewne poświadczenia użytkownika, repozytoria mogą być chronione, uniemożliwiając Ci przesyłanie kodu do gałęzi master, na przykład w celu skompromitowania procesu CI/CD.

Odwołania

Naucz się hakować AWS od zera do bohatera z htARTE (HackTricks AWS Red Team Expert)!

Inne sposoby wsparcia HackTricks:

PreviousGh Actions - Context Script InjectionsNextGitea Security

Last updated