The Industrial Raspberry Pi Forum

Volker,
soll ich mal lachen, ich habe diese PN Nachweislich an Matthias geschickt, seine Reaktion war totschweigen, deine Reaktion darauf unter nennung der PN an Matthias war um so größer, soll ich teile davon hier posten? ich hab mich damals bewusst dagegen entschieden im Forum direkt zu berichten, damit ihr die möglichkeit habt darauf zu reagieren. Bis heute sehen die scripte aber noch genauso aus. Keine Authorisation, keinerleis Überprüfung der übergebenen Parameter.

Datei /var/www/pictory/php/deleteFile.php aus pictory version 1.2.5-1 der aktuellsten, sieht immer noch so aus wie damals

..dass Ingo und Du hier eine Legende aufbauen, die einfach nicht den Tatsachen entspricht. ..

An legenden bin ich nicht interessiert, ich bin nur schlichtweg sauer wie man auf den Hinweis eingegangen ist, nämlich bisher gar nicht. und das hat auch nix mit ingo zu tun, der nen teil hardware von euch betreibt und mich gebeten hat da mal ein wenig drauf zu achten.
mfg
PS: volker, das problem was ich Matthias geschildert habe, hat zu dem geführt was wulf jetzt etwas genauer und mit höhere Wirkung präsentieren konnte. aber jetzt bitte weiter machen mit polemik

Axel, bitte mal mein Posting lesen:
Die Von Dir geschilderte Problematik wurde von uns geprüft und nicht als relavantes Sicherheitsproblem betrachtet. Und der aktuelle Code, um den es hier geht, hat rein gar nichts mit dem von dir damals genannten Script zu tun. Das von Dir bemängelte Script ist nicht in er Lage beliebigen Code auf dem Zielsystem auszuführen, sondern ermöglicht das Löschen von Dateien in einem Verzeichnis, in welchem der eingeloggte User die Freiheit hat zu tun und zu lassen was er will - einschließlich dem Löschen seiner Konfiguration.
Mach doch einfach Ingos System dicht, wenn es unbedingt im Internet zugängig sein soll. Der Code ist frei zugängig und niemand hindert Dich, ihn so abzuändern, wie du ihn Dir vorstellst. Wir haben schon damals unterschiedliche Vorstellungen davon gehabt, wie die Scripte auszusehen haben und ich respektiere Deine Meinung dazu. Es ist aber eben nur eine Meinung, die unsere Softwareabteilung nicht zur Basis der nachfolgenden Versionen hergenommen hat. Wenn Ingo in seinem Posting und Du in Deinem hier im Forum die Auffassung vertretet, dass KUNBUS in Sachen Security "nichts getan" hätte, dann kann ich das aber so nicht stehen lassen, weil es schlicht weg falsch ist. Allein die gemeinsame Schaffung und Bereitstellung eines TeamViewer RevPi zeigt doch deutlich, dass wir uns sehr wohl Gedanken zu dem Thema gemacht haben und auch eine sichere Lösung präsentiert haben.
Und noch einmal: In einem normalen industriellen Umfeld unter Einhaltung der gebotenen und von uns ausdrücklich empfohlenen Sicherheitshinweise liegt weder bei dem von Dir bemängeltem Script noch bei der von Wulf gefundenen Lücke eine Angriffsmöglichkeit auf das System vor. Deshalb verstehe ich nicht, warum von Ingo und Dir hier ein Risiko an die Wand gemalt wird, welches jeder User vermeiden kann (z.B. durch die Verwendung des TeamViewer RevPi) und welches bei sachgemäßer Anwendung so nicht besteht.

Volker deine Ausführungen, sind sehr interessant, ließ nochmal die PN an Matthias, ließ noch mal das Posting von Wulf.
huch den geübten fällt auf ich sprach von einen Ordner, exemplarisch von der Datei deleteFile.php, was schrieb wulf die nacht ?

Wo "pictory" angesprochen wurde. Da hab ich auch mal eben eine Lücke gefunden, über die man Code ausführen kann genau eine datei aus diesen besagten ordner.
wollen wir uns diesen hier auch anschauen ? ups da war es wieder, keine authorisation, keinerlei prüfung der vom Browser übergegebenen Parameter, genau das was ich kritisiert habe, was ja angeblich keinerlei Sicherheitsproblem darstellt, aus diesen Grund kann auch jeder ohne authorisation die urls von dal.php etc aufrufen. und kann mangels Parameter prüfung beinah alles machen was er will. Was natürlich auch kein Sicherheitsproblem ist. Hätte ich euch erst solche exploits schreiben müssen, oder hätte es genügen müssen wenn ich euch auf diese Schwachstelle im Programmcode Hinweise. einer wohlgemerkt seit Jahren schon bekannten Problematik im bereich der PHP Entwicklung. Ein Uni Dr meinte zu euren Code "das ist verdammt Mutig" ich schließ mich der sache an, und werde hier keinerlei postings mehr machen.

