Warum vertrauen Unternehmen Snyk im Kampf für Open-Source-Sicherheit?

Die Rolle eines eigenen Security-Teams zu definieren und zu erklären, das Schwachstellen in Open-Source-Ökosystemen erforscht und analysiert, um die Sicherheit von Open Source zu gewährleisten, ist keine leichte Aufgabe. Eine knappe Antwort auf die scheinbar einfache Frage „Was macht das Security-Team bei Snyk?“ zu geben, ist eine Herausforderung. Es gibt keine kurze Antwort darauf, womit wir uns genau beschäftigen und worauf wir uns in unserem Fachgebiet spezialisiert haben.

Das Problem liegt meiner Meinung nach darin, dass die Bezeichnungen „Researcher“ und „Analyst“ im Allgemeinen und „Security Analyst“ oder „Security Researcher“ im Besonderen zu den am häufigsten missbrauchten und überstrapazierten Titeln seit „Consultant“ gehören. Sie können buchstäblich alles bedeuten, und jedes Unternehmen scheint eine ganz eigene Definition davon zu haben, was sein Security Research Team macht (sofern es überhaupt eines hat).

Wahrscheinlich werde ich das Problem, Menschen außerhalb der Arbeit zu erklären, was ich tue, nicht vollständig lösen können. Dieser Blog ist aber zumindest ein Versuch, das Problem zu minimieren und ein für alle Mal zu erläutern, was das großartige Security Research Team bei Snyk macht.

Folgende Themen behandeln wir in diesem Artikel:

• Unsere Mission

• Unsere Methoden

  • Strukturierte Datenbanken von Community-Ökosystemen

  • Unstrukturierte Datenbanken und Sicherheitshinweise

  • Unveröffentlichte Schwachstellen aufspüren

  • Meldungen aus der Community und Wissenschaft

  • Eigene Forschung und Analyse von Schwachstellentrends

• Zusammenfassung

Unsere Mission

Die Mission von Snyk ist es, die Open-Source-Welt sicherer zu machen und Entwickler dabei zu unterstützen, aktiv zur Absicherung ihrer Codebasen beizutragen. Eine der wichtigsten Maßnahmen dafür ist, die von unseren Nutzerinnen und Nutzern verwalteten Open-Source-Bibliotheken und Container-Images auf Schwachstellen zu prüfen. Wir stellen ihnen möglichst genaue und umsetzbare Informationen zu den gefundenen Schwachstellen bereit und bieten ihnen außerdem die Möglichkeit, die Probleme zu beheben.

Das Security Research Team hat die Aufgabe, die Snyk Intel Vulnerability Database zusammenzutragen und zu pflegen. Sie bildet die Grundlage für unsere Scans und stellt Nutzerinnen und Nutzern Informationen bereit, mit denen sie Schwachstellen beheben können, bevor daraus Sicherheitsbedrohungen werden.

Der Aufbau und die Pflege einer erstklassigen Sicherheitsdatenbank sind anspruchsvoll. Dafür müssen wir nicht nur an der Genauigkeit der Daten arbeiten, sondern auch an der Breite und Tiefe unserer Datenbank. Am einfachsten lässt sich erklären, wie wir dabei vorgehen, wenn wir Ihnen zeigen, wie wir Schwachstellen für die Datenbank beschaffen, verifizieren und triagieren.

Unsere Methoden

Um eine kontinuierliche Abdeckung von Open-Source-Sicherheitsproblemen sicherzustellen, setzen wir verschiedene Methoden ein:

1. Strukturierte Datenbanken von Community-Ökosystemen

Die naheliegendste Quelle für Schwachstellen in Open-Source-Ökosystemen sind von der Community betriebene Datenbanken wie rubysec, friends of php, rustsec und viele andere. Sie werden von Open-Source-Entwicklern gepflegt, die innerhalb des jeweiligen Ökosystems arbeiten und versuchen, möglichst umfassend über die dort verbreiteten Sicherheitsprobleme zu informieren.

