Android Mobile Root Detection – Allheilmittel gegen Angriffe?

research vulnerability

Android ist eines der am weitesten verbreiteten mobilen Betriebssysteme der Welt. Aufgrund dieser Verbreitung ist es jedoch auch ein interessantes Ziel für Angriffe.

Root Detection

Eine der größten Bedrohungen sind Root-Exploits, die die Sicherheit eines Android-Geräts gefährden können. In einem Forschungsprojekt wollte SEC Consult herausfinden, ob aktuelle Root-Erkennungsbibliotheken, die von Applikationen, welche mit hoch-sensiblen Informationen arbeiten (z.B. Bank- oder Gesundheitsapplikationen), erkennen können, ob ein Gerät während der Laufzeit durch eine bösartige Anwendung via Root-Exploit kompromittiert wird. Das Ziel ist es, die Nützlichkeit der Root-Erkennung im Allgemeinen zu hinterfragen und die verschiedenen Implementierungsmöglichkeiten zu diskutieren.

Um dieses Thema besser zu verstehen, werden unsere Experten für mobile Sicherheit, Hussam Cheaib und Fabian Densborn, zunächst beschreiben, was Rooting eigentlich ist, welche verschiedenen Arten von Root es gibt und wie bzw. ob Root-Erkennung überhaupt funktioniert.

Was ist Rooting?

Rooting ist der Prozess der Erlangung von Administrationsrechten (Root-Rechten) auf einem Android-Gerät. Standardmäßig werden Android-Geräte mit eingeschränkten Benutzerkonten eingerichtet, die über begrenzte Berechtigungen verfügen. Diese Einschränkungen verhindern, dass Benutzer auf bestimmte Systemdateien und Einstellungen zugreifen können, was die Sicherheit und Stabilität des Geräts verbessern kann. Sobald ein Gerät gerootet wurde, hat der Benutzer die volle Kontrolle über das Gerät, einschließlich der Möglichkeit, benutzerdefinierte Software zu installieren, Systemeinstellungen zu ändern und auf Systemdateien zuzugreifen, die zuvor eingeschränkt waren. Das Rooten kann dem Benutzer zwar mehr Kontrolle über sein Gerät geben, birgt aber auch Risiken in sich. Durch das Rooten wird das Gerät möglicherweise anfälliger für Sicherheitsbedrohungen wie Malware und andere bösartige Software. Es gibt zwei verschiedene Arten des Rootings, die unterschieden werden müssen und im Folgenden beschrieben sind.

Nutzer Root - Willentliches rooten des eigenen Geräts

Für Benutzer, die mehr Kontrolle über ihr Gerät wünschen, kann Rooting eine Möglichkeit sein, diese Einschränkungen zu umgehen und die volle Kontrolle über das Betriebssystem zu erlangen. Beim Rooten wird im Wesentlichen die Firmware oder Software des Geräts verändert, um einen privilegierten Zugriff auf die Systemdateien und Systemeinstellungen zu ermöglichen. Das Rooten kann mit verschiedenen Methoden erfolgen, z. B. mit einem Rooting-Tool oder durch das Aufspielen einer modifizierten Version des Android-Betriebssystems ("Custom ROM"). In den meisten Fällen wird eine Gatekeeper-Anwendung wie Magisk installiert, um den Zugriff auf diese erweiterten Berechtigungen zu regulieren. In diesem Szenario sind sich die Benutzer über den Zustand des Geräts bewusst, weil sie das Gerät selbst modifiziert haben. Sie wollen die Flexibilität nutzen, die sie durch das Rooten ihres eigenen Geräts erhalten. Es gibt viele Artefakte auf dem Gerät, anhand derer man erkennen kann, dass ein solches Gerät gerootet ist. Da das Rooten jedoch beabsichtigt ist, versuchen die meisten modifizierten Android-Versionen nicht einmal, solche Artefakte zu verbergen.

Bösartiges Root - Gerät wird durch einen Angreifer kompromittiert

