Kriterien und Entwicklungsrichtlinien für Smartphone-Apps · 2017-07-13 · Jailbreaks / Rooting...

transcript

Kriterien und Entwicklungsrichtlinien für Smartphone-Apps

Agenda

§ Grundlagen zur Sicherheit des Umfelds

§ Typische Fragestellungen

§ Analyse fremder Apps

§ Anforderungen an eigene Apps

§ Zusammenfassung

Tastatureingaben bei Samsung

§ Komfortfunktion sichert und schlägt vor …

§ Inklusive der Passwörter

Quelle: Heise

Fingerprint im neuen iPhone?

Daten im iTunes-Backup

Zugriff auf iTunes-Backups

Zugriff auf iTunes-Backup

Jailbreaks / Rooting als Gefahr für Apps

§ Methode, um administrativen Zugriff zu erlangen / nicht signierten Code auszuführen

§ Motivation:

– Installation von beliebiger Software, Freischalten von Features

§ Jailbreak deaktiviert integrierte Sicherheitsmechanismen

– Bspw. Code Signing

§ Ermöglicht Applikationen im root-Kontext

§ Alles wird möglich

– Spyware (FlexiSpy, MobileSpy etc.)

– Trojaner (PoC durch Sogeti auf der HITB)

– Würmer (ikee, Duh etc.)

– Durchbrechen der Sandboxen

Malware als Bedrohung für die Daten

§ Vor allem bei Android

– Strategisch als offene Plattform

– Kein Code-Signing wie bei iOS (ggf. in künftigen Enterprise Versionen)

– Erkennung seit Version 4.2

– Studie zeigte 15% Erkennungsrate, japanische IPA rät von Google Play ab …

– Die meisten Geräte verwenden Android mit Versionen älter als 4.x

§ Bei iOS bisher keine großen Mailware-Probleme

– Aber auch hier wurde demonstriert, dass die AppStore-Prüfungen umgangen werden können

F-Secure

Bedrohung durch Malware / Jailbreaks:Man in the App bei iOS / Android

§ Auf einem Gerät mit Jailbreak kann man Code in Apps injizieren

– Entschlüsseln und Herauskopieren / Versenden von verschlüsselten Inhalten

– Deaktivieren der Jailbreak-Detection des MDM-Agenten

§ Beispiel:

– Cycript für iOS

Cycript

28.09.2012

§ Für was ist Cycript gedacht?

– “A programming language designed to blend the barrier between Objective-C and JavaScript”

– Erlaubt das Schreiben von iOS Apps in Javascript.

§ Für was kann man es noch benutzen?

– “Cycript” bietet die Möglichkeit, sich mit “–p” an einen Prozess anzuhängen.

– Somit kann auf alle Objekte des Prozesses zugegriffen werden

– Funktionen, Variablen und Klassen können zur Laufzeit geändert werden.

– Erst indirekt ein Thema, da bisher kein Bruteforcing möglich

§ BootRom-Fehler im iPhone 5?

– Bisher nicht öffentlich, noch nicht ausnutzbar

– Falls ein solcher Fehler öffentlich wird, sind lange PIN-Codes entscheidend für die Sicherheit der Mails und der KeyChain

Android und Windows Phone 8

§ Debug-Mode bei Android ermöglicht Auslesen

§ Trusted Boot bei Windows Phone 8 bisher nicht gebrochen

Sichere Apps (für Smartphones und Tablets)

Fragen zu „sicheren Apps“

§ Wie analysiert man fertige Apps ohne Quellcode

§ Wie machen wir unsere eigenen Apps sicher?

– Schutz der Daten auch auf nicht vertrauenswürdigen Privatgeräte / Kundengeräten

– Gejailbreakte / gerootete Geräte

– Steckt sogar Intellectual Property in der App selbst?

– Schutz vor Raubkopierern, Reverse Engineering etc.

– Wie kommunizieren wir, wie authentisieren wir?

Das „Manifest“ bei Android

