Podstawowe informacje o Github

Tip

Ucz się & ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się & ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się & ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Wspieraj HackTricks

Podstawowa struktura

Podstawowa struktura środowiska github w dużej firmie polega na posiadaniu enterprise, które posiada kilka organizacji, a każda z nich może zawierać wiele repozytoriów i kilka zespołów. Mniejsze firmy mogą posiadać tylko jedną organizację i brak enterprise.

Z punktu widzenia użytkownika user może być członkiem różnych enterprise i organizacji. W ich obrębie użytkownik może mieć różne role na poziomie enterprise, organizacji i repozytorium.

Ponadto użytkownik może być członkiem różnych zespołów z różnymi rolami na poziomie enterprise, organizacji lub repozytorium.

I wreszcie repozytoria mogą mieć specjalne mechanizmy ochronne.

Uprawnienia

Enterprise Roles

  • Enterprise owner: Osoby z tą rolą mogą zarządzać administratorami, zarządzać organizacjami w ramach enterprise, zarządzać ustawieniami enterprise, egzekwować zasady w organizacjach. Jednak nie mają dostępu do ustawień ani treści organizacji, chyba że zostaną uczynione właścicielem organizacji lub otrzymają bezpośredni dostęp do repozytorium należącego do organizacji.
  • Enterprise members: Członkowie organizacji należących do twojego enterprise są również automatycznie członkami enterprise.

Organization Roles

W organizacji użytkownicy mogą mieć różne role:

  • Organization owners: Właściciele organizacji mają pełny dostęp administracyjny do organizacji. Tę rolę należy ograniczyć, ale nie powinno być jej mniej niż u dwóch osób w organizacji.
  • Organization members: Domyślna, nieadministracyjna rola dla osób w organizacji to członek organizacji. Domyślnie członkowie organizacji mają określone uprawnienia.
  • Billing managers: Billing managers to użytkownicy, którzy mogą zarządzać ustawieniami rozliczeń organizacji, takimi jak informacje o płatnościach.
  • Security Managers: To rola, którą właściciele organizacji mogą przydzielić dowolnemu zespołowi w organizacji. Po zastosowaniu daje każdemu członkowi zespołu uprawnienia do zarządzania alertami i ustawieniami bezpieczeństwa w całej organizacji oraz uprawnienia do odczytu wszystkich repozytoriów w organizacji.
  • Jeśli twoja organizacja ma zespół ds. bezpieczeństwa, możesz użyć roli security manager, aby dać członkom zespołu minimalny potrzebny dostęp do organizacji.
  • Github App managers: Aby umożliwić dodatkowym użytkownikom zarządzanie GitHub Apps należącymi do organizacji, właściciel może przyznać im uprawnienia Github App manager.
  • Outside collaborators: Outside collaborator to osoba, która ma dostęp do jednego lub więcej repozytoriów organizacji, ale nie jest formalnie 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, które użytkownicy będą mieć tylko z tytułu bycia częścią organizacji.

Ustawienia tu skonfigurowane określają następujące uprawnienia członków organizacji:

  • Być adminem, writerem, readerem lub nie mieć żadnych uprawnień do wszystkich repozytoriów organizacji.
  • Czy członkowie mogą tworzyć prywatne, wewnętrzne lub publiczne repozytoria.
  • Czy możliwe jest forking repozytoriów.
  • Czy możliwe jest zapraszanie outside collaborators.
  • Czy publiczne lub prywatne strony mogą być publikowane.
  • Uprawnienia, jakie mają admini względem repozytoriów.
  • Czy członkowie mogą tworzyć nowe zespoły.

Role w repozytorium

Domyślnie tworzone są role w repozytorium:

  • Read: Zalecane dla współpracowników niepiszących kodu, którzy chcą przeglądać lub omawiać projekt.
  • Triage: Zalecane dla współpracowników, którzy muszą proaktywnie zarządzać issues i pull requestami bez dostępu do zapisu.
  • Write: Zalecane dla współpracowników, którzy aktywnie pushują do projektu.
  • Maintain: Zalecane dla kierowników projektu, którzy muszą zarządzać repozytorium bez dostępu do wrażliwych lub destrukcyjnych działań.
  • Admin: 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 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 także stworzyć własne role w https://github.com/organizations/<org_name>/settings/roles

Teams

