it-swarm.com.de

Bank beschwert sich über verwurzeltes Android. Ist es wirklich schlimmer als ein Windows-Desktop?

Wenn ich Android-Anwendung meiner Bank verwende, bemerkt die App, dass mein Telefon gerootet ist, und zeigt eine Nachricht mit einem großen roten "Gefahrensymbol" und einer Nachricht mit der Aufschrift "Anfälliges Gerät" an. Ich verstehe vollkommen, dass sie dies tun, weil Finanzinstitute immer gerne auf der sicheren Seite sind. Die Bank kann dann sagen "Wir haben Sie gewarnt!" Wenn jemand mit einem gerooteten Gerät sein Online-Banking gefährdet.

Jetzt stelle ich fest, dass mein Telefon weniger sicher ist als ein nicht verwurzeltes Android Gerät). Ich glaube, jeder wird es ohne weiteres tun stimme dem zu. ( Wie viel weniger wird offensichtlich von vielen Dingen abhängen.)

Aber der Gedanke, den ich habe, ist, unterscheidet sich das wirklich von der Verwendung von Net Banking in einem Browser, der auf einem Windows-Desktop ausgeführt wird? Ich meine, Windows ist auch in dem Sinne "verwurzelt", dass Sie die Möglichkeit haben, jeder gewünschten App "Root" (Administrator-) Berechtigungen zu erteilen?

In dem Sinne, dass sie sich darüber beschweren, dass mein Telefon Apps "Root" -Berechtigungen erteilen kann, ist dies nicht wie die Verwendung von Online-Banking auf einem Desktop-Betriebssystem, das auch über diese Funktion verfügt?

Was ist, wenn ich Online-Banking über eine Browser-App auf meinem Telefon verwendet habe? Wäre das sicherer als die App?

Würde sich die Verwendung von Online-Banking in einer Browser-App auf meinem Telefon von der Verwendung in einem Browser auf einem Windows-Desktop unterscheiden? (Beide sind Browser, die unter einem "gerooteten" Betriebssystem ausgeführt werden.)

Alles dreht sich um das Sicherheitsmodell

In fast allen Sicherheits-Checklisten für mobile Anwendungen (z. B. OWASP ) wird auf "Überprüfen auf Geräte mit Jailbreak/Root" verwiesen. Beim Vergleich mit Desktops oder Webbrowsern müssen wir berücksichtigen, dass sie unterschiedliche Bedrohungsmodelle haben.
Beispielsweise wissen wir auf Desktop-Computern beim Entwerfen einer Anwendung bereits, dass es andere Anwendungen gibt, die über Administratorrechte verfügen.

Das Sicherheitsmodell für Betriebssysteme wie Windows oder Linux verhindert beispielsweise nicht, dass eine Anwendung auf die Verzeichnisse oder den Speicher einer anderen Anwendung zugreift.

Im mobilen Kontext verhindert das Betriebssystem am Beispiel von Android als Beispiel), dass Anwendungen auf die Verzeichnisse der anderen zugreifen, und Root-Berechtigungen umgehen diese Sicherheitskontrolle. Wenn Sie also Ihr Gerät rooten, nehmen Sie eine Änderung vor Ihr Gerät, das von den Anwendungsentwicklern möglicherweise nicht vorhergesehen wird, und seine Risiken werden möglicherweise nicht berücksichtigt.

Zurück zu OWASPs Mobile Security Project (Gefahren von Jailbreaking/Rooting) werden die Rooting-Methoden wie folgt kategorisiert:

  • Userland Exploits: Jailbroken-Zugriff wird nur innerhalb der Benutzerebene erhalten. Beispielsweise kann ein Benutzer Root-Zugriff haben, den Startvorgang jedoch nicht ändern. Diese Exploits können mit einem Firmware-Update gepatcht werden.
  • iBoot Exploit: Jailbreak-Zugriff auf Benutzerebene und Startvorgang. iBoot-Exploits können mit einem Firmware-Update gepatcht werden.
  • Bootrom Exploits: Jailbreak-Zugriff auf Benutzerebene und Startvorgang. Bootrom-Exploits können nicht mit einem Firmware-Update gepatcht werden. Hardware-Update des Bootroms erforderlich, um in solchen Fällen zu patchen;

Und die Risiken sind:

General Mobile

  1. Bei einigen Jailbreaking-Methoden wird SSH mit einem bekannten Standardkennwort (z. B. Alpine) aktiviert, das Angreifer für Command & Control verwenden können.
  2. Das gesamte Dateisystem eines Geräts mit Jailbreak ist anfällig für einen böswilligen Benutzer, der Dateien einfügt oder extrahiert. Diese Sicherheitsanfälligkeit wird von vielen Malware-Programmen ausgenutzt, darunter Droid Kung Fu, Droid Dream und Ikee. Diese Angriffe können sich auch auf entsperrte Windows Phone-Geräte auswirken, abhängig von der erreichten Entsperrstufe.
  3. Anmeldeinformationen für vertrauliche Anwendungen wie Bank- oder Unternehmensanwendungen können mithilfe von Schlüsselprotokollierung, Sniffing oder anderer schädlicher Software gestohlen und dann über die Internetverbindung übertragen werden.

iOS

  1. Anwendungen auf einem Gerät mit Jailbreak werden als Root außerhalb der iOS-Sandbox ausgeführt. Auf diese Weise können Anwendungen auf vertrauliche Daten zugreifen, die in anderen Apps enthalten sind, oder schädliche Software installieren, die die Sandbox-Funktionalität negiert.
  2. Geräte mit Jailbreak können es einem Benutzer ermöglichen, selbstsignierte Anwendungen zu installieren und auszuführen. Da die Apps nicht über den App Store gehen, überprüft Apple überprüft sie nicht. Diese Apps enthalten möglicherweise anfälligen oder bösartigen Code, der zum Ausnutzen eines Geräts verwendet werden kann.

Android

  1. Android-Benutzer, die die Berechtigungen auf ihrem Gerät ändern, um Root-Zugriff auf Anwendungen zu gewähren, erhöhen die Sicherheit für schädliche Anwendungen und potenzielle Anwendungsfehler.
  2. Drittanbieter Android Anwendungsmärkte wurden als Host für schädliche Anwendungen mit Remoteverwaltungsfunktionen (RAT) identifiziert.

Nichttechnische Risiken

  1. Software-Updates können nicht sofort angewendet werden, da dies den Jailbreak entfernen würde. Dadurch ist das Gerät anfällig für bekannte, nicht gepatchte Software-Schwachstellen.
  2. Benutzer können dazu verleitet werden, schädliche Software herunterzuladen. Beispielsweise verwendet Malware häufig die folgenden Taktiken, um Benutzer zum Herunterladen von Software zu verleiten.
    Apps geben häufig an, dass sie zusätzliche Funktionen bereitstellen oder Anzeigen aus beliebten Apps entfernen, aber auch schädlichen Code enthalten.
    Einige Apps haben keinen Schadcode als Teil der ursprünglichen Version der App, aber nachfolgende "Updates" fügen Schadcode ein.

Man kann unzählige Risiken für jede Plattform zählen, die von Web, mobilen Anwendungen, Desktop-Anwendungen usw. reichen, und ein Vergleich dieser Plattformen hinsichtlich der Sicherheit ist nicht trivial. Es hängt möglicherweise stark von bestimmten Plattformen ab (Android vs iOS, Windows vs Linux) und auch vom Verhalten der Benutzer (ein mobiles Gerät mit vielen Junk-Anwendungen im Vergleich zu einem mobilen Gerät nur mit bekannten Apps). In jedem Kontext versuchen wir, Maßnahmen zu ergreifen, um unsere Risiken zu verringern. Sobald eine Plattform zu unsicher wird, stellen wir möglicherweise die Bereitstellung von Diensten ein (z. B. Telefonbanking über Festnetztelefon oder USSD).

Zurück zu Ihrer Frage zur Verwendung des Webbrowsers Ihres Mobiltelefons im Vergleich zur Verwendung der nativen Anwendung von Mobile Banks. Die Risiken hängen von der Implementierung der Mobile Banking-Anwendung und der Art der Malware ab, die möglicherweise auf Ihrem Mobiltelefon vorhanden ist.

21
Silverfox

Anwendungen in Android werden unter dem zugrunde liegenden Linux unterschiedliche UID/GIDs zugewiesen und sind somit auf diese Weise voneinander isoliert. Vergleichen Sie dies mit einer Standard-Desktopanwendung, bei der alle vom Benutzer ausgeführten Programme normalerweise die haben Gleiche Berechtigungen (ohne AppArmor- oder SELinux-Konfiguration für Linux). Ist Windows nicht ähnlich? Browser bieten einige Sandboxing-Funktionen, jedoch nur aus anderem vom Browser ausgeführtem Code, und selbst diese Umgebung bietet zahlreiche standortübergreifende Möglichkeiten für eine mögliche Ausnutzung.

