Polish - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

Github Security

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

Inne sposoby wsparcia HackTricks:

Co to jest Github

(Z tutaj) Na wysokim poziomie GitHub to strona internetowa i usługa w chmurze, która pomaga programistom przechowywać i zarządzać swoim kodem, a także śledzić i kontrolować zmiany w swoim kodzie.

Podstawowe informacje

pageBasic Github Information

Zewnętrzne Rozpoznanie

Repozytoria Github mogą być skonfigurowane jako publiczne, prywatne i wewnętrzne.

  • Prywatne oznacza, że tylko osoby z organizacji będą miały do nich dostęp

  • Wewnętrzne oznacza, że tylko osoby z przedsiębiorstwa (przedsiębiorstwo może mieć kilka organizacji) będą miały do niego dostęp

  • Publiczne oznacza, że cały internet będzie mógł do niego uzyskać dostęp.

W przypadku, gdy znasz użytkownika, repozytorium lub organizację, którą chcesz zaatakować, możesz użyć dorków Github do znalezienia poufnych informacji lub wyszukiwania wycieków poufnych informacji w każdym repozytorium.

Dorki Github

Github pozwala na wyszukiwanie czegoś, określając zakres użytkownika, repozytorium lub organizacji. Dlatego, mając listę ciągów, które pojawią się w pobliżu poufnych informacji, łatwo możesz szukać potencjalnych poufnych informacji w swoim celu.

Narzędzia (każde narzędzie zawiera swoją listę dorków):

Wycieki Github

Zauważ, że dorki Github są również przeznaczone do wyszukiwania wycieków za pomocą opcji wyszukiwania w Githubie. Ta sekcja jest poświęcona narzędziom, które pobiorą każde repozytorium i wyszukają w nich poufne informacje (nawet sprawdzając określoną głębokość commitów).

Narzędzia (każde narzędzie zawiera swoją listę wyrażeń regularnych):

Gdy szukasz wycieków w repozytorium i uruchamiasz coś w stylu git log -p, nie zapomnij, że mogą istnieć inne gałęzie z innymi commitami zawierającymi tajemnice!

Zewnętrzne Forki

Możliwe jest skompromitowanie repozytoriów, nadużywając żądań ściągnięcia. Aby dowiedzieć się, czy repozytorium jest podatne, głównie musisz przeczytać konfiguracje yaml Github Actions. Więcej informacji poniżej.

Zabezpieczenia Organizacji

Uprawnienia Członków

Istnieją pewne domyślne uprawnienia, które można przypisać członkom organizacji. Można nimi zarządzać ze strony https://github.com/organizations/<org_name>/settings/member_privileges lub za pomocą API organizacji.

  • Podstawowe uprawnienia: Członkowie będą mieć uprawnienia Brak/Odczyt/Zapis/Admin nad repozytoriami organizacji. Zalecane jest Brak lub Odczyt.

  • Tworzenie forków repozytoriów: Jeśli nie jest to konieczne, lepiej nie zezwalać członkom na tworzenie forków repozytoriów organizacji.

  • Tworzenie stron: Jeśli nie jest to konieczne, lepiej nie zezwalać członkom na publikowanie stron z repozytoriów organizacji. Jeśli konieczne, można zezwolić na tworzenie stron publicznych lub prywatnych.

  • Żądania dostępu do integracji: Dzięki temu zezwoleniu zewnętrzni współpracownicy będą mogli żądać dostępu dla aplikacji GitHub lub OAuth do dostępu do tej organizacji i jej zasobów. Zazwyczaj jest to konieczne, ale jeśli nie, lepiej to wyłączyć.

  • Nie mogłem znaleźć tej informacji w odpowiedziach API, udostępnij, jeśli znajdziesz

  • Zmiana widoczności repozytorium: Jeśli jest włączone, członkowie z uprawnieniami admina dla repozytorium będą mogli zmieniać jego widoczność. Jeśli jest wyłączone, tylko właściciele organizacji mogą zmieniać widoczność repozytoriów. Jeśli nie chcesz, aby ludzie robili rzeczy publiczne, upewnij się, że to jest wyłączone.

  • Nie mogłem znaleźć tej informacji w odpowiedziach API, udostępnij, jeśli znajdziesz

  • Usuwanie i przenoszenie repozytoriów: Jeśli jest włączone, członkowie z uprawnieniami admina dla repozytorium będą mogli usunąć lub przenieść publiczne i prywatne repozytoria.

  • Nie mogłem znaleźć tej informacji w odpowiedziach API, udostępnij, jeśli znajdziesz

  • Zezwalanie członkom na tworzenie zespołów: Jeśli jest włączone, każdy członek organizacji będzie mógł tworzyć nowe zespoły. Jeśli jest wyłączone, tylko właściciele organizacji mogą tworzyć nowe zespoły. Lepiej mieć to wyłączone.

  • Nie mogłem znaleźć tej informacji w odpowiedziach API, udostępnij, jeśli znajdziesz

  • Więcej rzeczy można skonfigurować na tej stronie, ale powyższe są najbardziej związane z bezpieczeństwem.

