Un chercheur découvre qu’une faille sur le site d’a16z a exposé des données de certaines entreprises

 (kibty.town)
1 points par GN⁺ 2024-07-21 | 1 commentaires | Partager sur WhatsApp
  • Un chercheur en sécurité a découvert que, sur le sous-domaine lié à a16z portfolio.a16z.com, l’intégralité de process.env d’une instance Heroku était injectée dynamiquement dans le JavaScript
  • Les valeurs exposées incluaient plusieurs identifiants de services comme DATABASE_URL, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, SALESFORCE_CLIENT_SECRET, OKTA_CLIENT_SECRET et MAILGUN_API_KEY
  • Le chercheur explique avoir repéré une référence à une clé AWS lors d’un contrôle classique de secrets dans des fichiers JS avec lunchcat, et précise que cela était visible rien qu’avec l’onglet Sources des outils de développement du navigateur
  • Le périmètre potentiellement touché comprenait une base de données contenant des PII, AWS, Salesforce et Mailgun ; il affirme que Mailgun permettait d’envoyer des e-mails arbitraires depuis le domaine a16z et de lire d’anciens e-mails
  • a16z n’a pas versé de bug bounty en invoquant les tentatives de contact publiques, tandis que le chercheur affirme qu’aucun contact n’était disponible sur le site principal et que l’adresse e-mail qu’il avait trouvée renvoyait un message d’erreur

Des variables d’environnement révélées lors d’un audit de sous-domaines

  • Le chercheur dit repérer des cibles en trouvant des entreprises sur Twitter puis en réalisant rapidement des tests d’intrusion, en utilisant souvent l’onglet Relevant People
    • Cette fois, le parcours a été : entreprise liée à la crypto → capital-risque crypto → a16z crypto → a16z
  • Lors de l’enquête sur a16z, il a effectué un scan classique de sous-domaines et utilisé l’outil lunchcat pour inspecter les domaines et détecter des secrets dans les fichiers JS
  • portfolio.a16z.com semblait être un outil de gestion de portefeuille pour les entreprises du portefeuille d’a16z, et l’audit a détecté quelque part sur le site une référence à une clé AWS
  • Dans le JS, des valeurs qui semblaient correspondre à l’intégralité de process.env d’une instance Heroku étaient injectées dynamiquement
    • Parmi les éléments inclus figuraient MARKETPLACE_URL, DATABASE_URL, SALESFORCE_CLIENT_ID, SALESFORCE_CLIENT_SECRET, OKTA_CLIENT_SECRET, SESSION_SECRET, MAILGUN_API_KEY, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, COOKIE_SECRET et HEROKU_POSTGRESQL_CRIMSON_URL
    • Le chercheur indique avoir rapidement vérifié ces identifiants et qu’ils semblaient être de vrais identifiants, pas de faux
    • Il précise que l’accès ne nécessitait rien de plus que l’ouverture de l’onglet Sources dans les outils de développement du navigateur

Périmètre d’exposition possible et controverse autour du bug bounty

  • Les services potentiellement compromis listés par le chercheur sont les suivants
    • Base de données : il affirme qu’elle contenait des PII
    • AWS : une possibilité d’accès via les clés exposées est mentionnée
    • Salesforce : il dit ne pas l’avoir vérifié directement et ajoute que les permissions du compte pouvaient être limitées
    • Mailgun : il affirme qu’il était possible d’envoyer des e-mails arbitraires depuis le domaine a16z et de lire d’anciens e-mails
    • Il mentionne aussi la possibilité d’autres services touchés
  • a16z n’a pas versé de bug bounty au motif que le chercheur avait tenté de contacter l’entreprise publiquement plutôt qu’en privé
  • Le chercheur avance deux raisons à cette prise de contact publique
    • Il n’a pas trouvé de moyen de contact exploitable sur le site principal d’a16z
    • L’e-mail envoyé à l’adresse qu’il avait pu trouver lui est revenu en erreur
  • Un article de TechCrunch est joint en référence, et le chercheur explique que Lorenzo a écrit l’article après l’avoir contacté en voyant son tweet publié pour tenter de joindre a16z

À lire aussi

