Jenkins Security
Last updated
Last updated
Jenkins is 'n instrument wat 'n eenvoudige metode bied om 'n deurlopende integrasie of deurlopende aflewering (CI/CD) omgewing te skep vir byna enige kombinasie van programmeertaal en bronkode-opslagplaats met behulp van pyplyne. Verder outomatiseer dit verskeie gereelde ontwikkelingstake. Alhoewel Jenkins nie die behoefte om skripte vir individuele stappe te skep uitskakel nie, bied dit 'n vinniger en robuuster manier om die hele reeks bou-, toets- en implementeringshulpmiddels te integreer as wat mens maklik met die hand kan konstrueer.
Basic Jenkins InformationOm te soek na interessante Jenkins-bladsye sonder verifikasie soos (/people of /asynchPeople, wat die huidige gebruikers lys) kan jy gebruik:
Kyk of jy opdragte kan uitvoer sonder om verifikasie nodig te hê:
Sonner credentials kan jy binne die /asynchPeople/ pad of /securityRealm/user/admin/search/index?q= vir gebruikersname kyk.
Jy kan moontlik die Jenkins weergawe kry vanaf die pad /oops of /error
In die basiese inligting kan jy alle maniere om binne Jenkins in te teken nagaan:
Basic Jenkins InformationJy sal Jenkins-instansies vind wat jou toelaat om 'n rekening te skep en daarin in te teken. So eenvoudig soos dit.
Ook as SSO-funksionaliteit/plugins teenwoordig was, moet jy probeer om in te teken by die toepassing met 'n toetsrekening (d.w.s. 'n toets Github/Bitbucket-rekening). Truuk van hier.
Jenkins ontbreek aan 'n wagwoordbeleid en gebruikersnaam-bruteforce-mitigasie. Dit is noodsaaklik om gebruikers met bruteforce aan te val aangesien swak wagwoorde of gebruikersname as wagwoorde gebruik kan word, selfs omgekeerde gebruikersname as wagwoorde.
Gebruik hierdie Python-skrip of hierdie PowerShell-skrip.
Baie organisasies kombineer SaaS-gebaseerde bronbeheerstelsels (SCM) soos GitHub of GitLab met 'n interne, self-gehoste CI-oplossing soos Jenkins of TeamCity. Hierdie opstelling maak dit moontlik vir CI-stelsels om webhook-gebeure van SaaS-bronbeheerders te ontvang, hoofsaaklik vir die aktivering van pyplynwerk.
Om dit te bereik, witlys organisasies die IP-reeks van die SCM-platforms, wat hulle toegang gee tot die interne CI-stelsel via webhooks. Dit is egter belangrik om daarop te let dat enigiemand 'n rekening op GitHub of GitLab kan skep en dit kan konfigureer om 'n webhook te aktiveer, wat moontlik versoek na die interne CI-stelsel kan stuur.
In hierdie scenario's gaan ons aanneem dat jy 'n geldige rekening het om toegang tot Jenkins te verkry.
Afhanklik van die Gemagtiging meganisme wat in Jenkins gekonfigureer is en die toestemming van die gekompromitteerde gebruiker, kan jy wel of nie die volgende aanvalle uitvoer nie.
Vir meer inligting, kyk na die basiese inligting:
Basic Jenkins InformationAs jy toegang tot Jenkins het, kan jy ander geregistreerde gebruikers lys in http://127.0.0.1:8080/asynchPeople/
Gebruik hierdie skrip om boukonsole-uitsette en bou-omgewingsveranderlikes te dump om hopelik klaarteksgeheime te vind.
Indien die gekompromitteerde gebruiker genoeg voorregte het om 'n nuwe Jenkins-node te skep/wysig en SSH-legitimasie is reeds gestoor om toegang tot ander nodes te verkry, kan hy daardie legitimasie steel deur 'n node te skep/wysig en 'n gasheer in te stel wat die legitimasie sal opneem sonder om die gasheer sleutel te verifieer:
Jy sal gewoonlik Jenkins SSH-legitimasie vind in 'n globale verskaffer (/credentials/
), sodat jy hulle ook kan dump soos jy enige ander geheim sou dump. Meer inligting in die Afsnyt oor geheime dump.
Om 'n shell in die Jenkins-bediener te kry, gee die aanvaller die geleentheid om al die geheime en omgewingsveranderlikes te lek en om ander masjiene in dieselfde netwerk te uitbuit of selfs wolk-legitimasie te versamel.
Standaard sal Jenkins as SYSTEM uitgevoer word. Dus, om dit te kompromitteer, sal die aanvaller SYSTEM-voorregte gee.
Die skep/wysiging van 'n projek is 'n manier om RCE oor die Jenkins-bediener te verkry:
Jenkins RCE Creating/Modifying ProjectJy kan ook RCE verkry deur 'n Groovy-skrip uit te voer, wat dalk sluwer kan wees as om 'n nuwe projek te skep:
Jenkins RCE with Groovy ScriptJy kan ook RCE kry deur 'n pyplyn te skep/wysig:
Jenkins RCE Creating/Modifying PipelineOm pyplyne te benut, moet jy steeds toegang tot Jenkins hê.
Pyplyne kan ook gebruik word as boumeganisme in projekte, in daardie geval kan 'n lêer binne die bewaarplek gekonfigureer word wat die pyplyn sintaks bevat. Standaard word /Jenkinsfile
gebruik:
Dit is ook moontlik om pyplynkonfigurasie lêers op ander plekke te stoor (in ander bewaarplekke byvoorbeeld) met die doel om die bewaarplek toegang en die pyplyn toegang te skei.
As 'n aanvaller skryftoegang tot daardie lêer het, sal hy dit kan wysig en die pyplyn moontlik aanhits sonder om selfs toegang tot Jenkins te hê. Dit is moontlik dat die aanvaller die nodig sal hê om sekere takbeskermings te omseil (afhangende van die platform en die gebruiker se voorregte kan dit omseil word of nie).
Die mees algemene aanhitsers om 'n aangepaste pyplyn uit te voer is:
Pull versoek na die hooftak (of moontlik na ander takke)
Druk na die hooftak (of moontlik na ander takke)
Bespreek die hooftak en wag totdat dit op een of ander manier uitgevoer word
As jy 'n eksterne gebruiker is, moet jy nie verwag om 'n PR na die hooftak van die bewaarplek van 'n ander gebruiker/organisasie te skep en die pyplyn te aanhits nie... maar as dit sleg gekonfigureer is, kan jy maatskappye heeltemal kompromitteer deur dit te benut.
In die vorige RCE-afdeling is reeds 'n tegniek aangedui om RCE te kry deur 'n pyplyn te wysig.
Dit is moontlik om duidelike teks omgewingsveranderlikes vir die hele pyplyn of vir spesifieke fases te verklaar. Hierdie omgewingsveranderlikes moet nie sensitiewe inligting bevat nie, maar 'n aanvaller kan altyd al die pyplyn konfigurasies/Jenkins-lêers nagaan:
Vir inligting oor hoe geheime gewoonlik deur Jenkins hanteer word, kyk na die basiese inligting:
Basic Jenkins InformationKredensiale kan geskopeer word na globale verskaffers (/credentials/
) of na spesifieke projekte (/job/<project-name>/configure
). Daarom, om almal uit te voer, moet jy ten minste al die projekte wat geheime bevat, kompromiteer en aangepaste/vergiftigde pyplyne uitvoer.
Daar is nog 'n probleem, om 'n geheim binne die env van 'n pyplyn te kry, moet jy die naam en tipe van die geheim ken. Byvoorbeeld, as jy probeer om 'n usernamePassword
geheim as 'n string
geheim te laai, sal jy hierdie fout kry:
Hier het jy die manier om sekere algemene geheimtipes te laai:
Aan die einde van hierdie bladsy kan jy alle tipe geloofsbriewe vind: https://www.jenkins.io/doc/pipeline/steps/credentials-binding/
Die beste manier om alle geheime terselfdertyd te dump is deur die Jenkins-masjien te kompromiteer (deur byvoorbeeld 'n omgekeerde dop in die ingeboude node te hardloop) en dan die meestersleutels en die versleutelde geheime te lek en dit aflyn te ontsluit. Meer hieroor in die Nodes & Agents-afdeling en in die Post Exploitation-afdeling.
Van die dokumentasie: Die triggers
riglyn definieer die geoutomatiseerde maniere waarop die Pyplyn heraangestuur moet word. Vir Pyplyne wat geïntegreer is met 'n bron soos GitHub of BitBucket, mag triggers
nie nodig wees nie, aangesien webhooks-gebaseerde integrasie waarskynlik reeds teenwoordig sal wees. Die tans beskikbare aanlokkinge is cron
, pollSCM
en upstream
.
Cron-voorbeeld:
Kyk na ander voorbeelde in die dokumente.
'n Jenkins-instansie mag verskillende agente hê wat op verskillende rekenaars loop. Vanuit 'n aanvaller se perspektief, toegang tot verskillende rekenaars beteken verskillende potensiële wolklegitimasie om te steel of verskillende netwerktoegang wat misbruik kan word om ander rekenaars te benut.
Vir meer inligting, kyk na die basiese inligting:
Basic Jenkins InformationJy kan die gekonfigureerde nodes in /rekenaar/
opnoem, jy sal gewoonlik die **Ingeboude Node
** (wat die node is wat Jenkins hardloop) en moontlik meer vind:
Dit is veral interessant om die Ingeboude node te kompromiteer omdat dit sensitiewe Jenkins-inligting bevat.
Om aan te dui dat jy die pipeline in die ingeboude Jenkins-node wil hardloop, kan jy binne die pipeline die volgende konfigurasie spesifiseer:
Pyplyn in 'n spesifieke agent, met 'n cron-aanvraag, met pyplyn- en stadium-omgewingsveranderlikes, wat 2 veranderlikes in 'n stap laai en 'n omgekeerde dop stuur:
Jy kan die geheime lys deur /credentials/
te benader as jy genoeg toestemmings het. Let daarop dat dit slegs die geheime binne die credentials.xml
lêer sal lys, maar boukonfigurasie-lêers kan ook meer geloofsbriewe hê.
As jy die konfigurasie van elke projek kan sien, kan jy ook daar sien die name van die geloofsbriewe (geheime) wat gebruik word om die argief te benader en ander geloofsbriewe van die projek.
Hierdie lêers is nodig om Jenkins-geheime te ontsleutel:
secrets/master.key
secrets/hudson.util.Secret
Sodanige geheime kan gewoonlik gevind word in:
credentials.xml
jobs/.../build.xml
jobs/.../config.xml
Hier is 'n regex om hulle te vind:
Indien jy die nodige wagwoorde om die geheime te ontsluit gedump het, gebruik hierdie skripsie om daardie geheime te ontsluit.
Toegang tot die Jenkins config.xml-lêer in /var/lib/jenkins/config.xml
of C:\Program Files (x86)\Jenkis\
Soek na die woord <useSecurity>true</useSecurity>
en verander die woord true
na false
.
sed -i -e 's/<useSecurity>true</<useSecurity>false</g' config.xml
Herlaai die Jenkins-bediener: service jenkins restart
Gaan nou weer na die Jenkins-portaal en Jenkins sal hierdie keer nie enige geloofsbriewe vra nie. Navigeer na "Bestuur Jenkins" om die administrateurswagwoord weer in te stel.
Aktiveer die sekuriteit weer deur instellings te verander na <useSecurity>true</useSecurity>
en herlaai die Jenkins weer.