Durch das Rooten kann der Benutzer eine beliebige Anwendung mit erhöhten Berechtigungen autorisieren. Dies stellt sicherlich eine Bedrohung dar und stört die Banken, weil sie das Gefühl haben, dass sie außerhalb ihrer Kontrolle liegen. Es liegt jedoch in der Kontrolle des Benutzers. Der wichtige Punkt ist, dass die Kompetenz und die Handlungen des Benutzers immer außerhalb der Kontrolle der Bank liegen. Vermutlich hat jeder, der sein Telefon verwurzelt, wahrscheinlich zumindest ein besseres Verständnis für die Risiken und das damit einhergehende Verständnis für Schadensbegrenzung. Die Bank weiß also nicht, mit wem der Benutzer sonst noch schläft - mit erhöhten Rechten - oder wie versiert er ist. Auf der anderen Seite ermöglicht Rooting Gegenmaßnahmen, die die Sicherheit verbessern können. Wenn der Benutzer nachlässig ist, kann das Rooten ihn sehr exponieren.

Auch ohne Root-Berechtigung kann jede Anwendung eine Anzeige anzeigen, die vorgibt, die Bankanwendung zu sein, und den Benutzer dazu verleiten, Authentifizierungsdaten bereitzustellen. Wie dies erfolgreich erreicht wird, ist zwar eine Herausforderung, aber für viele potenzielle Opfer definitiv möglich.

Ich glaube, dass das Dogma, dass root ein Telefon "unsicher" macht - ein schlecht definierter Begriff - irreführend ist und Banken ihre Aufmerksamkeit auf andere Angelegenheiten richten sollten.

FWIW, ich verwende root unter anderem, um iptables zu konfigurieren, da ich mit stock Android) interessanterweise keine Anwendungen für den Internetzugang selektiv autorisieren kann. Und wir können alle erraten, welchen Interessen gedient wird dieser Umstand.

4
Bill Michaelson

Ich stimme den Informationen von @Silverfox zu. Finanzinstitute zielen zweifellos darauf ab, das Betrugsrisiko zu verringern, indem sie ihre Sicherheitspolitik auf ein Bedrohungsmodell stützen, das nur für das Zielgerät gilt.

Viele Online-Banking-Systeme haben die Multi-Faktor-Authentifizierung (MFA) eingeführt, um die Identität ihres Benutzers zu beweisen. Dies bedeutet, dass ein Angreifer, der Ihre Kombination aus Benutzername und Kennwort erhält, nicht auf Ihr Konto zugreifen kann (er müsste entweder den Bestätigungscode erhalten oder einen zuvor "vertrauenswürdigen PC" fälschen/gefährden).

Durch die Eskalation von Berechtigungen kann der Gegner die Isolation aufheben und auf vertrauliche Daten zugreifen. Da das Telefon jetzt ein wichtiger Bestandteil des Benutzerauthentifizierungsschemas ist, ist ein gerootetes Gerät ein viel größeres Risiko für das Finanzunternehmen, da es kompromittiert wird. Beispielsweise kann die Malware Anmeldeinformationen aus der Banking-App stehlen oder sogar den Bestätigungscode SMS, der als Teil des MFA gesendet wird) abrufen und sofort löschen, um die Spuren vor dem Benutzer zu verbergen.

Eine wichtige Sache, die berücksichtigt werden muss, ist jedoch, dass diese Laufzeitumgebungsprüfungen häufig leicht umgangen werden können. Es gibt verschiedene Methoden und APIs für die Überprüfung, aber viele Anwendungen tun dies ungefähr: Überprüfen Sie, ob die Binärdatei "su" vorhanden ist. Wenn ja, wird davon ausgegangen, dass das Gerät über Root-Berechtigungen verfügt. Durch einfaches Umbenennen von "su" ist es durchaus möglich, diese Art der Prüfung zu umgehen.

Für bessere Ergebnisse verwenden viele moderne Android -Anwendungen etwas in der Art der Google SafetyNet-API, um eine Remote-Bestätigung durchzuführen und den Konformitätsstatus des Geräts zu überprüfen. Darüber hinaus gibt es Lösungen von Drittanbietern unter dem Dach von MDM-Anwendungen (Mobile Device Management), die in der Regel von großen Unternehmen bereitgestellt werden, die das Risiko teilen, dass ihre Mitarbeiter vertrauliche Daten tragen, z. B. wenn ihre geschäftliche E-Mail-App gefährdet wird, wenn ein gerootetes Gerät infiziert wird.

2
Amir