Temel Jenkins Bilgisi

Tip

AWS Hacking’i öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking’i öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE)
Az Hacking’i öğrenin ve pratik yapın: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks'i Destekleyin

Erişim

Kullanıcı Adı + Parola

Jenkins’e giriş yapmanın en yaygın yolu kullanıcı adı veya parola kullanmaktır.

Çerez

Eğer yetkili bir çerez çalınırsa, kullanıcı oturumuna erişmek için kullanılabilir. Çerez genellikle JSESSIONID.* olarak adlandırılır. (Bir kullanıcı tüm oturumlarını sonlandırabilir, ancak bunun için önce bir çerezin çalındığını öğrenmesi gerekir.)

SSO/Plugins

Jenkins, eklentiler kullanılarak üçüncü taraf SSO üzerinden erişilebilir şekilde yapılandırılabilir.

Tokenlar

Kullanıcılar token üretebilir; böylece CLI veya REST API üzerinden onları taklit edecek uygulamalara erişim verilebilir.

SSH Anahtarları

Bu bileşen Jenkins için yerleşik bir SSH sunucusu sağlar. Bu, Jenkins CLI için alternatif bir arayüzdür ve herhangi bir SSH istemcisi kullanılarak bu şekilde komutlar çalıştırılabilir. (From the docs)

Yetkilendirme

/configureSecurity konumunda Jenkins’in yetkilendirme yöntemini yapılandırmak mümkündür. Birkaç seçenek vardır:

  • Herkes her şeyi yapabilir: Anonim erişim bile sunucuyu yönetebilir
  • Legacy mode: Jenkins <1.164 ile aynı. Eğer “admin” rolüne sahipseniz, sistem üzerinde tam kontrol verilir; aksi halde (anonim kullanıcılar dahil) okuma erişimine sahip olursunuz.
  • Giriş yapmış kullanıcılar her şeyi yapabilir: Bu modda, her giriş yapmış kullanıcı Jenkins üzerinde tam kontrole sahip olur. Tam kontrole sahip olmayan tek kullanıcı anonim kullanıcıdır, ki sadece okuma erişimi alır.
  • Matris tabanlı güvenlik: Bir tabloda kimin ne yapabileceğini yapılandırabilirsiniz. Her sütun bir izni temsil eder. Her satır bir kullanıcı veya bir grup/rolu temsil eder. Bu, özel bir kullanıcı olan ‘anonymous’(kimlik doğrulanmamış kullanıcıları temsil eder) ile tüm kimlik doğrulanmış kullanıcıları temsil eden ‘authenticated’’ı içerir.

  • Proje Tabanlı Matris Yetkilendirme Stratejisi: Bu mod, Matris tabanlı güvenlik’in bir uzantısıdır ve her proje için ek ACL matrislerinin ayrı ayrı tanımlanmasına izin verir.
  • Rol Tabanlı Strateji: Yetkilendirmeleri bir rol tabanlı strateji kullanarak tanımlamayı sağlar. Rolleri /role-strategy içinde yönetin.

Güvenlik Alanı

/configureSecurity konumunda güvenlik alanı yapılandırılabilir. Varsayılan olarak Jenkins birkaç farklı güvenlik alanı desteği içerir:

  • Delegate to servlet container: Jenkins controller’ı çalıştıran bir servlet container’a (ör. Jetty) kimlik doğrulamayı delege etmek için.
  • Jenkins’ own user database: Kimlik doğrulama için Jenkins’in yerleşik kullanıcı veri deposunu kullanın; harici bir sisteme delege edilmez. Bu varsayılan olarak etkindir.
  • LDAP: Tüm kimlik doğrulamayı, kullanıcılar ve gruplar dahil, yapılandırılmış bir LDAP sunucusuna delege edin.
  • Unix user/group database: Kimlik doğrulamayı Jenkins controller üzerindeki Unix işletim sistemi seviyesindeki kullanıcı veritabanına delege eder. Bu mod ayrıca yetkilendirme için Unix gruplarının yeniden kullanılmasına da izin verir.

Eklentiler, Jenkins’i mevcut kimlik sistemlerine entegre etmek için faydalı olabilecek ek güvenlik alanları sağlayabilir, örneğin:

