Polish - Ht Cloud
HackTricks TrainingTwitterLinkedinSponsor

Basic Github Information

Wsparcie dla HackTricks

Podstawowa struktura

Podstawowa struktura środowiska github dużej firmy 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 ich ramach 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.

Uprawnienia

Role w przedsiębiorstwie

  • 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ć politykę 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.

Role w 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ż dla dwóch osób w twojej organizacji.

  • Członkowie organizacji: Domyślną, nieadministracyjną rolą dla osób w organizacji jest 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

Uprawnienia członków

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 do repozytoriów.

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

Role w repozytorium

Domyślnie tworzone są role w repozytorium:

  • Odczyt: Zalecane dla niekodujących 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 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ż utworzyć własne role w https://github.com/organizations/<org_name>/settings/roles

Zespoły

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

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.

Uwierzytelnianie Github

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

Dostęp przez sieć

Uzyskując dostęp do github.com, możesz zalogować się używając swojego nazwa użytkownika i hasło (oraz potencjalnie 2FA).

Klucze SSH

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

Klucze GPG

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.

Tokeny dostępu osobistego

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

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.

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żytkownika) 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 OAuth 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 do użycia, a następnie opuści firmę, nikt inny nie będzie miał do niej dostępu.

  • Więcej w tutaj.

Aplikacje Github

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ń na określonych zasobach. W aplikacjach Github musisz określić repozytoria, do których aplikacja będzie miała dostęp.

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żywać tokenów dostępu, które wygasają 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żywać 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 w tutaj.

Github Actions

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łoby dojść do kilku różnych ataków. Zobacz poniżej więcej informacji.

Akcje Git

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

Konfiguracja

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.

Sekrety Git

Akcje Github zazwyczaj potrzebują jakiegoś rodzaju sekretów do interakcji z githubem lub aplikacjami stron trzecich. Aby uniknąć umieszczania ich w postaci czystego tekstu 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 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"

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 tylko 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).

Git Environments

Github pozwala na tworzenie środowisk, w których możesz przechowywać sekrety. Następnie możesz dać akcji githuba dostęp do sekretów w środowisku za pomocą czegoś takiego:

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

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

Git Action Runner

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

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.

Git Action Compromise

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 przez usługę 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

Ochrona gałęzi jest zaprojektowana, aby nie dawać 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 w kodzie 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.

Odniesienia

Wsparcie HackTricks
PreviousAccessible Deleted Data in GithubNextGitea Security

Last updated