Und wieder eine Sicherheitslücke in der Luca App (für Android)

Ladet euch mal spaßeshalber die Luca App mit Raccoon herunter. Wenn ihr euch ein bisschen mit Android und App Sideloading auskennt, werdet ihr vermutlich eine APK Datei erwarten. Was ihr stattdessen bekommt ist das hier:

Großartig, ein App Bundle!

Was sind App Bundles?

Ursprünglich wurden Android Apps ausschließlich als eine einzige APK Datei bereit gestellt. Das ist im wesentlichem ein ZIP Archiv, das den Programmcode, Grafiken, Übersetzungen, sowie haufenweise Metadaten enthält. APK Dateien haben zwei Probleme:

1. Da ist alles drin was man braucht und auch was man nicht braucht (z.B. Grafiken für andere Bildschirmgrößen). Das kostet Speicherplatz auf dem Gerät.
2. APK Dateien lassen sich wunderbar einfach kopieren und können auch von Laien relativ einfach installiert werden. Das ist eine Gefahr für Play’s Monopolstellung.

Also kam Google bei Android 5 mit einem neuem Paketformat um die Ecke: App Bundles. Hierbei wird die App in mehrere APK Dateien aufgespalten und das Gerät lädt dann nur diejenigen, die es wirklich benötigt. Spart Platz, spart Zeit, ist und ist nahezu unmöglich irgendwo anders als auf Play zu hosten.

Entwickler haben die Wahl, ob sie ihre Apps als Bundle oder als traditionelle APK bereitstellen wollen. Wer den Köder “kleinere Apps” schluckt (die tatsächliche Ersparnis ist in der Praxis meist marginal), bindet sich auf Gedeih und Verderb an Play.

Ok, aber warum sind kleinere Dateien jetzt ein Sicherheitsrisiko!?

Traditionelle APK Dateien müssen vom Entwickler signiert werden. Andernfalls installiert das Android System sie nicht. Für alle Updates muss derselbe Schlüssel verwendet werden.

Anmerkung Es gibt für Android Apps keine Certificate Authority. Stattdessen wird darauf vertraut, dass bei der Erstinstallation eine original APK verwendet wird und dann nur geprüft, ob Updates aus derselben Quelle stammen. Das Sicherheitskonzept ist natürlich halbherzig, aber besser(?) als gar nichts.

Die Situation, die Google unbedingt vermeiden wollte ist, dass irgendwann eine staatliche Drei Buchstaben Organisation auf der Matte steht und sagt: “Hey, auf Play kann man doch nur mit Benutzerkonto zugreifen, richtig? Klasse! Es gibt da diese Person, die neuerdings über einen verschlüsselten Messenger kommuniziert. Wir würden da gerne mitlesen. Hier habt ihr den Kontonamen und eine trojanisierte Version des Messengers. Bitte genau diesem Nutzer als Update unterschieben.”

Bei traditionellen APKs ist ausgeschlossen, dass Google nachträglich ein manipuliertes Update installieren kann. Bei App Bundles sieht das anders aus. Hier lädt der Entwickler sein kompiliertes Android Studio Projekt, inklusive seines privaten Schlüssels hoch. Paketierung und Signierung geschieht dann durch Google Play:

An Android App Bundle is a publishing format that includes all your app’s compiled code and resources, and defers APK generation and signing to Google Play.

Wenn Google signieren soll, dann braucht Play den privaten Schlüssel. Wenn man irgendwo seinen privaten Schlüssel hochladen soll, weiß man, dass da was grundsätzlich faul ist. Die Corona Warn App macht es an der Stelle übrigens richtig und setzt auf ein traditionelles APK.

Zur Kontrolle: wer hat signiert?

Schauen wir sicherheitshalber mal in die APK Datei rein:

unzip -p de.culture4life.luca-57.apk META-INF/BNDLTOOL.RSA | keytool -printcert

Sieht nach einem Google Zertifikat aus:

Eigentümer: CN=Android, OU=Android, O=Google Inc., L=Mountain View, ST=California, C=US
Aussteller: CN=Android, OU=Android, O=Google Inc., L=Mountain View, ST=California, C=US
Seriennummer: 31680621e4bc6eae28c8fccada7325d75931e267
Gültig von: Wed Sep 16 18:17:38 CEST 2020 bis: Fri Sep 16 18:17:38 CEST 2050
Zertifikatfingerprints:
	 MD5: 48:F3:F6:71:22:DE:02:B3:15:AA:E4:30:11:A4:E9:1A:B1:35:A6:18
	 SHA1: A8:C7:46:91:61:79:0A:17:17:F6:0C:F1:75:E3:2B:3D:1D:99:72:D8:C7:94:06:F5:E1:E1:FB:57:91:60:AD:74
	 SHA256: SHA256withRSA
Signaturalgorithmusname: 4096-Bit-RSA-Schlüssel
Algorithmus des Public Key von Betreff: 3
Version: {10}

Erweiterungen: 

#1: ObjectId: 2.5.29.19 Criticality=false
BasicConstraints:[
  CA:true
  PathLen:2147483647
]

Man muss an der Stelle natürlich betonen, dass das hier Murks im Android Ökosystem ist. Aber wenn man sicherheitskritische Apps baut, dann sollte man vermutlich die Schlüsselverwaltung nicht delegieren.

Aber das ist jetzt schon ein bisschen paranoid, oder?

Die Luca App ist kein Messenger, allerdings ist für es für die Funktion des Systems wichtig, das sich Gäste beim Verlassen einer Veranstaltung auschecken. Da dies leicht vergessen werden kann, verfügt die App über eine automatische Checkout Funktion, basiert auf Geofencing und Standortdaten. Standortdaten sind, im Gegensatz zur Funkzellenortung metergenau und damit für “Sicherheits”behörden hochgradig interessant.

Über den Einsatz des/eines Bundestrojaners streiten wir jetzt seit mittlerweile über einem Jahrzehnt. Mit dem de-facto Zwang zur Luca Nutzung wachsen hier gerade Dinge zusammen, die nicht zusammen wachsen sollten.