23 Punkte von xguru 2024-11-06 | 1 Kommentare | Auf WhatsApp teilen
  • Vor Kurzem konnte mithilfe einer JSON-Injection-Schwachstelle auf Samsung-Geräten eine Angriffskette ausgelöst werden, die bis zur Ausführung von Code auf dem Gerät führte
  • Das kann als Lehrstück dafür dienen, wie sich APIs missbrauchen lassen, die dem JSON eines Payloads blind vertrauen

Alles „smart“ injizieren

  • Beim Samsung Smart Hub konnte eine mobile App aus der Ferne mit dem Hub kommunizieren und alles Angeschlossene steuern
  • Durch das Senden einer bösartigen POST-Anfrage an den Endpunkt /credentials konnten die Anmeldedaten verändert werden, die der Hub für die Verbindung zu einem Remote-Server nutzt, und Daten manipuliert werden, was zu SQL-Injection führen konnte
  • Die von Samsung verwendete Bibliothek json-c war mit JSON_TOKENER_STRICT=0 kompiliert, wodurch Strings mit einfachen und doppelten Anführungszeichen definiert werden konnten
  • Dadurch konnten Angreifer benutzerdefinierte Spalten in der internen sqlite-Datenbank des Hubs anlegen
  • Durch das Einfügen einer übermäßig langen ROP-Kette in die Tabelle camera und anschließendes Senden von DELETE an den Endpunkt /cameras konnte der video-core-Prozess beim Versuch, die Daten zu lesen, zum Absturz gebracht werden, was zu einem klassischen stackbasierten Buffer Overflow führte
  • Die Lehre daraus: JSON-Injection → SQL-Injection → Buffer Overflow → ROP = vollständige Übernahme

Was ist JSON-Injection?

  • JSON-Injection ist eine Schwachstelle, bei der bösartige Daten in einen JSON-Stream eingefügt werden, um das Verhalten einer Anwendung zu verändern oder unbeabsichtigte Aktionen auszulösen
  • Serverseitige JSON-Injection tritt auf, wenn Daten aus nicht vertrauenswürdigen Quellen auf dem Server nicht korrekt bereinigt und direkt oder indirekt im Code verwendet werden

Das Problem liegt im Parser

  • In modernen Webanwendungen und APIs können innerhalb der Request-Pipeline mehrere Parser mit jeweils eigenen Eigenschaften und Schwachstellen eingesetzt werden
  • Die Kombination aus Inkonsistenzen zwischen Parsern und mehrstufiger Request-Verarbeitung kann zu schwerwiegenden Schwachstellen führen
  • JSON-Parser stehen vor Herausforderungen, weil der offizielle JSON-RFC Themen wie doppelte Schlüssel und Zahlenrepräsentationen bewusst offenlässt
  • Der offizielle RFC ist nicht die einzige Spezifikation; es gibt auch ECMAScript, JSON5, HJSON und Binary JSON(BSON)
  • Die Interoperabilität zwischen Parsern legt Sicherheitsrisiken offen, deren Existenz vielen nicht einmal bewusst ist

Sicherheitsprobleme bei der Interoperabilität von JSON-Parsern

  • Uneinheitliche Behandlung doppelter Schlüssel
  • Uneinheitliche Behandlung von Sonderzeichen oder Kommentaren
  • Inkonsistenzen bei der JSON-(De-)Serialisierung

Wie lässt sich JSON missbrauchen?

  • Durch Manipulation von JSON lassen sich Daten so einschleusen, dass die Anwendung auf eine Weise arbeitet, die Entwickler nicht erwartet haben
  • Wenn sich manipulieren lässt, wie Daten innerhalb der API-Infrastruktur durch Komponenten fließen, entstehen Möglichkeiten, die Business-Logik zu steuern
  • Wer versteht, wie Parser Eingaben verarbeiten, kann ihr Verhalten ausnutzen, damit Eingaben auf manipulierbare Weise interpretiert werden und so die Eingabevalidierung umgehen

Fazit

  • Der Angriff auf den Samsung Smart Hub ist nur ein Beispiel dafür, dass JSON-Injection zu komplexen Schwachstellenketten führen kann, von SQL-Injection bis hin zu Remote Code Execution
  • Die eigentliche Ursache liegt oft in Inkonsistenzen bei der Datenverarbeitung durch JSON-Parser, besonders wenn mehrere ungewöhnliche Parser beteiligt sind
  • Durch gründliche Prüfung, wie JSON-Objekte serialisiert, deserialisiert und verarbeitet werden, lässt sich herausfinden, wie Payloads erstellt werden können, die Sanitizing-Filter umgehen und die Business-Logik beeinflussen
  • Da APIs weiterhin ein Grundpfeiler moderner Anwendungen sind, ist es wichtiger denn je, die Sicherheit ihrer Datenverarbeitung zu gewährleisten

1 Kommentare

 
yangeok 2024-11-08

Dann sollte man die per JSON-Body empfangenen Daten wohl ziemlich streng validieren.