Możesz wypisać zespoły utworzone w organizacji w https://github.com/orgs/<org_name>/teams. Zauważ, że aby zobaczyć zespoły będące dziećmi innych zespołów, musisz wejść do każdego zespołu nadrzędnego.

Użytkownicy

Użytkowników organizacji można wypisać w https://github.com/orgs/<org_name>/people.

W informacjach o każdym użytkowniku możesz zobaczyć zespoły, których jest członkiem, oraz repozytoria, do których ma dostęp.

Github Authentication

Github oferuje różne sposoby uwierzytelniania się do konta i wykonywania działań w twoim imieniu.

Web Access

Dostęp do github.com pozwala zalogować się przy użyciu nazwy użytkownika i hasła (oraz potencjalnie 2FA).

SSH Keys

Możesz skonfigurować swoje konto z jednym lub kilkoma kluczami publicznymi, pozwalającymi odpowiedniemu kluczowi prywatnemu wykonywać działania w twoim imieniu. https://github.com/settings/keys

GPG Keys

Nie możesz się podszyć pod użytkownika za pomocą tych kluczy, jednak jeśli ich nie używasz, możliwe jest, że zostaniesz wykryty za wysyłanie commitów bez podpisu. Dowiedz się więcej o vigilant mode tutaj.

Personal Access Tokens

Możesz wygenerować personal access token, aby dać aplikacji dostęp do twojego konta. Podczas tworzenia personal access token użytkownik musi określić uprawnienia, jakie token będzie posiadać. https://github.com/settings/tokens

Oauth Applications

Oauth applications mogą poprosić o uprawnienia do dostępu do części twoich informacji na github lub do podszywania się pod ciebie w celu wykonania pewnych działań. Powszechnym przykładem tej funkcji jest przycisk login with github, który możesz znaleźć na niektórych platformach.

Kilka rekomendacji bezpieczeństwa:

  • A OAuth App powinna zawsze działać jako uwierzytelniony użytkownik GitHub w całym GitHub (na przykład podczas dostarczania powiadomień użytkownikowi) i mieć dostęp tylko do określonych scope’ów.
  • OAuth App może być użyta jako dostawca tożsamości, umożliwiając “Login with GitHub” dla uwierzytelnionego użytkownika.
  • Nie twórz OAuth App, jeśli chcesz, aby twoja aplikacja działała tylko na jednym repozytorium. Z zakresem repo, OAuth Apps mogą działać na wszystkich repozytoriach uwierzytelnionego użytkownika.
  • Nie twórz OAuth App, aby działała jako aplikacja dla twojego zespołu lub firmy. OAuth Apps uwierzytelniają się jako pojedynczy użytkownik, więc jeśli jedna osoba stworzy OAuth App dla firmy i potem odejdzie, nikt inny nie będzie miał do niej dostępu.
  • Więcej informacji tutaj.

Github Applications

Github applications mogą prosić o uprawnienia do dostępu do twoich informacji na github lub podszywania się pod ciebie w celu wykonywania określonych działań na konkretnych zasobach. W Github Apps musisz określić repozytoria, do których aplikacja będzie miała dostęp.

Kilka zaleceń bezpieczeństwa:

  • GitHub App powinien wykonywać działania niezależne od użytkownika (chyba że aplikacja używa user-to-server tokena). Aby zabezpieczyć tokeny dostępu user-to-server, możesz użyć tokenów dostępu, które wygasają po 8 godzinach, oraz refresh tokena, który można wymienić na nowy token dostępu. Aby uzyskać więcej informacji, zobacz “Refreshing user-to-server access tokens.”
  • Upewnij się, że GitHub App integruje się z konkretnymi repozytoriami.
  • GitHub App powinien łączyć się z kontem osobistym lub organizacją.
  • Nie oczekuj, że GitHub App będzie wiedział i robił wszystko, co użytkownik potrafi.
  • Nie używaj GitHub App, jeśli potrzebujesz tylko usługi “Login with GitHub”. Jednak GitHub App może używać user identification flow do logowania użytkowników i wykonywania innych działań.
  • Nie twórz GitHub App 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 workflow, musisz uwierzytelnić się w imieniu użytkownika za pomocą tokena OAuth zawierającego scope workflow. Użytkownik musi mieć uprawnienia admin lub write do repozytorium, które zawiera plik workflow. Aby uzyskać więcej informacji, zobacz “Understanding scopes for OAuth apps.”
  • Więcej informacji tutaj.

Github Actions

To nie jest sposób uwierzytelniania w github, ale złośliwe Github Action może uzyskać nieautoryzowany dostęp do github i w zależności od uprawnień przyznanych Action może zostać przeprowadzonych kilka różnych ataków. Zobacz poniżej więcej informacji.

Git Actions

Git actions pozwalają automatyzować wykonywanie kodu, gdy zdarzenie ma miejsce. Zazwyczaj wykonywany kod jest jakoś powiązany z kodem repozytorium (np. budowanie obrazu docker lub sprawdzenie, czy PR nie zawiera sekretów).

Konfiguracja

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

Można całkowicie zablokować użycie github actions, zezwolić na wszystkie github actions, lub zezwolić tylko na określone actions.

Można też skonfigurować kto wymaga zatwierdzenia do uruchamiania Github Action oraz uprawnienia GITHUB_TOKEN Github Action podczas jego uruchomienia.

Git Secrets

Github Action zwykle potrzebują jakiegoś rodzaju sekretów do interakcji z github lub aplikacjami stron trzecich. Aby uniknąć umieszczania ich w postaci jawnym w repo, github pozwala umieścić je jako Secrets.

Te sekrety mogą być skonfigurowane dla repo lub dla całej organizacji. Następnie, aby Action mogła uzyskać dostęp do secretu, musisz zadeklarować go w taki 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"

Warning

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

Po skonfigurowaniu w repo lub w organizations users of github nie będą już mieli do nich dostępu, będą mogli jedynie je zmieniać.

W związku z tym jedynym sposobem na kradzież github secrets jest uzyskanie dostępu do maszyny, która wykonuje Github Action (w takim scenariuszu będziesz mieć dostęp tylko do secrets zadeklarowanych dla tej Action).

Git Environments

Github pozwala tworzyć environments, w których możesz zapisać secrets. Następnie możesz dać github action dostęp do secrets znajdujących się w environment za pomocą czegoś takiego:

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

Możesz skonfigurować environment tak, aby był dostępny dla wszystkich branches (domyślnie), tylko chronionych branches lub określić, które branches mogą mieć do niego dostęp.
Dodatkowo, zabezpieczenia environment obejmują:

  • Required reviewers: blokują joby kierujące deploy do environment aż do momentu zatwierdzenia. Włącz Prevent self-review, aby wymusić zasadę czterech oczu przy samym zatwierdzeniu.
  • Deployment branches and tags: ograniczają, które branches/tags mogą deployować do environment. Preferuj wybór konkretnych branches/tags i upewnij się, że te branches są chronione. Uwaga: opcja “Protected branches only” odnosi się do klasycznych protections dla branchy i może nie działać zgodnie z oczekiwaniami, jeśli używasz rulesets.
  • Wait timer: opóźnia deploymenty o konfigurowalny czas.

Można też ustawić liczbę wymaganych reviewów przed wykonaniem action wykorzystującej environment lub poczekać pewien czas zanim deploymenty będą mogły kontynuować.

Git Action Runner

A Github Action może być wykonywana wewnątrz github environment lub może być wykonywana w infrastruktury third party skonfigurowanej przez użytkownika.

Wiele organizacji pozwala uruchamiać Github Actions w infrastrukturze third party, ponieważ bywa to tańsze.

Możesz wypisać self-hosted runners organizacji pod adresem https://github.com/organizations/<org_name>/settings/actions/runners

Sposób, by znaleźć które Github Actions są uruchamiane w non-github infrastruktury, to wyszukać runs-on: self-hosted w konfiguracji yaml Github Action.

Nie jest możliwe uruchomienie Github Action organizacji wewnątrz self hosted box innej organizacji, ponieważ unikalny token jest generowany dla Runnera podczas jego konfiguracji, aby wiedzieć, do kogo runner należy.

Jeśli custom Github Runner jest skonfigurowany na maszynie w AWS lub GCP, na przykład, Action może mieć dostęp do metadata endpoint i ukraść token service account, z którego maszyna korzysta.

Git Action Compromise

Jeśli wszystkie actions (lub złośliwa action) są dozwolone, użytkownik mógłby użyć złośliwej Github Action, która skompromentuje container, w którym jest wykonywana.

Caution

