Interception de trafic chiffré détectée sur jabber.ru chez Hetzner et Linode

 (notes.valdikss.org.ru)
1 points par GN⁺ 2023-10-21 | 1 commentaires | Partager sur WhatsApp
  • Des indices montrent que des connexions XMPP STARTTLS sur le port 5222 ont été interceptées par un proxy MiTM transparent sur le serveur dédié Hetzner et les VPS Linode du service XMPP russe jabber.ru/xmpp.ru
  • Les attaquants ont obtenu plusieurs certificats TLS via Let’s Encrypt et ont terminé les connexions chiffrées au milieu du chemin ; le problème a été révélé lorsque le port 5222 de jabber.ru chez Hetzner a commencé à présenter un certificat expiré
  • Aucune trace de compromission des serveurs ni d’ARP spoofing sur le même segment réseau n’a été trouvée, et les instances Linode montraient un chemin et une adresse MAC de passerelle différents de ceux d’une VM normale, ce qui suggère fortement une reconfiguration du réseau d’hébergement
  • Le MiTM a été confirmé au minimum du 21 juillet au 19 octobre 2023, avec une possibilité dès le 18 avril 2023 ; 100 % des connexions sur le port 5222 ont été affectées, tandis que le port 5223 ne l’a pas été
  • Les communications jabber.ru/xmpp.ru pendant cette période doivent être considérées comme compromises, et même le chiffrement de bout en bout comme OMEMO, OTR ou PGP n’était protecteur que si les deux parties avaient vérifié les clés

Interception révélée par un certificat expiré

  • jabber.ru est un service XMPP russe lancé en 2000, également connu sous le nom de xmpp.ru
  • Le 16 octobre 2023, lors d’un accès au service, le message « Certificate has expired » est apparu, alors que tous les certificats installés sur le serveur étaient à jour
  • L’anomalie n’apparaissait que sur le port 5222 utilisé par XMPP STARTTLS, et n’a pas été observée sur d’autres ports comme le port 5223 pour XMPP sur TLS
  • Les serveurs touchés étaient un serveur dédié Hetzner en Allemagne et deux serveurs virtuels Linode
  • Sur le trafic du port 5222, il a été observé que le serveur recevait non pas le ClientHello d’origine du client, mais un ClientHello remplacé

Résultats de l’enquête côté compromission serveur

  • L’enquête visait à vérifier à la fois l’hypothèse d’un piratage des serveurs et celle d’un spoofing sur le réseau local
  • Côté serveur, les éléments suivants ont été vérifiés sans résultat anormal
    • l’ensemble des journaux
    • les dates de modification des exécutables et bibliothèques
    • les processus en cours, les cartes mémoire et les dangling file descriptors
    • la présence éventuelle de bibliothèques de détournement LD_PRELOAD en espace utilisateur à l’aide d’un busybox compilé statiquement
    • l’existence de modules de détournement au niveau noyau via un dump de mémoire noyau avec LiME et une analyse avec volatility
  • Dans les journaux du noyau du serveur dédié Hetzner, seule une coupure de 19 secondes du lien réseau physique le 18 juillet 2023 a été relevée comme exception
  • Les serveurs Linode n’étaient utilisés que comme tunnels de chemin alternatif vers le serveur Hetzner et n’exécutaient que des services de base comme SSH et NTP
  • À l’intérieur du tunnel Hetzner↔Linode, le ServerHello légitime du serveur Hetzner était visible, mais il était modifié au moment de l’envoi au client via l’interface réseau Linode
    • en d’autres termes, le même type d’interception de connexion chiffrée se produisait à la fois chez Hetzner et chez Linode

