Jenkins Security
Last updated
Last updated
AWS Hacking'i öğrenin ve pratik yapın:HackTricks Eğitim AWS Kırmızı Takım Uzmanı (ARTE) GCP Hacking'i öğrenin ve pratik yapın: HackTricks Eğitim GCP Kırmızı Takım Uzmanı (GRTE)
Jenkins, herhangi bir programlama dili ve kaynak kodu deposu kombinasyonu için sürekli entegrasyon veya sürekli teslimat (CI/CD) ortamı oluşturmanın basit bir yöntemini sunan bir araçtır. Ayrıca, çeşitli rutin geliştirme görevlerini otomatikleştirir. Jenkins, bireysel adımlar için betikler oluşturma ihtiyacını ortadan kaldırmasa da, tüm derleme, test ve dağıtım araçları dizisini entegre etmenin daha hızlı ve daha sağlam bir yolunu sağlar.
Kimlik doğrulaması olmadan ilginç Jenkins sayfalarını aramak için (/people veya /asynchPeople, bu mevcut kullanıcıları listeler) şunları kullanabilirsiniz:
Kimlik doğrulaması gerektirmeden komutları çalıştırıp çalıştıramayacağınızı kontrol edin:
Kredensiyalsiz olarak /asynchPeople/ yoluna veya /securityRealm/user/admin/search/index?q= yoluna bakarak kullanıcı adlarını görebilirsiniz.
Jenkins sürümünü /oops veya /error yolundan alabilirsiniz.
Temel bilgilerde Jenkins'e giriş yapmanın tüm yollarını kontrol edebilirsiniz:
Hesap oluşturmanıza ve içine giriş yapmanıza izin veren Jenkins örneklerini bulabileceksiniz. Bu kadar basit.
Ayrıca, SSO işlevselliği/eklentileri mevcutsa, bir test hesabı (yani, bir test Github/Bitbucket hesabı) kullanarak uygulamaya giriş yapmayı denemelisiniz. buradan hile yapın.
Jenkins, şifre politikası ve kullanıcı adı brute-force önlemesi eksikliği vardır. Zayıf şifreler veya şifre olarak kullanıcı adları kullanılıyor olabileceğinden, kullanıcıları brute-force yapmak önemlidir; hatta tersine çevrilmiş kullanıcı adları şifre olarak da kullanılabilir.
Bu python scriptini veya bu powershell scriptini kullanın.
Birçok organizasyon, SaaS tabanlı kaynak kontrol yönetimi (SCM) sistemleri olan GitHub veya GitLab'ı, Jenkins veya TeamCity gibi iç, kendi barındırdığı CI çözümleri ile birleştirir. Bu yapı, CI sistemlerinin SaaS kaynak kontrol sağlayıcılarından webhook olayları almasına olanak tanır, esasen pipeline işlerini tetiklemek için.
Bunu başarmak için, organizasyonlar SCM platformlarının IP aralıklarını beyaz listeye alır, böylece webhooklar aracılığıyla iç CI sistemine erişim izni verir. Ancak, herkesin GitHub veya GitLab'da bir hesap oluşturabileceğini ve bunu webhook tetiklemek için yapılandırabileceğini unutmamak önemlidir; bu da iç CI sistemine istek gönderebilir.
Kontrol edin: https://www.paloaltonetworks.com/blog/prisma-cloud/repository-webhook-abuse-access-ci-cd-systems-at-scale/
Bu senaryolarda Jenkins'e erişmek için geçerli bir hesabınız olduğunu varsayacağız.
Jenkins'te yapılandırılan Yetkilendirme mekanizmasına ve ele geçirilen kullanıcının izinlerine bağlı olarak, aşağıdaki saldırıları gerçekleştirme yeteneğiniz olabilir veya olmayabilir.
Daha fazla bilgi için temel bilgilere bakın:
Eğer Jenkins'e eriştiyseniz, http://127.0.0.1:8080/asynchPeople/ adresinde diğer kayıtlı kullanıcıları listeleyebilirsiniz.
Düz metin gizli bilgileri bulmak umuduyla yapı konsol çıktıları ve yapı ortam değişkenlerini dökmek için bu scripti kullanın.
Eğer ele geçirilen kullanıcı yeni bir Jenkins düğümü oluşturma/değiştirme için yeterli yetkiye sahipse ve diğer düğümlere erişim için SSH kimlik bilgileri zaten saklanıyorsa, bu kimlik bilgilerini çalabilir. Düğüm oluşturarak/değiştirerek ve kimlik bilgilerini kaydedecek bir ana bilgisayar ayarlayarak bunu gerçekleştirebilir, ana bilgisayar anahtarını doğrulamadan:
Jenkins ssh kimlik bilgilerini genellikle global sağlayıcıda (/credentials/
) bulabilirsiniz, bu nedenle diğer gizli bilgileri dökme şeklinizle bunları da dökebilirsiniz. Daha fazla bilgi için Gizli Bilgileri Dökme Bölümü.
Jenkins sunucusunda bir shell almak, saldırgana tüm gizli bilgileri ve env değişkenlerini sızdırma fırsatı verir ve aynı ağda bulunan diğer makineleri istismar etme veya hatta bulut kimlik bilgilerini toplama imkanı sağlar.
Varsayılan olarak, Jenkins SYSTEM olarak çalışır. Bu nedenle, onu ele geçirmek saldırgana SYSTEM ayrıcalıkları verecektir.
Proje oluşturma/düzenleme, Jenkins sunucusunda RCE elde etmenin bir yoludur:
Ayrıca, yeni bir proje oluşturmaktan daha gizli olabilecek bir Groovy script çalıştırarak RCE elde edebilirsiniz:
Ayrıca bir pipeline oluşturarak/düzenleyerek RCE elde edebilirsiniz:
Pipeline'ları istismar etmek için hala Jenkins'e erişiminiz olması gerekir.
Pipeline'lar, projelerde build mekanizması olarak da kullanılabilir. Bu durumda, pipeline sözdizimini içerecek depo içindeki bir dosya yapılandırılabilir. Varsayılan olarak /Jenkinsfile
kullanılır:
Ayrıca, pipeline yapılandırma dosyalarını başka yerlerde (örneğin, diğer depolarda) saklamak da mümkündür; bu, depo erişimini ve pipeline erişimini ayırma amacı taşır.
Eğer bir saldırgan o dosya üzerinde yazma erişimine sahipse, onu değiştirebilir ve pipeline'ı tetikleyebilir. Hatta Jenkins'e erişimi olmadan bile. Saldırganın bazı dal korumalarını atlatması gerekebilir (platforma ve kullanıcı ayrıcalıklarına bağlı olarak bunlar atlatılabilir veya atlatılamayabilir).
Özel bir pipeline'ı çalıştırmak için en yaygın tetikleyiciler şunlardır:
Ana dal için Pull request (veya potansiyel olarak diğer dallar için)
Ana dala Push (veya potansiyel olarak diğer dallar için)
Ana dalı güncelleyin ve bir şekilde çalıştırılmasını bekleyin
Eğer bir harici kullanıcıysanız, başka bir kullanıcı/organizasyonun reposunun ana dalına PR oluşturmayı ve pipeline'ı tetiklemeyi beklememelisiniz... ama eğer kötü yapılandırılmışsa, bunu istismar ederek şirketleri tamamen tehdit edebilirsiniz.
Önceki RCE bölümünde, bir pipeline'ı değiştirerek RCE elde etme tekniği zaten belirtilmişti.
Tüm pipeline için veya belirli aşamalar için düz metin env değişkenleri tanımlamak mümkündür. Bu env değişkenleri hassas bilgi içermemelidir, ancak bir saldırgan her zaman tüm pipeline yapılandırmalarını/Jenkinsfile'ları kontrol edebilir:
Jenkins'in gizli bilgileri genellikle nasıl ele aldığı hakkında bilgi için temel bilgilere göz atın:
Kimlik bilgileri küresel sağlayıcılara (/credentials/
) veya belirli projelere (/job/<project-name>/configure
) sınırlanabilir. Bu nedenle, hepsini dışarı aktarmak için gizli bilgileri içeren tüm projeleri en azından ele geçirmeniz ve özel/zehirli boru hatlarını çalıştırmanız gerekir.
Başka bir sorun var, bir boru hattının env'sinde bir gizli bilgi almak için gizli bilginin adını ve türünü bilmeniz gerekir. Örneğin, bir usernamePassword
gizli bilgisini string
gizli bilgisi olarak yüklemeye çalışırsanız bu hata ile karşılaşırsınız:
Burada bazı yaygın gizli türlerini yüklemenin yolu var:
Sayfanın sonunda tüm kimlik bilgisi türlerini bulabilirsiniz: https://www.jenkins.io/doc/pipeline/steps/credentials-binding/
Tüm gizli bilgileri bir kerede dökmenin en iyi yolu, Jenkins makinesini tehdit altına almaktır (örneğin, yerleşik düğümde ters bir shell çalıştırarak) ve ardından master anahtarlarını ve şifrelenmiş gizli bilgileri sızdırmak ve bunları çevrimdışı olarak çözmektir. Bunu nasıl yapacağınız hakkında daha fazla bilgi için Düğümler & Ajanlar bölümüne ve Sonrası Sömürü bölümüne bakın.
Belgelerden: triggers
direktifi, Pipeline'ın otomatik olarak yeniden tetiklenmesi gereken yolları tanımlar. GitHub veya BitBucket gibi bir kaynakla entegre olan Pipelinelar için, triggers
gerekli olmayabilir çünkü webhook tabanlı entegrasyon zaten mevcut olabilir. Mevcut tetikleyiciler cron
, pollSCM
ve upstream
'dir.
Cron örneği:
Check diğer örnekleri belgelerde.
Bir Jenkins örneği, farklı makinelerde çalışan farklı ajanlara sahip olabilir. Bir saldırgan perspektifinden, farklı makinelere erişim, çalıntı potansiyel bulut kimlik bilgileri veya diğer makineleri istismar etmek için kullanılabilecek farklı ağ erişimi anlamına gelir.
Daha fazla bilgi için temel bilgilere bakın:
Yapılandırılmış düğümleri /computer/
içinde listeleyebilirsiniz, genellikle Yerleşik Düğüm
(Jenkins'i çalıştıran düğüm) ve potansiyel olarak daha fazlasını bulacaksınız:
Yerleşik düğümü ele geçirmek özellikle ilginçtir çünkü hassas Jenkins bilgilerini içerir.
Yerleşik Jenkins düğümünde pipeline'ı çalıştırmak istediğinizi belirtmek için pipeline içinde aşağıdaki yapılandırmayı belirtebilirsiniz:
Belirli bir ajan içinde, bir cron tetikleyicisi ile, pipeline ve aşama ortam değişkenleri ile, bir adımda 2 değişken yükleyerek ve ters shell göndererek:
Yeterli izinleriniz varsa /credentials/
erişerek gizli anahtarları listeleyebilirsiniz. Bunun yalnızca credentials.xml
dosyasındaki gizli anahtarları listeleyeceğini unutmayın, ancak build yapılandırma dosyaları da daha fazla gizli anahtar içerebilir.
Eğer her projenin yapılandırmasını görebiliyorsanız, orada depo erişimi için kullanılan gizli anahtarların (gizli anahtarlar) ve projenin diğer gizli anahtarlarının isimlerini de görebilirsiniz.
Bu dosyalar Jenkins gizli anahtarlarını şifre çözmek için gereklidir:
secrets/master.key
secrets/hudson.util.Secret
Böyle gizli anahtarlar genellikle şunlarda bulunabilir:
credentials.xml
jobs/.../build.xml
jobs/.../config.xml
Onları bulmak için bir regex:
Eğer sırları çözmek için gereken şifreleri dökümlediyseniz, bu scripti kullanarak o sırları çözebilirsiniz. bu script
/var/lib/jenkins/config.xml
veya C:\Program Files (x86)\Jenkis\
içindeki Jenkins config.xml dosyasına erişin.
<useSecurity>true</useSecurity>
kelimesini arayın ve true
kelimesini false
olarak değiştirin.
sed -i -e 's/<useSecurity>true</<useSecurity>false</g' config.xml
Jenkins sunucusunu yeniden başlatın: service jenkins restart
Şimdi Jenkins portalına tekrar gidin ve bu sefer Jenkins herhangi bir kimlik bilgisi istemeyecek. Yönetim Jenkins bölümüne giderek yönetici şifresini tekrar ayarlayın.
Ayarları <useSecurity>true</useSecurity>
olarak değiştirerek güvenliği tekrar etkinleştirin ve Jenkins'i tekrar başlatın.
AWS Hacking öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE) GCP Hacking öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE)