Forscher entdeckt, dass Schwachstelle auf a16z-Website einige Unternehmensdaten offengelegt hat

 (kibty.town)
1 Punkte von GN⁺ 2024-07-21 | 1 Kommentare | Auf WhatsApp teilen
  • Ein Sicherheitsforscher entdeckte, dass auf der a16z-bezogenen Subdomain portfolio.a16z.com die gesamte process.env einer Heroku-Instanz dynamisch in JavaScript eingebunden war
  • Zu den offengelegten Werten gehörten mehrere Service-Zugangsdaten, darunter DATABASE_URL, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, SALESFORCE_CLIENT_SECRET, OKTA_CLIENT_SECRET und MAILGUN_API_KEY
  • Der Forscher erklärte, er habe bei einer routinemäßigen Prüfung mit lunchcat auf Secrets in JS-Dateien einen Verweis auf AWS-Keys entdeckt; die Bestätigung sei allein über den Sources-Tab der Browser-Entwicklertools möglich gewesen
  • Der potenzielle Einflussbereich umfasste eine Datenbank mit PII, AWS, Salesforce und Mailgun; bei Mailgun sei es möglich gewesen, beliebige E-Mails von a16z-Domains zu versenden und frühere E-Mails zu lesen, so die Behauptung
  • a16z zahlte keine Bug Bounty, mit der Begründung, der Forscher habe öffentlich Kontakt aufzunehmen versucht; der Forscher sagte, auf der Hauptwebsite gebe es keine Kontaktangaben und die gefundene E-Mail-Adresse sei unzustellbar gewesen

Bei Subdomain-Prüfung offengelegte Umgebungsvariablen

  • Der Forscher erklärte, er finde Ziele, indem er Unternehmen auf Twitter ausfindig mache und anschließend schnelle Penetrationstests durchführe; häufig nutze er dabei den Tab Relevant People
    • Der Weg führte diesmal von einem Unternehmen aus dem Bereich crypto → Krypto-Venture-Capital → a16z crypto → a16z
  • Im Zuge der Untersuchung von a16z führte er ein übliches Subdomain-Scanning durch und nutzte das Tool lunchcat, um Domains zu prüfen und Secrets in JS-Dateien zu finden
  • portfolio.a16z.com wirkte wie ein Portfolio-Management-Tool für Unternehmen, die zu a16z gehören; bei der Prüfung wurde irgendwo auf der Website ein Verweis auf AWS-Keys erkannt
  • Im JavaScript waren dynamisch Werte eingebunden, die offenbar der gesamten process.env einer Heroku-Instanz entsprachen
    • Zu den enthaltenen Einträgen gehörten 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, HEROKU_POSTGRESQL_CRIMSON_URL und weitere
    • Der Forscher überprüfte die Zugangsdaten rasch und erklärte, sie wirkten nicht wie Attrappen, sondern wie echte Zugangsdaten
    • Der Zugriff habe lediglich darin bestanden, in den Browser-Entwicklertools den Sources-Tab zu öffnen

