Wir erhielten ein Audit in Sachen Arbeiten am neuen „index-v2“ in der offiziellen Android-App und API (3 Tage) und das neue Frontend der Webserver-Einrichtung (1 Tag). Es gab keine Funde beim Webserver-Setup, somit wird sich die Analyse in diesem Beitrag mit der F-Droid-App beschäftigen. Das Audit wurde von Radically Open Security geleitet, was ein natürlicher Partner für F-Droid ist, da ihr gemeinsamer Schwerpunkt auf freier Software und offenen Prozessen liegt. Dank gilt NLnet für die Vermittlung der Auditoren und Kostenübernahme für deren Honorar. Wir stellen den Originalreport zum Download zur Verfügung.

Dieser Beitrag wurde im Geiste der Transparenz geschrieben und enthält technische Details zu den Risiken der einzelnen Schwachstellen. Wir begrüßen weitere Untersuchungen. Weitere Informationen über F-Droid’s Schutzvorkehrungen, finden Sie in der Dokumentation unter Sicherheitsmodell.

CLN-002 – XML-Parser potentiell durch XXE-Attacken gefährdet

• Schwachstellentyp: Eingabe-Validierung
• Gefährdungsgrad: Erhöht

Die XML-Parser-Einbindung der Anwendung ist u. U. bei Attacken von XML External Entity (XXE) angreifbar.

Auswirkung

Wenn der XML-Parser keine Einschränkungen hinsichtlich externer und interner Datensätze besitzt, dann kann dies bei der Analyse der XML-Eingabe zu willkürlicher Offenlegung von Dateien oder Schwachstellen durch Fälschung von Anfragen auf Server-Seite führen (server-side request forgery - SSRF).

Unsere Reaktion

Die ursprüngliche Index-Datei, im Version-0-Format, ist eine XML-Datei, die als Teil eines jeden Repos generiert wird. Sie ist entweder als index.xml oder in der neueren signierten Version als index.jar abrufbar. Neueste Versionen des Clients werden immer zunächst index-v1.jar, in einem signiertem JSON-Format, suchen. Steht sie nicht zur Verfügung, wird der Client auf index.jar ausweichen. index.jar wird auch bei der „Nearby“-App-Tauschfunktion verwendet. Alle diese index.jar-Dateien müssen zuerst die Signatur-Verifizierung durchlaufen, bevor das XML analysiert wird.

Für eine erfolgreiche Ausnutzung davon wäre es erforderlich, dass entweder a) der Angreifer das Ziel erreichen konnte, ein bösartiges Repo hinzuzufügen, oder b) der Angreifer die Repo-Signierschlüssel beziehen und dann in einen bestehenden Repo-Server einbrechen und die Index-Dateien ersetzen konnte. Zum Beispiel könnte ein hinterhältiger Akteur versuchen, jemanden über den Nearby-App-Tausch auszuspähen, bezieht also nur Apps von Leuten, denen ihr traut. Die Art und Weise wie der Client aufgebaut ist, um das XML zu analysieren, war angreifbar und würde es einem erfolgreichen Angreifer ermöglichen, Dateien auszulesen, die die F-Droid-App lesen kann.

Die Index-Dateien für f-droid.org und das Repo von Guardian Project werden überwacht und Änderungen an ihnen protokolliert. So können wir mit großem Selbstvertrauen sagen, dass index-v1.jar niemals entfernt wurde, was eine Grundvoraussetzung für die Ausnutzung dieser Sicherheitslücke wäre.

Der F-Droid-Client der Version 1.15.4 deaktiviert die Unterstützung externer XML-Entitäten komplett. Die v1.16-alpha0 unterstützt überhaupt keine XML-Indizes mehr und aller Code mit Bezug zu XML-Index-Analyse und -Erzeugung wurde entfernt. Wir werden im Rahmen der FFDW-DVD-Förderung auch an der Verbesserung der Sicherheit beim Hinzufügen von Repos arbeiten.

CLN-005 – Akzeptanz angreifbarer TLS-Versionen

• Schwachstellentyp: Unsichere Konfiguration
• Gefährdungsgrad: Erhöht

Die von der Anwendung verwendeten Backend Domains akzeptieren obsolete Protokolle vom Typ TLS 1.0 und TLS 1.1.

Auswirkung