Anomalies observées sur le réseau Linode

  • Du point de vue réseau, les points suivants ont été examinés sans trouver de traces de détournement à proximité des serveurs
    • un éventuel ARP spoofing de l’adresse MAC de la passerelle
    • le fait qu’une même IP réponde plusieurs fois aux requêtes ARP sur le segment L2
    • des règles de routage anormales injectées via ICMP redirect ou autres mécanismes
    • les règles Netfilter
    • l’existence de tunnels difficiles à détecter, comme IPsec
  • Les machines Linode affectées ne pouvaient ni résoudre par ARP ni joindre par ping les IP voisines du même segment réseau, alors que depuis des réseaux externes ces IP voisines fonctionnaient normalement
  • Une VM Linode tierce non affectée pouvait joindre les hôtes voisins par ping et était connectée à un routeur Cisco Systems
  • En revanche, les VPS affectés étaient connectés à une passerelle dont l’adresse MAC ne permettait pas d’identifier le constructeur
  • Cette différence renforce l’hypothèse que les VM Linode affectées utilisaient une configuration réseau différente des instances Linode ordinaires, ou qu’elles étaient isolées dans un VLAN distinct

Certificats frauduleux et traces dans Certificate Transparency

  • La base de données de certificate transparency crt.sh a révélé des rogue certificates que les serveurs jabber.ru n’avaient pas émis
  • Deux types de certificats étaient utilisés par le service XMPP légitime
    • xmpp.ru, *.xmpp.ru
    • jabber.ru, *.jabber.ru
  • Les certificats émis de manière malveillante différaient légèrement des certificats légitimes
    • soit en omettant le Subject Alternative Name wildcard
    • soit en regroupant jabber.ru et xmpp.ru dans un même certificat
  • La configuration MiTM côté Linode pointant vers le domaine xmpp.ru était partiellement incorrecte
    • le serveur d’origine était configuré pour fournir à la fois les certificats jabber.ru et xmpp.ru selon le domaine XMPP demandé
    • le côté MiTM ne fournissait que le certificat xmpp.ru
  • L’heure d’émission du certificat du 18 juillet 2023 coïncide presque avec l’instant où le lien réseau du serveur Hetzner a été coupé pendant quelques secondes
  • Un scanner réseau externe a confirmé qu’au minimum depuis le 21 juillet 2023, les serveurs Linode présentaient le certificat 04:b7:85… sur le port 5222
  • Ce scanner ne couvrait pas la plage Hetzner

Équipement en amont du port 5222 et différences de chemin

  • Des tests réseau supplémentaires ont été effectués depuis l’extérieur vers les VPS Linode
  • Les hôtes voisins du même segment Linode étaient joignables au hop 13 depuis une connexion Internet de portable
  • Le port 5222 intercepté du serveur Linode dawn.jabber.ru était lui aussi joignable au hop 13
  • Mais les ports non interceptés du même serveur, comme le port SSH 22, n’étaient joignables qu’au hop 14 après un hop supplémentaire non public
  • Cela indique que l’adresse IP de la VM Linode se trouvait derrière un équipement supplémentaire, lequel traitait directement le port TCP 5222 et routait les autres ports vers la destination réelle
  • À l’intérieur du VPS, il était impossible de créer de nouvelles connexions avec le port source 5222
    • le routeur ne répondait pas aux paquets émis avec ce port source
    • il n’envoyait pas non plus d’ICMP error ni de Time-to-Live Exceeded pour les paquets sortants avec TTL=0 ou TTL=1

Mode de terminaison STARTTLS et empreinte de détection

  • D’après l’analyse réalisée avec testssl.sh, le proxy intercepteur autorisait des anonymous ciphers à la fois sur Linode xmpp.ru et sur Hetzner jabber.ru
  • Il s’agit d’une mauvaise configuration rare qui peut servir d’empreinte de détection d’un MiTM XMPP
  • Les bibliothèques SSL/TLS classiques sont généralement compilées sans prise en charge des anonymous ciphers, et même lorsqu’on les autorise explicitement dans la configuration, il est souvent difficile de faire en sorte qu’un service les utilise réellement
  • Le serveur d’origine n’avait pas d’anonymous ciphers configurés
  • En testant une vingtaine de services XMPP populaires avec la même commande testssl.sh, aucun signe anormal comme la prise en charge d’Anonymous NULL Ciphers n’a été observé

