Suche
Neues vom Androiden-Planeten

Planet Android: Safety first, PHAs und Google Play Billing Library

Carina Schipper

   © Software & Support Media

Sicherheit ist auch bei Smartphones ein ganz heißes Thema. Immer wieder tauchen neue Malware-Varianten auf und sorgen für Schlagzeilen. Jetzt ist ein neuer Android-Schädling namens Red Alert 2.0 auf der Bildfläche erschienen. Wir bleiben beim Thema und schauen uns an, wie sich Apps unter Android Orio sicherer installieren lassen und sprechen über sogenannte PHAs.

Banking-Trojaner Red Alert 2.0 bedroht Android-User

Ein neuer Android-Schädling treibt derzeit sein Unwesen. IT-Sicherheitsforscher von SfyLabs B.V. haben den Mobile-Banking-Trojaner namens Red Alert 2.0 entdeckt und sprechen von über 60 betroffenen Banken und Social-Apps. Prinzipiell unterscheidet sich der jüngste Spross der Android-Banking-Trojaner-Familie nicht sehr von seinen Verwandten. Red Alert 2.0 benutzt wie sie Popup-Overlays, um Benutzername und Passwort seines Opfers zu stehlen und besitzt die Fähigkeit, SMS-Nachrichten abzufangen oder Kontaktdaten auszulesen. Allerdings sorgt der Schadcode etwas vehementer für sein Überleben als seine Vorgänger. Er befindet sich in der Lage, eingehende Anrufe von Banken zu blockieren und zu protokollieren. Der ahnungslose Bankkunde kann zunächst nicht über die böswilligen Aktivitäten informiert werden.

Der Angriffsvektor für Red Alert 2.0 ist ein alter Bekannter. Der Android-Trojaner verbreitet sich mithilfe gefälschter Apps, die in Drittanbieter-App-Stores gelistet sind, und über Google Play mittels der üblichen Verdächtigen, wie Messaging-Apps, Image-Tools oder Flash-Player, die den Schadcode verstecken. Allerdings berichten die IT-Sicherheitsforscher bei SfyLabs B.V. auch von einer Art bösartigem Geniestreich. Die Cyberkriminellen hinter Red Alert 2.0 haben es offenbar geschafft, eine Command-and-Control-Server-Redundanz in den Trojaner zu integrieren. Die Forscher beobachteten, dass der Softwareschädling, als er nicht in der Lage war, den C&C-Server zu kontaktieren, der von den Bedrohungsakteuren kontrolliert wird, stattdessen Konten auf Twitter kontaktierte, um aktualisierte Serverinformationen abzurufen.

Eigentlich ziele diese Art von Angriff auf Desktop-PCs ab, so die Experten bei SfyLabs B.V.. Dies führe sie zu der Annahme, dass Cyberkriminelle ihren Fokus verlagern und sich verstärkt auf die Entwicklung von Mobile-Malware konzentrieren. Welche Dimensionen die Verbreitung von Red Alert 2.0 bisher angenommen hat, ist nicht bekannt. Allerdings lässt sich der Trojaner laut Bleeping Computer im Darknet mieten, wo er sich scheinbar großer Beliebtheit erfreut. Fast jeden zweiten Tag würden neue HTML-Overlays erstellt, heißt es.

Mehr Sicherheit beim Installieren von Apps unter Android Oreo

Besonders wachsamen Android-Nutzern wird es bereits aufgefallen sein: In Android-Oreo ist die Einstellungsmöglichkeit unbekannte Quellen zulassen verschwunden. Der Ersatz heißt Install unknown apps permission und soll mehr Sicherheit für User und Developer nach sich ziehen. Der Großteil sogenannter Potentially Harmful Apps (PHAs) stammt aus Drittquellen. Die übliche Strategie der PHA-Autoren besteht darin, ihre Apps über einen Hostile-Downloader auszuliefern. Eine Gaming-App, die selbst gar keinen Schadcode enthält, könnte beispielsweise den User über ein wichtiges zu installierendes Sicherheitsupdate informieren, hinter dem in Wirklichkeit eine PHA steckt.

