Fragwürdige Sicherheit durch SRT AppGuard?

In den letzten Wochen wurde viel über eine neue “Security App” mit dem Namen “SRT AppGuard” geschrieben und berichtet, die am 05. Juli 2012 von der Fa. Backes SRT auf den Markt gebracht wurde. Die Fa. Backes SRT bezeichnet diese App als eine “innovative Android-Anwendung die es ermöglicht die Sicherheit Ihres Android-Geräts zu erhöhen”

Ob das so ist und was mir zu dem Ansatz von Backes SRT an Gedanken durch den Kopf geht möchte ich hier berichten.

Zunächst wurde die App im Google Play Store angeboten und auch ca. 40.000 Mal heruntergeladen. (Quelle:Saarbrücker Zeitung) Danach wurde die App “SRT AppGuard” aus dem Google Play Store verbannt und ist seither nur mehr von der Homepage des Herstellers herunter zu laden. Ich zumindest frage mich, warum Google zu dieser Maßnahme gegriffen hat, macht doch das Unternehmen, zumindest auf den ersten Blick, einen seriösen Eindruck und gibt vor um die Sicherheit des Anwenders bemüht zu sein.

Die Verbannung aus dem Google Play Store hinterlässt allerdings erste Kratzer an diesem Image wie ich finde, weil so ganz ohne Grund wird auch eine Fa. wie Google eine App nicht so einfach aus seinem App-Store verbannen. Aber schauen wir uns die Fakten mal der Reihe nach an und fällen unser Urteil am Schluss der Betrachtungen.

Was also macht dieser SRT AppGuard nun eigentlich?

In kurzen Worten würde sich das in etwa so lesen: Der SRT AppGuard analysiert ,deinstalliert modifiziert und installiert die jeweilige App erneut in einer modifizierten Version, die es dann ermöglicht gewisse “Sicherheits relevante Funktionen” zu deaktivieren, bzw. zu überwachen.

Die detailliertere Beschreibung liest sich dann so: Der SRT AppGuard ist eine Sicherheitssoftware für das mobile Betriebssystem Android. Sie ermöglicht dem Benutzer, das Verhalten von Android Apps von Drittanbietern zu überwachen und gegebenenfalls den Zugriff auf sicherheitskritische Systemressourcen zu verweigern. Der SRT AppGuard implementiert dazu folgende Funktionalität: Der Benutzer wählt eine bereits installierte App aus, die überwacht werden soll. Der SRT AppGuard untersucht den Bytecode (den kompilierten Quellcode) der App und identifiziert jene Instruktionen, die sicherheitsrelevante Funktionen der Android API (Android-Programmierschnittstelle, -Programmanbindung) aufrufen.

An diesen Stellen fügt der SRT AppGuard zusätzlichen Programmcode ein (Instrumentierung), der den Zugriff auf diese sicherheitsrelevanten Funktionen protokolliert und kontrolliert. Nach Abschluss dieses Prozesses wird die bestehende Original-App deinstalliert und durch die instrumentierte Version ersetzt; dieser Schritt muss durch den Benutzer explizit bestätigt werden.

 

Nur durch dieses Vorgehen ist die Funktionalität des SRT AppGuard gewährleistet. Sollten Sie mit dieser Funktionalität nicht einverstanden sein, installieren Sie den SRT AppGuard nicht.

(Quelle: Lizenzbedingungen der Fa. Backes SRT)

So weit so gut, aber was bedeutet das nun im Besonderen?