Jenkins Nodes, Agents & Executors

Definitions from the docs:

Nodes are the machines on which build agents run. Jenkins monitors each attached node for disk space, free temp space, free swap, clock time/sync and response time. A node is taken offline if any of these values go outside the configured threshold.

Agents manage the task execution on behalf of the Jenkins controller by using executors. An agent can use any operating system that supports Java. Tools required for builds and tests are installed on the node where the agent runs; they can be installed directly or in a container (Docker or Kubernetes). Each agent is effectively a process with its own PID on the host machine.

An executor is a slot for execution of tasks; effectively, it is a thread in the agent. The number of executors on a node defines the number of concurrent tasks that can be executed on that node at one time. In other words, this determines the number of concurrent Pipeline stages that can execute on that node at one time.

Jenkins Secrets

Sırların ve Kimlik Bilgilerinin Şifrelenmesi

Definition from the docs: Jenkins uses AES to encrypt and protect secrets, credentials, and their respective encryption keys. These encryption keys are stored in $JENKINS_HOME/secrets/ along with the master key used to protect said keys. This directory should be configured so that only the operating system user the Jenkins controller is running as has read and write access to this directory (i.e., a chmod value of 0700 or using appropriate file attributes). The master key (sometimes referred to as a “key encryption key” in cryptojargon) is stored _unencrypted_ on the Jenkins controller filesystem in $JENKINS_HOME/secrets/master.key which does not protect against attackers with direct access to that file. Most users and developers will use these encryption keys indirectly via either the Secret API for encrypting generic secret data or through the credentials API. For the cryptocurious, Jenkins uses AES in cipher block chaining (CBC) mode with PKCS#5 padding and random IVs to encrypt instances of CryptoConfidentialKey which are stored in $JENKINS_HOME/secrets/ with a filename corresponding to their CryptoConfidentialKey id. Common key ids include:

  • hudson.util.Secret: used for generic secrets;
  • com.cloudbees.plugins.credentials.SecretBytes.KEY: used for some credentials types;
  • jenkins.model.Jenkins.crumbSalt: used by the CSRF protection mechanism; and

Kimlik Bilgilerine Erişim

Credentials, herhangi bir yapılandırılmış proje tarafından erişilebilecek global sağlayıcılara (/credentials/) scope edilebilir veya belirli projelere (/job/<project-name>/configure) scope edilerek yalnızca ilgili projeden erişilebilir hale getirilebilir.

According to the docs: Kapsama dahil olan kimlik bilgileri pipeline içinde sınırlama olmadan kullanılabilir. Build günlüğünde yanlışlıkla maruz kalmalarını önlemek için, kimlik bilgileri normal çıktıdan maskeleme uygulanır; bu yüzden env (Linux) veya set (Windows) çağrısı ya da ortam değişkenlerini veya parametrelerini yazdıran programlar, kimlik bilgilerine erişimi olmayan kullanıcılar için build günlüğünde onları göstermez.

Bu nedenle, kimlik bilgilerini exfiltrate etmek isteyen bir saldırganın, örneğin, bunları base64 ile kodlaması gerekir.

Eklenti/İş konfigürasyonlarında diskteki sırlar

Sırlar sadece credentials.xml içinde saklanıyor varsaymayın. Birçok eklenti sırları kendi global XML’lerinde $JENKINS_HOME/*.xml altında veya her iş için $JENKINS_HOME/jobs/<JOB>/config.xml içinde saklar; bazen hatta düz metin olarak (UI maskelemesi şifreli depolama garantilemez). Dosya sistemi üzerinde okuma erişimi elde ederseniz, bu XML’leri listeleyin ve bariz secret etiketlerini arayın.

# Global plugin configs
ls -l /var/lib/jenkins/*.xml
grep -R "password\\|token\\|SecretKey\\|credentialId" /var/lib/jenkins/*.xml

# Per-job configs
find /var/lib/jenkins/jobs -maxdepth 2 -name config.xml -print -exec grep -H "password\\|token\\|SecretKey" {} \\;

Referanslar

Tip

AWS Hacking’i öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking’i öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE)
Az Hacking’i öğrenin ve pratik yapın: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks'i Destekleyin