Untersuchung COVID-19 SYMPTOM TRACKER App

Hintergrund.

Anlässlich der andauernden COVID-19-Pandemie wird der Ruf nach technischen Lösungen – insbesondere mobilen Apps – zur Überwachung, Vorhersage und Steuerung von Infektionsgeschehen und Massnahmen lauter. Die grosse Hoffnung auf eine herbeigesehnte Rückkehr zur Normalität hat gleichzeitig jedoch Schattenseiten: Eine Betrachtung der Verhältnismässigkeit und Angemessenheit findet nicht statt, die mit derartigen Lösungen stets einhergehenden Risiken werden ausgeblendet und nicht abgewogen.

Während die Regierungen noch an einer – oder mehreren – Lösungen arbeiten, gibt es bereits seit mehreren Wochen immer wieder neue COVID-19 Apps zum download in den App Stores. Diese verfolgen die verschiedensten Ansätze haben aber oft eins gemeinsam, das Sammeln von Daten.

Eine Entscheidung für und wider die Nutzung von Apps rund um das Coronavirus kann aber nur dann informiert erfolgen, wenn hier grösstmögliche Transparenz gegeben ist. Der Nutzer muss zumindest darauf vertrauen können, dass mit Nutzung der App keine unnötigen Risiken verbunden und die notwendigen Vorkehrungen zum Schutz medizinischer Daten umgesetzt sind, so wie sie das Bundesamt für Sicherheit in der Informationstechnik (BSI) zuletzt in einer Technischen Richtlinie (TR-03161) beschrieben hat:

• BSI TR-03161 „Sicherheitsanforderungen an digitale Gesundheitsanwendungen“ (PDF, 620KB, Datei ist barrierefrei⁄barrierearm)

Die TR-03161 befindet sich noch in der sogenannten „trial-use“-Phase. Sprich, Änderungen sind noch vorbehalten. Bei erster Betrachtung ergeben sich einige Gemeinsamkeiten mit anderen Standards wie dem OWASP-MASVS, welcher eine Vielzahl von technischen Sicherheitsanforderungen an Apps stellt.

Das ist begrüssenswert, denn mobile Endgeräte und somit auch die Apps, die darauf laufen, sind vielfältigen und immer neuen Gefahren ausgesetzt. Dies gilt auch für iOS-Geräte. Immer wieder tauchen schwerwiegende Sicherheitslücken in iOS-Komponenten auf, welche die Informationssicherheit der verarbeiteten Informationen gefährden (siehe Apple-Mail-Schwachstelle). Erst kürzlich wurde der sogenannte Chekra1n-Jailbreak veröffentlicht, für den lediglich ein kurzer physikalischer Zugriff auf ein Gerät notwendig ist um die volle Kontrolle zu erlangen. Mobile Endgeräte sind daher nicht zur sorglosen Verarbeitung oder Speicherung von sensiblen Informationen geeignet. Angesichts des auf dem Spiel stehenden Vertrauen fordere ich daher ein dem Schutzbedarf angemessenes Sicherheitsniveau ein.

An einem Negativbeispiel möchte ich nun aufzeigen, welche Mängel bei bereits oberflächlicher Sicherheitsuntersuchung zu Tage gefördert werden können, wenn dieser Grundsatz nicht beachtet wurde.

Die aufgedeckten Mängel wurden dem Hersteller der App gemeldet und teilweise behoben.

Am Ende des Artikels gibt es noch einige COVID-19-Survival-Tipps für diejenigen, die sich mit einfachen Massnahmen einen ersten Eindruck vom zu erwartenden Sicherheitsniveau einer App verschaffen wollen.

Vorbedingungen.

Im weiteren Verlauf getätigte Aussagen basieren auf den in der TR-03161 definierten Annahmen (2.3.1) sowie den Bedrohungen (2.3.2), welche auf mobile Anwendungen zutreffen.

Prüfaspekte.

Die folgenden Prüfaspekte umfasst die TR-03161:

• (1) Prüfung des Anwendungszwecks
• (2) Prüfung der Architektur
• (3) Prüfung des Quellcodes
• (4) Prüfung der Drittanbieter-Software
• (5) Prüfung der kryptographischen Umsetzung
• (6) Prüfung der Authentifizierung
• (7) Prüfung der Datenspeicherung und des Datenschutzes
• (8) Prüfung der kostenpflichtigen Ressourcen
• (9) Prüfung der plattformspezifischen Interaktionen
• (10) Prüfung der Netzwerkkommunikation
• (11) Prüfung der Resilienz

