Polish - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

Github Security

Wsparcie dla HackTricks

Czym 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

Basic Github Information

Zewnętrzne rozpoznanie

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

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

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

  • Publiczne oznacza, że wszyscy w internecie będą mogli uzyskać do nich dostęp.

W przypadku, gdy znasz użytkownika, repo lub organizację, którą chcesz zaatakować, możesz użyć github dorks, aby znaleźć wrażliwe informacje lub wyszukać wycieki wrażliwych informacji w każdym repo.

Github Dorks

Github pozwala na wyszukiwanie czegoś, określając jako zakres użytkownika, repo lub organizację. Dlatego z listą ciągów, które będą się pojawiać blisko wrażliwych informacji, możesz łatwo wyszukiwać potencjalne wrażliwe informacje w swoim celu.

Narzędzia (każde narzędzie zawiera swoją listę dorks):

Github Leaks

Proszę zauważyć, że github dorks są również przeznaczone do wyszukiwania wycieków przy użyciu opcji wyszukiwania github. Ta sekcja jest poświęcona tym narzędziom, które pobierają każde repo i wyszukują w nich wrażliwe informacje (nawet sprawdzając pewną głębokość commitów).

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

Kiedy szukasz wycieków w repo i uruchamiasz coś takiego jak git log -p, nie zapomnij, że mogą być inne gałęzie z innymi commitami zawierającymi sekrety!

Zewnętrzne forki

Możliwe jest kompromitowanie repozytoriów poprzez nadużywanie pull requestów. Aby dowiedzieć się, czy repo jest podatne, musisz głównie przeczytać pliki konfiguracyjne Github Actions yaml. Więcej informacji na ten temat poniżej.

Github Leaks w usuniętych/wewnętrznych forkach

Nawet jeśli usunięte lub wewnętrzne, może być możliwe uzyskanie wrażliwych danych z forków repozytoriów github. Sprawdź to tutaj:

Accessible Deleted Data in Github

Wzmacnianie organizacji

Uprawnienia członków

Istnieją pewne domyślne uprawnienia, które można przypisać członkom organizacji. Można je kontrolować z strony https://github.com/organizations/<org_name>/settings/member_privileges lub z API Organizacji.

  • Podstawowe uprawnienia: Członkowie będą mieli uprawnienia None/Read/write/Admin do repozytoriów organizacji. Zaleca się None lub Read.

  • Forkowanie repozytoriów: Jeśli nie jest to konieczne, lepiej nie pozwalać członkom na forkowanie repozytoriów organizacji.

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

  • Prośby o dostęp do integracji: Po włączeniu tego, zewnętrzni współpracownicy będą mogli prosić o dostęp do aplikacji GitHub lub OAuth, aby uzyskać dostęp do tej organizacji i jej zasobów. Zwykle jest to potrzebne, ale jeśli nie, lepiej to wyłączyć.

  • Nie mogłem znaleźć tych informacji w odpowiedzi API, podziel się, jeśli je masz

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

  • Nie mogłem znaleźć tych informacji w odpowiedzi API, podziel się, jeśli je masz

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

  • Nie mogłem znaleźć tych informacji w odpowiedzi API, podziel się, jeśli je masz

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

  • Nie mogłem znaleźć tych informacji w odpowiedzi API, podziel się, jeśli je masz

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

Ustawienia akcji

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

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

  • Polityki akcji Github: Pozwala to wskazać, które repozytoria mogą uruchamiać workflow i które workflow powinny być dozwolone. Zaleca się określenie, które repozytoria powinny być dozwolone i nie pozwalać na uruchamianie wszystkich akcji.

  • API-1, API-2

  • Workflow pull requestów z zewnętrznych współpracowników: Zaleca się wymaganie zatwierdzenia dla wszystkich zewnętrznych współpracowników.

  • Nie mogłem znaleźć API z tymi informacjami, podziel się, jeśli je masz

  • Uruchamianie workflow z pull requestów forków: Jest to wysoce odradzane uruchamianie workflow z pull requestów, ponieważ utrzymujący fork będą mieli możliwość używania tokenów z uprawnieniami do odczytu w repozytorium źródłowym.

  • Nie mogłem znaleźć API z tymi informacjami, podziel się, jeśli je masz

  • Uprawnienia workflow: Wysoce zaleca się przyznawanie tylko uprawnień do odczytu repozytoriów. Odradza się przyznawanie uprawnień do zapisu i tworzenia/zatwierdzania pull requestów, aby uniknąć nadużycia GITHUB_TOKEN przyznawanego do uruchamiania workflow.

  • API

