Was mir Bad Guys 2 über Informationsasymmetrie und die Application Security Ein Problem, das niemand benennen will

01 Sie waren Schüler Ihrer Arbeit

Es gibt eine Szene in „Bad Guys 2“, die jedem Sicherheitsexperten zu denken geben sollte. Als die Bad Girls – Kitty Kat, Pigtail Petrova und Doom – sich zum ersten Mal zeigen, kommen sie nicht etwa mit überlegener Feuerkraft oder besserer Technologie daher. Sie treten als Bewunderer auf. Fans. „Schülerinnen ihrer Arbeit“, wie der Film es ausdrückt. Sie haben die Bad Guys so gründlich studiert, dass sie deren Vorgehensweisen kopieren, ihre Züge vorhersehen und ihre Beziehungen ausnutzen können. Als die Bad Guys schließlich begreifen, was vor sich geht, ist das Spiel bereits entschieden. Die Informationsasymmetrie war schon vor der Eröffnungsszene vollkommen.

Die Angreifer hatten Ihre Arbeit bereits analysiert. Sie besaßen Ihre Binärdatei. Nichts von dieser Aufklärung tauchte in Ihren Protokollen auf.

Das ist keine raffinierte filmische Inszenierung. Das ist die Beschreibung des Produkts jedes schwerwiegenden Sicherheitsverstoßes in Anwendungen im letzten Jahrzehnt.

Die Angreifer hatten Ihre Arbeit bereits analysiert. Sie besaßen Ihre Binärdatei. Sie führten sie offline, mit Disassemblern und Debuggern, in aller Ruhe und ohne Zeitdruck oder Alarmsystem aus. Sie kannten Ihre kryptografischen Schlüssel, Ihre Authentifizierungslogik, Ihre API-Aufrufmuster und Ihr Verschleierungsschema – sofern Sie eines verwendet hatten. Sie kannten Ihre Anwendung besser als die meisten Ihrer eigenen Entwickler. Und all diese Aufklärungsergebnisse blieben in Ihren Protokollen verborgen.

Die Frage ist nicht, ob dies Ihrer Anwendung passiert. Das passiert. Die Frage ist, was sie bei der Überprüfung finden.

02 Informationsasymmetrie ist das eigentliche Problem

Informationsasymmetrie ist ein Konzept, das Ökonomen verwenden, um Situationen zu beschreiben, in denen eine Partei einer Transaktion deutlich mehr weiß als die andere. George Akerlof erhielt 2001 den Nobelpreis für seine Forschung darüber, wie asymmetrische Information Märkte zerstört – sein berühmtes Beispiel ist der Gebrauchtwagenmarkt, wo Verkäufer den wahren Zustand des Autos kennen, Käufer jedoch nicht, was zu einem Markt führt, der sich in Richtung mangelhafter Fahrzeuge verdichtet. Die Partei mit mehr Informationen gewinnt systematisch, nicht weil sie intelligenter ist, sondern weil sie Dinge weiß, die die andere Partei nicht weiß.

Im Bereich der Anwendungssicherheit liegt die Asymmetrie ab dem Zeitpunkt der Auslieferung vollständig zugunsten des Angreifers. Dieser erhält die Binärdatei. Diese enthält Ihre Logik, Ihre Schlüssel, Ihre Geheimnisse und Ihre Vertrauensannahmen. Der Angreifer kann sie uneingeschränkt untersuchen. Sie als Entwickler können nicht sehen, was der Angreifer mit Ihrer Anwendung anstellt, sobald diese Ihre Umgebung verlässt. Sie erhalten zwar Protokolle, der Angreifer hingegen hat nahezu uneingeschränkten Einblick in alles, was Sie ausgeliefert haben.

Dies ist keine bloße Hypothese. Moderne Dekompiler und Disassembler haben Reverse Engineering so weit demokratisiert, wie es vor zwanzig Jahren noch undenkbar gewesen wäre. Ein kompetenter Analyst kann mit frei verfügbaren Tools eine mobile Anwendung nehmen, ihre Verschleierungsschicht innerhalb eines Nachmittags entfernen, fest codierte Schlüssel innerhalb weniger Stunden extrahieren und die gesamte Serverkommunikationsschnittstelle der Anwendung in ein bis zwei Tagen abbilden. Die Tools sind ausgereift. Die Dokumentation ist umfassend. Die zugehörigen Communities sind aktiv.