Die Ergebnisse im weiteren Verlauf werden unter diesen Aspekten klassifiziert. Nicht alle Prüfaspekte waren prüfbar, anwendbar oder im zur Verfügung stehenden Zeitraum durchführbar. Es werden nur die kritischsten Ergebnisse der Untersuchung im Details erklärt.

Exemplarisches Prüfobjekt.

Untersucht wurde die COVID-19 SYMPTOM TRACKER App welche auf EUREQA.IO basiert (iOS-App-Store: Link). Diese App dient zur pseudonymen Erfassung von COVID-19-bezogenen Informationen. Es handelt sich um eine iOS-App, welche auf dem Apache-Cordova-Framework basiert. Dieses ist in Fachkreisen bekannt dafür, insbesondere für Lösungen verwendet zu werden, die schnell entwickelt werden müssen. Sicherheitsmechanismen müssen hier oftmals nachträglich mit Aufwand eingebracht werden – was wiederum zu einem Zeitverlust führt.

Aktiv erhoben werden unter anderem (Liste nicht vollständig) die folgenden Daten des Benutzers:

• Alter
• Geschlecht
• Postleitzahl
• Anamnese-Daten
• Symptome

Diese Daten werden mit einer bei erstmaligem Starten der App zufällig generierten Benutzerkennung (Pseudonym) verknüpft. Hierbei handelt es sich um sensible und somit schützenswerte zumindest mittelbar personenbezogene Daten. Passiv könnten ausserdem die folgenden Daten erfasst werden:

• IP-Adresse

Sowohl die erhobenen Daten als auch die IP-Adresse ermöglichen einen zumindest mittelbaren Rückschluss auf die Identität des Nutzers.

Die Erfassung der Daten findet primär über sogenannte Fragebögen/Questionnaires statt.

Die Ergebnisse werden an den folgenden Server (API) übertragen:

• covid19-api.eureqa.io (68.183.71.227)

Testumgebumg.

Als Plattform für die Untersuchung wurde das iOS-Betriebssystem gewählt. Hierzu wurde ein iPhone X mit iOS 13.2.2 und einem Jailbreak mithilfe von Chekra1n aufgesetzt. Als Proxy wurde ein Laptop mit der Burp-Suite-Professional-Software verwendet. Beide Geräte befanden sich im gleichen WLAN-Netzwerk, um einen Machine-in-the-Middle-Angriff zu simulieren. Zusätzlich wurde auf dem iOS-Gerät manuell das CA-Zertifikat des Proxy installiert.

Anlegen eines pseudonymen Benutzeraccounts.

Beim ersten Start der App wird ein Benutzeraccount mit zufälliger Nutzerkennung bzw. Pseudonym erstellt. Hierzu wird eine HTTP-Anfrage an die API gesendet. Diese antwortet mit dem Pseudonym und einem Aktivierungs-Code, welcher später als Passwort genutzt wird.

HTTP/1.0 200 OK
Date: Tue, 21 Apr 2020 23:34:56 GMT
Server: Apache/2.4.29 (Ubuntu)
Vary: Authorization,Origin
Cache-Control: private, must-revalidate
ETag: [REDACTED]
Access-Control-Allow-Origin: null
Content-Length: 118
Connection: close
Content-Type: application/json

{"study_id":116,"username":"[REDIGIERT]","language":"en-us","first_name":"anonymous_user","activation_code":"[REDIGIERT]"}

Im weiteren Verlauf werden diese Merkmale (username, activation_code) zur Authentisierung gegenüber dem Server verwendet. Als Nächstes wird ein Zugriffstoken abgerufen. Hierbei handelt es sich um einen Token im JWT-Format. Dieser verfügt über einen Header, eine Payload und eine Signatur über jene.

Dieser Token wird im weiteren Verlauf zur Authentifizierung gegenüber der API verwendet.

Um sogenannte horizontale Autorisierungsprüfungen durchzuführen, wurden von mir zwei solcher Benutzeraccounts erstellt.

Mängel.

Fehlende Prüfung der Autorisierung

Prüfaspekt	Authentifizierung
Klasse	O.Auth_2
Vorbedingung	Internet, Niedrige Privilegien

Eine Prüfung der Autorisierung auf einem API-Endpunkt fehlt. Hiermit kann das Pseudonym und das Passwort abgefragt werden. Ein Angreifer muss nur über einen eigenen gültigen Zugriffstoken verfügen um auf die Daten anderer Benutzer zuzugreifen.

Bei einer Prüfung der Autorisierung wird festgestellt, ob eine angefragte Ressource oder Funktion für den jeweiligen Benutzer freigegeben ist. Bei der Prüfung sollte das Principle of least privileges befolgt werden. Dieses beschreibt, dass ein Benutzer oder Dienst nur die minimal möglichen Privilegien bekommt, welche zur Erfüllung der Aufgabe zwingend benötigt werden.

