Roboter: Pepper ist voller Sicherheitslücken

Der japanische Roboter Pepper ist nicht sicher: Er kann aus der Ferne gesteuert werden, weil er keine Authentifzierung von Befehlen vornimmt. Außerdem gibt es stark veraltete Software und weitere Sicherheitsprobleme.

Artikel veröffentlicht am 29. Mai 2018, 16:38 Uhr, Hauke Gierow

Pepper ist niedlich, aber unsicher (Bild: Xavier Caré / Wikimedia Commons/CC-BY-SA 4.0)

Der japanische Roboter Pepper der Firma Softbank hat zahlreiche Sicherheitslücken, wie Forscher herausgefunden haben. So ist das Admin-Interface nicht durch eine HTTPS-Verbindung abgesichert, außerdem gibt es hardcodierte Passwörter und veraltete Software.

Alberto Giaretta, Michele De Donno und Nicola Drgoni von zwei Universitäten aus Schweden und Dänemark hatten den Roboter untersucht und die Probleme gefunden. Eine Untersuchung mit Nmap ergab schnell, dass veraltete Software eingesetzt wird, etwa OpenSSH 6.6 aus dem Jahr 2014, und, aus demselben Jahr, der Nginx-Server in der Version 1.4.7. Weitere automatische Untersuchungen ergaben die Verwendung schwacher Verschlüsselungsalgorithmen für die SSH-Verbindungen. Ebenfalls nicht beachtet wurden die Empfehlungen der OWASP; so ist kein effektiver Schutz gegen Cross-Site-Scripting (XSS) implementiert.

Nutzer können das hardcodierte Root-Passwort ('root') nicht ändern, es ist außerdem im Handbuch abgedruckt. Mit einem normal eingeloggten Nutzer kann also per Eingabe von su ohne Probleme eine Privilege Escalation durchgeführt werden. Auch der fest voreingestellte Nutzer nao für SSH-Verbindungen kann per Wörterbuchangriff trivial angegriffen werden. Rate-Limiting oder andere Sicherheitsmechanismen gibt es demnach nicht.

Alle korrekten Befehle an die API werden akzeptiert

Ebenfalls möglich ist die Fernsteuerung des Roboters ohne vorherige Authentifizierung. Denn Peppers API gibt den Zugriff auf Sensordaten auch dann frei, wenn kein Nutzer authentifiziert ist. Dafür müssen TCP-Pakete an Port 9559 gesendet werden.

Die Eingabe von uname -a zeigt, dass eine veraltete Version des Linuxkernels auf dem Roboter läuft und er für Meltdown und Spectre anfällig ist, weil keine der eingeführten Mitigationen aktiviert ist. Die Untersuchung zeigt, dass zahlreiche triviale Standardverfahren der Qualitätssicherung nicht eingehalten wurden und nicht einmal ein Portscan durchgeführt wurde.