ACCESS_WIFI_STATE Allows applications to access information about Wi-Fi networks ACCOUNT_MANAGER Allows applications to call into AccountAuthenticators.ADD_VOICEMAIL Allows an application to add voicemails into the system.AUTHENTICATE_ACCOUNTS Allows an application to act as an AccountAuthenticator for the AccountManager BATTERY_STATS Allows an application to collect battery statistics BIND_ACCESSIBILITY_SERVICE Must be required by an AccessibilityService, to ensure that only the system can bind to it.BIND_APPWIDGET Allows an application to tell the AppWidget service which application can access AppWidget's data.BIND_DEVICE_ADMIN Must be required by device administration receiver, to ensure that only the system can interact with it.BIND_INPUT_METHOD Must be required by an InputMethodService, to ensure that only the system can bind to it.BIND_REMOTEVIEWS Must be required by a RemoteViewsService, to ensure that only the system can bind to it.BIND_TEXT_SERVICE Must be required by a TextService (e.g.BIND_VPN_SERVICE Must be required by an VpnService, to ensure that only the system can bind to it.BIND_WALLPAPER Must be required by a WallpaperService, to ensure that only the system can bind to it.BLUETOOTH Allows applications to connect to paired bluetooth devices BLUETOOTH_ADMIN Allows applications to discover and pair bluetooth devices BRICK Required to be able to disable the device (very dangerous!).BROADCAST_PACKAGE_REMOVED Allows an application to broadcast a notification that an application package has been removed.BROADCAST_SMS Allows an application to broadcast an SMS receipt notification BROADCAST_STICKY Allows an application to broadcast sticky intents.BROADCAST_WAP_PUSH Allows an application to broadcast a WAP PUSH receipt notification

CALL_PHONE Allows an application to initiate a phone call without going through the Dialer user interface for the user to confirm the call being placed.

CALL_PRIVILEGED Allows an application to call any phone number, including emergency numbers, without going through the Dialer user interface for the user to confirm the call being placed.

CAMERA Required to be able to access the camera device.CHANGE_COMPONENT_ENABLED_STATE Allows an application to change whether an application component (other than its own) is enabled or not.CHANGE_CONFIGURATION Allows an application to modify the current configuration, such as locale.

Allows applications to discover and pair bluetooth devices

Allows an application to initiate a phone call without going through the Dialer user interface for the user to confirm the call being placed.

Required to be able to access the camera device.

Reverse Engineering: Android

§ Typisches Vorgehen:

