Alvaro Muñoz’ Job beim GitHub Security Lab ist es, Schwachstellen in Open-Source-Projekten zu suchen und zu finden.  GitHub ist wie GitLab oder BitBucket eine Plattform zur Versionsverwaltung von Softwareprojekten. Das IT-Sicherheits-Forschungslabor, Muñoz’ Wirkungsstätte, wurde vor knapp einem Jahr ins Leben gerufen. Die Zielsetzung: Open-Source-Software sicherer zu machen.

Eigentlich geschah es beinahe zufällig. Im Sommer 2020 befassten Muñoz und sein Team sich mit den Auswirkungen unsicherer Verwendungsmuster einer API zur Implementierung von Validierungsmechanismen in Java-Applikationen. Mehrere Wochen später, nachdem sie diese Muster bereits in mehreren Open-Source-Projekten ausfindig machen und in Zusammenarbeit mit deren Maintainern beheben konnten, stießen die Cybersecurity-Experten im Projekt des Corona-Warn-App-Servers – kurz CWA-Server – auf dieselben als unsicher identifizierten Verwendungsmuster.

Die Schwachstelle wurde durch eine unsichere Stelle im Code des Validierungsmechanismus für Nutzereingaben im Corona-Warn-App-Server-Projekt verursacht. Die Logik zur Validierung von Benutzereingaben ist im Projekt mittels einer Schnittstelle namens Java Bean Validation API implementiert. „Nutzereingabe“ bedeutet im Fall der Corona-Warn-App zum Beispiel das Teilen eines positiven Covid19-Testergebnisses.

Das Java-Bean-Validation-Framework gilt als der De-facto-Standard für die Umsetzung dieser Art von Logik. Im Juni 2020 hatte Muñoz einen Blogpost veröffentlicht, in dem er genauer beschreibt, wie die identifizierten unsicheren Verwendungsmuster zu sogenannten RCE-Schwachstellen führen. Die Abkürzung RCE steht für Remote Code Execution. Derartige Schwachstellen sind Einfallstore für Cyber-Attacken. Angreifer können sie ausnutzen, um ohne Autorisierung aus der Ferne auf fremde Systeme zuzugreifen und sie zu manipulieren.

Im Rahmen der begleitenden Untersuchungen durchkämmte sein Team in der Folge mehrere Open-Source-Repositories nach diesen Mustern. Dabei kam CodeQL, eine Technologie zur semantischen Code-Analyse, zum Einsatz. Erst im September 2019 hatte GitHub das Tool mitsamt zugehörigem Startup akquiriert. Die CodeQL-gestützte Suche nach solchen Schwachstellen basiert auf der Durchführung von Abfragen, auch Queries genannt. Das heißt, die Technologie gleicht den Programmcode der gescannten Projekte mit den in der Abfrage definierten, potenziell schadhaften Mustern ab. Bei einem Match schlägt das Tool entsprechend Alarm.

Die von Muñoz identifizierte unsichere Verwendung der Validierungs-API ist offenbar nicht ungewöhnlich – die Experten wurden in einer Reihe von Projekten fündig. In Zusammenarbeit mit den Maintainern der betroffenen Projekte waren Muñoz und sein Team glücklicherweise relativ schnell in der Lage, Methoden zur Behebung der Schwachstellen zu erarbeiten.

Kürzlich befand sich eben auch das Repository des deutschen Corona-Warn-App-Servers unter den gescannten Projekten. Wenig überraschend weckte das Projekt sofort die Aufmerksamkeit des IT-Experten. Er schaute genauer hin: Die Schwachstelle wurde in einem Microservice namens Submission Service lokalisiert. Der Corona-Warn-App-Server exponiert nur einen einzigen Endpoint, den Submission Endpoint. Dieser Endpoint kommt offenbar dann ins Spiel, wenn Nutzer ein positives Covid19-Testergebnis mit der Warn-App teilen. Das geschieht über einen mehrfach abgesicherten Mechanismus, unter anderem kommen dabei eine Tan und ein Diagnose-Key zum Einsatz, über die sichergestellt wird, dass die – natürlich vollkommen anonym übermittelten – positiven Corona-Testergebnisse auch verifiziert werden können. Dieser Server-Endpoint sei public und nicht authentifiziert, was bedeute, dass sogenannte _POST_-Requests an den Submission Endpoint standardmäßig erlaubt seien. Sie erforderten keinerlei weitere Autorisierung oder Authentifizierung, beschreibt Muñoz die Details in einem weiteren Blogpost.

In der Praxis wäre es Warn-App-Nutzern auch aufgrund der Schwachstelle nicht möglich gewesen, einen invaliden Diagnose-Key einzureichen; verhindert wird dies über den zusätzlichen Tan-gestützten Verifizierungsmechanismus, führt Muñoz die Implikationen der Schwachstelle weiter aus. Unglücklicherweise geschähe eine mögliche Remote-Code-Execution bereits vor der Verifizierung der Tan. Selbst wenn die Tan-Verifizierung an früherer Stelle stattfände, wäre es einem Angreifer mit einem positiven Covid-19-Test möglich gewesen, die Schwachstelle auszunutzen.

Die Experten des GitHub Security Labs verifizierten die Möglichkeit eines Exploits, indem sie ihn mit geeigneten Methoden in einer gesicherten Umgebung simulierten. Dann ging alles ganz schnell:

• Über das SAP Trust Center informierte Munoz’ Team das verantwortliche Entwicklerteam bei SAP am 21. Oktober 2020 über die Schwachstelle.
• Bereits am 23. Oktober 2020 gab es einen Pull Request mit einem ersten Ansatz zum Beheben der Lücke.
• Weitere fünf Tage später, am 28. Oktober 2020, wurde Muñoz von SAP informiert, dass das Problem in Release 1.5.1 des CWA-Servers, der am 27. Oktober, also einen Tag vorher deployed worden war, bereits behoben sei und das BSI die Änderungen teste.
• Am 1. November 2020 konnte schließlich ein weiterer Pull Request mit einem robusteren Fix gemerged werden.
• Am 9. November 2020 bestätigte das BSI, dass die Schwachstelle erfolgreich behoben sei.

Einem Angreifer wäre es bei einem Exploit der Lücke wohl möglich gewesen, arbiträren Java-Code oder System-Commands auf dem Corona-Warn-App-Server auszuführen. Auf die Frage, wie sich ein Exploit hätte auswirken können, sagte Jamie Cool, Vice President Of Product Management, Security bei GitHub, das ließe sich nicht mit Genauigkeit sagen. In jedem Fall hätte ein solches Vorkommnis jedoch die Integrität der Corona-Warn-App in Mitleidenschaft ziehen können.

Aber, Moment. Eine Schwachstelle in der Corona-Warn-App? Jener App, die in Windeseile von SAP und Telekom entwickelt wurde? Die in puncto Privatsphäre, Sicherheit, Contact-Tracing und Wirksamkeit wochenlang für Diskussionsstoff sorgte?

Um Missverständnisse auszuräumen: Die Schwachstelle wurde im Backend der Corona-Warn-App entdeckt. Auf die Datensicherheit der mobilen Android- und iOS-App hätte ein möglicher Exploit keine Auswirkungen gehabt. Außer der IP-Adresse der verwendeten Geräte sammelt und überträgt die App keine persönlichen Daten. Wie die Kontakt-Nachverfolgung der Corona-Warn-App funktioniert und wie deren Nutzer dabei vollkommen anonym bleiben, erklärt dieser Comic:

Die Infrastruktur hinter der mobilen Contract-Tracing-Lösung zur Eindämmung der Corona-Pandemie ist relativ komplex. Sie besteht aus drei Komponenten. Alle drei sind Open Source. Das bedeutet, ihr Programmcode ist offen über die Code-Hosting-Plattform GitHub einsehbar. Die Veröffentlichung des Source Codes der Anwendung sorgt für Transparenz. Dritte können nachvollziehen, wie die App funktioniert und haben die Möglichkeit, deren Sicherheit zu überprüfen. „Die Entdeckung der Schwachstelle und auch, dass sie so schnell behoben werden konnte, veranschaulicht einen der größten Vorzüge von Open-Source-Software“, sagte Cool gegenüber t3n. „Wäre die Anwendung nicht Open Source, wäre das so nicht möglich gewesen.“

Die Abfrage zum Finden der von Muñoz entdeckten Sicherheitslücke ist mittlerweile auch in GitHubs Code-Scanning-Feature integriert. Sollten also zukünftig Entwickler in die Verlegenheit kommen, eine derartige Schwachstelle in ihren Code einzubauen, würden das Code-Scanning-Feature sie warnen – sofern sie ihren Code bei aktiviertem Feature über GitHub versionieren.