Die „Bösen Mädchen“ mussten nicht schlauer sein als die „Bösen Jungs“. Sie brauchten lediglich mehr Informationen über die „Bösen Jungs“, als diese über sie wussten. Im Film wurde diese Asymmetrie durch geduldige Beobachtung und Recherche aufgebaut. In der Anwendungssicherheit hingegen erzeugt der Angreifer diese Asymmetrie in dem Moment, in dem er Ihre App aus dem Store herunterlädt.

03 Das Problem mit der purpurnen Pfote: Wenn das Geheimnis die Schachtel verlässt

Der lehrreichste Moment in Bad Guys 2 ist nicht der Raubüberfall selbst, sondern das Filmmaterial.

Gouverneurin Diane Foxington hat eine geheime Identität: die Crimson Paw, ihr früheres kriminelles Alter Ego. Dieses Geheimnis wird seit Jahren streng gehütet. Es ist die Grundlage ihrer öffentlichen Autorität, ihrer politischen Legitimität und ihrer Beziehung zu Wolf. Es ist in jeder Hinsicht ein kryptografischer Schlüssel – eine verborgene Information, auf der ein ganzes System des Vertrauens beruht.

Kitty Kat besitzt das Videomaterial. Sie nutzt es zur Erpressung und zwingt die Bösewichte zur Kooperation bei ihrem Coup. Im Höhepunkt des Films, als Wolf glaubt, den USB-Stick mit dem Videomaterial wiedergefunden zu haben, lädt Kitty es trotzdem ins Internet hoch. Dianes geheime Identität wird weltweit bekannt. Der Erpressungseffekt verpufft, doch mit ihm alles, was das Geheimnis schützte. Die Glaubwürdigkeit der Gouverneurin, ihre Beziehung, ihre politische Karriere – allesamt abhängig davon, dass dieser Schlüssel verborgen bleibt – brechen gleichzeitig zusammen.

Genau das passiert, wenn kryptografische Schlüssel aus einer Anwendung extrahiert werden.

Der Schlüssel ist das Geheimnis. Das Geheimnis ist die Grundlage des Vertrauenssystems. Sobald es extrahiert ist – sobald der Angreifer es besitzt – spielt Ihre Reaktion keine Rolle mehr. Die Gefährdung ist asymmetrisch und unumkehrbar. Sie können den Schlüssel ändern, die Anwendung patchen, das Zertifikat widerrufen. Der Angreifer hat bereits, was er braucht.

Wolfs Fehler bestand darin, zu glauben, der Besitz des USB-Sticks bedeute die Kontrolle über das Geheimnis. Das Geheimnis war jedoch bereits aus der Verpackung verschwunden. In der Entwicklung von mobilen und Webanwendungen ist dieser Fehler struktureller Natur. In Binärdateien eingebettete Schlüssel sind keine Geheimnisse. Sie stellen zeitverzögert öffentlich zugängliche Informationen dar. Die Verzögerung entspricht der Zeit, die ein kompetenter Analyst für die Analyse benötigt.

04 Der USB-Stick-Wahn

Ein Fehler, der im Denken über Anwendungssicherheit immer wieder auftritt, ist die Verwechslung von Container und Geheimnis. Unternehmen behandeln Schlüssel so, als ob deren Sicherheit von der Sicherheit ihres Speicherorts abhinge. Hardware-Sicherheitsmodul? Sicher. Verschlüsselter Schlüsseltresor? Sicher. Fest im Binärcode der mobilen Anwendung codiert? Nun ja, wir haben ein Drittanbieter-Verschleierungstool verwendet, also…

Wolf glaubte, der USB-Stick enthalte das Videomaterial. Kitty hatte bereits Kopien angefertigt und den Upload in die Warteschlange gestellt, bevor sie ihm irgendetwas aushändigte. Der physische Überrest war nur ein Requisit, ein Platzhalter. Etwas, das er ihm geben konnte, damit Wolf aufhörte, nach dem eigentlichen Videomaterial zu suchen, das sich zu diesem Zeitpunkt auf einer Infrastruktur befand, auf die er keinen Einblick hatte.