Das Snyk Security Research Team verfolgt diese von der Community betriebenen Datenbanken aktiv, um über neue Community-Meldungen zu Schwachstellen auf dem Laufenden zu bleiben. Trotz der hervorragenden Arbeit der Community, die Nutzerinnen und Nutzer im Ökosystem über diese Schwachstellen informiert, ist jedoch oft noch zusätzliche, notwendige Arbeit zu leisten.

Das Security Research Team verifiziert und analysiert jede gemeldete Schwachstelle zusätzlich, um:

1. zu verifizieren, dass es sich tatsächlich um eine Schwachstelle handelt – dazu untersuchen wir die gemeldete Schwachstelle und erstellen bei Bedarf Proofs of Concept, um zu überprüfen, ob sie tatsächlich ausnutzbar ist.

2. eine vollständige und genaue Beschreibung der Schwachstelle einschließlich ihres Schweregrads und CVSS-Scores zu erstellen – durch eine eingehende Untersuchung können wir ihre spezifischen wahrscheinlichen Auswirkungen und Angriffsvektoren sowie die wahrscheinliche Verwendung des anfälligen Pakets im Ökosystem besser verstehen. Auf Grundlage dieser Erkenntnisse erstellen wir eine Beschreibung und einen Sicherheitshinweis zum Schweregrad, damit Entwickler die Schwachstelle und ihre möglichen Auswirkungen auf ihre Codebasis bestmöglich verstehen.

3. zu prüfen, ob wichtige Metadaten wie behobene Versionen und betroffene Pakete vollständig und korrekt sind – wir untersuchen die Codebasis des Pakets und ermitteln genau, welche Codeänderungen die Schwachstelle eingeführt und welche sie behoben haben. Anschließend gleichen wir diese Informationen mit dem genauen Paketnamen und den Versionen ab, um sicherzustellen, dass wir nur tatsächlich anfällige Pakete und Versionen als betroffen kennzeichnen.

4. die anfälligen Funktionen oder Klassen innerhalb eines Pakets zu identifizieren – bei der Triage einer Schwachstelle ermitteln wir genau, welche Funktion oder Funktionen im Paket anfällig sind. Anhand dieser Metadaten können Entwickler erkennen, ob ihre konkrete Verwendung des Pakets anfällig ist.

5. bekannt gewordene Exploits dieser Schwachstelle in freier Wildbahn laufend zu beobachten und zu triagieren – auch nach Veröffentlichung einer Schwachstelle müssen wir verfolgen, ob weitere Informationen dazu bekannt werden, insbesondere wenn ein ausgereifter Exploit-Vektor veröffentlicht wird. Wir überwachen verschiedene Quellen, um Exploits unmittelbar nach ihrer Veröffentlichung zu erkennen, und triagieren sie, damit wir den Reifegrad des Exploits einschätzen können und Entwickler wissen, wie sie die Behebung dieser Schwachstellen priorisieren sollten.

2. Unstrukturierte Datenbanken und Sicherheitshinweise

Strukturierte Datenbanken innerhalb der Ökosysteme sind hilfreich. Doch auch unstrukturierte Datenbanken und öffentliche Sicherheitshinweise enthalten eine Fülle von Informationen zu neuen Schwachstellen. Deshalb ist es entscheidend, auch solche Quellen zu verfolgen und zu triagieren.

Das offensichtlichste Beispiel hierfür sind die CVE- und NVD-Datenbanken, in denen viele Schwachstellen in einem unstrukturierten, maschinenunlesbaren Format erfasst sind. Neben CVE und NVD gibt es unzählige einzelne Produkthinweise und Mailinglisten wie die Apache Mailing List, Node.JS update blogs, Jenkins’ Security Advisories und viele weitere, die wir alle im Blick behalten müssen.

