Skip to content

Die IoT Top 10, #1: Unsichere Weboberflächen, Teil 2

Es geht weiter mit der Beschreibung der gefährlichsten Schwachstellen in den Geräten des IoT. Auf der Liste der Top IoT Vulnerabilities von OWASP steht auf Platz 1 das "Insecure Web Interface". Die ersten dort aufgeführten Schwachstellen werden auf der Liste der OWASP Top 10 der Webschwachstellen unter dem Punkt A1, Injection zusammengefasst. Einen Teil davon habe ich bereits im ersten Teil behandelt: SQL Injection, LDAP Injection und XPath Injection. In dieser Folge geht es um die fehlenden Schwachstellen bzw. Angriffe.

OWASP Web Top 10 A1: Injection

4. NoSQL Injection

Auch NoSQL-Datenbanken benötigen eine Möglichkeit, Daten einzutragen, sie zu ändern oder abzufragen. Immer, wenn eine Abfragesprache verwendet wird und vom Benutzer manipulierbare Daten für die Abfragen verwendet werden, besteht die Gefahr einer Injection-Schwachstelle. Nur dass es dann eben keine SQL Injection ist, sondern eine JSON Injection, JavaScript Injection oder was auch immer.

Egal welche NoSQL-Datenbank verwendet wird, egal wie die Daten abgefragt werden: Zur Verhinderung von Injection-Schwachstellen muss darauf geachtet werden, dass über die in Abfragen verwendeten Benutzereingaben keine Manipulation der Abfrage möglich ist. Im Fall von JavaScript gilt dann beispielsweise

  • Die JavaScript-Abfragen sollten nicht ad-hoc durch die Verknüpfung vorhandenen Skriptcodes mit Benutzereingaben erzeugt werden.
  • Benutzereingaben sollten mittels regulärer Ausdrücke auf Korrektheit geprüft werden.
  • Der Einsatz des eval()-Befehls sollte vermieden werden, insbesondere zum Parsen von JSON-Eingaben.

Bei anderen Abfragesprachen sieht das Vorgehen ähnlich aus.

5. OS Injection / OS Command Injection

Es gibt immer wieder Situationen, in denen der direkte Aufruf von Befehlen des Betriebssystems nötig ist. Zum Beispiel, weil es kein API gibt, dass die benötigte Funktion zur Verfügung stellt. Werden dabei Benutzereingaben an den Shell-Befehl durchgereicht, kann ein Angreifer dadurch unter Umständen eigene Befehle einschleusen: Es handelt sich um eine OS Injection oder OS Command Injection Schwachstelle.

Aktuell (d.h. im November/Dezember 2016) sucht ein Bot nach Routern, die über eine Command Injection Schwachstelle im Protokoll TR-069 kompromittiert werden können. Beim Eintragen eines neuen NTP-Servers können Shellbefehle eingeschleust werden, über die der Bot seinen Schadcode in den Router lädt und ausführt. Es gibt ein Metasploit-Modul zum Testen dieser und ähnlicher Schwachstellen.

Die für den Aufruf der Systembefehle verwendeten Funktionen enthalten i.A. keinerlei Einschränkungen für die aufzurufenden Befehle und/oder die verwendeten Parameter. Sie reichen die Daten lediglich an das Betriebssystem weiter.

Der beste Schutz vor OS Command Injection ist der vollständige Verzicht auf direkte Aufrufe von Shell-Befehlen, zumindest aber der Verzicht auf entsprechende Aufrufe mit vom Benutzer manipulierbaren Parametern. Die allermeisten Aufgaben können auch über die nicht für Command Injection anfälligen API gelöst werden.

Lässt es sich nicht vermeiden, einen Shellbefehl mit einem vom Benutzer manipulierbaren Parameter aufzurufen, sollten möglichst API-Befehle für den Aufruf der Shell-Befehle verwendet werden, die die Eingaben zusätzlich prüfen und/oder die die gefährlichen Metazeichen nicht unterstützen.

Ist das nicht möglich, muss die Eingabe sehr genau geprüft werden. Wenn möglich, sollte die Eingabe mit einer Whitelist zulässiger Werte verglichen werden. Die zweitbeste Lösung ist die Beschränkung auf eine genau festgelegte Menge an Werten, beispielsweise nur alphanumerische Zeichen oder nur Ziffern. Die potentiell gefährlichen Metazeichen sollten nicht auf dieser Whitelist enthalten sein.

Hat die Eingabe ein genau definiertes Format, das mit Hilfe regulärer Ausdrücke geprüft werden kann, sollte diese Möglichkeit genutzt werden, um syntaktisch ungültige Eingaben zu erkennen. Diese Eingaben können sofort verworfen werden, da sie sowieso nicht verarbeitet werden könnten. Was haben Sie davon, zum Beispiel eine ungültige E-Mail-Adresse zu verwenden? Da sowohl von einem Angreifer manipulierte als auch vom Benutzer falsch eingegebene Daten verworfen werden, sollte der Benutzer über den Fehler informiert werden.

Als letzte Möglichkeit kann die Eingabe auf die folgenden, potentiell kritischen Metazeichen untersucht und diese ausgefiltert werden.:

' (Parameterübergabe)
" (Parameterübergabe)
` (Kommandoaufruf)
¦ (Kommandoaufruf, Pipelining)
> (Redirection, Ausgabe)
< (Redirection, Eingabe)
* (Wildcard)
? Wildcard)
; (Kommandokonkatenation)
$ (Variablennamen)
. (Path Traversal)
!
& (Kommandokonkatenation)
(
)
\0
\r
\n

In der nächsten Folge geht es um weitere Web-Schwachstellen in IoT-Weboberflächen, zunächst um die fehlenden Injection-Angriffe bzw. -Schwachstellen

Carsten Eilers

Trackbacks

Dipl.-Inform. Carsten Eilers am : Die IoT Top 10, #1: Unsichere Weboberflächen, Teil 3

Vorschau anzeigen
Die Beschreibung der gefährlichsten Schwachstellen in den Geräten des IoT geht weiter. Auf der Liste mit den Top IoT Vulnerabilities von OWASP steht auf Platz 1 das &quot;Insecure Web Interface&quot;. Die ersten dort aufgeführten Schwachstell

Dipl.-Inform. Carsten Eilers am : Die IoT Top 10, #1: Unsichere Weboberflächen, Teil 4

Vorschau anzeigen
Die Beschreibung der gefährlichsten Schwachstellen in den Geräten des IoT zieht sich zugegebenermaßen etwas hin. Was daran liegt, dass auf der Liste der Top IoT Vulnerabilities von OWASP auf Platz 1 das &quot;Insecure Web Interface&quot; st

Dipl.-Inform. Carsten Eilers am : Die IoT Top 10, #6: Unsichere Cloud-Interfaces

Vorschau anzeigen
Bei der Beschreibung der gefährlichsten Schwachstellen in den Geräten des IoT gemäß den Top IoT Vulnerabilities von OWASP sind wir bei Punkt 6 angekommen: &quot;Insecure Cloud Interface&quot;. Oder auf deutsch: Unsichere Cloud-Int