Le piratage d’un assureur via l’exploitation d’un calculateur de prime

• Des identifiants Microsoft Cloud d’entreprise ont été exposés sur un sous-domaine de calculateur de prime d’Eicher Motors, permettant de se connecter au compte e-mail noreply de TTIBI
• L’API d’envoi d’e-mails concernée envoyait des messages sans authentification, et les journaux d’envoi présents dans les réponses d’erreur du serveur révélaient un mot de passe encodé en base64
• Le compte exposé contenait 657 000 e-mails envoyés aux clients, environ 25 Go de PDF de polices d’assurance, d’informations clients, de liens de réinitialisation de mot de passe et d’OTP
• Le compte n’avait pas de 2FA, et d’autres ressources cloud comme l’annuaire d’entreprise Microsoft, SharePoint et Teams étaient également accessibles
• Plus de deux mois après le signalement, l’API vulnérable a été corrigée pour exiger une authentification ; au 27 janvier 2024, le mot de passe du compte e-mail avait aussi été modifié et il n’était plus possible de s’y connecter

---

La compromission de TTIBI partie du calculateur de prime d’Eicher

• En enquêtant sur les systèmes d’Eicher Motors, le compte e-mail Microsoft [e-mail] de Toyota Tsusho Insurance Broker India, ci-après TTIBI, a été exposé
• TTIBI est un courtier en assurance indien appartenant à la société japonaise Toyota Tsusho Insurance Management Corporation, fondé en 2008
• Eicher Motors est un constructeur automobile indien qui fabrique les motos Royal Enfield Motors ainsi que les véhicules utilitaires de VE Commercial Vehicles, une coentreprise avec Volvo Group
• Les deux entreprises avaient un partenariat lié à l’assurance, et le site de TTIBI disposait d’un sous-domaine dédié à Eicher

Chemin de découverte de la vulnérabilité

• En analysant l’application Android MY EICHER, une URL de calculateur de prime a été trouvée dans une classe Java d’interface API
• Le code source du site du calculateur de prime contenait un mécanisme d’envoi d’e-mails côté client
• Le code comportait des traces d’utilisation de Bearer Authorization, laissant penser qu’une authentification était nécessaire, mais lorsqu’une requête API a été construite directement, l’e-mail a effectivement été envoyé au lieu de renvoyer 401 Unauthorized
• La réponse d’erreur du serveur renvoyait aussi les journaux d’envoi d’e-mails, qui contenaient un mot de passe encodé en base64

Données présentes dans le compte noreply

• [e-mail] était un compte noreply destiné à l’envoi automatique d’e-mails, mais chez TTIBI il s’agissait d’un compte sur lequel il était réellement possible de se connecter
• Le compte conservait l’historique de tous les e-mails envoyés aux clients
  • Au total 657 000 e-mails
  • Environ 25 Go
  • Informations clients
  • PDF de polices d’assurance
  • Liens de réinitialisation de mot de passe
  • OTP
• La présence d’OTP et de liens de réinitialisation de mot de passe incluait des informations susceptibles d’être exploitées pour prendre le contrôle des comptes d’assurance des clients
• Le même compte permettait également d’accéder aux ressources Microsoft Cloud
  • Annuaire d’entreprise
  • SharePoint
  • Teams

Les défaillances de sécurité qui ont aggravé la vulnérabilité

• Fonction d’envoi d’e-mails côté client

  • Une fonction d’envoi d’e-mails où le client peut contrôler l’objet, le corps et le destinataire peut être détournée pour envoyer des messages malveillants
  • Comme les messages sont envoyés depuis un compte réel, cela peut nuire à la réputation e-mail et mener à du phishing

• Absence d’authentification de l’API

  • Le frontend contenait des traces d’utilisation d’un jeton d’authentification, mais le serveur ne vérifiait pas réellement ce jeton
  • Si le serveur avait validé le jeton, cette attaque aurait probablement pu être empêchée

