Sicherheitslücke in unserem Code melden

Wenn Sie eine Sicherheitslücke in unserem Code oder unserer Infrastruktur entdecken, melden Sie sie an uns. Je nach Komplexität und den möglichen Auswirkungen erhalten Sie eine Prämie von bis zu 10.000 € pro Sicherheitslücke.

Wie kann ich Sicherheitslücken melden?
Welche Sicherheitslücken entsprechen den Qualifizierungskriterien?
Welche Sicherheitslücken entsprechen nicht den Qualifizierungskriterien?
Gibt es Beispiele für konkrete Szenarien, die ich melden kann?
Wie werden Sicherheitslücken klassifiziert?
Welche Prämie erhalte ich?
Wer hat Anspruch auf eine Prämie?
Wer entscheidet über die Gültigkeit eines Sicherheitslückenmeldung?
Wie lange dauert es, bis ich eine Rückmeldung zu einer gemeldeten Sicherheitslücke erhalte?

So melden Sie eine Sicherheitslücke

Wir sind bestrebt, ein starkes Glied in Ihrer Sicherheitskette zu sein, indem wir Ihre Daten und Ihre Kommunikation durch Zero-Knowledge-Verschlüsselung schützen. Aber niemand ist perfekt, auch wir nicht. Deshalb würden wir uns freuen, von Ihnen zu hören, wenn Sie eine Sicherheitslücke in unserem Code oder unserer Infrastruktur entdeckt haben, die unsere Qualifizierungskriterien erfüllt.

Bevor Sie sich an uns wenden, lesen Sie bitte alle Informationen auf dieser Seite und befolgen Sie die Anweisungen.

Wie kann ich Sicherheitslücken melden?

Wir freuen uns auf gut strukturierte Meldungen, die das Problem klar erläutern. Dadurch können wir das Problem reproduzieren und nachvollziehen, und Sie erhalten in kürzerer Zeit höhere Auszahlungen. Für Tipps zum Schreiben von Bug-Bounty-Meldungen empfehlen wir Ihnen die Lektüre dieses Artikels.

Wenn Ihre Meldung fertiggestellt ist, senden Sie ihn bitte an [email protected].

Welche Sicherheitslücken entsprechen den Qualifizierungskriterien?

  • Remote-Codeausführung auf einem unserer Server, einschließlich SQL-Injection-Fehlern
  • Serverseitige Anfragefälschungen (server-side request forgery, SSRF).
  • Remote-Codeausführung auf einem Client-Browser; zum Beispiel durch Cross-Site-Scripting.
  • Alles, was unser kryptographisches Sicherheitsmodell kompromittiert und einen unbefugten Zugriff auf oder Manipulation von Schlüsseln oder Daten über eine Remote-Verbindung ermöglicht.
  • Umgehen von Zugriffskontrollen und Authentifizierungsmechanismen auf eine Weise, die zum unbefugten Überschreiben und Löschen von Schlüsseln oder Benutzerdaten führen kann
  • Jedes Problem, das die Daten eines Benutzeraccounts beim Kompromittieren der zugehörigen E-Mail-Adresse gefährdet

Welche Sicherheitslücken entsprechen nicht den Qualifizierungskriterien?

  • Alles, was eine aktive Benutzerinteraktion erfordert, wie zum Beispiel Phishing- und Social-Engineering-Angriffe
  • Schwache Benutzeraccount-Passwörter
  • Sicherheitslücken, deren Ausnutzung eine große Anzahl von Serveranfragen voraussetzt
  • Angriffe, die einen kompromittierten Client-Rechner voraussetzen
  • Probleme, die durch die Verwendung von nicht unterstützten oder veralteten Client-Browsern entstehen
  • Probleme, die physischen Zugang zu einem Rechenzentrum voraussetzen (siehe unten für begrenzte Szenarien mit kompromittierten Servern).
  • Sicherheitslücken in von Dritten betriebenen Diensten, z. B. von Vertriebspartnern
  • Alle Arten von Überlastungs-, Ressourcenerschöpfungs- und Dienstverweigerungsangriffen (denial of service, DoS).
  • Alle Szenarien, die auf gefälschten SSL-Zertifikaten basieren
  • Alles, was extreme Rechenleistung (2^60 kryptografische Operationen oder mehr) oder einen funktionierenden Quantencomputer erfordert, einschließlich einer vermeintlichen Vorhersagbarkeit von Zufallszahlen (wenn Sie nicht nur allgemeine Vermutungen anstellen, sondern eine konkrete Schwachstelle aufzeigen, könnte Ihr Fehlerbericht trotzdem die Qualifizierungskriterien erfüllen)
  • Alle Fehler oder Probleme, die nicht sicherheitsrelevant sind

Gibt es Beispiele für konkrete Szenarien, die ich melden kann?

Kompromittierter statischer CDN-Knoten (*.static.mega.co.nz)