volker wrote: ↑20 Feb 2018, 09:56 Und noch einmal: In einem normalen industriellen Umfeld unter Einhaltung der gebotenen und von uns ausdrücklich empfohlenen Sicherheitshinweise liegt weder bei dem von Dir bemängeltem Script noch bei der von Wulf gefundenen Lücke eine Angriffsmöglichkeit auf das System vor. Deshalb verstehe ich nicht, warum von Ingo und Dir hier ein Risiko an die Wand gemalt wird, welches jeder User vermeiden kann (z.B. durch die Verwendung des TeamViewer RevPi) und welches bei sachgemäßer Anwendung so nicht besteht.

@volker

Ich weiß ja nicht, wie eure anderen Industriekunden arbeiten. Es ist natürlich zu hoffen, dass dort eine hohe Security Awareness besteht und deren Entwickler und Admins sehr sensibel mit dem Thema umgehen.
Aber ich glaube nicht daran. Dazu sehe ich einfach zu viele Sicherheitsprobleme. Und in meinen Augen hat sich in den 20 Jahren, in denen ich Internet nutze, nicht viel geändert. Die meisten Leute haben sich damals nicht für Sicherheit interessiert, sie interessiert es auch heute noch nicht.

Es dürfte ein übliches Szenario sein, dass so ein RevPi im Produktiveinsatz zusammen mit anderen Geräten im selben Netzwerk hängt und der Webserver und diese PHP-Programme aus dem Netzwerk heraus erreichbar sind. Oder willst du mir wirklich erzählen, dass (fast) alle eure Kunden den Webserver abschalten bzw. die PHP-Programme löschen?

Ein anderes Szenario ist die Entwicklung: Ein Entwickler kriegt einen RevPi hingestellt und schließt den im selben Netz an wie seine Workstation. Die Workstation kommt ins Internet raus und kann auch auf den RevPi zugreifen. Ein Angreifer muss dem Entwickler nur noch einen Link schicken und schon hat der Angreifer Zugriff auf den RevPi und damit auch das Netzwerk in dem er steht.
Ich halte das durchaus für ein relevantes Sicherheitsproblem. Wenn es meiner Argumentation dienlich ist, kann ich gerne eine Demo basteln.

Schieb die Verantwortung bitte nicht auf andere ab und rede die Probleme bitte nicht kleiner, als sie sind.

Hallo,
eigentlich lese ich hier sonst nur mit, aber bei diesem Thema...

Ich muss schon sagen, seitens Kunbus scheint ein sehr schräges Verständnis von Sicherheit und Verantwortung zur Sicherheit vorzuherrschen.
Anderes kann man bei "intensiver Betrachtung und Bewertung" von durchaus gefährlichen Sicherheitslücken und deren Einschätzung als "nicht relevant" wirklich nicht annehmen.

Seit wann ist es für den Kunden verpflichtend sich um die programmierte (SOFTWARE-)Sicherheit einer erworbenen Appliance selbst zu kümmern? (welche, wie zurecht bemerkt, mit dem nächsten Update überschrieben wird)
Seit wann ist das unbrauchbar-machen oder das Ausführen beliebigen Programmcodes auf einem mehr oder minder wichtigen Device in einem Leistungserbringungsprozess, Herstellungsprozess, Überwachungsprozess oder wie auch immer automatisierten Prozesses eine potentiell akzeptable und gar nicht soooo gefährliche Situation??

Ich weiß auch gar nicht warum das Hauptargument der Unsicherheit darauf beruht, daß der Angreifer von ausserhalb kommt und somit das Device aus dem Internet erreichbar sein muss...
Das ist mit Verlaub, totaler Unsinn!
Das ist gerade mal EIN möglicher Angriffsvektor. Wenn man sich nur ein wenig mit IT-Sicherheit beschäftigt, dann weiß man, daß ein SEHR GROSSER Teil der Angriffe von INNEN kommen. Seien es frustierte oder gekündigte Mitarbeiter oder einfach nur unbedarftes Handeln nach dem Motto: Wird schon klappen. (Damit ist das Sicherheitsrisiko nicht nur eines für Privatanwender)

Mir wird gerade schlecht, wenn ich an die potentiellen Angriffsoptionen denke. Denial of service, Spamverbreitung, Spionage, Beeinflussung der damit kontrollierten Prozesse etc etc etc... Die Möglichkeiten sind endlos, solange ich ein Gerät habe, das tut was ich ihm sage.