• Réponses d’erreur d’API trop détaillées

  • Lorsqu’une erreur survenait pendant le traitement par l’API, celle-ci renvoyait trop d’informations au client
  • Dans ce cas, la réponse d’erreur exposait directement le mot de passe

• Absence de 2FA

  • Lors de la connexion au compte Microsoft, il n’y avait ni 2FA ni autre invite de vérification de connexion
  • Avec une 2FA, une connexion réussie aurait probablement été difficile

• Conservation des e-mails

  • Tous les e-mails envoyés et reçus par le compte étaient conservés, ce qui permettait d’accéder facilement à une grande quantité d’informations clients
  • Une politique de conservation aurait pu réduire l’impact de l’exposition des données clients

Réponse et état actuel

• Au 17 janvier 2024, plus de cinq mois après que TTIBI a pris connaissance de la vulnérabilité, le mot de passe du compte e-mail n’avait toujours pas été modifié
• Selon la mise à jour du 27 janvier 2024, le mot de passe du compte e-mail a été modifié, et il n’est plus possible de se connecter à ce compte
• L’API vulnérable a finalement été corrigée pour exiger une authentification
• Il n’a pas été confirmé s’il y avait eu des alertes de connexion Microsoft anormales ; si elles existaient, elles ont pu être ignorées ou ne pas être vérifiées

Chronologie du signalement

• TTIBI n’étant pas couverte par le programme de divulgation de vulnérabilités HackerOne de Toyota, le signalement a été fait à l’India CERT-In
• 7 août 2023 : envoi d’un rapport détaillé sur la vulnérabilité à CERT-In
• 8 août 2023 : CERT-In attribue un ID de dossier et répond qu’il contactera TTIBI
• 1er septembre 2023 : demande de mise à jour sur l’avancement
• 6 septembre 2023 : CERT-In répond avoir transmis la vulnérabilité à TTIBI et indique qu’il partagera d’autres mises à jour
• 8 octobre 2023 : le site web affecté est hors ligne, mais l’API vulnérable subsiste ; CERT-In en est informé
• 11 octobre 2023 : CERT-In répond que TTIBI a corrigé la vulnérabilité, mais une vérification montre qu’elle est toujours présente
• 18 octobre 2023 : l’API d’envoi d’e-mails est modifiée pour exiger une authentification, corrigeant la vulnérabilité
• Des échanges se poursuivent ensuite pour vérifier l’éventualité d’une récompense de bug bounty, mais TTIBI ne répond pas, et le dossier est clôturé le 22 décembre 2023

[GN⁺]

Commentaires sur Hacker News

• Je ne suis pas Indien, mais en travaillant dans une grande entreprise IT du genre Tata, tout cela me paraît terriblement réaliste
  Une culture managériale où l’on est récompensé si l’on boucle ça à bas coût joue énormément, tout comme une culture qui étouffe l’initiative des développeurs et leur accomplissement personnel
  Aux États-Unis, si j’avais vu ça, je serais parti immédiatement, mais là ils n’ont en pratique aucun choix, car en démissionnant ils doivent rembourser 90 jours de salaire
  La plupart des managers n’ont pas de bagage technique, n’écoutent que ce qu’ils veulent entendre et refusent d’entendre ce qui ne va pas
  Il est même possible que ce ne soit pas le résultat d’une seule équipe ou d’une seule entreprise, tant les développeurs sont cloisonnés à l’extrême : développeur API, développeur Office 365, développeur frontend, etc., et personne ne touche à un domaine pour lequel il n’est pas “certifié”
  Même dans des réunions sur des projets à 100 millions de dollars, on peut voir des gens se battre sérieusement sur le coût de SendGrid, puis finir avec un développeur qui dit qu’Office 365 peut le faire, au motif qu’il n’a pas d’“expérience SendGrid”
  Le budget de l’équipe sécurité est le premier à être coupé, puisqu’“on est déjà censés être en sécurité”, et si vous essayez d’en parler au jeune recruté pour la sécurité, l’attitude est de dire qu’aucun gouvernement ni personne ne va lancer de procès, alors pourquoi s’embêter
  Les développeurs ne sont pas encouragés à développer, mais à traiter des tickets et à ne pas poser de questions
  Je travaille avec des développeurs indiens brillants, mais ce n’est pas une culture de l’innovation : on les traite comme dans un centre d’appels. Il ne faut pas sortir du script, il faut rester dans un périmètre de problème étroit, et tant qu’on n’échoue pas, on considère qu’on gagne

  • Des choses comme le remboursement de 90 jours de salaire sont le résultat de l’absence de syndicats et de droits du travail
    Ça pourrait bientôt nous arriver aussi