Nehmen wir an, Sie haben einen unserer Server für statische Inhalte kompromittiert und sind in der Lage, die Dateien (einschließlich des gesamten JavaScript-Codes) zu manipulieren, die über diesen Server bereitgestellt werden. Können Sie dies dazu nutzen, unsere Sicherheit zu kompromittieren?

Hinweis: Die Beeinflussung von Benutzeraktionen durch veränderte Bilddateien ist ausgeschlossen, auch wenn dies in diesem Kontext eine potenzielle Sicherheitslücke darstellt.

Kompromittierter Benutzerspeicher-Knoten (*.userstorage.mega.co.nz)

Nehmen wir an, Sie sind in einen unserer Speicherknoten eingedrungen und können diesen frei manipulieren. Sie wissen, dass Ihr Opfer demnächst eine bestimmte Datei von diesem Knoten herunterlädt, aber Sie kennen den Schlüssel zu dieser Datei nicht. Können Sie den Inhalt der Datei so manipulieren, dass der Download trotzdem ohne Fehler abläuft?

Kompromittierte Kerninfrastruktur (*.api.mega.co.nz)

Dies ist das extremste Szenario. Nehmen wir an, Sie haben den Kern unserer operativen Aktivitäten kompromittiert – unsere API-Server. Können Sie API-Clients dazu bringen, verwendbare Schlüssel für Dateien in Accounts herauszugeben, die keine ausgehenden Freigaben enthalten?

Wie werden Sicherheitslücken klassifiziert?

MEGA klassifiziert Sicherheitslücken nach Schweregrad auf einer Skala von 1 bis 6.

  • Schweregradklasse 6
    Grundlegende kryptografische Designfehler, die generell ausnutzbar sind
  • Schweregradklasse 5
    Remote-Codeausführung auf zentralen MEGA-Servern, wie z. B. API, Datenbanken und Root-Cluster, oder schwerwiegende Umgehung von Zugriffskontrollen.
  • Schweregradklasse 4
    Kryptografische Designfehler, die nur nach einer Kompromittierung der Serverinfrastruktur ausgenutzt werden können, entweder live oder post-mortem.
  • Schweregradklasse 3
    Generell ausnutzbare Remote-Codeausführung auf Client-Browsern (Cross-Site-Scripting).
  • Schweregradklasse 2
    Cross-Site-Scripting, das nur ausgenutzt werden kann, nachdem der API-Servercluster kompromittiert oder ein Man-in-the-Middle-Angriff durchgeführt wurde, z. B. durch Ausstellung eines gefälschten TLS/SSL-Zertifikats mit zusätzlicher DNS/BGP-Manipulation.
  • Schweregradklasse 1
    Alle weniger schwerwiegenden oder rein theoretischen Schwachstellen-Szenarien.

Welche Prämie erhalte ich?

Je nach Komplexität und den möglichen Auswirkungen beträgt die Prämie bis zu 10.000 Euro pro Sicherheitslücke.

Für qualitativ hochwertige Fehler- und Sicherheitslückenmeldungen, die gut strukturiert und mit einem Proof-of-Concept dokumentiert sind, wird eine Belohnung am oberen Ende der jeweiligen Schweregradklasse ausgezahlt.

Wer hat Anspruch auf eine Prämie?

Die erste Person, die eine durch MEGA reproduzierbare und verifizierbare Sicherheitslücke meldet, erhält eine Prämie.

Wer entscheidet über die Gültigkeit eines Sicherheitslückenmeldung?

Die Entscheidung darüber, ob Ihre Meldung unsere Qualifizierungskriterien erfüllt und wie hoch die Prämie ausfällt, liegt in unserem Ermessen. Wir sind zwar bestrebt, fair und großzügig vorzugehen, aber durch das Einreichen eines Fehlerberichts erkennen Sie die Endgültigkeit unserer Entscheidung an.

Wie lange dauert es, bis ich eine Rückmeldung zu einer gemeldeten Sicherheitslücke erhalte?

Wir bemühen uns, Berichte innerhalb weniger Tage nach Erhalt zu beantworten. Wenn Sie innerhalb dieses Zeitraums nichts von uns hören, könnte dies daran liegen, dass Ihr Bericht fehlerhaft ist oder nicht genügend Details enthält, um angemessen geprüft zu werden. Bitte schreiben Sie eine weitere E-Mail, wenn Sie sich sicher sind, dass Ihr Bericht vollständig und korrekt ist.

Richtlinien für eine verantwortungsvolle Offenlegung

Bitte halten Sie sich an die branchenüblichen Richtlinien für die verantwortungsvolle Offenlegung von Sicherheitslücken, die eine Frist von 90 Tagen ab dem Zeitpunkt vorsehen, zu dem die gemeldete Sicherheitslücke verifiziert und bestätigt wurde, um uns genügend Zeit zu geben, etwaige Korrekturen zu testen und bereitzustellen.