Jenkins Security
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Jenkins to narzędzie, które oferuje prostą metodę do stworzenia środowiska ciągłej integracji lub ciągłego dostarczania (CI/CD) dla prawie dowolnej kombinacji języków programowania i repozytoriów kodu źródłowego za pomocą pipeline'ów. Ponadto automatyzuje różne rutynowe zadania deweloperskie. Chociaż Jenkins nie eliminuje potrzeby tworzenia skryptów dla poszczególnych kroków, zapewnia szybszy i bardziej niezawodny sposób integracji całej sekwencji narzędzi do budowy, testowania i wdrażania niż można łatwo skonstruować ręcznie.
Basic Jenkins InformationAby wyszukiwać interesujące strony Jenkins bez uwierzytelnienia, takie jak (/people lub /asynchPeople, które wyświetlają aktualnych użytkowników), możesz użyć:
Sprawdź, czy możesz wykonywać polecenia bez potrzeby uwierzytelnienia:
Bez poświadczeń możesz zajrzeć do ścieżki /asynchPeople/ lub /securityRealm/user/admin/search/index?q= w poszukiwaniu nazw użytkowników.
Możesz być w stanie uzyskać wersję Jenkins z ścieżki /oops lub /error
W podstawowych informacjach możesz sprawdzić wszystkie sposoby logowania się do Jenkins:
Basic Jenkins InformationBędziesz w stanie znaleźć instancje Jenkins, które pozwalają na utworzenie konta i zalogowanie się do niego. Tak prosto.
Jeśli funkcjonalność/wtyczki SSO były obecne, powinieneś spróbować zalogować się do aplikacji za pomocą konta testowego (tj. testowe konto Github/Bitbucket). Sztuczka z tutaj.
Jenkins nie ma polityki haseł ani ochrony przed atakami brute-force na nazwy użytkowników. Ważne jest, aby próbować brute-force użytkowników, ponieważ mogą być używane słabe hasła lub nazwy użytkowników jako hasła, nawet odwrócone nazwy użytkowników jako hasła.
Użyj tego skryptu python lub tego skryptu powershell.
Wiele organizacji łączy oparte na SaaS systemy zarządzania kodem źródłowym (SCM), takie jak GitHub lub GitLab, z wewnętrznym, samodzielnie hostowanym rozwiązaniem CI, takim jak Jenkins lub TeamCity. Taka konfiguracja pozwala systemom CI na odbieranie zdarzeń webhook z dostawców SCM opartych na SaaS, głównie w celu uruchamiania zadań w pipeline.
Aby to osiągnąć, organizacje dodają do białej listy zakresy IP platform SCM, zezwalając im na dostęp do wewnętrznego systemu CI za pośrednictwem webhooków. Ważne jest jednak, aby zauważyć, że każdy może założyć konto na GitHubie lub GitLabie i skonfigurować je do uruchamiania webhooka, potencjalnie wysyłając żądania do wewnętrznego systemu CI.
W tych scenariuszach zakładamy, że masz ważne konto do uzyskania dostępu do Jenkinsa.
W zależności od skonfigurowanego mechanizmu autoryzacji w Jenkinsie oraz uprawnień skompromitowanego użytkownika możesz być w stanie lub nie wykonać następujące ataki.
Aby uzyskać więcej informacji, sprawdź podstawowe informacje:
Basic Jenkins InformationJeśli uzyskałeś dostęp do Jenkinsa, możesz wyświetlić innych zarejestrowanych użytkowników pod adresem http://127.0.0.1:8080/asynchPeople/
Użyj tego skryptu, aby zrzucić wyjścia konsoli buildów i zmienne środowiskowe buildów, aby mieć nadzieję na znalezienie jawnych sekretów.
Jeśli skompromitowany użytkownik ma wystarczające uprawnienia do tworzenia/modyfikowania nowego węzła Jenkins i poświadczenia SSH są już przechowywane do uzyskania dostępu do innych węzłów, może ukraść te poświadczenia, tworząc/modyfikując węzeł i ustawiając hosta, który zarejestruje poświadczenia bez weryfikacji klucza hosta:
Zazwyczaj znajdziesz poświadczenia ssh Jenkins w globalnym dostawcy (/credentials/
), więc możesz je również zrzucić, tak jak zrzucasz inne sekrety. Więcej informacji w sekcji Zrzucanie sekretów.
Uzyskanie powłoki na serwerze Jenkins daje atakującemu możliwość wycieku wszystkich sekretów i zmiennych środowiskowych oraz eksploatacji innych maszyn znajdujących się w tej samej sieci lub nawet zbierania poświadczeń chmurowych.
Domyślnie Jenkins będzie działał jako SYSTEM. Zatem jego skompromitowanie da atakującemu uprawnienia SYSTEM.
Tworzenie/modyfikowanie projektu to sposób na uzyskanie RCE na serwerze Jenkins:
Jenkins RCE Creating/Modifying ProjectMożesz również uzyskać RCE, wykonując skrypt Groovy, co może być bardziej dyskretne niż tworzenie nowego projektu:
Jenkins RCE with Groovy ScriptMożesz również uzyskać RCE, tworząc/modyfikując pipeline:
Jenkins RCE Creating/Modifying PipelineAby eksploatować pipeline, nadal musisz mieć dostęp do Jenkins.
Pipeline mogą być również używane jako mechanizm budowania w projektach, w takim przypadku można skonfigurować plik w repozytorium, który będzie zawierał składnię pipeline. Domyślnie używany jest /Jenkinsfile
:
Możliwe jest również przechowywanie plików konfiguracyjnych pipeline w innych miejscach (na przykład w innych repozytoriach) w celu oddzielenia dostępu do repozytorium i dostępu do pipeline.
Jeśli atakujący ma dostęp do zapisu w tym pliku, będzie mógł go zmodyfikować i potencjalnie uruchomić pipeline bez nawet posiadania dostępu do Jenkins. Możliwe, że atakujący będzie musiał obejść niektóre zabezpieczenia gałęzi (w zależności od platformy i uprawnień użytkownika mogą one być obejdź lub nie).
Najczęstsze wyzwalacze do uruchomienia niestandardowego pipeline to:
Pull request do głównej gałęzi (lub potencjalnie do innych gałęzi)
Push do głównej gałęzi (lub potencjalnie do innych gałęzi)
Aktualizacja głównej gałęzi i czekanie, aż zostanie uruchomiona w jakiś sposób
Jeśli jesteś użytkownikiem zewnętrznym, nie powinieneś oczekiwać, że stworzysz PR do głównej gałęzi repozytorium innego użytkownika/organizacji i uruchomisz pipeline... ale jeśli jest źle skonfigurowany, możesz całkowicie skomplikować firmy, po prostu to eksploatując.
W poprzedniej sekcji RCE już wskazano technikę, aby uzyskać RCE, modyfikując pipeline.
Możliwe jest zadeklarowanie zmiennych środowiskowych w postaci czystego tekstu dla całego pipeline lub dla konkretnych etapów. Te zmienne środowiskowe nie powinny zawierać wrażliwych informacji, ale atakujący zawsze może sprawdzić wszystkie konfiguracje pipeline/Jenkinsfiles:
Aby uzyskać informacje na temat tego, jak sekrety są zazwyczaj traktowane przez Jenkins, zapoznaj się z podstawowymi informacjami:
Basic Jenkins InformationPoświadczenia mogą być ograniczone do globalnych dostawców (/credentials/
) lub do konkretnych projektów (/job/<project-name>/configure
). Dlatego, aby wyeksfiltrować wszystkie z nich, musisz skompromitować przynajmniej wszystkie projekty, które zawierają sekrety i wykonać niestandardowe/zepsute potoki.
Jest jeszcze jeden problem, aby uzyskać sekret wewnątrz env potoku, musisz znać nazwę i typ sekrety. Na przykład, jeśli spróbujesz załadować sekret usernamePassword
jako sekret string
, otrzymasz ten błąd:
Oto sposób na załadowanie niektórych powszechnych typów sekretów:
Na końcu tej strony możesz znaleźć wszystkie typy poświadczeń: https://www.jenkins.io/doc/pipeline/steps/credentials-binding/
Najlepszym sposobem na zrzucenie wszystkich sekretów jednocześnie jest kompromitacja maszyny Jenkins (na przykład uruchamiając reverse shell w wbudowanym węźle) i następnie wyciek kluczy głównych oraz zaszyfrowanych sekretów i odszyfrowanie ich offline. Więcej na ten temat w sekcji Węzły i Agenci oraz w sekcji Po Eksploatacji.
Z dokumentacji: Dyrektywa triggers
definiuje automatyczne sposoby, w jakie Pipeline powinien być ponownie wyzwalany. Dla Pipeline'ów, które są zintegrowane z źródłem takim jak GitHub lub BitBucket, triggers
mogą nie być konieczne, ponieważ integracja oparta na webhookach prawdopodobnie już istnieje. Obecnie dostępne wyzwalacze to cron
, pollSCM
i upstream
.
Przykład Cron:
Sprawdź inne przykłady w dokumentacji.
Instancja Jenkins może mieć różne agenty działające na różnych maszynach. Z perspektywy atakującego, dostęp do różnych maszyn oznacza różne potencjalne dane uwierzytelniające do chmury do kradzieży lub różny dostęp do sieci, który można wykorzystać do eksploatacji innych maszyn.
Aby uzyskać więcej informacji, sprawdź podstawowe informacje:
Basic Jenkins InformationMożesz enumerować skonfigurowane węzły w /computer/
, zazwyczaj znajdziesz Wbudowany Węzeł
(który jest węzłem uruchamiającym Jenkins) i potencjalnie więcej:
Jest szczególnie interesujące, aby skompromitować Wbudowany węzeł, ponieważ zawiera wrażliwe informacje o Jenkinsie.
Aby wskazać, że chcesz uruchomić pipeline w wbudowanym węźle Jenkins, możesz określić w pipeline następującą konfigurację:
Pipeline w konkretnym agencie, z wyzwalaczem cron, z zmiennymi środowiskowymi pipeline i etapu, ładujący 2 zmienne w kroku i wysyłający reverse shell:
Możesz wylistować sekrety, uzyskując dostęp do /credentials/
, jeśli masz wystarczające uprawnienia. Zauważ, że to wylistuje tylko sekrety znajdujące się w pliku credentials.xml
, ale pliki konfiguracyjne budowy mogą również zawierać więcej poświadczeń.
Jeśli możesz zobaczyć konfigurację każdego projektu, możesz również zobaczyć tam nazwy poświadczeń (sekretów) używanych do uzyskania dostępu do repozytorium oraz inne poświadczenia projektu.
Te pliki są potrzebne do deszyfrowania sekretów Jenkins:
secrets/master.key
secrets/hudson.util.Secret
Takie sekrety można zazwyczaj znaleźć w:
credentials.xml
jobs/.../build.xml
jobs/.../config.xml
Oto regex, aby je znaleźć:
Jeśli masz zrzutane potrzebne hasła do odszyfrowania sekretów, użyj tego skryptu do odszyfrowania tych sekretów.
Uzyskaj dostęp do pliku Jenkins config.xml w /var/lib/jenkins/config.xml
lub C:\Program Files (x86)\Jenkins\
Wyszukaj słowo <useSecurity>true</useSecurity>
i zmień słowo true
na false
.
sed -i -e 's/<useSecurity>true</<useSecurity>false</g' config.xml
Uruchom ponownie serwer Jenkins: service jenkins restart
Teraz przejdź ponownie do portalu Jenkins i Jenkins nie poprosi o żadne dane uwierzytelniające tym razem. Przejdź do "Zarządzaj Jenkins", aby ustawić hasło administratora ponownie.
Włącz ponownie bezpieczeństwo, zmieniając ustawienia na <useSecurity>true</useSecurity>
i uruchom ponownie Jenkins.
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)