assetnote/blind-ssrf-chainsअपनी Blind SSRF भेद्यता को चेन करने के सभी संभावित तरीकों की एक विस्तृत सूची
सर्वर साइड रिक्वेस्ट फॉरजेरी तब होती है जब आप किसी सर्वर को आपकी ओर से मनमाने अनुरोध करने के लिए मजबूर कर सकते हैं। चूँकि अनुरोध सर्वर द्वारा किए जा रहे होते हैं, इसलिए नेटवर्क में सर्वर की स्थिति के कारण आंतरिक संसाधनों तक पहुँच संभव हो सकती है। क्लाउड वातावरण में, मेटाडेटा एंडपॉइंट्स की उपस्थिति के कारण SSRF अधिक महत्वपूर्ण जोखिम पैदा करता है, जिनमें संवेदनशील क्रेडेंशियल या रहस्य हो सकते हैं।
सर्वर साइड रिक्वेस्ट फॉरजेरी का शोषण करते समय, हम अक्सर खुद को ऐसी स्थिति में पा सकते हैं जहाँ प्रतिक्रिया को पढ़ा नहीं जा सकता। उद्योग में, इस व्यवहार को अक्सर "ब्लाइंड SSRF" कहा जाता है। ऐसी स्थितियों में, हम प्रभाव कैसे साबित करें? यह एक दिलचस्प चर्चा थी जिसे जस्टिन गार्डनर ने ट्विटर पर छेड़ा था:
I've been finding a large amount of Blind SSRFs recently. What kind of one-shot RCE's have you guys used as pivots for these in the past? I've got access to some Kafka and a bunch of other things. @nnwakelam @thedawgyg
— Justin Gardner (@Rhynorater) January 13, 2021
यदि आप आंतरिक संसाधनों तक पहुँच सकते हैं, तो प्रभाव साबित करने के लिए कई संभावित शोषण श्रृंखलाएँ (exploit chains) निष्पादित की जा सकती हैं। यह ब्लॉग पोस्ट ब्लाइंड SSRF का लाभ उठाते समय प्रत्येक ज्ञात शोषण श्रृंखला के विवरण में जाने का प्रयास करती है, और जैसे-जैसे अधिक तकनीकें खोजी और साझा की जाती हैं, इसे अद्यतन किया जाएगा।
यदि हम कोई तकनीक चूक गए हैं, तो कृपया हमें एक ट्वीट या DM भेजें: @assetnote और हम इसे इस ब्लॉग में जोड़ देंगे।
I tend to call them SSRF canaries, when chaining a blind SSRF to another SSRF internally which makes an additional call externally, or by an app-specific open redir or blind XXE. Confluence, Artifactory, Jenkins and JAMF have some that works well.
— Frans Rosén (@fransrosen) January 13, 2021
यह सत्यापित करने के लिए कि आप आंतरिक सेवाओं या अनुप्रयोगों के साथ इंटरैक्ट कर सकते हैं, आप "SSRF कैनरीज़" का उपयोग कर सकते हैं।
यह तब होता है जब हम किसी आंतरिक URL का अनुरोध कर सकते हैं जो एक और SSRF करता है और आपके कैनरी होस्ट को कॉल करता है। यदि आपको अपने कैनरी होस्ट पर एक अनुरोध प्राप्त होता है, तो इसका मतलब है कि आपने सफलतापूर्वक एक आंतरिक सेवा को हिट किया है जो बाहरी अनुरोध करने में भी सक्षम है।
यह सत्यापित करने का एक प्रभावी तरीका है कि एक SSRF भेद्यता की आंतरिक नेटवर्क या अनुप्रयोगों तक पहुँच है, और यह भी सत्यापित करने के लिए कि आंतरिक नेटवर्क पर कुछ सॉफ़्टवेयर मौजूद हैं। आप SSRF कैनरी का उपयोग करके आंतरिक नेटवर्क के अधिक संवेदनशील भागों तक भी संभावित रूप से पहुँच प्राप्त (pivot) कर सकते हैं, यह इस बात पर निर्भर करता है कि यह कहाँ स्थित है।
लक्ष्य जितने संभव हो उतने आंतरिक होस्ट खोजना होने के साथ, DNS डेटास्रोतों का उपयोग उन सभी रिकॉर्ड्स को खोजने के लिए किया जा सकता है जो आंतरिक होस्ट की ओर इशारा करते हैं।
क्लाउड वातावरण में, हम अक्सर ELBs देखते हैं जो आंतरिक VPC के अंदर होस्ट की ओर इशारा कर रहे होते हैं। आप जिस एसेट को लक्षित कर रहे हैं वह किस VPC में है, इसके आधार पर उसी VPC के भीतर अन्य होस्ट तक पहुँच संभव हो सकती है।
उदाहरण के लिए, निम्नलिखित होस्ट DNS डेटास्रोतों से खोजा गया है:```bash livestats.target.com -> internal-es-livestats-298228113.us-west-2.elb.amazonaws.com -> 10.0.0.82
आप यह अनुमान लगा सकते हैं कि `es` Elasticsearch के लिए है, और फिर इस होस्ट पर आगे के हमले कर सकते हैं। आप इन सभी ब्लाइंड SSRF पेलोड्स को उन सभी "आंतरिक" होस्ट्स पर भी स्प्रे कर सकते हैं जिन्हें इस विधि के माध्यम से पहचाना गया है। यह अक्सर प्रभावी होता है।
अधिक आंतरिक होस्ट खोजने के लिए, मैं सुझाव देता हूँ कि आप अपना सारा DNS डेटा लें और फिर [AltDNS](https://github.com/infosec-au/altdns) जैसी किसी चीज़ का उपयोग करके क्रमपरिवर्तन उत्पन्न करें, और फिर उन्हें एक [तेज़ DNS ब्रूटफोर्सर](https://github.com/blechschmidt/massdns) से हल करें।
यह पूरा हो जाने के बाद, सभी नए खोजे गए आंतरिक होस्ट्स की पहचान करें और उन्हें अपनी ब्लाइंड SSRF श्रृंखला के भाग के रूप में उपयोग करें।
## साइड चैनल लीक
ब्लाइंड SSRF कमजोरियों का शोषण करते समय, आप लौटाई जा रही प्रतिक्रिया के बारे में कुछ जानकारी लीक कर पाने में सक्षम हो सकते हैं। उदाहरण के लिए, मान लीजिए कि आपके पास XXE के माध्यम से ब्लाइंड SSRF है, तो त्रुटि संदेश यह संकेत दे सकते हैं कि:
- एक प्रतिक्रिया लौटाई गई थी
`Error parsing request: System.Xml.XmlException: Expected DTD markup was not found. Line 1, position 1.`
बनाम
- होस्ट और पोर्ट अनुपलब्ध हैं
`Error parsing request: System.Net.WebException: Unable to connect to the remote server`
इसी तरह, XXE के अलावा, एक वेब एप्लिकेशन में भी साइड चैनल लीक हो सकता है जिसे निम्नलिखित के भीतर के अंतरों की जाँच करके पता लगाया जा सकता है:
- **प्रतिक्रिया स्थिति कोड**:
ऑनलाइन आंतरिक एसेट:पोर्ट `200 OK` के साथ प्रतिक्रिया करता है बनाम ऑफलाइन आंतरिक एसेट:पोर्ट `500 Internal Server Error`
- **प्रतिक्रिया सामग्री**:
प्रतिक्रिया का आकार बाइट्स में छोटा या बड़ा होता है, यह इस बात पर निर्भर करता है कि आप जिस URL को अनुरोध करने का प्रयास कर रहे हैं वह पहुंच योग्य है या नहीं।
- **प्रतिक्रिया समय**:
प्रतिक्रिया का समय धीमा या तेज़ होता है, यह इस बात पर निर्भर करता है कि आप जिस URL को अनुरोध करने का प्रयास कर रहे हैं वह पहुंच योग्य है या नहीं।
---------------
# तकनीकें
**HTTP(s) के माध्यम से संभव**
- [Elasticsearch](#elasticsearch)
- [Weblogic](#weblogic)
- [Hashicorp Consul](#consul)
- [Shellshock](#shellshock)
- [Apache Druid](#druid)
- [Apache Solr](#solr)
- [PeopleSoft](#peoplesoft)
- [Apache Struts](#struts)
- [JBoss](#jboss)
- [Confluence](#confluence)
- [Jira](#jira)
- [अन्य Atlassian उत्पाद](#atlassian-products)
- [OpenTSDB](#opentsdb)
- [Jenkins](#jenkins)
- [Hystrix डैशबोर्ड](#hystrix)
- [W3 Total Cache](#w3)
- [Docker](#docker)
- [Gitlab Prometheus Redis Exporter](#redisexporter)
**Gopher के माध्यम से संभव**
- [Redis](#redis)
- [Memcache](#memcache)
- [Apache Tomcat](#tomcat)
- [FastCGI](#fastcgi)
- [Java RMI](#java-rmi)
**उपकरण**
- [Gopherus](#gopherus)
- [remote-method-guesser](#remote-method-guesser)
- [SSRF Proxy](#ssrfproxy)
----------------------------------
**HTTP(s) के माध्यम से संभव**
<div id="elasticsearch"></div>
## Elasticsearch
**सामान्यतः बाउंड होने वाला पोर्ट: 9200**
जब Elasticsearch आंतरिक रूप से तैनात किया जाता है, तो इसे सामान्यतः प्रमाणीकरण की आवश्यकता नहीं होती है।
यदि आपके पास आंशिक रूप से ब्लाइंड SSRF है जहाँ आप स्थिति कोड निर्धारित कर सकते हैं, तो जाँच करें कि क्या निम्नलिखित एंडपॉइंट 200 लौटाते हैं:```http
/_cluster/health
/_cat/indices
/_cat/health
यदि आपके पास एक ब्लाइंड SSRF है जहाँ आप POST अनुरोध भेज सकते हैं, तो आप निम्न पथ पर POST अनुरोध भेजकर Elasticsearch इंस्टेंस को बंद कर सकते हैं:
नोट: _shutdown API को Elasticsearch संस्करण 2.x और उससे ऊपर के संस्करणों से हटा दिया गया है। यह केवल Elasticsearch 1.6 और उससे नीचे के संस्करणों में काम करता है:```http
/_shutdown
/_cluster/nodes/_master/_shutdown
/_cluster/nodes/_shutdown
/_cluster/nodes/_all/_shutdown
<div id="weblogic"></div>
## वेबलॉजिक
**सामान्य बाउंड पोर्ट: 80, 443 (SSL), 7001, 8888**
**SSRF कैनरी: UDDI एक्सप्लोरर (CVE-2014-4210)**```http
POST /uddiexplorer/SearchPublicRegistries.jsp HTTP/1.1
Host: target.com
Content-Length: 137
Content-Type: application/x-www-form-urlencoded