diff --git a/src/macos-hardening/macos-red-teaming/macos-mdm/README.md b/src/macos-hardening/macos-red-teaming/macos-mdm/README.md index 2d0c6fd85..f82686d96 100644 --- a/src/macos-hardening/macos-red-teaming/macos-mdm/README.md +++ b/src/macos-hardening/macos-red-teaming/macos-mdm/README.md @@ -11,7 +11,7 @@ ### **MDM (मोबाइल डिवाइस प्रबंधन) का अवलोकन** -[मोबाइल डिवाइस प्रबंधन](https://en.wikipedia.org/wiki/Mobile_device_management) (MDM) का उपयोग विभिन्न अंतिम उपयोगकर्ता उपकरणों जैसे स्मार्टफोन, लैपटॉप और टैबलेट की निगरानी के लिए किया जाता है। विशेष रूप से एप्पल के प्लेटफार्मों (iOS, macOS, tvOS) के लिए, इसमें विशेष सुविधाओं, APIs और प्रथाओं का एक सेट शामिल है। MDM का संचालन एक संगत MDM सर्वर पर निर्भर करता है, जो या तो व्यावसायिक रूप से उपलब्ध है या ओपन-सोर्स है, और इसे [MDM प्रोटोकॉल](https://developer.apple.com/enterprise/documentation/MDM-Protocol-Reference.pdf) का समर्थन करना चाहिए। मुख्य बिंदुओं में शामिल हैं: +[मोबाइल डिवाइस प्रबंधन](https://en.wikipedia.org/wiki/Mobile_device_management) (MDM) का उपयोग विभिन्न अंतिम उपयोगकर्ता उपकरणों जैसे स्मार्टफोन, लैपटॉप और टैबलेट की निगरानी के लिए किया जाता है। विशेष रूप से Apple के प्लेटफार्मों (iOS, macOS, tvOS) के लिए, इसमें विशेष सुविधाओं, APIs और प्रथाओं का एक सेट शामिल है। MDM का संचालन एक संगत MDM सर्वर पर निर्भर करता है, जो या तो व्यावसायिक रूप से उपलब्ध है या ओपन-सोर्स है, और इसे [MDM प्रोटोकॉल](https://developer.apple.com/enterprise/documentation/MDM-Protocol-Reference.pdf) का समर्थन करना चाहिए। मुख्य बिंदुओं में शामिल हैं: - उपकरणों पर केंद्रीकृत नियंत्रण। - MDM प्रोटोकॉल का पालन करने वाले MDM सर्वर पर निर्भरता। @@ -19,15 +19,15 @@ ### **DEP (डिवाइस नामांकन कार्यक्रम) की मूल बातें** -[डिवाइस नामांकन कार्यक्रम](https://www.apple.com/business/site/docs/DEP_Guide.pdf) (DEP) जो एप्पल द्वारा प्रदान किया जाता है, मोबाइल डिवाइस प्रबंधन (MDM) के एकीकरण को सरल बनाता है, iOS, macOS और tvOS उपकरणों के लिए जीरो-टच कॉन्फ़िगरेशन की सुविधा प्रदान करता है। DEP नामांकन प्रक्रिया को स्वचालित करता है, जिससे उपकरण बॉक्स से बाहर निकलते ही कार्यात्मक हो जाते हैं, न्यूनतम उपयोगकर्ता या प्रशासनिक हस्तक्षेप के साथ। आवश्यक पहलुओं में शामिल हैं: +Apple द्वारा प्रदान किया गया [डिवाइस नामांकन कार्यक्रम](https://www.apple.com/business/site/docs/DEP_Guide.pdf) (DEP) मोबाइल डिवाइस प्रबंधन (MDM) के एकीकरण को सरल बनाता है, जिससे iOS, macOS और tvOS उपकरणों के लिए शून्य-टच कॉन्फ़िगरेशन की सुविधा मिलती है। DEP नामांकन प्रक्रिया को स्वचालित करता है, जिससे उपकरण बॉक्स से बाहर निकलते ही कार्यशील हो जाते हैं, जिसमें न्यूनतम उपयोगकर्ता या प्रशासनिक हस्तक्षेप होता है। आवश्यक पहलुओं में शामिल हैं: -- उपकरणों को प्रारंभिक सक्रियण पर पूर्व-परिभाषित MDM सर्वर के साथ स्वायत्त रूप से पंजीकरण करने की अनुमति देता है। +- उपकरणों को प्रारंभिक सक्रियण पर पूर्व-निर्धारित MDM सर्वर के साथ स्वायत्त रूप से पंजीकरण करने की अनुमति देता है। - मुख्य रूप से नए उपकरणों के लिए फायदेमंद, लेकिन पुनः कॉन्फ़िगरेशन कर रहे उपकरणों के लिए भी लागू होता है। - एक सरल सेटअप की सुविधा देता है, जिससे उपकरणों को जल्दी से संगठनात्मक उपयोग के लिए तैयार किया जा सके। ### **सुरक्षा पर विचार** -यह ध्यान रखना महत्वपूर्ण है कि DEP द्वारा प्रदान की गई नामांकन की आसानी, जबकि फायदेमंद है, सुरक्षा जोखिम भी पैदा कर सकती है। यदि MDM नामांकन के लिए सुरक्षा उपायों को उचित रूप से लागू नहीं किया गया है, तो हमलावर इस सरल प्रक्रिया का लाभ उठाकर अपने उपकरण को संगठन के MDM सर्वर पर पंजीकृत कर सकते हैं, जो एक कॉर्पोरेट उपकरण के रूप में प्रच्छन्न हो सकता है। +यह ध्यान रखना महत्वपूर्ण है कि DEP द्वारा प्रदान की गई नामांकन की आसानी, जबकि फायदेमंद है, सुरक्षा जोखिम भी पैदा कर सकती है। यदि MDM नामांकन के लिए सुरक्षा उपायों को उचित रूप से लागू नहीं किया गया है, तो हमलावर इस सरल प्रक्रिया का लाभ उठाकर अपने उपकरण को संगठन के MDM सर्वर पर पंजीकृत कर सकते हैं, जो एक कॉर्पोरेट उपकरण के रूप में प्रकट होता है। > [!CAUTION] > **सुरक्षा चेतावनी**: सरल DEP नामांकन उचित सुरक्षा उपायों के बिना संगठन के MDM सर्वर पर अनधिकृत उपकरण पंजीकरण की अनुमति दे सकता है। @@ -35,11 +35,11 @@ ### मूल बातें SCEP (सादा प्रमाणपत्र नामांकन प्रोटोकॉल) क्या है? - एक अपेक्षाकृत पुराना प्रोटोकॉल, जो TLS और HTTPS के व्यापक होने से पहले बनाया गया था। -- ग्राहकों को एक मानकीकृत तरीके से **प्रमाणपत्र हस्ताक्षर अनुरोध** (CSR) भेजने की अनुमति देता है ताकि उन्हें एक प्रमाणपत्र दिया जा सके। ग्राहक सर्वर से एक हस्ताक्षरित प्रमाणपत्र देने के लिए कहेगा। +- ग्राहकों को एक मानकीकृत तरीका प्रदान करता है **प्रमाणपत्र हस्ताक्षर अनुरोध** (CSR) भेजने के लिए ताकि उन्हें एक प्रमाणपत्र दिया जा सके। ग्राहक सर्वर से एक हस्ताक्षरित प्रमाणपत्र देने के लिए कहेगा। ### कॉन्फ़िगरेशन प्रोफाइल (जिसे मोबाइलकॉन्फ़िग्स भी कहा जाता है) क्या हैं? -- एप्पल का आधिकारिक तरीका **सिस्टम कॉन्फ़िगरेशन सेट करने/लागू करने का।** +- Apple का आधिकारिक तरीका **सिस्टम कॉन्फ़िगरेशन सेट करने/लागू करने का।** - फ़ाइल प्रारूप जिसमें कई पेलोड हो सकते हैं। - प्रॉपर्टी सूचियों (XML प्रकार) पर आधारित। - “इनकी उत्पत्ति को मान्य करने, उनकी अखंडता सुनिश्चित करने और उनके सामग्री की सुरक्षा के लिए हस्ताक्षरित और एन्क्रिप्ट किया जा सकता है।” मूल बातें — पृष्ठ 70, iOS सुरक्षा गाइड, जनवरी 2018। @@ -52,30 +52,30 @@ - **संचार** एक **उपकरण** और एक सर्वर के बीच होता है जो एक **उपकरण** **प्रबंधन** **उत्पाद** से संबंधित है - **आदेश** MDM से उपकरण पर **plist-encoded dictionaries** में भेजे जाते हैं - सभी **HTTPS** पर। MDM सर्वर को (और आमतौर पर) पिन किया जा सकता है। -- एप्पल MDM विक्रेता को प्रमाणीकरण के लिए एक **APNs प्रमाणपत्र** प्रदान करता है +- Apple MDM विक्रेता को प्रमाणीकरण के लिए एक **APNs प्रमाणपत्र** प्रदान करता है ### DEP - **3 APIs**: 1 पुनर्विक्रेताओं के लिए, 1 MDM विक्रेताओं के लिए, 1 उपकरण पहचान के लिए (अविवृत): - तथाकथित [DEP "क्लाउड सेवा" API](https://developer.apple.com/enterprise/documentation/MDM-Protocol-Reference.pdf)। इसका उपयोग MDM सर्वरों द्वारा DEP प्रोफाइल को विशिष्ट उपकरणों के साथ जोड़ने के लिए किया जाता है। -- [DEP API जिसका उपयोग एप्पल अधिकृत पुनर्विक्रेताओं द्वारा किया जाता है](https://applecareconnect.apple.com/api-docs/depuat/html/WSImpManual.html) उपकरणों को नामांकित करने, नामांकन स्थिति की जांच करने और लेनदेन की स्थिति की जांच करने के लिए। -- अविवृत निजी DEP API। इसका उपयोग एप्पल उपकरणों द्वारा उनके DEP प्रोफाइल का अनुरोध करने के लिए किया जाता है। macOS पर, `cloudconfigurationd` बाइनरी इस API के माध्यम से संचार करने के लिए जिम्मेदार है। +- [DEP API जिसका उपयोग Apple अधिकृत पुनर्विक्रेताओं द्वारा किया जाता है](https://applecareconnect.apple.com/api-docs/depuat/html/WSImpManual.html) उपकरणों को नामांकित करने, नामांकन स्थिति की जांच करने और लेनदेन की स्थिति की जांच करने के लिए। +- अविवृत निजी DEP API। इसका उपयोग Apple उपकरणों द्वारा उनके DEP प्रोफाइल का अनुरोध करने के लिए किया जाता है। macOS पर, `cloudconfigurationd` बाइनरी इस API के माध्यम से संचार करने के लिए जिम्मेदार है। - अधिक आधुनिक और **JSON** आधारित (विपरीत plist) -- एप्पल MDM विक्रेता को एक **OAuth टोकन** प्रदान करता है +- Apple MDM विक्रेता को एक **OAuth टोकन** प्रदान करता है **DEP "क्लाउड सेवा" API** - RESTful -- एप्पल से MDM सर्वर पर उपकरण रिकॉर्ड को समन्वयित करें -- MDM सर्वर से एप्पल के लिए “DEP प्रोफाइल” को समन्वयित करें (बाद में एप्पल द्वारा उपकरण को वितरित किया गया) -- एक DEP “प्रोफाइल” में शामिल हैं: +- Apple से MDM सर्वर पर उपकरण रिकॉर्ड को समन्वयित करें +- MDM सर्वर से Apple को "DEP प्रोफाइल" समन्वयित करें (बाद में Apple द्वारा उपकरण पर भेजा गया) +- एक DEP “प्रोफाइल” में शामिल है: - MDM विक्रेता सर्वर URL - सर्वर URL के लिए अतिरिक्त विश्वसनीय प्रमाणपत्र (वैकल्पिक पिनिंग) - अतिरिक्त सेटिंग्स (जैसे सेटअप सहायक में कौन से स्क्रीन छोड़ने हैं) ## सीरियल नंबर -2010 के बाद निर्मित एप्पल उपकरणों में सामान्यतः **12-चर अल्फ़ान्यूमेरिक** सीरियल नंबर होते हैं, जिनमें **पहले तीन अंक निर्माण स्थान** का प्रतिनिधित्व करते हैं, इसके बाद के **दो** **वर्ष** और **सप्ताह** का संकेत देते हैं, अगले **तीन** अंक एक **विशिष्ट** **पहचानकर्ता** प्रदान करते हैं, और **अंतिम** **चार** अंक **मॉडल नंबर** का प्रतिनिधित्व करते हैं। +2010 के बाद निर्मित Apple उपकरणों में सामान्यतः **12-चर अल्फ़ान्यूमेरिक** सीरियल नंबर होते हैं, जिनमें **पहले तीन अंक निर्माण स्थान** का प्रतिनिधित्व करते हैं, अगले **दो** निर्माण के **वर्ष** और **सप्ताह** को दर्शाते हैं, अगले **तीन** अंक एक **विशिष्ट** **पहचानकर्ता** प्रदान करते हैं, और **अंतिम** **चार** अंक **मॉडल नंबर** का प्रतिनिधित्व करते हैं। {{#ref}} macos-serial-number.md @@ -83,9 +83,9 @@ macos-serial-number.md ## नामांकन और प्रबंधन के लिए कदम -1. उपकरण रिकॉर्ड निर्माण (पुनर्विक्रेता, एप्पल): नए उपकरण का रिकॉर्ड बनाया जाता है +1. उपकरण रिकॉर्ड निर्माण (पुनर्विक्रेता, Apple): नए उपकरण का रिकॉर्ड बनाया जाता है 2. उपकरण रिकॉर्ड असाइनमेंट (ग्राहक): उपकरण को एक MDM सर्वर के लिए असाइन किया जाता है -3. उपकरण रिकॉर्ड समन्वय (MDM विक्रेता): MDM उपकरण रिकॉर्ड को समन्वयित करता है और DEP प्रोफाइल को एप्पल पर धकेलता है +3. उपकरण रिकॉर्ड समन्वय (MDM विक्रेता): MDM उपकरण रिकॉर्ड को समन्वयित करता है और DEP प्रोफाइल को Apple पर भेजता है 4. DEP चेक-इन (उपकरण): उपकरण को उसका DEP प्रोफाइल मिलता है 5. प्रोफाइल पुनर्प्राप्ति (उपकरण) 6. प्रोफाइल स्थापना (उपकरण) a. MDM, SCEP और रूट CA पेलोड सहित @@ -97,14 +97,14 @@ macos-serial-number.md ### कदम 4: DEP चेक-इन - सक्रियण रिकॉर्ड प्राप्त करना -यह प्रक्रिया तब होती है जब एक **उपयोगकर्ता पहली बार Mac बूट करता है** (या एक पूर्ण वाइप के बाद) +यह प्रक्रिया तब होती है जब एक **उपयोगकर्ता पहली बार Mac बूट करता है** (या एक पूर्ण मिटाने के बाद) ![](<../../../images/image (1044).png>) या जब `sudo profiles show -type enrollment` निष्पादित किया जाता है - **यह निर्धारित करें कि उपकरण DEP सक्षम है या नहीं** -- सक्रियण रिकॉर्ड **DEP “प्रोफाइल”** का आंतरिक नाम है +- सक्रियण रिकॉर्ड **DEP "प्रोफाइल"** का आंतरिक नाम है - जैसे ही उपकरण इंटरनेट से जुड़ता है, यह शुरू होता है - **`CPFetchActivationRecord`** द्वारा संचालित - **`cloudconfigurationd`** द्वारा XPC के माध्यम से लागू किया गया। **"सेटअप सहायक"** (जब उपकरण पहली बार बूट होता है) या **`profiles`** कमांड इस डेमन से सक्रियण रिकॉर्ड प्राप्त करने के लिए संपर्क करेगा। @@ -120,7 +120,7 @@ macos-serial-number.md 1. POST [https://iprofiles.apple.com/session](https://iprofiles.apple.com/session) 4. सत्र स्थापित करें (**`NACKeyEstablishment`**) 5. अनुरोध करें -1. POST [https://iprofiles.apple.com/macProfile](https://iprofiles.apple.com/macProfile) को डेटा `{ "action": "RequestProfileConfiguration", "sn": "" }` भेजकर +1. POST [https://iprofiles.apple.com/macProfile](https://iprofiles.apple.com/macProfile) पर डेटा भेजते हुए `{ "action": "RequestProfileConfiguration", "sn": "" }` 2. JSON पेलोड को Absinthe (**`NACSign`**) का उपयोग करके एन्क्रिप्ट किया गया है 3. सभी अनुरोध HTTPs पर, अंतर्निहित रूट प्रमाणपत्रों का उपयोग किया जाता है @@ -137,11 +137,67 @@ macos-serial-number.md - **DEP प्रोफाइल में प्रदान किए गए URL** पर अनुरोध भेजा गया। - यदि प्रदान किया गया हो तो **एंकर प्रमाणपत्रों** का उपयोग **विश्वास का मूल्यांकन** करने के लिए किया जाता है। -- अनुस्मारक: **DEP प्रोफाइल की anchor_certs** प्रॉपर्टी +- अनुस्मारक: DEP प्रोफाइल की **anchor_certs** संपत्ति - **अनुरोध एक साधारण .plist** है जिसमें उपकरण की पहचान होती है - उदाहरण: **UDID, OS संस्करण**। - CMS-हस्ताक्षरित, DER-कोडित - **उपकरण पहचान प्रमाणपत्र (APNS से)** का उपयोग करके हस्ताक्षरित - **प्रमाणपत्र श्रृंखला** में समाप्त **Apple iPhone Device CA** शामिल है -![](<../../../images/image (567) (1) (2) (2) (2) (2) (2) (2) (2) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) +![](<../../../images/image (567) (1) (2) (2) (2) (2) (2) (2) (2) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (2) (2).png>) + +### कदम 6: प्रोफाइल स्थापना + +- एक बार पुनर्प्राप्त होने के बाद, **प्रोफाइल सिस्टम पर संग्रहीत किया जाता है** +- यह कदम स्वचालित रूप से शुरू होता है (यदि **सेटअप सहायक** में) +- **`CPInstallActivationProfile`** द्वारा संचालित +- XPC के माध्यम से mdmclient द्वारा लागू किया गया +- LaunchDaemon (रूट के रूप में) या LaunchAgent (उपयोगकर्ता के रूप में), संदर्भ के आधार पर +- कॉन्फ़िगरेशन प्रोफाइल में स्थापित करने के लिए कई पेलोड होते हैं +- फ्रेमवर्क में प्रोफाइल स्थापित करने के लिए एक प्लगइन-आधारित आर्किटेक्चर है +- प्रत्येक पेलोड प्रकार एक प्लगइन से संबंधित होता है +- यह XPC (फ्रेमवर्क में) या क्लासिक कोकोआ (ManagedClient.app में) हो सकता है +- उदाहरण: +- प्रमाणपत्र पेलोड्स CertificateService.xpc का उपयोग करते हैं + +आम तौर पर, एक MDM विक्रेता द्वारा प्रदान किया गया **सक्रियण प्रोफाइल** निम्नलिखित पेलोड्स को **शामिल करेगा**: + +- `com.apple.mdm`: उपकरण को MDM में **नामांकित** करने के लिए +- `com.apple.security.scep`: उपकरण को एक **क्लाइंट प्रमाणपत्र** सुरक्षित रूप से प्रदान करने के लिए। +- `com.apple.security.pem`: उपकरण के सिस्टम कीचेन में **विश्वसनीय CA प्रमाणपत्र** स्थापित करने के लिए। +- MDM पेलोड स्थापित करना दस्तावेज़ में **MDM चेक-इन के बराबर है** +- पेलोड में **मुख्य गुण** होते हैं: +- - MDM चेक-इन URL (**`CheckInURL`**) +- MDM आदेश पोलिंग URL (**`ServerURL`**) + इसे ट्रिगर करने के लिए APNs विषय +- MDM पेलोड स्थापित करने के लिए, **`CheckInURL`** पर अनुरोध भेजा जाता है +- **`mdmclient`** में लागू किया गया +- MDM पेलोड अन्य पेलोड्स पर निर्भर कर सकता है +- **विशिष्ट प्रमाणपत्रों** के लिए अनुरोधों को पिन करने की अनुमति देता है: +- संपत्ति: **`CheckInURLPinningCertificateUUIDs`** +- संपत्ति: **`ServerURLPinningCertificateUUIDs`** +- PEM पेलोड के माध्यम से वितरित +- उपकरण को एक पहचान प्रमाणपत्र के साथ विशेषता देने की अनुमति देता है: +- संपत्ति: IdentityCertificateUUID +- SCEP पेलोड के माध्यम से वितरित + +### **कदम 7: MDM आदेशों के लिए सुनना** + +- MDM चेक-इन पूरा होने के बाद, विक्रेता **APNs का उपयोग करके पुश सूचनाएँ जारी कर सकता है** +- प्राप्ति पर, इसे **`mdmclient`** द्वारा संभाला जाता है +- MDM आदेशों के लिए पोलिंग करने के लिए, **ServerURL** पर अनुरोध भेजा जाता है +- पहले से स्थापित MDM पेलोड का उपयोग करता है: +- **`ServerURLPinningCertificateUUIDs`** अनुरोध के लिए पिनिंग के लिए +- **`IdentityCertificateUUID`** TLS क्लाइंट प्रमाणपत्र के लिए + +## हमले + +### अन्य संगठनों में उपकरणों का नामांकन + +जैसा कि पहले टिप्पणी की गई थी, एक उपकरण को एक संगठन में नामांकित करने के लिए **केवल उस संगठन का एक सीरियल नंबर आवश्यक है**। एक बार उपकरण नामांकित हो जाने पर, कई संगठन नए उपकरण पर संवेदनशील डेटा स्थापित करेंगे: प्रमाणपत्र, अनुप्रयोग, WiFi पासवर्ड, VPN कॉन्फ़िगरेशन [और इसी तरह](https://developer.apple.com/enterprise/documentation/Configuration-Profile-Reference.pdf)।\ +इसलिए, यदि नामांकन प्रक्रिया को सही तरीके से सुरक्षित नहीं किया गया है, तो यह हमलावरों के लिए एक खतरनाक प्रवेश बिंदु हो सकता है: + +{{#ref}} +enrolling-devices-in-other-organisations.md +{{#endref}} + +{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-web/dependency-confusion.md b/src/pentesting-web/dependency-confusion.md index b121a13f9..28cab2e27 100644 --- a/src/pentesting-web/dependency-confusion.md +++ b/src/pentesting-web/dependency-confusion.md @@ -4,40 +4,262 @@ ## Basic Information -संक्षेप में, एक dependency confusion vulnerability तब होती है जब एक प्रोजेक्ट एक लाइब्रेरी का उपयोग कर रहा होता है जिसका **गलत स्पेलिंग** है, **अस्तित्वहीन** है या जिसका **निर्धारित संस्करण** नहीं है और उपयोग की गई dependency repository **सार्वजनिक** repositories से **अपडेटेड संस्करणों को इकट्ठा करने** की अनुमति देती है। +Dependency Confusion (जिसे प्रतिस्थापन हमले भी कहा जाता है) तब होता है जब एक पैकेज प्रबंधक एक निर्भरता नाम को एक अनपेक्षित, कम-विश्वसनीय रजिस्ट्रि/स्रोत (आमतौर पर एक सार्वजनिक रजिस्ट्रि) से हल करता है, बजाय इसके कि इसे इच्छित निजी/आंतरिक रजिस्ट्रि से हल किया जाए। इससे आमतौर पर एक हमलावर-नियंत्रित पैकेज की स्थापना होती है। -- **गलत स्पेलिंग**: **`reqests`** को आयात करें बजाय `requests` -- **अस्तित्वहीन**: `company-logging` को आयात करें, एक आंतरिक लाइब्रेरी जो **अब अस्तित्व में नहीं है** -- **निर्धारित संस्करण नहीं**: एक **आंतरिक** **अस्तित्व में** `company-requests` लाइब्रेरी को आयात करें, लेकिन repo **सार्वजनिक repos** की जांच करता है यह देखने के लिए कि क्या **बड़े संस्करण** हैं। +सामान्य मूल कारण: +- टाइपोसक्वाटिंग/गलत स्पेलिंग: `reqests` को `requests` के बजाय आयात करना (सार्वजनिक रजिस्ट्रि से हल होता है)। +- गैर-मौजूद/परित्यक्त आंतरिक पैकेज: `company-logging` को आयात करना जो अब आंतरिक रूप से मौजूद नहीं है, इसलिए हल करने वाला सार्वजनिक रजिस्ट्रियों में देखता है और एक हमलावर का पैकेज पाता है। +- कई रजिस्ट्रियों में संस्करण प्राथमिकता: एक आंतरिक `company-requests` को आयात करना जबकि हल करने वाले को सार्वजनिक रजिस्ट्रियों को भी क्वेरी करने की अनुमति है और एक हमलावर द्वारा सार्वजनिक रूप से प्रकाशित "सर्वश्रेष्ठ"/नया संस्करण पसंद करता है। + +मुख्य विचार: यदि हल करने वाला एक ही पैकेज नाम के लिए कई रजिस्ट्रियों को देख सकता है और "सर्वश्रेष्ठ" उम्मीदवार को वैश्विक रूप से चुनने की अनुमति है, तो आप कमजोर हैं जब तक कि आप समाधान को सीमित नहीं करते। ## Exploitation > [!WARNING] -> सभी मामलों में हमलावर को केवल एक **दुष्ट पैकेज का नाम** प्रकाशित करने की आवश्यकता है जो पीड़ित कंपनी द्वारा उपयोग की जाने वाली लाइब्रेरी का नाम है। +> सभी मामलों में, हमलावर को केवल एक दुर्भावनापूर्ण पैकेज प्रकाशित करने की आवश्यकता होती है जिसका नाम उस निर्भरता के समान है जिसे आपका निर्माण सार्वजनिक रजिस्ट्रि से हल करता है। स्थापना-समय हुक (जैसे, npm स्क्रिप्ट) या आयात-समय कोड पथ अक्सर कोड निष्पादन देते हैं। -### गलत स्पेलिंग और अस्तित्वहीन +### Misspelled & Inexistent -यदि आपकी कंपनी एक **लाइब्रेरी आयात करने की कोशिश कर रही है जो आंतरिक नहीं है**, तो बहुत संभावना है कि लाइब्रेरी का repo इसे **सार्वजनिक repositories** में खोजने जा रहा है। यदि एक हमलावर ने इसे बनाया है, तो आपका कोड और चलने वाली मशीनें बहुत संभावना है कि समझौता की जाएंगी। +यदि आपका प्रोजेक्ट एक लाइब्रेरी का संदर्भ देता है जो निजी रजिस्ट्रि में उपलब्ध नहीं है, और आपका उपकरण सार्वजनिक रजिस्ट्रि पर वापस जाता है, तो एक हमलावर उस नाम के साथ एक दुर्भावनापूर्ण पैकेज सार्वजनिक रजिस्ट्रि में डाल सकता है। आपके रनर/CI/dev मशीनें इसे लाएंगी और निष्पादित करेंगी। -### निर्दिष्ट संस्करण नहीं +### Unspecified Version / “Best-version” selection across indexes -डेवलपर्स के लिए यह बहुत सामान्य है कि वे उपयोग की जाने वाली लाइब्रेरी का **कोई संस्करण निर्दिष्ट नहीं करते** हैं, या केवल एक **मुख्य संस्करण** निर्दिष्ट करते हैं। फिर, इंटरप्रेटर उन आवश्यकताओं के अनुसार **नवीनतम संस्करण** डाउनलोड करने की कोशिश करेगा।\ -यदि लाइब्रेरी एक **ज्ञात बाहरी लाइब्रेरी** है (जैसे python `requests`), तो एक **हमलावर ज्यादा कुछ नहीं कर सकता**, क्योंकि वह `requests` नाम की लाइब्रेरी नहीं बना सकेगा (जब तक कि वह मूल लेखक न हो)।\ -हालांकि, यदि लाइब्रेरी **आंतरिक** है, जैसे इस उदाहरण में `requests-company`, यदि **लाइब्रेरी repo** बाहरी रूप से **नए संस्करणों की जांच करने** की अनुमति देता है, तो यह सार्वजनिक रूप से उपलब्ध एक नए संस्करण की खोज करेगा।\ -तो यदि एक **हमलावर जानता है** कि कंपनी `requests-company` लाइब्रेरी **संस्करण 1.0.1** का उपयोग कर रही है (छोटे अपडेट की अनुमति देता है)। वह लाइब्रेरी `requests-company` **संस्करण 1.0.2** को **प्रकाशित** कर सकता है और कंपनी उस लाइब्रेरी का **उपयोग करेगी** बजाय आंतरिक वाले के। +डेवलपर्स अक्सर संस्करणों को अनपिन करते हैं या व्यापक रेंज की अनुमति देते हैं। जब एक हल करने वाला आंतरिक और सार्वजनिक सूचियों के साथ कॉन्फ़िगर किया जाता है, तो यह स्रोत की परवाह किए बिना नवीनतम संस्करण का चयन कर सकता है। आंतरिक नामों जैसे `requests-company` के लिए, यदि आंतरिक सूची में `1.0.1` है लेकिन एक हमलावर सार्वजनिक रजिस्ट्रि में `1.0.2` प्रकाशित करता है और आपका हल करने वाला दोनों पर विचार करता है, तो सार्वजनिक पैकेज जीत सकता है। ## AWS Fix -यह सुरक्षा कमी AWS **CodeArtifact** में पाई गई (पढ़ें [**इस ब्लॉग पोस्ट में विवरण**](https://zego.engineering/dependency-confusion-in-aws-codeartifact-86b9ff68963d)).\ -AWS ने इसे इस तरह से ठीक किया कि यह निर्दिष्ट करने की अनुमति देता है कि एक लाइब्रेरी आंतरिक है या बाहरी, ताकि बाहरी repositories से आंतरिक निर्भरताओं को डाउनलोड करने से बचा जा सके। +यह कमजोरियों AWS CodeArtifact में पाई गई थी (इस ब्लॉग पोस्ट में विवरण पढ़ें)। AWS ने निर्भरताओं/फीड को आंतरिक बनाम बाहरी के रूप में चिह्नित करने के लिए नियंत्रण जोड़े ताकि क्लाइंट "आंतरिक" नामों को अपस्ट्रीम सार्वजनिक रजिस्ट्रियों से न लाए। ## Finding Vulnerable Libraries -[**Dependency confusion के बारे में मूल पोस्ट**](https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610) में, लेखक ने हजारों उजागर package.json फ़ाइलों की खोज की जिनमें जावास्क्रिप्ट प्रोजेक्ट की निर्भरताएँ थीं। +निर्भरता भ्रम के बारे में मूल पोस्ट में लेखक ने हजारों उजागर मैनिफेस्ट (जैसे, `package.json`, `requirements.txt`, लॉकफाइल) की खोज की ताकि आंतरिक पैकेज नामों का अनुमान लगाया जा सके और फिर उच्च-संस्करण वाले पैकेजों को सार्वजनिक रजिस्ट्रियों में प्रकाशित किया जा सके। -## References +## Practical Attacker Playbook (for red teams in authorized tests) + +- Enumerate names: +- मैनिफेस्ट/लॉक फ़ाइलों और आंतरिक नाम स्थानों के लिए रिपॉजिटरी और CI कॉन्फ़िगरेशन को ग्रेप करें। +- संगठन-विशिष्ट उपसर्गों की तलाश करें (जैसे, `@company/*`, `company-*`, आंतरिक groupIds, NuGet ID पैटर्न, Go के लिए निजी मॉड्यूल पथ, आदि)। +- उपलब्धता के लिए सार्वजनिक रजिस्ट्रियों की जांच करें: +- यदि नाम सार्वजनिक रूप से अनरजिस्टर्ड है, तो इसे रजिस्टर करें; यदि यह मौजूद है, तो आंतरिक पारगमन नामों को लक्षित करके उपनिर्भरता हाइजैकिंग का प्रयास करें। +- प्राथमिकता के साथ प्रकाशित करें: +- एक सेमवर चुनें जो "जीतता है" (जैसे, एक बहुत उच्च संस्करण) या हल करने वाले के नियमों से मेल खाता है। +- जहां लागू हो, न्यूनतम स्थापना-समय निष्पादन शामिल करें (जैसे, npm `preinstall`/`install`/`postinstall` स्क्रिप्ट)। पायथन के लिए, आयात-समय निष्पादन पथों को प्राथमिकता दें, क्योंकि पहिए आमतौर पर स्थापना पर मनमाना कोड निष्पादित नहीं करते हैं। +- नियंत्रण का एक्सफिल: +- सुनिश्चित करें कि CI से आपके नियंत्रित एंडपॉइंट तक आउटबाउंड की अनुमति है; अन्यथा, कोड निष्पादन को साबित करने के लिए DNS क्वेरी या त्रुटि संदेशों का उपयोग करें। + +> [!CAUTION] +> हमेशा लिखित प्राधिकरण प्राप्त करें, संलग्नक के लिए अद्वितीय पैकेज नाम/संस्करण का उपयोग करें, और परीक्षण समाप्त होने पर तुरंत अनप्रकाशित करें या सफाई का समन्वय करें। + +## Defender Playbook (what actually prevents confusion) + +उच्च-स्तरीय रणनीतियाँ जो पारिस्थितिक तंत्रों में काम करती हैं: +- अद्वितीय आंतरिक नाम स्थानों का उपयोग करें और उन्हें एकल रजिस्ट्रि से बांधें। +- समाधान के समय विश्वास स्तरों को मिलाने से बचें। अनुमोदित सार्वजनिक पैकेज को प्रॉक्सी करने के लिए एकल आंतरिक रजिस्ट्रि को प्राथमिकता दें, बजाय इसके कि पैकेज प्रबंधकों को आंतरिक और सार्वजनिक एंडपॉइंट दोनों दें। +- जिन प्रबंधकों का समर्थन है, पैकेजों को विशिष्ट स्रोतों से मानचित्रित करें (रजिस्ट्रियों के बीच कोई वैश्विक "सर्वश्रेष्ठ-संस्करण" नहीं)। +- पिन और लॉक: +- उन लॉकफाइलों का उपयोग करें जो हल की गई रजिस्ट्रि URLs को रिकॉर्ड करती हैं (npm/yarn/pnpm) या हैश/प्रमाणन पिनिंग का उपयोग करें (pip `--require-hashes`, Gradle निर्भरता सत्यापन)। +- आंतरिक नामों के लिए सार्वजनिक फॉलबैक को रजिस्ट्रि/नेटवर्क परत पर अवरुद्ध करें। +- भविष्य के स्क्वाट को रोकने के लिए जब संभव हो, सार्वजनिक रजिस्ट्रियों में अपने आंतरिक नामों को आरक्षित करें। + +## Ecosystem Notes and Secure Config Snippets + +नीचे व्यावहारिक, न्यूनतम कॉन्फ़िगरेशन हैं जो निर्भरता भ्रम को कम या समाप्त करने के लिए हैं। इन्हें CI और डेवलपर वातावरण में लागू करने को प्राथमिकता दें। + +### JavaScript/TypeScript (npm, Yarn, pnpm) + +- सभी आंतरिक कोड के लिए स्कोप्ड पैकेज का उपयोग करें और स्कोप को अपने निजी रजिस्ट्रि पर पिन करें। +- CI में इंस्टॉलेशन को अपरिवर्तनीय रखें (npm लॉकफाइल, `yarn install --immutable`)। + +.npmrc (प्रोजेक्ट-स्तरीय) +``` +# Bind internal scope to private registry; do not allow public fallback for @company/* +@company:registry=https://registry.corp.example/npm/ +# Always authenticate to the private registry +//registry.corp.example/npm/:_authToken=${NPM_TOKEN} +strict-ssl=true +``` +package.json (आंतरिक पैकेज के लिए) +``` +{ +"name": "@company/api-client", +"version": "1.2.3", +"private": false, +"publishConfig": { +"registry": "https://registry.corp.example/npm/", +"access": "restricted" +} +} +``` +Yarn Berry (.yarnrc.yml) +``` +npmScopes: +company: +npmRegistryServer: "https://registry.corp.example/npm/" +npmAlwaysAuth: true +# CI should fail if lockfile would change +enableImmutableInstalls: true +``` +संचालन संबंधी सुझाव: +- केवल `@company` स्कोप के भीतर आंतरिक पैकेज प्रकाशित करें। +- तृतीय-पक्ष पैकेज के लिए, अपने निजी प्रॉक्सी/मिरर के माध्यम से सार्वजनिक रजिस्ट्री की अनुमति दें, सीधे ग्राहकों से नहीं। +- ट्रेसबिलिटी बढ़ाने के लिए सार्वजनिक पैकेज के लिए npm पैकेज उत्पत्ति सक्षम करने पर विचार करें (यह अपने आप में भ्रम को रोकता नहीं है)। + +### Python (pip / Poetry) + +मुख्य नियम: विश्वास स्तरों को मिलाने के लिए `--extra-index-url` का उपयोग न करें। या तो: +- एकल आंतरिक इंडेक्स को उजागर करें जो अनुमोदित PyPI पैकेजों को प्रॉक्सी और कैश करता है, या +- स्पष्ट इंडेक्स चयन और हैश पिनिंग का उपयोग करें। + +pip.conf +``` +[global] +index-url = https://pypi.corp.example/simple +# Disallow source distributions when possible +only-binary = :all: +# Lock with hashes generated via pip-tools +require-hashes = true +``` +pip-tools के साथ हैश किए गए आवश्यकताएँ उत्पन्न करें: +``` +# From pyproject.toml or requirements.in +pip-compile --generate-hashes -o requirements.txt +pip install --require-hashes -r requirements.txt +``` +यदि आपको सार्वजनिक PyPI तक पहुंचना है, तो इसे अपने आंतरिक प्रॉक्सी के माध्यम से करें और वहां एक स्पष्ट अनुमति सूची बनाए रखें। CI में `--extra-index-url` से बचें। + +### .NET (NuGet) + +पैकेज आईडी पैटर्न को स्पष्ट स्रोतों से जोड़ने और अप्रत्याशित फीड से समाधान को रोकने के लिए पैकेज स्रोत मैपिंग का उपयोग करें। + +nuget.config +``` + + + + + + + + + + + + + + + + + +``` +### Java (Maven/Gradle) + +Maven settings.xml (सभी को आंतरिक में मिरर करें; POMs में ad-hoc repos को Enforcer के माध्यम से अनुमति न दें): +``` + + + +internal-mirror +* +https://maven.corp.example/repository/group + + + +``` +Enforcer को POMs में घोषित रिपॉजिटरीज़ पर प्रतिबंध लगाने और आपके मिरर के उपयोग को मजबूर करने के लिए जोड़ें: +``` + +org.apache.maven.plugins +maven-enforcer-plugin +3.6.1 + + +enforce-no-repositories +enforce + + + + + + + + +``` +Gradle: निर्भरता को केंद्रीकृत और लॉक करें। +- केवल `settings.gradle(.kts)` में रिपॉजिटरी लागू करें: +``` +dependencyResolutionManagement { +repositoriesMode = RepositoriesMode.FAIL_ON_PROJECT_REPOS +repositories { +maven { url = uri("https://maven.corp.example/repository/group") } +} +} +``` +- निर्भरता सत्यापन (चेकसम/हस्ताक्षर) सक्षम करें और `gradle/verification-metadata.xml` को कमिट करें। + +### गो मॉड्यूल + +निजी मॉड्यूल को इस तरह से कॉन्फ़िगर करें कि सार्वजनिक प्रॉक्सी और चेकसम DB का उनके लिए उपयोग न किया जाए। +``` +# Use corporate proxy first, then public proxy as fallback +export GOPROXY=https://goproxy.corp.example,https://proxy.golang.org +# Mark private paths to skip proxy and checksum db +export GOPRIVATE=*.corp.example.com,github.com/your-org/* +export GONOSUMDB=*.corp.example.com,github.com/your-org/* +``` +### Rust (Cargo) + +क्रेट्स.io को अनुमोदित आंतरिक मिरर या विक्रेता निर्देशिका के साथ बदलें; मनमाने सार्वजनिक बैकफॉल की अनुमति न दें। + +.cargo/config.toml +``` +[source.crates-io] +replace-with = "corp-mirror" + +[source.corp-mirror] +registry = "https://crates-mirror.corp.example/index" +``` +प्रकाशन के लिए, `--registry` के साथ स्पष्ट रहें और क्रेडेंशियल्स को लक्षित रजिस्ट्री तक सीमित रखें। + +### Ruby (Bundler) + +स्रोत ब्लॉकों का उपयोग करें और मल्टीसोर्स Gemfiles को अक्षम करें ताकि जेम्स केवल इच्छित रिपॉजिटरी से आएं। + +Gemfile +``` +source "https://gems.corp.example" + +source "https://rubygems.org" do +gem "rails" +gem "pg" +end + +source "https://gems.corp.example" do +gem "company-logging" +end +``` +कॉन्फ़िग स्तर पर लागू करें: +``` +bundle config set disable_multisource true +``` +## CI/CD और रजिस्ट्रि नियंत्रण जो मदद करते हैं + +- प्राइवेट रजिस्ट्रि एकल इनग्रेस के रूप में: +- Artifactory/Nexus/CodeArtifact/GitHub Packages/Azure Artifacts का उपयोग करें जो एकमात्र एंडपॉइंट है जिसे डेवलपर्स/CI पहुंच सकते हैं। +- ब्लॉक/अनुमति नियम लागू करें ताकि आंतरिक नामस्थान कभी भी अपस्ट्रीम सार्वजनिक स्रोतों से हल न हों। +- लॉकफाइल्स CI में अपरिवर्तनीय हैं: +- npm: `package-lock.json` को कमिट करें, `npm ci` का उपयोग करें। +- Yarn: `yarn.lock` को कमिट करें, `yarn install --immutable` का उपयोग करें। +- Python: हैश किए गए `requirements.txt` को कमिट करें, `--require-hashes` को लागू करें। +- Gradle: `verification-metadata.xml` को कमिट करें और अज्ञात आर्टिफैक्ट्स पर विफल हों। +- आउटबाउंड ईग्रेस नियंत्रण: CI से सार्वजनिक रजिस्ट्रियों तक सीधे पहुंच को ब्लॉक करें सिवाय स्वीकृत प्रॉक्सी के माध्यम से। +- नाम आरक्षण: जहां समर्थित हो, सार्वजनिक रजिस्ट्रियों में अपने आंतरिक नाम/नामस्थान को पूर्व-रजिस्टर करें। +- पैकेज प्रॉविनेंस / अटेस्टेशन: जब सार्वजनिक पैकेज प्रकाशित करें, तो छेड़छाड़ को नीचे की ओर अधिक पहचानने योग्य बनाने के लिए प्रॉविनेंस/अटेस्टेशन सक्षम करें। + +## संदर्भ - [https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610](https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610) - [https://zego.engineering/dependency-confusion-in-aws-codeartifact-86b9ff68963d](https://zego.engineering/dependency-confusion-in-aws-codeartifact-86b9ff68963d) +- [https://learn.microsoft.com/en-us/nuget/consume-packages/package-source-mapping](https://learn.microsoft.com/en-us/nuget/consume-packages/package-source-mapping) +- [https://yarnpkg.com/configuration/yarnrc/](https://yarnpkg.com/configuration/yarnrc/) {{#include ../banners/hacktricks-training.md}}