CVE-2025-53770 अनुसंधान प्रयोगशाला

यह रिपॉजिटरी एक नियंत्रित प्रयोगशाला में SharePoint-शैली डिसीरियलाइज़ेशन और टूल-पेन प्रोसेसिंग मुद्दे को मान्य करने के लिए एक प्रूफ-ऑफ-कॉन्सेप्ट अनुसंधान परियोजना प्रतीत होती है। इसमें एक Python ड्राइवर, एक नकली कमजोर अनुप्रयोग, और पृथक परीक्षण के लिए कंटेनर संपत्तियां शामिल हैं।

[!चेतावनी] इस परियोजना का उपयोग केवल उन प्रणालियों, कंटेनरों या नेटवर्कों में किया जाना चाहिए जिनके आप स्वामी हैं या जिनके परीक्षण के लिए आपको स्पष्ट रूप से अधिकृत किया गया है। इस कोड को सार्वजनिक बुनियादी ढांचे, तृतीय-पक्ष सेवाओं, उत्पादन वातावरण, या बिना लिखित अनुमति के किसी भी लक्ष्य के विरुद्ध न चलाएं। अनधिकृत सुरक्षा परीक्षण कानून, अनुबंध, नीति या स्वीकार्य उपयोग शर्तों का उल्लंघन कर सकता है।

इस रिपॉजिटरी की सामग्री को संवेदनशील सुरक्षा अनुसंधान सामग्री के रूप में माना जाना चाहिए। यदि आप इस परियोजना का उपयोग मूल्यांकन कार्य के लिए करते हैं, तो निष्पादन को पृथक रखें, सभी गतिविधियों को लॉग करें, और परीक्षण से पहले सिस्टम स्वामी के साथ समन्वय करें।

परियोजना का दायरा

रिपॉजिटरी में वर्तमान में निम्नलिखित शामिल हैं:

• sploit.py: अतुल्यकालिक Python ड्राइवर जो ToolPane एंडपॉइंट पर निर्मित अनुरोध प्रस्तुत करता है।
• lab/mock_vulnerable_app.cs: नकली ASP.NET अनुप्रयोग जो एक सत्यापन मार्कर को प्रतिबिंबित करता है और अपने वर्तमान रूप में, लैब कंटेनर के अंदर आपूर्ति किए गए कमांड को निष्पादित कर सकता है।
• lab/docker-compose.yml: स्थानीय दो-कंटेनर लैब जो नकली लक्ष्य को हमलावर टर्मिनल से अलग करती है।
• lab/Dockerfile: मल्टी-स्टेज .NET बिल्ड जो नकली कमजोर अनुप्रयोग को एक छोटे ASP.NET रनटाइम छवि में प्रकाशित करता है और इसे गैर-रूट उपयोगकर्ता के रूप में चलाता है।
• lab/attacker.Dockerfile: Python हमलावर कंटेनर परिभाषा जो लैब टर्मिनल के लिए आवश्यक स्क्रिप्ट निर्भरता सेट को पूर्वस्थापित करती है।
• lab/vulnerable.csproj: नकली कमजोर अनुप्रयोग के लिए .NET 6 वेब प्रोजेक्ट फ़ाइल।
• lab/genGadget.py: केवल-लैब डिसीरियलाइज़ेशन परीक्षण के लिए संपीड़ित Base64 पेलोड उत्पन्न करने के लिए सहायक स्क्रिप्ट।

सेटअप और उपयोग

यह वर्कफ़्लो केवल स्थानीय लैब के लिए अभिप्रेत है।

पूर्वापेक्षाएँ:

• Compose समर्थन के साथ Docker इंजन
• Docker कमांड चलाने की अनुमति वाला स्थानीय शेल

lab/ निर्देशिका से लैब प्रारंभ करें:

cd lab
docker-compose up --build -d

यदि आपके Docker सेटअप में उन्नत विशेषाधिकारों की आवश्यकता है, तो उन्हीं कमांडों को sudo के साथ चलाएं।

पुष्टि करें कि दोनों कंटेनर चल रहे हैं:

docker-compose ps

समस्या या एक्सप्लॉइट सत्यापन के मामले में लॉगिंग:

docker logs sp_attacker
docker logs sp_vulnerable_lab

लैब जानबूझकर पृथक है:

• लक्ष्य कंटेनर आंतरिक lab_net नेटवर्क पर चलता है;
• होस्ट पर कोई पोर्ट प्रकाशित नहीं हैं;
• हमलावर कंटेनर उसी निजी नेटवर्क के अंदर एक डिस्पोजेबल टर्मिनल के रूप में प्रदान किया गया है।

