AppArmor
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
AppArmor एक कर्नेल संवर्धन है जिसे कार्यक्रमों के लिए उपलब्ध संसाधनों को प्रति-कार्यक्रम प्रोफाइल के माध्यम से प्रतिबंधित करने के लिए डिज़ाइन किया गया है, प्रभावी रूप से अनिवार्य पहुँच नियंत्रण (MAC) को लागू करता है, जो पहुँच नियंत्रण विशेषताओं को सीधे कार्यक्रमों से जोड़ता है बजाय उपयोगकर्ताओं के। यह प्रणाली कर्नेल में प्रोफाइल लोड करके काम करती है, आमतौर पर बूट के दौरान, और ये प्रोफाइल निर्धारित करते हैं कि एक कार्यक्रम किन संसाधनों तक पहुँच सकता है, जैसे नेटवर्क कनेक्शन, कच्चे सॉकेट तक पहुँच, और फ़ाइल अनुमतियाँ।
AppArmor प्रोफाइल के लिए दो संचालन मोड हैं:
Enforcement Mode: यह मोड प्रोफाइल के भीतर परिभाषित नीतियों को सक्रिय रूप से लागू करता है, उन क्रियाओं को अवरुद्ध करता है जो इन नीतियों का उल्लंघन करती हैं और syslog या auditd जैसे सिस्टम के माध्यम से उल्लंघन के किसी भी प्रयास को लॉग करता है।
Complain Mode: प्रवर्तन मोड के विपरीत, शिकायत मोड उन क्रियाओं को अवरुद्ध नहीं करता है जो प्रोफाइल की नीतियों के खिलाफ जाती हैं। इसके बजाय, यह इन प्रयासों को नीति उल्लंघनों के रूप में लॉग करता है बिना प्रतिबंध लागू किए।
Kernel Module: नीतियों के प्रवर्तन के लिए जिम्मेदार।
Policies: कार्यक्रम के व्यवहार और संसाधन पहुँच के लिए नियम और प्रतिबंध निर्दिष्ट करते हैं।
Parser: प्रवर्तन या रिपोर्टिंग के लिए नीतियों को कर्नेल में लोड करता है।
Utilities: ये उपयोगकर्ता-मोड कार्यक्रम हैं जो AppArmor के साथ बातचीत करने और प्रबंधित करने के लिए एक इंटरफ़ेस प्रदान करते हैं।
Apparmor प्रोफाइल आमतौर पर /etc/apparmor.d/ में सहेजे जाते हैं।
sudo aa-status
के साथ आप उन बाइनरीज़ की सूची प्राप्त कर सकेंगे जो किसी प्रोफाइल द्वारा प्रतिबंधित हैं। यदि आप सूचीबद्ध प्रत्येक बाइनरी के पथ में "/" को बिंदु में बदल सकते हैं, तो आप उल्लेखित फ़ोल्डर के भीतर apparmor प्रोफाइल का नाम प्राप्त करेंगे।
उदाहरण के लिए, /usr/bin/man के लिए एक apparmor प्रोफाइल /etc/apparmor.d/usr.bin.man में स्थित होगा।
प्रभावित निष्पादन योग्य को इंगित करने के लिए, पूर्ण पथ और वाइल्डकार्ड फ़ाइलों को निर्दिष्ट करने के लिए अनुमति है (फ़ाइल ग्लोबिंग के लिए)।
यह इंगित करने के लिए कि बाइनरी के पास फाइलों पर क्या पहुंच होगी, निम्नलिखित एक्सेस नियंत्रण का उपयोग किया जा सकता है:
r (पढ़ें)
w (लिखें)
m (निष्पादन योग्य के रूप में मेमोरी मैप)
k (फाइल लॉकिंग)
l (हार्ड लिंक बनाना)
ix (एक नए प्रोग्राम के साथ दूसरे प्रोग्राम को निष्पादित करने के लिए नीति विरासत में लेना)
Px (दूसरे प्रोफ़ाइल के तहत निष्पादित करें, पर्यावरण को साफ़ करने के बाद)
Cx (एक बच्चे के प्रोफ़ाइल के तहत निष्पादित करें, पर्यावरण को साफ़ करने के बाद)
Ux (बिना किसी प्रतिबंध के निष्पादित करें, पर्यावरण को साफ़ करने के बाद)
चर को प्रोफाइल में परिभाषित किया जा सकता है और प्रोफाइल के बाहर से हेरफेर किया जा सकता है। उदाहरण: @{PROC} और @{HOME} (प्रोफ़ाइल फ़ाइल में #include <tunables/global> जोड़ें)
अनुमति नियमों को ओवरराइड करने के लिए अस्वीकृति नियमों का समर्थन किया जाता है।
प्रोफ़ाइल बनाने की प्रक्रिया को आसान बनाने के लिए apparmor आपकी मदद कर सकता है। यह संभव है कि apparmor एक बाइनरी द्वारा किए गए कार्यों का निरीक्षण करे और फिर आपको यह तय करने दे कि आप कौन से कार्यों की अनुमति देना या अस्वीकृत करना चाहते हैं। आपको बस यह चलाना है:
फिर, एक अलग कंसोल में सभी क्रियाएँ करें जो बाइनरी आमतौर पर करेगी:
फिर, पहले कंसोल में "s" दबाएं और फिर रिकॉर्ड की गई क्रियाओं में संकेत दें कि आप क्या अनदेखा, अनुमति या कुछ और करना चाहते हैं। जब आप समाप्त कर लें, तो "f" दबाएं और नया प्रोफ़ाइल /etc/apparmor.d/path.to.binary में बनाया जाएगा।
तीर कुंजियों का उपयोग करके आप चुन सकते हैं कि आप क्या अनुमति/अस्वीकृत/कुछ और करना चाहते हैं
आप एक बाइनरी के apparmor प्रोफ़ाइल का टेम्पलेट भी बना सकते हैं:
ध्यान दें कि एक बनाए गए प्रोफ़ाइल में डिफ़ॉल्ट रूप से कुछ भी अनुमति नहीं है, इसलिए सब कुछ अस्वीकृत है। आपको /etc/passwd r,
जैसी पंक्तियाँ जोड़ने की आवश्यकता होगी ताकि बाइनरी को /etc/passwd
पढ़ने की अनुमति मिल सके, उदाहरण के लिए।
आप फिर लागू कर सकते हैं नया प्रोफ़ाइल के साथ
निम्नलिखित उपकरण लॉग पढ़ेगा और उपयोगकर्ता से पूछेगा कि क्या वह कुछ पहचाने गए प्रतिबंधित क्रियाओं की अनुमति देना चाहता है:
तीर कुंजियों का उपयोग करके आप चुन सकते हैं कि आप क्या अनुमति देना/अस्वीकृत करना/कुछ और करना चाहते हैं
Example of AUDIT and DENIED logs from /var/log/audit/audit.log of the executable service_bin
:
आप इस जानकारी को निम्नलिखित का उपयोग करके भी प्राप्त कर सकते हैं:
ध्यान दें कि docker-profile का प्रोफ़ाइल डॉकर द्वारा डिफ़ॉल्ट रूप से लोड किया जाता है:
डिफ़ॉल्ट रूप से Apparmor docker-default प्रोफ़ाइल https://github.com/moby/moby/tree/master/profiles/apparmor से उत्पन्न होती है
docker-default प्रोफ़ाइल सारांश:
सभी नेटवर्किंग तक पहुँच
कोई क्षमता परिभाषित नहीं है (हालांकि, कुछ क्षमताएँ बुनियादी आधार नियमों को शामिल करने से आएँगी यानी #include <abstractions/base>)
किसी भी /proc फ़ाइल में लिखना अनुमति नहीं है
/proc और /sys के अन्य उपनिर्देशिकाएँ/फ़ाइलें पढ़ने/लिखने/लॉक/लिंक/निष्पादित करने की पहुँच अस्वीकृत हैं
माउंट अनुमति नहीं है
Ptrace केवल उस प्रक्रिया पर चलाया जा सकता है जो समान apparmor प्रोफ़ाइल द्वारा सीमित है
एक बार जब आप docker कंटेनर चलाते हैं, तो आपको निम्नलिखित आउटपुट देखना चाहिए:
ध्यान दें कि apparmor डिफ़ॉल्ट रूप से कंटेनर को दी गई क्षमताओं के विशेषाधिकारों को भी ब्लॉक करेगा। उदाहरण के लिए, यह /proc के अंदर लिखने की अनुमति को ब्लॉक कर सकेगा, भले ही SYS_ADMIN क्षमता दी गई हो क्योंकि डिफ़ॉल्ट रूप से docker apparmor प्रोफ़ाइल इस एक्सेस को अस्वीकार करती है:
आपको इसकी सीमाओं को बायपास करने के लिए apparmor को अक्षम करना होगा:
ध्यान दें कि डिफ़ॉल्ट रूप से AppArmor भी कंटेनर को अंदर से फ़ोल्डर माउंट करने से मना करेगा भले ही SYS_ADMIN क्षमता हो।
ध्यान दें कि आप docker कंटेनर में क्षमताएँ जोड़/हटा सकते हैं (यह अभी भी AppArmor और Seccomp जैसी सुरक्षा विधियों द्वारा प्रतिबंधित होगा):
--cap-add=SYS_ADMIN
SYS_ADMIN
क्षमता दें
--cap-add=ALL
सभी क्षमताएँ दें
--cap-drop=ALL --cap-add=SYS_PTRACE
सभी क्षमताएँ हटा दें और केवल SYS_PTRACE
दें
आमतौर पर, जब आप पाते हैं कि आपके पास एक विशिष्ट क्षमता docker कंटेनर के अंदर उपलब्ध है लेकिन शोषण का कुछ हिस्सा काम नहीं कर रहा है, तो इसका कारण यह होगा कि docker apparmor इसे रोक रहा होगा।
(उदाहरण यहां से)
AppArmor कार्यक्षमता को स्पष्ट करने के लिए, मैंने निम्नलिखित पंक्ति के साथ एक नया Docker प्रोफ़ाइल "mydocker" बनाया:
प्रोफ़ाइल को सक्रिय करने के लिए, हमें निम्नलिखित करना होगा:
प्रोफाइल सूचीबद्ध करने के लिए, हम निम्नलिखित कमांड कर सकते हैं। नीचे दी गई कमांड मेरे नए AppArmor प्रोफाइल को सूचीबद्ध कर रही है।
जैसा कि नीचे दिखाया गया है, जब हम “/etc/” को बदलने की कोशिश करते हैं तो हमें त्रुटि मिलती है क्योंकि AppArmor प्रोफ़ाइल “/etc” पर लिखने की पहुँच को रोक रही है।
आप यह पता लगा सकते हैं कि कौन सा apparmor प्रोफ़ाइल एक कंटेनर चला रहा है:
फिर, आप निम्नलिखित पंक्ति चला सकते हैं सटीक प्रोफ़ाइल खोजने के लिए जो उपयोग की जा रही है:
In the weird case you can modify the apparmor docker profile and reload it. You could remove the restrictions and "bypass" them.
AppArmor is path based, this means that even if it might be protecting files inside a directory like /proc
if you can configure how the container is going to be run, you could mount the proc directory of the host inside /host/proc
and it won't be protected by AppArmor anymore.
In this bug you can see an example of how even if you are preventing perl to be run with certain resources, if you just create a a shell script specifying in the first line #!/usr/bin/perl
and you execute the file directly, you will be able to execute whatever you want. E.g.:
अजीब स्थिति में आप apparmor docker प्रोफ़ाइल को संशोधित कर सकते हैं और इसे फिर से लोड कर सकते हैं। आप प्रतिबंधों को हटा सकते हैं और "बायपास" कर सकते हैं।
AppArmor पथ आधारित है, इसका मतलब है कि भले ही यह एक निर्देशिका के अंदर फ़ाइलों की रक्षा कर रहा हो जैसे कि /proc
यदि आप कॉन्फ़िगर कर सकते हैं कि कंटेनर कैसे चलाया जाएगा, आप माउंट कर सकते हैं होस्ट की proc निर्देशिका को /host/proc
के अंदर और यह अब AppArmor द्वारा संरक्षित नहीं होगा।
इस बग में आप एक उदाहरण देख सकते हैं कि भले ही आप कुछ संसाधनों के साथ perl को चलाने से रोक रहे हों, यदि आप बस एक शेल स्क्रिप्ट बनाते हैं पहली पंक्ति में निर्दिष्ट करते हुए #!/usr/bin/perl
और आप फाइल को सीधे निष्पादित करते हैं, तो आप जो चाहें उसे निष्पादित कर सकेंगे। उदाहरण:
सीखें और प्रैक्टिस करें AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) सीखें और प्रैक्टिस करें GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)