Integracje

Daj mi znać, jeśli znasz punkt końcowy API, aby uzyskać te informacje!

  • Polityka dostępu aplikacji zewnętrznych: Zaleca się ograniczenie dostępu do każdej aplikacji i zezwolenie tylko na te potrzebne (po ich przeglądzie).

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

Rozpoznanie i ataki nadużywające poświadczeń

W tym scenariuszu zakładamy, że uzyskałeś dostęp do konta github.

Z poświadczeniami użytkownika

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

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

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

Sprawdź sekcję poniżej o obejściach ochrony gałęzi, jeśli to może być przydatne.

Z kluczem SSH użytkownika

Github pozwala użytkownikom ustawiać 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 uzyskania dostępu do API github, aby wyliczyć środowisko. Możesz jednak wyliczyć lokalne ustawienia, aby uzyskać informacje o repozytoriach i użytkowniku, do którego 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 github, możesz uzyskać dostęp do publicznych kluczy, które ustawił w swoim koncie pod adresem https://github.com/<github_username>.keys, możesz to sprawdzić, aby potwierdzić, że znaleziony klucz prywatny może być użyty.

Klucze SSH mogą być również ustawione w repozytoriach jako klucze wdrożeniowe. Każdy, kto ma dostęp do tego klucza, będzie mógł uruchomić projekty z repozytorium. Zwykle na serwerze z różnymi kluczami wdrożeniowymi lokalny plik ~/.ssh/config dostarczy informacji o tym, do którego klucza się odnosi.

Klucze GPG

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

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

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

Z tokenem użytkownika

Aby uzyskać wprowadzenie do 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ą Basic Authentication. W zależności od przypisanych do niego uprawnień, możesz być w stanie wykonać różne akcje.

Token użytkownika wygląda tak: ghp_EfHnQFcFHX6fGIu5mpduvRiYR584kK0dX123

Z aplikacją Oauth

Aby uzyskać wprowadzenie do Aplikacji Oauth Github sprawdź podstawowe informacje.

Atakujący może stworzyć złośliwą aplikację Oauth, aby uzyskać dostęp do uprzywilejowanych danych/akcji użytkowników, którzy prawdopodobnie zaakceptują je jako część kampanii phishingowej.

To są zakresy, o które może prosić aplikacja Oauth. Zawsze należy sprawdzić żądane zakresy przed ich zaakceptowaniem.

Ponadto, jak wyjaśniono w podstawowych informacjach, organizacje mogą przyznawać/odmawiać dostępu aplikacjom trzecim do informacji/repozytoriów/akcji związanych z organizacją.

Z aplikacją Github

Aby uzyskać wprowadzenie do Aplikacji Github sprawdź podstawowe informacje.

Atakujący może stworzyć złośliwą aplikację Github, aby uzyskać dostęp do uprzywilejowanych danych/akcji użytkowników, którzy prawdopodobnie zaakceptują je jako część kampanii phishingowej.

Ponadto, jak wyjaśniono w podstawowych informacjach, organizacje mogą przyznawać/odmawiać dostępu aplikacjom trzecim do informacji/repozytoriów/akcji związanych z organizacją.

Kompromitacja i nadużycie Github Action

Istnieje kilka technik, aby skompromitować i nadużywać Github Action, sprawdź je tutaj:

Abusing Github Actions