Erinnert sich noch jemand an die Zentrifugen zur Urananreicherung, die durch einen gezielten "Virus" zerstört wurden?
Die Laufgeschwindigkeit wurde sicher auch durch ein Device überwacht.
Ich glaube nicht, daß dieses über Internet erreichbar gewesen wäre... (Meines Wissens wurde der Virus durch SocialEngineering eingeschleust)

Wenn ein Angreifer auch nur ein bißchen kriminelle Energie besitzt und weiß, wo und wofür ein Konkurrent einen solchen Pi einsetzt, dann kann er sehr wohl echten Schaden anrichten.
Und meiner Meinung nach ist dann nicht der Netzwerkverantwortliche / Admin / Betreiber dafür verantwortlich, weil er ein unsicheres Passwort vergeben hat (Scheint ja keins notwendig zu sein ),
sondern der Hersteller der Appliance / der Software, weil er davon ausgeht, daß sämtliche Anfragen an das Device legitim sind und nicht geprüft werden müssen.

Ich kann nur hoffen, daß solche, meiner bescheidenen Meinung nach schon sehr kritische Sicherheitslücken auch als solche behandelt und geschlossen werden. Nur weil noch nichts passiert ist, heißt das nicht, daß es keine Relevanz hat. Der frustrierte MA muss jetzt nur diese Seite finden...

Dennoch einen schönen Tag,
Micha

Hallo Leute.
jetzt muss ich doch auch mal was schreiben (normal les ich hier immer nur). Wir setzten den RevPi seit vielen Monatnen in allen möglichen projekten ein und sind total begeistert von dem teil. Und vor allem von dem support hier online. ich hab selber schon viel mit S... und co zu tun gehabt und deren sogenannte hotline is einfach nur eine katastrophe. Kollegen haben hier ihr problem geschildert und in nix komma nix wurde hoch qualifiziert geantwortet. ich mach den job schon ziemlich lang und hab so reaktionsszeiten bei keiner anderen firma bekommen. und jetzt findet da jemand eine schwachstelle im pictory, meldet sich damit bei den Revolutions-Machern und was machen die? Keine der firmen, die ich kenne hätte so was öffentlich gemacht, sondern alle hätten es totgeschwiegen und forenbeiträge einfach gelöscht. Aber hier macht Revpi offenbar alles anders - eben ganz auf revolution: die veröffentlichen das und freuen sich sogar noch über den Wulf seine arbeit. Dann versprechen sie das loch schnell zu zu machen. Und was macht ihr hier, Leute? Ihr schiebt stress wegen einer ganz anderen sache von vor einem jahr, die offenbar ganz anders zu bewerten ist. Was soll das bringen? Motivationsschub für kunbsu weiter so offen mit uns kunden umzugehen? mann freut euch doch, dass wir hier so offen über ein problem reden und die jungs das dann auch noch schnell in ordnung bringen wolln statt euch mit irgendwelchem zeug von vorgestern zu befassen. ich sag jedenfalls alle achtung volker für die offenheit und den mut. Ihr habt ein sau geiles produkt. macht weiter so!
Georg

Danke Georg für dieses Lob.
Vielleicht wurde durch die Diskussion um einen weit zurückliegenden Austausch damals meine Aussage für die Gegenwart relativiert. Das war nicht meine Absicht. Ich sagte gleich in meinem ersten Beitrag: KUNBUS nimmt diese Meldung ernst, hat sie genau deshalb entgegen dem gut gemeinten telefonischen Angebot von Wulf umgehend öffentlich werden lassen und wird sehr zeitnah ein Update veröffentlichen, in welchem die Ausführung von beliebigen Schadcode nicht mehr möglich sein wird.
Wir wollten immer ein offenes System ausliefern, welches sehr viele Schwachstellen in sicherheitstechnischer Hinsicht hat. Würden wir die Philosophie von Micha vertreten und uns in der Verantwortung sehen, ein fertiges System auszuliefern, welches Plug & Play sicher vor beratungsresistenten Kunden sein soll, dann dürften wir kein offenes System ausliefern, sondern eines welches keinen root Zugriff ermöglicht und ausschließlich mit von KUNBUS festgelegten Programmen arbeitet. Genau das ist dann aber kein Raspberry Pi für die Industrie mehr, sondern einer von vielen Linux IPCs, mit denen eben nur machbar ist, was der Hersteller erlaubt.
Der Nachteil unserer Philosophie ist dann zwangsläufig ein hohes Maß an Verantwortung welches der Kunde trägt, um aus so einem offenen System ein sicheres System zu machen. Und ja, wir kennen die Realität "da draußen". Dort werden zum Beispiel nach Untersuchungen von Sicherheitsexperten an mehr als 1/3 aller Systeme Passwörter auf PostIt Zettel geschrieben und an das Gerät geklebt. Sind wir deshalb als Hersteller in der Pflicht unsere Gehäuse so zu beschichten, dass keine PostIts mehr drauf halten? Wir haben sehr sehr deutlich in unseren Tutorials und an anderen Stellen darauf hingewiesen, dass der User das Default Passwort direkt nach der Erstinbetriebnahme abändern soll. Und dort erlauben wir uns, die Verantwortung an den Kunden abzugeben. Als Autohersteller muss ich auch ein Minimum an "Compliance" der Fahrer erwarten können: Sie sollten einen Führerschein besitzen und die Verkehrsregeln einhalten. Und so erwarten wir auch von Usern unserer Geräte, dass sie ein für die Industrie geschaffenes Produkt mit entsprechender Fachkenntnis einsetzen und die zu dieser Fachkenntnis gehörenden Regeln einhalten. Wenn wir einfache Wege sehen, User vor eigener Unkenntnis oder Faulheit zu schützen, dann gehen wir auch diese Wege - solange nicht andere fachkundige User dadurch Freiheiten verlieren würden, die sie für die Realisierung ihrer Projekte benötigen. Und nocheinmal in aller Klarheit: Genau darum steht Wulfs Beitrag hier im Forum und genau darum werden wir darauf mit einem Update reagieren.