Möglicher Umfang der Offenlegung und Streit um Bug Bounty

  • Die vom Forscher aufgelisteten potenziell kompromittierbaren Services waren folgende
    • Datenbank: enthielt nach seinen Angaben PII
    • AWS: ein möglicher Zugriff über die offengelegten Keys wurde erwähnt
    • Salesforce: nicht direkt überprüft; er ergänzte, dass die Kontoberechtigungen eingeschränkt sein könnten
    • Mailgun: darüber hätten beliebige E-Mails von a16z-Domains gesendet und auch frühere E-Mails gelesen werden können, so seine Aussage
    • Er erwähnte außerdem, dass es noch weitere geben könnte
  • a16z zahlte keine Bug Bounty, weil der Forscher nicht vertraulich Kontakt aufnahm, sondern öffentlich versuchte, Kontakt herzustellen
  • Der Forscher nannte zwei Gründe für die öffentliche Kontaktaufnahme
    • Auf der Hauptwebsite von a16z konnte er keine nutzbaren Kontaktangaben finden
    • E-Mails an die auffindbare Adresse wurden zurückgesendet
  • Als zugehöriger Beitrag ist ein TechCrunch-Artikel angehängt; demnach nahm Lorenzo Kontakt auf, nachdem er den Tweet gesehen hatte, mit dem der Forscher a16z zu erreichen versuchte, und schrieb den Artikel

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-07-21
Hacker-News-Kommentare

  • Als wir unser Open-Source-Projekt(https://github.com/heyPuter/puter/) veröffentlicht haben, hat Eva ziemlich umfangreiche Penetrationstests durchgeführt und den Bericht zur Schwachstelle sehr professionell abgewickelt.
    Damals gab es nicht einmal ein Bug-Bounty-Programm, trotzdem hat sie keine Belohnung verlangt, und Eva ist eine großartige und verantwortungsbewusste Hackerin, also sollte a16z sie besser behandeln.

  • Ich habe einmal einen ähnlichen Fehler gemacht.
    Ich habe das Node.js-CMS apostrophecms benutzt und die global settings im Admin-Panel verwendet, um API-Schlüssel des Authentifizierungsservers zu verwalten, und erst Monate später gemerkt, dass diese Werte im HTML-Quellcode ausgegeben wurden.
    Das war so gebaut, damit es in JavaScript verwendet werden kann, und es stand auch in der Dokumentation, daher gebe ich ihnen nicht die Schuld, wir haben das einfach schlampig übersehen.
    Noch ärgerlicher ist, dass wir für viel Geld einen Penetrationstest von einer großen Beratung bekommen haben und selbst die es nicht entdeckt haben; am Ende haben wir es selbst gefunden und nach Prüfung der Logs sah es nicht nach einer Ausnutzung aus, aber es war ein ziemlich schockierendes Leak.

    • Für diesen Penetrationstest würde ich zumindest eine Rückerstattung verlangen.
      Die Penetrationstests, die ich bisher gesehen habe, waren nie mehr als Checkbox-Abhaken.
    • Es tut mir wirklich leid, dass du bei ApostropheCMS eine unerwartete Offenlegung erlebt hast.
      Wie du gesagt hast, war diese Art der Datenweitergabe in der Dokumentation beschrieben, aber trotzdem kann sie überraschen.
      Für Leute, die das später nachlesen: Die aktuell unterstützten Hauptversionen von Apostrophe funktionieren nicht mehr so.
      Daten werden nicht mehr in ein ausgeloggtes Frontend injiziert, außer ein Entwickler entscheidet sich ausdrücklich dafür; das wurde geändert, um genau solche Überraschungen zu vermeiden.
      Es gibt allerdings weiterhin Anwendungsfälle, in denen ein API-Schlüssel in den Einstellungen bestimmter Widgets und in Teilen des Inhalts enthalten sein muss.
      Zur Einordnung: Ich bin Design Lead bei Apostrophe und übernehme auch Engineering-Aufgaben.
    • Ich frage mich, warum du ein webbasiertes Content-Management-System zur Verwaltung von Geheimnissen verwendet hast.
    • Bearbeitung: Ich will apostrophe cms nicht die Schuld geben.
      Diese Situation entstand wegen unserer Multi-Tenant-Konfiguration und weil wir apostrophe nicht gut genug verstanden haben.
    • Du sagst zwar: „Es stand in der Dokumentation, also mache ich ihnen keinen Vorwurf. Wir haben es schlampig übersehen“, aber man sollte ihnen trotzdem die Schuld geben.
      Gefährliches Verhalten zu dokumentieren befreit nicht von Verantwortung, und ich würde sagen, diese Lektion sollte inzwischen allgemein bekannt sein.

  • Wenn man einen neuen Service baut und per ACME ein LetsEncrypt-Zertifikat auf den Server legt, füllen sich die Logs sofort mit Müllanfragen.
    Man sieht ganz offensichtlich Bots, die nach nachlässigen Standardwerten suchen, die Entwickler offengelassen haben könnten, und ich habe sogar schon Anfragen nach Prozess-Umgebungsdateien gesehen.
    Ich weiß nicht, wie so eine Schwachstelle nicht entdeckt oder ausgenutzt worden sein soll; entweder hatte a16z sehr viel Glück, oder sie wurde bereits ausgenutzt und nur nicht offengelegt.
    Wahrscheinlich hat sich einfach ein gutwilliger Forscher oder ein gelangweilter Mensch mit White-Hat-Mentalität zuerst gemeldet, und es ist bedauerlich, dass es für solche Nachlässigkeit keinen rechtlichen Rahmen gibt, aber ich finde, a16z sollte eine hohe Geldstrafe bekommen.

    • „Wie kann so eine Schwachstelle nicht entdeckt oder ausgenutzt worden sein?“
      Vielleicht wurde sie es schon.
      Möglicherweise war es wertvoller, sie offen zu lassen, als einfach etwas kaputtzumachen.
    • Fairerweise wirkt die Hauptseite selbst nicht besonders interessant.
      Einige Zugangsdaten wie etwa für OKTA sehen allerdings ziemlich riskant aus.

  • Der Teil „Wir haben keine Bug Bounty gezahlt, weil der Kontakt öffentlich erfolgte. Der Grund dafür war, dass es auf der Hauptseite keine Kontaktmöglichkeit gab und die gefundene Adresse engineering@a16z.com unzustellbar war“ wirkt wie ein cleverer Lifehack, um Firmengeld zu sparen.
    Wenn man jede Möglichkeit entfernt, das Engineering-Team privat zu kontaktieren, laufen alle Bug-Bounty-Meldungen öffentlich ab, und dann muss man nichts zahlen.

    • Schon auf mehrere Arten clever.
      Wahrscheinlich wurde auch bei der Entwicklung brutal gespart, indem man Leute über so etwas wie fiverr ausgequetscht hat, und wenn eine russische Ransomware-Gruppe sie mühelos ausräumt, spart das indirekt bestimmt auch viele Buchhaltungskosten.
    • Aber beim nächsten Mal bringt man Sicherheitsforschern damit bei, diese Informationen nicht zu melden, sondern zu verkaufen.
    • Ein Unternehmen muss keinen zusätzlichen „Hack“ veranstalten, um kein Geld zahlen zu müssen.
      Wenn es kein öffentliches Bug-Bounty-Programm gibt, schuldet es niemandem etwas.
      Außerdem steht unten auf https://a16z.com/connect eine Kontakt-E-Mail-Adresse, die der Forscher praktischerweise übersehen hat.
      Es wirkt eher so, als habe er auf Aufmerksamkeit aus gewesen statt auf verantwortungsvolle Offenlegung.
    • Wenn sich so etwas wiederholt, spricht sich herum, dass dort keine Bounties gezahlt werden, und dann sinkt auch die Wahrscheinlichkeit, dass Leute gefundene Probleme melden.
    • Wenn jemand auf HN gefragt hätte, wie man a16z Engineering kontaktieren kann, hätte das wohl ziemlich gut funktioniert.

  • Wenn Unternehmen sagen, sie seien „gehackt worden“, klingt das inzwischen wie eine Unternehmensformulierung für: „Wir haben wichtige Zugangsdaten nicht richtig geschützt, aber bitte schiebt die Verantwortung auf einen namenlosen Akteur, den wir ‚Hacker‘ nennen.“

    • Wenn man versehentlich die Haustür sperrangelweit offen lässt und jemand alles mitnimmt, würde man trotzdem sagen, dass man „bestohlen wurde“.
      Es gibt rechtliche Unterscheidungen wie „Einbruch“, „Diebstahl“ oder „Hausfriedensbruch“, und ob die Tür offen war, kann die Rechtswidrigkeit oder das Strafmaß beeinflussen, aber in der Alltagssprache wurde man trotzdem bestohlen.

  • Nicht einmal eine symbolische Summe als Bounty für so ein weit offenes Loch zu zahlen, ist ziemlich erbärmlich.

    • Wenn beim nächsten Mal jemand ihre Schlüssel findet, sieht diese Person vielleicht diesen Beitrag und lädt sie statt einer Meldung einfach in ein öffentliches GitHub-Repository hoch.

  • Sie sind wohl zu beschäftigt damit, riesige Whitepaper über generative KI-Architekturen zu schreiben.
    Geben wir ihnen also etwas Ruhe, sie träumen schließlich von einer zukünftigen Agentenwelt, in der halbfertige Chatbots herumlaufen.
    Während die Welt wegen kaputter Software-Updates brennt.

    • Die Welt brennt schon wegen der Auswirkungen des Klimawandels.
      Das kaputte Software-Update vom Freitag war nur noch das Tüpfelchen auf dem i.
    • „engineering@a16z.com war unzustellbar“
      Überhaupt nicht überraschend.

  • Wenn man tatsächlich Zugriff auf die Salesforce-Instanz hatte, wäre das aus Sicht eines Gründers sehr beunruhigend gewesen.
    In so etwas wie Salesforce werden E-Mails typischerweise protokolliert, und darin könnten ständig Finanzierungspläne oder M&A-Pläne von Gründern der Portfoliounternehmen stehen, die nicht extern geteilt wurden.

    • Schlüssel aus dem öffentlichen Quellcode einer Webseite zu sammeln, ist legal und kann sicher gemeldet werden.
      Mit diesen Schlüsseln auf nicht autorisierte Systeme zuzugreifen, ist jedoch eine Straftat.
      Dieser Unterschied ist sehr groß.
    • Wenn LP-Informationen enthalten wären, könnte auch das ein ziemlich großer Schaden sein.

  • Dass diese VC-Firma für so ein großes Sicherheitsloch keine Bug Bounty gezahlt hat, schafft kein Vertrauen.

  • Die HN-Moderation hat den Titel in etwas weniger Peinliches geändert.
    Nicht überraschend.

    • Mein Kommentar war wohl auch zu kritisch gegenüber a16z.
      An der Punktzahl hat sich nichts geändert, aber er wurde vom obersten an den untersten Platz verschoben.
      Es gibt wirklich viele Arten, eine Reaktion zu liefern.