Snyk Vulnerability-Disclosure-Programm: Was passiert hinter den Kulissen?

Bei Snyk sind wir fest davon überzeugt, dass die Open-Source-Community geschützt werden muss. Deshalb haben wir unser Programm zur verantwortungsvollen Offenlegung von Sicherheitslücken ins Leben gerufen. Es unterstützt bei allen Sicherheitslücken in verwalteten Open-Source-Paketen und in Programmiersprachen wie JavaScript, Java, Python, .NET, Go, Ruby und PHP.

Warum Sicherheitslücken an Snyk melden?

Mit unserer Praxis zur Offenlegung von Sicherheitslücken möchten wir bei Snyk die Lücke zwischen Forschenden und Maintainer:innen schließen und einige der Herausforderungen und Schwierigkeiten im Zusammenhang mit verantwortungsvollen Offenlegungen verringern – wie wir bereits in einem früheren Blogbeitrag erläutert haben.

Wie schließen wir diese Lücke? Wird Snyk eine neue Sicherheitslücke gemeldet, geht die Meldung direkt an unser Sicherheitsteam, das sie prüft und verifiziert. Als Unternehmen, bei dem Entwickler:innen im Mittelpunkt stehen, verfolgen wir einen Ansatz, der auch die Perspektive der Maintainer berücksichtigt. Von Anfang bis Ende pflegen wir einen offenen, gegenseitigen Austausch (gemäß unserer Richtlinie zur Offenlegung von Sicherheitslücken). Wir möchten beide Perspektiven verstehen und letztlich eine Entscheidung treffen, die sowohl von den Maintainer:innen akzeptiert wird als auch angesichts unserer Erfahrung und Expertise die verantwortungsvollste ist. Dabei versuchen wir, alle Faktoren zu berücksichtigen – etwa den Kontext des Pakets, den Schweregrad, die Wahrscheinlichkeit einer Ausnutzung und mehr.

Snyk ist außerdem eine CNA (CVE Numbering Authority) und kann daher CVE-IDs für gemeldete Sicherheitslücken vergeben. Sobald ein Fix veröffentlicht wurde (oder alternativ, wenn innerhalb von 50 Tagen keine Antwort eingegangen ist), vergeben wir eine CVE-ID für die Sicherheitslücke und veröffentlichen eine öffentliche Warnmeldung. Eine CVE-ID für eine Sicherheitslücke ist entscheidend: Sie sorgt dafür, dass das gesamte Ökosystem davon erfährt und Entwickler:innen sowie Unternehmen entsprechend handeln können, um ihren Code zu schützen.

Während des gesamten Prozesses informieren wir die Person, die die Sicherheitslücke ursprünglich gemeldet hat, regelmäßig über den aktuellen Stand. Noch wichtiger: Sie wird für ihren wertvollen Fund gewürdigt.

Bisher hat unser Programm verantwortungsvoll 88 Sicherheitslücken offengelegt, die von verschiedenen externen Forschenden gemeldet wurden. Sehen wir uns einen solchen Fall an.

Fallstudie: Zusammenarbeit mit der Johns Hopkins University

Vor Kurzem haben wir mit Forschenden der Johns Hopkins University an der Offenlegung von 57 Sicherheitslücken in großem Umfang gearbeitet.

Im Rahmen ihrer Abschlussarbeit entwickelte das Team der Johns Hopkins University eine neuartige Methode, um Sicherheitslücken automatisiert zu finden:

„Wir schlagen ein neuartiges Konzept namens Object Property Graph (OPG) vor, das die Wechselwirkungen zwischen JavaScript-Objekten erfasst und die Erkennung von JavaScript-Sicherheitslücken erleichtert. Ein OPG stellt sämtliche Informationen zu Objektnamen – etwa Variablennamen und Eigenschaften, Objektbereiche und die Objekte selbst – als Knoten in einer graphartigen Struktur dar. So lässt sich der Graph durchlaufen, um ein Objekt während der Ausführung aufzulösen. OPGs bieten zwei wesentliche Funktionen: (i) Sie erleichtern die Erstellung eines besseren, also präziseren CFG und DFG, wenn ein unbekanntes Objekt aufgelöst werden muss, und (ii) sie bilden die Wechselwirkungen zwischen Objekten ab, sodass sich diese auf bestimmte Sicherheitslückenmuster hin abfragen lassen.

Wir haben ein Framework namens OPGen entwickelt und implementiert, das während einer sogenannten simulierten Ausführung OPGs für Node.js-Anwendungen generiert. Mit OPGen haben wir vier Arten von Sicherheitslücken in Node.js erkannt: Command Injection, Prototype Pollution, beliebige Codeausführung und Path Traversal.

Auf dem Code Property Graph (CPG) bauen wir zusätzliche Objektknoten und die dazugehörigen Kanten auf. Dazu führen wir eine simulierte Ausführung des Codes durch und prüfen, ob ein Datenfluss von der Benutzereingabe ausgeht und die Sink-Funktionen erreichen kann.“

- Song Li, JHU Security Labs

Das Team kontaktierte uns anschließend über das Formular zur Offenlegung von Sicherheitslücken. Wir antworteten mit der Einladung zu einem Videoanruf, um die Art und den Umfang der Funde zu besprechen und zu klären, wie wir das Team unterstützen können.

Nachdem wir das Ausmaß der Offenlegung verstanden hatten, richteten wir ein gemeinsames privates Repository ein, in dem das Team weitere Funde hinzufügen konnte. Das Team übermittelte uns den Typ der Sicherheitslücke, die betroffenen Pakete und Versionen, einen POC sowie einen Verweis auf den anfälligen Code. Alle Angaben erfolgten in einem einheitlichen Format, das in eine speziell für unsere internen Systeme entwickelte Pipeline eingespeist wurde. So konnten wir den großen Umfang der Offenlegung effektiv bewältigen.

Mit einem eigens entwickelten internen Tool verifizierten wir die relevanten POCs. Anschließend prüften wir die Meldungen vollständig und arbeiteten mit den zuständigen Maintainer:innen zusammen, um die Sicherheitslücken verantwortungsvoll offenzulegen.

Bis heute haben wir aus dieser Zusammenarbeit über 55 Sicherheitslücken veröffentlicht. Zu den Arten der Sicherheitslücken zählen Command Injection, Path Traversal, Prototype Pollution und Codeausführung. Beispiele hierfür sind SNYK-JS-BLAMER-559541, SNYK-JS-BODYMEN-548897 und SNYK-JS-PULVERIZR-560122.

Wir arbeiten weiterhin eng mit dem Team der JHU Security Labs an neuen Funden und noch nicht veröffentlichten Sicherheitslücken zusammen.

Wie können Sie loslegen?

Ein wichtiger erster Schritt ist, unsere Richtlinie zur Offenlegung von Sicherheitslücken zu lesen.

Anschließend reichen Sie Ihren Bericht am besten über das eigens dafür vorgesehene Meldeformular ein.

Bitte machen Sie möglichst ausführliche Angaben, insbesondere zu folgenden Punkten:

• Beschreibung des Problems

• Schritte zur Reproduktion (oder ein Proof of Concept)

• Kontaktdaten – damit wir wissen, wem wir Anerkennung aussprechen und wen wir kontaktieren können, falls wir weitere Informationen benötigen.

Alternativ können Sie uns auch eine E-Mail an report@snyk.io senden. Bitte machen Sie auch hier möglichst ausführliche Angaben.