Ustawienia Akcji

Na stronie https://github.com/organizations/<org_name>/settings/actions można skonfigurować kilka ustawień związanych z bezpieczeństwem akcji.

Zauważ, że wszystkie te konfiguracje można również ustawić niezależnie dla każdego repozytorium

  • Zasady akcji Github: Pozwala określić, które repozytoria mogą uruchamiać przepływy pracy i które przepływy pracy powinny być dozwolone. Zaleca się określenie, które repozytoria powinny być dozwolone, a nie zezwalanie na uruchamianie wszystkich akcji.

  • API-1, API-2

  • Uruchamianie przepływów pracy z żądań ściągnięcia forków od zewnętrznych współpracowników: Zaleca się wymaganie zatwierdzenia dla wszystkich zewnętrznych współpracowników.

  • Nie znalazłem API z tą informacją, udostępnij, jeśli znajdziesz

  • Uruchamianie przepływów pracy z żądań ściągnięcia forków: Zdecydowanie odradza się uruchamianie przepływów pracy z żądań ściągnięcia, ponieważ utrzymujący oryginalnego forka będą mieli możliwość korzystania z tokenów z uprawnieniami do odczytu w repozytorium źródłowym.

  • Nie znalazłem API z tą informacją, udostępnij, jeśli znajdziesz

  • Uprawnienia przepływu pracy: Zdecydowanie zaleca się udzielenie uprawnień tylko do odczytu repozytorium. Odradza się udzielanie uprawnień do zapisu i tworzenia/zatwierdzania żądań ściągnięcia, aby uniknąć nadużyć tokena GITHUB_TOKEN udzielonego do uruchamiania przepływów pracy.

  • API

Integracje

Powiedz mi, jeśli znasz punkt końcowy API do uzyskania tych informacji!

  • Polityka dostępu do aplikacji innych firm: Zaleca się ograniczenie dostępu do każdej aplikacji i zezwolenie tylko na te, które są potrzebne (po ich przeglądzie).

  • Zainstalowane aplikacje GitHub: Zaleca się zezwolenie tylko na te, które są potrzebne (po ich przeglądzie).

Rozpoznanie i ataki wykorzystujące poświadczenia

W tym scenariuszu załóżmy, że uzyskałeś dostęp do konta na GitHubie.

Z poświadczeniami użytkownika

Jeśli w jakiś sposób już masz poświadczenia dla użytkownika wewnątrz organizacji, możesz po prostu się zalogować i sprawdzić, jakie role przedsiębiorstwa i organizacji posiadasz, jeśli jesteś zwykłym członkiem, sprawdź, jakie uprawnienia mają zwykli członkowie, w jakich grupach się znajdujesz, jakie uprawnienia posiadasz w stosunku do repozytoriów i jak są chronione repozytoria.

Zauważ, że może być używane 2FA, więc będziesz mógł uzyskać dostęp do tych informacji tylko wtedy, gdy będziesz mógł przejść tę weryfikację.

Zauważ, że jeśli uda ci się ukraść ciasteczko user_session (obecnie skonfigurowane z SameSite: Lax), możesz całkowicie podszyć się pod użytkownika bez konieczności posiadania poświadczeń ani 2FA.

Sprawdź sekcję poniżej dotyczącą obejścia zabezpieczeń gałęzi, jeśli jest to przydatne.

Z kluczem SSH użytkownika

Github pozwala użytkownikom ustawić klucze SSH, które będą używane jako metoda uwierzytelniania do wdrażania kodu w ich imieniu (nie stosuje się 2FA).

Z tym kluczem możesz dokonywać zmian w repozytoriach, w których użytkownik ma pewne uprawnienia, jednak nie możesz go użyć do dostępu do interfejsu API GitHuba w celu wyliczenia środowiska. Możesz jednak wyliczyć lokalne ustawienia, aby uzyskać informacje o repozytoriach i użytkowniku, do których masz dostęp:

# Go to the the repository folder
# Get repo config and current user name and email
git config --list

Jeśli użytkownik skonfigurował swoją nazwę użytkownika jako swoją nazwę użytkownika na GitHubie, możesz uzyskać dostęp do kluczy publicznych, które ustawił w swoim koncie pod adresem https://github.com/<nazwa_użytkownika_githuba>.keys, możesz to sprawdzić, aby potwierdzić, czy znaleziony klucz prywatny może być użyty.

Klucze SSH mogą również być ustawione w repozytoriach jako klucze deploy. Każdy mający dostęp do tego klucza będzie w stanie uruchamiać projekty z repozytorium. Zazwyczaj na serwerze z różnymi kluczami deploy plik lokalny ~/.ssh/config dostarczy informacje o powiązanym kluczu.

Klucze GPG

Jak wyjaśniono tutaj czasami konieczne jest podpisanie commitów lub możesz zostać odkryty.

Sprawdź lokalnie, czy bieżący użytkownik ma jakiś klucz za pomocą:

gpg --list-secret-keys --keyid-format=long

Z Użytkownikiem Token

Dla wprowadzenia na temat Tokenów Użytkownika sprawdź podstawowe informacje.

Token użytkownika może być używany zamiast hasła do Git przez HTTPS, lub może być używany do uwierzytelniania w API za pomocą uwierzytelniania podstawowego. W zależności od przyznanych uprawnień, możesz wykonywać różne akcje.

Token użytkownika wygląda tak: ghp_EfHnQFcFHX6fGIu5mpduvRiYR584kK0dX123

Z Aplikacją Oauth

Dla wprowadzenia na temat Aplikacji Github Oauth sprawdź podstawowe informacje.

Atakujący może stworzyć złośliwą Aplikację Oauth w celu uzyskania dostępu do poufnych danych/akcji użytkowników, którzy najprawdopodobniej akceptują je jako część kampanii phishingowej.

Oto zakresy, które aplikacja Oauth może żądać. Zawsze należy sprawdzić żądane zakresy przed ich akceptacją.

Co więcej, jak wyjaśniono w podstawowych informacjach, organizacje mogą udzielać/odmawiać dostępu aplikacjom zewnętrznym do informacji/repozytoriów/akcji związanych z organizacją.

Z Aplikacją Github

Dla wprowadzenia na temat Aplikacji Github sprawdź podstawowe informacje.

Atakujący może stworzyć złośliwą Aplikację Github w celu uzyskania dostępu do poufnych danych/akcji użytkowników, którzy najprawdopodobniej akceptują je jako część kampanii phishingowej.

Co więcej, jak wyjaśniono w podstawowych informacjach, organizacje mogą udzielać/odmawiać dostępu aplikacjom zewnętrznym do informacji/repozytoriów/akcji związanych z organizacją.

Kompromitacja i Nadużycie Akcji Github

Istnieje kilka technik kompromitacji i nadużycia Akcji Github, sprawdź je tutaj:

pageAbusing Github Actions

Ominięcie Ochrony Gałęzi

  • Wymagaj określonej liczby zatwierdzeń: Jeśli skompromitowałeś kilka kont, możesz zaakceptować swoje PR z innych kont. Jeśli masz dostęp do środowiska Github Action wewnątrz repozytorium, używając GITHUB_TOKEN możesz zaakceptować swój PR i uzyskać w ten sposób 1 zatwierdzenie.

  • Uwaga dotycząca tego i ograniczenia Właścicieli Kodu, że zazwyczaj użytkownik nie będzie mógł zatwierdzić swoich własnych PR, ale jeśli tak, możesz to nadużyć, aby zaakceptować swoje PR.

  • Odrzuć zatwierdzenia po dodaniu nowych commitów: Jeśli to nie jest ustawione, możesz przesłać prawidłowy kod, poczekać, aż ktoś go zatwierdzi, dodać złośliwy kod i scalić go z chronioną gałęzią.

  • Wymagaj recenzji od Właścicieli Kodu: Jeśli to jest aktywowane, a jesteś Właścicielem Kodu, możesz sprawić, że Github Action stworzy Twój PR, a następnie zaakceptujesz go samodzielnie.

  • Gdy plik CODEOWNER jest źle skonfigurowany, Github nie zgłasza błędu, ale go nie używa. Dlatego jeśli jest źle skonfigurowany, ochrona Właścicieli Kodu nie jest stosowana.

  • Zezwalaj określonym podmiotom na ominięcie wymagań dotyczących pull requestów: Jeśli jesteś jednym z tych podmiotów, możesz ominąć zabezpieczenia dotyczące pull requestów.

  • Uwzględnij administratorów: Jeśli to nie jest ustawione, a jesteś administratorem repozytorium, możesz ominąć te zabezpieczenia gałęzi.

  • Porwanie PR: Możesz być w stanie zmodyfikować PR kogoś innego, dodając złośliwy kod, zatwierdzając wynikowy PR i scalając wszystko.

  • Usuwanie Ochrony Gałęzi: Jeśli jesteś administratorem repozytorium, możesz wyłączyć zabezpieczenia, scalić swój PR i ponownie ustawić zabezpieczenia.

  • Ominięcie zabezpieczeń push: Jeśli repozytorium pozwala tylko określonym użytkownikom na wysyłanie push (scalanie kodu) w gałęziach (ochrona gałęzi może chronić wszystkie gałęzie, określając symbol wieloznaczny *).

  • Jeśli masz dostęp do zapisu w repozytorium, ale nie możesz przesłać kodu z powodu ochrony gałęzi, nadal możesz utworzyć nową gałąź i w niej utworzyć akcję github, która jest wyzwalana po przesłaniu kodu. Ponieważ ochrona gałęzi nie będzie chronić gałęzi do momentu jej utworzenia, pierwsze przesłanie kodu do gałęzi uruchomi akcję github.