Die Verschleierung ist der USB-Stick. Es ist nicht das Filmmaterial.

Das ist etwas, was die Branche immer wieder lernt und vergisst. Verschleierung erschwert Reverse Engineering und erhöht die Kosten. Bei manchen Bedrohungsmodellen ist diese Kostensteigerung eine sinnvolle Verteidigungsmaßnahme. Doch für jeden Angreifer mit ausreichendem Motiv – sei es ein Staat, eine organisierte Finanzkriminalität oder ein finanzstarker Konkurrent – ​​ist Verschleierung nur eine Verzögerung, keine Verteidigung. Der Schlüssel liegt weiterhin im Binärcode. Ein erfahrener Analyst wird ihn finden. Er braucht dafür vielleicht drei Tage statt drei Stunden. Das Ergebnis ist dasselbe.

Die klassische Kryptographie basiert auf der Annahme, dass Algorithmen öffentlich und Schlüssel geheim sind. Das gesamte theoretische Gerüst moderner Verschlüsselung ist nur so lange gültig, wie diese Annahme zutrifft. In einer Umgebung, in der die Anwendung auf Hardware läuft, die vom Angreifer kontrolliert wird – also auf jedem Mobilgerät, jedem IoT-Endpunkt, jeder Client-Anwendung –, ist diese Annahme nicht mehr gegeben. Der Schlüssel befindet sich irgendwo im Binärcode.

Mit genügend Zeit und den richtigen Werkzeugen lässt sie sich finden. Die einzige kryptografische Architektur, die die Schlüsselextraktion übersteht, ist diejenige, bei der die Schlüsselextraktion nichts Brauchbares liefert.

05 Susan war nie Susan: Die Insiderbedrohung als Informationsbeschaffungskanal

Snakes Freundin „Susan“ ist Doom. Sie wirkt nicht bedrohlich, sondern eher wie eine Beziehung. Snake, der sich in letzter Zeit immer seltener an den Operationen der Bad Guys beteiligt hat, verbringt seine Zeit mit jemandem, der sich genau den Zugang verschafft hat, den sie braucht. Sie muss den Perimeter nicht durchbrechen. Sie ist bereits innerhalb des Perimeters. Snake lässt sie herein.

Die Position innerhalb der Gruppe ist sowohl im Film als auch in der Realität einer der zuverlässigsten Angriffswege. Die „Bad Girls“ mussten die „Bad Guys“ nicht durch einen Angriff von außen kompromittieren. Sie brauchten einen vertrauenswürdigen Knotenpunkt innerhalb ihres Beziehungsnetzwerks, und Snake lieferte ihn ihnen, ohne es selbst zu ahnen.

Im Bereich der Anwendungssicherheit lässt sich dies direkt auf die Lieferkette übertragen. Die größte Gefahr für eine gehärtete Anwendung geht nicht von der Anwendung selbst aus, sondern von dem, worauf die Anwendung vertraut. Drittanbieter-SDKs, Open-Source-Abhängigkeiten, API-Dienste, Analysepakete – jede externe Bibliothek, die Ihre Anwendung zur Laufzeit initialisiert, hat prinzipiell denselben Zugriff auf den Laufzeitzustand Ihrer Anwendung wie Ihr eigener Code. Wenn diese Bibliothek kompromittiert ist oder von vornherein bösartig war, ist die Vertrauensbeziehung, die Sie innerhalb Ihrer eigenen Codebasis aufgebaut haben, irrelevant.

Das SolarWinds-Sicherheitslücke 2020 Das Paradebeispiel auf Infrastrukturebene ist die Kompromittierung eines Build-Systems, das bösartige Updates über vertrauenswürdige Kanäle an Tausende von Organisationen verteilte. Dieses Muster lässt sich jedoch routinemäßig auf mobile Anwendungen übertragen. Ein mobiles SDK eines legitimen Anbieters wird erworben. Der neue Eigentümer liefert ein Update mit integrierter Datenexfiltration aus. Jede Anwendung, die dieses SDK automatisch bezogen hat, führt nun Code aus, der alle Vertrauensannahmen verletzt, auf denen sie basierte. Die Perimeter-Sicherheitslücke wurde nie durchbrochen. Die Vertrauensbeziehung selbst war der Angriff.

