Last updated
Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
(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.
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, repozytorium 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 repozytorium.
Github pozwala na wyszukiwanie czegoś, określając jako zakres użytkownika, repozytorium 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):
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 repozytorium 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 repozytorium i uruchamiasz coś takiego jak git log -p, nie zapomnij, że mogą być inne gałęzie z innymi commitami zawierającymi sekrety!
Możliwe jest kompromitowanie repozytoriów poprzez nadużywanie pull requestów. Aby dowiedzieć się, czy repozytorium jest podatne, musisz głównie przeczytać pliki konfiguracyjne Github Actions yaml. Więcej informacji na ten temat poniżej.
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:
Istnieją pewne domyślne uprawnienia, które mogą być przypisane do członków 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 tej opcji 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
Zezwolenie 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 jest to wyłączyć.
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.
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ć workflowy i które workflowy powinny być dozwolone. Zaleca się określenie, które repozytoria powinny być dozwolone i nie pozwalać na uruchamianie wszystkich akcji.
Workflowy 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ów z pull requestów: Jest to wysoce odradzane uruchamianie workflowów z pull requestów, ponieważ utrzymujący oryginalny 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ów: 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żywania GITHUB_TOKEN przyznawanego do uruchamiania workflowów.
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).
W tym scenariuszu zakładamy, że uzyskałeś dostęp do konta github.
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ść cookie 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.
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 enumerować środowisko. Możesz jednak enumerować lokalne ustawienia, aby uzyskać informacje o repozytoriach i użytkowniku, do którego masz dostęp:
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 w 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.
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ą:
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
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/repos/akcji związanych z organizacją.
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/repos/akcji związanych z organizacją.
Istnieje kilka technik, aby skompromitować i nadużyć Github Action, sprawdź je tutaj:
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 przeglądów 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 push: Jeśli repozytorium zezwala tylko określonym użytkownikom na przesyłanie push (łą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.
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 push nad nią. Ochrona gałęzi zezwala na push do nowej gałęzi, więc github action zostanie wyzwolona.
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.
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
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:
Aby uzyskać więcej informacji, sprawdź https://www.chainguard.dev/unchained/what-the-fork-imposter-commits-in-github-actions-and-ci-cd
Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