हमलावर कंटेनर में एक शेल खोलें:

docker exec -it sp_attacker bash

हमलावर कंटेनर के अंदर से, आप लैब-सुरक्षित जांच कर सकते हैं जैसे कि लक्ष्य तक पहुंच की पुष्टि करना और नकली लक्ष्य के विरुद्ध सत्यापन मोड में स्क्रिप्ट का परीक्षण करना:

python3 sploit.py http://sp_vulnerable_lab/
# यदि आपके वातावरण में सेवा-नाम DNS रिज़ॉल्यूशन विफल होता है, तो लैब IP का उपयोग करें:
# python3 sploit.py http://10.10.10.5
# यदि आप आधार सत्यापन से आगे जाना चाहते हैं तो आप वांछित कमांड शामिल कर सकते हैं।
python3 sploit.py http://sp_vulnerable_lab whoami

स्थानीय नकली वातावरण में अपेक्षित व्यवहार:

• हमलावर कंटेनर से लक्ष्य http://sharepoint-target के रूप में पहुंच योग्य होना चाहिए;
• नकली अनुप्रयोग सत्यापन के लिए एक निर्धारित मार्कर लौटाता है;
• स्क्रिप्ट द्वारा उत्पन्न कोई भी परिणाम आर्टिफैक्ट माउंटेड लैब वर्कस्पेस के अंदर रहता है।

परिचालन नोट:

• लैब को बाहरी नेटवर्क से डिस्कनेक्ट रखें और लक्ष्य सेवा को होस्ट पर प्रकाशित न करें;
• इस वातावरण को उत्पादन मूल्यांकन के लिए पुन: उपयोग न करें;
• यदि आप नकली अनुप्रयोग या कंटेनर परिभाषाओं को संशोधित करते हैं, तो पुन: परीक्षण से पहले छवियों को पुनर्निर्मित करें।

सफाई

लैब कंटेनरों और नेटवर्क को रोकें और हटाएं:

cd lab
docker-compose down

यदि आप निर्मित छवियों को भी हटाना चाहते हैं:

docker-compose down --rmi local

यदि आप लैब वर्कस्पेस आर्टिफैक्ट्स का पूर्ण रीसेट चाहते हैं, तो शटडाउन के बाद किसी भी उत्पन्न परिणाम फ़ाइल को हटा दें:

rm -f vuln.lst

प्रत्येक अभ्यास के बाद अनुशंसित सफाई अभ्यास:

1. docker-compose down के साथ लैब बंद करें;
2. उन परिणाम आर्टिफैक्ट्स को हटाएं जिन्हें बने रहना नहीं चाहिए;
3. यदि आपने कोड, निर्भरताएँ या कंटेनर सेटिंग्स बदली हैं तो अगले रन से पहले लैब का पुनर्निर्माण करें।

सत्यापन सारांश

परियोजना एक स्थानीय अनुसंधान लैब के रूप में संरचनात्मक रूप से मान्य है, लेकिन इसे अपने वर्तमान रूप में उत्पादन-सुरक्षित सत्यापक के रूप में नहीं माना जाना चाहिए।

क्या काम कर रहा है:

• लैब टोपोलॉजी सरल और पुनरुत्पादनीय है।
• Python ड्राइवर एक लक्ष्य या लक्ष्यों की सूची का परीक्षण कर सकता है।
• नकली अनुप्रयोग लैब सत्यापन के लिए निर्धारित सफलता संकेतक देता है।

क्या सावधानी की आवश्यकता है:

• मुख्य स्क्रिप्ट में स्पष्ट कमांड-निष्पादन व्यवहार शामिल है जब दूसरा तर्क प्रदान किया जाता है।
• आउटबाउंड अनुरोधों में TLS सत्यापन अक्षम है।
• सकारात्मक निष्कर्ष vuln.lst में लिखे जाते हैं, जो अनावश्यक अवशिष्ट संवेदनशील डेटा बना सकते हैं।
• नकली अनुप्रयोग सीधे शेल इनपुट निष्पादित करता है और इसे कभी भी पृथक लैब के बाहर उजागर नहीं किया जाना चाहिए।

पद्धति

इस परियोजना का उपयोग केवल पहचान और जोखिम के नियंत्रित सत्यापन के लिए करें, परिचालन शोषण के लिए नहीं।

अनुशंसित पद्धति:

1. बिना किसी बाहरी जोखिम के एक पृथक लैब वातावरण बनाएं।
2. नेटवर्क सीमाओं को मान्य करें ताकि केवल शोधकर्ता नकली सेवा तक पहुंच सके।
3. लैब लक्ष्य चलाएं और पुष्टि करें कि अनुप्रयोग इच्छित एंडपॉइंट पर प्रतिक्रिया करता है।
4. ड्राइवर का उपयोग केवल गैर-विनाशकारी सत्यापन मोड में करें ताकि यह पुष्टि हो सके कि लक्ष्य अपेक्षित मार्कर को दर्शाता है।
5. दस्तावेज़ीकरण के लिए अनुरोध और प्रतिक्रिया आर्टिफैक्ट कैप्चर करें, फिर परीक्षण के बाद लैब वातावरण को नष्ट कर दें।

वास्तविक दुनिया के मूल्यांकन कार्य के लिए, सुरक्षित मानक एक्सप्लॉइट-शैली सत्यापन को निम्नलिखित में से एक या अधिक से बदलना है:

• संस्करण और पैच-स्तर सत्यापन;
• प्रमाणित कॉन्फ़िगरेशन समीक्षा;
• वेब-टियर लॉग विश्लेषण;
• EDR, SIEM, और WAF टेलीमेट्री समीक्षा;
• विक्रेता-प्रदत्त समझौता संकेतक और स्वास्थ्य जांच।

प्रभाव

यदि कोई लक्ष्य वास्तव में विशेषाधिकार प्राप्त अनुप्रयोग घटक में एक डिसीरियलाइज़ेशन दोष के लिए कमजोर है, तो संभावित प्रभाव गंभीर हो सकता है:

• प्रभावित सेवा के सुरक्षा संदर्भ में दूरस्थ कोड निष्पादन;
• अनुप्रयोग डेटा, क्रेडेंशियल्स और रहस्यों की गोपनीयता की हानि;
• सामग्री या कॉन्फ़िगरेशन छेड़छाड़ से अखंडता की हानि;
• विनाशकारी कमांड या अनुवर्ती कार्यों से उपलब्धता में गिरावट;
• पार्श्व गति के अवसर यदि होस्ट में व्यापक नेटवर्क या पहचान विशेषाधिकार हैं।

यहां तक कि एक लैब में, कमांड-निष्पादन शब्दार्थ जोखिम को काफी बढ़ा देते हैं क्योंकि वे उन वर्कफ़्लो को सामान्य करते हैं जो कड़ाई से नियंत्रित, अधिकृत जांच के लिए आरक्षित होने चाहिए।

शमन

उचित शमन पथ रक्षात्मक और स्तरित है।

तत्काल कार्रवाई:

1. प्रभावित उत्पाद संस्करण के लिए विक्रेता सुरक्षा अद्यतन और आपातकालीन मार्गदर्शन लागू करें।
2. सार्वजनिक जोखिम हटाएं या कमजोर अनुप्रयोग सतह तक पहुंच प्रतिबंधित करें।
3. यदि समझौते का संदेह है तो क्रेडेंशियल्स घुमाएं और विशेषाधिकार प्राप्त सेवा खातों की समीक्षा करें।
4. पोस्ट-एक्सप्लॉइटेशन गतिविधि के लिए लॉग, निर्धारित कार्य, चाइल्ड प्रक्रियाएं और आउटबाउंड कनेक्शन का निरीक्षण करें।
5. यदि वातावरण पहले से ही समझौता हो सकता है तो सफाई से पहले सबूत संरक्षित करें।

कठोरीकरण कार्रवाई:

1. SharePoint या समतुल्य अनुप्रयोग स्तरों के आसपास नेटवर्क विभाजन लागू करें।
2. सेवा को रिवर्स प्रॉक्सी, WAF, या समतुल्य फ़िल्टरिंग नियंत्रण के पीछे रखें।
3. सेवा-खाता विशेषाधिकार और स्थानीय निष्पादन क्षमता को जहां संभव हो कम करें।
4. /_layouts/15/ToolPane.aspx और आसन्न प्रशासनिक पथों पर संदिग्ध अनुरोधों के लिए केंद्रीकृत लॉगिंग और अलर्टिंग सक्षम करें।
5. अनुप्रयोग कार्यकर्ता संदर्भ से अप्रत्याशित प्रक्रिया निर्माण की निगरानी करें।

अनुसंधान-लैब विशिष्ट शमन: