The Industrial Raspberry Pi Forum

Moin,
Zeile 445 hat eine Sicherheitslücke, über die man beliebigen Code auf dem RevPi ausführen kann:
müsste escaped werden, siehe https://secure.php.net/manual/en/functi ... ellarg.php

Der Rest vom PHP-Code ist auch nicht wirklich sicher. Man kann z. B. den Hostnamen und das Default-Passwort ohne Authentifizierung abfragen. Ich glaube das Skript sollte besser nochmal neu gemacht werden.

Hier ist ein Demo-Exploit, mit dem eine Reverse-Shell zu einem anderen Rechner aufgebaut werden kann.
Auf dem Rechner des Angreifers ausführen (Port 31337 muss vom RevPi aus erreichbar sein):
Und um die Shell zu starten (Es muss socat installiert sein. Wenn nicht gibt's auch genug andere Möglichkeiten.):
"angreifer-ip-adresse" und "revpi-ip-addresse" müssen entsprechend angepasst werden.
Wenn das Default-Passwort nicht geändert ist, ist der Weg zum Root nicht weit:
Und noch eine Anmerkung zum Default-Passwort: Das lässt sich aus dem Hostnamen (z. B. "JZKTK64C7R" --> "5r2v5o") mit folgendem Programm berechnen. Deshalb sollte das Passwort *wirklich* geändert werden.

Beste Grüße!

Hallo Wulf,

ich finde es klasse von dir das du dieses Thema noch einmal ausfühlich hier beschreiben tust. Es ist nun schon 1 jahr her das Kunbus diese Sicherheitslücke von einem User geschickt bekommen hat, da es ohne Anmeldung an den Pi möglich ist daten aus der Pictory zu löschen und so das system unbrauchbar zu machen.

Ich hoffe da tut sich bald etwas.

Hallo Wulf,
vielen Dank für Deinen Anruf heute und die wertvollen Hinweise. Dein Mühe diese Lücke aufzudecken und auch gleich die notwendigen Schritte zum Schließen mitzuteilen bestätigt uns darin, dass die beste Sicherheit durch Öffentlichkeit und nicht durch möglichst geschlossene Systeme gegeben ist. Nur die Menge der User einer guten und großen Community ist in der Lage, auch versteckte Schwachstellen aufzudecken und so zu einer stetig wachsenden Sicherheit beizutragen.

Natürlich werden wir sehr zeitnah ein Update veröffentlichen, in welchem diese Lücke geschlossen wird.

Allen anderen Lesern, denen die technischen Details zu komplex sind, ob sie zu beurteilen, möchte ich hier gerne mit einfachen Worten erläutern, wer von der Lücke betroffen sein kann und wer nicht:

1)
Betroffen können Kunden sein, die den Webserver des Systems (also unseren Webstatus und PiCtory) über das internet bereitstellen. Dafür muss der RevPi an einem Router angeschlossen sein, der den Zugang von außen auf das System freigibt und entweder eine feste externe IP dafür bereitstellt (eher unwahrscheinlich) oder über einen Dyn-DNS Service die aktuelle IP des Systems mit einem Domain-Namen verknüpft. Hacker können dann statt einfach mit einem Browser auf das System zu schauen mit einem selbstgeschriebenen Code Daten an den Server senden, die einen beliebigen Code auf dem Server ausführen.
Außerdem beschreibt Wulf einen Algorithmus, mit dem aus dem Servernamen des RevPi das Defaultpasswort berechnet werden kann. Wenn Kunden daher dieses Defaultpasswort nicht abändern, dann kann ein Hacker, der den Servernamen kennt, daraus das Passwort berechnen und somit einen root Zugriff freischalten.

2)
Nicht betroffen sind alle Kunden, die sich an unsere Sicherheitsempfehlungen gehalten haben:

• Kein direkter Zugriff aus dem Internet auf das System freischalten (Router sperrt Zugriffe aus dem Internet auf den Server). Statt dessen Verwendung unseres TeamViewer RevPi, der die Webserver Ausgaben ausschließlich über eine gesicherte Verbindung auf eine TeamViewer Applikation zulässt. Einschleusen von Schadcode ist dabei nur möglich, wenn die TeamViewer Applikation gehackt würde, was unseres Wissens nach noch nicht passiert ist.

• Sofortiger Austausch des Default-Passwortes gegen ein sicheres persönliches Passwort direkt nach dem ersten Login.

• Nutzung eines eigenen Webservers ohne Bereitstellung der RevPi Webseiten mit Status und PiCtory.

Zugriffe im LAN ermöglichen natürlich auch so einen Angriff, aber das ist nochmal eine ganz andere Angelegenheit. Wer Zugriff über LAN auf das System hat, der kann rein prinzipiell auch SSH nutzen (falls dies freigeschaltet ist) und muss nicht über den Webserver gehen, um eine Attacke zu starten. Generell sollten im LAN dann eh die Sicherheitskonzepte des Kunden greifen, der hier ggf. auch über den Router oder einen administrierbaren Switch sicher stellen kann, dass Zugriffe auf die Devices nur von bestimmten Rechnern aus geschehen können.

Wir gehen daher davon aus, dass diese Bedrohung eher nur sehr wenige Kunden betreffen wird und empfehlen nochmals dringend allen Kunden, die üblichen Sicherheitsmaßnahmen zu ergreifen, wenn sie Zugänge über das Internet ermöglichen. Die Sicherheit unseres Webservers ist definitiv nicht auf den freien Zugang aus dem Internet angelegt, sondern für die Verwendung zur Konfiguration im LAN gedacht. Der Zugang aus dem Internet sollte grundsätzlich geschützt (z.B. über den TeamViewer RevPi) erfolgen.

Wir werden in "Neuigkeiten und Ankündigungen" auf die Bereitstellung eines Updates hinweisen, sobald dieses bereit steht.

Es ist nun schon 1 jahr her das Kunbus diese Sicherheitslücke von einem User geschickt bekommen hat

Sorry Ingo, aber das entspricht nun wirklich nicht den Tatsachen, was Du da schreibst. Die hier beschriebene Lücke betrifft Schadcode, der einzig dann auf dem System ausgeführt werden kann, wenn jemand den Zugang von Außen (internet) auf den Webserver vom RevPi freischaltet. Das hat nun rein gar nix mit "ohne Anmeldung an den Pi möglich ist daten aus der Pictory zu löschen und so das system unbrauchbar zu machen" zu tun. Das ist seit heute Nachmittag bekannt und nicht seit einem Jahr!!! Die Sache damals wurde umgehend durch ein Update bereinigt und die neue Sache wird ebenfalls in dem nächsten Update bereinigt sein.

Hallo,
ich glaube ich hatte damals geschrieben:

Gesendet: 28 Jun 2017, 20:23
ich bin ebend ein wenig stutzig geworden über den Ordner /var/www/pictory/php speziell deleteFile.php, wenn ich das jetzt richtig sehe ist da ein löschen von Daten möglich ohne sich zu authorisiern -- das ist doch nicht wirklich euer ernst ?! Ich hoffe mal , dass der Ordner ein überbleibsel von den ersten tests ist und längst gelöscht sein sollte.

Das sich weitere scripte missbrauchen lassen war eigentlich schon fast zu erwarten gewesen und wie ich sehe ist bisher nicht wirklich viel passiert.

Ich empfehle dringenst die authorisation via .htaccess für alle vom webserver genutzten Bereiche zu aktivieren.

Danke wulf, das du dich der sache noch intensiver gewidment hast. ich hoff das es jetzt zügig eine abgesicherte Version gibt.
mfg

volker wrote: ↑19 Feb 2018, 22:37 Die Sicherheit unseres Webservers ist definitiv nicht auf den freien Zugang aus dem Internet angelegt, sondern für die Verwendung zur Konfiguration im LAN gedacht.

Es ist natürlich vollkommen richtig, dass das Risiko besonders groß ist, wenn ein Gerät direkt aus dem Internet heraus erreichbar ist. Aber so schwierig ist es auch nicht, Geräte anzugreifen, die hinter der Firewall stehen:
Wenn hier jemand seinen Desktop/Laptop im selben Netz wie seinen RevPi betreibt und beide nicht direkt aus dem Internet erreichbar sind, würde ein Klick auf den falschen Link ausreichen. Kleines JavaScript, das die lokale IP-Adresse mit WebRTC ausliest oder errät (Hat doch eh jeder zweite ne Fritzbox mit 192.168.178.0/24). Dann fix paar Hundert XMLHttpRequest-Anfragen stellen und alle RevPis im Netz sind gehackt. Dauert max. paar Sekunden und ein normaler User bekommt davon nichts mit. Bevor jemand fragt: Cross-Origin-Requests gehen auch mit POST, ohne preflight. Gerade nochmal getestet.

Ein gutes Sicherheitskonzept würde derartige Angriffe verhindern. Aber das ist den meisten Leuten zu aufwendig umzusetzen, wenn überhaupt das Bewusstsein existiert.

Meine Devise ist immer, dass man auch einem üblichen internen Netzwerk nicht trauen kann und darf. Bloß weil ich paranoid bin, heißt es nicht, dass solche Angriffe nicht möglich wären
Software sollte so programmiert werden, dass man sie auch offen ins Internet stellen könnte.

Wo "pictory" angesprochen wurde. Da hab ich auch mal eben eine Lücke gefunden, über die man Code ausführen kann:
@Ingo, keine Ahnung welche Lücke du meinst. Aber so wie ich das bisher sehe, sollte sich nochmal jemand diese ganzen Webseiten + PHP-Skript genau anschauen. Da wird noch mehr sein
Und bis dahin sollten User sicherstellen, dass der Webserver ausgeschaltet ist oder wirklich kein Unberechtigter diesen erreichen kann.