Das Team muss hier selbstverständlich dieselben Maßnahmen ergreifen wie im vorherigen Abschnitt beschrieben. Zusätzlich müssen die Daten in ein maschinen- und menschenlesbares Format überführt werden. So wird in der NVD oder der Apache Mailing List vielleicht gemeldet, dass eine Schwachstelle beispielsweise „Apache Tomcat“ betrifft. Entwickler müssen jedoch wissen, ob das konkrete Paket, das sie verwenden, anfällig ist – und zwar unter den 958 verschiedenen Paketen mit Bezug zu „Apache Tomcat“, die derzeit in Maven verfügbar sind.

Durch eingehende Untersuchungen der anfälligen Codebasis kann das Team die Parameter des anfälligen Codes ermitteln. Anschließend nutzen wir interne Tools, um Pakete zu scannen, die wahrscheinlich mit dieser Schwachstelle zusammenhängen, und zu prüfen, ob der anfällige Code darin enthalten ist. Erst wenn wir bestätigt haben, dass der anfällige Code vorhanden und relevant ist, ordnen wir die Schwachstelle einem bestimmten Paket zu. Diese Arbeit reduziert die Zahl falsch positiver Meldungen in unserer Datenbank erheblich. So können sich Entwickler, die Snyk nutzen, auf die Behebung von Schwachstellen konzentrieren, anstatt sich mit irrelevanten Meldungen aufzuhalten.

3. Unveröffentlichte Schwachstellen aufspüren

Bis hierhin habe ich vor allem beschrieben, wie das Team dabei hilft, bekannte Schwachstellen zu triagieren und für Entwickler besser nutzbar zu machen – eine wichtige Aufgabe für sich. Darüber hinaus stärkt das Team die Sicherheit in Open-Source-Ökosystemen, indem es noch nicht offengelegte Schwachstellen identifiziert.

Gemeinsam mit unserem Data Team haben wir verschiedene Machine-Learning-Algorithmen entwickelt, mit denen wir sogenannte „Half-Day“-Schwachstellen aufspüren. Dabei handelt es sich um Schwachstellen, die möglicherweise in verschiedenen öffentlichen Foren diskutiert, aber noch nicht offiziell offengelegt wurden.

Es ist allgemein bekannt, dass diese Schwachstellen oft besonders gefährlich sind. Zwischen der Diskussion über eine Schwachstelle und ihrer offiziellen Bestätigung, nach der die Öffentlichkeit Maßnahmen zur Behebung ergreifen kann, liegt ein Zeitfenster, in dem böswillige Akteure ihren Wissensvorsprung über die Schwachstelle ausnutzen können.

Wir helfen, diese Lücke zu schließen, indem wir neu entdeckte Schwachstellen sehr früh in ihrem Lebenszyklus aufspüren und Nutzerinnen und Nutzer darüber informieren. Dazu beobachten wir Quellen, in denen Code-Korrekturen, Fehlerberichte und potenzielle Schwachstellen häufig in einem frühen Stadium diskutiert werden – etwa Pull Requests und Issues in Quellcode-Repositories, JIRA-Tickets oder Websites wie Reddit und StackOverflow.

Dank unserer bestehenden, sorgfältig zusammengestellten Datenbank mit anfälligen Codeausschnitten, Fehlerberichten und Schwachstellenbeschreibungen verfügen wir über eine breite Grundlage für unsere Machine-Learning-Logik. Unsere Systeme können daher Tausende von Ereignissen über alle Pakete in den von uns unterstützten Ökosystemen hinweg verarbeiten und das Team auf potenzielle Schwachstellen hinweisen. Insgesamt glauben wir, einen der derzeit umfassendsten verfügbaren Alert-Feeds aufgebaut zu haben.