Disclaimer: Es wurden zum Nachweis dieser Schwachstelle zwei Benutzeraccounts erstellt, um eine horizontale Prüfung der Autorisierung durchzuführen. Zu keinem Zeitpunkt wurde auf Daten anderer Studienteilnehmer zugegriffen.

Im vorliegenden Fall war der folgende API-Endpunkt von dem Problem betroffen:

• /v1/participant/{user-id}

Der Wert {user-id} ist die jeweilige Benutzer-ID des Benutzers. Benutzer-IDs werden im vorliegenden Fall mit jedem neuen Benutzeraccount inkrementiert. Beispielsweise 1, 2, 3, …

Da der Benutzer seine eigene Benutzerkennung über den legitimen URL-Aufruf einsehen kann, können die Benutzer-IDs anderer Benutzeraccounts sehr einfach durch inkrementieren oder dekrementieren herausgefunden werden.

Sendet man eine HTTP-GET-Anfrage mit dem eigenen Zugriffstoken an eine gültige URL+{user-id}, bekommt man die folgende Server-Antwort:

{
  "data": {
    "first_name": " ",
    "last_name": " ",
    "email": null,
    "username": "[REDIGIERT]",
    "country": " ",
    "birthday": " ",
    "sex": " ",
    "height": 0,
    "weight": 0,
    "language": "en-us",
    "active_studies": [
      {
        "id": [REDIGIERT],
        "study_id": 116,
        "name": "COVID-19 Symptom Tracker",
        "description": "Helfen Sie mit den Corona-Virus (COVID-19) und seine klinischen Verläufe besser zu verstehen. Teilen Sie uns über die App täglich mit wie es Ihnen geht und welche Symptome Sie aufweisen. Ihre Mithilfe kann Leben retten!",
        "sharing_type": 3,
        "logo": "study_logo_images/ebc948685608f5ce36ed81b34156ca81.png",
        "test_mode": null,
        "completed_at": null,
        "activityUpcoming": null,
        "new_activities_count": 1
      }
    ],
    "completed_studies": []
  }
}

Wie zu sehen, ist der username sowie die Anzahl neuer Aktivitäten (Fragebögen) einsehbar. Der username ist das Pseudonym, welches bei der initialen Anmeldung durch den Server vergeben wird. Beispiel: zT74jh9f

Verwendet man jedoch statt einer HTTP-GET-Anfrage eine PUT-Anfrage, so bekommt man das Passwort (activation_code) des Benutzers zurück:

HTTP/1.0 200 OK
Date: Fri, 23 Apr 2020 22:14:34 GMT
Server: Apache/2.4.29 (Ubuntu)
Vary: Authorization,Origin
Cache-Control: private, must-revalidate
Access-Control-Allow-Origin: null
Content-Length: 415
Connection: close
Content-Type: application/json

{"id":[REDIGIERT],"first_name":" ","last_name":" ","username":"[REDIGIERT]","email":null,"password":"$2y$10$.[REDIGIERT]","activation_code":"[REDIGIERT]","code_used":1,"forgot_password":0,"birthday":" ","sex":" ","height":0,"weight":0,"country":" ","language":"en-us","reset_password":0,"created_at":"2020-04-21 22:36:56","updated_at":"2020-04-21 22:36:56","push_notification_id":null}

Dieses kann in Kombination mit dem Benutzernamen zur Anmeldung an dem Dienst verwendet werden. Da im vorliegenden Fall keine 2-Faktor-Authentifizierung verwendet wird, genügen Benutzername und Passwort um die volle Kontrolle über einen Benutzeraccount und die verarbeiteten Informationen zu übernehmen.

Des Weiteren könnte eine Änderung am Code des Backends zu weiteren Informations-Preisgaben führen. Wie in der obigen Server-Antwort ersichtlich besteht theoretisch die Möglichkeit auch Personal Identification Information (PII) abzufragen. Hierzu zählen unter anderem:

• E-Mail-Adresse
• Vor- und Nachnahme
• Land
• Geschlecht
• Grösse
• Gewicht
• Geburtsdatum

Es wird empfohlen, eine Prüfung der Autorisierung auf allen API-Endpunkten durchzuführen, um den Zugriff auf Daten Dritter zu erschweren.

Fehlende Verschlüsselung sensibler Daten

Prüfaspekt	Datenspeicherung und Datenschutz, Zustandslose Authentifizierungsmaßnahmen
Klasse	O.Data_2, O.Data_3, O.Data_5, O.Tokn_1
Vorbedingung	Physisch, Erhöhte Privilegien