1 commentaires

 
GN⁺ 2024-07-21
Commentaires sur Hacker News

  • Lorsque nous avons publié notre projet open source (https://github.com/heyPuter/puter/), Eva a réalisé des tests d’intrusion assez approfondis et a traité le signalement des vulnérabilités de façon très professionnelle.
    À l’époque, nous n’avions même pas de programme de bug bounty, elle n’a pas demandé de récompense, et Eva est une hackeuse à la fois brillante et responsable ; a16z devrait mieux la traiter.

  • J’ai déjà fait une erreur similaire.
    Nous utilisions un CMS Node.js appelé apostrophecms, et nous nous servions du panneau d’administration « global settings » pour gérer des clés d’API du serveur d’authentification ; ce n’est que plusieurs mois plus tard que nous avons découvert que ces valeurs étaient rendues dans le code source HTML.
    C’était conçu ainsi pour les rendre utilisables en JavaScript, et c’était documenté, donc je ne leur en veux pas, mais nous avons survolé ça un peu trop vite.
    Le plus agaçant, c’est que nous avions payé assez cher une grande société de conseil pour un test d’intrusion, et qu’eux non plus ne l’ont pas détecté ; au final, nous l’avons découvert nous-mêmes et, en vérifiant les journaux, il ne semblait pas y avoir de traces d’exploitation, mais c’était une fuite assez choquante.

    • Pour ce test d’intrusion, je demanderais au moins un remboursement.
      Jusqu’ici, je n’ai jamais vu de test d’intrusion qui soit plus qu’une case à cocher.
    • Je suis vraiment désolé que vous ayez subi une exposition inattendue en utilisant ApostropheCMS.
      Comme vous l’avez dit, ce mode de partage des données était documenté, mais il pouvait tout de même surprendre.
      Pour ceux qui enquêteraient à l’avenir, j’ajoute que la version majeure d’Apostrophe actuellement prise en charge ne fonctionne plus de cette façon.
      L’injection de données dans le front-end non connecté doit être un choix délibéré du développeur, et ce changement a été fait pour éviter ce genre de surprise.
      Cela dit, il existe encore des cas d’usage où des clés d’API doivent être incluses dans les paramètres et une partie du contenu de certains widgets.
      À noter : je suis responsable du design d’Apostrophe et j’y ai aussi un rôle d’ingénierie.
    • Je me demande pourquoi utiliser un système de gestion de contenu web pour gérer des secrets.
    • Correction : je ne veux pas accuser apostrophe cms.
      Cette situation est due à notre configuration multitenant et à notre manque de compréhension d’apostrophe.
    • Tu as dit : « c’était documenté, donc je ne leur en veux pas. Nous avons survolé ça un peu trop vite », mais il faut quand même leur en vouloir.
      Documenter un comportement dangereux n’exonère pas de toute responsabilité, et cette leçon devrait désormais être largement connue.

  • Quand on crée un nouveau service et qu’on ajoute un certificat LetsEncrypt au serveur via ACME, les journaux se remplissent immédiatement de requêtes poubelles.
    On voit clairement des bots chercher des valeurs par défaut faibles que des développeurs auraient pu laisser ouvertes, et j’ai même déjà vu des requêtes visant le fichier d’environnement du processus.
    Je ne comprends pas comment cette vulnérabilité a pu ne pas être découverte ou exploitée ; soit a16z a eu énormément de chance, soit elle a déjà été exploitée sans que cela soit rendu public.
    Un chercheur bien intentionné, ou quelqu’un qui s’ennuyait avec un état d’esprit white hat, les a contactés en premier ; c’est dommage qu’il n’existe pas de cadre juridique pour ce genre de négligence, mais je pense qu’a16z devrait recevoir une lourde amende.

    • « Comment cette vulnérabilité a-t-elle pu ne pas être découverte ou exploitée ? »
      Peut-être qu’elle l’a déjà été.
      La laisser ouverte avait peut-être plus de valeur que de simplement casser quelque chose.
    • Pour être juste, le site principal lui-même ne semble pas si intéressant.
      En revanche, quelques identifiants comme OKTA semblent assez dangereux.

  • Le passage disant : « Nous n’avons pas accordé de bug bounty parce que le contact a été public. La raison est qu’il n’y avait aucun contact sur le site principal, et que l’adresse engineering@a16z.com trouvée renvoyait les e-mails » ressemble à une astuce maligne pour économiser l’argent de l’entreprise.
    Si l’on ne laisse aucun moyen de contacter l’équipe d’ingénierie en privé, tous les signalements de bug bounty se font publiquement, et on peut alors ne rien payer.

    • Malin à plusieurs niveaux.
      Ils ont probablement aussi beaucoup économisé sur le développement en cassant les prix avec des gens sur des plateformes comme fiverr, et si un groupe de rançongiciels russe les dépouille facilement, ils économiseront aussi indirectement beaucoup de frais comptables.
    • Mais pour la prochaine fois, cela revient à apprendre aux chercheurs en sécurité à vendre l’information au lieu de la signaler.
    • Une entreprise n’a pas besoin d’un « hack » séparé pour ne pas payer.
      S’il n’y a pas de programme public de bug bounty, elle ne doit rien.
      En plus, il y a une adresse e-mail de contact en bas de https://a16z.com/connect, que le chercheur a commodément manquée.
      Cela ressemble davantage à une recherche de visibilité qu’à une divulgation responsable.
    • Si cela se répète, ils seront connus comme des gens qui ne paient pas les primes, et les gens seront moins susceptibles de signaler les problèmes qu’ils découvrent.
    • S’il avait publié sur HN pour demander comment contacter l’ingénierie d’a16z, cela aurait probablement donné de bons résultats.

  • Quand les entreprises disent qu’elles ont été « piratées », j’entends désormais une formule corporate du genre : « nous n’avons pas correctement protégé des identifiants importants, mais veuillez faire porter la responsabilité à un acteur inconnu que nous appelons “hacker” ».

    • Si vous laissez accidentellement la porte d’entrée grande ouverte et que quelqu’un vole tous vos biens, vous direz quand même que vous avez été « cambriolé ».
      Il existe des distinctions juridiques comme « violation de domicile », « vol » ou « intrusion », et le fait que la porte ait été ouverte peut influer sur l’illégalité ou la peine, mais dans le langage courant, cela reste un cambriolage.

  • Ne pas accorder ne serait-ce qu’une prime d’un montant symbolique pour une faille aussi largement béante, c’est assez lamentable.

    • La prochaine fois que quelqu’un trouvera leurs clés, il lira peut-être ce billet et les publiera dans un dépôt GitHub public au lieu de les signaler.

  • Ils sont occupés à écrire d’énormes livres blancs sur les architectures d’IA générative.
    Laissons-les souffler un peu : ils rêvent d’un futur monde d’agents où des chatbots à moitié finis se déplacent.
    Pendant que le monde brûle à cause d’une mise à jour logicielle cassée.

    • Le monde brûle déjà sous les effets du changement climatique.
      La mise à jour logicielle cassée de vendredi n’est que la cerise sur le gâteau.
    • « engineering@a16z.com renvoyait les e-mails »
      Pas du tout surprenant.

  • S’il était réellement possible d’accéder à l’instance Salesforce, ce serait très inquiétant du point de vue des fondateurs.
    En général, des endroits comme Salesforce conservent les e-mails, et ceux-ci peuvent contenir durablement des plans de financement ou de M&A que les fondateurs des sociétés en portefeuille n’ont pas partagés à l’extérieur.

    • Collecter des clés dans le code source public d’une page web est légal et peut être signalé en toute sécurité.
      Mais utiliser ces clés pour accéder à un système sans autorisation est un crime.
      La différence est énorme.
    • Si cela contient des informations sur les LP, les dégâts pourraient aussi être considérables.

  • Le fait que cette société de capital-risque n’ait pas versé de bug bounty pour une faille de sécurité aussi importante n’inspire pas confiance.

  • Les modérateurs de HN ont changé le titre pour quelque chose de moins embarrassant.
    Pas surprenant.

    • Mon commentaire aussi était probablement trop critique envers a16z.
      Son score n’a pas changé, mais il a été déplacé du tout début à tout en bas.
      Il y a décidément bien des façons de fournir une réponse.