Rein rechtlich ist die App „SRT AppGuard“ schon höchst bedenklich – ich lasse mal AGB von Google außen vor. SRT AppGuard könnte aber zum einen urheberrechtlich problematisch sein, da in die Urheberrechte des Entwicklers der veränderten App nach 69a UrhG eingegriffen wird. Zwar ist die Bearbeitung der App für den privaten Gebrauch noch zulässig, jedoch dürften die Rechte aus § 14 UrhG (Entstellung) und auch §69c Nr. 2 UrhG (Zustimmungsbedürftige Handlungen bei Computerprogrammen) je nach Zweck der App beeinträchtigt sein. Zivilrechtlich also sehr bedenklich. Und auch strafrechtlich ist die App SRT AppGuard durchaus problematisch: Die Dekompilierung der App könnte einen Verstoß nach §§ 202a, 303a StGB bedeuten. Sollte der Hersteller von „SRT AppGuard“ sein Programm nicht selber getestet haben, könnte mit SRT AppGuard zumindest ein Programm zugänglich gemacht werden, welches eine Straftat nach 202a StGB ermöglich, was nach § 202c Abs. 1 Nr. 2 StGB strafbar sein könnte.

Anmerkung: Obige Angaben zum UrhG und StGB beziehen sich auf das Deutsche UrhG und StGB.

Der nächste, wichtige Punkt ist der verlorene Link der betroffenen, also von SRT AppGuard überwachten bzw. veränderten App, zum Google Play Store. Die betroffene, vom SRT AppGuard modifizierte App, wird keinerlei automatisierte Updates mehr aus dem Google Play Store erhalten, weil der Google Play Store dieses aufgrund der Modifikationen nicht mehr erkennen kann. Security Updates dieser App werden den Anwender also niemals erreichen!
Technisch begründet sich dies in der zwangsläufig veränderten Signatur der App, die der SRT AppGuard natürlich nicht erhalten kann. Der SRT AppGuard muss, bedingt durch die Modifikation der App, eine eigene Signatur in die App einfügen, damit diese auch vom Smartphone als valide anerkannt werden kann. (Ich werde hier beispielhaft später noch auf diesen Punkt eingehen)

Nicht unerwähnt sollte auch die Tatsache bleiben, dass die Modifikationen welche der SRT AppGuard in den App’s vornimmt, dazu führen können, dass die modifizierte App nicht mehr so funktioniert wie sie eigentlich sollte. Im Zweifelsfall kann das zu einer wesentlich höheren Gefährdung des Anwenders führen als ohne den SRT AppGuard.
(Auch hierzu werde ich später noch weitere Ausführungen schreiben)

Ein ebenfalls wichtiger Punkt, der an keiner Stelle Erwähnung findet, ist die Tatsache, dass eine durch den SRT AppGuard veränderte App nach der Deinstallation des SRT AppGuard wieder ganz normal funktioniert. Der SRT AppGuard muss also installiert bleiben, um die entzogenen Funktionen dauerhaft zu entziehen.

Zusammengefasst kann man also sagen, dass diese App unrechtmäßig andere Apps verändert, aktiv deren Update, bzw. die Benachrichtigung über Updates aus dem Google Playstore, verhindert und andere Apps ggf. sogar unbrauchbar macht.

Dem Anwender wird hier, meiner Meinung nach, eine doch sehr zweifelhafte Sicherheit vorgegaukelt, die in Wirklichkeit nicht besteht. Warum das so ist, möchte ich an einem praktischen Beispiel einmal demonstrieren.

Nehmen wir eine App, die sich auch um die Sicherheit des Anwenders bemüht, den Logman Logcat Überprüfung, eine von mir selber entwickelt App, an der ich auch die Urheberrechte halte. Diese App benötigt folgende Berechtigungen um zu funktionieren:

• Inhalt des USB-Speichers ändern/löschen
• Sensible Logdaten auslesen
• Telefonstatus und Identität lesen

Die wesentlichen Aufgaben dieser App bestehen darin, IMEI, IMSI, Telefonnummer und Seriennummer der Sim-Karte auszulesen und dann das Logcat des Devices nach Einträgen zu durchsuchen welche einen dieser Parameter beinhalten. Wir ein solcher Eintrag gefunden, wird der Anwender aktiv darauf hingewiesen und die Gefährdung wird ihm erklärt.

