 Welcome everybody to this next talk. Herzlich Willkommen zum nächsten Vortrag. Inside Android Safety Net Attestation, Attack and Defense. Mich würde es interessieren, wer von euch hat hier schon mal eine Android App entwickelt? Also das ist ja fast jeder. Also irgendwas zwischen 90 und 95 Prozent. Und wer von euch hat schon die Android Safety Net App API benutzt? Das sieht eher so nach fünf und sechs aus. Und wer von euch hat schon von dieser App hier gehört, bevor sie hierher kamen? Das sind sehr viel mehr. Das ist wahrscheinlich die Grund, warum ihr alle hier seid. Also, haltet euch bereit. Viel Spaß mit dem Vortrag von Colin Müllender. Er ist auch Co-Auto vom Android Hackers Endbook. Vielen, also ich bin sehr gespannt auf den Vortrag. Applaus. Vielen Dank für die nette Vorstellung. Herzlich Willkommen alle. Dann starte ich einfach mal. Ich habe ein paar Sachen zu mobilesicherheit gemacht und Entwicklung. Hab ein paar Guides geschrieben und das Buch, aber dann fangen wir jetzt mit dem Vortrag an. Also das Hauptziel dieses Vortrags ist das Verstehen von dem, also das Android Safety Net zu verstehen. Und wie man auch, ist auch richtig implementiert und ausrollt. Also es ist nicht ganz straightforward. Es ist, also wir gucken uns die App hier an. Und was es machen kann und was nicht für einen machen kann. Und wie die meisten Sicherheitssysteme und Sicherheitsfeatures. Also was man kann, ist wirklich das Interessanteste. Und dann gucken wir uns noch ein paar Angriffe an und noch ein paar Verteidigungsstrategien dagegen. Und von mir und ein paar anderen Leuten. Und das zweite Ziel von dem Vortrag ist, die Dokumentation vorzustellen. Und weil die Google-Dokumentation ist nicht so geil dazu und deswegen wollte ich hier über reden. Also natürlich, dieses, dieses Gesamt, der gesamten Vortrag ist über mobilesicherheit. Es gibt viele Apps, die, früher haben die Apps nicht viel geredet, aber heutzutage, Google ist faszinierend mehr. Also heutzutage gibt es, also wenn das Backend und die App funktioniert, ist jeder glücklich. Und wenn es nicht funktioniert und alles ist unglücklicher und die Firma macht dann keinen Umsatz. Und wird dann irgendwann den Dienst abschalten. Also, mobile App Security ist wirklich interessant, weil das Ganze eigentlich nur eine Schnittstelle, also Zugriff, ein Interface für das Backend ist. Also für die ganzen Mobile Services, also wenn über so viel Snapchat nachdenkt, die haben gar keine Website mehr. Also App Sicherheit ist vor allem darüber, wie ein Daten kontrolliert. Also Daten anzeigen, Daten handhaben und sich hier zu stellen, dass niemand die Daten rauskopieren kann, die vor allem von der App bearbeitet werden. Also die mobile App Sicherheit ist vor allem, es geht darum, die eigene Marke zu schützen und den Kunden. Also wenn man sich die Angriffe generell anguckt, also da muss man sich um so Sachen kümmern, wie so Sachen wie Routing, das ist so das Hauptproblem. Also wenn man das Handy routet, kann man den Inhalt aus Apps rausziehen, die es nicht haben wollen. Also man kann einfach Daten lesen oder Screenshots machen oder die App missbrauchen und Daten rauszuziehen. Also man kann natürlich auch die App direkt modifizieren und dann halt auch noch ändern, was die App umsetzt. Und natürlich kann man noch den Network Traffic bearbeiten, aber da werden wir jetzt nicht so stark darauf konzentrieren. Also was ist Routing eigentlich? Man greift eigentlich nur, also man bekommt einfach nur das System zuvor auf das Handy. Also das kann man heutzutage mit jedem Handy und Tablet machen, also wo er keinen komplett Zugang hat. Und mit Routing kann man dann wieder auf die ganzen Sachen zugreifen, die sonst eingeschränkt sind. Also man kann dann wieder das System und die Software modifizieren, die davor schreibgeschoss sind. Also und neue Android-Versionen sind sehr viel mehr abgesichert als die alten, aber das werde ich nicht anfangen. Wenn wir uns dann also Epsicherheit in der etwas älteren Vergangenheit anschauen, es gab Checks gegen Routing. Das heißt man konnte überprüfen, ob beispielsweise das System X-Band SU existiert. Das heißt man konnte überprüfen, ob jemand das Gerät geroutet hat und dieses Datei neu installiert hat. Und dann konnte man nicht eben daraufhin Ausführungsvorgang abbrechen oder sowas. Dann gab es auch noch Checks, ob bestimmte Pakete vorhanden sind und so weiter. Und konnte dann abhängig davon den Ausführungsfluss ändern und vielleicht nicht mehr weitermachen. Und das sind wirklich die alten Zeiten. Früher war es wirklich einfach für die Entwickler, das zu implementieren, denn sie wussten, dass sie einfach bestimmte Dateien oder Pakete testen konnten. Und wenn die da waren, dann war dieser Haus fertig. Man musste da kein Genie für sein, einfach nur nach der Datei suchen. Und ja, es war sehr einfach diese Checks zu implementieren. Aber für die Angreifer war das natürlich auch ein leichtes Spiel, denn sie konnten Dateien einfach umbenennen, Dateien durch die Gegend bewegen und so weiter und dann diese Anwendung missbrauchen oder exploiten. Moderne App-Sicherheit funktioniert dadurch, dass man Daten sammelt. Das heißt, man hat im Endeffekt Code das Daten sammelt und diese Daten dann zu einem Backend sendet. Und das Backend macht dann die Entscheidung, ob die Auswirkungen fortgesetzt werden darf oder nicht. Also das Backend entscheidet, ob das geroutet ist oder nicht. Und die Idee dahinter ist, dass der Angreifer nicht einfach beliebige Patches machen kann, denn wenn der Angreifer einfach bin es so oder sowas setzen könnte, dann wird es einfach funktionieren. Aber wenn wir tatsächlich viele Daten vom Gerät sammeln und dann müsste der Angreifer quasi alle Daten auf dem Gerät faken und das ist dann nicht mehr wirklich praktikabel für den Angreifer. Das heißt, so funktionieren im Prinzip alle modernen Absicherungsmechanismen, wenn wir irgendwelche Hörer und Anforderungen an Sicherheit haben. Und Safety Net Desistation macht im Prinzip auch genau das. Wenn wir noch mal ein bisschen zurückgehen zu Android, früher war es relativ offen, aber heute würde ich sagen, ist ziemlich viel von dieser Offenheit Geschichte. Sie haben ein Sequelent von Secure Boot mit einem Trust Enker und so weiter. Und das heißt, das kann zum Beispiel feststellen, ob der Bootloader geanlockt wurde und so weiter und dann darauf reagieren. Es gibt auch sehr viel mehr SCD-Nurse-Restriktionen und stärkere Sandboxen im Zusammenhang. Dann gibt es eben noch Safety Net. Und Safety Net ist tatsächlich einfach nur ein Markenname für verschiedene Sicherheitsdienste, die Android bereitstellt. Es gibt verschiedene Dienste, Refizierte, Apps, Checks für PHAs, was Google's Terminus für malware ist und dann eben Attestierung und Capture-Dienste. Safety Net ist darauf ausgeheckt, auf jedem Android-Gerät zu laufen, dass auch Google Play bereitstellt. Und das heißt, es ist einfach Teil von Google Play Services. Und der schöne Teil dabei ist, dass es dann unabhängig davon ist, von welchem Hersteller es genau kommt. Also es ist nicht speziell für die Google-Geräte. Und das ist eben ein Remote-Feature dann an der Stelle. Also natürlich benutzt Google auch sehr stark ihr eigene API. Als Beispiel, wenn man Android Pay benutzt und diese Meldung sieht, dann bedeutet es, dass für Safety Net gefehlt ist, das Gerät zu verifizieren. Also zum Beispiel, die Android Pay App macht das. Also da sieht man, die App sagt dann, ja, da hast du mal was modifiziert. Eine Sache hinter der Verifizierungsstrategie ist, dass man nicht alles kontrollieren kann, aber zum Beispiel Apple Pay unterstützen möchte. Also man hat praktisch eine Möglichkeit gefunden, sie haben eine Möglichkeit gefunden, um zu checken, ob das Gerät, wo Android Pay 3 läuft, modifiziert wurde. Sie können das sofort modifizieren, sie müssen keine Software updaten, sie können Code einfach auf die Geräte schieben, um das Ganze um die Modifizierung festzustellen. Also damit können sie wirklich schnell auf neue Route-Sachen reagieren oder also schneller als wenn Software-Updates ausgerollt werden. Also was macht der Bescheidigungspart eigentlich? Also das ist ein Teil der App und des Geräts. Also es ist praktisch all das, was die Leute früher selber implementiert haben. Also es ist ein Teil von Google Play Services. Und praktisch ruft man der App hier auf und validiert die App auf dem Gerät und dass das Gerät nicht modifiziert wurde. Also unglücklicherweise ist die Dokumentation nicht wirklich detailliert und lässt viel Interpretation Spielraum. Also dann muss man ausprobieren, wie es wirklich funktioniert. Also es wird besser mit der Zeit, aber als ich angefangen habe war es wirklich, also vor ein, zwei Jahren war vieles der Dokumentation wirklich schlecht. Aber sie haben viele Features, sie dokumentieren die, sie haben eine private Mailing-Liste, wo ein bisschen was diskutiert wird, aber ja. Also das ist praktisch der einzige Code, den ich hier zeigen werde. Also Safety Net ist Teil des Google API Clients und praktisch sagt man wilde Verbindungen zu Safety Net API und es verbindet einen. Also wie funktioniert es wirklich? Also hier in der Mitte sieht man, dass es praktisch die Software, die auf dem Handy läuft und man hat dann das Backend und das Google Playbackend. Also wenn man, und wenn die App kein eigenes Backend hat, kann man das Safety Net nicht benutzen. Also was passiert, die App redet mit dem Backend, also zum Beispiel einloggen, sich einloggen möchte oder eine spezifische Operation machen. Da sagt das App, sagt das Backend, ich würde gerne von der App eine Verifizierung haben. Also schickt das Backend praktisch der App eine Anfrage, die Google Safety Net API aufzurufen und der Code wird auf dem Gerät ausgeführt, also zum Beispiel das Checked System und er guckt sich auch die App an. Hier sind noch ein paar kleine Sachen, also das sollte ein Non-Stream sein, um Replayattacken zu verhindern. Aber das ist praktisch, also praktisch stattdessen ist man alles selber implementiert, ruft man die API auf und man hat die ganze Arbeit von Google erledigt. Also zum Beispiel der ganze Sicherheitsbescheinigungsprozess kann man so an Google auslagern. Also was passiert, nachdem das Ganze verifiziert wurde und das Ganze an Google geschickt wurde. Also Google analysiert die Daten und stellt dann fest, in welchem Zustand das Gerät ist und schickt das Ganze an die App um sicherzustellen, dass die App umzufinden, dass die App modifiziert wurde, das signiert man das Ganze und dann kann das Backend die weitergeleite Anfrage verifizieren und das Ganze im Backend validieren. Also das, was dann zurückbekommt, ist eigentlich ziemlich einfach, es ist ein Blog. Also Google hat eine Signature API, die praktisch nur für Entwicklerzwecke da ist, aber das ist ziemlich gut dokumentiert, denke ich. Aber schauen wir uns dann mal die Attestierungsdaten etwas genauer an. Das ist das, was man in diesem Blog bekommt. Alles andere ist einfach nur Certificate Chain und Signaturen und so weiter. Seit man sieht, das CTS Profile Match fällt. Das ist im Prinzip der Wert der Indikator dafür, ob die Indikator der Gerät des Noch-Gewährleistes noch gewährleistet ist. Und Google stellt eine sogenannte Integrity Compatibility Test Suite bereit. Das heißt, eine Möglichkeit für Entwickler von Hardware eben, sie herzustellen, das ihr Gerät zu beschreiben und Google vergleicht dann die Beschreibung des Herstellers, die der abgeliefert hat mit dem, was sie vor dem konkreten Gerät bekommen. Dann gibt es dann noch den APK-Paketnamen, ein Prüfzimmer davon, der Herrsch-Form-Zertifikat und so weiter. Und das Basic Integrity-Feld, das man gesehen hat, bezieht sich dann auf Routing. Das Jahr haben sie jetzt zu ihrer Redoku ungefähr vor sieben Monaten hinzugefügt und haben dann im Prinzip einfach nur gesagt, also davor gab es einfach so, es gibt einen True and False-Feld. Und man sieht jetzt hier das ZTS-Novava, das ZTS-Daten. Also sobald man den Bootloader anlockt, wechselt es ganz zu Fals, aber es wird immer noch von Google als Legitimen bescheinigt. Also wenn den Bootloader anlockt, passiert da nichts. Also das ist praktisch, was die beiden Indikatoren machen, die einem helfen zu verstehen, in welchem Zustand das Gerät ist. Also es ist eine coole Tabelle, da kann man die ganzen Checks einbauen. Also ich habe hier diese, also ich habe das Ganze implementiert für eine größte Firma, aber ich habe auch noch diese Demo hier gebaut, die ich euch am Ende zeigen werde. Also die App geht praktisch her, lässt die ganze Referenz laufen und sagt einem, ob das Gerät gerudet ist oder nicht. Also es schafft alle Checks, aber wir werden damit nachher noch ein bisschen mehr Spaß haben. Das große Problem mit der API sind die Errorfehler. Wenn man nicht weiß, was man umgeht, kann man praktisch das ganze System umgehen. Also wenn man ist nicht saubimplantiert. Also als Beispiel, das ist eines der Basisfehler, wo der API aufrufe erfolgreich war, aber der Code in der API ist in den Fehler gelaufen, dann kriegt man das. Also ja, wir hatten diese zufällige Fehlermeldung und dann wird man feststellen, wie es aussieht, dass es nicht wirklich dokumentiert. Also das bedeutet praktisch einfach, beruft die API nochmal auf, dann funktioniert es. Das ist eine der interessanteren Fehler. Es sagt praktisch, dass man nicht wirklich unterscheiden kann, welchen API-Call das... Ja, also dass wer Vertrauen im Gerät einmal grundsätzlich nicht will, wenn wir nicht wissen, welches APK das aufgerufen hat. Das heißt, manche Felder in den JSON sind da trotzdem gesetzt und das ist ein bisschen verwirrend beim ersten Mal, wenn man das benutzt. Und nochmal, das war natürlich alles nicht wirklich dokumentiert. Jetzt wisst ihr, dass es diese API gibt und die JSON-Felder sehen vielleicht irgendwie komisch aus oder so, aber wir könnten jetzt irgendwie unsere Anwendung implementieren und diese Interaktionen mit unserer App und dem Backend implementieren, dass die App auch die Attestierung benutzt usw. Aber es ist immer noch nicht so wirklich einfach. Tatsächlich können auch die ganzen API-Calls auch alle Fehler zurückgeben und das passiert auch tatsächlich draußen und das heißt, jede API, die man irgendwo aufruft, kann tatsächlich auch mal fehlen. Sie tun das, hat meine Partierfahrung gezeigt. Wenn man das zu Hause allerdings ausprobiert oder auf Arbeit, dann wird man diese Fehler wahrscheinlich nicht sehen, aber das passiert tatsächlich. Das heißt, wenn die Anwendung auf 100.000 oder 1.000.000 von Geräten läuft, dann sieht man tatsächlich jeden Fehler irgendwann mal und man hat Dinge wie Google Play Services unterstützen, Google Play Services noch nicht und man kann jetzt natürlich den User dazu zwingen, seine Play Services zu updaten und sonst nicht weitermachen oder es gibt auch relativ allgemeine Fehler und in diesen ganzen Fällen muss man dann eigentlich tatsächlich einfach alles normalerweise suchen. Wenn man vergisst, irgendwelche von diesen Fehlern zu handeln, bedeutet das letztendlich, dass irgendein Client in unserem Netz nicht funktioniert, indem er gerade ist oder dass er funktioniert und dann aber diese Sicherheitschecks nicht bestanden hat. Hier noch ein paar weitere Beispiele. Ich habe zum Beispiel diese Play Services dann mal deinstalliert und das ist auf Android 4.4, das heißt, das hat auch kein Secure Boot und das heißt, wenn man die Anwendung jetzt startet, dann wird einfach gar nichts funktionieren, weil man eben die Play Services updaten muss. Viele von den Fehlern, die die API zurückgibt oder wenn die API nicht funktioniert, sind temporär. Das heißt, man muss im Prinzip anfangen, alles nochmal auszuprobieren. Also generische Fehler, Netzwerkfehler usw. Man muss da einfach retry machen. Man sollte dabei dann exponentielle Backoff zur Anwendung bringen. Das heißt, nicht direkt wieder versuchen, sondern immer weitere Wartezeiten dazwischen durchverwenden. Man kann auch auf den JSON-Blob auf dem Gerät selber schauen und abhängig davon entscheiden, ob man dann retry machen möchte oder nicht. Was man aber auf jeden Fall machen sollte, ist, die ganzen Fehler an das Backend zu kommunizieren und planen, was man denn machen soll, wenn ein Gerät einfach die ganze Zeit damit weitermacht, Fehler zu werfen. Denn im schlimmsten Fall kann es sein, dass irgendein legitimate User unserer App nicht nutzen kann und den verlieren wir dann im Moment. Das heißt, wir wissen uns tatsächlich Gedanken darüber machen, was wir machen. Es ist tatsächlich auch eine app-spezifische Entwicklungsentscheidung senkt von der Situation ab. Es kann sein, dass wir zum Beispiel sagen, dass wir sagen, nur verifizierte integriere Apps dürfen unseren Service nutzen, das ist nicht alles eine sehr app-spezifische Entscheidung. So, schauen wir uns jetzt, die zwei Hauptfunktionitäten des Gerätes sind eben diese beiden Felder, die den Integrated-Check auszeigen, also dem Prinzip uns einfach nur true or false geben, aber App-Antiquity funktioniert dann etwas anders. Google kann nämlich nicht wirklich sicher sagen, ob das die App jetzt noch integer ist oder nicht. Also im einfachen Modus, also wenn eine App signiert, dann ändert sich der Digest natürlich, aber wenn Programm die APK ändert, dann ändert sich die Digest auch. Also da muss man um die Integrated-Check zu kontrollieren, eine Vergleichung bei den Digests. Wenn man fünf unterschiedliche Apps hat, dann sind sie vermutlich alle mit dem selben Cert signiert, dann kann man das einfach mit dem selben Cert kontrollieren. Also das ist eigentlich eine ziemlich einfache Vergleich, mit dem man verifizieren kann, ob man an der App rumgespielt wurde oder nicht. Aber man kann natürlich ein bisschen fortgeschrittener machen, also man kann natürlich die APK Digests vergleichen. Also das ist natürlich ein bisschen schwieriger, weil das bedeutet, dass für jede APK, die man rausbringt, in den App Store muss man praktisch den Digest aufschreiben, wenn das in der ich nicht gemacht habe. Dann lehnt man Leute einfach von der App ab, weil man sagt man erkennt diese Digest im Backend nicht. Deswegen muss man die ganzen Daten sammeln. Also man muss wirklich gute Kontrolle über den Release-Prozess haben. Man kann damit sehr gut verifizieren, ob das Ganze funktioniert oder nicht, wenn z.B. den Digest aus der Datenbank im Backend löscht, dann sieht man, ob das Safety Net fehlt oder nicht. Also praktisch, um das Ganze zu implementieren und zu depleuen, auf dem Client muss man also die ganzen Fehler melden und neue Versuche starten und die Daten kontrollieren. Also alle Felder checken, Non-Zeit-Stempel und natürlich auch explizite Entscheidungen treffen für Fehler. Also vor allem für so Sachen wie Leute z.B. dazu zwingen, ihr Play Store zu updaten. Also man kann dann z.B. manche Geräte weitlisten, weil es uns damit Probleme gibt. Und man möchte z.B. keine Gruppe davon abhalten, den Dienst zu nutzen. So, das war ja der Teil zur Safety Net-Atastation. Wie die Safety Net-Atastation funktioniert, wie man es implementiert, worauf man achten muss dabei. Aber was ja wichtig ist, jeder, der tatsächlich an Sicherheit interessiert ist, wenn man das implementiert, dann will man ja auch tatsächlich wissen, ob man diesem System wirklich vertrauen kann oder ob es effektiv eigentlich gar nichts tut. Das heißt, wenn ich zuerst darauf geschaut habe, habe ich mir überlegt, schauen wir mal, ob das wirklich taugt dieses System. Dann können wir da irgendwie drumrum arbeiten. Offensichtlich in Limitierung waren das verschiedene Android-Versionen ein Problem darstellen, weil auf Android 4 und 5 es den Secure Boot-Zustand noch nicht gibt. Und dadurch, dass wir den nicht feststellen können, ist es nicht möglich, gegen einen ge-undockten Bootloader vorzugehen. Android 6 und später, da kann man zwar den Bootstate detektieren und sich dann auch tatsächlich darauf verlassen. Aber das zeigt tatsächlich, dass alle Geräte aus Sicht vom Attestierungssystem etwas schwieriger zu bewerten sind, einfach anhand der Android-Version. Das heißt, man muss in der Security Policy im Backend wissen, dass Android 4 oder 5 Geräte, vielleicht bestimmte Features, dann einfach gar nicht zu Gesicht bekommen und so weiter und andere dann aber schon. Bei Android 4 hat man dann auch nicht DM-Varity. Das heißt, man kann einfach Remounts machen oder Dateien auf der Systempartition ändern. Das heißt, man kann SU zum Beispiel einfach in ein anderes Verzeichen bewegen. Das heißt, man würde dann tatsächlich trotzdem im Attestierungsvorgang bestehen, aber nachdem die Anwendung benutzt wurde, dann können wir einfach SU wieder zurückbewegen. Das ist tatsächlich auch ein anderer Indikator, wie man tun kann. Wenn man tatsächlich Selfie nicht nur beim Start der App benutzt, dann war es das ein Prinzip an der Stelle. Man sollte es tatsächlich häufiger verwenden. Entweder jedes Mal, wenn man auf den Backend-Service zugreift oder in zufälligen Intervallen, sodass es nicht so ganz einfach ist, eine Anwendung einfach einmal zu starten, das auch zu tauschen, um wieder zurückzubiegen, wenn die Anwendung fertig ist. So, hier ist noch mal meine kleine Demo-Anwendung. Das hier ist ein Nexus 5 mit Android 6 und da drauf anlocken wir dann den Bootloader. Man sieht hier jetzt das Feld Secure Boot, und das kommt aber nicht aus den Systemproperties. Und es ändert dann, also man anlockt den Bootloader und dann sieht man hier, ändert das CTS Profile in der Mitte zu falsch und sagt einem praktisch, dass damit das Gerät modifiziert wurde. Also, das wurde aber erst letztens hinzugefügt. Ich habe mir das Zelt Jason Fall angeguckt und habe mir gesagt, boah, ein neues Feld, wie cool. Also, Suheit und Magisk. Obwohl, wenn ein System so existiert, dann werden die Leute versuchen, wie man daran vorbeikommt. Also ein Beispiel war es Suheit oder man könnte es Rootkit nennen, also was es versucht ist, es versucht zu verstecken, dass das Gerät geroutet wurde. Das wurde, also das war eigentlich ziemlich einfach und Google hat es relativ schnell feststellen. Also, Google, also zwei Tage später hat Google, also wurde es Suheit geändert, dann ist Google hinterher, es geht also wie ein Katzungsmauspiel, aber es ist ein sehr kurzer Zyklus, weil Google den Code halt auf die Geräte runter pushen kann und Google reagiert relativ schnell darauf. Dann wurde Suheit eingestellt, weil der Entwickler aufgehört hat, weil er meinte, dass Google zu schnell reagiert und er meinte, er kann mit seinem Netzteil das Bestes anfangen. Und dann gab es Magisk, also Magisk ist ein modernerer Weg, um das Root zu verstecken, es geht her und so weit wie ich weiß, also kann Google das nicht feststellen, weil Safety Net mit den System-Privilegien nicht läuft, aber in dieser Phase muss man halt den Boot-Logo anlocken, sehr viel modifizieren, um dorthin zu kommen. Also deswegen wird es wahrscheinlich von vielen benutzt, aber praktisch gibt es echte Root-Kids, um vom Dienst das Root zu verstecken und man spielt ein Katzungsmauspiel. Also, und auch diese beiden versuchen einfach, nur das System-Modifikation zu verstecken, war es ja nur ein Aspekt, das den Safety Net-Versuch zu detektieren und den Entwickler davor zu schützen. Ich war prinzipiell auch mehr interessiert an der Integrität der eigentlichen Anwendung, denn die Anarbeit in Checks kann ja relativ offensichtlich überprüft werden und die man hat sich so wirklich App-Intecität angeguckt und ich habe mich gewundert, warum. Für uns ist das besonders, für uns war es besonders interessant, deswegen habe ich mir das besonders angeschaut. Das Ziel hinter der ganzen Sache ist herauszufinden, ob jemand tatsächlich die Anwendung irgendwie modifiziert hat und das macht man indem man auf das, indem man letztendlich einfach das Digest, also die Prüfsumme vom APK überprüft. Wenn man die Anwendung modifiziert hat, kann man ansonsten einfach Datenverkehr modifizieren und so weiter. Das möchten wir nicht. Das heißt, App-Intecität ist ziemlich interessant. Also, wie funktioniert das tatsächlich? Der interessante Teil ist, bis in zwei Werte, werden über dem APK-Fall berechnet, dass auf der Platte gespeichert wird. APKs beinhalten Dexfiles und bis Android 4 wurden ja die Dexfiles konvertiert in ODEX, falls also optimiert ein Bytecode und seit Android 4 oder 5 werden die dann tatsächlich in nativen Code konvertiert. Und das kann man tatsächlich angreifen. Ungefähr vor drei Jahren gab es relativ viel Arbeiten zum Patchen von ODEX-Dateien. Das heißt, das Problem, dass man die Dexfiles auf eine Art von Datei berechnet, aber dann eigentlich andere Dateien ausführt, nämlich dann halt die kompilierten Dateien. Das kann eben zu Problemen führen. Und unter Android 4.4 und 5 hat man das Data-APK, SAPK-Verzeichnis, und dann hat man das Datenverzeichnis und das Codeverzeichnis, wo der Daifik-Cache liegt. Dann hat man das ein ziemlich langen Dateip-Fahrt, wo eben dieser optimierte Code dann oben liegt. Unter Android 6 und später hat man dann so ein Paketverzeichnis, in dem man dann einmal das APK-Rummling hat und das Basis ODEX, die Basis ODEX-Datei, aber die ist tatsächlich gar keine ODEX-Datei, sondern die beinhaltet nativen Code. Und diese Dateien haben als besitzeres System zugeordnet und können nur von Instalti installiert werden. Das heißt, der Anwendung kann ihr eigenes Binary nicht lesen. Ja, das ist auf jeden Fall ziemlich interessant. Sehr gut, da fährt das dann einfach in den Speicher und die Anwendung muss da nicht ihren eigenen Code lesen müssen. Wenn wir jetzt ODEX-Code-Notification ein bisschen genauer angucken, also was das dann macht, und verwende eine ganze Kette von Tools um das Ganze um die APK zu bauen, dann signiert man das Java-File. Also natürlich in dem Fall kann man die Signature knacken, weil man den Auton schlüssellich hat. Auf dem Gerät kann man auf dem, werden die APKs zu DEX-Files kompiliert und da hat man eine modifizierte APK. Und was man dann natürlich machen kann mit dem ODEX-File, also man kann es, dass die Datei immer noch modifizieren. Das ODEX-File enthält den CRC32, das ist kein Sicherheitscheck, sondern das ist wirklich nur für den WM um zu schauen, ob die App geupdatet wurde oder nicht. Also man kann das DEX-File hernehmen und einfach neu kompilieren. Also das ist kein Sicherheitsfeature. Also um das Ganze um ein CSC-File zu patchen, habe ich einen Tool geschrieben. Da kann man die CRC-Dateien einfach neu schreiben. Also was dann praktisch machen kann auf jeder Android-Version, ist man kann hergehen und die ODEX-Dateien überschreiben. Von der bestimmten App. Also wenn man eine Route hat, kann man her, kann man die bestimmte Datei überschreiben. Also etwa im Dalvik Cache oder direkt in dem App Old Cache. Dann kann man die App anhalten und neu starten und man hat eine modifizierte APK und es geht an den ganzen Checks vorbei, weil man nur den Execute Code modifiziert hat und nicht die originale APK. Aber da muss man es natürlich anrouten, weil man noch den generalen Device Integrity Check bestehen möchte. Also wenn wir zurückgehen, also wenn Jan vorhin denkt über Android 4 und 5, der kann man nicht feststellen, ob der Bootloader anlockt ist oder nicht. Also auf einem Android 4 kann man praktisch die ganzen App Integrity Checks umgehen. Also wenn man ein Gerät hat, was mit dem anlackten Bootloader geboten ist, kann man daran nichts verwerfen. Also daran komme ich vorbei. Aber ich habe mir gedacht, man kann bestimmt auch noch andere Wege finden, um das zu erreichen. Das primäre Ziel für diese Attacke war, dass man genau diese eine ODEX-Datei überschreiben möchte. Aber wir wissen das tatsächlich nur genau zwei Demons dieses, das SCLinux-Privileg haben, um diese Dateien zu überschreiben, nämlich install.de und cycle. Und wer kann noch darauf schreiben, der Linux-Körnel? Denn alles, was so ist wie SCLinux oder das Teilsystem beim Mischungsland, geht nicht für den Körnel. Und es gab ja im Linux-Körnel diesen schönen Bug namens Dirty Cow und für diesen Talk fasse ich das mal so zusammen, dass man in der Lage war, jeder Datei im Datei-System zu überschreiben, die man lesen konnte. Das heißt, als Schellennutzer kann man offensichtlich alle ODEX-Dateien lesen mit diesem Exploit. Und dadurch, dass wir alle ODEX-Dateien lesen können, ohne das Device zu roten, können wir dieser Attacke tatsächlich auch fahren, ohne das für uns zu roten. Und das heißt, wir hitzen einfach das ODEX-File-Patchen, und das eine kleine Ding, das noch fehlt, war, dass Dirty Cow Dateien nur In-Place überschreiben kann, also sie nicht vergrößern kann oder so. Und der einfache Trick, den ich gefunden habe, war, dass Dexter-Ode normalerweise mit Prozessorspezifischen Optimierungen lief, und diese Optimierung machen Dateien normalerweise sehr viel größer. Das heißt, wenn man Dexter-Ode ohne Optimierungen ausführt, bekommt man eine sehr viel kleinere Datei. Und diese kleine Datei kann man dann In-Place einfach über das Original schreiben. Ja, und ich werde euch jetzt tatsächlich eine kleine Live-Demo geben, weil es tatsächlich so einfach ist. Ich zeige es euch erst mal. So, mal sehen, ich muss einfach ein bisschen warten, bis die Kamera zu den Weinen adjustiert ist. Okay. Das hier ist meine Demo-Anwendung. Ja, und sie hat jetzt alle Tests bestanden. Und das ist jetzt ein nicht gerotetes Gerät. Unmodifizierte Anwendung. Sieht alles gut aus. Also, das kann man das lesen. Ich denke, das ist okay. Ja, ich denke, das ist okay. Das ist die APK. Ja, das ist das APK. Das heißt, wenn man das entpackt, dann modifizieren wir einfach ein bisschen Code. Das ist tatsächlich ein bisschen Code, den wir jetzt einfach in die Anwendung einfügen. Und das ist auch alles, was wir machen müssen. Und jetzt können wir einfach die Anwendung neu bauen, was im Prinzip einfach nur auch wieder APK-Tool benutzt, den Jawsigner mit dem Standard Key-Shorch benutzt, also ein selbstsignetes APK, das wir jetzt erstellen. Ich vermute, ich habe den Passer für nicht gesetzt. Wer weiß, wo die Datei ist? Ah, es ist ein Bildtools. Also, ich finde den Fahrt für Jawsigner nicht. Ja, das. Wo ist das? Ich habe gehört, JDK ist da. Wo ist mein JDK? Wo ist mein JDK? Ich habe gehört, das ist da. Definitiv nicht. Ja? Wo ist der JDK? Hier geht es. No. Ich habe es jetzt gefunden. Hier. Ja, ich bin überrascht. Ich war mir relativ sicher. Ah, dort. Okay, machen wir das jetzt nochmal. Ja. Also, jetzt haben wir den modifizierten App neu signiert. Und was müssen wir jetzt machen? Wir haben unsere neu signete Anwendung. Und wir möchten jetzt tatsächlich diese Anwendung auf dem Gerät kompilieren. Das heißt, wir schieben das APK auf das Gerät. Und kommen jetzt zu das modifizierte Auto. Also, wir haben das APK auf dem Gerät. Und kommen jetzt zu das modifizierte ODEX. Jetzt wollen wir das Original Base-File. Denn wir müssen die originale CRC-Summe extrahieren. Das ist die Originale Datei. Und das ist die, die wir ändern wollen. Das heißt, wir möchten das. Nicht das ersetzen. Das ist natürlich immer ungünstig, wenn man die Kommandozeilen-Argumente seiner eigenen Anwendung vergesst. Also, es ist jetzt modifiziert und es ist gepatched. Und für die Attacke schieben wir jetzt tatsächlich einfach das modifizierte ODEX-File auf das Gerät. Und dann läuft es tatsächlich auch wieder im Punkt, wo diese Demo kaputt gehen könnte. Und das hat nicht funktioniert. Ich kann es nochmal versuchen. Ich habe noch ein paar Minuten. Ich liebe Live-Demos. Manchmal funktionieren sie einfach nicht beim ersten Mal. Versuchen wir es nochmal. Also, das werden wir dann halt nochmal installieren. Die originelle APA, da wir schon die modifizierte Dateien hier haben, werden wir alles andere überspringen. Also, versuchen wir es doch noch einmal. Und es hat geklappt. Also, wechseln wir zur Kamera. Und warten, dass es sich einstellt. Und jetzt seht ihr diese schöner Pop-Up, den wir hinzugefickt haben. Ihr werdet sehen, dass die Garnet-Checks passen. So, ja. Das ist quasi nicht geroutete Geräte. Es wird kompromiert auf der Integritätsebene. Was die eigentliche Auswirkungen sind. Das wird natürlich... Also, das ist tatsächlich limitiert auf Android-Geräte, auf den Dirti-Core funktioniert. Allerdings gibt es da noch ziemlich viele von... Das muss auch der Besitzer vom Gerät selber tun, denn... Denn bösartige Apps, die der Nutzer runtergeladen hat, können diese Dateien nicht modifizieren. Das heißt, können die ODEX-Dateien nicht lesen. Das heißt, alle Checks, die wir auf ODEX-Dateien machen, sind halt verwundbar mit dieser Attacke. Das heißt, Google hat jetzt tatsächlich die Policy für diese CTS-Tests einfach geändert. Das heißt, wenn noch Dirti-Core auf dem Gerät funktioniert, dann bekommt man einfach nicht die Zertifizierung von Google. Das setzt allerdings mittlerweile so fast 2 Jahre her. Und es ist einfach noch weit verbreitet. Cobby-Held-OS ist tatsächlich noch ein gehärteter Android-Clone. Und sie kompilieren einfach jede Datei beim Starten neu. Das heißt, das verhindert, dass modifizierte ODEX-Dateien benutzt werden können wie eben in der Demo. So was... Wir können generell festhalten, dass SafetyNet sich über die Zeit verbessert hat. Das heißt, ja... Wir haben das gefunden. Und dieses Jahr haben Sie dann diesen Hinweis da eingefügt, der über den Bootloader... also der über ein Bootloader-Update hinweist. Oder den User darauf hinweist, dass mit dem Gerät irgendwas nicht stimmt. Aber die Webseite... Also man konnte da bei dem Prozess halten, dass sie zwar besser darauf reagieren, aber die Webseite immer noch nicht zeitlich geupdatet wurde. Da die Attestierung ja auf den CTS-Daten funktioniert und CTS aber von den Herstellern gemacht wird, bevor sie ein Update herausgeben, haben wir eben das Problem, dass wenn die Daten nicht zurückgekommen oder sowas, dass dann die CTS-Tests fehlschlagen, obwohl das eigentlich auch das Digitime ist. Das hatten wir zum Beispiel auf ein paar Telefonen von Jota, die dann bei uns zu Breakage geführt haben, weil bei dem CTS-Prozess was schief gelaufen ist. Und dieses Jahr ist Google tatsächlich selber passiert. Google musste einen Sicherheitsupdate für das Nexus 7 zurückziehen, weil es eben die Attestierung auf verschiedenen Android-Geräten kaputt gemacht hat. Und dann gibt es noch generell den Aspekt, dass wenn Safety Net irgendeine Form von Downtime hat, dann können wir da drauf als App-Entwickler nur das so reagieren. Wir müssen aber dann klarkommen, dass wir den Moment dann keine Attestierung machen. Das heißt, entweder haben wir selber Downtime oder wir akzeptieren nicht integriere Clients. Generell können wir festhalten, dass es sich halt im Prinzip immer um einen Cuts-Amau-Spiel handelt, wo Google halt immer nachlegen muss. Google selbst geht es hauptsächlich darum, Android-Pay zu schützen. Aber der große Vorteil von Benefit ist eben der Attestierungsaspekt, dass im Prinzip Google die ganze Arbeit für uns macht. Das heißt, wenn wir unsere eigene App sichern möchten, dann können wir da einfach die Arbeit von Google neu benutzen und müssen es nicht selber bauen oder ein Self-Party-Produkt verwenden. Natürlich ist dann diese Attestierung kostenlos. Man hat natürlich dann keinen SLA oder so was. Es gibt Rate Limits, die sind allerdings sehr hochgesteckt. Wenn man es vergleicht mit Diensten von anderen third parties, dann hat man da auf jeden Fall den ökonomischen Freuten, dass es kostenlos ist. Was es natürlich auch gibt, ist, dass es einfach Neupacket-Hit der Android-Anwendung gibt. Das schützt uns natürlich davon nicht. Wenn jemand einfach Angry Birds modifiziert und da Code rauspatscht, dann geht das, es sei dann die Anwendung benutzt Safety Net, dann kann es sich eben dagegen schützen. Und Angreifer werden vermutlich nicht die Anwendung so stark modifizieren, sondern sich schützt irgendeine andere Anwendung dem und der Arbeiten. Das heißt, man kann damit einfach durch die höhere Hürde Angreifer davon abhalten, die Arbeit zu machen. Zusammenfassend kann man sagen, dass Safety Net ein sehr grundlegender Plattform, eine Plattform aus Fraktion ist, die die Sicherheit erhöht. Und wenn man tatsächlich irgendwas auf die Sicherheit seiner Anwendung hält, dann sollte man das benutzen. Es gibt natürlich offensichtliche Nachteile davon. Allerdings hat man beim Felt-Partyservice oder bei einer eigenen Lösung ähnliche Nachteile. Das heißt, die Mehrzahl der Geräte hat davon, die Mehrzahl der Geräte und Entwickler hat einen dünnlichen Vorteil davon. Und ich ermutige euch das zu benutzen. Die Folien und so weiter sind alle online. Auf meinem Blog habe ich auch noch mehr dazu geschrieben. Es gibt auch noch mehr Referenzen. Das war's. Vielen Dank. Wir haben jetzt noch zwei Minuten für Fragen. Thank you very much, Colin. We have about three minutes for questions. Vielen herzlichen Dank, Colin. Wir haben noch drei Minuten für Fragen. Ich möchte erst mal eine Frage aus dem Internet. Just be quiet and give us another three minutes of quiet while we do the Q&A. Das ist jetzt eine dumme Ruhe von den nächsten Gästen, von den nächsten Talk. Why does safety net not run with full permissions? Warum läuft safety net nicht mit full permissions? Weil es innerhalb von Google Play Services läuft. Also im Prinzip gibt es die Play App, also den Play App Service. Und der läuft einfach nur als Systemdienst. Und nicht als Full Services. Weil es in einer leicht privilegierten Anwärmung läuft. Einfach nur bei Design. Denkt zum Beispiel auch an andere Hersteller, die vielleicht nicht unbedingt einen super hoch privilegierten Google-Prozess auf einem Gerät haben wollen. Und das ist halt einfach der Grund, den wir so in den Kopf kommen. Vielen Dank. Das ist der Frage von Mico Nummer zwei, bitte. Hören Sie mich. Vielen Dank für den Talk. Erst mal, wie es aussieht, hat safety net läuft als ein Systemnutzer. Ja, und es hat viel mehr Gewilligien zu gucken. Beim File System lohnt es sich, weitere Checks zu machen. Es hängt tatsächlich sehr vom Risikomodell ab. Wenn du jetzt wirklich sehr hohe Sorgen vor modifizierten Anwendungen oder sowas hast, dann kannst du natürlich dann eine eigene Checks da einfügen. Aber wenn du eine neue App entwickelst, dann sollte man erst mal Safety Net-Adjustierung entwickeln und das alles richtig hinbekommen. Und dann kann man Geld investieren, eine eigene Lösung zu bauen. Wenn du dann mit deinem eigenen Anfängst, dann brauchst du ein eigenes Team, das die ganze Zeit mithält mit den Entwicklungen in der Android-Welt zusätzlich zu den anderen Sachen. Und du wirst voll als Positives haben und das dann wirklicherweise für viele Leute unbrauchbar macht. Und es hängt einfach sehr davon ab, was man machen will, wie viel man dafür ausgeben will und so weiter. Danke schön. Und leider ist die Zeit aus und alle anderen Fragen können, sollen bitte Kohlenacht im Talk finden. Ihr wisst bestimmt. Es ist nicht so einfach mit den Nerven, wenn die Präzision nicht so läuft, wie man erwartet. Ich hoffe, jetzt klatscht. Jetzt sehr laut, für Ihnen nochmals.