Basic Jenkins Information
Naucz się i ćwicz AWS Hacking:
HackTricks Training AWS Red Team Expert (ARTE)
Naucz się i ćwicz GCP Hacking: 
HackTricks Training GCP Red Team Expert (GRTE)
Dostęp
Nazwa użytkownika + Hasło
Najczęstszym sposobem logowania się do Jenkins jest użycie nazwy użytkownika i hasła.
Cookie
Jeśli autoryzowany cookie zostanie skradziony, może być użyty 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 dowiedzieć się, że cookie zostało skradzione).
SSO/Plugins
Jenkins może być skonfigurowany za pomocą wtyczek, aby był dostępny przez zewnętrzne SSO.
Tokeny
Użytkownicy mogą generować tokeny, aby umożliwić aplikacjom podszywanie się pod nich za pomocą CLI lub REST API.
Klucze SSH
Ten komponent zapewnia wbudowany serwer SSH dla Jenkins. Jest to alternatywny interfejs dla Jenkins CLI, a polecenia mogą być wywoływane w ten sposób za pomocą dowolnego klienta SSH. (Z dokumentacji)
Autoryzacja
W /configureSecurity można skonfigurować metodę autoryzacji Jenkins. Istnieje kilka opcji:
Każdy może robić wszystko: Nawet anonimowy dostęp może administrować serwerem.
Tryb legacy: Taki sam jak Jenkins <1.164. Jeśli masz rolę "admin", otrzymasz pełną kontrolę nad systemem, a w przeciwnym razie (w tym anonimowi użytkownicy) będziesz miał dostęp tylko do odczytu.
Zalogowani użytkownicy mogą robić wszystko: 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 niezalogowanych użytkowników, oraz 'zalogowany', który reprezentuje wszystkich zalogowanych użytkowników.
Strategia autoryzacji oparta na macierzy projektów: Ten tryb jest rozszerzeniem "Bezpieczeństwa opartego na macierzy", które pozwala na dodatkową macierz ACL zdefiniowaną 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.
Realm bezpieczeństwa
W /configureSecurity można skonfigurować realm bezpieczeństwa. Domyślnie Jenkins obsługuje kilka różnych realmów bezpieczeństwa:
Delegowanie do kontenera servletów: Do delegowania uwierzytelniania do kontenera servletów uruchamiającego kontroler Jenkins, takiego jak Jetty.
Własna baza danych użytkowników Jenkins: Użyj wbudowanego magazynu danych użytkowników Jenkins do uwierzytelniania zamiast delegowania do zewnętrznego systemu. Jest to domyślnie włączone.
LDAP: Delegowanie całego uwierzytelniania do skonfigurowanego serwera LDAP, w tym zarówno użytkowników, jak i grup.
Baza danych użytkowników/grup Unix: Deleguje uwierzytelnianie do bazowego systemu operacyjnego Unix na kontrolerze Jenkins. Ten tryb pozwala również na ponowne użycie grup Unix do autoryzacji.
Wtyczki mogą dostarczać dodatkowe realmy bezpieczeństwa, które mogą być przydatne do włączenia Jenkins do istniejących systemów tożsamości, takich jak:
Węzły Jenkins, Agenci i Wykonawcy
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, wolnej przestrzeni tymczasowej, wolnej pamięci wymiany, czasu zegara/synchronizacji i czasu odpowiedzi. Węzeł jest wyłączany, jeśli którykolwiek z tych parametrów przekroczy 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 istocie procesem z własnym PID na maszynie hosta.
Wykonawca to slot do wykonywania zadań; w istocie jest to wątek w agencie. Liczba wykonawców na węźle definiuje liczbę jednoczesnych zadań, które mogą być wykonywane na tym węźle w danym momencie. Innymi słowy, określa to liczbę jednoczesnych etapów Pipeline, które mogą być wykonywane na tym węźle w danym momencie.
Sekrety Jenkins
Szyfrowanie sekretów i poświadczeń
Definicja z dokumentacji: Jenkins używa AES do szyfrowania i ochrony sekretów, poświadczeń i ich odpowiednich kluczy szyfrowania. Te klucze szyfrowania 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 0700 lub użycie odpowiednich atrybutów plików). Klucz główny (czasami nazywany "kluczem szyfrowania kluczy" w żargonie kryptograficznym) jest przechowywany _niezaszyfrowany_ na systemie plików kontrolera Jenkins w $JENKINS_HOME/secrets/master.key, co nie chroni przed atakującymi z bezpośrednim dostępem do tego pliku. Większość użytkowników i deweloperów będzie używać tych kluczy szyfrowania pośrednio za pomocą API Secret do szyfrowania ogólnych danych tajnych lub za pomocą API poświadczeń. Dla ciekawych kryptografii, Jenkins używa AES w trybie łańcuchowym bloków szyfrowania (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żywany do ogólnych sekretów;com.cloudbees.plugins.credentials.SecretBytes.KEY: używany do niektórych typów poświadczeń;jenkins.model.Jenkins.crumbSalt: używany przez mechanizm ochrony CSRF; oraz
Dostęp do poświadczeń
Poświadczenia mogą być zakresowane do globalnych dostawców (/credentials/), które mogą być dostępne przez każdy skonfigurowany projekt, lub mogą być zakresowane do konkretnych projektów (/job/<project-name>/configure) i w związku z tym dostępne tylko z konkretnego projektu.
Według dokumentacji: Poświadczenia, które są w zakresie, są udostępniane pipeline bez ograniczeń. Aby zapobiec przypadkowemu ujawnieniu w logu budowy, poświadczenia są maskowane w regularnym wyjściu, 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 wyeksfiltrować poświadczenia, atakujący musi na przykład zakodować je w base64.
Referencje
Naucz się i ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Naucz się i ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Last updated