Nun habe ich den SRT-AppGuard installiert und ihn angewiesen diese App “Logman” zu überwachen. In einigen, durchaus als  Anwenderfreundlich zu bezeichneten Schritten, wurde nun folgendes vom SRT-AppGuard durchgeführt.

• Der Bytecode von Logman wurde untersucht (Decompilierung)
• Die Original App Logman wurde deinstalliert
• Der Bytecode von Logman wurde verändert (Instrumentierung)
• Die modifizierte App Logman wurde wieder installiert

Nach diesen Schritten taucht Logman in der Liste der zu überwachenden Apps auf. Ruft man nun im AppGuard den Eintrag “Logman” auf, erscheint eine Liste der von Logman verwendeten Berechtigungen und man hat die Möglichkeit bei gewissen Berechtigungen den Haken zu entfernen. (Standardmäßig sind immer noch alle Berechtigungen angehakt!)

In diesem Fall wird von SRT AppGuard lediglich die Berechtigung “Telefonstatus und Identität lesen” als kritisch eingestuft und ist somit abwählbar. Als nächstes habe ich also genau das getan und eben diese Berechtigung entzogen.

Als nächstes verlasse ich den SRT AppGuard und starte meine App Logman. Sie startet ganz normal und lässt mich auch den Scan des Logcat starten. Allerdings findet Logman keine Einträge und schreibt dies auch brav dem Anwender in der Meldung heraus. Vermittelt dem Anwender also, Du bist sicher, keine Anwendung auf Deinem Smartphone schreibt zu Zeit irgendwelche kompromittierenden privaten Daten ins Logcat.
Allerdings waren zu jenem Zeitpunkt faktisch kompromittierende Daten im Logcat vorhanden.
Ein erneuter Aufruf des SRT AppGuard und Aufruf des Menüpunktes “Überwachte Apps verwalten” sowie der Aufruf des Logs von AppGuard fördern dann zu Tage, dass verhindert wurde die SimSerial, die SubscriberID, die DeviceID sowie die Line1Number (Telefonnummer) auszulesen.

Meiner App Logman wurde also nicht die Berechtigung entzogen diese Daten auszulesen, sondern es wurde durch Veränderung meines Applikationscodes unterbunden diese Daten auszulesen und für die Dauer der Überprüfung zu speichern. Ansonsten hätte es in meiner App zu einer Fehlermeldung führen müssen.
Dies hat effektiv verhindert, die definitiv zu diesem Zeitpunkt vorhandene IMSI im Logcat aufzufinden, da der Vergleichsstring der IMSI gefehlt hat.

Innerhalb meiner Anwendung Logman hat das zu keiner Fehlermeldung geführt und es gab keinerlei Hinweis darauf, dass diese Daten nicht ausgelesen werden können.
Der Anwender glaubt also er ist sicher, obwohl er es in Wirklichkeit gar nicht ist. Würde der Anwender nun in gutem Glauben sein Logcat an irgendjemanden weitergeben, würde die IMSI an Dritte übermittelt werden.

Der SRT AppGuard gaukelt dem Anwender hier eine doch eher sehr zweifelhafte Sicherheit vor, denn die wenigsten Anwender dürften in der Lage sein, beurteilen zu können, welche Funktionen sie in einer App lahmlegen können ohne die Grundfunktionalität dieser App damit wesentlich zu beeinflussen.

Nun spinnen wir den Faden noch ein wenig weiter. Angenommen, ich hätte bei der Entwicklung meiner App Logman wirklich einen groben Fehler begangen und es gäbe ein Sicherheitsproblem mit meiner App. Ein Aufmerksamer und Verantwortungsvoller Anwender macht sich die Mühe, mir eine E-Mail zu schreiben, in der er mich auf diesen Umstand hinweist.
Als ebenso Verantwortungsvoller Entwickler, setze ich mich natürlich sofort an die Behebung dieses Problems und veröffentliche ein Update im Google Play Store. Alle Anwender meiner App Logman würden somit, spätestens im Verlauf eines Tages, von diesem Update automatisch benachrichtigt und können das Security Update von Logman installieren.

