0.0.0.0 Day - Schwere Lücke
-
https://www.oligo.security/blog/0-0-0-0-day-exploiting-localhost-apis-from-the-browser
Soviel zum Thema 'Ist doch egal, ob ich root bin oder nicht, ich bin alleine in meinen Netzwerk!'
Ein ziemlicher Trugschluß...
Da kann man nur hoffen, dass da möglichst bald Patches für ankommen.
Der ioBroker (bzw. Adapter) reißt ja einige Dienste auf 0.0.0.0 auf. Wenn die dann auch noch als root laufen, prostmahlzeit. -
Ein dezenter Hinweis ist okay , aber so ne Panikmache ?
Der Hinweis dieser „Lücke“ besteht seit 2006.
Ist die Welt untergegangen danach? Nein.
Von 200mio Webseiten sind 100.000 ca betroffen.
0,015% sind das wohl.
Und wenn ich das richtig gelesen habe , dann ist nur noch Firefox hintendran mit nem Patch.
Also lass die Kirche mal im Dorf.Und solange kein Patch da ist , werden die Developer angesprochen zu handeln :
Obviously, waiting for a browser fix isn’t ideal—so there are some things developers can do to protect local applications.
Here are our biggest pointers:
Implement PNA headers
Verify the HOST header of the request to protect against DNS rebinding attacks to localhost or 127.0.0.1.
Don’t trust the localhost network because it is “local”—add a minimal layer of authorization, even when running on localhost. Jupyter Notebook developers did a great job at this, adding a token by default.
Use HTTPS when possible.
Implement CSRF tokens in your applications, even if they are local.
Remember that browsers act as gateways, and they have routing capabilities to internal IP address spaces in many browsers. -
The figure below illustrates this rise.
-
Der Anstieg ist irre ! Vielen dank fuer den Hinweis!
-
@thomas-braun sagte in 0.0.0.0 Day - Schwere Lücke:
Der ioBroker (bzw. Adapter) reißt ja einige Dienste auf 0.0.0.0 auf.
wäre es denn bei diesen Adaptern möglich 0.0.0.0 gegen definierte IPs zu ersetzen?
Frage geht natürlich auch an @devs
-
Kann ich nichts zu sagen. So tief blicke ich da auch nicht rein.
-
@thomas-braun deswegen der Nachsatz
-
@homoran sagte in 0.0.0.0 Day - Schwere Lücke:
@thomas-braun sagte in 0.0.0.0 Day - Schwere Lücke:
Der ioBroker (bzw. Adapter) reißt ja einige Dienste auf 0.0.0.0 auf.
wäre es denn bei diesen Adaptern möglich 0.0.0.0 gegen definierte IPs zu ersetzen?
Frage geht natürlich auch an @devs
Setz es doch mit auf die Agenda fürs nächste Dev Meeting
-
wenn wir schon beim Thema Sicherheit sind, dann aber auch gleich den Admin auf https beschraenken...
-
@ilovegym sagte in 0.0.0.0 Day - Schwere Lücke:
wenn wir schon beim Thema Sicherheit sind, dann aber auch gleich den Admin auf https beschraenken...
der lauscht ja auch auf 0.0.0.0
-
@homoran said in 0.0.0.0 Day - Schwere Lücke:
@ilovegym sagte in 0.0.0.0 Day - Schwere Lücke:
wenn wir schon beim Thema Sicherheit sind, dann aber auch gleich den Admin auf https beschraenken...
der lauscht ja auch auf 0.0.0.0
Moment
Wenn ich den Artikel richtig lese geht es darum dass Browser keine OUTGOING connections mehr an die Adresse 0.0.0.0 senden sollen.Bei den Adaptern wird aber 0.0.0.0 als Wildcard "Lausch auf allen Adressen die das System anbietet" verwendet. Das ist auch lt. dem Artikel und genanntem RFC zulässig bzw. normal.
Der Fehler / das Sicherheitsloch besteht "nur" bei Browsern bzw. Code der in irgendeiner Form verbindungen aufbaut.
Bin zwar kein Netzwerkspezialist - aber nach meinem Verstäbdnis betrifft dieses Problem ioBroker maximal dort wo outgoind Verbindungen aufgebaut werden - NICHT aber dort wo es um die Auswahl der Interfaces geht.,
-
@ilovegym said in 0.0.0.0 Day - Schwere Lücke:
wenn wir schon beim Thema Sicherheit sind, dann aber auch gleich den Admin auf https beschraenken...
NEIN
Man kann darüber nachdenken den Default anders einzustellen. Aber wenn der ioBroker nicht von außen zugänglich ist dann bringt https außer einem erhöhten Aufwand absolut nichts. Das Verschlüsseln der Daten im LAN bringt nur dann mehr Sicherheit wenn jemand davon ausgehen muss, dass sein lokales LAN abgehört wird. Und der Zugriff selkbst wird durch https um nicht merh gesichert.
Nebenbei wünsche ich allen viiiiiel Spass dem durchschnittlichen User hier Zertifikate nahe zu bringen,
-
@mcm1957 sagte in 0.0.0.0 Day - Schwere Lücke:
Bin zwar kein Netzwerkspezialist
Bin ich auch nicht. Deswegen wollte ich auch eigentlich nichts mehr dazu beitragen, weil das nicht mein Gebiet ist.
Nur braucht es für derartige Verbindungen nicht zwingend einen Browser. Das kannst du auch über andere Geschichten anleiern. -
@thomas-braun said in 0.0.0.0 Day - Schwere Lücke:
Nur braucht es für derartige Verbindungen nicht zwingend einen Browser. Das kannst du auch über andere Geschichten anleiern.
Ja - natürlich. Jede Software die Verbindungen AUFBAUT (bzw. aufbauen kann) darf keine Verbindung zu 0.0.0.0 aufbauen bzw. Pakete dorthin senden. Insofern sind Adapter potenziell betroffen.
Aber die hier zitierten "listen on all interfaces 0.0.0.0) sind (m.E.) eine Sache. Listen sendet nicht sondern lauscht (no na :-). Und 0.0.0.0 ist hie rnur eine Wildcardbeschreibung und sicherheitsmäßig m.E. ident zu einem extra listen je Interface.
Also sehe ich hier keienrlei Grund für eine Panik oder großflächige Codeanpassungen.
Aber warten wir mal ab was Netzwerkspezialisten dazu sagen. @apollon77 hast du dazu mehr Fachwissen?
-
Wenn ich mir anschaue, welchen Diensten da Code untergejubelt werden konnte bzw. welchen nicht
Don’t trust the localhost network because it is “local”—add a minimal layer of authorization, even when running on localhost. Jupyter Notebook developers did a great job at this, adding a token by default.
gibt mir das zu denken.
-
@thomas-braun sagte in 0.0.0.0 Day - Schwere Lücke:
add a minimal layer of authorization
und das geht doch nur wenn man
@mcm1957 sagte in 0.0.0.0 Day - Schwere Lücke:
den Admin auf https beschraenken...
NEIN
würde.
ohne https kein auth, oder?Denn
@mcm1957 sagte in 0.0.0.0 Day - Schwere Lücke:
Nebenbei wünsche ich allen viiiiiel Spass dem durchschnittlichen User hier Zertifikate nahe zu bringen,
kannst du das IMHO auf einen Großteil der User ausdehnen
-
@homoran said in 0.0.0.0 Day - Schwere Lücke:
ohne https kein auth, oder?
Also nach meinem Verständnis kann man ein Authentifizierung (z.B. Username/Passwort) auch ohne https machen. Auch jestzt kannst du bei Admin einstellen, dass du nur mit Usernamen und Passowrt rein darfst - ganz ohne https. Und https selbst bringt keine Authentifizierung des Client mit (zumindest im Normalfall). Bei keiner der öffentlich lesbaren Webseiten die via https erreichbar sind authentifiziere ich ich mit meinem Browser in irgendeiner Weise. Unterschied ist nur, dass der Client prüfen kann ob die Webseite die er sieht die ist die er erreichen wollte. Dass das aber auch eher Theorie ist steht auf einem anderen Blatt. Oder prüfts du bei jedem Aufruf deiner Online Bank das Zertifikat? Ich nicht. Ergo kann eine Fakeseite mit irgendeinem Zertifikat (das es via Lets Encrypt ja trivial gibt) eine saubere https Verbindung herstellen. Das haben auch die Browserhersteller erkannt und google hat aus diesem Grund zB. das Schloss Symbol entfernt. https bedeutet nicht sichere Webseite sondern nur dass die Daten am Weg zum Webserver nicht mitgelesen werden können (von Firewalls im Firmenumfeld die die tls Verbinsung mittels privater Zertifikate aufbrechen mal abgesehen). Persönlich halte ich das Risiko dass jemand meinen Traffic im LAN zu einer Fake ioBroker Seite umleitet für sehr überschaubar (gering).
Siehe z.B.
https://www.golem.de/news/google-chrome-koennte-auf-https-schloss-verzichten-2107-158203.html -
@mcm1957 sagte in 0.0.0.0 Day - Schwere Lücke:
Wenn ich den Artikel richtig lese geht es darum dass Browser keine OUTGOING connections mehr an die Adresse 0.0.0.0 senden sollen.
So sehe ich das auf den ersten Blick auch. Verstehe den Ausgangspost in Kombination dazu überhaupt nicht. Wie hängt das zusammen?
@thomas-braun sagte in 0.0.0.0 Day - Schwere Lücke:
Der ioBroker (bzw. Adapter) reißt ja einige Dienste auf 0.0.0.0 auf. Wenn die dann auch noch als root laufen, prostmahlzeit.
Kannst Du mal bitte ein Angriffsszenario skizzieren und warum das ein Problem ist?
Wenn man einen Dienst auf
0.0.0.0hören lässt, heißt das doch einfach nur, dass aus jedem IP-Adressebereich / von jedem Interface die Verbindungen angenommen werden. Die meisten hier werden wohl eh nur ein Interface am System haben. Macht also keinen Unterschied was man dort einstellt (für 99,999% der Nutzer hier). -
@haus-automatisierung said in 0.0.0.0 Day - Schwere Lücke:
Kannst Du mal bitte ein Angriffsszenario skizzieren und warum das ein Problem ist?
Ich glaube da besteht ein Missverständnis zwischen LISTEN ON ALL INTERFACES [0.0.0.0] und einem Get von der Adresse 0.0.0.0 (http://0.0.0.0/ShowData)
Kann aber auch sein, dass ich völlig blind bin.
-
Remote Code Execution hört sich jetzt nicht so lustig an.