• Au milieu ou à la fin des années 2000, un concessionnaire automobile lié à Honda avec lequel j’ai eu affaire stockait les dossiers de financement avec des ID numériques incrémentaux
  Je ne l’ai pas signalé, mais j’ai pu consulter les données sensibles de nombreux habitants du New Jersey, comme leur SSN, leur date de naissance, leur nom et leur adresse
  À l’époque, les bug bounties n’existaient pratiquement pas et le CFAA, lui, existait, donc je n’ai rien signalé
  J’ai obtenu la suppression de mon propre dossier, mais la faille est restée pendant des années, jusqu’au remplacement par un nouveau système, qui semblait lui aussi vulnérable
  Je n’ai plus jamais traité avec ce concessionnaire, et je suis encore aujourd’hui très prudent avec les demandes de financement automobile. Même si c’est un peu plus cher, je me finance généralement ailleurs

  • L’auteur a d’ailleurs redécouvert cette vulnérabilité en juin 2023
    https://eaton-works.com/2023/06/06/honda-ecommerce-hack/
  • Il existe une énorme faille autour d’un intermédiaire de confiance pour les données d’identité
    Je travaille sur le sujet connexe de la vérification d’identité chez https://cerebrum.com, et ce commentaire m’a donné beaucoup d’idées

• La faute de sécurité en elle-même est terrible, mais on peut au moins en partie l’expliquer par le fait qu’on a confié à un développeur inexpérimenté une tâche très au-delà de son champ de compréhension
  En revanche, je ne comprends absolument pas comment on a pu valider le stockage de documents clients confidentiels dans un compte e-mail
  Cela signifie que personne n’est responsable en sachant réellement comment exploiter cette activité, et si c’est une filiale ou un prestataire externe, cela veut aussi dire que personne n’a jamais procédé au moindre audit
  C’est proche de la négligence pénale, à la fois du côté du propriétaire de l’entreprise et de celui qui a confié cette mission

  • Avec un niveau de compétence pareil, il semble peu probable que quiconque ait même donné son approbation
    Il est bien plus probable qu’il y avait une fonction de stockage des messages envoyés sur le serveur mail, et que cela soit apparu comme sous-produit de la décision stupide d’utiliser un vrai compte pour une adresse “noreply”
  • J’ai déjà vu, dans un système immobilier assez important, tous les e-mails sortants être mis en copie cachée vers un compte partagé, puis synchronisés pour tout le monde dans Outlook
    Cela servait à la fois de journal d’audit, d’outil de débogage et de sauvegarde de base de données
    Ils n’ont changé cela qu’après avoir compris que les employés partaient vers un nouvel emploi avec toutes les données clients

• Si, “plus de 5 mois après, TTIBI connaissait la vulnérabilité mais n’a toujours pas changé le mot de passe du compte e-mail”, j’espère au moins qu’ils ont retiré le mot de passe en Base64 des journaux d’erreurs
  Ils l’ont sûrement fait. N’est-ce pas ?

• L’impact est littéralement énorme, au niveau d’un accès complet à SharePoint et Outlook, alors que le vecteur d’attaque se limite à regarder du JavaScript côté client, ce qui en fait une vulnérabilité assez atypique
  Un détail mineur : sur les captures d’écran, je pense qu’il vaut mieux masquer les données sensibles avec des blocs noirs plutôt qu’avec un flou. On n’est jamais trop prudent

  • De nos jours, la fonction de flou ne fait peut-être pas vraiment disparaître le texte d’origine ; elle peut simplement le rendre flou à l’affichage

