Suche nach Schwachstellen in IoT-Geräten am Beispiel CVE-2022-46527 (Teil 2)

Dieser Artikel ist der zweite Teil der Fallstudie zu CVE-2022-46527 und schildert die Entdeckung der Schwachstelle sowie einen Proof of Concept, der zu einem Absturz führt. Die Vorstellung der Hardware befindet sich im ersten Teil.

Da die Details der Schwachstelle inzwischen nicht mehr unter Verschluss stehen, dürfen wir angeben, dass es sich bei dem betroffenen Gerät um ein ELSYS ERS Sound mit der Firmware-Version 2.3.8 handelt.

Bestimmung des Codes zur Verarbeitung der NFC-Daten

Im ersten Teil des Artikels wurde erläutert, dass die Geräte über Nachrichten konfiguriert werden, die auf dem NFC-Chip gespeichert sind. Durch die Erfassung der ausgetauschten Daten haben wir Beispiele für die in der Konfiguration verwendeten Wörter ermittelt, die nützlich sein werden, um den für die Verarbeitung zuständigen Teil der Firmware zu lokalisieren.
 

Abbildung 1: Auszug aus einer Ndef-Nachricht

Erkennung von Risikofunktionen

Dank der Verwendung von Schlüsselwörtern wurde mit Ghidra die Funktion gefunden, mit der die auf dem NFC-Chip gespeicherten Daten analysiert werden können.

Abbildung 2: Überblick über die Datenanalysefunktion des NFC-Chips

In dieser Analysefunktion fällt auf, dass in den Argumenten, die an eine Funktion mit den drei folgenden Parametern gesendet wird, das Schlüsselwort „lock“ verwendet wird:

• Schlüsselwort
• Chipdaten
• Größe des zu extrahierenden Wertes

Mit dieser Funktion lässt sich der Wert extrahieren, der einem Schlüsselwort zugewiesen ist.
 

Abbildung 3: Überblick über die Funktion zur Extraktion des einem Schlüsselwort zugewiesenen Werts

Analyse der Problemursache

In diesem Fall soll die Kopierfunktion „strncpy“ kein Problem mit einem Pufferüberlauf verursachen. Diese Funktion nimmt als Parameter die maximale Größe, die kopiert werden soll, damit der Pufferspeicher nicht überschritten wird.
Allerdings ist in unserem Fall die maximale Größe die Wertgröße, die dem Schlüssel zugeordnet ist und vom Nutzer kontrolliert wird. Dieser kann die Größe des Pufferspeichers übersteigen.

Auslösung des Absturzes

Da der Pufferspeicher auf dem Stack liegt, handelt es sich bei der Schwachstelle um einen „stack-based buffer overflow“.

Die Größe des Pufferspeichers beträgt 36 Zeichen. Um die Rücksprungadresse neu zu schreiben, benötigen wir eine Payload von mindestens 36 Zeichen. Hierzu wird die Größe der Variablen addiert, die mit dem Puffer gespeichert werden, bis das erneute Schreiben der Rücksprungadresse der Funktion erreicht wird. In unserem Fall reichen 52 Zeichen für einen Absturz der Hardware.

Durch das erneute Schreiben der Rücksprungadresse erhält man die Kontrolle über den Ablauf der Ausführung von Anweisungen an den MCU.
 

Abbildung 4: Beispiel für den Effekt eines Stack-Pufferüberlaufs

Wenn die folgende Konfiguration auf den NFC-Chip geladen wird, stürzt das Gerät ab und startet für unbestimmte Zeit neu. „lock: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA“
Wenn die LED weiß blinkt, ist dies kein normales Verhalten des Geräts. Eine rot leuchtende LED zeigt an, dass das Gerät gestartet wurde.

Abbildung 5: Absturz des Geräts nach dem Laden der Payload

Ein PoC ist auf unserem GitHub verfügbar.

Korrekturvorschlag

Bei der Schwachstelle handelt es sich um einen Speicherüberlauf, der durch eine verbesserte Handhabung der Zeichenkettengröße behoben werden kann.
Eine mögliche Lösung zur Behebung des Problems ist die Änderung des Teils des Codes sein, der für die Berechnung der Größe verantwortlich ist. Da die Funktion die maximale Größe als Parameter nimmt, kann dieser Parameter von der Funktion „strncpy“ wiederverwendet werden. So wird die maximale Größe vom Entwickler statt vom Nutzer kontrolliert.

Schlussfolgerung

Der Verkäufer wurde über dieses Problem mit seiner Hardware benachrichtigt und hat den Erhalt der Benachrichtigung bestätigt. Zum Zeitpunkt der Erstellung dieses Artikels lagen uns jedoch noch keine Informationen des Verkäufers über eine neue Version vor, die dieses Problem behebt. Inzwischen ist eine neue Firmware-Version erschienen.

Der PoC löst nur einen Absturz aus. In der vorgegebenen Zeit des für unseren Mandanten durchgeführten Auftrags war eine echte Nutzung nicht möglich. Um die Nutzung zu ermöglichen, ist noch einiges zu tun, zumal der Debug-Modus der MCU nicht verfügbar ist. Unter der Annahme, dass die Bedingungen hierfür gegeben sind, lässt sich diese Schwachstelle tatsächlich nutzen, um die vertraulichen Verbindungsdaten für die Anmeldung am LoraWAN-Netzwerk zu extrahieren, indem man sich als das Gerät ausgibt.