Skip to content

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

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 "Insecure Web Interface" steht, und zur Sicherheit im Web gibt es bekanntlich eine eigene OWASP Top 10 Liste. Auch wenn OWASP davon nur einen Teil für die IoT-Weboberflächen für relevant hält gibt es da einiges zu beachten.

Die ersten dort für die IoT-Oberflächen 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 behandelt: Im ersten Teil SQL Injection, LDAP Injection und XPath Injection, im zweiten Teil NoSQL Injection und OS Injection / OS Command Injection sowie im dritten Teil SMTP Injection und XML Injection. In dieser Folge geht es um die fehlenden Schwachstellen bzw. Angriffe.

OWASP Web Top 10 A1: Injection

8. Scriptcode Injection

Die meisten Skriptsprachen unterstützen die dynamische Ausführung während der Laufzeit generierten (neuen) Codes. Werden dabei vom Benutzer manipulierbare Daten verwendet, kann ein Angreifer unter Umständen eigenen Code bzw. eigene Befehle einschleusen - eine Scriptcode Injection ist möglich.

Betrachten wir als Beispiel mal eine Weboberfläche, die in PHP implementiert wurde. In PHP wird die Funktion eval() für die dynamische Ausführung von Code verwendet.

Zum Beispiel könnte die Oberfläche vom Benutzer formulierte, gespeicherte Befehle unterstützen, die dann als dynamisch erzeugte Links in der Benutzeroberfläche integriert werden. Die Benutzer rufen diese gespeicherten Befehle dann über einen Link wie zum Beispiel

http://www.iot-geraet.example/aktion.php?befehl=$meinbefehl%3dderbefehl

auf. %3d ist das =-Zeichen.

In der Anwendung werden die Befehle durch dynamisch erzeugte Variablen mit den im Parameter befehl übergebenen Name/Wert-Paar realisiert, im Beispiel mit der Variable meinbefehl und deren Wert derbefehl:

$neuerBefehl = $_GET['befehl'];
eval("$neuerBefehl");

Ein Angreifer kann über diese Funktion eigenen PHP-Code einschleusen. Das Semikolon ; kann verwendet werden, um mehrere Befehle zu einem Batch zusammen zu fassen. Um z.B. die Datei /etc/passwd anzuzeigen, können z.B. die PHP-Funktionen file_get_contents() oder system() verwendet werden:

http://www.server.example/aktion.php?befehl=$meinbefehl%3dderbefehl;%20echo%20file_get_contents('/etc/passwd')

oder

http://www.server.example/aktion.php?befehl=$meinbefehl%3dderbefehl;%20system('cat%20/etc/passwd')

Die Leerzeichen werden URL-kodiert als %20 eingegeben.

Im ersten Fall wird aus obigen eval() Aufruf

eval("$meinbefehl=derbefehl; echo file_get_contents('/etc/passwd')");

Dadurch wird nicht nur der vom Benutzer vorgegebene Befehl ausgeführt, sondern zusätzlich der Inhalt der Datei /etc/passwd ausgegeben.

Deren Ausgabe ist unter Unix/Linux ein beliebtes Standardbeispiel für das Ausspähen von Informationen. Für einen Angreifer gibt es natürlich viel interessantere Möglichkeiten, wie das Ausführen beliebiger Shellbefehle oder das Installieren einer Hintertür. Auch das ist durch das Einschleusen entsprechenden PHP-Codes möglich.

Der beste Schutz vor dem Einschleusen von Skriptcode besteht wie immer darin, keine vom Benutzer manipulierbaren Parameter für die dynamische Codeausführung zu verwenden.

Lässt sich das aus zwingenden Gründen nicht vermeiden, müssen die Parameter besonders gründlich überprüft werden. Wann immer möglich, sollte die Eingabe mit einer Whitelist zulässiger Werte verglichen und nur erwünschte Werte übernommen werden. Die zweitbeste Lösung besteht in einer Beschränkung der Eingabe auf harmlose Wertbereiche, zum Beispiel nur alphanumerische Zeichen ohne Whitespace-Zeichen wie Leer- und Tabulatorzeichen.

Mein dringender Rat ist aber: Nutzen Sie keine dynamische Codeausführung mit Benutzereingaben, dann kann darüber auch kein Schadcode eingeschleust werden. Das Risiko ist einfach zu groß.

9. SOAP Injection

Das Simple Object Access Protocol (SOAP), dient dem Austausch von Daten und dem Durchführen von Remote Procedure Calls (RPC, entfernte Prozedur-Aufrufe) zwischen verschiedenen Servern oder im Fall des IoT zwischen den IoT-Geräten und den zugehörigen Servern. SOAP stützt sich auf verschiedene andere Standards: XML für die Repräsentation der Daten und Internet-Protokolle für ihren Austausch.

Da XML interpretiert wird, ist SOAP potentiell für das Einschleusen fremden Codes anfällig. XML-Elemente werden mit Hilfe der Meta-Zeichen <, > und / dargestellt. Werden Benutzereingaben, die diese drei Zeichen enthalten, direkt in eine SOAP-Nachricht eingefügt, kann der Angreifer darüber die Struktur der Nachricht und indirekt die Anwendungslogik beeinflussen.

Zum Schutz vor einem Injection-Angriff dürfen Eingaben nie ohne vorherige Prüfung weitergegeben werden. Eingabeparameter müssen aus der Schnittstellenbeschreibung (WSDL-Datei) heraus auf schädlichen Code gefiltert werden. So können z.B. über eine Whitelist nur systemkonforme Strings zugelassen werden. XML-Metazeichen müssen in die entsprechenden HTML-Entities umgewandelt werden, so dass der XML-Interpreter sie als Daten des betreffenden Elements und nicht als Teil der Nachrichtenstruktur interpretiert. Das betrifft insbesondere < (&lt;), > (&gt;) und / (&#47;).

Strings sollten als Eingabetyp möglichst komplett vermieden und Integer-Werten auf ihre Länge geprüft werden.

In der nächsten Folge werden weitere Schwachstellen in den Weboberflächen der IoT-Geräte vorgestellt.

Carsten Eilers

Trackbacks

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