Unter Android Oreo sorgt die Install unknown apps permission für mehr Sicherheit beim Installieren von Apps aus unbekannten Quellen. Die Install unknown apps permission ist an die Anwendung gebunden, die die Installation – wie andere Laufzeitberechtigungen auch – anfragt und gewährleistet, dass der Benutzer die Berechtigung zur Verwendung der Installationsquelle erteilt, bevor er den Benutzer zur Installation einer App auffordern kann. Die neue Permission schafft Transparenz, Kontrolle und verschlankt den Prozess, Installationen aus vertrauenswürdigen Quellen zu ermöglichen. Einstellungen zeigt die Liste der Apps, die der Benutzer für die Installation unbekannter Apps freigegeben hat und die Berechtigung für eine bestimmte App lassen sich jederzeit widerrufen.

Änderungen für Entwickler

Um dieses neue Verhalten für sich zu nutzen, müssen Entwickler von Apps, die das Herunterladen und Installieren anderer Apps via Package-Installer erfordern, einige Änderungen vornehmen. Wenn eine App einen targetSdkLevel von 26 oder höher verwendet und den Benutzer auffordert, andere Apps zu installieren, muss die Manifestdatei die Berechtigung REQUEST_INSTALL_PACKAGES enthalten:

<uses-permission android:name="android.permission.REQUEST_INSTALL_PACKAGES" />

Apps ohne diese Berechtigung können keine anderen Apps installieren. Sie können sich dafür entscheiden, Ihre User unterbrechbar zur Install unknown apps permission-Seite weiterzuleiten, indem Sie ACTION_MANAGE_UNKNOWN_APP_SOURCES verwenden. Der Status dieser Berechtigung lässt sich auch mithilfe der Package-Manager canRequestPackageInstalls() API abfragen.

SafetyNet Verify Apps API: Google Play Protect auf Knopfdruck

Gerade sprachen wir von PHAs – Google Play Protect, das die Sicherheitsfunktion von Verify Apps enthält, schützt Benutzer vor genau solchen schädlichen Anwendungen. Google Play Protect ist auf allen Android-Geräten mit installiertem Google Play verfügbar. Es sorgt für Sicherheit und verschafft Nutzern Einblicke bezüglich des Sicherheitsstatus ihrer Geräte. App-Entwicklern eröffnet die SafetyNet Verify Apps API ähnliche Sicherheitseinblicke in Landschaft der installierten Apps auf den Endgeräten der Benutzer. Die neue API-Suite zeigt ihnen, ob das Gerät des Benutzers den Schutz von Google Play Protect genießt. Sie besitzen ebenfalls die Möglichkeit, Benutzer, die Google Play Protect noch nicht einsetzen, dazu zu motivieren, es zu tun. Zusätzlich können Entwickler jegliche bekannte PHA, die sich auf dem Gerät befindet identifizieren.

Für Entwickler von Anwendungen, die von installierten PHAs beeinflusst werden, profitieren besonders von den neuen APIs. Festzulegen, dass Google Play Protect mit enableVerifyApps () aktiviert ist, gibt Entwicklern zusätzliche Sicherheit, dass ein Gerät höchstwahrscheinlich „sauber“ ist. Wenn auf einem Gerät Google Play Protect nicht aktiviert ist, können Entwickler den Benutzer auffordern, Google Play Protect mit enableVerifyApps () zu aktivieren. Mithilfe eines aktivierten Google Play Protects können sie die listHarmfulApps()-Method verwenden, um festzustellen, ob das Geräte eines Nutzers eine PHA aufweist. Die Suite erfordert keine API-Schlüssel und kein Anfragekontingent.

Gerade für unternehmensfokussierte Anwendungen bringt die Verify Apps-API einige Vorteile mit sich. In der Konzeption von Enterprise-Apps auf der Absicherung der Daten eines Unternehmens vor der Außenwelt. Diese Apps implementieren oft strenge Durchsetzung. Als Beispiel hierfür dient die Sicherstellung, dass das mobile Endgerät vom Unternehmen genehmigt ist und ein sicheres Passwort für die Sperrbildschirme benötigt. Entspricht das mobile Endgerät nicht allen Kriterien, kann das Unternehmen Login-Daten entziehen und sensible Daten vom Gerät entfernen. Einen Mechanismus zur Durchsetzung von Google Play Protect und zum Scannen nach PHAs einzusetzen, ist eine weitere Möglichkeit zur Unterstützung von App-Entwicklern in Unternehmen, um Unternehmensdaten und -geräte abzusichern.