Susan war nie Susan. Ihr Analytics-SDK ist möglicherweise nicht Ihr Analytics-SDK.

06 Zopf kennt Ihre Unterschriften

Pigtail Petrova, die geniale Ingenieurin unter den Bad Girls, ist die technisch interessanteste Figur des Films. Sie war es, die die Bad Guys überführte. Nicht mit Gewalt, sondern durch Nachahmung. Sie studierte die Methoden der Bad Guys – ihre typischen Verhaltensweisen, ihre Vorgehensweise, ihre verräterischen Anzeichen – so gründlich, dass sie Verbrechen begehen konnte, die von ihren Taten nicht zu unterscheiden waren. Die Bad Guys wurden für Raubüberfälle verantwortlich gemacht, die sie nicht begangen hatten, weil Pigtail ihr Verhalten bis ins kleinste Detail imitieren konnte.

Das ist Reverse Engineering im Rahmen der Wettbewerbsanalyse. Genau das tun auch raffinierte Finanzangreifer, um Anwendungsauthentifizierungssysteme zu kompromittieren.

Wenn ein Angreifer eine Mobile-Banking-Anwendung vollständig analysiert, findet er nicht nur die Schlüssel, sondern auch das Verhalten. Er versteht die Abfolge der API-Aufrufe, die eine legitime Sitzung ausmacht. Er versteht das Challenge-Response-Protokoll, mit dem die Anwendung ihre Authentizität gegenüber dem Server nachweist. Er versteht, welche Gerätetelemetriedaten die Anwendung sendet, welche Header sie enthält und welche Zeitmuster die normale Nutzung kennzeichnen. Mit diesen Informationen kann er einen Emulator erstellen – einen synthetischen Client, der das Verhalten der Anwendung so genau nachahmt, dass er die serverseitige Validierung besteht.

Der Server empfängt Anfragen, die den Anschein erwecken, von einer legitimen Anwendung zu stammen. Forensisch sind sie von legitimen Anfragen nicht zu unterscheiden, da der Angreifer die Signatur der legitimen Anfrage analysiert und nachgebildet hat. Der Betrug bleibt unentdeckt, bis das Betrugsmuster selbst erkennbar wird – bis dahin hat der Angreifer bereits Tausende von Transaktionen durchgeführt.

07 MacGuffinite und das wahre Ziel

Die Filmemacher sorgten für Lacher, indem sie ihren MacGuffin „MacGuffinite“ nannten – ein seltenes Metall, das Gold magnetisch anzieht. Der Witz ist eine Anspielung auf Hitchcock: Ein MacGuffin ist das, was die Handlung erfordert, dass alle es unbedingt haben wollen, unabhängig von seiner eigentlichen Bedeutung. Der MacGuffinite ist der Vorwand. Das wahre Ziel ist die Bergung des gesamten Goldes der Welt von der multinationalen Raumstation. Der aufwendige Coup ist die Infrastruktur für das eigentliche Ziel, das in einer ganz anderen Größenordnung stattfindet.

Sicherheitsteams sind darauf trainiert, das MacGuffinite zu verteidigen. Der Angreifer will etwas anderes.

Wenn ein Angreifer Ihre mobile Anwendung per Reverse Engineering analysiert, liegt sein Hauptziel offensichtlich in den kryptografischen Schlüsseln. Doch Schlüssel sind oft nur Mittel zum Zweck. Was der Angreifer tatsächlich anstrebt, könnte die Möglichkeit sein, in großem Umfang gültige Authentifizierungstoken zu generieren – und damit die Konten von Millionen von Nutzern zu übernehmen. Es könnte ihm auch darum gehen, Finanzdaten während der Übertragung abzufangen und zu verändern, ohne dass Certificate Pinning ausgelöst wird. Oder es könnte ihm darum gehen, die Identität der Anwendung zu klonen, um direkt auf Backend-Dienste zuzugreifen und so alle Sicherheitsvorkehrungen zu umgehen, die die Anwendung auf Client-Ebene durchsetzt.