Alle Anwender? Nein, leider nicht. Diejenigen Anwender, welche Logman mit dem SRT AppGuard überwachen, haben leider keine Benachrichtigung bekommen und müssten nun weiterhin mit der unsicheren Version der App Logman leben in der wichtige und sensible Daten gefährdet wären. Dies liegt daran, dass SRT AppGuard beim erneuten Kompilieren meiner mittlerweile ja veränderten App Logman, eine andere Signatur verwenden musste. SRT AppGuard hat ja keinen Zugriff auf meine verschlüsselte Signatur. Somit wurde also aktiv verhindert, dass diese App jemals auf dem Device des Anwenders Updates des Entwicklers empfangen kann.

Resümee
Ich will gar nicht abstreiten, dass es so manche App gibt, die mehr als zweifelhafte Berechtigungen mit sich bringt und dass sich darunter auch so manch eine Malware befindet, die sicherlich nicht zum Besten des Anwenders ist und Schaden anrichten kann.

Nur ist es, zumindest in meinen Augen, mindestens genauso zweifelhaft, dem Anwender, vollmundig eine sogenannte “Sicherheit” zu versprechen, die eigentlich gar nicht gegeben ist.

Es ist wohl besser, wenn man Apps, die zweifelhafte Rechte fordern, gar nicht erst auf seinem Smartphone installiert, anstatt sich auf derartige Apps wie den SRT AppGuard zu verlassen.

Mein besonderer Dank geht an Lars von Allaboutsamsung.de der mir zu den Rechtlichen Fragen zum Urheber und Strafrecht wertvollen Input geliefert hat.

 

31.07.2012. Nachtrag:

Da es teilweise angezweifelt wurde, dass die App „SRT AppGuard“  tatsächlich bestehende Apps rekompiliert, habe ich trotz ich persönlich davon überzeugt war noch mal ein wenig tiefer nachgeforscht.

Ich habe es ausprobiert an einer meiner eigenen Apps, bei denen mich keiner, Rechtlich betrachtet, davon abhalten kann das zu dekompilieren.
Näher betrachtet habe ich dabei das in der App befindliche Dex-file, welches im wesentlichen den „Bytecode“ beinhaltet, also die in der VM auf dem Device zur Ausführung gelangenden Codebestandteile.

1. Originalgröße des unveränderten classes.dex 31.184 KB
2. Größe der classes.dex nach der Veränderung durch SRT AppGuard: 140.948 KB

Von 31 KB auf 140 KB … hoppala .. da muss aber schon deutlich etwas hinzugefügt worden sein!

Dann habe ich weiter die beiden Code Trees verglichen. Im von „SRT AppGuard“ veränderten classes.dex ist ein ganzer Verzeichnis Tree dazu gekommen.
srt/appguard/mobile/service
srt/appguard/monitor[….]

mit weiteren unterverzeichnissen!)
Dann habe ich die Größen der beiden Hauptklassen meiner App verglichen:
1. Original Code LogmanActivity : 75 KB
2. Recompilierter Code LogmanActivity: 81 KB
Hinzugefügte Codegröße: 6 KB

3. Original Code ShowList: 14 KB
4. Recompilierte ShowList: 15 KB
Hinzugefügte Codegröße: 1 KB

Bei näherer Untersuchung werden bspw. Methodenaufrufe wie folgt umgebogen:
invoke-static {v0}, Lcom/srt/appguard/monitor/MonitorInterface;->android_telephony_TelephonyManager__getDeviceId(Landroid/telephony/TelephonyManager;)V

sowie bspw.:
.catch Lcom/srt/appguard/monitor/exception/MonitorException; {:try_start_1b .. :try_end_21} :catch_6e

Diese Untersuchung habe ich mit dem Smali/Backsmali Tool vorgenommen.

SRT AppGuard benötigt KEIN Root. Er ist darauf angewiesen, die Apps zu deinstallieren und recompiliert wieder neu zu installieren.