Der ausgestellte Zugriffstoken sowie Server-Antworten, welche sensible Daten enthalten, sind unverschlüsselt auf dem mobilen Endgerät gespeichert. Sie werden beim Schliessen der App nicht gelöscht. Ein Angreifer, der die iOS-Sicherheitsmechanismen umgehen kann, ist in der Lage, auf diese Informationen zuzugreifen.

Netzwerk-Cache-Funktionalitäten werden häufig genutzt, um die Geschwindigkeit und den Netzwerkverkehr einer App zu optimieren. HTTP-Anfragen und -Antworten, welche sensible Informationen enthalten, sollten nicht in einem Cache abgelegt werden. Auf iOS ist der Netzwerk-Cache einer App in dem jeweiligen Sandbox-Verzeichnis vorzufinden. Hier findet keine zusätzliche Verschlüsselung statt. Für die Speicherung sensibler Informationen wie Authentifizierungs-Merkmalen (JWT) muss die iOS-KeyChain genutzt werden.

Beim Ausfüllen eines Fragebogens wurde unter anderem die Postleitzahl abgefragt, dieser Fragebogen konnte auch wieder über eine HTTP-Anfrage abgerufen werden. Die Server-Antwort enthält die eingegebene Information. Im Folgenden wird ein Ausschnitt aus der Server-Antwort gezeigt – die Postleitzahl befindet sich dabei im Feld value (hier redigiert):

[...]{"id":[REDIGIERT],"type":"short_text","title":"What is your post code\/zip code?","hint":null,"content":null,"answered":true,"position":3,"transition":null,"items":[],"value":"[REDIGIERT]","length":"25","continue_button":"Continue"}[...]

Um die Präsenz auf dem Mobiltelefon nachzuweisen, wurde ein grep-Kommando im Verzeichnis der App ausgeführt. Diverse Datenstrukturen mit diesem Wert wurden identifiziert:

Diese Dateien haben darüber hinaus eine unzureichende NSFileProtection gesetzt – CompleteUntilFirstUserAuthentication. Dieser Wert legt fest, wann die Verschlüsselung der Datei aufgehoben wird. In diesem Fall ist die Datei nur bis zum ersten Entsperren des mobile Gerätes nach einem Neustart verschlüsselt.

Das Fehlen von applikationsspezifischer Verschlüsselung vor der Speicherung von sensiblen Informationen birgt das Risiko, dass ein Angreifer, der in der Lage ist die Sandboxing-Sicherheitsmechanismen des Betriebssystems zu umgehen, auf diese zugreifen kann.

Ausserdem werden die Daten beim Beenden der App nicht aus dem lokalen Speicher gelöscht.

Es wird empfohlen eine applikationsspezifische Verschlüsselung sowie die iOS-KeyChain mit entsprechenden Schutzklassen zu verwenden. Ausserdem sollte entweder beim Wechsel in den Hintergrundmodus – spätestens aber beim Beenden der App – der lokale Speicher von sensiblen Information bereinigt werden.

Fehlendes Zertifikatspinning

Prüfaspekt	Netzwerkkommunikation
Klasse	O.Ntwk_4
Vorbedingung	Machine-in-the-Middle, Physisch, Erhöhte Privilegien

Die Integrität des Servers wird nicht überprüft. Ein Angreifer in einer Machine-in-the-Middle position kann die Zielperson dazu bringen ein falsches Zertifikat zu installieren und anschliessend die TLS-verschlüsselte Kommunikation einsehen.

TLS-Zertifikatspinning dient zur Prüfung der Integrität des Servers. Hierbei wird auf das Zertifkat oder eine Zertifikatskette des Servers gepinnt und bei Abweichung wird die Verbindung nicht hergestellt. Dies verhindert, dass ein Angreifer die Inhalte einer TLS-verschlüsselten Kommunikation einsehen kann.

Um von dieser Schwachstelle zu profitieren, muss der Angreifer ein eigenes Zertifikat im Vertrauensspeicher des mobilen Endgerätes installieren. Dies kann durch temporären physikalischen Zugriff, die Installation eines MDM-Profiles oder einen geschickten Phishing Angriff erreicht werden.

Alternativ muss sich der Angreifer ein Zertifikat auf den Domain-Namen des Servers von einer Zertifizierungsstelle (CA) verschaffen, dem das iOS-Gerät standardmässig vertraut. Ein solcher Identitätsdiebstahl wird durch die Verwendung eines automatisiert beantragten Domain-Validation-Zertifikats vereinfacht.