Conclusions établies et impact pour les utilisateurs

  • Les attaquants ont obtenu via Let’s Encrypt plusieurs certificats SSL/TLS pour les domaines jabber.ru et xmpp.ru à partir du 18 avril 2023
  • Une attaque Man-in-the-Middle visant à déchiffrer le trafic XMPP client de jabber.ru/xmpp.ru a été confirmée au minimum du 21 juillet au 19 octobre 2023
  • Il reste possible qu’elle ait commencé dès le 18 avril 2023, sans confirmation formelle
  • Le périmètre d’impact couvre 100 % des connexions XMPP STARTTLS sur le port 5222, le port 5223 n’étant pas concerné
  • Les attaquants n’ont pas réussi à renouveler les certificats TLS, et le proxy MiTM du port 5222 de jabber.ru chez Hetzner a commencé à présenter un certificat expiré
  • L’attaque MiTM a cessé juste après l’enquête du 18 octobre 2023, les tests réseau et l’ouverture de tickets auprès du support Hetzner et Linode
  • Cependant, sur au moins un serveur Linode, une écoute passive subsistait sous la forme d’un hop de routage supplémentaire
  • Aucune trace de piratage des serveurs n’a été trouvée, et tout porte à croire que les réseaux Hetzner et Linode ont été reconfigurés pour mener cette attaque contre les adresses IP du service XMPP
  • Les communications jabber.ru/xmpp.ru durant cette période doivent être considérées comme compromises
    • les attaquants pouvaient agir comme s’ils exécutaient des actions depuis un compte authentifié sans connaître le mot de passe du compte
    • ils pouvaient télécharger le roster du compte, accéder à l’historique complet des messages côté serveur non chiffrés, envoyer de nouveaux messages et modifier des messages en temps réel
  • Les communications chiffrées de bout en bout avec OMEMO, OTR ou PGP n’étaient protégées contre l’interception que si les deux parties avaient vérifié les clés de chiffrement
  • Les utilisateurs doivent vérifier la présence de nouvelles clés OMEMO ou PGP non autorisées dans le dépôt PEP et changer leur mot de passe

Prévention et supervision possibles pour les opérateurs

  • Les nouvelles émissions de certificats étant enregistrées dans Certificate Transparency, il est possible de mettre en place une surveillance Certificate Transparency
  • L’utilisation de RFC 8657 CAA Record Extensions for Account URI and ACME Method Binding permet de restreindre les méthodes d’émission de certificats et les identifiants de compte autorisés à émettre
  • Il est possible de surveiller via un service externe les changements de certificats SSL/TLS de tous les services
  • Il est possible de surveiller les changements d’adresse MAC de la passerelle par défaut
  • Le channel binding de XMPP peut détecter un MiTM même si l’intercepteur présente un certificat valide
    • le client et le serveur doivent tous deux prendre en charge le mécanisme d’authentification SCRAM PLUS
    • ce n’était pas activé sur jabber.ru au moment de l’attaque
  • D’autres recommandations du développeur ACME Hugo Landau sont regroupées dans More recommendations from ACME developer Hugo Landau

Réponses de Hetzner et Linode

  • Au 20 octobre 2023, aucune réponse suffisante n’avait été reçue de Hetzner et Linode
  • Dans la mise à jour du 3 novembre 2023, aucun des deux fournisseurs n’avait encore apporté de réponse appropriée à cet incident
  • Hetzner a répondu qu’il ne fournissait pour les serveurs root dédiés et les serveurs Cloud que le matériel, l’accès réseau et l’infrastructure nécessaire, et qu’il ne pouvait proposer de solution supplémentaire
  • Linode a indiqué avoir reçu les journaux mais n’avoir observé aucune activité illicite affectant le service, puis a clos le ticket
  • Les opérateurs estiment plus probable que Hetzner et Linode aient été contraints d’appliquer cette configuration dans le cadre d’une interception légale à la demande de la police allemande
  • Une autre possibilité serait une intrusion dans les réseaux internes de Hetzner et de Linode visant spécifiquement jabber.ru, mais ce scénario paraît bien moins crédible sans être totalement impossible