– Backup der App mittels ES Datei Explorer o.ä. erstellen (https://play.google.com/store/apps/details?id=com.estrongs.android.pop&hl=de)

– Daraus resultierende .apk Datei mittels Winrar entpacken

– Enthaltene classes.dex Datei mittels dex2jar in jar-Paket umwandeln (https://code.google.com/p/dex2jar/)

– jar-Paket mittels JD-GUI o.ä. dekompilieren oder gegebenenfalls mit Winrar entpacken und .class-Dateien mit jad dekompileren.

Alternative mit ART

– Dekompiliert Apps in „smali“ und bietet die Möglichkeit, die App zu bearbeiten und anschließend direkt wieder richtig zu packen.

.class public LHelloWorld;

.super Ljava/lang/Object;

.method public static main([Ljava/lang/String;)V

.registers 2

sget-object v0, Ljava/lang/System;->out:Ljava/io/PrintStream;

const-string v1, "Hello World!"

invoke-virtual {v0, v1}, Ljava/io/PrintStream;->println(Ljava/lang/String;)V

return-void.end method

Reverse-Engineering: IOS

§ Um die App zu dekompilieren, muss sie zuerst entschlüsselt werden.

§ Tool „Clutch“ (Cydia) entschlüsselt die App auf dem Gerät und erstellt anschließend eine .ipa-Datei.

§ Diese kann nun mit WinRar entpackt werden und das Binary mit IDA Pro dekompiliert werden.

Reverse-Engineering Windows Phone 8

§ Apps in .NET

§ .NET Reflector etc. erlaubt direkte Manipulation

§ Aber:

– Ohne Jailbreak (Windows Phone 8)bekommt man Apps bisher nicht vom Telefon

Reverse-Engineering von .NET

28.09.2012

Zusammenfassung: Analyse von Apps

§ Reverse Engineering meist gar nicht so kompliziert

– Zeigt das Innenleben der Apps auch ohne Quellcode

– Muss bei der Verarbeitung von vertraulichen Daten in Apps berücksichtigt werden!

Anforderungen an eigene Apps

Erste Anforderung

§ Eigenes Sicherheitskonzept je Applikation

– Sollte in einem SSDLC verankert sein

§ Daten klassifizieren

– Welche Daten werden von der App verarbeitet / gespeichert?

– Wie hoch sind die Schutzanforderungen?

§ Daraus lassen sich Anforderungen ableiten an

– Verschlüsselung, Authentisierung und Session-Management

– Schutz vor gerätespezifischen Bedrohungen

§ Entwicklungsrichtlinien und klare Vorgaben

– Für eigene Entwickler

– Als Vertragsbestandteil für externe Software-Firmen

OWASP Top 10 Mobile Risks(Release Candidate v1.0)

§ Insecure Data Storage

§ Weak Server Side Controls

§ Insufficient Transport Layer Protection

§ Client Side Injection

§ Poor Authorization and Authentication

§ Improper Session Handling

§ Security Decisions via Untrusted Inputs

§ Side Channel Data Leakage

§ Broken Cryptography

§ Sensitive Information Disclosure

1. Insecure Data Storage

§ Vertrauliche Daten oder Credentials schlecht gesichert

– Auf dem Gerät, auf SD-Karten oder in der Cloud

– Überflüssigerweise / zu lange gecached / gespeichert

– Unverschlüsselt / mit zu offenen Zugriffsrechten versehen

§ Maßnahmen in Design / Entwicklung bzw. nötige Regelungen

– Möglichst wenig oder auf Serverseite speichern

– Umgang mit Speicher für Entwickler regeln

– Keychain, Schutzklassen, Attribute, …

– Berücksichtigen von

– Daten im Hauptspeicher

– Backups

– Minimale Rechte vergeben

– Credentials sinnvoll wählen und verwalten (siehe 5.)

– Verschlüsselung richtig einsetzen (siehe 9.)

2. Weak Server Side Controls

§ Zu den meisten Apps gehört auch eine Server-Komponente

– Oft ein Webservice

§ Klassische und bekannte Probleme ebenso wie Lösungen

– XSS, SQL-I, Verschlüsselung, Authentisierung, Session, Vertrauen, …

§ Maßnahmen in Design und Entwicklung bzw. nötige Regelungen

– Siehe Sicherheit von Web-Applikationen und Web-Services, Backend-Integration etc.

§ Hier sind Richtlinien oft schon vorhanden

3. Insufficient Transport Layer Protection

§ Gar keine oder schwache Verschlüsselung der Übertragung

§ Fehlerhafte oder gar keine Zertifikatsprüfung

§ Maßnahmen in Design und Entwicklung bzw. Regelungen

– Richtiger Einsatz von SSL/TLS

– Validieren von Zertifikaten

– Bekannte Bibliotheken oder Plattformfunktionen statt Eigenentwicklungen

4. Client Side Injection

§ Apps verwenden

– Lokale Datenbanken

– Browser-Funktionen für die Anzeige

– Uvm.

§ lokale Varianten von klassischen Angriffen werden möglich

– SQL-I, XSS, …

– Angriffe können ggf. Telefonie, SMS, Payment etc. nutzen

§ Maßnahmen in Entwicklung bzw. nötige Regelungen

– Eingabevalidierung und Ausgabekodierung

– Prepared Statements für Datenbankzugriffe etc.

– Beschränkung von Interpretern / Browser-Funktionen in der App (z.B. UIWebView bei iOS)

– Umgang mit Grafiken / Bildern

5. Poor Authorization and Authentication

§ Wie wird authentisiert?

– An der App oder reicht Unlock des Geräts per PIN / Fingerprint?

– App / User gegenüber dem Backend?

– Wo liegen die Credentials? Welche Credentials?

– Eigene „versteckte“ Geheimnisse

– Hardware-IDs wie IMEI etc.

§ Wie sicher ist die Geräteauthentisierung?

– Rooting, Auslesen der Geräte per Ramdisk / Debug-Mode etc.

§ Was bedeutet 2-Faktor Authentisierung oder OOB im Kontext von Smartphones?

§ Maßnahmen in Design und Entwicklung

– Zertifikate in Hardware statt eigene Erfindungen

– Etablierte Sicherheitsstandards nutzen

– Vorhandene Policies / Richtlinien aktualisieren

6. Improper Session Handling

§ Auf dem Gerät und zu Backend-Services

§ Wie wird eine Session-ID gebildet?

§ Wie lange ist sie gültig?

§ Enge Verwandtschaft zum vorigen Punkt (Authentisierung / Autorisierung)

– Siehe 5.

– Tatsächlich zufällige Session IDs verwenden

7. Security Decisionsvia Untrusted Inputs

§ Generelles Thema:

– Eingabevalidierung und Vertrauen, IPC

§ Umgehung des Sicherheitsmodells

– z.B. Intents bei Android

§ Eigener Punkt in der OWASP Mobile Top-10 ist diskutierbar

8. Side Channel Data Leakage

§ Schwachstellen in den Plattformen oder Programmierdefizite

– Screenshots beim Beenden von iOS Apps

– Keyboard-Cache für Rechtschreibkorrektur

– Web Cache

– Logs

§ Maßnahmen in Design und Entwicklung bzw. nötige Regelungen

– Umgang mit Protokollierung auf Client-Seite

– Explizite Absicherung von Seitenkanälen im Programm

– Zwischenablage, Autokorrektur, automatische Screenshots

9. Broken Cryptography

§ Eigenentwickelte Verschlüsselung

– Eigentlich immer eine schlechte Idee

§ Falsch implementierte / verwendete Bibliothek

– Initialisierungen, Reihenfolge der Calls, Schlüsselgenerierung, Verifikationen, …

§ Schlüsselverwaltung

– Erzeugung / Ableitung

– Wo liegen die Schlüssel

– Keychain?

– Korrekte Nutzung der Plattformfunktionen

10. Sensitive Information Disclosure

§ Abgrenzung zu M1: nicht gespeicherte, sondern im Code enthaltene Informationen

– Schlüssel

– Namen

– Etc.

– Keine Geheimnisse / Credentials in den Code

Weitere Anforderungen an App-Entwicklung

§ Einstellungen der Entwicklungsumgebung

– Unterstützte Betriebssysteme / Plattformen

– Verwendung von ASLR, HW-Crypto, Bibliotheken etc.

– Vollständige Aktivierung von Sicherheitsfunktionen

– ASLR, Stack Protection, automatische Speicherverwaltung

– Entfernen von Debugging Symbolen

– …

§ Generelles Coding

– Vermeidung unsicherer Klassen / Funktionen

– Vermeidung von Problemen aus C

– Speicherfehler, Format Strings

Weitere Anforderungen an App-Entwicklung

§ Eigener Schutz vor Reversing und Manipulationen

§ Prüfungen zur Laufzeit

– Erkennung von Debugging

– Erkennung von Jailbreaks

– Erkennung von „Man-in-the-App“-Szenarien

– Verhalten bei erkannten Angriffen

§ Korrekte Nutzung der Plattform-Sicherheitsfunktionen

– Enterprise SSO etc. bei iOS7

– App-Konfiguration über MDM

– etc.

Bibliotheken für sichere Apps

§ Grundidee:

– Sicherheitsfunktionen innerhalb von Apps bereitstellen

– Idealerweise plattformübergreifend

§ Typische Features

– Erkennen der Plattformsicherheit

– Jailbreak, Rooting, unerwünschte Apps

– Absicherung von Seitenkanälen

– Keylogger, Screenshots, …

– Härtung der eigenen App

– Erschweren von Manipulationen, Debugging, Reversing etc.

– Sichere plattformübergreifende Datenablage

– Lokal oder auf dem Server

Zusammenfassung

§ Smartphones und Tablets bringen viele neue Bedrohungen

§ Apps können mit wenig Aufwand analysiert werden

§ Bei der Eigenentwicklung von Apps sind viele Dinge zu berücksichtigen

– Eigene Fehler vermeiden

– Sicherheitsdefizite der Plattformen umgehen

– Sicherheitsfunktionen der Plattform korrekt nutzen

§ Spezielle Richtlinien sind nötig

§ Spezielle Bibliotheken können helfen

§ MDM ist für die zentrale Verwaltung wichtig, aber für die Sicherheit bei weitem nicht ausreichend

Kriterien und Entwicklungsrichtlinien für Smartphone-Apps · 2017-07-13 · Jailbreaks / Rooting...

Documents