Feature

Open Source sei Dank: So fanden Experten eine Schwachstelle im Server der Corona-Warn-App

Die mobile App war nicht betroffen. (Foto: Firn / shutterstock)

Lesezeit: 5 Min. Gerade keine Zeit? Jetzt speichern und später lesen

Ein Cybersecurity-Experte hat eine Sicherheitslücke in der Infrastruktur der Corona-Warn-App entdeckt. Die Hintergründe und der weitere Verlauf der Geschichte zeigen einmal mehr die Vorteile von Open-Source-Software.

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.

Es passierte zufällig

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.

Fast fertig!

Bitte klicke auf den Link in der Bestätigungsmail, um deine Anmeldung abzuschließen.

Du willst noch weitere Infos zum Newsletter? Jetzt mehr erfahren

Framework gilt als Standard für die Umsetzung dieser Art von Logik

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.

Semantische Code-Analyse hilft beim Finden von Schwachstellen

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.

Schwachstelle im Submission Endpoint

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.

Dann ging alles ganz schnell

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.

Die mobile App war nicht betroffen

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:

contact tracing comic

(Bild: Nicky Case)

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.“

Davon profitiert auch die Entwickler-Community

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.

Meistgelesen

Bitte beachte unsere Community-Richtlinien

Wir freuen uns über kontroverse Diskussionen, die gerne auch mal hitzig geführt werden dürfen. Beleidigende, grob anstößige, rassistische und strafrechtlich relevante Äußerungen und Beiträge tolerieren wir nicht. Bitte achte darauf, dass du keine Texte veröffentlichst, für die du keine ausdrückliche Erlaubnis des Urhebers hast. Ebenfalls nicht erlaubt ist der Missbrauch der Webangebote unter t3n.de als Werbeplattform. Die Nennung von Produktnamen, Herstellern, Dienstleistern und Websites ist nur dann zulässig, wenn damit nicht vorrangig der Zweck der Werbung verfolgt wird. Wir behalten uns vor, Beiträge, die diese Regeln verletzen, zu löschen und Accounts zeitweilig oder auf Dauer zu sperren.

Trotz all dieser notwendigen Regeln: Diskutiere kontrovers, sage anderen deine Meinung, trage mit weiterführenden Informationen zum Wissensaustausch bei, aber bleibe dabei fair und respektiere die Meinung anderer. Wir wünschen Dir viel Spaß mit den Webangeboten von t3n und freuen uns auf spannende Beiträge.

Dein t3n-Team

Schreib den ersten Kommentar!

Melde dich mit deinem t3n Account an oder fülle die unteren Felder aus.

Bitte schalte deinen Adblocker für t3n.de aus!

Hey du! Schön, dass du hier bist. 😊

Bitte schalte deinen Adblocker für t3n.de aus, um diesen Artikel zu lesen.

Wir sind ein unabhängiger Publisher mit einem Team bestehend aus 70 fantastischen Menschen, aber ohne riesigen Konzern im Rücken. Banner und ähnliche Werbemittel sind für unsere Finanzierung sehr wichtig.

Danke für deine Unterstützung.

Digitales High Five,
Luca Caracciolo (Chefredakteur t3n) & das gesamte t3n-Team

Anleitung zur Deaktivierung