Ominięcie Ochrony Środowisk

Dla wprowadzenia na temat Środowiska Github sprawdź podstawowe informacje.

W przypadku, gdy środowisko może być dostępne ze wszystkich gałęzi, nie jest chronione i możesz łatwo uzyskać dostęp do poufnych informacji wewnątrz środowiska. Zauważ, że możesz znaleźć repozytoria, gdzie wszystkie gałęzie są chronione (poprzez określenie ich nazw lub za pomocą *), w takim przypadku, znajdź gałąź, do której możesz przesłać kod i możesz wydobyć poufne informacje, tworząc nową akcję github (lub modyfikując jedną).

Zauważ, że możesz natrafić na skrajny przypadek, gdzie wszystkie gałęzie są chronione (za pomocą symbolu wieloznacznego *), określono kto może przesyłać kod do gałęzi (możesz to określić w ochronie gałęzi) i Twój użytkownik nie jest do tego uprawniony. Nadal możesz uruchomić niestandardową akcję github, ponieważ możesz utworzyć gałąź i użyć wyzwalacza push na niej. Ochrona gałęzi pozwala na przesłanie do nowej gałęzi, więc akcja github zostanie uruchomiona.

push: # Run it when a push is made to a branch
branches:
- current_branch_name #Use '**' to run when a push is made to any branch

Zauważ, że po utworzeniu gałęzi ochrona gałęzi zostanie zastosowana do nowej gałęzi i nie będziesz mógł jej modyfikować, ale do tego czasu już zdążyłeś wyciec tajemnice.

Trwałość

  • Wygeneruj token użytkownika

  • Ukradnij tokeny Githuba z sekretów

  • Usunięcie wyników i gałęzi workflow

  • Nadaj więcej uprawnień wszystkim organizacjom

  • Utwórz webhooki do wycieku informacji

  • Zaproś zewnętrznych współpracowników

  • Usuń webhooki używane przez SIEM

  • Utwórz/zmodyfikuj Akcję Githuba z tylnymi drzwiami

  • Znajdź narażoną Akcję Githuba na wstrzyknięcie poleceń poprzez modyfikację wartości sekretnej

Fałszywe Commity - Tylna furtka poprzez commity repozytorium

W Githubie jest możliwe utworzenie PR do repozytorium z forka. Nawet jeśli PR nie zostanie zaakceptowany, identyfikator commita wewnątrz oryginalnego repozytorium zostanie utworzony dla wersji kodu z forka. Dlatego atakujący mógłby przypiąć użycie określonego commita z pozornie legalnego repozytorium, które nie zostało utworzone przez właściciela repozytorium.

Podobnie jak tutaj:

name: example
on: [push]
jobs:
commit:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@c7d749a2d57b4b375d1ebcd17cfbfb60c676f18e
- shell: bash
run: |
echo 'hello world!'

Dla dalszych informacji sprawdź https://www.chainguard.dev/unchained/what-the-fork-imposter-commits-in-github-actions-and-ci-cd

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

Inne sposoby wsparcia HackTricks:

PreviousPentesting CI/CD MethodologyNextAbusing Github Actions

Last updated