NOTE: Nach weiterem Austausch mit dem Anbieter stellte sich heraus, dass es sich bei der Schwachstelle nicht um eine BO-Schwachstelle handelt, sondern um ein mangelndes Exception-Handling-Design. Der Artikel bleibt allerdings so wie erst ist, da die Ergebnisse, Risiken und Auswirkungen immer noch dieselben sind und einer Buffer Overflow Schwachstelle, die nicht zu RCE führt, ziemlich ähnlich wären.
Hacken ist für mich mit Gaming vergleichbar. Man stellt sich bestimmten Herausforderungen wie z.B. einem Endboss oder einem Rätsel, das es zu lösen gilt. Wenn die offensichtlichsten Herangehensweisen nicht auf Anhieb funktionieren, muss man neue Strategien entwickeln und Dinge ausprobieren, um das Ziel zu erreichen. Je schwieriger der Endgegner, desto größer ist die Zufriedenheit und Genugtuung nach einem errungenen Sieg.
Beim Hacken ist es ähnlich: Man überprüft ein meist unbekanntes System (den Endgegner) auf Sicherheitslücken (die Schwächen). Durch viel Recherche (studieren der Angriffsmuster) und Trial & Error findet man Schwachstellen und lernt diese auszunutzen.
Mit jeder gefundenen Schwachstelle lässt sich das System leichter kompromittieren und schlussendlich (hoffentlich) unter Kontrolle bringen.
Aufgrund von Zeit- und Kostengründen testet man Systeme zuerst auf bereits bekannte Schwachstellen, weil diese dokumentiert sind und auch oft Exploits dafür verfügbar sind. Wenn man anschließend Schwachstellen findet, welche ausnutzbar sind, ist das schon sehr befriedigend aus Sicht eines Pentesters. Wenn man aber undokumentierte Sicherheitslücken (als erstes?) aufdeckt ist das noch einmal ein ganz anderes Gefühl…
Die Ausgangssituation
Einer unserer Kunden beauftragte uns mit dem Angriff auf mobilen Geräten aus der Sicht von Hackern. Ziel war es die Geräte derart zu kompromittieren, sodass an die darauf gespeicherten sensiblen Unternehmensdaten zugegriffen werden kann.
Bei den Geräten handelte es sich um ein Tablet und ein Handy mit installiertem MDM-Agent sowie einer Kiosk Applikation (Details im nächsten Abschnitt). Der Zweck dieser Geräte ist den Nutzern nur eine Handvoll Apps zur Verfügung zu stellen, die während der täglichen Arbeit benutzt werden. Nutzer sollen keine Systemeinstellungen vornehmen oder zusätzliche Apps installieren können.
Falls euch die bisher genannten Begrifflichkeiten bekannt sind und ihr mit Buffer Overflows vertraut seid, könnt ihr direkt zum „Proof-of-Concept“ Abschnitt weiter unten springen.
Was ist ein MDM-Agent?
Unter einem MDM-Agent (Mobile Device Management) versteht man eine Softwareanwendung, die in der mobilen Geräteverwaltung verwendet wird. Diese Agents werden häufig auf Mobilgeräten wie Smartphones und Tablets installiert, um die Verwaltung, Überwachung, Sicherheit und Konfiguration dieser Geräte durch eine zentrale Verwaltungsplattform zu ermöglichen.
Die Verwendung von MDM-Agenten ist besonders in Unternehmen, Bildungseinrichtungen und anderen Organisationen weit verbreitet, um die Verwaltung und Sicherheit der auf den Geräten gespeicherten Daten zu gewährleisten und die Produktivität der Benutzer zu erhöhen.
Was ist eine Kiosk Applikation?
Eine Kiosk Applikation auf mobilen Geräten wie z.B. Tablets ist eine Anwendung, die dazu dient, das Gerät in einen interaktiven und kontrollierten Informations- oder Präsentationspunkt zu verwandeln.
Beispiele für die Verwendung von Kiosk Apps umfassen interaktive Informationsterminals, POS-Systeme (Point-of-Sale), digitale Speisekarten, digitale Beschilderungen oder auch Kindersicherungs-Apps, die den Zugriff auf bestimmte Apps und Inhalte für Kinder einschränken.
Was sind Buffer Overflows?
Ein Buffer Overflow ist wie ein überfüllter Eimer. Stell dir vor, du hast einen Eimer, der nur eine bestimmte Menge Wasser aufnehmen kann. Wenn du mehr Wasser hineinschüttest, als der Eimer fassen kann, läuft das Wasser über und es passieren ungewollte Dinge wie z.B. Beschädigungen an elektronischen Geräten, die in der Nähe sind.
In der Computerwelt ist ein Buffer Overflow ähnlich. Wenn ein Computerprogramm Daten in einen Speicherbereich (den „Eimer“) steckt, kann es passieren, dass es dort mehr Daten speichert, als dieser Platz hat. Dadurch könnten diese zusätzlichen Daten andere Dinge im Computer durcheinanderbringen oder beschädigen, weil sie über den ihnen zugewiesenen Bereich gespeichert werden.
Das ist ein Problem, weil Personen mit entsprechendem Know-How dies ausnutzen können, um ungewollte Dinge zu tun, indem sie absichtlich zu viele Daten in einen Speicherbereich schieben. Die Auswirkungen einer solchen Attacke sind vielfältig. Meist stürzt ein Programm einfach nur ab, im Schlimmsten Fall aber kommt es zur Codeausführung (RCE), was eine Kompromittierung des Systems zur Folge hat.
Proof-of-Concept
Der folgende Proof-of-Concept beschreibt das Auffinden der Sicherheitslücke im „Baramundi EMM Agent“ und sowie das Ausnutzen dieser. Mögliche Auswirkungen und Risiken werden im Anschluss behandelt. Der Einfachheit halber werden hier nur Bildmaterial auf einem der beiden Geräte gezeigt (am Handy). Alle durchgeführten Versuche ließen sich jedoch auf dieselbe oder sehr ähnliche Weise auch auf dem Tablet durchführen.
Im ersten Schritt gilt es herauszufinden, was ein Nutzer alles mit dem Gerät machen kann bzw. welche Berechtigungen er hat.
Naheliegend ist es zuerst die verfügbaren Apps zu öffnen, um zu überprüfen, was sie erlauben. Die Kiosk-App unterbindet den Zugriff auf die meisten Apps bereits.
In der Baramundi App (baramundi EMM Agent) kann man direkt auf die Log-Einträge zugreifen. Die Informationen in diesem Log sind teils sehr aufschlussreich und beinhalten u.a. die Tastenkombination zur Passworteingabe zum Aktivieren des Administrator-Modes. Dass die Baramundi App vom Kunden in der Kiosk App freigegeben wurde, hat sich später als Konfigurationsfehler herausgestellt und wurde umgehend behoben.
Weitere nützliche Informationen, die das Log beinhaltet, sind unter anderem der Passwort-Hash zum Aktivieren des Administrator-Modes und die Adresse des Servers, von dem aus das Gerät verwaltet wird.
Die oben erwähnte Tastenkombination ist wichtig zu kennen, da sie die Tür zu nahezu allen Einstellungen am Gerät öffnet. Wenn also das Passwort für den Admin-Prompt bekannt ist, erhält man Administrator-Rechte.
In unserem Fall handelte es sich um ein komplexes Passwort, das nicht leicht erraten werden konnte. Auch wegen des inkrementell steigenden Timeouts stellte sich das Ausprobieren vieler einfacher Passwörter als nicht effizient heraus.
Wenn man ein wenig Programmiererfahrung hat, weiß man, dass alle Werte in Variablen gespeichert werden. Diesen Variablen werden oft bestimmte Speichergrößen zugeordnet, was heißt, dass nicht beliebig viele Zeichen in einer Variable gespeichert werden dürfen. Wenn z.B. die Variable „Name“ nicht mehr als 30 Zeichen enthalten darf, dann sollte das Front- und Backend-seitig unterbunden werden. Falls es diesbezüglich keine Maßnahmen gibt, passieren oft unerwartete Dinge in einer App (siehe Abschnitt „Buffer Overflows“).
Zurück zu unserem Beispiel. Meine Annahme war die folgende: Da die Passwort-Eingabe für Admin-Rechte „versteckt“ ist und nur in seltenen Fällen benutzt wird, ist davon auszugehen, dass beim Programmieren diesem Teil des Codes nicht die gleiche Aufmerksamkeit geschenkt wurde wie dem Rest. Bugs werden schließlich auch bei eher häufig verwendeten Programmfunktionen entdeckt und gemeldet.
Nach einigem Herumprobieren wurde klar, dass ein Passwort von mehr als 71 Zeichen zum Absturz der Kiosk- und der Baramundi-App führt. Wenn man mit dem richtigen Timing das Menü von oben herunterzieht, sind plötzlich Einstellungen verfügbar, die vorher unzugänglich waren. Die Baramundi-App startet unverzüglich wieder – die Kiosk-App jedoch bleibt geschlossen, solange man nicht wieder ins Hauptmenü navigiert.
Die folgende Aufzeichnung zeigt, dass zu Beginn keine Einstellungen beim Swipen nach unten zu sehen sind. Nach Eingabe eines langen Passworts (von mehr als 71 Zeichen) lassen sich die Quick-Menü-Items aufrufen. Auch das Baramundi-Warnungsfenster poppt kurz auf, das hindert einem aber nicht am Zugriff auf die Einstellungen.
Das richtige Timing ließ sich am besten durch Betätigen der Geräte-Tasten erreichen. Als erfolgversprechendste Methode hat sich die „Geöffnete Apps“-Taste herausgestellt, welche eine Liste aller geöffneten Apps anzeigt. Wird sie im richtigen Moment (mehrmals) gedrückt, verbleibt das Gerät in der aktuellen Ansicht und man kann in Ruhe andere Menüpunkte und Apps aufrufen, ohne dabei in den „restriktiveren“ Zustand zurückzufallen.
Es ist sehr wahrscheinlich, dass bei Eingabe eines zu langen Passwortes (>71 Zeichen) der Buffer mit den 72., 73., 74., etc. überschrieben wird und in einem nicht zugewiesenen Speicherbereich landet (siehe Abschnitt „Was sind Buffer Overflows?“). Das führt zum Crash des Baramundi-Agents, welcher sich kurz darauf aber sofort wieder startet – wenn auch nicht vollständig. Denn immerhin sind einige der zuvor gesperrten Einstellungen nach dem Crash verfügbar.
Auswirkungen und Risiken
Das Ausnutzen der Schwachstelle wurde an zwei Geräten getestet mit jeweils unterschiedlichen Baramundi EMM Agent Versionen (in Klammer):
- Lenovo TB-X606X (v22.2.190)
- Samsung Xcover 4s (v23.1.50)
Die potenziellen Auswirkungen sind vielfältig. So konnte zum Beispiel Bluetooth oder NFC aktiviert werden oder auch Android’s Nearby Share um Dateien zu senden bzw. zu empfangen. Auch kann Android „Smart View“ zum Spiegeln des Displays verwendet oder die Shortcut-Menüs (Android nennt sie „Paneele“) angepasst werden.
Über den Google Play Store, welcher über die Panels hinzugefügt und geöffnet werden kann, ist es z.B. möglich Apps zu installieren oder das vorinstallierte Heißluftballon Game zu spielen (sofern keine Netzwerkverbindung besteht). Die nachträglich installierten Apps lassen sich jedoch nur ausführen, wenn auch der Baramundi Agent die jeweiligen Apps zulässt und ist somit von der jeweiligen angewandten Policy abhängig.
Ziemlich praktisch war auch die Tatsache, dass sich Microsoft Teams installieren ließ. Dies war jedoch auch nur möglich, weil die App vom Administrator freigegeben wurde und hat per se nichts mit der Schwachstelle zu tun. Mithilfe von Teams konnte ich somit die Screenshots zum Erstellen der Dokumentation direkt am Gerät anfertigen.
Selbst wenn die genannten Risiken im ersten Moment nicht sehr kritisch zu sein scheinen, führt der Absturz des Baramundi EMM Agents doch zu einer gewissen Rechteausweitung (Privilege Escalation).
Auch der Reset des Timers für die Passworteingabe bestätigt, dass der Agent nach dem Absturz neu initialisiert wird, was auch ein Erraten des Passworts erheblich erleichtert.
Da es sich bei den getesteten Geräten um Kundeneigentum handelt und auch die Zeit für das Assessment limitiert war, haben wir entschieden unsere Untersuchungen mit dem bisherigen Kenntnisstand dem Hersteller zu übermitteln.
Der CVSS-Score v4.0 für diese Schwachstelle beträgt 5,2 (Medium):
Die dazugehörige CVE-Nummer ist CVE-2023-37605. Der dazugehörige CVE-Eintrag in der Datenbank ist bereits veröffentlicht worden.
Weitere potenzielle Schwachstellen?
Bei einer weiteren potenziellen Schwachstelle (Race Condition) war zum Zeitpunkt der Erstellung dieses Artikels noch nicht klar, ob es sich tatsächlich um eine Sicherheitslücke bzw. mangelnde Konfigurationseinstellungen handelt oder die Ergebnisse Geräte-spezifisch sind und auf anderer Hardware nicht auftreten.
Die möglichen Auswirkungen könnten sein, dass auf zusätzliche Einstellungen direkt aus dem Einstellungen-Menü zugegriffen und Änderungen vorgenommen werden können. Der Unterschied zur vorherigen Schwachstelle ist, dass nicht nur auf die Quick-Menü-Einstellungen zugegriffen werden kann.
Aktuell untersucht Baramundi das Verhalten noch. Sobald die Ursache des Problems gefunden wurde und ein Fix bereitgestellt wird, aktualisiere ich den Artikel entsprechend.
Credits
Für uns mindsetters war dieses Assessment wieder mal der Beweis dafür wie wichtig Pentests sind. Man kann sich nicht immer auf gut gepatchte Softwareprodukte verlassen – deren Entwickler oft wirklich gute Arbeit leisten. Programmierer unterstehen demselben Leistungsdruck wie wir alle und genau wie in einer nicht-digitalen Arbeit können kleine Fehler große Auswirkungen haben. Fehler werden immer passieren, daran werden auch künstliche Intelligenzen und Blockchains nichts ändern. Deshalb: Selbst wenn man ein gut funktionierendes Patchmanagement im eigenen Unternehmen vorfindet, sollte man Business-kritische Applikationen immer „von Hand“ überprüfen (lassen).
Abschließend möchte ich mich bei Baramundi für die hervorragende und unkomplizierte Kommunikation bedanken. Selten sind Software-Hersteller derart responsive und stellen einen Fix für die Schwachstelle nach gerade einmal 4 Tagen zur Verfügung. Die behobene Version ist die Version EMM Agent v23.1.171.
Zusätzlich möchte ich mich auch bei unseren Auftraggebern bedanken. Ohne das Vertrauen und die super Zusammenarbeit wäre eine solche Arbeit nicht möglich gewesen.
Falls auch du deine verwendeten Produkte einem „Stresstest“ unterziehen möchtest, vereinbare gerne ein kostenloses Erstgespräch mit uns mindsetters.
Timeline und Kommunikation
- 14.08.2023 – Erster Kontakt zu Baramundi (E-Mail)
- 21.08.2023 – Baramundi bestätigt die Schwachstelle
- 25.08.2023 – Baramundi veröffentlicht Fix für Buffer Overflow Schwachstelle (EMM Agent v23.1.171)
- 25.08.2023 – Weitere Schwachstelle eingemeldet (Racing Condition)
- 01.09.2023 – Baramundi validiert Legitimität der RC-Schwachstelle
- F.f.