Bösartiges Root wird häufig von Schadsoftware verwendet, um erhöhte Administrationsrechte (Root-Rechte) zu erhalten. In den meisten Fällen wird ein Kernel-Exploit missbraucht, um die Privilegien zu erweitern. Die Schadsoftware führt im Anschluss ihre bösartigen Aktionen aus. Nur wenige Artefakte, die auf die Kompromittierung des Systems hinweisen könnten, werden auf dem Gerät platziert, da die Schadsoftware versucht, ihre bösartige Absicht zu verbergen. Dies macht es fast unmöglich, einen bösartigen Root zu entdecken, da die Malware dank ihrer hohen Privilegien alle ihre Spuren verwischen kann. Die meisten bösartigen Root-Exploits sind vorübergehend, d. h. sie überleben keinen Geräte-Neustart. Da Smartphones in der Regel aber ohnehin selten neu gestartet werden, kann die Schadsoftware sehr lange auf dem Gerät überleben. Es gibt jedoch auch bösartige Root-Exploits, die dauerhaft bestehen bleiben können, einige von ihnen überleben sogar das Zurücksetzen des Smartphones auf die Werkseinstellungen.

Root-Exploits sind im Wesentlichen Schwachstellen, die es Angreifern ermöglichen, Root-Rechte auf einem Gerät zu erlangen. Sobald Angreifer Root-Rechte erlangt haben, können sie alles auf dem Gerät tun, einschließlich der Änderung von Systemdateien, dem Diebstahl von Daten und der Installation von zusätzlicher Schadsoftware.

Die meisten Root-Exploits nutzen eine Kernel-Schwachstelle aus, um erhöhte Rechte auf dem Gerät zu erlangen. Für eine erfolgreiche Ausnutzung müssen jedoch zunächst viele Sicherheitsfunktionen wie SECCOMP oder SELinux umgangen werden. Zusätzlich müssen die meisten Root-Exploits auf ein bestimmtes Gerät zugeschnitten sein, damit sie funktionieren. 

Root-Erkennung

Was ist Root-Erkennung?

Root-Erkennung ist eine Technik, die von einigen Android-Apps verwendet wird, um festzustellen, ob ein Gerät kompromittiert wurde. Wenn eine App installiert wird, prüft sie auf Anzeichen für Rooting, z. B. das Vorhandensein bestimmter Dateien oder Ordner, die während des Prozesses erstellt wurden. Wird erkannt, dass das Gerät verändert wurde, deaktiviert die App möglicherweise bestimmte Funktionen, die von einem Angreifer mit Root-Zugriff ausgenutzt werden könnten, oder sie verweigert die Ausführung ganz. Der Zweck dieses Prozesses ist es, sicherzustellen, dass die App auf einem Gerät läuft, das die Standardsicherheitsmaßnahmen des Betriebssystems gewährleistet. Dazu zählt beispielsweise, dass das private Verzeichnis einer Anwendung nur für die App selbst zugänglich ist und nicht von anderen Apps auf diese sensiblen Daten zugegriffen werden kann. 

Wie funktioniert Root-Erkennung?

Die Root-Erkennung kann auf unterschiedliche Weise funktionieren, abhängig von der App und den verwendeten Techniken. Einige Apps prüfen lediglich, ob bestimmte Dateien oder Ordner vorhanden sind, die oftmals beim Rooten des Geräts erstellt werden. Andere verwenden fortschrittlichere Techniken, wie z. B. die Überprüfung des Kernels auf Änderungen oder auf Manipulationsanzeichen des Dateisystems. Einige Anwendungen verwenden auch eine Kombination aus verschiedenen Techniken, um die Genauigkeit ihrer Root-Erkennung zu verbessern.

Die meisten Root-Erkennungsbibliotheken überprüfen die folgenden Dinge:

  • Sind Root-Management-Anwendungen (z. B. Magisk) auf dem Gerät installiert?
  • Sind andere potenziell bösartige Anwendungen installiert?
  • Enthält das Build-Tag Testschlüssel?
  • Hat das Gerät gefährliche Geräteeigenschaften eingestellt?
  • Ist die busybox-Binärdatei auf dem Gerät installiert?
  • Ist die su-Binärdatei auf dem Gerät installiert?
  • Ist die Systempartition mit Lese- und Schreibzugriff gemountet und nicht schreibgeschützt?

Einige Anwendungen versuchen sogar den aktuellen SELinux-Modus zu ermitteln, in dem das Gerät läuft, aber ohne spezielle Berechtigungen, auf die nur Systemanwendungen Zugriff haben, ist dies in modernen Android-Versionen nicht möglich.

Wie gehen Applikationen mit Root-Erkennung um?

