atlasvector/kestra-cve-2026-53576CVE-2026-53576 का एंड-टू-एंड पुनरुत्पादन और क्रॉस-लेयर डिटेक्शन, जो Kestra में अनऑथेंटिकेटेड RCE है — इसे बेस PoC से आगे ले जाकर यह दिखाया गया है कि कैसे एक सामान्य Docker-socket मिसकॉन्फ़िगरेशन container-root को पूर्ण host compromise में बदल देता है।
Kestra, एक ओपन-सोर्स वर्कफ़्लो ऑर्केस्ट्रेशन प्लेटफ़ॉर्म, ने एक ऑथेंटिकेशन फ़िल्टर भेजा जो यह तय करता था कि किसी अनुरोध को क्रेडेंशियल्स की आवश्यकता है या नहीं, यह जाँच करके कि URL /configs पर समाप्त होता है या नहीं - यह जाँच एक हानिरहित सार्वजनिक एंडपॉइंट को उजागर करने के लिए थी।
चूँकि जाँच केवल स्ट्रिंग के अंत को देखती थी, कोई भी अनुरोध जिसका URL उस तरह से समाप्त होता था, ऑथेंटिकेशन को पूरी तरह से छोड़ देता था, जिसमें वे एंडपॉइंट भी शामिल थे जो मनमाना कोड बनाते और चलाते हैं। परिणाम: कोई भी व्यक्ति जो नेटवर्क पर एक कमज़ोर Kestra इंस्टेंस तक पहुँच सकता है, शून्य क्रेडेंशियल्स के साथ root के रूप में कमांड चला सकता है, कोई फ़िशिंग नहीं, कोई पासवर्ड अनुमान नहीं, कोई विशेषाधिकार वृद्धि चरण आवश्यक नहीं।
इस अभ्यास में, उस एकल अंतराल को एक स्व-होस्टेड लैब इंस्टेंस के विरुद्ध शुरू से अंत तक निभाया गया:
प्रत्येक चरण को रक्षात्मक टेलीमेट्री (नेटवर्क IDS, होस्ट रनटाइम सुरक्षा, Linux ऑडिट, और सिस्टम लॉग) के विरुद्ध कैप्चर किया गया।
यदि अनपैच्ड छोड़ा जाए तो व्यावसायिक प्रभाव: Kestra चलाने वाले होस्ट का पूर्ण समझौता, केवल एप्लिकेशन का नहीं - और विस्तार से उस होस्ट से पहुँचने योग्य किसी भी अन्य चीज़ का भी।
समाधान: Kestra 1.0.45 / 1.3.21 या बाद के संस्करण में अपग्रेड करें (अकेला पैच प्राथमिक भेद्यता को बंद कर देता है; वृद्धि और दृढ़ता के चरणों के लिए एक अलग, स्वतंत्र समाधान की आवश्यकता होती है - Docker सॉकेट को एप्लिकेशन कंटेनरों में माउंट न करें, अनुभाग 8 देखें)।
यह रिपोर्ट CVE-2026-53576 का दस्तावेज़ीकरण करती है, जो Kestra ≤1.3.20 में एक CVSS 10.0 अनऑथेंटिकेटेड रिमोट कोड निष्पादन भेद्यता है, जो एक पाथ-सफ़िक्स ऑथेंटिकेशन बायपास (AuthenticationFilter.java, endsWith("/configs")) के कारण होती है।
एक हमलावर जो किसी वर्कफ़्लो का नेमस्पेस और ID configs नाम देता है, बिना क्रेडेंशियल्स के, Kestra कंटेनर के अंदर root के रूप में मनमाना शेल कमांड बना और चला सकता है। 1.0.45 और 1.3.21 में ठीक किया गया। यही बग स्वतंत्र रूप से CVE-2026-49869 के अंतर्गत भी रिपोर्ट किया गया था, जो CISA KEV-सूचीबद्ध संख्या है जो वास्तविक इन-द-वाइल्ड शोषण से जुड़ी है। दोनों को एक साथ उद्धृत किया जाना चाहिए, क्योंकि सार्वजनिक स्रोत और स्कैनर या तो किसी एक का संदर्भ दे सकते हैं।
| कमज़ोर | Kestra ≤ 1.3.20 (और 1.0.x लाइन पर pre-1.0.45) |
| ठीक किया गया | 1.0.45 / 1.3.21+ |
| CVE | CVE-2026-53576 |
| जुड़वाँ सलाह | CVE-2026-49869 - वही बग, CISA KEV-सूचीबद्ध (इन-द-वाइल्ड) |
| दिनांक | घटना |
|---|---|
| 2026-06-02 | Kestra 1.3.21 जारी; चेंजलॉग "ऑथेंटिकेशन फ़िल्टर में संभावित ऑथेंटिकेशन बायपास" का संदर्भ देता है |
| 2026-06-03 | Kestra 1.0.45 1.0.x लाइन पर जारी |
| 2026-09-02 | CVE-2026-49869 (जुड़वाँ सलाह) CISA KEV कैटलॉग में जोड़ा गया |
| 2026-09-22 से 09-24 | यह लैब प्रतिकृति, डिटेक्शन बिल्ड, और क्रॉस-लेयर सत्यापन |
स्व-होस्टेड होमलैब:
- Debian होस्ट (होस्टनाम docker, कर्नेल 6.12.107+deb13-amd64),
- Docker Engine 29.8.1।
- Kestra आधिकारिक kestra/kestra:v1.3.20 इमेज के रूप में तैनात, kestra.int.atlasvec.com पर एक Caddy रिवर्स प्रॉक्सी के माध्यम से पहुँच योग्य।
- परीक्षण के अंतर्गत टेलीमेट्री स्टैक: Falco (रनटाइम/eBPF, होस्ट-स्तर),
- Suricata 8.0.3 IDS (निष्क्रिय SPAN मिरर), Splunk की ओर अग्रेषित।
कुछ भी छूने से पहले, मैंने पुष्टि की कि लक्ष्य वास्तव में कमज़ोर था और टेलीमेट्री स्टैक सक्रिय था। मैंने हमले-पूर्व स्थिति का स्नैपशॉट भी लिया ताकि काम पूरा होने पर मैं वापस लौट सकूँ।
Kestra कमज़ोर संस्करण चला रहा है:
कंटेनर स्वयं, चालू और पहुँच योग्य:
होस्ट पर लोड किए गए Falco के यूनिट:
Falco सक्रिय रूप से इवेंट उत्सर्जित कर रहा है (आधुनिक eBPF मोड):
Suricata की सेवा सक्रिय:
और इसका eve.json लाइव इवेंट लिख रहा है:
यह दो गलतियाँ हैं जो एक साथ मिलती हैं, एक नहीं।
पहला, ऑथेंटिकेशन फ़िल्टर यह तय करता है कि कोई अनुरोध ऑथ को छोड़ सकता है या नहीं, यह अनुरोध पथ के अंत से मिलान करके करता है:```java // AuthenticationFilter.java — the vulnerable check, confirmed against the self-hosted v1.3.20 source if (path.endsWith("/configs")) { // treated as a public, unauthenticated path }
यह जाँच एक हानिरहित एंडपॉइंट, सार्वजनिक इंस्टेंस कॉन्फ़िग को उजागर करने के लिए मौजूद है। चूँकि `endsWith` केवल स्ट्रिंग के अंत को पढ़ता है, यह एक सुरक्षित पथ को किसी अन्य पथ से अलग नहीं बता सकता जो संयोगवश उसी तरह समाप्त होता है।
दूसरा, Kestra का राउटर अभी भी उन मिलते-जुलते पथों को उनके वास्तविक, संवेदनशील हैंडलरों तक पहुँचाता है। `/api/v1/main/flows/configs` फ़्लो-क्रिएट हैंडलर तक पहुँचता है। `/api/v1/main/executions/configs/configs` एक्ज़ीक्यूशन हैंडलर तक पहुँचता है। फ़िल्टर दोनों को सार्वजनिक के रूप में पास कर देता है, और राउटर उन्हें वैसे भी चलाता है। किसी फ़्लो के namespace और ID को `configs` नाम दें, और एक कोड-निष्पादक एंडपॉइंट अब `/configs` पर समाप्त होता है, इसलिए यह सार्वजनिक पथ के मुफ़्त पास को विरासत में ले लेता है।
कैप्चर किया गया अनुरोध युग्म इसे स्पष्ट रूप से दिखाता है। बिना क्रेडेंशियल के `GET /api/v1/main/flows/search` `401` लौटाता है। उसी खाली auth हेडर के साथ `POST /api/v1/main/flows/configs` `200` लौटाता है और फ़्लो को संग्रहीत करता है (§5.1 देखें)।
## 5. हमला सिमुलेशन
> नीचे दिया गया प्रत्येक चरण अपने स्वयं के स्क्रीनशॉट के साथ कैप्चर किया गया है। यह सब मेरे अपने पृथक homelab के अंदर, रिवर्स प्रॉक्सी के पीछे स्व-होस्टेड Kestra इंस्टेंस के विरुद्ध चलता है।
### 5.1 चरण 1 - auth bypass -> Kestra कंटेनर के अंदर root
**नियंत्रण :** बिना क्रेडेंशियल के `GET /api/v1/main/flows/search` → `401 Unauthorized`।
पुष्टि करता है कि सामान्य रूट पर auth लागू है।
_____
**रोपण :** बिना auth हेडर के `POST /api/v1/main/flows/configs` भेजना। बॉडी एक फ़्लो YAML है जिसका `namespace` और `flow id` दोनों `configs` हैं, जिसमें एक Commands टास्क है जो Process टास्क रनर का उपयोग करता है। सर्वर `200 OK` लौटाता है और फ़्लो को संग्रहीत करता है। अन्यथा संरक्षित रूट पर `/configs` प्रत्यय ही बायपास को ट्रिगर करता है **(धारा 4 देखें)।**
**सुनें और प्रतीक्षा करें** : परीक्षण उद्देश्यों के लिए nc का उपयोग करके सरल लिसनर शुरू करना, ताकि हम रिवर्स शेल को पकड़ सकें।
**ट्रिगर / निष्पादन** `POST /api/v1/main/executions/configs/configs`, बिना auth हेडर → `200 OK`, नया एक्ज़ीक्यूशन बनाया गया।
**BaaaaM :** हमने शेल पॉप कर लिया है, लेकिन याद रखें - हम "पृथक" हैं, `root` **लेकिन** Kestra docker कंटेनर के अंदर, इसलिए हमें यहाँ से "निकलने" में सक्षम "नहीं" होना चाहिए। "**खैर, मैंने यही सोचा था**"
टास्क का कमांड Kestra JVM प्रक्रिया के सीधे चाइल्ड के रूप में चलता है, जिसकी पुष्टि होस्ट-साइड प्रक्रिया ट्री के माध्यम से होती है, और Kestra के स्वयं के एक्ज़ीक्यूशन लॉग के अनुसार सफलतापूर्वक पूर्ण होता है।
**Kestra का लॉग्स डैशबोर्ड**
**Kestra का प्रक्रिया ट्री**
**परिणाम:** Kestra कंटेनर के अंदर root के रूप में अनधिकृत रिमोट कोड निष्पादन। यह **CVE-2026-53576** का पूर्ण, स्व-निहित प्रमाण है।
### 5.2 चरण 2 - उजागर Docker सॉकेट के माध्यम से एस्केलेशन (homelab-विशिष्ट, CVE का हिस्सा नहीं)
चरण 1 शेल से, `/var/run/docker.sock` कंटेनर में माउंट किया हुआ पाया गया - एक Docker-outside-of-Docker (DooD) पैटर्न, जो सामान्य है जब Kestra का स्वयं का `Docker` टास्क रनर कॉन्फ़िगर किया जाता है, क्योंकि इसे बात करने के लिए एक डेमॉन की आवश्यकता होती है।
उस सॉकेट तक पहुँचना ही होस्ट **root** के बराबर है: Docker API एक क्लाइंट को उन कंटेनरों के लिए मनमाने होस्ट बाइंड माउंट और होस्ट PID/नेटवर्क नेमस्पेस कॉन्फ़िगर करने देता है जिन्हें वह स्पॉन करता है, और सॉकेट के पीछे का डेमॉन पहले से ही होस्ट पर root के रूप में चलता है।
यह कर्नेल या कंटेनर-एस्केप एक्सप्लॉइट नहीं है - यह Docker API वही कर रहा है जो करने के लिए इसे डिज़ाइन किया गया है, ऐसी जगह से पहुँचा गया जहाँ से इसे पहुँच योग्य नहीं होना चाहिए था।
सॉकेट का उपयोग करके, मैंने होस्ट फ़ाइलसिस्टम को बाइंड करके और होस्ट PID और नेटवर्क नेमस्पेस के साथ एक सहोदर कंटेनर बनाया, फिर उसे शुरू किया।
**नोट:** परीक्षण के दौरान एक दूसरा, अधिक शांत प्रकार भी सामने आया, हालाँकि मैंने इसे अलग से स्क्रीनशॉट नहीं लिया। हमेशा एक नया सहोदर कंटेनर बनाने के बजाय, वही सॉकेट एक्सेस आपको पहले से चल रहे कंटेनर के विरुद्ध `POST /containers/{id}/exec` चलाने देता है, इसलिए कोई कंटेनर-क्रिएट इवेंट बिल्कुल नहीं होता। इस Docker होस्ट पर मेरे पास Kestra और Portainer दोनों हैं, जिनमें से किसी का भी उपयोग मैं उसी एस्केप के लिए कर सकता हूँ। यह डिटेक्शन के लिए मायने रखता है: नया विशेषाधिकार प्राप्त कंटेनर बनाए जाने पर केंद्रित कोई भी नियम इस प्रकार को चूक जाता है।
root की पुष्टि करना और सॉकेट को वहाँ पड़ा हुआ, किसी भी प्रतिबंध से अनमाउंटेड पाना:
जाँचना कि Docker डेमॉन वास्तव में सॉकेट के माध्यम से पहुँच योग्य है:
सूचीबद्ध करना कि कौन सी इमेज पहले से लोकल हैं, ताकि मुझे कुछ भी पुल करने की आवश्यकता न हो:
पहला प्रयास: होस्ट फ़ाइलसिस्टम को बाइंड करके एक विशेषाधिकार प्राप्त कंटेनर:
दूसरा प्रयास, इस बार होस्ट PID और नेटवर्क नेमस्पेस जोड़ना:
तीसरा प्रयास, सीधे माउंटेड होस्ट फ़ाइलसिस्टम में chroot करना:
लिसनर तैयार और उस पोर्ट पर प्रतीक्षा कर रहा है जिस पर एस्केप शेल कॉलबैक करेगा:
कंटेनर शुरू करना:
**Root, लेकिन इस बार यह होस्ट है, कंटेनर नहीं:**
कर्नेल संस्करण वास्तविक होस्ट से मेल खाता है, कंटेनर के पृथक दृश्य से नहीं:
शेष सत्र के लिए एक उचित इंटरैक्टिव शेल में अपग्रेड करना:
### 5.3 चरण 3 - दृढ़ता, पुष्टि की गई फायरिंग
होस्ट-root शेल से मैंने दो स्वतंत्र दृढ़ता तंत्र स्थापित किए,
**पहला**, एक SSH कुंजी। मैंने जाँचा कि पहले से किसकी पहुँच थी :
फिर sshd के स्वयं के कॉन्फ़िग में जाँचा कि कुछ भी नई कुंजी को अवरुद्ध करेगा या नहीं:
हमलावर बॉक्स पर एक कीपेयर जनरेट किया:
पुष्टि की कि sshd वास्तव में सुन रहा था:
सार्वजनिक कुंजी को root के `authorized_keys` में डाला:
और मेल खाती निजी कुंजी के साथ लॉग इन किया:
**PS:** यह मूल RCE श्रृंखला से स्वतंत्र root एक्सेस है। भले ही Kestra को पैच कर दिया जाए, यह कुंजी अभी भी काम करती है।
**दूसरा**, एक cron बीकन। मैंने एक अंतराल पर चलने के लिए सेट एक root-स्तरीय कॉलबैक डाला, फिर यह देखने के लिए एक नए लिसनर के साथ परीक्षण किया कि यह वास्तव में निर्धारित समय पर फायर होता है या नहीं:
**यह फायर हुआ। होस्ट पर एक दूसरा फुटहोल्ड, RCE और SSH कुंजी दोनों से स्वतंत्र।**
### 5.4 सत्यापित kill-chain टाइमलाइन।
नीचे दी गई टाइमलाइन अलग है: यह पूरी तरह से स्वतंत्र डिफेंडर-साइड टेलीमेट्री (नेटवर्क IDS + होस्ट रनटाइम सुरक्षा) से पुनर्निर्मित है, जिसे वास्तविक Splunk डेटा के विरुद्ध लाइव खींचा और मान्य किया गया।
**प्राथमिक RCE - नेटवर्क डिलीवरी का पता लगाता है, होस्ट निष्पादन की पुष्टि करता है, 103 सेकंड का अंतर:**
| समय (EDT) | परत | घटना |
| ------------ | ------------------ | -------------------------------------------------------------------------------------------- |
| 02:46:09.778 | नेटवर्क (Suricata) | इस सटीक CVE के लिए सार्वजनिक ET हस्ताक्षर फायर होता है |
| 02:47:52.277 | होस्ट (Falco) | Kestra कंटेनर के अंदर रिवर्स शेल की पुष्टि, सटीक कमांड और कंटेनर ID कैप्चर किया गया |
**एस्केलेशन - नेटवर्क और होस्ट प्रत्येक स्वतंत्र रूप से एक ही घटना के एक अलग हिस्से की पुष्टि करते हैं:**
| समय (EDT) | परत | घटना |
| ------------ | ------------------ | ---------------------------------------------------------------------------------------------------------------------------------- |
| 03:48:55.503 | होस्ट (Falco) | एस्केलेशन कंटेनर से रिवर्स शेल |
| 03:51:57.360 | नेटवर्क (Suricata) | TCP फ़्लो **और** एक सामग्री-आधारित अलर्ट - जब `id` चलाया गया तो होस्ट से सादे टेक्स्ट में निकलती शाब्दिक स्ट्रिंग `uid=0(root)` देखी गई |
## 6. डिटेक्शन इंजीनियरिंग
मैंने वास्तविक कैप्चर की गई टेलीमेट्री के विरुद्ध डिटेक्शन बनाए, फिर प्रत्येक को एक रीप्ले के विरुद्ध परीक्षण किया। मैट्रिक्स दिखाता है कि मेरे शुरू करने से पहले कवरेज कहाँ मौजूद थी और कहाँ नहीं।
### 6.0 डिटेक्शन कवरेज मैट्रिक्स
| चरण | नेटवर्क (Suricata) | होस्ट (Falco) | होस्ट (auditd/journald) | स्थिति |
| --- | --- | --- | --- | --- |
| प्रारंभिक एक्सप्लॉइट अनुरोध | सार्वजनिक ET हस्ताक्षर फायर होता है | कोई ऐप-लेयर दृश्यता नहीं | - | कवर (पूर्व-मौजूद) |
| RCE निष्पादन | - | नेटिव नियम, T1059-टैग किया गया | - | कवर (पूर्व-मौजूद) |
| Docker-सॉकेट एस्केलेशन (तकनीक) | - | अंतराल: केवल परिणामी शेल को पकड़ता है, सॉकेट-दुरुपयोग API कॉल को नहीं | EXECVE रिकॉर्ड सटीक `curl --unix-socket` कॉल कैप्चर करते हैं | अंतराल पाया गया, auditd + एक कस्टम Falco नियम के साथ बंद किया गया |
| एस्केलेशन प्रभाव पुष्टि | लीक हुए `id` आउटपुट पर सामग्री अलर्ट | वही सामान्य शेल नियम | - | कवर (पूर्व-मौजूद, क्रॉस-लेयर) |
| SSH दृढ़ता | - | - | journald: पूर्ण PAM जीवनचक्र और कुंजी फिंगरप्रिंट | कवर (केवल-होस्ट) |
| Cron दृढ़ता | - | - | journald और linux_audit, दो स्रोत, सटीक 5-मिनट कैडेंस | कवर (केवल-होस्ट) |
अंतराल docker-सॉकेट एस्केलेशन है। Falco के डिफ़ॉल्ट नियम एक समझौता किए गए कंटेनर द्वारा स्पॉन किए गए शेल को पकड़ते हैं, लेकिन स्थिर डिफ़ॉल्ट सेट में कुछ भी Docker API को सीधे चलाने के लिए `/var/run/docker.sock` तक पहुँचने वाली प्रक्रिया को फ़्लैग नहीं करता। जो नियम विशेषाधिकार प्राप्त-कंटेनर लॉन्च को छूते हैं, `Launch Privileged Container` और `Launch Sensitive Mount Container`, `incubating` और `sandbox` परिपक्वता पर आते हैं, इसलिए डिफ़ॉल्ट नियमसेट उन्हें भी लोड नहीं करता। मैंने अंतराल को एक auditd सहसंबंध खोज (डिटेक्शन 03) और एक कस्टम Falco नियम (§6.3) के साथ बंद किया।
### 6.1 Splunk - पाँच सहसंबंध खोजें, तैनात और शेड्यूल की गईं
सभी पाँच Splunk में लाइव चलती हैं (`*/5 * * * *`, अलर्ट ट्रैकिंग सक्षम, प्रति-फ़ील्ड थ्रॉटलिंग), न कि केवल लिखी गई और टेक्स्ट के रूप में छोड़ी गईं। प्रत्येक के लिए पूर्ण SPL, सटीक FP नोट्स, गंभीरता, MITRE टैग, और प्रतिक्रिया रनबुक `detections/splunk/*.spl` में हैं। नीचे दी गई स्थिति तालिका प्रत्येक के लिए लाइव-परीक्षण किया गया परिणाम है, जिसमें एक वास्तविक बग भी शामिल है जो मैंने पाया और ठीक किया।
| # | डिटेक्शन | MITRE | स्थिति |
| --- | ---------------------------------------------------------- | -------------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
| 01 | नेटवर्क एक्सप्लॉइट हस्ताक्षर (Suricata ET अलर्ट का उपभोग करता है) | T1190 | **फायर हुआ** - ऐतिहासिक रीप्ले की पुष्टि, तब से कोई नई घटना नहीं (वर्तमान लुकबैक के बाहर) |
| 02 | होस्ट RCE निष्पादन (Falco रीडायरेक्ट-टू-नेटवर्क नियम) | T1059 | **फायर हुआ** - ऐतिहासिक रीप्ले की पुष्टि |
| 03 | Docker-सॉकेट दुरुपयोग (auditd, अंतराल-बंद करने वाला) | T1610, T1611 | **लाइव शेड्यूलर पर ही फायर हुआ** - वास्तविक `*/5 * * * *` रन पर `triggered_alert_count: 1` की पुष्टि, न कि केवल मैनुअल परीक्षण |
| 04 | SSH root-लॉगिन दृढ़ता | T1098.004, T1021.004 | **फायर हुआ** - ऐतिहासिक रीप्ले की पुष्टि |
| 05 | Cron-बीकन दृढ़ता | T1053.003 | **एक बग के साथ तैनात जिसे मैंने पाया और लाइव ठीक किया।** `-10m` डिस्पैच विंडो में तीन 5-मिनट बकेट में से केवल दो थे जिनकी `distinct_intervals >= 3` थ्रेशोल्ड को आवश्यकता है, इसलिए यह वास्तविक डेटा में बीकन के अभी भी चलने के बावजूद कभी फायर नहीं हो सकता था। इसे `-30m` तक चौड़ा किया और पुनः तैनात किया - और शेड्यूलर ने तब से इसे 53 बार फायर किया है, इसलिए फिक्स टिका हुआ है। |
डिटेक्शन 03 का श्रम विभाजन जानबूझकर है: SPL में Suricata के स्वयं के हस्ताक्षर तर्क को पुनः लागू करने के बजाय, या Falco को सॉकेट-स्तरीय तकनीक पकड़ने की कोशिश करने के बजाय जिसके लिए इसे नहीं बनाया गया था, यहाँ SIEM परत सटीक `curl --unix-socket` कॉल के auditd के EXECVE रिकॉर्ड का उपभोग करती है - इस विशिष्ट तकनीक के लिए सबसे विश्वसनीय साबित हुआ टेलीमेट्री स्रोत।
1. **डिटेक्शन 01** - ET हस्ताक्षर फायरिंग (`suricata:eve` अलर्ट):```spl
index=main sourcetype=suricata:eve event_type=alert
alert.signature="ET WEB_SPECIFIC_APPS Kestra Unauthenticated Remote Code Execution (CVE-2026-53576)"
| stats count min(_time) as first_seen max(_time) as last_seen
values(src_ip) as source_ips
by dest_ip dest_port
| eval first_seen=strftime(first_seen,"%Y-%m-%d %H:%M:%S")
| eval last_seen=strftime(last_seen,"%Y-%m-%d %H:%M:%S")
Detection 02 - Falco का redirect-to-network नियम, प्रति कंटेनर अलग-अलग। Source IP, Kestra कंटेनर के bridge address (172.17.0.3, port 4489 पर primary RCE) से होस्ट स्वयं (172.66.66.67, port 4491 पर escalation) की ओर शिफ्ट होता है - कंटेनर-से-होस्ट escalation दृश्यमान हो जाता है - जबकि destination स्थिर रहता है: 172.66.66.125 पर हमलावर का listener:
Detection 03 - curl --unix-socket docker.sock के auditd EXECVE रिकॉर्ड:
Detection 04 - journald root SSH लॉगिन, key fingerprint कैप्चर किया गया:
Detection 05 - छिपी हुई dotfile cron beacon (/usr/local/bin/.sysmon) जो root के रूप में ठीक 5-मिनट की cadence पर चल रही है: ~6.5 घंटों (04:30-11:00 EDT) में 79 अलग-अलग अंतराल। distinct_intervals >= 3 threshold ही एक periodic beacon को one-off cron job से अलग करता है:
सभी पाँच scheduled saved searches (*/5 * * * *) के रूप में deploy किए गए:
प्रमाण कि cron scheduler वास्तव में इन्हें चलाता है, केवल यह नहीं कि वे मौजूद हैं: सभी पाँच 54 बार execute हुए। Detection 03 एक बार fire हुआ (docker-socket का दुरुपयोग, 06:35 EDT) और Detection 05 53 बार fire हुआ (अभी भी सक्रिय cron beacon)। Detections 01/02/04 में 0 fires दिखते हैं क्योंकि वे one-time historical events हैं (exploit request, RCE, SSH login) जो -10m lookback से बाहर हो चुके हैं, जबकि कोई live या recurring instance अभी भी alert करेगा:
/dev/tcp/ reverse-shell pattern - जो primary RCE और escalation callback दोनों में उपयोग हुआ। SigmaHQ इसके लिए एक नियम देता है: "Suspicious Reverse Shell Command Line" (id 738d9bcf-6999-4fdb-b4ac-3033037db8ab, Florian Roth द्वारा Nextron Systems में), और इसके keywords में से एक है bash -i >& /dev/tcp/ - ठीक वही जो हमारे capture में दिखा।
तो मैंने उस नियम को बिना बदलाव के लिया (detections/sigma/lnx_shell_susp_rev_shells.yml) और इसके keyword को उसी Falco event पर जाँचा जिसे Detection 02 पहले ही कैप्चर कर चुका था। Sigma अपने आप "fire" नहीं होता - यह एक portable signature है, चलने वाला engine नहीं - लेकिन मैं दिखा सकता हूँ कि इसका keyword किसी textbook उदाहरण के बजाय इस run की वास्तविक telemetry पर लगता है।
सार्वजनिक SigmaHQ नियम "Suspicious Reverse Shell Command Line" - इसका bash -i >& /dev/tcp/ keyword, Detection 02 के समान वास्तविक event पर:
detections/falco/docker_socket_abuse.yaml - live Falco instance पर deploy किया गया और वास्तविक replay पर firing की पुष्टि हुई, 2026-09-24T10:27:29Z।
Falco का default ruleset इसे कवर नहीं करता। किसी process का /var/run/docker.sock तक पहुँचना detect करना कोई नई बात नहीं है - Sysdig के स्वयं के Falco उदाहरण इसे socket path पर open_write देखकर करते हैं - लेकिन shipped/default set में ऐसा कोई नियम नहीं है (project के पास इसके लिए एक खुला अनुरोध है, falcosecurity/falco #2940), और एकमात्र निकटवर्ती default नियम केवल docker/kubectl CLIs को पकड़ता है, raw curl --unix-socket को नहीं।
पेच यह है: वह मानक open_write-on-the-socket दृष्टिकोण इस setup में fire नहीं हुआ - modern_bpf और passive mirror के साथ, socket तक connect() के ज़रिए पहुँचा जाता है, open() के ज़रिए नहीं। इसलिए मैं spawn के समय process command line पर match करता हूँ (spawned_process + proc.cmdline contains "docker.sock"), वही event class जिसे Falco यहाँ पहले से ही विश्वसनीय रूप से handle करता है। यह प्रति call दो बार fire होता है - shell wrapper और curl leaf - पूर्ण context के साथ:```
priority=Critical, container_id=d417e027d444, image=kestra/kestra:v1.3.20, user=root, cmdline="curl -s --unix-socket /var/run/docker.sock http://localhost/version", tags=[T1610, T1611]
कस्टम Falco नियम फायरिंग - "Unexpected Process Accessing Docker Socket" (T1610/T1611):
फायर हुए स्टॉक Falco नियम - डिफ़ॉल्ट सेट में कोई docker-socket नियम नहीं है, यही अंतराल है:
### 6.4 Suricata - मौजूदा सार्वजनिक कवरेज, कस्टम नियम स्थगित
प्राथमिक एक्सप्लॉइट के लिए नेटवर्क लेयर पहले से ही एक सार्वजनिक Emerging Threats सिग्नेचर द्वारा कवर की गई है, `ET WEB_SPECIFIC_APPS Kestra Unauthenticated Remote Code Execution (CVE-2026-53576)`, जो Phase 2 के दौरान वास्तविक ट्रैफ़िक पर फायर हुआ।
नीचे वही बायपास नेटवर्क लेयर पर देखा गया है, और मैंने क्वेरी को भेद्यता पैटर्न से बनाया। `flows` या `executions` एंडपॉइंट पर जिस भी रिक्वेस्ट का पाथ `/configs` पर समाप्त होता था, वह `200` लौटाती थी, जबकि एक सामान्य रूट (`/flows/search`) अपेक्षित `401` लौटाता था।
`Attacker IP (XFF)` कॉलम वास्तविक HTTP ओरिजिन है, जो `X-Forwarded-For` हेडर से पढ़ा गया: `10.10.10.106`, मेरा Mac जिस पर Burp चल रहा था। Suricata का अपना `src_ip` केवल रिवर्स-प्रॉक्सी हॉप (`172.66.66.1`) देखता है। यह उस `172.66.66.125` Kali बॉक्स से अलग मशीन है जिसने बाद में रिवर्स शेल पकड़े और SSH लॉगिन किया, इसलिए HTTP एक्सप्लॉइट और कॉलबैक अलग-अलग होस्ट से आए।
### 6.5 डैशबोर्ड
`cve_2026_53576_kill_chain` Splunk पर डिप्लॉय किया गया है और इसमें शामिल हैं: हेडलाइन KPIs (डिटेक्शन लेयर, ATT&CK तकनीकें, डिप्लॉय किए गए डिटेक्शन, पर्सिस्टेंस मेकैनिज़्म), टेलीमेट्री लेयर द्वारा रंगा गया एक अटैक-टाइमलाइन कॉलम चार्ट, एक MITRE ATT&CK किल-चेन मैप जिसमें प्रत्येक चरण के लिए लाइव एविडेंस काउंट है, §5.4 से नेटवर्क-और-होस्ट सहसंबद्ध टाइमलाइन, शेड्यूल्ड सेव्ड सर्च द्वारा डिटेक्शन कवरेज, docker-socket तकनीक का विभाजन, और लॉग्स से लाइव खींची गई एक इंडिकेटर्स-ऑफ-कॉम्प्रोमाइज़ टेबल।
- KPIs, अटैक-टाइमलाइन चार्ट, और ATT&CK मैप की शुरुआत:
- ATT&CK मैप का शेष भाग, सहसंबद्ध किल-चेन, docker-socket विभाजन के बगल में डिटेक्शन कवरेज, और IOC टेबल:
## 7. ATT&CK मैपिंग
| Tactic | Technique | Evidence |
| -------------------- | --------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- |
| Initial Access | T1190 - Exploit Public-Facing Application | Control/plant/execute requests (§5.1); Suricata ET signature fire, §5.4 |
| Execution | T1059.004 - Command and Scripting Interpreter: Unix Shell | Kestra `Commands` task, host process tree (`07-kestra-process-tree.png`); Falco rule, §6.1 Detection 02 |
| Command and Control | T1095 - Non-Application Layer Protocol | Raw `/dev/tcp/` TCP reverse shell - no application-layer C2 framing used |
| Discovery | T1613 - Container and Resource Discovery | Docker image enumeration via the socket (`10-docker-images-enum.png`) |
| Privilege Escalation | T1610 - Deploy Container | Sibling container create/start via the Docker API (`11`–`15`); auditd EXECVE records, §6.1 Detection 03 |
| Privilege Escalation | T1611 - Escape to Host | Host-root confirmation, hostname/kernel match (`16`, `17`) |
| Persistence | T1098.004 - Account Manipulation: SSH Authorized Keys | Key implant to `/root/.ssh/authorized_keys` (`23`) |
| Lateral Movement | T1021.004 - Remote Services: SSH | Successful key-based root login (`24`); journald, §6.1 Detection 04 |
| Persistence | T1053.003 - Scheduled Task/Job: Cron | Cron beacon, confirmed firing on schedule (`25`); §6.1 Detection 05 |
## 8. उपचार और हार्डनिंग
**प्राथमिक फिक्स।** Kestra 1.0.45 (1.0.x लाइन) या 1.3.21+ (1.3.x लाइन) पर अपग्रेड करें। यह अकेले ही auth-bypass को बंद कर देता है - इस अभ्यास का Stage 1 - और यह
एकमात्र फिक्स है जिसे लागू करने के बाद किसी अतिरिक्त कम्पेसेंटिंग कंट्रोल की आवश्यकता नहीं होती। देखें [GHSA-2q47-568g-9h4f](https://github.com/kestra-io/kestra/security/advisories/GHSA-2q47-568g-9h4f)।
**यदि तत्काल पैचिंग संभव नहीं है**, तो कम्पेसेंटिंग कंट्रोल, प्रभाव के क्रम में:
1. **रिवर्स-प्रॉक्सी प्रवर्तन** - चूंकि भेद्य फ़िल्टर केवल रॉ पाथ सफ़िक्स पर विफल होता है, Kestra के सामने एक रिवर्स प्रॉक्सी (इस लैब में Caddy) स्वतंत्र रूप से `/api/v1/*/(flows|executions)/.*` से मेल खाने वाले किसी भी पाथ पर auth लागू कर सकता है, चाहे वह किसी भी चीज़ पर समाप्त हो, बायपास को उस लेयर पर बंद करते हुए जहाँ एप्लिकेशन बग पहुँच नहीं सकता।
2. **Docker socket माउंट को प्रतिबंधित करें** - यह Kestra पैच से स्वतंत्र रूप से Stages 2–3 को पूरी तरह बंद कर देता है। `/var/run/docker.sock` को Kestra कंटेनर में बाइंड-माउंट न करें। यदि `Docker` टास्क रनर वास्तव में आवश्यक है, तो एक स्कोप्ड socket प्रॉक्सी (जैसे `docker-socket-proxy`) का उपयोग करें जो पूर्ण डेमन एक्सेस देने के बजाय विशिष्ट API कॉल्स को allowlist करता है - socket तक पूर्ण एक्सेस होस्ट रूट के बराबर है, जैसा §5.2 में प्रदर्शित किया गया है।
3. **SSH हार्डनिंग** - पर्सिस्टेंस चेन का पहला मेकैनिज़्म इस बात पर निर्भर था कि रूट तक key-based SSH से पहुँचा जा सके। `PermitRootLogin no` (या रूट के लिए bastion/MFA की आवश्यकता) उस विशिष्ट पर्सिस्टेंस पाथ को प्रारंभिक RCE की परवाह किए बिना अवरुद्ध कर देता - इस CVE से स्वतंत्र रूप से करने योग्य।
4. **अंतरिम डिटेक्शन कवरेज** - Splunk सहसंबंध सर्च और कस्टम Falco नियम, जो इस अभ्यास के दौरान डिप्लॉय और सत्यापित किए गए, पैचिंग शेड्यूल होने तक इस विशिष्ट चेन के चरणों के लिए अंतरिम कवरेज प्रदान करते हैं।
**पोस्ट-इंसिडेंट हाइजीन**, यदि यह पैटर्न पहले से शोषित पाया जाता है: इसे केवल एप्लिकेशन कॉम्प्रोमाइज़ नहीं, बल्कि पूर्ण होस्ट कॉम्प्रोमाइज़ मानें - Kestra इंस्टेंस की पहुँच वाले प्रत्येक क्रेडेंशियल और सीक्रेट को रोटेट करें (KV store एंट्रीज़, डाउनस्ट्रीम सिस्टम्स के लिए कनेक्शन क्रेडेंशियल), न कि केवल Kestra की अपनी एक्सेस।
**इन-द-वाइल्ड स्थिति।** `CVE-2026-49869`, इसी बग के लिए जुड़वाँ एडवाइज़री, CISA की KEV कैटलॉग में सूचीबद्ध है और देखे गए क्रिप्टो-माइनिंग और क्लाउड-क्रेडेंशियल-थेफ्ट अभियानों से जुड़ी है। `CVE-2026-53576` (यह रिपोर्ट) की अपनी कोई KEV लिस्टिंग नहीं है, लेकिन यह वही भेद्यता है। केवल दो CVE नंबरों में से एक को ट्रैक करने वाले भेद्यता प्रबंधन टूल्स एक्सपोज़र को कम रिपोर्ट कर सकते हैं।
## 9. संदर्भ
- Kestra Security Advisory - [GHSA-2q47-568g-9h4f](https://github.com/kestra-io/kestra/security/advisories/GHSA-2q47-568g-9h4f) (CVE-2026-53576, इस रिपोर्ट का प्राथमिक स्रोत)
- जुड़वाँ एडवाइज़री - [GHSA-5vc5-wxxq-3fjx](https://github.com/kestra-io/kestra/security/advisories/GHSA-5vc5-wxxq-3fjx) (CVE-2026-49869, समान बग, CISA KEV-सूचीबद्ध)
- CVE.org - [CVE-2026-53576](https://www.cve.org/CVERecord?id=CVE-2026-53576), [CVE-2026-49869](https://www.cve.org/CVERecord?id=CVE-2026-49869)
- CISA Known Exploited Vulnerabilities Catalog - https://www.cisa.gov/known-exploited-vulnerabilities-catalog (CVE-2026-49869 प्रविष्टि, 2026-09-02 को जोड़ी गई)
- फिक्स्ड रिलीज़, दोनों के अस्तित्व और टैग की पुष्टि - [v1.3.21](https://github.com/kestra-io/kestra/releases/tag/v1.3.21) (2026-06-02, चेंजलॉग स्पष्ट रूप से "potential authentication bypass in the authentication filter" का संदर्भ देता है), [v1.0.45](https://github.com/kestra-io/kestra/releases/tag/v1.0.45) (2026-06-03)
- Docker socket एस्केलेशन तकनीक (§5.2) - [HackTricks: Docker Breakout / Privilege Escalation](https://hacktricks.wiki/en/linux-hardening/privilege-escalation/docker-security/docker-breakout-privilege-escalation/index.html), [Trail of Bits: Understanding Docker Container Escapes](https://blog.trailofbits.com/2019/07/19/understanding-docker-container-escapes/), [MindPatch: Docker Escape](https://www.mindpatch.net/posts/docker-escape/)
- Sigma नियम (§6.2) - अपना लिखने के बजाय जो सार्वजनिक नियम मैंने उपयोग किया: [SigmaHQ "Suspicious Reverse Shell Command Line"](https://github.com/SigmaHQ/sigma/blob/master/rules/linux/builtin/lnx_shell_susp_rev_shells.yml) (id `738d9bcf-6999-4fdb-b4ac-3033037db8ab`, Florian Roth / Nextron Systems), [Detection Rule License 1.1](https://github.com/SigmaHQ/sigma/blob/master/LICENSE.Detection.Rules.md) के अंतर्गत उपयोग किया गया
- Falco नियम (§6.3) - docker-socket अंतराल एक ओपन अपस्ट्रीम रिक्वेस्ट है ([falcosecurity/falco #2940](https://github.com/falcosecurity/falco/issues/2940)); कस्टम नियम [Sysdig के Docker + Falco उदाहरणों](https://www.sysdig.com/blog/docker-falco-security) में दिए पैटर्न का अनुसरण करता है