Die Zielperson wird kaum in der Lage sein festzustellen ob Sie Opfer eines solchen Angriffes ist, wenn die App wie gewohnt verwendet werden kann.

Es wird empfohlen ein geeignetes Zertifikatspinning zu implementieren. Bei fehlgeschlagener Prüfung muss die Kommunikation mit dem Backend beendet und der Anwender gegebenenfalls über eine Fehlermeldung informiert werden.

Fehlende Resilienz Massnahmen

Prüfaspekt	Resilienz
Klasse	O.Resi_2, O.Resi_3, O.Resi_6, O.Resi_8
Vorbedingung	Physisch, Erhöhte Privilegien

Die mobile App hat keine Resilienz-Massnahmen implementiert. Ein Angreifer, der in der Lage ist, die iOS-Sicherheitsmechanismen zu umgehen, kann die vollständige Kontrolle über die verarbeiteten Informationen übernehmen.

Resilienz-Massnahmen dienen zum Schutz vor einem lokalen Angreifer, der das mobile Endgerät kontrolliert. Zu den gängigsten Resilienz-Massnahmen zählen unter anderem die Folgenden:

• Jailbreak-Erkennung
• TLS-Zertifikats-Pinning
• Code-Obfuskierung
• Debug-Erkennung
• Code-Tampering Erkennung

Zwar bietet keine Resilienz-Massnahme einen 100%-igen Schutz, dennoch kann der Aufwand für einen Angreifer erhöht werden, die verarbeiteten Informationen zu kontrollieren.

Im vorliegenden Fall ist es möglich die Cordova-App auf einem Gerät mit Jailbreak und Proxy-Server (Machine-in-the-Middle) zu betreiben. Der ausgeführte Code ist nicht obfuskiert oder gegen Manipulation geschützt.

Ein Angreifer, der die volle Kontrolle über das mobile Gerät hat (Jailbreak), kann alle verarbeiteten Informationen kontrollieren. Er kann beispielsweise auf einfachste Weise den empfangenden Server im Code der App ändern und somit das Ergebnis der Fragebögen erhalten.

Es wird empfohlen Resilienz-Massnahmen gemäss aktuellem Stand der Technik zu implementieren. Es können auch professionelle Frameworks zum Einsatz gebracht werden, welche diesen Zweck erfüllen.

Mangelhafte Verwendung zustandsloser Authentifizierungstoken

Prüfaspekt	Zustandslose Authentifizierungsmaßnahmen
Klasse	O.Tokn_1, O.Tokn_8, O.Tokn_9, O.Tokn_10
Vorbedingung	Machine-in-the-Middle, Physisch, Erhöhte Privilegien

Die Umsetzung der Zugriffstoken ist mangelhaft. Ein Angreifer mit Zugriff auf diesen Token kann den Benutzer für einen längeren Zeitraum impersonifizieren und auf dessen Daten zugreifen, ohne das der Benutzer dies erkennen oder beenden kann.

Zustandslose Authentifizierungsmerkmale wie JWT haben eine Lebensdauer. Diese wird serverseitig vorgegeben und sollte bei jeder Anfrage überprüft werden. Um das Window of Opportunity für einen Angreifer, welcher Zugriff auf einen solchen Token erlangt hat, einzuschränken, sollte eine möglichst geringe Lebensdauer gewählt werden. Die Lebensdauer sollte im Sekunden-, Minuten- und nicht Stunden-/Tage-/Monate-/Jahre-Bereich liegen. Ausserdem müssen diese sensiblen Informationen in der iOS-KeyChain gesichert werden. Das Backend muss dem Anwender die Möglichkeit bieten, ausgestellte Token einzusehen und deren Gültigkeit zu revozieren.

Dekodiert man einen solchen ausgestellten JWT, dann geht die Lebensdauer aus der Differenz der Werte der Felder iat und exp hervor:

{
  "iss": "https://covid19-api.eureqa.io/v1/login",
  "iat": 1587440412,
  "exp": 1588045212,
  "nbf": 1587440412,
  "jti": "[REDIGIERT]",
  "sub": [REDIGIERT],
  "prv": "[REDIGIERT]"
}

Im vorliegenden Fall haben wir eine Lebensdauer von sieben Tagen. Diese wird als zu lang bewertet.

Um Zugriff auf einen JWT zu bekommen muss ein Angreifer in der Lage sein, eine Machine-in-the-Middle-Position (MitM) einzunehmen oder den lokalen Speicher des Gerätes auszulesen. Beides ist möglich, da die Empfehlungen des BSI auch in diesen Prüfungsaspekten nicht umgesetzt wurden.