A złośliwa Github Action uruchomiona może zostać wykorzystana przez atakującego do:

  • Ukradzenia wszystkich secrets, do których Action ma dostęp
  • Poruszania się lateralnie, jeżeli Action jest uruchamiana w infrastrukturze third party, gdzie SA token użyty do uruchomienia maszyny może być dostępny (prawdopodobnie przez metadata service)
  • Nadużycia tokena używanego przez workflow, aby ukraść kod repo, w którym Action jest uruchomiona lub nawet go zmodyfikować.

Branch Protections

Branch protections są zaprojektowane, aby nie dawać pełnej kontroli nad repo użytkownikom. Celem jest umieszczenie wielu mechanizmów ochronnych zanim będzie można wpisać kod do danego branch.

Branch protections repo można znaleźć pod adresem https://github.com/<orgname>/<reponame>/settings/branches

Note

Nie jest możliwe ustawienie branch protection na poziomie organizacji. Wszystkie muszą być zadeklarowane w każdym repo.

Różne zabezpieczenia mogą być zastosowane do branch (np. master):

  • Możesz wymagać PR przed merge (tak, aby nie można było bezpośrednio merge’ować kodu do branch). Jeśli to jest wybrane, mogą być aktywne inne zabezpieczenia:
  • Wymagaj liczby zatwierdzeń. Często wymaga się 1 lub 2 dodatkowych osób do zatwierdzenia PR, żeby pojedynczy użytkownik nie mógł bezpośrednio scalć kodu.
  • Odrzucaj zatwierdzenia gdy pushowane są nowe commity. W przeciwnym razie użytkownik może zatwierdzić legitny kod, a następnie dodać złośliwy kod i zmerge’ować go.
  • Require approval of the most recent reviewable push. Zapewnia, że jakiekolwiek nowe commity po zatwierdzeniu (w tym pushy od innych współpracowników) ponownie wyzwalają review, więc atakujący nie może dopchać zmian po zatwierdzeniu i scalić.
  • Wymagaj zatwierdzeń od Code Owners. Co najmniej 1 code owner repo musi zatwierdzić PR (więc „losowi” użytkownicy nie mogą go zatwierdzić).
  • Ogranicz kto może dismissować pull request reviews. Możesz określić osoby lub zespoły uprawnione do odrzucania review.
  • Pozwól wskazanym actorom na obejście wymagań pull request. Ci użytkownicy będą mogli obejść poprzednie ograniczenia.
  • Wymagaj przejścia status checks przed merge. Niektóre checks muszą przejść przed możliwością merge (np. GitHub App raportujący wyniki SAST). Wskazówka: przypnij wymagane checks do konkretnego GitHub App; w przeciwnym razie dowolna aplikacja może sfałszować check przez Checks API, a wiele botów akceptuje dyrektywy skip (np. “@bot-name skip”).
  • Wymagaj rozwiązania konwersacji przed merge. Wszystkie komentarze w kodzie muszą być rozwiązane zanim PR może zostać scalony.
  • Wymagaj podpisanych commitów. Commity muszą być podpisane.
  • Wymagaj linear history. Zapobiega pushowaniu merge commitów do pasujących branchy.
  • Include administrators. Jeśli to nie jest ustawione, administratorzy mogą obejść ograniczenia.
  • Ogranicz kto może pushować do pasujących branchy. Ogranicz kto może wysyłać PR.

Note

Jak widać, nawet jeśli uda Ci się uzyskać poświadczenia użytkownika, repo może być chronione i uniemożliwić Ci push kodu do master, na przykład, by skompromitować pipeline CI/CD.

Tag Protections

Tags (np. latest, stable) są domyślnie mutowalne. Aby wymusić przepływ czterech oczu przy aktualizacjach tagów, chroń tagi i powiąż zabezpieczenia przez environments i branchy:

  1. W regule ochrony tagu włącz Require deployments to succeed i wymagaj udanego deploymentu do chronionego environment (np. prod).
  2. W docelowym environment ogranicz Deployment branches and tags do release branch (np. main) i opcjonalnie skonfiguruj Required reviewers z Prevent self-review.
  3. Na branchu release skonfiguruj branch protections, aby Require a pull request, ustaw approvals ≥ 1 oraz włącz zarówno Dismiss approvals when new commits are pushed, jak i Require approval of the most recent reviewable push.

Taki łańcuch uniemożliwia jednemu współpracownikowi przetagowanie lub siłowe opublikowanie release’ów przez edycję workflow YAML, ponieważ bramki deploymentu są egzekwowane poza workflow.

References

Tip

Ucz się & ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się & ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się & ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Wspieraj HackTricks