Hallo,

dass das Produkt im Allgemeinen "geil" ist sehen wir ja genau so. Sonst würden wir uns nicht damit befassen. Es ist halt schade (und in unserem Bewusstsein ein Stück weit fahrlässig), wenn das alles zum Konzept gehört, um die Freiheit nicht einzuschränken. Das hat prinzipiell auch nichts mit der Qualität des Supports zu tun. Das der super funktioniert ist ja auch lobenswert.

Das aber Skripte etwas tun ohne sicherzustellen, daß die Anfrage legitim ist, macht jedwedes Passwort obsolet. Also wozu dann überhaupt ein Passwort verwenden? Das lese ich zumindest aus den Posts von Axel und Wulf heraus. Und das ist im Endeffekt der Urspung der Probleme. Der Türsteher pennt! Die Code-Injection ist dann "nur" eine weitere Konsequenz. Hätte der Türsteher nur den Fahrer mit Führerschein reingelassen, wäre der VIELLEICHT EVENTUELL auch verantwortlich, wenn er an der Bar ein Glas an die Wand schmeisst.

Ich gehe hier ja auch nicht davon aus, daß derjenige mit Führerschein nicht weiß, wie man Auto fährt.

ABER:
Was würde denn passieren, wenn dem Fahrer mit Führerschein während der Fahrt die Räder gelöscht werden oder das Lenkrad plötzlich die Scheibenwischer regelt, und das nur weil jemand "Fremdes" das so wollte, weil möglich.

Ich bin jedenfalls auf die nächsten Updates gespannt.
In diesem Sinne...

Gruß Micha.

Ich finde es gut, wie offen Kunbus mit dem Thema umgeht. Ich hatte vor meinem Foren-Post angerufen. Ich hatte mich etwas über die Aufforderung gewundert, hier gleich alle Details zu veröffentlichen. Ist halt kein übliches Vorgehen, normal wird sowas erstmal unter Verschluss gehalten. Aber ich finde es prinzipiell besser als Geheimniskrämerei.
Hoffentlich hilft es den Kunbus-Kunden dabei, ihre eigene Verantwortung ernst zu nehmen und sich über Sicherheit mehr Gedanken zu machen.
Und um es nochmal zu betonen: Interne Netzwerk sind immer als unsicher zu betrachten! Ebenso ist sämtlichen Daten, die man empfängt, nicht blind zu vertrauen. Liebe Entwickler, bitte schreibt eure Software anständig

Dennoch erwarte ich von Kunbus (und jedem anderen Hersteller von Hard- oder Software in der Welt!) dass vernetzte Produkte vom Werk aus sicher konfiguriert sind. Man muss die mit öffentlicher IP-Adresse ans Internet hängen können und es darf nichts passieren. Erst wenn ich selbst was dran ändere, gerate ich in die Verantwortung, für Sicherheit zu sorgen. Und wenn ich ein Gerät stark modifiziere und produktiv einsetze, liegt die Verantwortung um so mehr bei mir selbst.

Ich gehe mal davon aus, dass die Probleme zeitnah mit einem Update behoben werden.

Das versprochene Update ist heute online gestellt worden und sollte die diversen Lücken schließen.