Zum besseren Schutz sollten Entwickler die Attestierungs-API in Kombination mit der neuen Verify Apps API einsetzen. Sie sollten die Attestation-API zunächst benutzen, um festzustellen, dass das Gerät nicht modifiziert wurde. Wenn das Android-System vertrauenswürdig ist, können auch die Ergebnisse der Verify Apps-API vertrauenswürdig sein. Bestehende Benutzer der Attestierungs-API können zusätzliche Vorteile aus der Verwendung der Verify Apps-API zeihen, da sie in der Lage sein dürfte, PHAs auf dem Gerät ausfindig zu machen. Generell wird die Verwendung mehrerer Signale zur Erkennung von Anti-Abuse Detection empfohlen.

Um zu erfahren, wie Sie diese API in Ihrer Anwendung verwenden können, werfen Sie bitte einen Blick aus die developer docs.

Lesen Sie auch: Sicherheit für Android Oreo & unser Quickvote zu Android P

Die Google Play Billing Library 1.0 ist da

Kostenpflichtige Apps und In-App-Käufe sind keine Seltenheit. Mithilfe der Play Billing Library 1.0 möchte Google Android-App-Entwicklern mehr Zeit verschaffen, sich auf die Arbeit an ihren Apps zu konzentrieren. Sie soll den Entwicklungsprozess für Google Play Billing vereinfachen und steht über das Maven-Repository zur Verfügung. Die neue Bibliothek lässt sich über folgende Dependency in die build.gradle Datei einer App integrieren:

dependencies {
    ...
    compile 'com.android.billingclient:billing:1.0'
}

Sie ergänzt automatisch die APK um die Berechtigung com.android.vending.BILLING, was bedeutet, dass der Entwickler sie nicht mehr manuell ins Manifest des Anwendungsmoduls aufnehmen muss.

BillingClient and PurchasesUpdatedListener

Beide Klassen verkörpern während der Integration der Bibliothek in eine Android-App die zwei wichtigsten Bestandteile. Der BillingClient schlägt eine Brücke zwischen der App und Google Play. Er lässt sich für die Auflistung der verfügbaren Produkte, das Starten des Abrechnungsprozesses für In-App-Produkte oder Abonnements (d. h. das Öffnen der Zahlungsschnittstelle), das Abrufen von Benutzerkäufen und das Erstellen oder Ändern von Abonnements einsetzen. Um einen BillingClient zu erstellen, muss der Programmierer einen PurchasesUpdatedListener einrichten. Dieser Schritt versetzt die App in die Lage, Updates seitens der In-app-Billing API zu erhalten. Dazu gehören Transaktionsergebnisse nach dem Abrechnungsprozess und Käufe, die außerhalb der App getätigt wurden, beispielsweise, wenn ein Benutzer einen Promo-Code eingelöst oder ein Produkt auf einem anderen Gerät erworben hat.

Der anschließende Code veranschaulicht, sich die onPurchasesUpdated()-Methode ihres PurchasesUpdatedListeners überschreiben lässt:

@Override
void onPurchasesUpdated(@BillingResponse int responseCode,
        List<Purchase> purchases) {
    if (responseCode == BillingResponse.OK
            && purchases != null) {
        for (Purchase purchase : purchases) {
            handlePurchase(purchase);
        }
    } else if (responseCode == BillingResponse.USER_CANCELED) {
        // Handle an error caused by a user canceling the purchase flow.
    } else {
        // Handle any other error codes.
    }
}

In Abhängigkeit von der Architektur der App hat der Entwickler die Möglichkeit, den PurchasesUpdatedListener in seiner Activity oder in jeder beliebigen anderen Klasse zu implementieren. Der Code für die Erstellung der BillingClient Instanz und das Setzen des PurchasesUpdatedListener sieht so aus:

mBillingClient = BillingClient.newBuilder(mContext)
                              .setListener(mPurchasesUpdatedListener)
                              .build();

Listing und Selling von Produkten

Schritt eins, um Produkte in einer App zu verkaufen lautet, diese zuerst über die Play Console hinzuzufügen. Falls es sich allerdings um eine neue App handelt, muss der Entwickler diese zunächst im Alpha- oder Beta-Vertriebskanal veröffentlichen. Der Befehl querySkuDetailsAsync() liefert eine Liste der Produktdetails und Preise für den aktuellen User. Zusätzlich muss ein Listener festgelegt werden, der das SkuDetailsResponseListener-Interface implementiert. Das folgende Codebeispiel zeigt, wie sich die onSkuDetailsResponse()-Methode, die den Listener benachrichtigt, wenn die Abfrage beendet wird, überschreiben lässt:

List<String> skuList = new ArrayList<> ();
skuList.add("premiumUpgrade");
skuList.add("gas");
SkuDetailsParams.Builder params = SkuDetailsParams.newBuilder();
params.setSkusList(skuList).setType(SkuType.INAPP);
mBillingClient.querySkuDetailsAsync(params.build(),
    new SkuDetailsResponseListener() {
        @Override
        public void onSkuDetailsResponse(SkuDetailsResult result) {
            // Process the result.
        }
    })

Nachdem der Benutzer sich dazu entschieden hat, ein Produkt zu kaufen, muss der Entwickler den Abrechnungsprozess einleiten und das Transaktionsergebnis bearbeiten. Um eine Kaufanfrage von einer App aus zu starten, muss die launchBillingFlow()-Methode auf dem Play Billing Library Client aufgerufen werden. Diese und alle anderen BillingClient-Methoden müssen über den UI-Thread aufgerufen werden. Die Methode launchBillingFlow() erfordert ein BillingFlowParams-Objekt, das alle relevanten Informationen enthält, um den Kauf abzuschließen. Dazu gehören beispielsweise die Produkt-ID des Kaufobjekts und der Produkttyp. Um die Instanz BillingFlowParams zu erhalten, lässt sich die newBuilder()-Methode heranziehen:

BillingFlowParams.Builder builder = BillingFlowParams
                                       .newBuilder()
                                       .setSku(skuId).setType(SkuType.INAPP);
int responseCode = mBillingClient.launchBillingFlow(builder.build());

Produkte konsumieren

Standardmäßig werden alle In-App-Produkte verwaltet. Konkret heißt das, Google Play verfolgt den Produktbesitz und verbietet es, mehrmals zu kaufen. Um ein Produkt erneut kaufen zu können, muss es verbraucht werden bevor es wieder verfügbar wird.

Um ein Produkt zu konsumieren, muss die consumeAsync()-Methode auf dem Play Billing Library Client aufgerufen und der beim Kauf erhaltene Wert in den purchaseToken-String eingeflochten werden. Das Konsumergebnis kommt über die onConsumeResponse()-Methode der ConsumeResponseListener-Schnittstelle zurück. Diese muss der Entwickler überschreiben, um das Vebrauchsergebnis zu bearbeiten. Das folgende Beispiel beschreibt, wie man ein Produkt mithilfe des dazugehörigen purchaseTokens konsumiert:

ConsumeResponseListener listener = new ConsumeResponseListener() {
    @Override
    public void onConsumeResponse(@BillingResponse int responseCode, 
                                  String outToken) {
        if (responseCode == BillingResponse.OK) {
            // Handle the success of the consume operation.
            // For example, increase the number of player's coins,
            // that provide temporary benefits
        }
    }
};
mBillingClient.consumeAsync(purchaseToken, listener);

Sample updated: Trivial Drive V2

Eine neue Bibliothek bringt ein neues Sample mit sich. Damit Entwickler sich leichter tun, zu verstehen, wie sich die In-App-Abrechnung in ihrer App mit der neuen Play Billing Library implementieren lässt, wurde das Trivial Drive Sample komplett überholt. Trivial Drive ist seit 2013 auf den Markt. Seitdem ist das Android-Ökosystem kräftig gewachsen und viele neue Funktionen, Geräte und Plattformen sind hinzugekommen. Um diese Entwicklung widerzuspiegeln, läuft das Trivial Drive v2 Sample nun auch auf Android TV und Android Wear.

Geschrieben von
Carina Schipper
Carina Schipper
Carina Schipper ist seit 2017 Redakteurin beim Java Magazin, Business Technology und JAXenter. Sie hat Germanistik und Europäische Ethnologie / Volkskunde an der Julius-Maximilians-Universität Würzburg studiert.
Kommentare
  1. lolnexus2017-09-29 05:05:55

    I have enjoyed reading many of the articles and posts contained on the website, keep up the good work and hope to read some more interesting content in the future.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.