Axel wrote: ↑19 Feb 2018, 23:44 Ich empfehle dringenst die authorisation via .htaccess für alle vom webserver genutzten Bereiche zu aktivieren.

Das wäre auch nur ein quick+dirty Workaround. Lässt sich mit überschaubarem Aufwand überwinden.
Es führt kein Weg daran vorbei, den Code zu reparieren.

Ich weiß wulf,
leider bringt die Absicherung der einzelnen scripte (von hand) nichts, beim nächsten update via packet verwaltung fängt man nämlich wieder von vorne an. aber besser als gar kein schutz ist es erstmal.
Ingo sprach von dem problem was ich damals gemeldet hatte . wo ich gesehen habe das gegen einfachste programmierregeln verstossen wird "Traue keinen Code der vom Browser kommt" und das an nen unlink gegeben wurde ist mir jedes lächeln aus'm gesicht gefallen. spassig wirds wenn die pictory cfg damit mal ebend gelöscht wird (login daten sind dafür ja gar nicht notwendig). Und modbus master / slave darüber konfiguriert wurden oder nach den löschen halt nicht mehr.
So viel Zeit das system weiter zu analysieren hatte ich leider nicht. und ich bin so nur bei den einen ordner hängen geblieben, von daher gute arbeit und auch eine gute präsentation des problems.

Ich möchte in dieser sache gerne auf https://www.owasp.org/index.php/Main_Page verweisen, eine sehr interessante lektüre die auf aktuellen stand gehalten wird.

Alle unsere industriellen Kunden die ich näher kenne haben extrem restriktive Security Konzepte in ihrem Intranet. Das von Wulf beschriebene Szenario mit einem Laptop wäre dort definitiv nicht möglich. Unsere Webserver PHPs wurden definitiv nicht für den "smart home" Bereich geschrieben, sondern als einfache Möglichkeit, ein Device im Entwicklungsstadium zu konfigurieren. Typische Kunden setzten danach hunderte von Devices mit identischer Konfiguration auf und benötigen den Webserver nicht mehr. jene Kunden, die den Webserver für eine GUI mit Procon Web oder anderen Programmen verwenden, ändern in der Regel die Einstiegsseite so oder so, da nicht erwünscht ist, dass der Endkunde überhaupt mit einer Konfiguration in Berührung kommt. Ansonsten verwenden sie dann eben den TeamViewer RevPi, mit dem diese Art der Attacken nicht ohne weiteren Hack machbar sind.
Die hier dargestellte Lücke betrifft daher in der Regel wirklich nur Privatanwender, die sich irgendwelche Dinge in ihrem privaten Umfeld automatisieren wollen, aber nicht in er Lage oder nicht Willens sind, die Empfehlungen zur Cybersicherheit auch umzusetzen.

Und bis dahin sollten User sicherstellen, dass der Webserver ausgeschaltet ist oder wirklich kein Unberechtigter diesen erreichen kann.

Nein, da widerspreche ich: Nicht "bis dahin", sondern generell sollte das für eine abgeschlossene Entwicklung und ein Seriengerät so sein. Die Konfigurationsseiten des RevPi sind und waren nie dafür gedacht dauerhaft über das Internet Zugängig zu sein und dafür Sorge zu tragen, dass keine Unberechtigten Zugang zum Webserver bekommen, das ist ein sehr zu empfehlender Standard, welcher grundsätzllich immer einzuhalten ist.

Hallo Axel,
lass uns bitte hier mal klarstellen, dass auf die von Dir zitierte Meldung damals umgehend reagiert wurde. Ich möchte mich doch sehr dagegen verwehren, dass Ingo und Du hier eine Legende aufbauen, die einfach nicht den Tatsachen entspricht.

Wir hatten die verschiedenen Einwände von Dir, in denen es primär um Performance ging, ausführlich diskutiert und bewertet. Das von Dir hier angesprochene PHP scipt hat rein gar nichts mit der von Wulf gefundenen Lücke zu tun. Während Wulf hier eine Möglichkeit gefunden hat, beliebigen Schadcode auf dem Zielsystem auszuführen, ging es damals um die Möglichkeit, dass ein eingeloggter User ein Löschen von Dateien in einem Ordner durchführen kann, in dem ausschließlich Dateien liegen, die User editieren können und sollen.

Wenn eine sicherheitsrelevante Lücke bekannt wird, beseitigen wir sie zeitnah. Das war so und wird auch in Zukunft so bleiben. Seit Deiner Meldung damals sind viele hundert Zeilen Code hinzugekommen und unzählige neue Funktionalitäten wurden der Konfigurations-GUI verpasst. Du bist herzlich eingeladen, Dich mit konkreten Vorschlägen, so wie Wulf, konstruktiv in die Verbesserung des Codes einzubringen, denn wir haben hier ein Open Source und Community basiertes Projekt.