Diese Alerts werden in das Frühwarnsystem des Teams eingespeist und anschließend vom Team triagiert. Ein Analyst wertet die Informationen im Alert aus. Falls nötig, verifizieren wir die Schwachstelle mit einem Proof of Concept und wenden uns anschließend an die Maintainer des Pakets, um ihre Einschätzung zur potenziellen Schwachstelle einzuholen.

Nach der Abstimmung mit den Maintainerinnen und Maintainer und der Verifizierung der Schwachstelle veröffentlichen wir sie in unserer Datenbank. So wird das gesamte Ökosystem auf das Sicherheitsproblem aufmerksam und kann es beheben. Allein im vergangenen Jahr haben wir auf diese Weise bei der Offenlegung von rund 200 Schwachstellen geholfen, darunter die Command Injection in Vizion sowie der Timing-Angriff auf die beliebten Pakete Escada und Elliptic.

4. Meldungen aus der Community und Wissenschaft

Die koordinierte Offenlegung von Schwachstellen ist ein in der Cybersicherheit häufig verwendetes Verfahren. Dabei werden Zero-Day-Schwachstellen zunächst vertraulich gemeldet. So erhalten Code- und Anwendungs-Maintainer genügend Zeit, einen Fix oder Patch bereitzustellen, bevor die Schwachstelle schließlich öffentlich bekannt gemacht wird. Andernfalls würden wir die Sicherheit der Endnutzer gefährden. Wie immer kommt es auf die richtige Balance an: Ziel ist es, sowohl die Dauer der vertraulichen Behandlung einer Schwachstelle als auch die Zeit zu minimieren, in der die Anwendung ohne Fix anfällig bleibt.

Snyk hat sein Programm zur Meldung von Schwachstellen 2019 gestartet, um diese Lücke zu schließen und Forschenden eine einfache Möglichkeit zu bieten, Schwachstellen zu melden – selbstverständlich unter voller Anerkennung ihrer Arbeit bei der Entdeckung.

Unser Security-Team prüft jeden einzelnen Schwachstellenbericht sorgfältig. Dafür braucht es spezifisches Wissen und Verständnis sowohl für die jeweilige Programmiersprache als auch für das Paket und seinen Kontext. Sobald die Details der Schwachstelle verifiziert sind, arbeitet das Team eng mit den Maintainerinnen und Maintainer zusammen, damit die Schwachstelle zeitnah behoben wird.

Als CVE Numbering Authority (CNA) unterstützen wir schließlich bei der Vergabe einer CVE-ID und der Veröffentlichung eines ausführlichen Sicherheitshinweises. 2019 haben wir bei der Offenlegung von über 130 Schwachstellen geholfen. Zu den bemerkenswerten Beispielen zählen RCE in mongo-express und Arbitrary File Write in yarn.

Wir arbeiten mit unabhängigen Forschenden, Sicherheitsexpertinnen und -experten sowie der akademischen Community zusammen, um Sicherheitslücken offenzulegen. Einzelne Forschende nutzen unser Offenlegungsprogramm, um einzelne oder mitunter mehrere Sicherheitslücken in Paketen zu melden. Akademische Forschende, die neue Arten von Sicherheitslücken melden möchten, wenden sich dagegen an Snyk, um über unser Offenlegungsprogramm zahlreiche Sicherheitslücken im gesamten Ökosystem offenzulegen. Anfang 2020 starteten wir eine große Partnerschaft mit dem Security-Lab-Team der Johns Hopkins University. Gemeinsam halfen wir dabei, mehr als 60 Sicherheitslücken offenzulegen – und es werden immer mehr. Zu den bekannten Beispielen gehören CVE-2019-10795 in undefsafe und CVE-2019-10777 in aws-lambda.

5. Proprietäre Forschung und Analyse von Trends bei Sicherheitslücken