Wenn eine Applikation feststellt, dass das Gerät, auf dem sie läuft, kompromittiert ist, gibt es verschiedene Möglichkeiten, wie Apps darauf reagieren können:

  1. Warnung des Benutzers: Einige Apps warnen den Benutzer, dass sie auf einem gerooteten Gerät ausgeführt werden, und informieren ihn über die potenziellen Risiken. Diese Warnung kann vom Nutzer bestätigt werden, doch die App bleibt weiterhin nutzbar.
  2. Funktionalitäten einschränken: Einige Apps können bestimmte Funktionen einschränken, wenn sie feststellen, dass das Gerät gerootet ist. So kann beispielsweise eine Banking-App Transaktionen auf einem gerooteten Gerät verbieten.
  3. Zugriff verweigern: In extremeren Fällen kann sich eine Anwendung ganz weigern, auf einem gerooteten Gerät zu laufen. Dies ist häufig bei Anwendungen der Fall, die mit hoch-sensiblen Daten oder Transaktionen zu tun haben, z. B. Banking- oder Finanz-Apps, bestimmte Spiele, um Betrug zu verhindern, oder Streaming-Dienste, um Raubkopien zu vermeiden.

Proof of Concept: Erkennen moderne Root Detection Bibliotheken bösartiges Root?

Um zu prüfen, ob Anwendungen mit Root-Erkennungsmechanismen auch bösartige Root-Exploits zur Laufzeit erkennen, mussten wir zunächst mögliche Exploit-Kandidaten identifizieren, für die ein öffentlicher Proof-of-Concept (PoC) existiert.

Bei der Recherche stellten sich die Schwachstellen mit den Kennungen CVE-2019-2215 und CVE-2020-0847 als die am besten dokumentierten heraus. Für beide Schwachstellen gibt es bereits einen PoC, der es uns ermöglicht, die Kernel-Schwachstelle auszunutzen und zur Laufzeit eine Kommandozeile mit Root-Rechten zu erstellen.

Screenshot eines erfolgreichen Root-Exploits, der von der RootBeer Sample App nicht erkannt wird.
Abbildung 1: Screenshot eines erfolgreichen Root-Exploits, der von der RootBeer Sample App nicht erkannt wird.
Screenshot eines erfolgreichen Root-Exploits, der von der SU-Checker App nicht erkannt wird.
Abbildung 2: Screenshot eines erfolgreichen Root-Exploits, der von der SU-Checker App nicht erkannt wird.

Bad Binder Exploit - CVE-2019-2215

Diese Sicherheitslücke wurde von der Sicherheitsforscherin Maddy Stone bereits sehr gut dokumentiert.

Sie ermöglicht es einer installierten bösartigen Anwendung, Root-Rechte auf einem Android-Gerät zu erlangen, indem sie eine Schwachstelle im Binder-Treiber ausnutzt.

Um diese Schwachstelle auszunutzen und zu prüfen, ob die Root-Erkennungsbibliotheken diesen bösartigen Root-Zugriff erkennen würden, mussten wir zunächst ein Gerät mit einer anfälligen Kernel-Version einrichten. Dazu kompilierten wir unseren eigenen Kernel für Android 10 und führten die Schwachstelle wieder ein, indem wir den Commit mit der Schwachstellenbehebung rückgängig machten. Danach erstellten wir ein virtuelles Android-Gerät (AVD) und starteten es mit unserem neu kompilierten Kernel. Anschließend verwendeten wir den verfügbaren PoC-Root-Exploit, um eine Root-Shell über die Android Debugging Bridge (ADB) zu starten. In diesem Szenario haben wir ADB anstelle einer bösartigen Anwendung verwendet, um den Exploit auszulösen, da der ADB-Prozess nicht mit SECCOMP gesichert ist, was eine weitere Hürde wäre, die es zu umgehen gilt, um das Zielgerät erfolgreich auszunutzen. Das Ergebnis der Root-Erkennungsbibliotheken wird dadurch jedoch in keiner Weise beeinträchtigt. Nachdem wir Root-Zugriff auf das Gerät erhalten hatten, versuchten wir, auf das private Verzeichnis der installierten Anwendungen zuzugreifen. Wie erwartet war es möglich, alle privat gespeicherten Dateien der Anwendungen zu lesen.

Als nächstes haben wir eine Reihe von Anwendungen mit Root-Erkennungsmechanismen installiert, um zu sehen, ob sie das Vorhandensein des Root-Exploits erkennen können. Unter anderem haben wir die folgenden Anwendungen getestet, von denen wir wissen, dass sie irgendeine Form von Root-Erkennungsmechanismen implementieren:

  • Barclays Privatkunden
  • Snapchat
  • Instagram
  • RootBeer Beispiel APK
  • SuChecker