À lire aussi

1 commentaires

 
GN⁺ 2023-10-21
Avis sur Hacker News

  • Il semble très probable que ce soit lié à une enquête sur la cybercriminalité russe. Si vous avez lu Krebs ou fréquenté des forums russes plus obscurs, xmpp.ru vous sera familier, et il y a effectivement ce contexte
    Je ne cherche pas à faire porter quoi que ce soit aux opérateurs ; je veux dire que lorsqu’on exploite un service anonyme, il finit par avoir ce genre de profil
    https://ddanchev.blogspot.com/2021/03/exposing-currently-act...
    https://ddanchev.blogspot.com/2019/07/profiling-currently-ac...
    https://blog.talosintelligence.com/picking-apart-remcos/
    https://flashpoint.io/wp-content/uploads/Plea-Agreement-USA-...
    L’article lui-même est vraiment intéressant, et ressemble à un exemple concret de pourquoi tout le monde devrait utiliser un service de surveillance de la transparence des certificats

    • Les organisations de trafic de drogue utilisent largement XMPP avec Tor comme canal de communication sécurisé. Le marché du darknet Hydra a été fermé par la police allemande en 2022 alors qu’il tentait d’étendre ses « services » à l’UE ; quelque chose de similaire a pu, ou non, se produire ici
    • Je suis globalement du même avis. Cela semble pouvoir être lié au démantèlement de Genesis Market ou de Qakbot

  • Je suis d’accord avec la plupart des mesures d’atténuation proposées. Si l’on est une cible à haut risque, il vaut la peine d’envisager d’empiler une couche d’authentification supplémentaire qui ne dépende pas des autorités de certification de confiance : Tor onion services, SSH, WireGuard, etc.
    Je suis d’accord sur le fait que tous les certificats SSL/TLS émis sont soumis à la transparence des certificats, et crt.sh propose aussi un flux RSS
    Utiliser CAA est généralement une bonne idée, mais je doute que cela aide dans ce cas. L’attaquant peut demander exactement la configuration de certificat autorisée par CAA ; cela pourrait aider s’il était possible de restreindre plus fortement une méthode de validation précise
    Je suis aussi d’accord sur le fait qu’il faut surveiller, via un service externe, les changements de certificats SSL/TLS de tous les services. Les cibles à haut risque doivent toujours savoir quels certificats sont valides et les vérifier
    Quant à surveiller les changements d’adresse MAC de la passerelle par défaut, une attaque plus sophistiquée pourrait conserver la même adresse MAC
    J’ignorais que le « channel binding » de XMPP pouvait aussi détecter une attaque de l’homme du milieu présentant un certificat valide

    • Je suis l’auteur d’ACME-CAA (RFC 8657). On peut mettre l’identifiant unique du compte ACME dans l’enregistrement CAA, ce qui permet d’atténuer ce type d’attaque, sauf si l’attaquant obtient la clé privée du compte ACME ou contraint le service ACME
      Cela suppose bien sûr que le serveur de noms soit protégé par DNSSEC. Sinon, les requêtes DNS peuvent aussi être interceptées lorsque l’autorité de certification les consulte
      Pour l’ensemble des considérations de sécurité, voir la RFC 8657. Cette RFC a été conçue pour être plus lisible que la plupart des RFC
      Mon billet de blog avec le contexte : https://www.devever.net/~hl/acme-caa-live
    • Que se passe-t-il si un État ordonne à une autorité de certification située sur son territoire d’émettre un certificat sans journaux CT, avec une interdiction d’en parler ? Dans une situation où refuser signifie aller en prison, je doute qu’un administrateur système ordinaire veuille aller en prison pour protéger un serveur Jabber russe
    • Si l’on a un accès physique au serveur, autant viser directement celui-ci. Avec un minimum d’efforts, on peut dupliquer le disque, le réseau et la RAM sur du matériel courant

  • Réussir une vraie attaque de l’homme du milieu à la perfection puis oublier de renouveler le certificat, c’est assez allemand :-)

    • Je me demande si quelqu’un ne l’a pas « oublié » volontairement. Peut-être pour que les gens l’apprennent
      Ou bien quelqu’un a peut-être suivi les ordres très consciencieusement. Il y avait bien un ordre de configurer le certificat, mais aucune exigence de renouvellement automatique :)
    • Let’s Encrypt envoie pourtant des e-mails de rappel en continu, comment est-ce possible ?

  • Archive : https://archive.ph/C0jYJ
    Les théories sont intéressantes et, si elles sont vraies, elles expliquent comment le certificat a été obtenu. La leçon à en tirer est peut-être de disposer de plusieurs sondes chez plusieurs fournisseurs, de vérifier toutes les empreintes TLS et, lorsqu’une empreinte inconnue apparaît, de recevoir une alerte et de vérifier aussi la présence dans les journaux de transparence des certificats
    openssl s_client -servername news.ycombinator.com -connect news.ycombinator.com:443 < /dev/null 2>/dev/null | openssl x509 -fingerprint -noout -in /dev/stdin
    SHA1 Fingerprint=7E:49:BA:40:86:87:B3:39:66:93:94:9E:9C:45:71:85:3C:8D:95:16

    • J’ai ajouté une section « Peut-on prévenir ou surveiller ce type d’attaque ? ». Il existe plusieurs signaux utilisables pour détecter l’attaque dès le premier jour
      Comme tous les certificats SSL/TLS émis sont soumis à la transparence des certificats, il est recommandé de configurer une surveillance de la transparence des certificats comme Cert Spotter afin de recevoir une notification par e-mail lorsqu’un nouveau certificat est émis pour le domaine
      Avec l’extension des enregistrements CAA de la RFC 8657, c’est-à-dire Account URI et ACME Method Binding, on peut limiter les méthodes de validation et préciser l’identifiant exact du compte autorisé à émettre de nouveaux certificats, ce qui permet d’empêcher l’émission de certificats pour le domaine via d’autres autorités de certification, comptes ACME ou méthodes de validation
      Il faut surveiller via un service externe les changements de certificats SSL/TLS de tous les services, ainsi que les changements d’adresse MAC de la passerelle par défaut

  • J’étais un peu curieux parce que l’adresse MAC n’était pas une adresse administrée localement. Il semble possible que quelqu’un ait choisi intentionnellement cette plage d’adresses
    https://www.google.com/search?q=%2290%253Ade%253A01%22+linod...
    En cherchant "90:de:01" linode et "90:de:00" linode, il semble que des adresses de ce bloc aient récemment été attribuées à d’autres VM Linode. Je n’ai pas de VM Linode sous la main pour comparer directement, mais on dirait que le trafic a été routé vers une autre VM de l’infrastructure Linode

  • Ce n’est qu’une spéculation sans preuve, mais je pense que Jabber a été ciblé parce qu’il est notoirement utilisé sur les marchés du darknet pour le trafic de drogue ou d’autres activités illégales
    Cela montre qu’il ne faut pas se contenter de croire que « c’est chiffré, donc tout va bien ». Au minimum, les messages devraient être chiffrés avec PGP
    Je me demande si PGP peut être cassé par des ordinateurs quantiques, et si des renforcements contre ce type d’attaques verront le jour. Si des messages ont été collectés en masse sous forme chiffrée, leur déchiffrement pourrait au final n’être qu’une question de temps
    Et il semble que ce genre de chose arrive à presque tout le trafic web auquel ils peuvent mettre la main. Voir https://en.wikipedia.org/wiki/Utah_Data_Center

    • Jabber/XMPP dispose d’un chiffrement de bout en bout depuis au moins 10 à 15 ans. À l’époque où Facebook/Google Talk prenaient en charge XMPP, on pouvait utiliser pidgin, kopete, etc. pour communiquer ainsi même avec des amis ordinaires
      Évidemment, échanger des clés en toute sécurité avec un vendeur de drogue anonyme sur Internet est propice aux erreurs
    • Cette attaque de l’homme du milieu pourrait faire partie du démantèlement de Genesis Market, mais ce n’est qu’une hypothèse sortie de nulle part
      https://therecord.media/genesis-market-takedown-cybercrime
    • Une deuxième couche de chiffrement aiderait, mais je ne recommanderais pas spécialement PGP lui-même
      PGP a beaucoup de problèmes et beaucoup de gens conseillent de l’éviter. Par exemple : https://www.latacora.com/blog/2019/07/16/the-pgp-problem/ / https://news.ycombinator.com/item?id=20455780

  • Les communications chiffrées de bout en bout comme OMEMO, OTR ou PGP ne protègent contre l’interception que si les deux parties ont vérifié les clés de chiffrement. L’attaquant doit mettre en place une attaque de l’homme du milieu distincte pour chaque méthode de chiffrement de bout en bout utilisée
    Certains clients XMPP que j’ai vus refusaient de fonctionner si l’on n’indiquait pas explicitement avoir vérifié une identité de chiffrement donnée
    Cela reste un bon rappel. Si vous n’avez jamais eu à vérifier une suite de chiffres absurdement longue, ou quelque chose d’équivalent, il est difficile de considérer que le chiffrement de bout en bout est réellement établi

  • Il y a un point que je ne comprends pas dans cette histoire. S’il s’agissait d’une interception légale, pourquoi Hetzner et Linode auraient-ils configuré une interception par homme du milieu avec des certificats et clés LE séparés ?
    Ils auraient pu extraire directement la clé privée TLS depuis la RAM ou le stockage du VPS. Même avec un serveur physique dédié, il serait possible d’obtenir un dump de la RAM après un redémarrage non annoncé et d’en extraire la clé privée
    L’extraction de la clé privée n’apparaît pas dans les logs CT, elle est donc bien plus discrète et pratiquement impossible à détecter

    • Probablement parce que c’était plus simple
      Une autre possibilité est qu’un côté relevait d’une « perquisition » et l’autre d’une « interception », avec des niveaux d’autorisation différents. Cela dit, je ne connais pas bien la situation juridique actuelle en Allemagne
    • C’est probablement parce que cette option serait « plus illégale ». Si le serveur n’est pas directement impliqué dans des activités cybercriminelles, je ne pense pas qu’il soit permis de le pirater
    • Avec un serveur physique, ne pourrait-on pas brancher à chaud une carte PCIe et extraire les données voulues via DMA ? Cela semble possible avec quelque chose comme une carte réseau dotée d’un firmware adapté à cet objectif
      Ça paraît tellement standard pour les forces de l’ordre qu’il doit bien exister du matériel prêt à l’emploi pour ça

  • Un utilisateur l’avait déjà posté sur Reddit il y a 3 jours : https://www.reddit.com/r/hetzner/comments/17ankoh/does_hetzn...

  • Je me demande s’il existe un moyen d’obliger légalement Hetzner/Linode à commenter cette situation. Il semble très probable qu’une agence gouvernementale ou la police soit derrière cette interception

    • Étant donné que Hetzner est une entreprise allemande, s’il s’agit d’une interception légale, on ne peut pas exiger de réponse. Difficile de faire quoi que ce soit sans passer d’abord par un avocat
      À l’inverse, s’il ne s’agit pas d’une interception légale, je doute que Hetzner l’ait autorisée, car ce serait également contraire à la loi
    • Rien ne garantit non plus que l’interception ait été effectuée via Hetzner ou Linode. Elle pourrait par exemple venir de l’opérateur télécom, et dans presque tous les pays, les opérateurs télécoms sont contraints depuis des décennies de coopérer aux interceptions légales