Der entscheidende Diebstahl ist die Smartwatch-Aktion auf der Hochzeit. Reibungslos, präzise, ​​nahezu unauffällig. Der eigentliche Clou ist das, was danach passiert.

08 Der Perimeter war immer ein Vorschlag, keine Mauer.

Die Sicherheitsbranche hat fast zwei Jahrzehnte damit verbracht, Perimeter zu errichten: Firewalls, Intrusion-Detection-Systeme, Netzwerksegmentierung, Zero-Trust-Architektur. Das zugrundeliegende Modell: Angreifer draußen halten, dem Verborgenen vertrauen und die Grenze zwischen beiden schützen.

Das Modell war sinnvoll, solange die Anwendung auf Ihrer Hardware, in Ihrem Rechenzentrum und hinter Ihrer Firewall lief. Es stieß an seine Grenzen, als die Anwendung in die Cloud verlagert wurde. Völlig versagte es, als die Anwendung auf die Hosentasche des Nutzers wanderte.

Eine mobile Anwendung wird auf Hardware bereitgestellt, die der Angreifer kontrolliert. Ein IoT-Gerät wird auf Hardware bereitgestellt, die der Angreifer physisch in Besitz nehmen kann. Eine Webanwendung wird in einem Browser geladen, den der Angreifer untersuchen kann. In keiner dieser Umgebungen greift das Perimeter-Modell. Die Anwendung befindet sich nicht innerhalb des Perimeters. Sie befindet sich außerhalb des Perimeters und läuft von dem Moment ihrer Veröffentlichung an in einer feindlichen Umgebung.

Dies ist das architektonische Problem, das Perimetersicherheit nicht lösen kann. Sie können Ihre Serverumgebung makellos gestalten. Keine Schwachstellen in der Infrastruktur. Perfekte Netzwerksegmentierung. Tadellose Zugriffskontrollen für jeden Backend-Dienst. Und dann wird Ihre mobile Anwendung mit einem fest codierten Service-Schlüssel und einem Verschleierungsschema ausgeliefert, das ein unerfahrener Analyst mit einem freien Wochenende knacken kann. Der Angreifer greift nicht Ihren Server an. Er greift Ihre Anwendung an, die nahtlos mit Ihrem Server kommuniziert.

09 Die Geometrie der Angriffsfläche hat sich verändert

Finanzdienstleistungen. Gesundheitswesen. Rüstungsindustrie. Telekommunikation. Jede Branche, die in den letzten zehn Jahren ihre kundenorientierten Prozesse digitalisiert hat, hat unbewusst ihre Angriffsfläche vom Rechenzentrum zum Endgerät verlagert. Sensible Daten, Authentifizierungslogik, kryptografische Operationen – all das läuft nun zumindest teilweise auf Hardware, die dem Unternehmen weder gehört noch von ihm kontrolliert wird.

Die Auswirkungen auf die Kryptographie sind spezifisch und werden unterschätzt. Klassische Kryptographie – die AES-256-Verschlüsselung, die RSA-Signaturen, die TLS-Handshakes – ist unter der Annahme, dass der Schlüssel geheim ist, nachweislich sicher. Diese Annahme ist nicht mathematischer, sondern physikalischer Natur. Die Mathematik moderner Verschlüsselung ist korrekt. Das Problem liegt in der Annahme selbst.

Wenn eine Anwendung kryptografische Operationen auf einem vom Angreifer kontrollierten Gerät ausführt, kann dieser den Speicher der Anwendung beobachten, sobald der Schlüssel geladen, die Operation ausgeführt und die Ausgabe erzeugt wird. Eine Angriffsklasse, sogenannte Seitenkanalangriffe, nutzt genau dies aus: Stromverbrauch, elektromagnetische Emissionen, Timing-Schwankungen und Cache-Zugriffsmuster – all dies gibt Informationen über den verwendeten Schlüssel preis. Bei einem White-Box-Angriff geht der Angreifer noch einen Schritt weiter: Er behandelt die Anwendung selbst als offene Box zur Analyse und extrahiert den Schlüssel direkt aus dem kompilierten Code.