Die Verwendung von TLS 1.0 und 1.1 macht die Kommunikation anfällig für niederschwellige Angriffe, da sie mit SHA-1-Hashfunktionen zur Integritätsprüfung ausgetauschter Nachrichten arbeiten. Die Handshake-Authentifizierung wird ebenfalls mit SHA-1 erledigt, was es einem Angreifer erleichtert, sich als Server für MITM-Angriffe auszugeben. Der PCI DSS (Payment Card Industry Data Security Standard) legt fest, dass TLS 1.0 ab 30. Juni 2018 nicht länger verwendet werden darf, und empfiehlt dringend auch 1.1 zu deaktivieren, somit würde dies die Einhaltung der Vorschriften beeinträchtigen.

Unsere Reaktion

F-Droid legt großen Wert darauf, Kompatibilität so lange wie möglich zu gewährleisten. Aus diesem Grund lassen wir TLS 1.0 und TLS 1.1 auf unseren Websites aktiv. Wir glauben, dass es für Leute, die ihre Software auf dem neuesten Stand halten, kein zusätzliches Risiko beinhaltet. Die F-Droid-App erlaubt keine Verbindungen mit TLS 1.1 oder 1.0. TLS 1.3 bietet einen guten Downgrade-Schutz, TLS 1.2 weniger. Jede ordentliche TLS-Implementierung aus den letzten Jahren macht es ziemlich schwer, eine Verbindung zur Verwendung von TLS 1.0 oder 1.1 zu zwingen. Neueste Browser-Versionen entfernen überhaupt jegliche Unterstützung von TLS 1.0 und 1.1. Das heißt, dass jene Browser- oder Client-Version, die sich über TLS 1.0 oder 1.1 verbindet, das tatsächlich muss, um zu funktionieren. Ein Gerät, auf dem Android 1.6 läuft, sollte in der Lage sein, eine alte Version von F-Droid zu installieren und einen funktionierenden App-Store zu haben.

Wenn ihr ein Gerät habt, das immer noch TLS 1.0 oder 1.1 nutzen muss, dann gibt es bereits so viele bestens bekannte Sicherheitslücken, dass die eine nicht von besonderem Interesse ist. Wenn ihr testen wollt, ob euer Browser noch TLS 1.0 oder 1.1 unterstützt, klickt auf die Links unten und seht, ob sie zu einer Fehlermeldung führen.

• https://tls-v1-0.badssl.com:1010/
• https://tls-v1-1.badssl.com:1011/

CLN-001 – Verschlüsselungsalgorithmen verwenden unsicheres Verfahren und Padding-System

• Schwachstellentyp: Schwache Kryptographie
• Gefährdungsgrad: Gering

Die in der App genutzten Verschlüsselungsalgorithmen verwenden ein unsicheres Verfahren sowie Padding-System.

Auswirkung

Wenn sensible Daten mittels unsicherer Verfahrem, unsicherem Padding verschlüsselt werden, kann dies dazu führen, dass Daten aus dem verschlüsselten Datensatz gestohlen oder rückgewonnen werden.

Unsere Reaktion

Dies wurde einzig und allein dazu verwendet, die beim Nearby-App-Tausch verwendete Indexdatei der App zu signieren, was nur in einem lokalen Netzwerk funktioniert. Die Signatur ist eine kurzlebige Datei, die während des Vorgangs generiert und fast ausschließlich in einer Eins-zu-eins-Interaktion angewandt wird. Eine Vielzahl weiterer Bausteine müssten vor Ort sein, damit dies ausgenutzt werden kann. Außerdem müsste ein beträchtlicher Aufwand betrieben werden, um die Kryptographie der Datei zu knacken, die Sekunden oder Minuten vorher signiert wurde und wahrscheinlich nur für rund 10 Minuten Verwendung finden wird. Jedes App-Update, das über den Nearby-Tausch empfangen wird, besitzt immer noch den vollen Schutz der APK-Signatur. Aus diesen Gründen ist es immer noch sicher, den SHA1-Algorithmus zu verwenden, der hier aus Kompatibilitätsgründen notwendig ist. Dieser Anwendungsfall fällt unter die Angelegenheit “Second Preimage Attack”, was bedeutet, dass der Angreifer die Daten nicht beeinflussen kann, bevor sie signiert sind. Git kann sich aus diesem Grund auch immer noch auf SHA1 verlassen.

Der F-Droid-Client in den Versionen v1.15.4 und v1.16-alpha1 wechselt vom RSA/ECB/PKCS1Padding zum Algorithmus SHA1withRSA als Standard, um index.jar bei Nearby zu signieren. Der neue „index-v2“ für Repositorys in v1.16-alpha0 nutzt SHA256withRSA als Signieralgorithmus. Der offizielle Client startet immer mit der Suche nach der letzten Indexversion in jedem Repository und in v1.16 wurde ein Downgrade-Schutz ergänzt, so kann ein Repo, das bereits „index-v2“ beinhaltet, nicht auf „index-v1“ zurückgestuft werden.