Wir haben festgestellt, dass keine der getesteten Anwendungen in der Lage war, die Kompromittierung des Geräts zu erkennen. Die folgenden Screenshots zeigen die RootBeer-Beispiel-App und die SuChecker-App, die viele Root-Prüfungen durchführen, aber das gerootete System nicht erkennen, während die Befehlszeile einen erfolgreichen Root-Exploit mit auf "permissive" gesetztem SELinux zeigt.

Busybox-Binärdateien können vor Root-Erkennungsbibliotheken versteckt werden.
Abbildung 3: Busybox-Binärdateien können vor Root-Erkennungsbibliotheken versteckt werden.

Um jedoch auf der sicheren Seite zu sein und unsere Vermutung zu überprüfen, haben wir auch einen zweiten Root-Exploit auf einem physischen Android-Gerät getestet.

Dirty Pipe Exploit - CVE-2020-0847

Die auch als "Dirty Pipe" bekannte Schwachstelle wurde von Max Kellerman entdeckt und ermöglicht das Überschreiben aller lesbaren Dateien auf dem System. Dies kann missbraucht werden, um Systembibliotheken zu überschreiben und die Ausführung von Code mit erhöhten Privilegien zu erreichen. Es sind weitere Schritte erforderlich, um SELinux-Beschränkungen zu umgehen, die jedoch den Rahmen dieses Blogbeitrags sprengen würden.

Dieses Mal haben wir ein physisches Google Pixel 6-Gerät verwendet, auf dem Android 12 mit dem Sicherheitspatch-Level vom Februar 2020 läuft. Auch hier haben wir den bestehenden PoC-Exploit verwendet, um eine Root-Shell auf dem Gerät zu erhalten. Um zu überprüfen, ob wir tatsächlich Root-Berechtigungen erhalten haben, haben wir versucht, Dateien aus dem privaten App-Verzeichnis zu lesen. Anschließend haben wir erneut die Anwendungen mit Root-Erkennungsmechanismen auf dem Gerät installiert, um zu prüfen, ob sie das kompromittierte Betriebssystem erkennen.

Selbst auf dem physischen Gerät mit einem anderen Exploit erkannten die Anwendungen das kompromittierte System nicht. Obwohl der Exploit die "busybox"-Binärdatei auf das Gerät kopiert, wird sie von den Root-Erkennungsbibliotheken nicht erkannt, da die Binärdatei an einem nicht standardmäßigen Speicherort abgelegt ist, auf den installierte Anwendungen keinen Zugriff haben.

Das folgende Bild zeigt, dass die Root-Erkennungsbibliothek RootBeer nach der Binärdatei sucht, sie aber nicht finden konnte:

Was lässt sich daraus schließen?

Wir haben die von diesen Anwendungen implementierten Root-Erkennungsmechanismen analysiert, um herauszufinden, warum sie den Root-Exploit nicht effektiv erkennen. Wir haben festgestellt, dass die meisten dieser Mechanismen an bestimmten Stellen nach Root-Artefakten suchen, die nur in den "Benutzer-Root"-Einstellungen vorhanden sind. Böswillige Exploits versuchen jedoch, ihre Spuren zu verwischen, und da sie vollständigen Zugriff auf das Gerät haben, können sie jede Eigenschaft, nach der die Root-Erkennungsbibliotheken suchen, einfach ausblenden/ändern. Sobald eine bösartige Anwendung Root-Zugriff erhalten hat, kann sie ohne Einschränkungen alles auf dem Gerät tun.

Das bedeutet, dass Root-Erkennungsmechanismen in den meisten Fällen nur "kompromittierte" Geräte erkennen, bei denen sich die Benutzer der Tatsache bewusst sind, dass ihre Geräte gerootet sind, und wahrscheinlich auch über die Sicherheitsfolgen Bescheid wissen. Die eigentliche Bedrohung geht jedoch von böswilligem Root-Zugriff aus, der durch Ausnutzung bekannter oder unbekannter Schwachstellen erlangt wird. In solchen Fällen ist sich der Benutzer nicht bewusst, dass sein Gerät kompromittiert ist, und weiß daher nicht, welche Folgen die Verwendung von Anwendungen mit sensiblen Daten auf diesem Gerät hat.

Schlussfolgerung – Root-Erkennung - Allheilmittel gegen Angriffe?