Der Zugriff auf den JWT ermöglicht es beispielsweise, auf den Inhalt ausgefüllter Fragebögen zuzugreifen. Hierzu könnte der Angreifer die folgende HTTP-Anfrage an den Server senden:

GET /v1/study/p/116 HTTP/1.1
Host: covid19-api.eureqa.io
Content-Type: application/json;charset=utf-8
Origin: null
Connection: close
Accept: application/json, text/plain, */*
User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 13_2_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E148
Authorization: Bearer [REDIGIERT]
Accept-Language: en-us
Accept-Encoding: gzip, deflate

Der ausgestellte JWT, welcher zur Authentifizierung gegenüber der API genutzt wird, ist auch unverschlüsselt in den Netzwerk-Cache Dateien vorhanden. Im Folgenden redigiert:

# cat Library/Caches/WebKit/NetworkCache/Version\ 14/Records/507D8CD146BC87DF2F2A65BEF6CD6DC4F92B29A9/Resource/B51A95BF36D09DE37BAE0E9CEB77D293A7B8E915
Resource,https://covid19-api.eureqa.io/v1/study/p/116�������6Н�{���wғ���P}��F���/*e���m��+)��s;���Aݯ�Ё�qQll�ǔ��`/��
e'��,�\Z�y�]l���Z�0/q��9���4�Ų����,https://covid19-api.eureqa.io/v1/study/p/116application/json������������OHTTP/1.VaryAuthorization,Origin
Connectionclose
AuthorizationSBearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.[REDIGIERT]Originnull

Des Weiteren steht dem Benutzer keine Möglichkeit zur Verfügung, ausgestellte JWT’s einzusehen und deren Gültigkeit zu revozieren. Somit wäre ein Benutzer nicht selbst in der Lage, diesen Zustand zu beenden, selbst wenn er die Kompromittierung eines solchen Token feststellen würde.

Es wird empfohlen die Lebensdauer des Zugriffstoken auf ein sinnvolles Mass zu begrenzen. Ausserdem sollten Authentifizierungstoken in der iOS-KeyChain gespeichert werden und dem Benutzer sollte die Möglichkeit gegeben werden, diese zu managen.

Sensible Informationen einsehbar im Hintergrundmodus

Prüfaspekt	Plattformspezifische Interaktion
Klasse	O.Plat_11
Vorbedingung	Physisch, Niedrige Privilegien

Die mobile App gibt sensible Informationen preis während sie sich im Hintergrundmodus (Task Switcher) befindet. Ein Angreifer mit lokalem Zugriff auf ein nicht gesperrtes Gerät oder ein Geräte-Backup kann diese Informationen einsehen.

Wird eine mobile App nicht geschlossen sondern in den Hintergrundmodus versetzt (Task Switcher), erstellt das Betriebssystem einen Screenshot der aktuellen Ansicht, um diese im Task Switcher anzuzeigen. Hierbei können sensible Informationen, beispielsweise ein ausgefüllter Fragebogen, exponiert werden.

Des Weiteren werden diese Screenshots (auch Snapshots genannt) bei einem Geräte-Backup mit übertragen.

iOS-Geräte-Backups können lokal auf einem PC, aber auch in der Apple-iCloud abgelegt werden. In beiden Fällen können die Daten unverschlüsselt durch Dritte eingesehen werden (Lokal, iCloud).

Um von dieser Schwachstelle zu profitieren benötigt der Angreifer physikalischen Zugriff auf ein nicht gesperrtes (iOS-Passcode) Endgerät. Anschliessend kann über den Task Switcher Einsicht in Informationen der App genommen werden.

Es wird empfohlen beim Wechsel in den Hintergrundmodus alle sensiblen Informationen zu entfernen oder eine generische Abbildung anzuzeigen.

Verwendung ohne iOS-Passcode möglich

Prüfaspekt	Plattformspezifische Interaktion
Klasse	O.Plat_1
Vorbedingung	Physisch, Niedrige Privilegien

Die Verwendung der mobilen App ist ohne iOS-Passcode möglich. Auch existiert kein zusätzlicher App spezifischer Passcode-Schutz. Ein Angreifer mit physischem Zugriff auf das Endgerät kann auf den Inhalt der ausgefüllten Fragebögen zugreifen.

Der iOS-Passcode dient als erste Linie der Verteidigung gegen einen Angreifer mit physischem Zugriff auf das mobile Endgerät. Wird ein Gerät gestohlen oder bleibt für kurze Zeit unbeaufsichtigt, können die Informationen, welche in der App verarbeitet werden, durch Öffnen der App eingesehen werden. Daher sollte die App erkennen falls kein iOS-Passcode gesetzt ist und den Benutzer auf diesen Missstand hinweisen und die Verwendung der App unterbinden.

Um von dieser Schwachstelle zu profitieren benötigt ein Angreifer Zugang zu einem mobilen Endgerät ohne aktivierten iOS-Passcode. Anschliessend ist der Zugriff auf bereits ausgefüllte Fragebögen möglich und deren Inhalt kann eingesehen werden.

Wie auf den folgenden Abbildungen ersichtlich können die Informationen bereits ausgefüllter Fragebögen eingesehen werden.

Es wird empfohlen die Verwendung der App ohne iOS-Passcode zu unterbinden. Des Weiteren kann eine App spezifische Passcode-Abfrage implementiert werden. Die Umsetzung sollte gemäss aktuellen Best Practices betreffend Passcode-Stärke und Speicherung des Passcodes erfolgen.

Erweiterte Angriffsoberfläche des Backend

Prüfaspekt	Datenspeicherung und Datenschutz
Klasse	O.Data_2, O.Data_3, O.Data_5
Vorbedingung	Physisch, Erhöhte Privilegien

Der Server hat eine vergrösserte Angriffsoberfläche, da TCP-Ports, welche ausschliesslich dem Zweck des Management dienen, zum Internet geöffnet sind.

Eine shodan-Suche der IP-Adresse 68.183.71.227 hat ergeben, dass neben den Standard-HTTP-Ports 80 und 443 (TLS) auch der TCP-Port 22 (SSH) geöffnet ist.

Der SSH-Port wird nicht zum Verwenden mit der mobilen App benötigt. In der Regel werden über SSH-Verbindungen Management und Wartungsarbeiten am Betriebssystem oder den Diensten auf dem Server vorgenommen. Daher sollte der Zugriff auf diesen Netzwerk-Port auf die IP-Adressen autorisierten Administratoren beschränkt werden.

Selbst wenn der SSH-Port mit geeigneten Schutzmechanismen wie Passwort und Zertifikatsprüfung versehen ist, bleibt das Risiko einer Schwachstelle in der verwendeten Software bestehen. In der Vergangenheit gab es immer wieder Schwachstellen in SSH-Server-Software, welche zur Umgehung der Authentifizierung oder Remote-Code-Execution (Exploits) geführt haben. Die Ausnutzung einer solchen Schwachstelle hätte den Kontrollverlust über den Server zur Folge.

Um von dieser Schwachstelle zu profitieren muss ein Angreifer in der Lage sein einen solchen Exploit zu entwickeln oder zu erwerben.

Es wird empfohlen Netzwerk-Schnittstellen, welche zum Management des Servers genutzt werden, vor Zugriff aus dem Internet zu schützen und nur für autorisierte Administratoren freizugeben.

Veraltete Webserver-Software mit bekannten Schwachstellen

Prüfaspekt	Organisatorische Sicherheitspolitiken
Klasse	OSP.CriticalUpdates
Vorbedingung	Internet

Die verwendete Webserver-Software-Version verfügt über öffentlich bekannte Schwachstellen. Ein Angreifer, der in der Lage ist diese Schwachstellen auszunutzen, kann die Vertraulichkeit, Integrität und Verfügbarkeit der verarbeiteten Informationen gefährden.

Die eingesetzte Webserver-Version wird durch einen HTTP-Header preisgegeben. Dies widerspricht dem Information Hiding Approach, der besagt, dass einem System nur so viel Informationen preisgegeben werden sollen, wie für die Erfüllung der Aufgabe notwendig sind.

HTTP/1.0 200 OK
Date: Thu, 23 Apr 2020 22:34:23 GMT
Server: Apache/2.4.29 (Ubuntu)
Vary: Authorization,Origin
Cache-Control: private, must-revalidate
ETag: "8a1d0920b1a5e06aff79f25fda8000ca1ded0ac6"
Access-Control-Allow-Origin: null
Content-Length: 680
Connection: close
Content-Type: application/json

Ausserdem wurde die Software Apache v.2.4.29 am 23. Oktober 2017 veröffentlicht und gilt gemäss Wikipedia als veraltet und nicht mehr unterstützt.

Des Weiteren existieren für die verwendete Version der Software einige teils kritische Schwachstellen. Die Kritischste mit einem CVSS-Scoring von 7.2.

Die Schwachstellen werden vom Autor mit Blick auf das untersuchte Backend als weniger kritisch eingestuft, dennoch kann ein fehlendes Software-Update-Management zukünftig kritischere Schwachstellen anwendbar machen.

Es wird empfohlen alle Software-Komponenten sowie verwendete Frameworks, auch solche von Dritt-Anbietern, auf Aktualität zu prüfen. Insbesondere sollten sicherheitsrelevante Updates zeitnah eingespielt werden.

Fazit.

Die aufgedeckten Mängel zeigen, dass die mobile App COVID-19 SYMPTOM TRACKER nicht den Empfehlungen der Technischen Richtlinie des Bundesamtes für Sicherheit in der Informationstechnik entspricht.

Es wurde ein API-Endpunkt identifiziert, über die Benutzernamen sowie dazugehörige Passwörter abgefragt werden können. Diese Informationen können genutzt werden, um die volle Kontrolle über beliebige Pseudonyme Benutzeraccounts und darin gespeicherte Informationen zu übernehmen.

Die mobile App hat keinerlei Resilienz-Massnahmen gegen einen lokalen Angreifer implementiert. Der Code der Anwendung liegt zum Grossteil gut lesbar in JavaScript vor und ist nicht vor Manipulation geschützt. Es wird nicht erkannt, ob die App auf einem nicht-vertrauenswürdigen Betriebssystem (Jailbreak) ausgeführt wird. Ein Machine-in-the-Middle Angriff auf die verschlüsselte Kommunikation ist mangels Zertifikatpinnings möglich. Debugging-Werkzeuge wie Frida können zur Laufzeit verwendet werden um den Programmablauf nachzuvollziehen oder zu manipulieren.

Signifikante Mängel wurden bei der Handhabung von sensiblen Informationen auf dem mobilen Endgerät identifiziert. Beispielsweise ist das Ergebnis eines ausgefüllten Symptom- oder Anamnese-Fragebogens unverschlüsselt auf dem iOS-Gerät zugänglich.

Die verarbeiteten Informationen sind unzureichend vor einem Angreifer mit physikalischen Zugriff auf das Endgerät geschützt. Es fehlt sowohl die Prüfung des Vorhandenseins eines iOS-Passcode oder eines applikationsspezifischen Passcode. Ausserdem können sensible Informationen über den iOS-Task-Switcher eingesehen werden. Geräte-Backups können Screenshots (Snapshot) von sensiblen Informationen enthalten.

Die verwendete Webserver-Software ist veraltet und verfügt über öffentlich bekannte Schwachstellen. Dies weist auf die Abwesenheit eines Update-Managements hin. Hierdurch können weitreichende Probleme für den Betrieb der Infrastruktur und der verarbeiteten Informationen entstehen.

COVID-19 Survival Tipps. (Endbenutzer)

Die folgenden Tests können durchgeführt werden, um einen ersten Eindruck zu bekommen, ob Informationssicherheit ein zentraler Bestandteil der Entwicklung war. Die gewählten Prüfaspekte sind für einen Entwickler einfach umzusetzen und für einen Anwender einfach zu prüfen.

• Achten Sie beim erstmaligen Öffnen der App darauf, ob es möglich ist, ein App-spezifisches Passwort (Passcode) zu setzen.
• Versetzen Sie die App durch Wischen in den Hintergrundmodus. Wechseln Sie zum iOS-Task-Switcher und schauen Sie, ob immer noch sensible Informationen einsehbar sind.
• Erstellen Sie manuell einen Screenshot in der App. Werden Sie durch die App benachrichtigt, das dies ein Sicherheitsproblem darstellen kann?
• Suchen Sie in der App nach Informationen über die Sicherheit. Legt die App verständlich dar, wie Ihre Daten geschützt werden? Gibt es einen erreichbaren Ansprechpartner für die Sicherheit der App?

Natürlich gilt es zu beachten, dass eine Anwendung nicht automatisch sicher ist, nur weil Sie diese Bedingungen erfüllt. Aber eine Schlussfolgerung bei Nicht-Einhaltung ist erlaubt.

Erfüllt die Anwendung nicht diese einfach zu prüfenden Aspekte, dann kann angenommen werden, dass Informationssicherheit und der Schutz der Privatsphäre nicht im Vordergrund standen, als die App erstellt wurde.

Ich würde in so einem Fall von der Verwendung der App abraten, aber am Ende muss das Jeder für sich selbst entscheiden. Im Zweifelsfall fragen Sie nicht Ihren Arzt oder Apotheker, diese haben andere Fachgebiete. Wenden Sie sich lieber an den Hersteller, mit der Bitte um Einsicht in das Sicherheitskonzept.

Ähnliche Artikel.

• https://www.ccc.de/de/updates/2020/abofalle-datenspende
• https://epicenter.works/content/analyse-der-stopp-corona-app-unmittelbare-verbesserungen-durch-experten-bericht

Dank.

Ich möchte Martin Tschirsich für fachlich-redaktionelle Unterstützung in dieser Angelegenheit danken.