Skip to content

Die IoT Top 10, #7: Mobile Cloud-Interfaces

Bei der Beschreibung der gefährlichsten Schwachstellen in den Geräten des IoT gemäß den Top IoT Vulnerabilities von OWASP sind wir bei Punkt 7 angekommen: "Insecure Mobile Interface". Oder auf deutsch:

Unsichere Mobile-Interfaces

Eine App ist für die Nutzung vieler IoT-Geräte zwingend notwendig. Und genau wie im Fall des Cloud-Interfaces aus der vorherigen Folge gilt, dass das zugehörige Interface sicher sein muss, um einen Missbrauch von App und/oder IoT-Gerät auszuschließen. Denn Sie wollen ja sicher weder, dass sich ein Angreifer gegenüber Ihrem IoT-Gerät als ihre App ausgibt, noch dass er sich gegenüber Ihrer App als zugehöriges IoT-Gerät ausgibt. Denn in beiden Fällen kann das sehr unschöne Folgen haben, egal ob dem Gerät nun Befehle erteil werden, die nicht in Ihrem Interesse liegen, oder ob der App falsche Daten untergeschoben werden, die Sie dann zu unerwünschten Aktionen bewegen.

Betrachten wir als einfachstes Beispiel einmal eine Alarmanlage, natürlich vollständig durchdigitalisiert und über eine App zu steuern. Weder möchten Sie, dass ein Einbrecher sich gegenüber der Alarmanlage als Sie (d.h. Ihre App) ausgibt und sie einfach ausschaltet, um dann Ihr Haus auszuräumen, noch möchten Sie, dass ein Einbrecher sich gegenüber Ihrer App als die Alarmanlage ausgibt und den beim Einbruch ausgelösten Alarm als Fehler storniert.

Wenig verwunderlich gibt es diesmal viele Überschneidungen mit dem Punkt 6 der IoT-Top-10, den Cloud-Interfaces, der ja selbst bereits viele Überschneidungen mit vorherigen Einträgen auf der Top-10-Liste aufwies. In diesem Falls sind es die Punkte

Unsichere Mobile-Interfaces erkennen

Im Grunde muss auf alle oben schon aufgeführten Schwachstellen geachtet werden. OWASP listet in der Beschreibung von Punkt 7 explizit die folgenden Punkte auf, auf die geachtet werden muss:

  • Prüfen Sie, ob der Default-Benutzername und das Default-Passwort beim ersten Einrichten des Geräts geändert werden können (was ich zumindest beim Passwort zu einem "müssen!" verschärfen würde).
  • Prüfen Sie, ob ein bestimmter Benutzeraccount nach 3-5 fehlgeschlagenen Login-Versuchen blockiert wird (was ich wie schon bei den Cloud-Interfaces für gefährlich halte, denn so lässt sich wunderbar ein DoS auslösen, wenn es keine Möglichkeit gibt, die Sperre wieder aufzuheben - der Angreifer muss dann nur alle Benutzeraccounts der Reihe nach lahm legen und die Benutzer sind draußen).
  • Prüfen Sie, ob gültige Benutzernamen z.B. über die Passwort-Recovery-Funktion oder neue Benutzer-Seiten ermittelt werden können.
  • Prüfen Sie, ob die Zugangsdaten in WLANs ausgespäht werden können (mit anderen Worten: Prüfen Sie, ob die Zugangsdaten verschlüsselt übertragen werden oder nicht).
  • Prüfen Sie, ob optional eine Zwei-Faktor-Authentifizierung verwendet werden kann.

Anforderungen an ein sicheres Mobile-Interface

OWASP listet in der Beschreibung von Punkt 7 explizit die folgenden Punkte auf, auf die geachtet werden muss:

  • Default-Passwörter und idealerweise auch Default-Benutzernamen können beim ersten Einrichten geändert werden (wobei ich für die Passwörter wieder ein "müssen!" verlangen würde).
  • Gültige Benutzernamen können nicht über Funktionen wie den Passwort-Reset etc. ermittelt werden.
  • Nach 3-5 fehlgeschlagenen Login-Versuchen sollte das betreffende Benutzerkonto gesperrt werden (aber passen Sie auf, dass Sie sich dadurch keine DoS-Schwachstelle einhandeln, s.o.).
  • Zugangsdaten dürfen in WLANs nicht ausgespäht werden, mit anderen Worten: Die Zugangsdaten müssen immer verschlüsselt übertragen werden. Was am einfachsten durch die Verschlüsselung der kompletten Kommunikation über SSL/TLS erfolgt. Ggf. wäre es zwar auch möglich, die Zugangsdaten separat zu verschlüsseln, aber dann besteht immer noch die Gefahr, dass ein Angreifer die übertragenen Nutzdaten manipuliert.
  • Wenn möglich, sollte eine Zwei-Faktor-Authentifizierung verwendet werden.
  • Für die App sollten Obfuscation-Techniken verwendet werden (das sehe ich nicht so - Obfuscation ist Security by Obscurity, das funktioniert nicht!).
  • Schützen Sie die App vor Manipulationen.
  • Der Punkt "Ensuring the mobile app's memory hacking is possible" ist hoffentlich ein Schreibfehler - seit wann möchte man denn, dass der Speicher der eigenen App gehackt werden kann? Eigentlich sollte man doch wohl das Gegenteil fordern. Aber eigentlich ist das sowieso egal, denn ob ein Angreifer den Speicher einer App manipulieren kann oder nicht dürfte kaum von der App zu beeinflussen sein. Da ist ja wohl dann doch das Betriebssystem des Mobilgeräts gefordert.
  • Auch die nächste Forderung ist diskussionswürdig: Schränken Sie die Ausführung der App auf manipulierten Betriebssystemen ein. Das kann man machen, sperrt damit aber auch die Nutzer solcher Systeme aus. Und ich könnte mir vorstellen, dass das genau die Benutzer sind, die am ehesten ein neues IoT-Gerät ausprobieren würden. Also: Wenn Sie auf diesen Markt verzichten können, verhindern Sie die Ausführung Ihrer IoT-App auf gerooteten bzw. gejailbreakten Geräten. Wenn nicht, akzeptieren Sie die Hoheit der Benutzer über ihre eigenen Geräte und legen Sie ihnen keine Steine in den Weg.

Soviel zum "Insecure Mobile Interface". In der nächsten Folge geht es um Punkt 8 der IoT-Top-10: "Insufficient Security Configurability", also mangelhafte (Sicherheits-)Konfigurationsmöglichkeiten.

Carsten Eilers

Trackbacks

Keine Trackbacks