Basic Jenkins Information
Last updated
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)
Najczęstszy sposób logowania do Jenkins to użycie nazwy użytkownika lub hasła.
Jeśli autoryzowane cookie zostanie skradzione, może być użyte do uzyskania dostępu do sesji użytkownika. Cookie zazwyczaj nazywa się JSESSIONID.*. (Użytkownik może zakończyć wszystkie swoje sesje, ale najpierw musi się dowiedzieć, że cookie zostało skradzione).
Jenkins może być skonfigurowany za pomocą wtyczek, aby być dostępnym przez SSO stron trzecich.
Użytkownicy mogą generować tokeny, aby dać dostęp do aplikacji, aby je imitować za pomocą CLI lub REST API.
Ten komponent zapewnia wbudowany serwer SSH dla Jenkins. Jest to alternatywne interfejs dla Jenkins CLI, a polecenia mogą być wywoływane w ten sposób za pomocą dowolnego klienta SSH. (Z dokumentacji)
W /configureSecurity można skonfigurować metodę autoryzacji Jenkins. Istnieje kilka opcji:
Każdy może robić cokolwiek: Nawet dostęp anonimowy może administrować serwerem.
Tryb dziedziczony: Tak jak Jenkins <1.164. Jeśli masz rolę "admin", otrzymasz pełną kontrolę nad systemem, a w przeciwnym razie (w tym użytkownicy anonimowi) będziesz miał dostęp do odczytu.
Zalogowani użytkownicy mogą robić cokolwiek: W tym trybie każdy zalogowany użytkownik ma pełną kontrolę nad Jenkins. Jedynym użytkownikiem, który nie będzie miał pełnej kontroli, jest użytkownik anonimowy, który ma tylko dostęp do odczytu.
Bezpieczeństwo oparte na macierzy: Możesz skonfigurować kto może robić co w tabeli. Każda kolumna reprezentuje uprawnienie. Każdy wiersz reprezentuje użytkownika lub grupę/rolę. Obejmuje to specjalnego użytkownika 'anonimowy', który reprezentuje użytkowników nieautoryzowanych, a także 'autoryzowany', który reprezentuje wszystkich użytkowników autoryzowanych.
Strategia autoryzacji oparta na projektach: Ten tryb jest rozszerzeniem do "Bezpieczeństwa opartego na macierzy", które pozwala na definiowanie dodatkowej macierzy ACL dla każdego projektu osobno.
Strategia oparta na rolach: Umożliwia definiowanie autoryzacji za pomocą strategii opartej na rolach. Zarządzaj rolami w /role-strategy.
W /configureSecurity można skonfigurować królestwo bezpieczeństwa. Domyślnie Jenkins zawiera wsparcie dla kilku różnych Królestw Bezpieczeństwa:
Delegowanie do kontenera servletów: Do delegowania autoryzacji do kontenera servletów uruchamiającego kontroler Jenkins, takiego jak Jetty.
Własna baza danych użytkowników Jenkins: Użyj wbudowanej bazy danych użytkowników Jenkins do autoryzacji zamiast delegować do zewnętrznego systemu. Jest to włączone domyślnie.
LDAP: Deleguj całą autoryzację do skonfigurowanego serwera LDAP, w tym zarówno użytkowników, jak i grupy.
Baza danych użytkowników/grup Unix: Deleguje autoryzację do podstawowej bazy danych użytkowników Unix na kontrolerze Jenkins. Ten tryb pozwoli również na ponowne wykorzystanie grup Unix do autoryzacji.
Wtyczki mogą dostarczać dodatkowe królestwa bezpieczeństwa, które mogą być przydatne do włączenia Jenkins w istniejące systemy tożsamości, takie jak:
Definicje z dokumentacji:
Węzły to maszyny, na których działają agenci budowy. Jenkins monitoruje każdy podłączony węzeł pod kątem miejsca na dysku, wolnego miejsca tymczasowego, wolnej pamięci swap, czasu zegara/synchronizacji i czasu odpowiedzi. Węzeł jest wyłączany, jeśli jakiekolwiek z tych wartości przekracza skonfigurowany próg.
Agenci zarządzają wykonywaniem zadań w imieniu kontrolera Jenkins, używając wykonawców. Agent może używać dowolnego systemu operacyjnego, który obsługuje Javę. Narzędzia wymagane do budowy i testów są instalowane na węźle, na którym działa agent; mogą być instalowane bezpośrednio lub w kontenerze (Docker lub Kubernetes). Każdy agent jest w rzeczywistości procesem z własnym PID na maszynie gospodarza.
Wykonawca to miejsce do wykonywania zadań; w rzeczywistości jest to wątek w agencie. Liczba wykonawców na węźle definiuje liczbę równoległych zadań, które mogą być wykonywane na tym węźle w danym czasie. Innymi słowy, określa to liczbę równoległych stages Pipeline, które mogą być wykonywane na tym węźle w danym czasie.
Definicja z dokumentacji: Jenkins używa AES do szyfrowania i ochrony sekretów, poświadczeń i ich odpowiednich kluczy szyfrujących. Te klucze szyfrujące są przechowywane w $JENKINS_HOME/secrets/ wraz z kluczem głównym używanym do ochrony tych kluczy. Ten katalog powinien być skonfigurowany tak, aby tylko użytkownik systemu operacyjnego, na którym działa kontroler Jenkins, miał dostęp do odczytu i zapisu do tego katalogu (tj. wartość chmod wynosząca 0700 lub używając odpowiednich atrybutów plików). Klucz główny (czasami nazywany "kluczem szyfrującym" w kryptologii) jest przechowywany _nieszyfrowany_ w systemie plików kontrolera Jenkins w $JENKINS_HOME/secrets/master.key, co nie chroni przed atakującymi mającymi bezpośredni dostęp do tego pliku. Większość użytkowników i deweloperów będzie używać tych kluczy szyfrujących pośrednio za pomocą API Secret do szyfrowania ogólnych danych sekretów lub przez API poświadczeń. Dla ciekawskich kryptograficznie, Jenkins używa AES w trybie łańcucha bloków szyfrujących (CBC) z paddingiem PKCS#5 i losowymi IV do szyfrowania instancji CryptoConfidentialKey, które są przechowywane w $JENKINS_HOME/secrets/ z nazwą pliku odpowiadającą ich identyfikatorowi CryptoConfidentialKey. Typowe identyfikatory kluczy obejmują:
hudson.util.Secret: używane do ogólnych sekretów;
com.cloudbees.plugins.credentials.SecretBytes.KEY: używane dla niektórych typów poświadczeń;
jenkins.model.Jenkins.crumbSalt: używane przez mechanizm ochrony CSRF; oraz
Poświadczenia mogą być ograniczone do globalnych dostawców (/credentials/), które mogą być dostępne przez dowolny skonfigurowany projekt, lub mogą być ograniczone do konkretnych projektów (/job/<project-name>/configure), a zatem dostępne tylko z konkretnego projektu.
Zgodnie z dokumentacją: Poświadczenia, które są w zakresie, są udostępniane w potoku bez ograniczeń. Aby zapobiec przypadkowemu ujawnieniu w logu budowy, poświadczenia są ukrywane przed regularnym wyjściem, więc wywołanie env (Linux) lub set (Windows), lub programy drukujące swoje środowisko lub parametry nie ujawnią ich w logu budowy użytkownikom, którzy w przeciwnym razie nie mieliby dostępu do poświadczeń.
Dlatego, aby wyeksportować poświadczenia, atakujący musi na przykład zakodować je w base64.
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)
