mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-26 20:54:14 -08:00
Translated ['src/pentesting-ci-cd/ansible-tower-awx-automation-controlle
This commit is contained in:
Translator
@@ -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}}
|
||||
|
||||
@@ -1,5 +1,7 @@
|
||||
# OpenShift - मूल जानकारी
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Kubernetes पूर्व b**asic knowledge** <a href="#a94e" id="a94e"></a>
|
||||
|
||||
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=<server> --token=<bearer token>
|
||||
```
|
||||
### **OpenShift - सुरक्षा संदर्भ प्रतिबंध** <a href="#a94e" id="a94e"></a>
|
||||
|
||||
उपयोगकर्ता क्या कर सकता है, इसे नियंत्रित करने वाले [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}}
|
||||
|
||||
@@ -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}}
|
||||
|
||||
@@ -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}}
|
||||
|
||||
@@ -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}}
|
||||
|
||||
@@ -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 प्राप्त करते हैं।
|
||||
|
||||
<figure><img src="../../../images/openshift-missing-service-account-image1.png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
पिछले ग्राफ में हमारे पास कई 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}}
|
||||
|
||||
@@ -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 लागू नहीं होते हैं, प्रभावी रूप से किसी भी प्रतिबंध को हटा देते हैं।
|
||||
|
||||
<figure><img src="../../../images/Openshift-RunLevel4.png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
@@ -47,7 +49,7 @@ name: evil
|
||||
labels:
|
||||
openshift.io/run-level: 0
|
||||
```
|
||||
अब, नामस्थान पर बनाए गए सभी नए पॉड्स में कोई SCC नहीं होनी चाहिए
|
||||
अब, नामस्थान पर बनाए गए सभी नए पॉड्स के पास कोई SCC नहीं होना चाहिए
|
||||
|
||||
<pre class="language-bash"><code class="lang-bash"><strong>$ oc get pod -o yaml | grep 'openshift.io/scc'
|
||||
</strong><strong>$
|
||||
@@ -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}}
|
||||
|
||||
@@ -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}}
|
||||
|
||||
@@ -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}}
|
||||
|
||||
Reference in New Issue
Block a user