Der letzte Baustein im Sicherheitspuzzle ist unsere interne, proprietäre Forschung, mit der wir neue Sicherheitslücken im Open-Source-Ökosystem aufdecken und verantwortungsvoll offenlegen. Bei Snyk sehen wir es als entscheidend für die Sicherheit des Ökosystems an, neue Sicherheitslücken aufzudecken und verantwortungsvoll offenzulegen. Dafür nutzen wir unsere Datenbank mit bekannten Sicherheitslücken. Indem wir Trends bei Sicherheitslücken in einer bestimmten oder in mehreren Programmiersprachen untersuchen, erkennen wir wichtige Merkmale von Sicherheitslücken, die im Ökosystem wahrscheinlich weit verbreitet sind.

Mit anderen Worten: Wenn eine bestimmte Sicherheitslücke in mehreren verschiedenen Paketen im Ökosystem auftritt – jeweils mit ähnlichen Angriffsvektoren –, wissen wir, dass es wahrscheinlich weitere, noch unentdeckte Sicherheitslücken im Ökosystem gibt. Außerdem wissen wir, dass andere, womöglich böswilligere Akteure wahrscheinlich ebenfalls davon wissen und versuchen, diese Möglichkeit zu ihrem Vorteil zu nutzen.

Deshalb setzen wir unsere Forschungskapazitäten gezielt und effizient ein, um entweder neue Sicherheitslückentypen mit großer Reichweite wie zip-slip aufzudecken oder neue Fälle verbreiteter Sicherheitslückentypen in beliebten Paketen zu finden. Für diese Forschung kombinieren wir umfangreiche Datenanalysen, um anfällige Code-Snippets, Code-Muster und ähnliche Merkmale in potenziell gefährdeten Paketen zu identifizieren, mit der Untersuchung verschiedener Exploit-Vektoren. Unsere internen Tools wenden diese anschließend auf die potenziell gefährdeten Pakete an und stellen fest, ob sie tatsächlich anfällig sind.

Nach der Entdeckung nutzen wir unseren Zeitplan und unsere Methodik für die verantwortungsvolle Offenlegung, um die betroffenen Maintainer über die Sicherheitslücken zu informieren und sie bei der Behebung zu unterstützen. Anschließend veröffentlichen wir die Sicherheitslücke in unserer Datenbank und weisen ihr eine CVE zu.

Zusammenfassung

Das Ergebnis dieser umfangreichen Arbeit: Unser Sicherheitsprodukt erfüllt vier entscheidende Ziele:

1. Aktualität – Unsere Nutzerinnen und Nutzer erhalten rechtzeitig Informationen zu Sicherheitslücken und Exploits, sodass sie handeln können. Sie werden oft schon vor einer breiteren Bekanntgabe und bevor böswillige Akteure aktiv werden über Sicherheitslücken gewarnt.

2. Vollständigkeit – Nutzerinnen und Nutzer können sich darauf verlassen, ein vollständiges Bild ihrer Sicherheitslücken zu erhalten. Sie müssen sich keine Sorgen machen, dass weitere, potenziell ausnutzbare Sicherheitslücken in ihrer Codebasis schlummern.

3. Genauigkeit – Die bereitgestellten Daten sind präzise und vermeiden so das gefürchtete Grundrauschen und Fehlalarme bei Sicherheits-Scans.

4. Umsetzbarkeit – Anhand der Daten können Entwicklerinnen und Entwickler die sie betreffenden Sicherheitslücken schnell bewerten und ihre Arbeit entsprechend priorisieren.

Diese vier Ziele sorgen dafür, dass Snyk-Nutzerinnen und -Nutzer trotz des scheinbar endlosen Dschungels an Sicherheitslücken in Open-Source-Ökosystemen wissen: Ein engagiertes Team aus Sicherheitsexpertinnen und -experten steht ihnen zur Seite und ist bereit, ihnen alle Informationen zu liefern, die sie benötigen, um sich selbst und den Rest der Open-Source-Welt zu schützen.

Finden Sie Sicherheitslücken in Ihrem Code – erstellen Sie ein kostenloses Snyk-Konto.