• À cause de cette structure qui se termine par un simple “merci”, la plupart de ces vulnérabilités ne sont ni signalées ni divulguées par des white hats, mais activement exploitées par des hackers
  Il faudrait un cadre juridique permettant d’engager la responsabilité des entreprises en cas de mauvaise gestion de la sécurité au-delà d’un certain seuil, surtout lorsqu’il s’agit de données personnelles de clients

  • En Europe, ça existe déjà, et ça s’appelle le RGPD

• L’Inde a des problèmes plus graves encore que les fuites de données
  L’un d’eux est la fiabilité de l’alimentation électrique
  J’attends le jour où l’Inde aura suffisamment d’électricité pour que le piratage devienne la principale source d’inquiétude
  Le pays pose 100 000 km de fibre optique par mois et met en service 350 stations de base 5G par jour

• Il faut aussi voir que l’endpoint e-mail de supervision a en pratique été conçu comme un opérateur/agent/runner de communication, puis laissé à l’abandon jusqu’à grossir sans cesse
  Cela signifie aussi qu’il n’y a aucun suivi de l’usage de l’e-mail, ni aucun garde-fou permettant de repérer des comportements anormaux du type : “pourquoi cet alias e-mail coûte-t-il plusieurs fois plus cher en stockage que les autres ?”
  L’idée essentielle est que “le compte noreply possède potentiellement l’historique complet de tout ce qui a été envoyé aux clients, donc c’est peut-être le compte le plus important de toute l’organisation”

• Si un “courtier d’assurance leader à l’échelle de l’Inde” n’a pas les moyens d’embaucher des développeurs compétents, il devrait au moins verser quelque chose à la personne qui a découvert plusieurs problèmes graves mettant les clients en danger et les a signalés de façon responsable
  Mais ils ne l’ont pas fait, et il est même incroyable de constater qu’ils n’ont toujours pas réinitialisé le mot de passe du compte e-mail compromis
  Comment faire confiance à une entreprise qui se comporte ainsi et espérer qu’elle fasse quoi que ce soit correctement ?
  Toyota Tsusho Insurance Broker India ressemble à une entreprise à éviter comme la peste

  • J’ai déjà vu moi-même un niveau d’incompétence comparable
    Ce n’est pas quelqu’un qui ignore activement une alerte de sécurité importante ; c’est quelqu’un qui ne comprend tout simplement pas ce dont vous parlez
    Il ne comprend pas fondamentalement l’environnement qu’il exploite ni les problèmes auxquels il fait face, et le jargon spécialisé que vous employez n’a aucun sens ni pour lui ni pour son équipe, donc il veut juste que vous disparaissiez
    C’est une attitude du genre : “Arrêtez de m’envoyer ces e-mails confus. J’ai des choses importantes à faire”
    Pour régler ça, il faut un remplacement de la direction à l’échelle de l’organisation, et le responsable IT ainsi que tout ce qu’il a touché doivent partir
  • Il est très probable qu’il n’existe presque pas d’alternative, et c’est peut-être précisément ce qui a engendré ce genre de problème dès le départ

• Une partie du problème vient du fait qu’ils utilisaient cette boîte de réception comme une sorte de compte SMTP “gratuit” afin d’éviter de payer l’envoi d’e-mails
  S’ils avaient utilisé quelque chose comme SES, il n’y aurait probablement pas eu autant d’informations sensibles dans les éléments envoyés et reçus de ce compte
  SES coûte seulement 0,10 $ pour 1 000 e-mails, ce qui est extrêmement bon marché

  • Techniquement c’est vrai, mais ici le vrai coût de SES aurait sans doute été le temps de développement
    Il aurait fallu enregistrer tous les e-mails envoyés et créer une interface permettant à des chargés d’opérations non développeurs de consulter et rechercher les anciens messages
    S’ils exploitaient réellement toutes les fonctionnalités de cet accès SMTP “gratuit”, alors le coût de développement et de maintenance serait assez élevé