Dipl.-Inform. Carsten Eilers

Eigentlich müssten die OWASP Top 10 fürs Web also die Plätze 1-10 der IoT Top 10 füllen und erst danach die restlichen IoT-Schwachstellen folgen. Womit wir eine "Top 21"-Liste hätten.

Freundlicherweise hat man bei OWASP aber die Web-Schwachstellen in Punkt 1 zusammen gefasst und sich dabei auf einen Teil der Web-Top-10-Einträge beschränkt:

"A secure web interface requires:

1. Default passwords and ideally default usernames to be changed during initial setup
2. Ensuring password recovery mechanisms are robust and do not supply an attacker with information indicating a valid account
3. Ensuring web interface is not susceptible to XSS, SQLi or CSRF
4. Ensuring credentials are not exposed in internal or external network traffic
5. Ensuring weak passwords are not allowed
6. Ensuring account lockout after 3 -5 failed login attempts"

Damit bleiben von den 10 Einträgen der Web-Top-10-Liste "nur" noch drei übrig:

• Top 10 2013 - A1 - Injection
• Top 10 2013 - A3 - Cross-Site Scripting
• Top 10 2013 - A8 - Cross-Site Request Forgery (CSRF)

Aber freuen Sie sich nicht zu früh, einige der weiteren Einträge in den IoT Top 10 haben Entsprechungen in den Web Top 10. Außerdem fallen einige der oben zitierten Anforderungen in weitere Web-Top-10-Einträge: Alles rund um die Passwörter gehört im Web zu Top 10 2013 - A2 - Broken Authentication and Session Management, und der Punkt "Ensuring credentials are not exposed in internal or external network traffic" fällt im Web unter den Punkt Top 10 2013 -A6 - Sensitive Data Exposure.

Also sehen wir uns die Schwachstellen mal der Reihe nach an.

OWASP Web Top 10 A1: Injection

Unter dem Punkt A1, Injection wird eine ganze Reihe von Angriffen bzw. Schwachstellen zusammen gefasst, die sich alle mit dem Einschleusen von Befehlen in Interpreter befassen.

Beachten Sie bei allen Angriffen auch immer die Gefahr eines Angriffs auf die Server, mit denen sich viele IoT-Geräte verbinden müssen, um überhaupt genutzt werden zu können. Wenn Sie für so einen Server zuständig sind, egal ob als Entwickler oder Administrator, denken Sie daran: Ein Angreifer kann

• sein IoT-Gerät manipulieren, um davon präparierte Daten senden zu lassen,
• die von einem unveränderten Gerät gesendeten Daten in einem Proxy manipulieren, oder
• ein beliebiges Programm verwenden, um sich mit dem Server zu verbinden und präparierte Daten einzuschleusen.

Sie müssen also immer mit Angriffen rechnen und dürfen sich nicht darauf verlassen, dass sich ja nur "ihre" vertrauenswürdigen IoT-Geräte mit dem Server verbinden.

1. SQL Injection

Die Structured Query Language (SQL) wird für die Abfrage von Datenbanken verwendet, und SQL Injection dürfte der bekannteste Injection-Angriff sein. SQL Injection habe ich bereits hier im Blog beschrieben, so dass ich hier nicht weiter darauf eingehen muss. Alles, was ich damals dazu geschrieben habe, ist nach wie vor gültig. Und unabhängig davon, ob die SQL-Datenbank nun auf einem Server oder einem IoT-Gerät läuft.

2. LDAP Injection

Das Lightweight Directory Access Protocol (LDAP) dient zur Abfrage von Informationen verteilter Verzeichnisdienste. LDAP Injection Schwachstellen entstehen, wenn Benutzereingaben ungeprüft für LDAP-Abfragen verwendet werden. Der Angreifer manipuliert die LDAP-Abfragen so, dass mehr als die vorgesehenen Daten ausgegeben werden.

Nun werden IoT-Geräte eher selten mit LDAP zu tun haben, so dass i.A. keine Gefahr einer LDAP-Injection besteht. Aber falls doch LDAP eingesetzt wird, müssen zum Schutz vor solchen Angriffen alle Benutzereingaben geprüft werden. Wie, steht ausführlich im OWASP LDAP Injection Prevention Cheat Sheet.

3. XPath Injection

Die XML Path Language (XPath) dient zur Abfrage von Informationen aus XML-Dateien. Werden Benutzereingaben ungeprüft für XPath-Abfragen verwendet, kommt es zur XPath Injection: Ein Angreifer kann die Abfrage nach seinen Wünschen manipulieren und unbefugt auf Daten zugreifen.

XML wird oft für die Speicherung von Konfigurationsdateien oder der Übertragung von Daten verwendet, etwas, was im IoT ja des öfteren passiert.

Für den Schutz vor XPath Injection gelten im Grunde die gleichen Maßnahmen wie für den Schutz vor SQL Injection: Die Verwendung parametrisierter Abfragen und die Filterung der Eingaben.

Im Gegensatz zu den meisten Datenbanken kennt XPath selbst keine parametrisierten Abfragen, sie werden aber von verschiedenen APIs wie zum Beispiel XQuery bereit gestellt. Sofern verfügbar, sind sie der beste Schutz vor XPath-Injection und sollten verwendet werden.

Stehen parametrisierte Abfragen nicht zur Verfügung, müssen alle Benutzereingaben geprüft und unerwünschte Eingaben verworfen oder gefiltert werden. Wobei beim Ausfiltern gefährlicher Zeichen wie immer die Gefahr besteht, dass die Filter ausgetrickst werden können.

Am besten wird die Eingabe anhand einer Whitelist mit zulässigen Werten geprüft. Ist das nicht möglich, kann evtl. ein Whitelist zulässiger Zeichen verwendet werden, die am besten nur alphanumerische Zeichen enthält. Als letzte Möglichkeit bleibt das Prüfen auf die gefährlichen Zeichen, über die die XPath-Abfrage manipuliert werden kann. Diese müssen ausgefiltert werden.

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