AES-256 ist immer noch AES-256. Aber wenn der Schlüssel zugänglich ist, ist die Verschlüsselung nur so stark wie die Geheimhaltung des Schlüssels – und die Geheimhaltung des Schlüssels ist null oder nahezu null.

10. Binäre Härtung ist keine Verschleierung. White-Box-Kryptographie ist keine Verschlüsselung.

Hier muss die Sicherheitsdiskussion präziser werden, denn die Vermischung dieser Konzepte kostet Unternehmen echtes Geld und birgt ein reales Risiko.

Verschleierung macht Code schwerer lesbar. Sie benennt Variablen um, vereinfacht den Kontrollfluss, fügt unnötigen Code ein und verschlüsselt Zeichenketten. Ein entschlossener Analyst wird sie letztendlich durchschauen. Verschleierung ist Verzögerung. Sie ist wie ein USB-Stick.

Binäre Härtung ist etwas anderes. Sie stattet die Anwendung selbst mit Schutzmechanismen aus, die Manipulationen erkennbar machen oder verhindern. Dazu gehören Anti-Debugging-Techniken, die erkennen, wenn die Anwendung unter einem Debugger ausgeführt wird, und das Verhalten entsprechend anpassen. Integritätsprüfungen verifizieren den Code der Anwendung zur Laufzeit und verweigern die Ausführung bei festgestellten Änderungen. Manipulationsschutzmechanismen erkennen, ob die Anwendung in einer emulierten Umgebung läuft. Umgebungsprüfungen identifizieren Root-/Jailbreak-Zustände, die auf ein Angreifergerät hindeuten. Binäre Härtung verlangsamt nicht nur die Analyse – sie verändert die Effektivität von Angriffen, indem sie die gängigsten Reverse-Engineering-Methoden unzuverlässig macht.

White-Box-Kryptographie löst das Problem der Schlüsseloffenlegung direkt. Bei herkömmlicher Black-Box-Kryptographie ist der Schlüssel eine separate Eingabe für die kryptographische Operation. Bei White-Box-Kryptographie hingegen ist der Schlüssel mathematisch in die Implementierung selbst eingebettet. Dies geschieht durch eine Reihe mathematischer Transformationen, die den Schlüssel selbst dann unwiederbringlich machen, wenn der Angreifer vollen Zugriff auf den Code und den Speicher hat und jede Zwischenberechnung beobachten kann. Die kryptographische Operation liefert weiterhin korrekte Ergebnisse. Der Schlüssel kann nicht aus der Implementierung extrahiert werden. Es gibt keinen USB-Stick, der übergeben werden könnte.

Dies sind keine inkrementellen Verbesserungen der Perimeter-Sicherheit. Es handelt sich um einen anderen architektonischen Ansatz: Anstatt Angreifer von der Anwendung fernzuhalten, entwickelt man eine Anwendung, die auch dann sicher bleibt, wenn Angreifer vollen Zugriff darauf haben.

11 App-basierte Bedrohungsanalyse: Erkennen, wann die gefährlichen Mädchen bereits im System sind

Das grundlegende Problem der Bösewichte im Film ist ihre reaktive Natur. Sie reagieren auf Ereignisse, die sie nicht vorhergesehen haben, weil sie keine Ahnung hatten, was sich gegen sie zusammenbraute. Sie wussten nichts von den Bösewichtinnen, bis diese sich – zu einem von ihnen gewählten Zeitpunkt und unter ihren eigenen Bedingungen – zu erkennen gaben.

Die Anwendungssicherheit stand historisch gesehen vor demselben Problem: Der Angriff wird erst im Nachhinein entdeckt. Protokolle werden nach dem Sicherheitsvorfall ausgewertet. Forensische Analysen rekonstruieren die Aktionen des Angreifers. Der Zeitraum zwischen der ersten Kompromittierung und der Entdeckung – in der Branche als Verweildauer bezeichnet – beträgt durchschnittlich Wochen bis Monate. Während dieser Zeit agiert der Angreifer mit der Informationsasymmetrie, die ihm vollständig zu seinen Gunsten zukommt.