Ominięcie ochrony gałęzi

  • Wymagaj liczby zatwierdzeń: Jeśli skompromitowałeś kilka kont, możesz po prostu zaakceptować swoje PR z innych kont. Jeśli masz tylko konto, z którego utworzyłeś PR, nie możesz zaakceptować swojego własnego PR. Jednak jeśli masz dostęp do środowiska Github Action w repozytorium, używając GITHUB_TOKEN, możesz być w stanie zatwierdzić swój PR i w ten sposób uzyskać 1 zatwierdzenie.

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

  • Odrzuć zatwierdzenia, gdy nowe commity są przesyłane: Jeśli to nie jest ustawione, możesz przesłać legalny kod, poczekać, aż ktoś go zatwierdzi, a następnie dodać złośliwy kod i połączyć go z chronioną gałęzią.

  • Wymagaj recenzji od Właścicieli Kodów: Jeśli to jest aktywowane i jesteś Właścicielem Kodu, możesz sprawić, że Github Action utworzy twój PR, a następnie zatwierdzisz 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 Kodów nie jest stosowana.

  • Zezwól określonym aktorom na ominięcie wymagań dotyczących pull requestów: Jeśli jesteś jednym z tych aktorów, możesz ominąć ochronę pull requestów.

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

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

  • Usuwanie ochron gałęzi: Jeśli jesteś administratorem repozytorium, możesz wyłączyć ochrony, połączyć swój PR i ponownie ustawić ochrony.

  • Ominięcie ochron przesyłania: Jeśli repozytorium zezwala tylko określonym użytkownikom na przesyłanie (łączenie 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 masz pozwolenia na przesyłanie kodu z powodu ochrony gałęzi, możesz nadal utworzyć nową gałąź i w jej ramach utworzyć github action, która jest wyzwalana, gdy kod jest przesyłany. Ponieważ ochrona gałęzi nie będzie chronić gałęzi, dopóki nie zostanie utworzona, to pierwsze przesłanie kodu do gałęzi wykona github action.

Ominięcie ochron środowisk

Aby uzyskać wprowadzenie do Ś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 sekretów wewnątrz środowiska. Zauważ, że możesz znaleźć repozytoria, w których wszystkie gałęzie są chronione (poprzez określenie ich nazw lub użycie *), w tym scenariuszu, znajdź gałąź, w której możesz przesyłać kod i możesz wyeksportować sekrety, tworząc nową github action (lub modyfikując jedną).

Zauważ, że możesz napotkać przypadek brzegowy, w którym wszystkie gałęzie są chronione (poprzez symbol wieloznaczny *), określono kto może przesyłać kod do gałęzi (możesz to określić w ochronie gałęzi), a twój użytkownik nie ma pozwolenia. Możesz nadal uruchomić niestandardową github action, ponieważ możesz utworzyć gałąź i użyć wyzwalacza przesyłania nad nią. Ochrona gałęzi zezwala na przesyłanie do nowej gałęzi, więc github action zostanie wyzwolona.

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 będzie miała zastosowanie do nowej gałęzi i nie będziesz mógł jej modyfikować, ale w tym czasie już zrzuciłeś sekrety.

Utrzymywanie

  • Wygeneruj token użytkownika

  • Ukradnij tokeny github z sekretów

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

  • Przyznaj więcej uprawnień całej organizacji

  • Utwórz webhooki do eksfiltracji informacji

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

  • Usuń webhooki używane przez SIEM

  • Utwórz/modyfikuj Github Action z tylnym wejściem

  • Znajdź vulnerable Github Action do wstrzykiwania poleceń poprzez modyfikację wartości sekretu

Fałszywe Commity - Tylne wejście przez commity repo

W Githubie możliwe jest utworzenie PR do repo z forka. Nawet jeśli PR nie zostanie zaakceptowany, identyfikator commita w oryginalnym repo zostanie utworzony dla wersji kodu z forka. Dlatego atakujący może przypiąć się do użycia konkretnego commita z pozornie legalnego repo, które nie zostało utworzone przez właściciela repo.

Jak to:

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

Aby uzyskać więcej informacji, sprawdź https://www.chainguard.dev/unchained/what-the-fork-imposter-commits-in-github-actions-and-ci-cd

Wsparcie HackTricks
PreviousPentesting CI/CD MethodologyNextAbusing Github Actions

Last updated