yoshida-git-ai/spacex-starlink-router-gen-2-xssCVE-2023-49965 | SpaceX / Starlink Router Gen 2 XSS
Vous pouvez voir la version coréenne de l'article ici :
https://hackintoanetwork.com/blog/2023-starlink-router-gen2-xss-kor
Une vulnérabilité de type Cross-Site Scripting (XSS) dans la page captive portal initiale du routeur de deuxième génération pourrait permettre à un attaquant de prendre le contrôle du routeur et de Dishy.
La vulnérabilité est causée par un filtrage insuffisant des valeurs d'entrée pour les paramètres ssid et password sur la page de configuration initiale du routeur (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>
Cette vulnérabilité Cross-Site Scripting (XSS) peut être exploitée conjointement avec une attaque Cross-Site Request Forgery (CSRF), comme illustré dans la preuve de concept ci-dessus.
Normalement, la page captive portal ne devrait être active que sur l'adresse interne du routeur, 192.168.1.1, mais il y avait un bug dans les anciens routeurs qui permettait à la page du portail captif d'être accessible de manière inattendue depuis l'adresse interne de Dishy, 192.168.100.1.
http://192.168.1.1/setup → La page du portail captif s'affiche correctement.
http://192.168.100.1/setup → La page du portail captif est également affichée à cette adresse.
(Normalement, l'accès à la page du portail captif ne devrait pas être possible à l'adresse interne de Dishy, 192.168.100.1.)
L'utilisation d'un tel bug avec la vulnérabilité Cross-Site Scripting (XSS) permet de contourner la Same-Origin Policy (SOP) du navigateur, permettant le contrôle à la fois du routeur et de Dishy.
On peut confirmer que la même vulnérabilité Cross-Site Scripting (XSS) se produit également à l'adresse http://192.168.100.1/setup.
Voyons maintenant comment je peux exploiter ces bugs pour prendre le contrôle du Routeur et de Dishy.
Lorsque la commande Stow est émise depuis l'interface administrateur, la requête HTTP suivante est envoyée à Dishy
(Note : La commande Stow permet de plier l'antenne Dishy pour le déplacement ou le stockage.)
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'en-tête de cette requête contient plusieurs informations importantes.
x-grpc-web: 1
Cela indique l'utilisation du protocole gRPC-Web.
(gRPC-Web est un protocole qui permet aux clients web d'effectuer des appels gRPC vers un serveur.)
content-type: application/grpc-web+proto
Cela signifie que les données transmises utilisent le protocole gRPC et sont encodées au format protobuf.
Corps de la requête
Corps de la requête Stow de Dishy (Hex)
\x00\x00\x00\x00\x03\xef\xbf\xbd\x7d\x00
Le corps de la requête contient des données au format grpc-web+proto, qui contiennent probablement les détails de la commande Stow.
En rassemblant ces informations, lorsqu'un utilisateur émet une commande Stow via l'interface d'administration, la commande est envoyée à Dishy via gRPC, ce qui plie Dishy dans un état portable.
Cependant, si vous regardez la requête, vous remarquerez qu'il n'y a pas d'authentification pour l'utilisateur qui l'envoie.
Cela signifie que quelqu'un d'autre qu'un administrateur pourrait envoyer la même requête et prendre le contrôle de Dishy sans autorisation. Mais cette vulnérabilité nécessite que l'attaquant ait un accès physique au réseau local, ce qui limite la portée de l'attaque par rapport aux attaques pouvant survenir à distance.
Si c'est le cas, vous pourriez penser que vous pouvez tenter une attaque Cross-Site Request Forgery (CSRF) avec une charge utile qui envoie la même requête.
Bien que ce soit un scénario possible, la Same-Origin Policy (SOP) du navigateur limite cette attaque.
gRPC nécessite un en-tête content-type spécifique appelé application/grpc-web+proto.
Cependant, la Same-Origin Policy (SOP) fait que les navigateurs suppriment cet en-tête lors de l'envoi de requêtes depuis d'autres sources.
Cela rend impossible l'envoi de requêtes gRPC à Dishy depuis l'extérieur dans des circonstances normales.
Normalement, une Same-Origin Policy (SOP) empêche les navigateurs web d'effectuer des requêtes depuis différentes sources.
Cependant, avec une vulnérabilité Cross-Site Scripting (XSS), un attaquant peut exécuter un script dans le navigateur web de la victime.
Les scripts injectés par un attaquant utilisant une vulnérabilité Cross-Site Scripting (XSS) sont considérés comme ayant été exécutés depuis la même source (c'est-à-dire le site web sur lequel la victime se trouve actuellement).
Pour cette raison, la Same-Origin Policy (SOP) reconnaît les requêtes générées par ces scripts comme provenant de la même source, et donc les restrictions de la Same-Origin Policy (SOP) ne s'appliquent pas dans ce cas.
Par conséquent, dans une attaque Cross-Site Request Forgery (CSRF) utilisant une vulnérabilité Cross-Site Scripting (XSS) qui nécessite un en-tête content-type spécifique, comme une requête gRPC, comme le script d'attaque s'exécute dans le navigateur de la victime, la requête est reconnue comme une requête légitime et envoyée avec cet en-tête content-type spécifique.