Die logische Gegenmaßnahme ist die Instrumentierung, die die Erkennung in einen früheren Abschnitt der Angriffskette verschiebt – bevor die Schlüsselextraktion abgeschlossen ist, bevor das gefälschte Sitzungstoken verwendet wird und bevor der emulierte Client seinen ersten betrügerischen Anruf tätigt. Anwendungen, die ihre eigene Laufzeitumgebung überwachen und Anomalien melden können – Debugging-Aktivitäten, ungewöhnliche Speicherzugriffsmuster, Ausführung in Emulatoren, manipulierter Code, der auf Live-Diensten ausgeführt wird – erzeugen Telemetriedaten, die die Verweildauer des Angreifers verkürzen.

Wenn Ihre Anwendung Ihnen mitteilen kann, dass sie in einem Debugger ausgeführt wird, ist der Analyst, der Ihre Binärdatei untersucht, nicht länger unsichtbar. Wenn Ihre Anwendung meldet, dass eine gecrackte Version Ihre Server anruft, bleibt die Pigtail-Imitation nicht monatelang unentdeckt. Die Informationsasymmetrie beginnt zu schwinden.

12 Die eine Frage, die Sie sich vor dem Versand stellen sollten

Bevor die Bösewichte einen Auftrag annahmen, hatte Wolf einen Plan. Dieser Plan basierte auf der Annahme, dass die Bösewichte über bestimmte Informationsasymmetrien verfügten. Sie wussten Dinge, die das Ziel nicht wusste. Sie besaßen Fähigkeiten, die das Ziel nicht vorhersehen konnte. Der Plan ging auf, solange diese Asymmetrie bestand.

Die „Bad Girls“ drehten den Spieß um. Sie verschafften sich ein umfassenderes Bild von den „Bad Guys“, als diese selbst hatten – zumindest in operativer Hinsicht. Der Plan scheiterte, weil die Informationsasymmetrie, auf der er beruhte, bereits umgekehrt war.

Bevor Sie Ihre nächste Anwendung veröffentlichen, sollten Sie sich eine Frage stellen: Findet der Angreifer, der Ihre Binärdatei per Reverse Engineering analysiert, etwas Brauchbares?

Lautet die Antwort „Ja“ – sind also Schlüssel, reproduzierbare Authentifizierungssignaturen oder Logik enthalten, die bei Offenlegung das Vertrauen untergräbt –, dann beruht Ihr Plan auf einer Informationsasymmetrie, die der Angreifer früher oder später ausgleichen wird. Irgendwo studieren sie Ihre Arbeit.

Die Bösen gewinnen natürlich am Ende. Es ist schließlich ein Familienfilm. Aber sie gewinnen, indem sie die Informationsasymmetrie verändern – indem sie Kittys Plan durchschauen, ihr wahres Ziel erkennen und auf Basis von Wissen handeln, von dem sie selbst nichts wusste. Genauso gewinnt man auch in der Anwendungssicherheit. Man gewinnt nicht, indem man hofft, dass die Angreifer die eigene Arbeit nie analysieren. Das haben sie bereits getan. Man gewinnt, indem man sicherstellt, dass das, was sie analysiert haben, ihnen keine Hinweise auf ihr weiteres Vorgehen gibt.

Digital.ai Anwendungsschutz

Digital.ai's Plattform Dieser Ansatz beginnt auf der Binärebene. Binärhärtung schützt die Anwendung vor den gängigsten Reverse-Engineering- und Manipulationsmethoden – Anti-Debugging, Integritätsprüfung, Umgebungserkennung und Laufzeit-Selbstschutz. White-Box-Kryptografie bettet Schlüssel so in die Implementierung ein, dass ihre Extraktion mathematisch unmöglich und nicht nur umständlich ist. Anwendungsbasierte Intelligenz liefert Telemetriedaten darüber, was mit Ihrer Anwendung in freier Wildbahn geschieht – ob sie analysiert, modifiziert oder imitiert wird.

Ziel ist es nicht, den Analysten zu verlangsamen. Ziel ist es vielmehr sicherzustellen, dass die Erkenntnisse des Analysten, selbst bei vollem Zugriff, keinen operativen Vorteil bringen. Wenn der USB-Stick leer ist, kann Kitty nichts hochladen.