Linux Privilege Escalation
सिस्टम सूचना
ओएस सूचना
आइए शुरू करते हैं जिसमें ओएस चल रहा है की कुछ जानकारी प्राप्त करना।
पथ
यदि आपको PATH
चर में किसी भी फोल्डर पर लेखन अनुमति है तो आपको कुछ लाइब्रेरी या बाइनरी को हाइजैक करने की संभावना हो सकती है:
वातावरण सूचना
क्या वातावरण में दिलचस्प जानकारी, पासवर्ड या API कुंजी हैं?
कर्नेल एक्सप्लॉइट्स
कर्नेल संस्करण की जाँच करें और यदि कोई एक्सप्लॉइट है जो उच्चाधिकार प्राप्त करने के लिए उपयोग किया जा सकता है
आप एक अच्छी तरह से वंशवादी कर्नेल सूची और कुछ पहले से कंपाइल किए गए एक्सप्लॉइट्स यहाँ पा सकते हैं: https://github.com/lucyoa/kernel-exploits और exploitdb sploits. अन्य साइट जहां आप कुछ कंपाइल किए गए एक्सप्लॉइट्स पा सकते हैं: https://github.com/bwbwbwbw/linux-exploit-binaries, https://github.com/Kabot/Unix-Privilege-Escalation-Exploits-Pack
उस वेबसाइट से सभी वंशवादी कर्नेल संस्करणों को निकालने के लिए आप कर सकते हैं:
उपकरण जो कर्नेल एक्सप्लॉइट्स की खोज में मदद कर सकते हैं:
linux-exploit-suggester.sh linux-exploit-suggester2.pl linuxprivchecker.py (कुर्बान में निष्पादित करें, कर्नेल 2.x के लिए केवल एक्सप्लॉइट्स की जांच करता है)
हमेशा Google में कर्नेल संस्करण की खोज करें, शायद आपके कर्नेल संस्करण को किसी कर्नेल एक्सप्लॉइट में लिखा गया हो और फिर आप यह सुनिश्चित करेंगे कि यह एक्सप्लॉइट वैध है।
CVE-2016-5195 (DirtyCow)
Linux विशेषाधिकार उन्नति - Linux कर्नेल <= 3.19.0-73.8
सुडो संस्करण
जो भी सुडो संस्करण अविश्वसनीय हैं, उस पर आधारित:
आप इस grep का उपयोग करके जांच सकते हैं कि sudo संस्करण में कोई सुरक्षितता संदेह है।
sudo < v1.28
@sickrov द्वारा
Dmesg हस्ताक्षर सत्यापन विफल
इस भेदन को कैसे शोषित किया जा सकता है का एक उदाहरण देखने के लिए HTB के smasher2 बॉक्स की जाँच करें
अधिक सिस्टम जांच
विभाजन संभावित सुरक्षा
AppArmor
Grsecurity
ग्रसुरक्षा
पैक्स
एक्ज़ीक्यूशील्ड
SElinux
ASLR
ASLR (Address Space Layout Randomization) एक security feature है जो किसी process के memory layout को randomize करता है, जिससे किसी attacker को exploit करना मुश्किल हो जाता है।
Docker Breakout
यदि आप एक डॉकर कंटेनर के अंदर हैं तो आप इससे बाहर निकलने का प्रयास कर सकते हैं:
Docker Securityड्राइव्स
जांचें कि क्या माउंट किया गया है और क्या अनमाउंट किया गया है, कहाँ और क्यों। यदि कुछ अनमाउंट किया गया है तो आप उसे माउंट करने का प्रयास कर सकते हैं और निजी जानकारी के लिए जांच कर सकते हैं।
उपयोगी सॉफ़्टवेयर
उपयोगी बाइनरी की जांच करें
भी जांचें कि कोई कंपाइलर स्थापित है। यह उपयोगी है अगर आपको कोई कर्णेल एक्सप्लॉइट का उपयोग करना हो तो इसे कंपाइल करना सुझावित है मशीन में जहां आप इसका उपयोग करने जा रहे हैं (या एक समान)।
इंस्टॉल किए गए संवर्णीय सॉफ्टवेयर
इंस्टॉल किए गए पैकेज और सेवाओं की संस्करण की जाँच करें। शायद कोई पुराना Nagios संस्करण (उदाहरण के लिए) हो, जिसका उपयोग विशेषाधिकारों को बढ़ाने के लिए किया जा सकता है... सुझाव दिया जाता है कि अधिक संदेहपूर्ण इंस्टॉल किए गए सॉफ्टवेयर के संस्करण की जाँच मैन्युअल रूप से की जाए।
यदि आपके पास मशीन का SSH एक्सेस है तो आप openVAS का उपयोग करके मशीन में स्थापित पुराने और वंशकर सॉफ्टवेयर की जांच कर सकते हैं।
ध्यान दें कि ये कमांड्स बहुत सारी जानकारी दिखाएंगे जो अधिकांशत: अफ़ाल होगी, इसलिए सिफारिश की जाती है कुछ एप्लिकेशन्स जैसे OpenVAS या समान जो जांचें कि क्या कोई स्थापित सॉफ्टवेयर संस्करण ज्ञात दुरुपयोगों के लिए वंशकर है
प्रक्रियाएँ
देखें कि कौन सी प्रक्रियाएँ कार्यान्वित हो रही हैं और यह जांचें कि क्या कोई प्रक्रिया जितनी अधिक अधिकार रखती है जितनी चाहिए (शायद एक टॉमकैट जो रूट द्वारा कार्यान्वित हो रहा हो?)
हमेशा electron/cef/chromium debuggers के लिए संभावित चेक करें, आप इसका दुरुपयोग करके वर्चस्व उन्नति कर सकते हैं। Linpeas इसे प्रक्रिया के कमांड लाइन में --inspect
पैरामीटर की जांच करके पहचानता है। इसके अलावा प्रक्रियाओं के बाइनरी पर अपने वर्चस्व की जांच करें, शायद आप किसी को ओवरराइट कर सकते हैं।
प्रक्रिया मॉनिटरिंग
आप pspy जैसे उपकरणों का उपयोग प्रक्रियाओं का मॉनिटरिंग करने के लिए कर सकते हैं। यह विशेष रूप से उपयोगी हो सकता है जब कोई वंश्चित प्रक्रियाएं नियमित रूप से निष्पादित हो रही हों या जब कुछ आवश्यकताएं पूरी हों।
प्रक्रिया मेमोरी
सर्वर की कुछ सेवाएं मेमोरी में स्पष्ट पाठ में क्रेडेंशियल्स सहेजती हैं। सामान्यत: आपको अन्य उपयोगकर्ताओं की प्रक्रियाओं की मेमोरी पढ़ने के लिए रूट वर्चस्व की आवश्यकता होगी, इसलिए यह आमतौर पर जब आप पहले से ही रूट हो और अधिक क्रेडेंशियल्स खोजना चाहते हों तो अधिक उपयोगी होता है। हालांकि, ध्यान रखें कि आमतौर पर एक साधारण उपयोगकर्ता के रूप में आप अपनी प्रक्रियाओं की मेमोरी पढ़ सकते हैं।
ध्यान दें कि आजकल अधिकांश मशीनों डिफ़ॉल्ट रूप से ptrace की अनुमति नहीं देते हैं जिसका मतलब है कि आप अपने अनुप्रयोगी उपयोगकर्ता के प्रक्रियाओं को डंप नहीं कर सकते।
फ़ाइल /proc/sys/kernel/yama/ptrace_scope ptrace की पहुंच को नियंत्रित करती है:
kernel.yama.ptrace_scope = 0: सभी प्रक्रियाएं डीबग की जा सकती हैं, जब तक उनका यूआईडी समान हो। यह ptracing कैसे काम करता था का क्लासिकल तरीका है।
kernel.yama.ptrace_scope = 1: केवल एक माता प्रक्रिया को डीबग किया जा सकता है।
kernel.yama.ptrace_scope = 2: केवल व्यवस्थापक ptrace का उपयोग कर सकते हैं, क्योंकि इसे CAP_SYS_PTRACE क्षमता की आवश्यकता होती है।
kernel.yama.ptrace_scope = 3: कोई प्रक्रियाएं ptrace के साथ ट्रेस नहीं की जा सकती हैं। एक बार सेट करने के बाद, ptracing को फिर से सक्षम करने के लिए एक पुनरारंभ की आवश्यकता होती है।
GDB
यदि आपके पास एफटीपी सेवा की मेमोरी का उपयोग है (उदाहरण के लिए) तो आप हीप को प्राप्त कर सकते हैं और इसके क्रेडेंशियल्स के भीतर खोज कर सकते हैं।
GDB स्क्रिप्ट
/proc/$pid/maps और /proc/$pid/mem
एक दिया गया प्रक्रिया आईडी के लिए, maps दिखाता है कि प्रक्रिया के वर्चुअल पता स्थान में मेमोरी कैसे मैप है; यह भी प्रत्येक मैप क्षेत्र की अनुमतियाँ दिखाता है। mem प्यूडो फ़ाइल प्रक्रिया की मेमोरी को खुद ही उजागर करता है। हम maps फ़ाइल से जानते हैं कि कौन से मेमोरी क्षेत्र पढ़ने योग्य हैं और उनके ऑफसेट्स। हम इस जानकारी का उपयोग करते हैं mem फ़ाइल में जाने और सभी पढ़ने योग्य क्षेत्रों को एक फ़ाइल में डंप करने के लिए।
/dev/mem
/dev/mem
प्रणाली की भौतिक स्मृति तक पहुंच प्रदान करता है, न कि आभासी स्मृति। कर्णेल का आभासी पता अंतर्ित करने के लिए /dev/kmem का उपयोग किया जा सकता है। सामान्यत: /dev/mem
केवल root और kmem समूह द्वारा पढ़ने योग्य होता है।
लिनक्स के लिए ProcDump
ProcDump एक लिनक्स का नया रूपांतरण है, जो विंडोज के सिसइंटरनल्स सुइट के क्लासिक ProcDump टूल का है। इसे https://github.com/Sysinternals/ProcDump-for-Linux से प्राप्त करें।
उपकरण
प्रक्रिया की मेमोरी डंप करने के लिए आप निम्न उपकरण का उपयोग कर सकते हैं:
https://github.com/hajzer/bash-memory-dump (रूट) - _आप रूट आवश्यकताओं को मैन्युअल रूप से हटा सकते हैं और आपके द्वारा स्वामित प्रक्रिया को डंप कर सकते हैं
https://www.delaat.net/rp/2016-2017/p97/report.pdf से स्क्रिप्ट A.5 (रूट की आवश्यकता है)
प्रक्रिया मेमोरी से क्रेडेंशियल्स
मैन्युअल उदाहरण
यदि आपको लगता है कि प्रमाणीकरण प्रक्रिया चल रही है:
आप प्रक्रिया को डंप कर सकते हैं (प्रक्रिया की मेमोरी को डंप करने के विभिन्न तरीकों को जानने के लिए पहले खंड देखें) और मेमोरी में क्रेडेंशियल्स खोज सकते हैं:
मिमीपेंग्विन
यह टूल https://github.com/huntergregal/mimipenguin मेमोरी से साफ पाठ प्रमाणपत्र चुरा लेगा और कुछ प्रसिद्ध फ़ाइलों से। इसे सही ढंग से काम करने के लिए रूट विशेषाधिकारों की आवश्यकता है।
विशेषता | प्रक्रिया का नाम |
---|---|
GDM पासवर्ड (Kali डेस्कटॉप, Debian डेस्कटॉप) | gdm-password |
Gnome Keyring (Ubuntu डेस्कटॉप, ArchLinux डेस्कटॉप) | gnome-keyring-daemon |
LightDM (Ubuntu डेस्कटॉप) | lightdm |
VSFTPd (सक्रिय FTP कनेक्शन) | vsftpd |
Apache2 (सक्रिय HTTP बेसिक प्रमाणीकरण सत्र) | apache2 |
OpenSSH (सक्रिय SSH सत्र - सुडो उपयोग) | sshd: |
खोज रेजेक्स/truffleproc
निर्धारित/Cron नौकरियाँ
जांचें कि क्या कोई निर्धारित नौकरी वंलरेबल है। शायद आप किसी स्क्रिप्ट का फायदा उठा सकते हैं जो रूट द्वारा निष्पादित किया जा रहा है (वाइल्डकार्ड वल्न? क्या रूट द्वारा उपयोग किए जाने वाले फ़ाइलों को संशोधित किया जा सकता है? सिमलिंक का उपयोग करें? रूट द्वारा उपयोग किए जाने वाले निर्देशिका में विशेष फ़ाइलें बनाएँ?)।
क्रॉन पथ
उदाहरण के लिए, /etc/crontab के अंदर आप पाथ पा सकते हैं: PATH=/home/user:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
(ध्यान दें कि उपयोगकर्ता "user" को /home/user पर लेखन अधिकार है)
यदि इस crontab के अंदर रूट उपयोगकर्ता कोई कमांड या स्क्रिप्ट बिना पथ सेट किए को क्रियान्वित करने की कोशिश करता है। उदाहरण के लिए: * * * * root overwrite.sh तो, आप निम्नलिखित का उपयोग करके रूट शेल प्राप्त कर सकते हैं:
क्रॉन का उपयोग वाइल्डकार्ड के साथ स्क्रिप्ट का उपयोग करना (वाइल्डकार्ड इंजेक्शन)
यदि रूट द्वारा एक स्क्रिप्ट को निष्पादित किया जाता है और कमांड में "*" है, तो आप इसका शोषण कर सकते हैं ताकि अप्रत्याशित चीजें की जा सकें (जैसे privesc). उदाहरण:
यदि वाइल्डकार्ड किसी पथ के पहले हो जैसे /some/path/* , तो यह कमजोर नहीं है (यहाँ तक कि ./* भी नहीं है।)
और वाइल्डकार्ड शोधन तकनीकों के लिए निम्नलिखित पृष्ठ को पढ़ें:
Wildcards Spare tricksक्रॉन स्क्रिप्ट अधिलेखण और सिमलिंक
यदि आप रूट द्वारा निष्पादित किसी क्रॉन स्क्रिप्ट को संशोधित कर सकते हैं, तो आप बहुत आसानी से एक शैल प्राप्त कर सकते हैं:
यदि रूट द्वारा निष्पादित स्क्रिप्ट एक निर्देशिका का उपयोग करती है जिसमें आपके पास पूर्ण पहुंच है, तो शायद उस फ़ोल्डर को हटाना और एक और फ़ोल्डर के लिए एक सिमलिंक फ़ोल्डर बनाना जो आपके द्वारा नियंत्रित स्क्रिप्ट को सेव करता है
नियमित cron jobs
आप प्रक्रियाओं का मॉनिटर कर सकते हैं ताकि 1, 2 या 5 मिनट के अंतर से चलाई जा रही प्रक्रियाओं की खोज करें। शायद आप इसका फायदा उठा सकते हैं और विशेषाधिकारों को उन्नत कर सकते हैं।
उदाहरण के लिए, 1 मिनट के दौरान हर 0.1 सेकंड का मॉनिटरिंग करने के लिए, कम चलाए गए कमांडों से क्रमबद्ध करें और सबसे अधिक चलाए गए कमांडों को हटाने के लिए, आप निम्नलिखित कर सकते हैं:
आप यहाँ भी उपयोग कर सकते हैं pspy (यह हर प्रक्रिया को मॉनिटर और सूचीबद्ध करेगा जो शुरू होती है)।
अदृश्य cron जॉब्स
एक क्रॉन जॉब बनाना संभव है एक कमेंट के बाद एक कैरिज रिटर्न डालकर (न्यूलाइन वर्णक्रम के बिना), और क्रॉन जॉब काम करेगा। उदाहरण (कैरिज रिटर्न चार ध्यान दें):
सेवाएं
लिखने योग्य .service फ़ाइलें
जांचें कि क्या आप किसी भी .service
फ़ाइल को लिख सकते हैं, यदि हां, तो आप इसे संशोधित कर सकते हैं ताकि जब सेवा शुरू, पुनः आरंभ या रोकी जाती है, तो आपका बैकडोर कार्यान्वित हो सकता है (शायद आपको मशीन को रिबूट होने तक का इंतज़ार करना पड़ेगा)।
उदाहरण के लिए अपना बैकडोर बनाएं .service फ़ाइल के अंदर ExecStart=/tmp/script.sh
लिखने योग्य सेवा बाइनरी
ध्यान रखें कि यदि आपके पास सेवाएं द्वारा क्रियान्वित किए जाने वाले बाइनरी पर लिखने की अनुमति है, तो आप उन्हें बैकडोर के लिए बदल सकते हैं ताकि जब सेवाएं पुनः क्रियान्वित हों, तो बैकडोर कार्यान्वित होंगे।
systemd PATH - सापेक्ष मार्ग
आप systemd द्वारा उपयोग किए जाने वाले PATH को देख सकते हैं:
यदि आपको लगता है कि आप किसी भी फ़ोल्डर में लिख सकते हैं तो आपको विशेषाधिकारों को बढ़ाने की संभावना हो सकती है। आपको सेवा कॉन्फ़िगरेशन फ़ाइलों पर उपयोग किए जा रहे सापेक्ष मार्गों की खोज करनी चाहिए:
फिर, executable बनाएं जिसका नाम रिलेटिव पाथ बाइनरी के नाम के समान हो सिस्टमड पाथ फोल्डर में जिसमें आप लिख सकते हैं, और जब सेवा से वंलरेबल क्रिया (शुरू, रोकें, रीलोड) को निषेधित करने के लिए कहा जाए, तो आपका बैकडोर चलाया जाएगा (अनविशेषित उपयोगकर्ता साधारणत: सेवाएं शुरू/रोकने में सक्षम नहीं हो सकती हैं लेकिन जांचें कि क्या आप sudo -l
का उपयोग कर सकते हैं।)
man systemd.service
के साथ सेवाओं के बारे में अधिक जानें।
टाइमर्स
टाइमर्स systemd यूनिट फ़ाइलें हैं जिनका नाम **.timer**
से समाप्त होता है जो **.service**
फ़ाइलों या घटनाओं को नियंत्रित करती हैं। टाइमर्स क्रॉन के विकल्प के रूप में उपयोग किए जा सकते हैं क्योंकि उनमें कैलेंडर समय घटनाओं और मोनोटोनिक समय घटनाओं के लिए सहायक समर्थन है और ये असमवर्ती रूप से चलाए जा सकते हैं।
आप सभी टाइमर्स को गणना कर सकते हैं:
लिखने योग्य टाइमर
यदि आप एक टाइमर को संशोधित कर सकते हैं तो आप इसे कुछ systemd.unit के अस्तित्व को निष्पादित करने के लिए बना सकते हैं (जैसे एक .service
या एक .target
)
दस्तावेज़ में आप पढ़ सकते हैं कि इकाई क्या है:
यह टाइमर समाप्त होने पर सक्रिय करने के लिए इकाई। तार्किक एक इकाई नाम है, जिसका सूफ़िक्स ".timer" नहीं है। यदि निर्दिष्ट नहीं किया गया है, तो यह मान एक सेवा के लिए डिफ़ॉल्ट होता है जिसका नाम टाइमर इकाई के नाम के समान है, सूफ़िक्स को छोड़कर। (ऊपर देखें।) सुझाव दिया जाता है कि सक्रिय किए जाने वाले इकाई का नाम और टाइमर इकाई का इकाई नाम समान हो, सूफ़िक्स को छोड़कर।
इसलिए, इस अनुमति का दुरुपयोग करने के लिए आपको करना होगा:
कुछ सिस्टमड इकाई (जैसे
.service
) ढूंढें जो एक लिखने योग्य बाइनरी को निष्पादित कर रहा हैकुछ सिस्टमड इकाई ढूंढें जो एक सापेक्ष मार्ग को निष्पादित कर रहा है और आपके पास सिस्टमड पाथ पर लिखने योग्य अधिकार हैं (उस निष्पादन को अनुकरण करने के लिए)
टाइमर के बारे में अधिक जानकारी के लिए man systemd.timer
का उपयोग करें।
टाइमर सक्रिय करना
टाइमर को सक्रिय करने के लिए आपको रूट अधिकार चाहिए और निम्नलिखित को निष्पादित करने की आवश्यकता है:
नोट करें कि टाइमर को /etc/systemd/system/<WantedBy_section>.wants/<name>.timer
पर एक symlink बनाकर सक्रिय किया जाता है।
सॉकेट्स
Unix डोमेन सॉकेट्स (UDS) क्लाइंट-सर्वर मॉडल के भीतर समान या भिन्न मशीनों पर प्रक्रिया संचार को संभावित बनाते हैं। इन्हें अंतर-कंप्यूटर संचार के लिए मानक Unix डिस्क्रिप्टर फ़ाइलों का उपयोग किया जाता है और ये .socket
फ़ाइलों के माध्यम से सेटअप किए जाते हैं।
सॉकेट्स को .socket
फ़ाइलों का उपयोग करके कॉन्फ़िगर किया जा सकता है।
man systemd.socket
के साथ सॉकेट्स के बारे में अधिक जानें। इस फ़ाइल के भीतर, कई दिलचस्प पैरामीटर कॉन्फ़िगर किए जा सकते हैं:
ListenStream
,ListenDatagram
,ListenSequentialPacket
,ListenFIFO
,ListenSpecial
,ListenNetlink
,ListenMessageQueue
,ListenUSBFunction
: ये विकल्प अलग-अलग हैं लेकिन एक सारांश का उपयोग सॉकेट पर कहाँ सुनेगा इसे दर्शाने के लिए किया जाता है (AF_UNIX सॉकेट फ़ाइल का पथ, सुनने के लिए IPv4/6 और/या पोर्ट नंबर, आदि)।Accept
: एक बूलियन तर्क लेता है। यदि सत्य है, तो प्रत्येक आने वाली कनेक्शन के लिए एक सेवा इंस्टेंस उत्पन्न किया जाता है और केवल कनेक्शन सॉकेट को उसे पास किया जाता है। यदि झूठा है, तो सभी सुनने वाले सॉकेट खुद को शुरू की गई सेवा इकाई को पास किया जाता है, और केवल एक सेवा इकाई सभी कनेक्शनों के लिए उत्पन्न किया जाता है। यह मान्यता डेटाग्राम सॉकेट्स और FIFOs के लिए एक ही सेवा इकाई सभी आने वाले ट्रैफ़िक को अवश्य ही संभालती है। डिफ़ॉल्ट रूप से झूठा है। प्रदर्शन कारणों के लिए, यह सुझाव दिया जाता है कि नए डेमन को केवल उस तरीके में लिखना चाहिए जोAccept=no
के लिए उपयुक्त है।ExecStartPre
,ExecStartPost
: एक या एक से अधिक कमांड लाइन लेता है, जो सुनने वाले सॉकेट/FIFOs को बनाए जाने से पहले या बाद में निष्पादित किए जाते हैं। कमांड लाइन का पहला टोकन एक पूर्ण फ़ाइल नाम होना चाहिए, फिर प्रक्रिया के लिए तर्कों का अनुसरण किया जाना चाहिए।ExecStopPre
,ExecStopPost
: अतिरिक्त कमांड जो सुनने वाले सॉकेट/FIFOs को बंद करने से पहले या बाद में निष्पादित किए जाते हैं और हटाए जाते हैं, क्रमशः।Service
: इनकमिंग ट्रैफ़िक पर सक्रिय करने के लिए नामित सेवा इकाई को निर्दिष्ट करता है। इस सेटिंग को केवल Accept=no वाले सॉकेट्स के लिए अनुमति है। इसका डिफ़ॉल्ट रूप से वह सेवा है जो सॉकेट के नाम के समान है (सफ़िक्स को बदलकर)। अधिकांश मामलों में, इस विकल्प का उपयोग करने की आवश्यकता नहीं होनी चाहिए।
लिखने योग्य .socket फ़ाइलें
यदि आपको एक लिखने योग्य .socket
फ़ाइल मिलती है तो आप [Socket]
खंड की शुरुआत में कुछ इस प्रकार कुछ जोड़ सकते हैं: ExecStartPre=/home/kali/sys/backdoor
और बैकडोर सॉकेट बनाया जाने से पहले निष्पादित होगा। इसलिए, आपको संभावित है कि मशीन को रिबूट होने तक प्रतीक्षा करनी पड़ेगी।
ध्यान दें कि सिस्टम को उस सॉकेट फ़ाइल कॉन्फ़िगरेशन का उपयोग करना चाहिए या तो बैकडोर नहीं निष्पादित होगा
लिखने योग्य सॉकेट्स
यदि आप किसी भी लिखने योग्य सॉकेट की पहचान करते हैं (अब हम Unix सॉकेट्स के बारे में बात कर रहे हैं और .socket
फ़ाइलों के बारे में नहीं), तो आप उस सॉकेट के साथ संवाद कर सकते हैं और शायद एक सुरक्षा दोष का शोध कर सकते हैं।
Unix सॉकेट्स की जांच करें
कच्ची कनेक्शन
शोषण उदाहरण:
Socket Command InjectionHTTP सॉकेट्स
ध्यान दें कि कुछ HTTP अनुरोधों के लिए सुनने वाले सॉकेट्स हो सकते हैं (मैं .socket फ़ाइलों के बारे में नहीं बात कर रहा हूँ बल्कि यूनिक्स सॉकेट के रूप में काम करने वाली फ़ाइलों के बारे में). आप इसे निम्नलिखित के साथ जांच सकते हैं:
लिखने योग्य डॉकर सॉकेट
डॉकर सॉकेट, जो अक्सर /var/run/docker.sock
पर पाया जाता है, एक महत्वपूर्ण फ़ाइल है जिसे सुरक्षित रूप से रखा जाना चाहिए। डिफ़ॉल्ट रूप से, इसे root
उपयोगकर्ता और docker
समूह के सदस्यों द्वारा लिखने योग्य बनाया गया है। इस सॉकेट को लिखने की पहुंच के पास होने से विशेषाधिकार उन्नति हो सकती है। यहाँ इसका विवरण दिया गया है कि यह कैसे किया जा सकता है और वैकल्पिक विधियाँ अगर डॉकर CLI उपलब्ध नहीं है।
डॉकर API सीधे उपयोग करना
उन स्थितियों में जहां डॉकर CLI उपलब्ध नहीं है, डॉकर API और curl
कमांड का उपयोग करके फिर भी डॉकर सॉकेट को मोड़ना संभव है।
डॉकर इमेजेस की सूची देखें: उपलब्ध इमेजेस की सूची प्राप्त करें।
एक कंटेनर बनाएं: एक अनुरोध भेजें ताकि एक कंटेनर बनाया जा सके जो होस्ट सिस्टम की रूट निर्देशिका को माउंट करता है।
नए बनाए गए कंटेनर को शुरू करें:
कंटेनर से जुड़ें:
socat
का उपयोग करें ताकि कंटेनर से जुड़ने के लिए एक कनेक्शन स्थापित किया जा सके, जिससे उसमें कमांड का निष्पादन संभव हो।
socat
कनेक्शन सेट करने के बाद, आप होस्ट की फ़ाइल सिस्टम के रूट स्तर तक पहुँचकर कंटेनर में सीधे कमांड निष्पादित कर सकते हैं।
यहाँ एक D-Bus संचार को जांचने और उसका शोषण कैसे करें सीखें:
D-Bus Enumeration & Command Injection Privilege Escalationनेटवर्क
मशीन की स्थिति का जांच करने और नेटवर्क को जांचना हमेशा दिलचस्प होता है।
सामान्य जांच
खुले पोर्ट्स
हमेशा मशीन पर चल रही नेटवर्क सेवाओं की जांच करें जिनसे आप पहले इंटरैक्ट करने में सक्षम नहीं थे:
स्निफिंग
जांचें कि क्या आप ट्रैफिक स्निफ कर सकते हैं। यदि आप कर सकते हैं, तो आप कुछ क्रेडेंशियल पकड़ सकते हैं।
उपयोगकर्ता
सामान्य गणना
जांचें कि आप कौन हैं, आपके पास कौन सी विशेषाधिकार हैं, सिस्टम में कौन उपयोगकर्ता हैं, कौन लॉगिन कर सकते हैं और कौनके पास रूट विशेषाधिकार हैं:
बड़ा UID
कुछ लिनक्स संस्करणों को एक बग से प्रभावित किया गया था जो उपयोगकर्ताओं को UID > INT_MAX के साथ विशेषाधिकारों में वृद्धि देता है। अधिक जानकारी: यहाँ, यहाँ और यहाँ।
इसे शातित करने के लिए: systemd-run -t /bin/bash
समूह
जांचें कि क्या आप किसी समूह के सदस्य हैं जो आपको रूट विशेषाधिकार प्रदान कर सकता है:
Interesting Groups - Linux Privescक्लिपबोर्ड
जांचें कि क्या कोई भी दिलचस्प वस्तु क्लिपबोर्ड में स्थित है (यदि संभव हो)
पासवर्ड नीति
ज्ञात पासवर्ड
यदि आपके पास पर्यावरण का कोई पासवर्ड है तो प्रत्येक उपयोगकर्ता के रूप में लॉगिन करने का प्रयास करें उस पासवर्ड का उपयोग करके।
Su Brute
यदि आपको ज्यादा शोर करने के बारे में कोई चिंता नहीं है और कंप्यूटर पर su
और timeout
बाइनरी मौजूद हैं, तो आप su-bruteforce का उपयोग करके उपयोगकर्ता को ब्रूट-फोर्स करने का प्रयास कर सकते हैं।
Linpeas के साथ -a
पैरामीटर का उपयोग करके भी उपयोगकर्ताओं को ब्रूट-फोर्स करने का प्रयास करें।
लिखने योग्य PATH दुरुपयोग
$PATH
यदि आपको लगता है कि आप $PATH के किसी फ़ोल्डर में लिख सकते हैं तो आप एक बैकडोर बनाकर उच्चाधिकारों को उन्नत कर सकते हैं जिसका नाम किसी ऐसे कमांड के अंदर हो सकता है जो एक विभिन्न उपयोगकर्ता (मुख्य रूप से रूट) द्वारा निष्पादित किया जाएगा और जो आपके लिखने योग्य फ़ोल्डर से पहले स्थित नहीं है $PATH में।
SUDO और SUID
आपको सुडो का उपयोग करके कुछ कमांड को निष्पादित करने की अनुमति हो सकती है या उनके पास सुइड बिट हो सकती है। इसे जांचने के लिए:
कुछ अप्रत्याशित कमांड्स आपको फ़ाइलें पढ़ने या लिखने या फिर कमांड चलाने की अनुमति देती हैं। उदाहरण के लिए:
NOPASSWD
सुडो कॉन्फ़िगरेशन एक उपयोगकर्ता को पासवर्ड पता न करते हुए किसी अन्य उपयोगकर्ता की विशेषाधिकारों के साथ कुछ कमांड को निष्पादित करने की अनुमति दे सकती है।
इस उदाहरण में उपयोगकर्ता demo
root
के रूप में vim
चला सकता है, अब रूट निर्देशिका में एक ssh कुंजी जोड़कर या sh
बुलाकर एक शैल मिलना सरल है।
SETENV
यह निर्देशिका उपयोगकर्ता को किसी चीज को क्रियान्वित करते समय एक पर्यावरण चर सेट करने की अनुमति देती है:
यह उदाहरण, HTB मशीन Admirer पर आधारित, PYTHONPATH हाइजैकिंग के लिए वंशानुक्रमिक था जबकि स्क्रिप्ट को रूट के रूप में क्रियान्वित किया जा रहा था:
Sudo कार्रवाई पथों को छलकरना
जंप करें और अन्य फ़ाइलें पढ़ें या सिमलिंक का उपयोग करें। उदाहरण के लिए sudoers फ़ाइल में: hacker10 सभी= (root) /bin/less /var/log/*
यदि एक वाइल्डकार्ड का उपयोग किया जाता है (*), तो यह और भी आसान हो जाता है:
काउंटरमेज़र्स: https://blog.compass-security.com/2012/10/dangerous-sudoers-entries-part-5-recapitulation/
Sudo कमांड/SUID बाइनरी बिना कमांड पथ के
यदि सुडो अनुमति किसी एक कमांड को पथ निर्दिष्ट किए बिना दी गई है: hacker10 ALL= (root) less तो आप PATH वेरिएबल को बदलकर इसका शोषण कर सकते हैं
यह तकनीक उपयोग की जा सकती है अगर एक suid बाइनरी पथ को निर्दिष्ट किए बिना एक और कमांड को निष्पादित करती है (हमेशा strings के साथ जांचें एक अजीब SUID बाइनरी की सामग्री)।
SUID बाइनरी के साथ कमांड पथ
अगर suid बाइनरी पथ को निर्दिष्ट करते हुए एक और कमांड को निष्पादित करती है, तो आपको कोशिश करनी चाहिए एक फ़ंक्शन निर्मित करने की जिसे उस कमांड के रूप में नामित किया गया है जिसे suid फ़ाइल बुलाती है।
उदाहरण के लिए, अगर एक suid बाइनरी /usr/sbin/service apache2 start को बुलाती है तो आपको उस फ़ंक्शन को बनाने और निर्यात करने की कोशिश करनी चाहिए:
LD_PRELOAD & LD_LIBRARY_PATH
LD_PRELOAD पर्यावरण चर एक या अधिक साझा पुस्तकालयें (.so फ़ाइलें) निर्दिष्ट करने के लिए उपयोग किया जाता है जो लोडर द्वारा सभी अन्य, स्टैंडर्ड सी पुस्तकालय (libc.so
) सहित, से पहले लोड की जाएं। इस प्रक्रिया को एक पुस्तकालय को पूर्व-लोड करना कहा जाता है।
हालांकि, सिस्टम सुरक्षा बनाए रखने और इस सुविधा का शोषण न होने देने के लिए, विशेष रूप से suid/sgid कार्यक्रमों के साथ, सिस्टम निश्चित शर्तों का पालन करता है:
लोडर LD_PRELOAD को उन कार्यक्रमों के लिए नजरअंदाज करता है जहां वास्तविक उपयोगकर्ता आईडी (ruid) मेल नहीं खाती है इफेक्टिव उपयोगकर्ता आईडी (euid) से।
suid/sgid वाले कार्यक्रमों के लिए, केवल मानक पथों में पुस्तकालयें पूर्व-लोड की जाती हैं जो सुईड/एसजीआईडी भी हैं।
यदि आपके पास sudo
के साथ कमांड निष्पादित करने की क्षमता है और sudo -l
का आउटपुट वाक्य env_keep+=LD_PRELOAD शामिल है, तो विशेषाधिकार उन्नति हो सकती है। यह विन्यास LD_PRELOAD पर्यावरण चर को स्थायी रूप से बनाए रखने और उच्च विशेषाधिकारों के साथ अनिवार्य रूप से पहचाना जाने की अनुमति देता है, जो संभावित रूप से उच्च विशेषाधिकारों के साथ अर्बिट्रे कोड का निष्पादन करने में ले जा सकता है।
सहेजें जैसे /tmp/pe.c
फिर इसे कंपाइल करें इस्तेमाल करके:
अंत में, विशेषाधिकारों को बढ़ाएं चल रहा है
एक समान privesc का दुरुपयोग किया जा सकता है अगर हमलावार LD_LIBRARY_PATH env variable को नियंत्रित करता है क्योंकि उसके पास वह पथ नियंत्रित करता है जहां पुस्तकालयों की खोज की जाएगी।
SUID बाइनरी - .so इंजेक्शन
जब एक बाइनरी के साथ SUID अनुमतियाँ होती हैं जो असामान्य लगती है, तो यह अच्छी प्रथा है कि यह सत्यापित किया जाए कि क्या यह .so फ़ाइलें सही ढंग से लोड कर रहा है। इसे निम्नलिखित कमांड चलाकर जांचा जा सकता है:
उदाहरण के रूप में, त्रुटि का सामना करना जैसे "open(“/path/to/.config/libcalc.so”, O_RDONLY) = -1 ENOENT (कोई ऐसा फ़ाइल या निर्देशिका नहीं है)" एक शोषण की संभावना सुझाता है।
इसे शोषित करने के लिए, कोई एक सी फ़ाइल बनाने के लिए आगे बढ़ेंगे, मान लीजिए "/path/to/.config/libcalc.c", जिसमें निम्नलिखित कोड होगा:
यह कोड, एक बार कंपाइल और निष्पादित किया जाने पर, फ़ाइल अनुमतियों को मानिपुरित करके और उच्च विशेषाधिकारों के साथ एक शैल निष्पादित करने का उद्देश्य रखता है।
उपरोक्त सी फ़ाइल को एक साझा ऑब्जेक्ट (.so) फ़ाइल में कंपाइल करें:
साझा ऑब्जेक्ट हाइजैकिंग
अब जब हमें एक SUID बाइनरी मिल गया है जो एक लाइब्रेरी लोड कर रहा है जो एक फ़ोल्डर से है जहाँ हम लिख सकते हैं, तो उस फ़ोल्डर में आवश्यक नाम की लाइब्रेरी बनाएं:
यदि आपको निम्नलिखित त्रुटि मिलती है:
इसका मतलब है कि जिस पुस्तकालय को आपने उत्पन्न किया है, उसमें a_function_name
नामक फ़ंक्शन होना चाहिए।
GTFOBins
GTFOBins एक चयनित सूची है जिसमें Unix बाइनरीज़ को संग्रहित किया गया है जिनका उपयोग एक हमलावर द्वारा स्थानीय सुरक्षा प्रतिबंधों को दौर करने के लिए किया जा सकता है। GTFOArgs एक समान सूची है लेकिन उसके लिए मामले जहां आप केवल तर्क इंजेक्शन कर सकते हैं।
यह परियोजना Unix बाइनरीज़ के वैध फ़ंक्शनों को संग्रहित करती है जो प्रतिबंधित शैलियों से बाहर निकलने, उच्च वर्चस्व को बढ़ाने या बनाए रखने, फ़ाइलें स्थानांतरित करने, बाइंड और रिवर्स शैलियों को उत्पन्न करने, और अन्य पोस्ट-एक्सप्लोइटेशन कार्यों को सुविधाजनक बनाने के लिए दुरुपयोग किए जा सकते हैं।
gdb -nx -ex '!sh' -ex quit sudo mysql -e '! /bin/sh' strace -o /dev/null /bin/sh sudo awk 'BEGIN {system("/bin/sh")}'
FallOfSudo
यदि आप sudo -l
तक पहुंच सकते हैं तो आप टूल FallOfSudo का उपयोग कर सकते हैं ताकि यह जांच सके कि कोई सुडो नियम कैसे शातिरता कर सकता है।
Sudo टोकन का पुनः उपयोग
उन मामलों में जहां आपके पास sudo एक्सेस है लेकिन पासवर्ड नहीं है, आप sudo कमांड के निष्पादन का इंतजार करके और फिर सत्र टोकन को हाइजैक करके वर्चस्व को बढ़ा सकते हैं।
वर्चस्व बढ़ाने के लिए आवश्यकताएँ:
आपके पास पहले से ही उपयोगकर्ता "नमूनाउपयोगकर्ता" के रूप में एक शैली है
"नमूनाउपयोगकर्ता" ने
sudo
का उपयोग करके कुछ करने के लिए पिछले 15 मिनटों में कुछ किया है (डिफ़ॉल्ट रूप से यह समय है जो हमें किसी पासवर्ड को दर्ज किए बिनाsudo
का उपयोग करने की अनुमति देता है)cat /proc/sys/kernel/yama/ptrace_scope
0 हैgdb
एक्सेस करने योग्य है (आप इसे अपलोड कर सकते हैं)
(आप अस्थायी रूप से ptrace_scope
को echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope
के साथ सक्षम कर सकते हैं या स्थायी रूप से /etc/sysctl.d/10-ptrace.conf
को संशोधित करके kernel.yama.ptrace_scope = 0
सेट करके)
यदि सभी योग्यताएँ पूरी होती हैं, आप इसका उपयोग करके वर्चस्व बढ़ा सकते हैं: https://github.com/nongiach/sudo_inject
पहला उत्पीड़न (
exploit.sh
) /tmp/ मेंactivate_sudo_token
नामक बाइनरी बनाएगा। आप इसका उपयोग करके अपने सत्र में सुडो टोकन को सक्रिय कर सकते हैं (आपको स्वचालित रूप से रूट शैली नहीं मिलेगी,sudo su
करें):
दूसरा उत्पीड़न (
exploit_v2.sh
) /tmp में एक sh शैल बनाएगा जिसका मालिक रूट होगा और सेटयूआइड होगा
तीसरा उत्पीड़न (
exploit_v3.sh
) एक सुडोअर्स फ़ाइल बनाएगा जो सुडो टोकन को शाश्वत बनाएगा और सभी उपयोगकर्ताओं को सुडो का उपयोग करने देगा
/var/run/sudo/ts/<उपयोगकर्ता>
यदि आपको इस फ़ोल्डर में या फ़ोल्डर में बनाए गए किसी भी फ़ाइल में लेखन अनुमति है, तो आप write_sudo_token नामक बाइनरी का उपयोग करके उपयोगकर्ता और PID के लिए एक सुडो टोकन बना सकते हैं। उदाहरण के लिए, यदि आप /var/run/sudo/ts/sampleuser फ़ाइल को अधिलेखित कर सकते हैं और आपके पास उस उपयोगकर्ता के रूप में PID 1234 के साथ एक शैल है, तो आप पासवर्ड जानने की आवश्यकता के बिना सुडो विशेषाधिकार प्राप्त कर सकते हैं:
/etc/sudoers, /etc/sudoers.d
फ़ाइल /etc/sudoers
और फ़ोल्डर /etc/sudoers.d
के अंदर के फ़ाइलें sudo
कौन और कैसे उपयोग कर सकता है यह कॉन्फ़िगर करती है। इन फ़ाइलों डिफ़ॉल्ट रूप से केवल उपयोगकर्ता रूट और समूह रूट द्वारा पढ़ी जा सकती हैं।
अगर आप इस फ़ाइल को पढ़ सकते हैं तो आप कुछ दिलचस्प जानकारी प्राप्त कर सकते हैं, और अगर आप किसी भी फ़ाइल को लिख सकते हैं तो आप विशेषाधिकारों को उन्नत कर सकते हैं।
यदि आप लिख सकते हैं तो आप इस अनुमति का दुरुपयोग कर सकते हैं।
इन अनुमतियों का दुरुपयोग करने का एक और तरीका:
DOAS
कुछ विकल्प sudo
बाइनरी के लिए doas
जैसे OpenBSD के लिए हैं, /etc/doas.conf
पर इसकी विन्यास की जाँच करना न भूलें।
सुडो हाइजैकिंग
यदि आपको पता है कि एक उपयोगकर्ता सामान्यत: एक मशीन से कनेक्ट करता है और sudo
का उपयोग करके विशेषाधिकारों को बढ़ाता है और आपके पास उस उपयोगकर्ता संदर्भ में एक शेल है, तो आप एक नया सुडो एक्जीक्यूटेबल बना सकते हैं जो आपके कोड को रूट के रूप में और फिर उपयोगकर्ता का कमांड एक्जीक्यूट करेगा। फिर, उपयोगकर्ता संदर्भ का $PATH संशोधित करें (उदाहरण के लिए .bash_profile में नया पथ जोड़ना) ताकि जब उपयोगकर्ता सुडो का उपयोग करता है, तो आपका सुडो एक्जीक्यूटेबल एक्जीक्यूट होता है।
ध्यान दें कि यदि उपयोगकर्ता एक विभिन्न शैली का उपयोग करता है (बैश नहीं) तो आपको नए पथ जोड़ने के लिए अन्य फ़ाइलों को संशोधित करने की आवश्यकता होगी। उदाहरण के लिए sudo-piggyback ~/.bashrc
, ~/.zshrc
, ~/.bash_profile
को संशोधित करता है। आप bashdoor.py में एक और उदाहरण पा सकते हैं।
या कुछ इस प्रकार का कुछ चला सकते हैं:
साझा पुस्तकालय
ld.so
फ़ाइल /etc/ld.so.conf
दर्शाती है कि लोड की गई कॉन्फ़िगरेशन फ़ाइलें कहाँ से हैं। सामान्यत: यह फ़ाइल निम्नलिखित पथ को शामिल करती है: include /etc/ld.so.conf.d/*.conf
इसका मतलब है कि /etc/ld.so.conf.d/*.conf
से कॉन्फ़िगरेशन फ़ाइलें पढ़ी जाएंगी। यह कॉन्फ़िगरेशन फ़ाइलें अन्य फ़ोल्डर्स की ओर लाइब्रेरी खोजने के लिए पॉइंट करती हैं। उदाहरण के लिए, /etc/ld.so.conf.d/libc.conf
का विषय /usr/local/lib
है। इसका मतलब है कि सिस्टम /usr/local/lib
के अंदर लाइब्रेरीज़ की खोज करेगा।
यदि किसी कारणवश किसी उपयोगकर्ता के पास लिखने की अनुमति है किसी भी निर्दिष्ट पथ पर: /etc/ld.so.conf
, /etc/ld.so.conf.d/
, /etc/ld.so.conf.d/
के किसी भी फ़ाइल या /etc/ld.so.conf.d/*.conf
के भीतर किसी भी फ़ोल्डर पर, तो उसे वर्चस्व को उन्नत करने की क्षमता हो सकती है।
निम्नलिखित पृष्ठ पर इस गलत कॉन्फ़िगरेशन का शोध कैसे करें इसे देखें:
RPATH
कॉपी करके लिब को /var/tmp/flag15/
में डालने से यह प्रोग्राम इस स्थान पर RPATH
वेरिएबल में निर्दिष्ट किए गए रूप में उपयोग किया जाएगा।
तो /var/tmp
में gcc -fPIC -shared -static-libgcc -Wl,--version-script=version,-Bstatic exploit.c -o libc.so.6
के साथ एक दुष्ट पुस्तकालय बनाएं।
क्षमताएँ
Linux capabilities एक प्रक्रिया को उपलब्ध रूट विशेषाधिकारों का एक सबसेट प्रदान करते हैं। यह वास्तव में रूट विशेषाधिकारों को छोटे और विशिष्ट इकाइयों में विभाजित कर देता है। इन इकाइयों में से प्रत्येक को प्रक्रियाओं को स्वतंत्र रूप से प्रदान किया जा सकता है। इस तरह प्रिविलेजेज का पूरा सेट कम हो जाता है, जिससे शोषण के जोखिम कम होते हैं। Capabilities के बारे में और अधिक जानने के लिए निम्नलिखित पृष्ठ को पढ़ें और उन्हें कैसे दुरुपयोग किया जा सकता है:
Linux Capabilitiesनिर्देशिका अनुमतियाँ
एक निर्देशिका में, "क्रियान्वयन" के लिए बिट इसका सूचित करता है कि प्रभावित उपयोगकर्ता "cd" फ़ोल्डर में जा सकता है। "पढ़ना" बिट इसका सूचित करता है कि उपयोगकर्ता फ़ाइलें सूचीबद्ध कर सकता है, और "लिखना" बिट इसका सूचित करता है कि उपयोगकर्ता नई फ़ाइलें बना सकता है और हटा सकता है।
ACLs
पहुंच नियंत्रण सूची (ACLs) विभाजनीय अनुमतियों का द्वितीय स्तर प्रस्तुत करती है, जो पारंपरिक ugo/rwx अनुमतियों को नष्ट करने की क्षमता रखती है। ये अनुमतियाँ फ़ाइल या निर्देशिका पहुंच पर अधिक नियंत्रण प्रदान करती हैं जिसके द्वारा विशेष उपयोगकर्ताओं को अनुमति देने या नकारने की अधिकार होती है। यह स्तर की विस्तारणता सुनिश्चित करती है कि अधिक सटीक पहुंच प्रबंधन हो। अधिक विवरण यहाँ मिल सकता है।
"kali" उपयोगकर्ता को एक फ़ाइल पर पढ़ने और लिखने की अनुमति दें:
सिस्टम से विशिष्ट ACLs वाले फ़ाइलें प्राप्त करें:
खुली शैल सत्र
पुराने संस्करणों में आप किसी अलग उपयोगकर्ता (रूट) के कुछ शैल सत्र को हाइजैक कर सकते हैं। नवीनतम संस्करणों में आप केवल अपने उपयोगकर्ता के स्क्रीन सत्र से कनेक्ट कर सकेंगे। हालांकि, आप सत्र के अंदर रोचक जानकारी पा सकते हैं।
स्क्रीन सत्र हाइजैकिंग
स्क्रीन सत्रों की सूची
एक सत्र से जुड़ें
tmux सत्र हाइजैकिंग
यह पुराने tmux संस्करणों की समस्या थी। मैं एक गैर-विशेषाधिकारी उपयोगकर्ता के रूप में रूट द्वारा बनाई गई एक tmux (v2.1) सत्र को हाइजैक नहीं कर सका।
tmux सत्रों की सूची
एक सत्र में जुड़ें
एचटीबी से वैलेंटाइन बॉक्स की जाँच के लिए एक उदाहरण।
SSH
Debian OpenSSL Predictable PRNG - CVE-2008-0166
सभी SSL और SSH कुंजी जो देवीयन आधारित सिस्टमों (उबंटू, कुबंटू, आदि) पर सितंबर 2006 से 13 मई, 2008 के बीच उत्पन्न की गई हों, इस बग से प्रभावित हो सकती हैं। यह बग उस समय उत्पन्न होता है जब उन ओएस में एक नई SSH कुंजी बनाई जाती है, क्योंकि केवल 32,768 वेरिएशन संभव थे। इसका मतलब है कि सभी संभावनाएँ गणना की जा सकती हैं और जब आपके पास SSH सार्वजनिक कुंजी होती है तो आप उसके संबंधित निजी कुंजी की खोज कर सकते हैं। आप यहाँ गणित संभावनाएँ देख सकते हैं: https://github.com/g0tmi1k/debian-ssh
SSH दिलचस्प विन्यास मान
PasswordAuthentication: पासवर्ड प्रमाणीकरण की अनुमति है या नहीं यह निर्धारित करता है। डिफ़ॉल्ट है
no
।PubkeyAuthentication: सार्वजनिक कुंजी प्रमाणीकरण की अनुमति है या नहीं यह निर्धारित करता है। डिफ़ॉल्ट है
yes
।PermitEmptyPasswords: जब पासवर्ड प्रमाणीकरण की अनुमति है, तो यह निर्धारित करता है कि सर्वर खातों में खाली पासवर्ड स्ट्रिंग के साथ लॉगिन की अनुमति है या नहीं। डिफ़ॉल्ट है
no
।
PermitRootLogin
यह निर्धारित करता है कि क्या रूट SSH का उपयोग करके लॉग इन कर सकता है, डिफ़ॉल्ट है no
। संभावित मान:
yes
: रूट पासवर्ड और निजी कुंजी का उपयोग करके लॉग इन कर सकता हैwithout-password
याprohibit-password
: रूट केवल निजी कुंजी के साथ ही लॉग इन कर सकता हैforced-commands-only
: रूट केवल निजी कुंजी का उपयोग करके और यदि कमांड विकल्प निर्धारित किए गए हैं तो ही लॉग इन कर सकता हैno
: नहीं
AuthorizedKeysFile
उन पब्लिक कुंजियों को उपयोग के लिए जो उपयोगकर्ता प्रमाणीकरण के लिए उपयोग किया जा सकता है, उन फ़ाइलों को निर्धारित करता है। यह %h
जैसे टोकन्स शामिल कर सकता है, जो घर के निर्देशिका द्वारा प्रतिस्थापित किया जाएगा। आप सटीक पथों की सूचना दे सकते हैं (जो /
से प्रारंभ होती हैं) या उपयोगकर्ता के घर से संबंधित पथ। उदाहरण के लिए:
वह कॉन्फ़िगरेशन इसका संकेत देगा कि अगर आप "testusername" उपयोगकर्ता की निजी कुंजी के साथ लॉगिन करने का प्रयास करते हैं तो ssh आपकी कुंजी की सार्वजनिक कुंजी को /home/testusername/.ssh/authorized_keys
और /home/testusername/access
में स्थित कुंजियों के साथ तुलना करेगा
ForwardAgent/AllowAgentForwarding
SSH एजेंट फॉरवर्डिंग आपको अपनी स्थानीय SSH कुंजियों का उपयोग करने की अनुमति देता है बिना कुंजी (पासफ्रेज़ के बिना!) अपने सर्वर पर बैठने देने के बजाय। इसलिए, आप ssh के माध्यम से एक होस्ट पर जंप करने के लिए और वहां से अन्य होस्ट पर जंप करने के लिए अपनी प्रारंभिक होस्ट में स्थित कुंजी का उपयोग कर सकेंगे।
आपको इस विकल्प को $HOME/.ssh.config
में इस प्रकार सेट करने की आवश्यकता है:
ध्यान दें कि यदि Host
*
है तो हर बार जब उपयोगकर्ता एक विभिन्न मशीन पर जाता है, तो उस होस्ट को कुंजियों तक पहुंचने की अनुमति होगी (जो एक सुरक्षा समस्या है)।
फ़ाइल /etc/ssh_config
इस विकल्प को रद्द कर सकती है और इस विन्यास को अनुमति देने या नकारने की अनुमति दे सकती है।
फ़ाइल /etc/sshd_config
ssh-agent forwarding को AllowAgentForwarding
शब्द के साथ अनुमति या नकार सकती है (डिफ़ॉल्ट अनुमति है)।
यदि आपको लगता है कि Forward Agent को कॉन्फ़िगर किया गया है तो निम्नलिखित पृष्ठ को पढ़ें क्योंकि आप इसका दुरुपयोग करके विशेषाधिकारों को बढ़ा सकते हैं:
SSH Forward Agent exploitationदिलचस्प फ़ाइलें
प्रोफ़ाइल फ़ाइलें
फ़ाइल /etc/profile
और /etc/profile.d/
के तहत की फ़ाइलें स्क्रिप्ट हैं जो एक उपयोगकर्ता नए शैली चलाता है जब वह एक नई शैली चलाता है। इसलिए, यदि आप किसी भी एक को लिखने या संशोधित कर सकते हैं तो आप विशेषाधिकारों को बढ़ा सकते हैं।
पासवर्ड/शैडो फ़ाइलें
आपको किसी भी अजीब प्रोफ़ाइल स्क्रिप्ट को खोजने पर उसे संवेदनशील विवरणों के लिए जांचना चाहिए।
ऑपरेटिंग सिस्टम के आधार पर /etc/passwd
और /etc/shadow
फ़ाइलें एक अलग नाम का उपयोग कर सकती हैं या एक बैकअप हो सकता है। इसलिए सुझाव दिया जाता है कि आप सभी उन्हें खोजें और देखें कि क्या आप उन्हें पढ़ सकते हैं ताकि आप देख सकें कि क्या फ़ाइलों में हैश हैं:
कभी-कभी आप /etc/passwd
(या समकक्ष) फ़ाइल में पासवर्ड हैश पा सकते हैं।
लिखने योग्य /etc/passwd
पहले, निम्नलिखित कमांड्स में से किसी एक के साथ एक पासवर्ड उत्पन्न करें।
तो उपयोगकर्ता हैकर
जोड़ें और उसका उत्पन्न किया गया पासवर्ड जोड़ें।
उदा: हैकर: $1 $हैकर $TzyKlv0/R/c28R.GAeLw.1:0:0:हैकर:/root:/bin/bash
अब आप su
कमांड का उपयोग हैकर:हैकर
के साथ कर सकते हैं
वैकल्पिक रूप से, आप निम्नलिखित पंक्तियों का उपयोग करके एक डमी उपयोगकर्ता जोड़ सकते हैं बिना पासवर्ड के। चेतावनी: आप मशीन की वर्तमान सुरक्षा को कम कर सकते हैं।
ध्यान दें: BSD प्लेटफॉर्मों में /etc/passwd
को /etc/pwd.db
और /etc/master.passwd
में स्थानित किया जाता है, और /etc/shadow
को /etc/spwd.db
में नामांकित किया जाता है।
आपको यह जांचनी चाहिए कि क्या आप कुछ संवेदनशील फ़ाइलों में लिख सकते हैं। उदाहरण के लिए, क्या आप किसी सेवा कॉन्फ़िगरेशन फ़ाइल में लिख सकते हैं?
उदाहरण के लिए, यदि मशीन tomcat सर्वर चल रहा है और आप /etc/systemd/ के अंदर Tomcat सेवा कॉन्फ़िगरेशन फ़ाइल को संशोधित कर सकते हैं, तो आप लाइनों को संशोधित कर सकते हैं:
फोल्डर जाँचें
निम्नलिखित फोल्डर बैकअप या दिलचस्प जानकारी रख सकते हैं: /tmp, /var/tmp, /var/backups, /var/mail, /var/spool/mail, /etc/exports, /root (शायद आप आखिरी वाला नहीं पढ़ पाएंगे लेकिन कोशिश करें)
अजीब स्थान/स्वामित्व वाली फ़ाइलें
पिछले मिनटों में संशोधित फ़ाइलें
Sqlite डीबी फ़ाइलें
*_इतिहास, .sudo_as_admin_सफल, प्रोफ़ाइल, bashrc, httpd.conf, .plan, .htpasswd, .git-credentials, .rhosts, hosts.equiv, Dockerfile, docker-compose.yml फ़ाइलें
छिपे हुए फ़ाइलें
पथ में स्क्रिप्ट/बाइनरी
वेब फ़ाइलें
बैकअप
ज्ञात फ़ाइलें जिनमें पासवर्ड हो सकता है
linPEAS कोड को पढ़ें, यह कई संभावित फ़ाइलें खोजता है जिनमें पासवर्ड हो सकता है। एक और दिलचस्प उपकरण जिसका उपयोग किया जा सकता है वह है: LaZagne जो एक ओपन सोर्स एप्लिकेशन है जिसका उपयोग विंडोज, लिनक्स और मैक पर स्थानीय कंप्यूटर पर स्टोर किए गए कई पासवर्ड प्राप्त करने के लिए किया जाता है।
लॉग
यदि आप लॉग पढ़ सकते हैं, तो आपको उनमें दिलचस्प/गोपनीय जानकारी मिल सकती है। जितना अजीब लॉग होगा, उतना ही दिलचस्प होगा (संभावना है)। इसके अलावा, कुछ "बुरा" कॉन्फ़िगर किए गए (बैकडोर?) ऑडिट लॉग आपको यह संभावना देते हैं कि आप ऑडिट लॉग में पासवर्ड रिकॉर्ड कर सकते हैं जैसा कि इस पोस्ट में स्पष्ट किया गया है: https://www.redsiege.com/blog/2019/05/logging-passwords-on-linux/.
जानकारी प्राप्त करने के लिए ग्रुप लॉग्स पढ़ें adm वास्तव में मददगार होगा।
शैल फ़ाइलें
जेनेरिक क्रेडेंशियल खोज/रीजेक्स
आपको फ़ाइलें भी चेक करनी चाहिए जिसमें शब्द "पासवर्ड" होता है उसके नाम में या सामग्री के अंदर, और लॉग्स में IPs और ईमेल्स की भी जांच करें, या हैश रीजेक्स में। मैं यहाँ सभी इसे कैसे करना है इसकी सूची नहीं देने जा रहा हूँ लेकिन अगर आप इसमें रुचि रखते हैं तो आप उस आखिरी जांच की जांच कर सकते हैं जो linpeas करता है।
लिखने योग्य फ़ाइलें
पायथन पुस्तकालय हाइजैकिंग
अगर आपको पता है कि किस स्थान से एक पायथन स्क्रिप्ट को निष्पादित किया जा रहा है और आप उस फ़ोल्डर में लिख सकते हैं या आप पायथन पुस्तकालयों को संशोधित कर सकते हैं, तो आप ऑएस पुस्तकालय को संशोधित कर सकते हैं और उसे बैकडोर कर सकते हैं (अगर आप जहाँ पायथन स्क्रिप्ट निष्पादित होने जा रहा है वहाँ लिख सकते हैं, तो ऑएस.पाय लाइब्रेरी की कॉपी और पेस्ट करें)।
पुस्तकालय को बैकडोर करने के लिए बस ऑएस पुस्तकालय के अंत में निम्नलिखित पंक्ति जोड़ें (आईपी और पोर्ट बदलें):
लॉगरोट शोषण
लॉगरोट
में एक कमजोरी उन उपयोगकर्ताओं को लेने की अनुमति देती है जिनके पास एक लॉग फ़ाइल या उसके माता-पिता निर्देशिकाओं पर लेखन अनुमतियाँ हो सकती हैं। यह इसलिए है क्योंकि लॉगरोट
, अक्सर रूट के रूप में चलता है, किसी भी फ़ाइल को अर्बिट्रेरी रूप से निष्पादित करने के लिए मानिया जा सकता है, विशेष रूप से निर्देशिकाओं में जैसे /etc/bash_completion.d/। /var/log के न केवल अनुमतियों की जाँच करना महत्वपूर्ण है बल्कि किसी भी निर्देशिका में भी जहाँ लॉग घूर्णन किया जाता है।
यह कमजोरी लॉगरोट
संस्करण 3.18.0
और पुराने पर प्रभावित करती है
इस कमजोरी के बारे में अधिक विस्तृत जानकारी इस पृष्ठ पर मिल सकती है: https://tech.feedyourhead.at/content/details-of-a-logrotate-race-condition.
आप इस कमजोरी का शोषण कर सकते हैं logrotten.
यह कमजोरी CVE-2016-1247 (nginx logs) के लिए बहुत समान है, इसलिए जब भी आपको लगे कि आप लॉग को बदल सकते हैं, तो देखें कि वह लॉग कौन संभाल रहा है और यह जांचें कि क्या आप लॉग को सिमलिंक्स द्वारा अधिकार उन्नत कर सकते हैं।
/etc/sysconfig/network-scripts/ (सेंटोस/रेडहैट)
कमजोरी संदर्भ: https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure&qid=e026a0c5f83df4fd532442e1324ffa4f
यदि, किसी कारणवश, एक उपयोगकर्ता किसी ifcf-<whatever>
स्क्रिप्ट को /etc/sysconfig/network-scripts में लिखने के लिए सक्षम है या वह एक मौजूदा को समायोजित कर सकता है, तो तो आपका सिस्टम पून्ड हो जाता है।
नेटवर्क स्क्रिप्ट, ifcg-eth0 उदाहरण के लिए नेटवर्क कनेक्शन के लिए उपयोग किए जाते हैं। वे .INI फ़ाइलों के रूप में दिखते हैं। हालांकि, वे लिनक्स पर नेटवर्क प्रबंधक (डिस्पैचर.d) द्वारा ~सोर्स~ किए जाते हैं।
मेरे मामले में, इन नेटवर्क स्क्रिप्ट में NAME=
विशेषता को सही ढंग से संभाला नहीं गया है। यदि आपके पास नाम में सफेद/खाली जगह है तो सिस्टम को खाली जगह के बाद का हिस्सा निष्पादित करने की कोशिश करता है। इसका मतलब है कि पहले खाली जगह के बाद का हर कुछ रूट के रूप में निष्पादित किया जाता है।
उदाहरण के लिए: /etc/sysconfig/network-scripts/ifcfg-1337
आरंभ, आरंभ.डी, सिस्टमडी, और आरसी.डी
डायरेक्टरी /etc/init.d
सिस्टम वी आरंभ (SysVinit), क्लासिक लिनक्स सेवा प्रबंधन सिस्टम के लिए स्क्रिप्ट का घर है। इसमें सेवाओं को शुरू
, रोकें
, पुनः आरंभ
और कभी-कभी रीलोड
करने के लिए स्क्रिप्ट शामिल हैं। ये सीधे या /etc/rc?.d/
में पाए गए प्रतीकात्मक लिंक के माध्यम से क्रियान्वित किए जा सकते हैं। रेडहैट सिस्टम में एक वैकल्पिक पथ /etc/rc.d/init.d
है।
वहीं, /etc/init
अपस्टार्ट के साथ जुड़ा है, जो उबुंटू द्वारा पेश किए गए एक नए सेवा प्रबंधन है, सेवा प्रबंधन कार्यों के लिए कॉन्फ़िगरेशन फ़ाइलों का उपयोग करता है। अपस्टार्ट की ओर स्थानांतरण के बावजूद, उपस्थिति में एक संगतता परत के कारण अपस्टार्ट के साथ सिसवीनिट स्क्रिप्ट भी उपयोग किए जाते हैं।
सिस्टमडी एक आधुनिक प्रारंभीकरण और सेवा प्रबंधक के रूप में सामने आता है, जो आवश्यकतानुसार डेमन शुरू करने, ऑटोमाउंट प्रबंधन, और सिस्टम स्थिति स्नैपशॉट जैसी उन्नत सुविधाएं प्रदान करता है। यह वितरण पैकेजों के लिए /usr/lib/systemd/
में फ़ाइलों को संगठित करता है और प्रशासक संशोधनों के लिए /etc/systemd/system/
में, सिस्टम प्रशासन प्रक्रिया को सुगम बनाता है।
Last updated