CLN-003 – Datenverkehr in der Anwendung ist als Klartext möglich

• Schwachstellentyp: Unsichere Konfiguration
• Gefährdungsgrad: Gering

Die Netzwerk-Basiskonfiguration der Anwendung erlaubt Klartext-Übertragung.

Auswirkung

Das Zulassen von Klartext-Übertragung hat Auswirkungen auf Vertraulichkeit, Glaubwürdigkeit und Schutz gegen Fälschung. Ein Angreifer, der einen Machine-in-the-Middle-Angriff ausführt, kann übertragene Daten aushorchen und sie verändern, ohne dabei erkannt zu werden.

Unsere Reaktion

Demnach ist die Android-Eigenschaft zur Blockade von Klartext-HTTP-Verbindungen eine Funktion, die Apps verwenden sollten. Diese zu deaktivieren ist offensichtlich nicht ideal, aber wir mussten das tun, um die Funktionalität zum lokalen HTTP-Tausch und in der Vergangenheit auch HTTP-.onion-Adressen zu unterstützen (heutzutage ist hierfür eine Zwischenlösung möglich). So haben wir Extramaßnahmen ergriffen, um HTTPS durchzusetzen:

• Alle eingeschlossenen Repository-URLs sind in HTTPS fest programmiert

• Beliebtes Cloud-Hosting für Repos wird zu HTTPS gezwungen

• Der Standarddialog für den Nutzer zum Hinzufügen von Repos beinhaltet https://

Diese Schwachstelle betrifft exakt denselben Kontext wie CLN-001: Nearby-App-Tausch. Somit ist es von Haus aus eine ganz begrenzte Umgebung, in der böswillige Akteure agieren können. Es beeinträchtigt eingebaute Repos in keinster Weise, da sie in HTTPS fest programmiert sind. Hinzukommt, dass gute Webserver-Einrichtungen wie f-droid.org keine Datenübertragung über einfaches HTTP erlauben.

CLN-004 – HTTP Request URLs werden protokolliert

• Schwachstellentyp: Datenleck
• Gefährdungsgrad: Gering

Die Android-App (org.fdroid.fdroid.debug ver. 1.14-alpha3-505-gc8514adb9-debug) protokolliert URLs.

Auswirkung

Das Protokollieren sensibler Informationen im Android-Protokoll ist keine empfohlene Praxis, da auf diese Informationen durch andere Anwendungen auf demselben Gerät (in bestimmten Szenarien) zugegriffen werden kann. URLs können Tokens oder andere möglicherweise protokollierte sensible Daten enthalten, was zur Offenlegung dieser Daten in anderen Apps führt.

Unsere Reaktion

Datenschutz ist wichtig und wir möchten sicherstellen, dass keine potenziell vertrauliche Information preisgegeben wird, auch nicht zugunsten einer leichteren Fehlersuche oder Dienstanalyse. So wissen wir die Aufmerksamkeit der Auditoren beim Hinweis auf dieses Problem zu schätzen und haben das Protokollieren von URLs bei Release-Versionen entfernt.

Diese Schwachstelle beeinträchtigt nicht die Sicherheit von Operationen. Viele Web-Dienste stecken private Tokens in URLs und deren Protokollierung wäre wie die Preisgabe von Klartext-Passwörtern. Alle gut bekannten Repositorys einschließlich f-droid.org werden als statische Website betrieben, so gibt es dort keine Nutzerkonten. Das Problem hier ist, wenn jemand den „logcat“-Text erhält, der generell in Android geschützt ist, und Apps den Text nicht mehr einfach lesen können. Ein denkbares Leckage-Szenario wäre, wenn jemand eine heikle App installiert und dann deinstalliert. Diese App-Installation und -Deinstallation wäre im Protokoll verzeichnet, wäre abrufbar, wenn der Anwender dazu genötigt würde, das Protokoll zur Verfügung zu stellen, oder wenn das Gerät instrumentalisiert würde, den Zugriff auf geschützte Daten zu gewähren.

Dies wird behoben in der endgültigen Version v1.16.

(Diese Arbeiten wurden von NLnet im Rahmen eines fortlaufenden Projekts namens Tracking the Trackers und The Search for Ethical Apps unter der Schirmherrschaft von Guardian Project gefördert)