Die Root-Erkennung kann eine hilfreiche Maßnahme sein, um sicherzustellen, dass die Benutzer von Unternehmensanwendungen die Sicherheitsmaßnahmen der App nicht umgehen können und dass vertrauliche Daten nicht von bösartigen Apps abgerufen werden können. Eine böswillige Kompromittierung des Geräts kann damit jedoch nicht erkannt werden. Insgesamt sollte die Root-Erkennung nicht als Allheilmittel betrachtet werden. Hier sind Gründe dafür:

Falsches Sicherheitsempfinden: Es ist wichtig, dass man sich durch die Implementierung einer Root-Erkennung nicht in einem falschen Sicherheitsgefühl wiegt. Ein Unternehmen oder ein Benutzer könnte fälschlicherweise glauben, dass man vor bösartigen Bedrohungen geschützt ist, was nicht immer der Fall ist. Darüber hinaus können Schutzmaßnahmen wie Data Loss Prevention (DLP), die Aktionen wie Kopieren und Einfügen oder das Anfertigen von Screenshots verhindern, durch ein zentralisiertes Mobile Device Management (MDM)-System und gut definierte Richtlinien besser durchgesetzt werden. Ein MDM kann die Integrität des Betriebssystems kontinuierlich überwachen, während eine Anwendung die Integrität nur während der Ausführung überprüfen kann. Wenn die Root-Erkennung nur in einzelne Anwendungen eingebettet ist, kann die Anwendung zwar die Ausführung auf einem Gerät mit Root-Funktion verweigern, verhindert aber nicht von vornherein, dass ein Root-Benutzer oder Angreifer auf die gespeicherten Daten zugreift.

Wirksamkeit und Anwendungsfälle: Benutzer, die ihre Geräte rooten, streben oft nach voller Kontrolle. Aufgrund ihrer erhöhten Privilegien kann ein entschlossener Benutzer in der Regel die meisten Mechanismen zur Erkennung von Root-Anwendungen umgehen. Daher ist es bei Anwendungen, die nicht für Unternehmen bestimmt sind, möglicherweise besser, die Benutzer vor den potenziellen Sicherheitsrisiken zu warnen, die mit der Verwendung der Anwendung auf einem gerooteten Gerät verbunden sind. Dies hilft ihnen, fundierte Entscheidungen zu treffen. In Unternehmensumgebungen, in denen die Geräte- und Datenkontrolle von entscheidender Bedeutung ist, kann die Root-Erkennung in bestimmten Anwendungsfällen von Vorteil sein. In den meisten Anwendungsfällen kann jedoch eine höhere Sicherheit durch Sicherheitsfunktionen wie hardwaregestützte Verschlüsselung (z. B. Android Keystore) und erweiterte Authentifizierung (z. B. biometrische Verfahren) erreicht werden.

Kosten und Ressourcenzuweisung: Die Implementierung der Root-Erkennung ist nicht kostenlos; sie erfordert Zeit, Geld und technische Ressourcen für die Entwicklung und strenge Tests. Bei Anwendungen für Verbraucher kann es vorteilhafter sein, diese Ressourcen in eine robuste Sicherheitsarchitektur und regelmäßige Penetrationstests ("Pentests") zu investieren. Mobile Security Pentests bewerten die Sicherheit einer Anwendung und liefern die notwendigen Anhaltspunkte, um die Anwendung so sicher wie möglich zu machen, selbst bei einer möglichen Kompromittierung.

Zusammengefasst:

  • Für Endbenutzeranwendungen raten wir nicht zur Root-Erkennung, sondern zur Konzentration auf andere Sicherheitsmechanismen und regelmäßige Sicherheitsüberprüfungen.
  • Bei Unternehmensanwendungen sollte die Root-Erkennung nicht der wichtigste Sicherheitsmechanismus sein, sondern kann eine sinnvolle zusätzliche Sicherheitsmaßnahme darstellen. Es wäre jedoch effektiver, dies über eine Mobile Device Management (MDM)-Lösung zu implementieren.
  • In jedem Fall wäre es ratsamer, die Sicherheitsarchitektur der Anwendung so zu verbessern, dass die Daten auch bei Verwendung auf einem kompromittierten Gerät geschützt werden können.

 

 

Dieser Blog Post wurde von Fabian Densborn und Hussam Cheaib im Auftrag des SEC Consult Vulnerability Labs verfasst.

Interessieren Sie sich für eine Karriere bei SEC Consult?

SEC Consult ist immer auf der Suche nach talentierten Sicherheitsexpert:innen, die unser Team verstärken möchten.