diff --git a/src/pentesting-cloud/azure-security/az-services/az-automation-accounts.md b/src/pentesting-cloud/azure-security/az-services/az-automation-accounts.md index c7f35f94c..0b18a7a87 100644 --- a/src/pentesting-cloud/azure-security/az-services/az-automation-accounts.md +++ b/src/pentesting-cloud/azure-security/az-services/az-automation-accounts.md @@ -1,10 +1,10 @@ # Az - Automation Accounts -{{#include ../../../../banners/hacktricks-training.md}} +{{#include ../../../banners/hacktricks-training.md}} ## Basic Information -Azure Automation Accounts Microsoft Azure में क्लाउड-आधारित सेवाएँ हैं जो **कार्य स्वचालित** करने में मदद करती हैं जैसे संसाधन प्रबंधन, कॉन्फ़िगरेशन, और Azure और ऑन-प्रिमाइसेस वातावरण में अपडेट। ये **Runbooks** (स्वचालन के लिए स्क्रिप्ट जो निष्पादित होती हैं), **अनुसूचियाँ**, और **हाइब्रिड कार्यकर्ता समूह** प्रदान करती हैं ताकि स्वचालन **नौकरियों** को चलाया जा सके, जो कोड के रूप में बुनियादी ढाँचा (IaC) और प्रक्रिया स्वचालन को सक्षम बनाती हैं, जिससे क्लाउड संसाधनों के प्रबंधन में दक्षता और स्थिरता में सुधार होता है। +Azure Automation Accounts Microsoft Azure में क्लाउड-आधारित सेवाएँ हैं जो **कार्य स्वचालित** करने में मदद करती हैं जैसे संसाधन प्रबंधन, कॉन्फ़िगरेशन, और Azure और ऑन-प्रिमाइसेस वातावरण में अपडेट। ये **Runbooks** (स्वचालन के लिए स्क्रिप्ट जो निष्पादित होती हैं), **अनुसूचियाँ**, और **हाइब्रिड कार्यकर्ता समूह** प्रदान करती हैं ताकि स्वचालन **नौकरियों** को चलाया जा सके, जो कोड के रूप में बुनियादी ढाँचा (IaC) और प्रक्रिया स्वचालन को सक्षम बनाता है जिससे क्लाउड संसाधनों के प्रबंधन में दक्षता और स्थिरता में सुधार होता है। ### Settings @@ -16,9 +16,9 @@ Azure Automation Accounts Microsoft Azure में क्लाउड-आधा ### Runbooks & Jobs -Azure Automation में एक Runbook एक **स्क्रिप्ट है जो स्वचालित रूप से कार्य करती है** आपके क्लाउड वातावरण के भीतर। Runbooks को PowerShell, Python, या ग्राफिकल संपादकों में लिखा जा सकता है। ये VM प्रबंधन, पैचिंग, या अनुपालन जांच जैसे प्रशासनिक कार्यों को स्वचालित करने में मदद करते हैं। +Azure Automation में एक Runbook एक **स्क्रिप्ट है जो स्वचालित रूप से कार्य करती है** आपके क्लाउड वातावरण के भीतर। Runbooks को PowerShell, Python, या ग्राफिकल संपादकों में लिखा जा सकता है। ये प्रशासनिक कार्यों जैसे VM प्रबंधन, पैचिंग, या अनुपालन जांच को स्वचालित करने में मदद करते हैं। -**Runbooks** के भीतर **कोड** में **संवेदनशील जानकारी** (जैसे क्रेड्स) हो सकती है। +**Runbooks** के भीतर स्थित **कोड** में **संवेदनशील जानकारी** (जैसे क्रेड्स) हो सकती है। एक **Job एक Runbook निष्पादन का उदाहरण है**। जब आप एक Runbook चलाते हैं, तो उस निष्पादन को ट्रैक करने के लिए एक Job बनाया जाता है। प्रत्येक नौकरी में शामिल हैं: @@ -26,29 +26,29 @@ Azure Automation में एक Runbook एक **स्क्रिप्ट - **Output**: Runbook निष्पादन का परिणाम। - **Start and End Time**: जब नौकरी शुरू हुई और पूरी हुई। -एक नौकरी में **Runbook** निष्पादन का **आउटपुट** होता है। यदि आप **jobs** को **पढ़** सकते हैं, तो ऐसा करें क्योंकि वे **run** का **आउटपुट** **संवेदनशील जानकारी** हो सकती है। +एक नौकरी में **Runbook** निष्पादन का **output** होता है। यदि आप **jobs** को **पढ़** सकते हैं, तो ऐसा करें क्योंकि वे **run** का **output** रखते हैं (संभावित **संवेदनशील जानकारी**)। ### Schedules & Webhooks Runbook निष्पादित करने के 3 मुख्य तरीके हैं: -- **Schedules**: इन्हें **विशिष्ट समय** या **अवधि** पर Runbooks को **प्रेरित** करने के लिए उपयोग किया जाता है। -- **Webhooks**: ये **HTTP endpoints** हैं जिन्हें **बाहरी सेवाओं** से Runbooks को **प्रेरित** करने के लिए उपयोग किया जा सकता है। ध्यान दें कि वेबहुक URL **निर्माण के बाद दिखाई नहीं देता**। -- **Manual Trigger**: आप Azure Portal और CLI से एक Runbook को **हाथ से प्रेरित** कर सकते हैं। +- **Schedules**: इन्हें **विशिष्ट समय** या **अवधि** पर Runbooks को **trigger** करने के लिए उपयोग किया जाता है। +- **Webhooks**: ये **HTTP endpoints** हैं जिन्हें **बाहरी सेवाओं** से Runbooks को **trigger** करने के लिए उपयोग किया जा सकता है। ध्यान दें कि webhook URL **निर्माण के बाद दिखाई नहीं देता**। +- **Manual Trigger**: आप Azure Portal और CLI से एक Runbook को **हाथ से ट्रिगर** कर सकते हैं। ### Source Control -यह **Github, Azure Devops (Git) और Azure Devops (TFVC)** से Runbooks को आयात करने की अनुमति देता है। यह संभव है कि यह स्वचालन खाते में रिपॉजिटरी के Runbooks को प्रकाशित करने के लिए इंगित किया जाए और यह भी संभव है कि **रिपॉजिटरी से परिवर्तनों को Azure Automation खाते में समन्वयित करने** के लिए इंगित किया जाए। +यह **Github, Azure Devops (Git) और Azure Devops (TFVC)** से Runbooks को आयात करने की अनुमति देता है। यह संभव है कि यह स्वचालन खाते में repo के Runbooks को प्रकाशित करने के लिए इंगित किया जाए और यह भी संभव है कि **repo से परिवर्तनों को Azure Automation खाते में समन्वयित करने** के लिए इंगित किया जाए। -जब समन्वय सक्षम होता है, तो **Github रिपॉजिटरी में एक वेबहुक बनाया जाता है** ताकि हर बार एक पुश इवेंट होने पर समन्वय को प्रेरित किया जा सके। वेबहुक URL का उदाहरण: `https://f931b47b-18c8-45a2-9d6d-0211545d8c02.webhook.eus.azure-automation.net/webhooks?token=DRjQyFiOrUtz%2fw7o23XbDpOlTe1%2bUqPQm4pQH2WBfJg%3d` +जब समन्वय सक्षम होता है, तो **Github रिपॉजिटरी में एक webhook बनाया जाता है** ताकि हर बार एक पुश इवेंट होने पर समन्वय को ट्रिगर किया जा सके। एक webhook URL का उदाहरण: `https://f931b47b-18c8-45a2-9d6d-0211545d8c02.webhook.eus.azure-automation.net/webhooks?token=DRjQyFiOrUtz%2fw7o23XbDpOlTe1%2bUqPQm4pQH2WBfJg%3d` -ध्यान दें कि ये वेबहुक **Github रिपॉजिटरी से संबंधित रनबुक में सूचीबद्ध करते समय दिखाई नहीं देंगे**। यह भी ध्यान दें कि एक बार बनाए जाने के बाद स्रोत नियंत्रण का रिपॉजिटरी URL **बदलना संभव नहीं है**। +ध्यान दें कि ये webhooks **Github repo से संबंधित runbooks में सूचीबद्ध करते समय दिखाई नहीं देंगे**। यह भी ध्यान दें कि एक बार बनाए जाने के बाद **source control का repo URL बदलना संभव नहीं है**। -कॉन्फ़िगर किए गए स्रोत नियंत्रण के काम करने के लिए, **Azure Automation Account** को एक प्रबंधित पहचान (सिस्टम या उपयोगकर्ता) के साथ **`Contributor`** भूमिका होनी चाहिए। इसके अलावा, स्वचालन खाते में उपयोगकर्ता प्रबंधित पहचान को असाइन करने के लिए, इसे वेरिएबल **`AUTOMATION_SC_USER_ASSIGNED_IDENTITY_ID`** में उपयोगकर्ता MI का क्लाइंट ID इंगित करना आवश्यक है। +कॉन्फ़िगर किए गए स्रोत नियंत्रण के काम करने के लिए, **Azure Automation Account** को एक प्रबंधित पहचान (सिस्टम या उपयोगकर्ता) के साथ **`Contributor`** भूमिका होनी चाहिए। इसके अलावा, Automation Account को उपयोगकर्ता प्रबंधित पहचान सौंपने के लिए, यह आवश्यक है कि उपयोगकर्ता MI के क्लाइंट ID को वेरिएबल **`AUTOMATION_SC_USER_ASSIGNED_IDENTITY_ID`** में इंगित किया जाए। ### Runtime Environments -जब एक Runbook बनाया जाता है, तो रनटाइम वातावरण का चयन करना संभव होता है। डिफ़ॉल्ट रूप से, निम्नलिखित रनटाइम वातावरण उपलब्ध हैं: +जब एक Runbook बनाया जाता है तो रनटाइम वातावरण का चयन करना संभव है। डिफ़ॉल्ट रूप से, निम्नलिखित रनटाइम वातावरण उपलब्ध हैं: - **Powershell 5.1** - **Powershell 7.1** @@ -57,32 +57,32 @@ Runbook निष्पादित करने के 3 मुख्य तर - **Python 3.8** - **Python 2.7** -हालांकि, यह भी संभव है कि आप इनमें से किसी एक का उपयोग करके **अपने स्वयं के वातावरण** बनाएँ। Python के मामले में, यह संभव है कि आप उस वातावरण में उपयोग के लिए `.whl` पैकेज अपलोड करें। PowerShell के मामले में, यह संभव है कि आप रनटाइम में रखने के लिए मॉड्यूल के साथ `.zip` पैकेज अपलोड करें। +हालांकि, यह भी संभव है कि आप इनमें से किसी एक का उपयोग करके **अपने स्वयं के वातावरण** बनाएँ। Python के मामले में, यह संभव है कि आप उस वातावरण में उपयोग किए जाने वाले `.whl` पैकेज अपलोड करें। PowerShell के मामले में, यह संभव है कि आप रनटाइम में रखने के लिए मॉड्यूल के साथ `.zip` पैकेज अपलोड करें। ### Hybrid Worker Groups -Azure Automation में, रनबुक के लिए डिफ़ॉल्ट निष्पादन वातावरण **Azure Sandbox** है, जो Azure द्वारा प्रबंधित एक क्लाउड-आधारित प्लेटफ़ॉर्म है, जो Azure संसाधनों से संबंधित कार्यों के लिए उपयुक्त है। हालाँकि, इस सैंडबॉक्स में सीमाएँ हैं, जैसे ऑन-प्रिमाइसेस संसाधनों तक सीमित पहुँच और निष्पादन समय और संसाधन उपयोग पर प्रतिबंध। इन सीमाओं को पार करने के लिए, हाइब्रिड कार्यकर्ता समूहों का उपयोग किया जाता है। एक हाइब्रिड कार्यकर्ता समूह में **आपकी अपनी मशीनों पर स्थापित एक या अधिक हाइब्रिड रनबुक कार्यकर्ता** होते हैं, चाहे वे ऑन-प्रिमाइसेस हों, अन्य क्लाउड वातावरण में हों या Azure VMs में। यह सेटअप रनबुक को सीधे इन मशीनों पर निष्पादित करने की अनुमति देता है, स्थानीय संसाधनों तक सीधी पहुँच प्रदान करता है, लंबे और अधिक संसाधन-गहन कार्यों को चलाने की क्षमता, और Azure की तात्कालिक पहुँच से परे वातावरण के साथ बातचीत करने की लचीलापन। +Azure Automation में, Runbooks के लिए डिफ़ॉल्ट निष्पादन वातावरण **Azure Sandbox** है, जो Azure द्वारा प्रबंधित एक क्लाउड-आधारित प्लेटफ़ॉर्म है, जो Azure संसाधनों से संबंधित कार्यों के लिए उपयुक्त है। हालाँकि, इस सैंडबॉक्स में सीमाएँ हैं, जैसे ऑन-प्रिमाइसेस संसाधनों तक सीमित पहुँच और निष्पादन समय और संसाधन उपयोग पर प्रतिबंध। इन सीमाओं को पार करने के लिए, हाइब्रिड कार्यकर्ता समूहों का उपयोग किया जाता है। एक हाइब्रिड कार्यकर्ता समूह में **एक या एक से अधिक हाइब्रिड रनबुक कार्यकर्ता शामिल होते हैं जो आपकी मशीनों पर स्थापित होते हैं**, चाहे वे ऑन-प्रिमाइसेस हों, अन्य क्लाउड वातावरण में हों या Azure VMs में। यह सेटअप Runbooks को इन मशीनों पर सीधे निष्पादित करने की अनुमति देता है, स्थानीय संसाधनों तक सीधी पहुँच प्रदान करता है, लंबे और अधिक संसाधन-गहन कार्यों को चलाने की क्षमता और Azure की तात्कालिक पहुँच से परे वातावरण के साथ बातचीत करने की लचीलापन प्रदान करता है। -जब एक हाइब्रिड कार्यकर्ता समूह बनाया जाता है, तो उपयोग करने के लिए **क्रेडेंशियल्स** इंगित करना आवश्यक होता है। 2 विकल्प हैं: +जब एक हाइब्रिड कार्यकर्ता समूह बनाया जाता है, तो उपयोग करने के लिए **credentials** इंगित करना आवश्यक होता है। 2 विकल्प हैं: -- **Default credentials**: आपको क्रेडेंशियल्स प्रदान करने की आवश्यकता नहीं है और रनबुक VMs के भीतर **System** के रूप में निष्पादित होंगे। -- **Specific credentials**: आपको स्वचालन खाते के भीतर क्रेडेंशियल्स ऑब्जेक्ट का नाम प्रदान करने की आवश्यकता है, जिसका उपयोग **VMs के भीतर रनबुक्स को निष्पादित करने** के लिए किया जाएगा। इसलिए, इस मामले में, यह संभव हो सकता है कि **VMs के लिए मान्य क्रेडेंशियल्स चुराए जाएँ**। +- **Default credentials**: आपको क्रेडेंशियल प्रदान करने की आवश्यकता नहीं है और रनबुक VMs के भीतर **System** के रूप में निष्पादित की जाएगी। +- **Specific credentials**: आपको स्वचालन खाते के भीतर क्रेडेंशियल ऑब्जेक्ट का नाम प्रदान करने की आवश्यकता है, जिसका उपयोग **VMs के भीतर रनबुक्स को निष्पादित करने** के लिए किया जाएगा। इसलिए, इस मामले में, यह संभव हो सकता है कि **VMs के लिए मान्य क्रेडेंशियल चुराए जाएँ**। -इसलिए, यदि आप **Runbook** को **Hybrid Worker** में चलाने का विकल्प चुनते हैं, तो आप **System** के रूप में एक बाहरी मशीन के भीतर **मनमाने आदेश** निष्पादित करेंगे (अच्छी पिवट तकनीक)। +इसलिए, यदि आप **Hybrid Worker** में एक **Runbook** चलाने का विकल्प चुनते हैं, तो आप **System** के रूप में एक बाहरी मशीन के भीतर **मनमाने आदेश** निष्पादित करेंगे (अच्छी पिवट तकनीक)। -इसके अलावा, यदि हाइब्रिड कार्यकर्ता Azure में अन्य प्रबंधित पहचान के साथ चल रहा है, तो रनबुक **रनबुक की प्रबंधित पहचान और VM की सभी प्रबंधित पहचानों तक पहुँच प्राप्त कर सकेगा**। +इसके अलावा, यदि हाइब्रिड कार्यकर्ता Azure में अन्य प्रबंधित पहचानों के साथ चल रहा है, तो रनबुक **रनबुक की प्रबंधित पहचान और VM की सभी प्रबंधित पहचानों तक पहुँच प्राप्त कर सकेगी** जो मेटाडेटा सेवा से हैं। > [!TIP] -> याद रखें कि **मेटाडेटा सेवा** का एक अलग URL है (**`http://169.254.169.254`**) उस सेवा से जहाँ स्वचालन खाते की प्रबंधित पहचान टोकन प्राप्त किया जाता है (**`IDENTITY_ENDPOINT`**). +> याद रखें कि **मेटाडेटा सेवा** का एक अलग URL है (**`http://169.254.169.254`**) उस सेवा से जहाँ स्वचालन खाते की प्रबंधित पहचान टोकन प्राप्त किया जाता है (**`IDENTITY_ENDPOINT`**)। ### State Configuration (SC) ->[!WARNING] -> जैसा कि [the docs](https://learn.microsoft.com/en-us/azure/automation/automation-dsc-overview) में संकेत दिया गया है, Azure Automation State Configuration 30 सितंबर, 2027 को समाप्त किया जाएगा और [Azure Machine Configuration](https://learn.microsoft.com/en-us/azure/governance/machine-configuration/overview) द्वारा प्रतिस्थापित किया जाएगा। +> [!WARNING] +> जैसा कि [the docs](https://learn.microsoft.com/en-us/azure/automation/automation-dsc-overview) में संकेत दिया गया है, Azure Automation State Configuration 30 सितंबर, 2027 को समाप्त हो जाएगा और [Azure Machine Configuration](https://learn.microsoft.com/en-us/azure/governance/machine-configuration/overview) द्वारा प्रतिस्थापित किया जाएगा। -Automation Accounts भी **State Configuration (SC)** का समर्थन करते हैं, जो एक विशेषता है जो आपकी VMs की **स्थिति** को **कॉन्फ़िगर** और **रखरखाव** करने में मदद करती है। यह **Windows** और **Linux** मशीनों पर DSC कॉन्फ़िगरेशन को **बनाने** और **लागू करने** की अनुमति देता है। +Automation Accounts भी **State Configuration (SC)** का समर्थन करते हैं, जो एक विशेषता है जो आपकी VMs की **स्थिति** को **कॉन्फ़िगर** और **रखरखाव** करने में मदद करती है। यह **Windows** और **Linux** मशीनों पर DSC कॉन्फ़िगरेशन **बनाने** और **लागू करने** की अनुमति देता है। -हमलावरों के दृष्टिकोण से यह दिलचस्प था क्योंकि यह **सभी कॉन्फ़िगर की गई VMs में मनमाने PS कोड को निष्पादित करने** की अनुमति देता था, जिससे इन VMs की प्रबंधित पहचान के लिए विशेषाधिकार बढ़ाने की अनुमति मिलती थी, संभावित रूप से नए नेटवर्क में पिवटिंग... इसके अलावा, कॉन्फ़िगरेशन में **संवेदनशील जानकारी** हो सकती है। +हमलावरों के दृष्टिकोण से यह दिलचस्प था क्योंकि यह **सभी कॉन्फ़िगर की गई VMs में मनमाने PS कोड को निष्पादित करने** की अनुमति देता था जिससे इन VMs की प्रबंधित पहचानों के लिए विशेषाधिकार बढ़ाने की अनुमति मिलती थी, संभावित रूप से नए नेटवर्क में पिवटिंग... इसके अलावा, कॉन्फ़िगरेशन में **संवेदनशील जानकारी** हो सकती है। ## Enumeration ```bash @@ -238,4 +238,4 @@ Get-AzAutomationHybridWorkerGroup -AutomationAccountName -R - [https://learn.microsoft.com/en-us/azure/automation/automation-dsc-overview](https://learn.microsoft.com/en-us/azure/automation/automation-dsc-overview) - [https://github.com/rootsecdev/Azure-Red-Team#runbook-automation](https://github.com/rootsecdev/Azure-Red-Team#runbook-automation) -{{#include ../../../../banners/hacktricks-training.md}} +{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-services/az-container-instances.md b/src/pentesting-cloud/azure-security/az-services/az-container-instances.md index a58172711..4bd4824b3 100644 --- a/src/pentesting-cloud/azure-security/az-services/az-container-instances.md +++ b/src/pentesting-cloud/azure-security/az-services/az-container-instances.md @@ -1,6 +1,6 @@ # Az - Container Instances -{{#include ../../../../banners/hacktricks-training.md}} +{{#include ../../../banners/hacktricks-training.md}} ## Basic Information @@ -18,7 +18,7 @@ Azure Container Instances (ACI) एक **सर्वरलेस, ऑन-डि - **पोर्ट्स** - **CPU और मेमोरी सीमाएँ** - **रीस्टार्ट नीति** -- **विशेषाधिकार प्राप्त के रूप में चलाएँ** +- **प्रिविलेज्ड के रूप में चलाएँ** - **चलाने के लिए कमांड लाइन** - ... diff --git a/src/pentesting-cloud/azure-security/az-services/az-container-registry.md b/src/pentesting-cloud/azure-security/az-services/az-container-registry.md index 76860ada7..8cd68b562 100644 --- a/src/pentesting-cloud/azure-security/az-services/az-container-registry.md +++ b/src/pentesting-cloud/azure-security/az-services/az-container-registry.md @@ -1,6 +1,6 @@ # Az - Container Registry -{{#include ../../../../banners/hacktricks-training.md}} +{{#include ../../../banners/hacktricks-training.md}} ## Basic Information @@ -20,19 +20,19 @@ Azure Container Registry (ACR) एक सुरक्षित, निजी र कुछ **बिल्ट-इन भूमिकाएँ** भी हैं जिन्हें सौंपा जा सकता है, और **कस्टम भूमिकाएँ** बनाना भी संभव है। -![]() +![](/images/registry_roles.png) ### Authentication > [!WARNING] -> यह बहुत महत्वपूर्ण है कि भले ही रजिस्ट्री नाम में कुछ बड़े अक्षर हों, आपको हमेशा **छोटे अक्षरों** का उपयोग करके लॉगिन, इमेज पुश और पुल करना चाहिए। +> यह बहुत महत्वपूर्ण है कि भले ही रजिस्ट्री नाम में कुछ बड़े अक्षर हों, आपको हमेशा **छोटे अक्षरों** का उपयोग करके लॉगिन, पुश और पुल इमेज करनी चाहिए। -ACR में प्रमाणित होने के 4 तरीके हैं: +ACR के लिए प्रमाणित होने के 4 तरीके हैं: -- **Entra ID के साथ**: यह ACR में प्रमाणित होने का **डिफ़ॉल्ट** तरीका है। यह ACR में प्रमाणित होने के लिए **`az acr login`** कमांड का उपयोग करता है। यह कमांड **`~/.docker/config.json`** फ़ाइल में **क्रेडेंशियल्स** को **स्टोर** करेगा। इसके अलावा, यदि आप इस कमांड को ऐसे वातावरण से चला रहे हैं जिसमें डॉकर सॉकेट तक पहुंच नहीं है जैसे कि **क्लाउड शेल** में, तो ACR में प्रमाणित होने के लिए **`--expose-token`** ध्वज का उपयोग करके **टोकन** प्राप्त करना संभव है। फिर प्रमाणित होने के लिए आपको उपयोगकर्ता नाम के रूप में `00000000-0000-0000-0000-000000000000` का उपयोग करना होगा जैसे: `docker login myregistry.azurecr.io --username 00000000-0000-0000-0000-000000000000 --password-stdin <<< $TOKEN` -- **एक प्रशासनिक खाते के साथ**: प्रशासनिक उपयोगकर्ता डिफ़ॉल्ट रूप से अक्षम होता है लेकिन इसे सक्षम किया जा सकता है और फिर रजिस्ट्री तक पहुंच प्राप्त करना संभव होगा प्रशासनिक खाते के **उपयोगकर्ता नाम** और **पासवर्ड** के साथ जिसमें रजिस्ट्री के लिए पूर्ण अनुमतियाँ होती हैं। यह अभी भी समर्थित है क्योंकि कुछ Azure सेवाएँ इसका उपयोग करती हैं। ध्यान दें कि इस उपयोगकर्ता के लिए **2 पासवर्ड** बनाए जाते हैं और दोनों मान्य होते हैं। आप इसे `az acr update -n --admin-enabled true` के साथ सक्षम कर सकते हैं। ध्यान दें कि उपयोगकर्ता नाम आमतौर पर रजिस्ट्री का नाम होता है (और `admin` नहीं)। -- **एक टोकन के साथ**: रजिस्ट्री तक पहुंच के लिए एक **विशिष्ट `scope map`** (अनुमतियाँ) के साथ एक **टोकन** बनाना संभव है। फिर, इस टोकन नाम का उपयोग उपयोगकर्ता नाम के रूप में और रजिस्ट्री में प्रमाणित होने के लिए कुछ उत्पन्न पासवर्ड का उपयोग करना संभव है `docker login -u -p aregistry-url>` -- **एक सेवा प्रमुख के साथ**: एक **सेवा प्रमुख** बनाना और इमेज खींचने के लिए **`AcrPull`** जैसी भूमिका सौंपना संभव है। फिर, यह SP appId को उपयोगकर्ता नाम के रूप में और एक उत्पन्न गुप्त को पासवर्ड के रूप में उपयोग करके **रजिस्ट्री में लॉगिन** करना संभव होगा। +- **Entra ID के साथ**: यह ACR के लिए प्रमाणित होने का **डिफ़ॉल्ट** तरीका है। यह ACR के लिए प्रमाणित करने के लिए **`az acr login`** कमांड का उपयोग करता है। यह कमांड **`~/.docker/config.json`** फ़ाइल में **क्रेडेंशियल्स** को **स्टोर** करेगा। इसके अलावा, यदि आप इस कमांड को ऐसे वातावरण से चला रहे हैं जिसमें डॉकर सॉकेट तक पहुंच नहीं है जैसे कि **क्लाउड शेल**, तो ACR के लिए प्रमाणित करने के लिए **`--expose-token`** ध्वज का उपयोग करके **टोकन** प्राप्त करना संभव है। फिर प्रमाणित करने के लिए आपको उपयोगकर्ता नाम के रूप में `00000000-0000-0000-0000-000000000000` का उपयोग करना होगा जैसे: `docker login myregistry.azurecr.io --username 00000000-0000-0000-0000-000000000000 --password-stdin <<< $TOKEN` +- **एक व्यवस्थापक खाते के साथ**: व्यवस्थापक उपयोगकर्ता डिफ़ॉल्ट रूप से अक्षम होता है लेकिन इसे सक्षम किया जा सकता है और फिर रजिस्ट्री तक पहुंच प्राप्त करने के लिए व्यवस्थापक खाते के **उपयोगकर्ता नाम** और **पासवर्ड** का उपयोग किया जा सकता है जिसमें रजिस्ट्री के लिए पूर्ण अनुमतियाँ होती हैं। यह अभी भी समर्थित है क्योंकि कुछ Azure सेवाएँ इसका उपयोग करती हैं। ध्यान दें कि इस उपयोगकर्ता के लिए **2 पासवर्ड** बनाए जाते हैं और दोनों मान्य होते हैं। आप इसे `az acr update -n --admin-enabled true` के साथ सक्षम कर सकते हैं। ध्यान दें कि उपयोगकर्ता नाम आमतौर पर रजिस्ट्री का नाम होता है (और `admin` नहीं)। +- **एक टोकन के साथ**: रजिस्ट्री तक पहुंच के लिए **विशिष्ट `scope map`** (अनुमतियाँ) के साथ एक **टोकन** बनाना संभव है। फिर, इस टोकन नाम का उपयोग उपयोगकर्ता नाम के रूप में और रजिस्ट्री में प्रमाणित करने के लिए कुछ उत्पन्न पासवर्ड का उपयोग करना संभव है `docker login -u -p aregistry-url>` +- **एक सेवा प्रमुख के साथ**: एक **सेवा प्रमुख** बनाना और इमेज खींचने के लिए **`AcrPull`** जैसी भूमिका सौंपना संभव है। फिर, SP appId का उपयोग करके रजिस्ट्री में **लॉगिन करना** संभव होगा और एक उत्पन्न गुप्त को पासवर्ड के रूप में उपयोग करना होगा। रजिस्ट्री पर पहुंच के लिए SP उत्पन्न करने के लिए [docs](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-auth-service-principal) से उदाहरण स्क्रिप्ट: ```bash @@ -67,9 +67,9 @@ echo "Service principal password: $PASSWORD" ### Webhooks -यह registry के अंदर **webhooks** **create** करना संभव है। इस webhook में उस URL को निर्दिष्ट करना आवश्यक है जहाँ एक **request भेजी जाएगी जब भी एक push या delete action किया जाता है**। इसके अलावा, Webhooks एक scope को इंगित कर सकते हैं ताकि उन repositories (images) को इंगित किया जा सके जो प्रभावित होंगी। उदाहरण के लिए, 'foo:*' का अर्थ है repository 'foo' के तहत घटनाएँ। +यह registry के अंदर **webhooks** **create** करना संभव है। इस webhook में उस URL को निर्दिष्ट करना आवश्यक है जहाँ एक **request भेजी जाएगी जब भी एक push या delete action किया जाएगा**। इसके अलावा, Webhooks एक scope को इंगित कर सकते हैं ताकि उन repositories (images) को इंगित किया जा सके जो प्रभावित होंगी। उदाहरण के लिए, 'foo:\*' का अर्थ है repository 'foo' के तहत घटनाएँ। -एक हमलावर के दृष्टिकोण से, registry में किसी भी कार्रवाई करने से पहले इसे जांचना दिलचस्प है, और यदि आवश्यक हो तो इसे अस्थायी रूप से हटा देना चाहिए, ताकि पता न चले। +एक हमलावर के दृष्टिकोण से, registry में कोई भी कार्रवाई करने से पहले इसे चेक करना दिलचस्प है, और यदि आवश्यक हो तो इसे अस्थायी रूप से हटा देना चाहिए, ताकि पता न चले। ### Connected registries @@ -94,13 +94,13 @@ az acr run --registry mycontainerregistry008 --cmd '$Registry/sample/hello-world ``` हालांकि, यह ऐसे रन को ट्रिगर करेगा जो हमलावर के दृष्टिकोण से बहुत दिलचस्प नहीं हैं क्योंकि उनके साथ कोई प्रबंधित पहचान संलग्न नहीं है। -हालांकि, **tasks** के साथ **system और user managed identity** संलग्न हो सकते हैं। ये tasks वे हैं जो कंटेनर में **privileges को बढ़ाने** के लिए उपयोगी हैं। प्रिविलेज़ एस्कलेशन सेक्शन में यह देखना संभव है कि प्रिविलेज़ को बढ़ाने के लिए tasks का उपयोग कैसे किया जाए। +हालांकि, **tasks** के साथ **system and user managed identity** संलग्न हो सकती है। ये tasks वे हैं जो कंटेनर में **privileges** को **escalate** करने के लिए उपयोगी हैं। प्रिविलेज़ एस्कलेशन सेक्शन में यह देखना संभव है कि प्रिविलेज़ को एस्केलेट करने के लिए tasks का उपयोग कैसे किया जाए। ### Cache कैश फीचर **एक बाहरी रिपॉजिटरी से इमेज डाउनलोड करने** और नए संस्करणों को रजिस्ट्री में स्टोर करने की अनुमति देता है। इसके लिए Azure Vault से क्रेडेंशियल्स का चयन करके कुछ **credentials configured** होना आवश्यक है। -यह हमलावर के दृष्टिकोण से बहुत दिलचस्प है क्योंकि यह **एक बाहरी प्लेटफॉर्म पर पिवट करने** की अनुमति देता है यदि हमलावर के पास क्रेडेंशियल्स तक पहुंचने के लिए पर्याप्त अनुमतियाँ हैं, **एक बाहरी रिपॉजिटरी से इमेज डाउनलोड करने** और कैश को कॉन्फ़िगर करना **persistency mechanism** के रूप में भी उपयोग किया जा सकता है। +यह हमलावर के दृष्टिकोण से बहुत दिलचस्प है क्योंकि यह **एक बाहरी प्लेटफॉर्म पर पिवट** करने की अनुमति देता है यदि हमलावर के पास क्रेडेंशियल्स तक पहुंचने के लिए पर्याप्त अनुमतियाँ हैं, **एक बाहरी रिपॉजिटरी से इमेज डाउनलोड करने** और कैश को कॉन्फ़िगर करने का उपयोग **persistency mechanism** के रूप में भी किया जा सकता है। ## Enumeration @@ -143,7 +143,7 @@ az acr cache list --registry # Get cache details az acr cache show --name --registry ``` -## विशेषाधिकार वृद्धि और पोस्ट एक्सप्लॉइटेशन +## विशेषाधिकार वृद्धि और पोस्ट एक्सप्लोइटेशन {{#ref}} ../az-privilege-escalation/az-automation-accounts-privesc.md @@ -154,4 +154,4 @@ az acr cache show --name --registry - [https://learn.microsoft.com/en-us/azure/container-registry/container-registry-authentication?tabs=azure-cli](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-authentication?tabs=azure-cli) - [https://learn.microsoft.com/en-us/azure/container-registry/container-registry-roles?tabs=azure-cli#access-resource-manager](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-roles?tabs=azure-cli#access-resource-manager) -{{#include ../../../../banners/hacktricks-training.md}} +{{#include ../../../banners/hacktricks-training.md}} diff --git a/theme/ht_searcher.js b/theme/ht_searcher.js index 1cee01a8c..276bbfe6a 100644 --- a/theme/ht_searcher.js +++ b/theme/ht_searcher.js @@ -471,12 +471,12 @@ window.search = window.search || {}; showResults(true); } - fetch(path_to_root + 'searchindex.json') + fetch('https://raw.githubusercontent.com/HackTricks-wiki/hacktricks-cloud/refs/heads/master/searchindex.json') .then(response => response.json()) .then(json => init(json)) .catch(error => { // Try to load searchindex.js if fetch failed var script = document.createElement('script'); - script.src = path_to_root + 'searchindex.js'; + script.src = 'https://raw.githubusercontent.com/HackTricks-wiki/hacktricks-cloud/refs/heads/master/searchindex.js'; script.onload = () => init(window.search); document.head.appendChild(script); });