[English]Sicherheitsforscher haben offen gelegt, dass Hacker einen seit 18 Jahren bekannten, alten Fehler in Safari, Chrome und Firefox ausgenutzt haben, um in private Netzwerke einzudringen. Die als "0.0.0.0 Day" bezeichnete Sicherheitslücke ermöglicht es böswilligen Websites, die Browsersicherheit zu umgehen und mit Diensten zu interagieren, die im lokalen Netzwerk einer Organisation laufen. Dies kann zu unautorisiertem Zugriff und Remotecodeausführung auf lokalen Diensten durch Angreifer außerhalb des Netzwerks führen. Die Browserhersteller beginnen nun, diese Adresse zu blockieren.
Anzeige
Ein Team von Sicherheitsforschern des Unternehmens Oligo Security ist auf eine gravierende Schwachstelle in quasi allen Browsern (Safari, Chrome, Firefox) gestoßen. Die als "0.0.0.0 Day" bezeichnete Sicherheitslücke ermöglicht es böswilligen Websites, die Browsersicherheit zu umgehen und und mit Diensten zu interagieren, die im lokalen Netzwerk eines Unternehmens laufen. Dies kann zu unbefugtem Zugriff und Remotecode-Ausführung auf lokale Dienste durch Angreifer außerhalb des Netzwerks führen.
Das Problem lässt sich auf die uneinheitliche Implementierung von Sicherheitsmechanismen in verschiedenen Browsern und die fehlende Standardisierung in der Browserbranche zurückführen, schreiben die Sicherheitsforscher. Infolgedessen kann die scheinbar harmlose IP-Adresse 0.0.0.0 zu einem mächtigen Werkzeug für Angreifer werden, um lokale Dienste auszunutzen. Das umfasse auch Dienste, die für Entwicklung, Betriebssysteme und sogar interne Netzwerke verwendet werden.
Die Oligo-Forscher haben entdeckt, dass öffentliche Websites mit Diensten im lokalen Netzwerk (localhost) kommunizieren und möglicherweise beliebigen Code auf dem Host des Besuchers ausführen können. Dazu senden Sie HTTP-Anfragen an die Adresse 0.0.0.0 statt an localhost/127.0.0. Das Problem ist aber wohl schon 18 Jahre lang bekannt. Die Auswirkungen des 0.0.0.0 Day sind weitreichend – und die Schwachstelle wird in Kampagnen wie ShadowRay aktiv ausgenutzt.
Die Entdeckung wurde im April 2024 an die betreffenden Browser-Entwickler gemeldet. HTTP-Anfragen an 0.0.0.0 sollen nun mittels eines Request for Comment (RFC) in die Sicherheitsstandards aufgenommen werden. Entsprechende HTTP-Anfragen sollen nicht mehr als Ziel-IP-Adresse zugelassen werden. Die aktiv gepflegten Browser (Chrome, Firefox, Safari und ihre Derivate) werden bald 0.0.0.0 blockieren, schreiben die Oligo-Leute.
Anzeige
Google beginnt bereits den Zugriff auf 0.0.0.0 ab Chromium 128 blocken und will diese Änderung in den nächsten Versionen schrittweise einführen und sie mit Chrome 133 abschließen. Auch Apple hat wohl Änderungen am WebKit vorgenommen, so dass Browser die Adresse nicht mehr aufrufen können.
Nur beim Firefox gibt es noch keine entsprechende Blockade (ein Fix ist in Arbeit), schreiben die Oligo-Forscher, und ergänzen, dass Firefox hat den privaten Netzwerkzugang (Private Network Access, PNA) nie eingeschränkt habe. Es sei also technisch gesehen immer erlaubt gewesen und aus dieser Perspektive ist "nichts zu beheben".
Laut den Sicherheitsforschern wurde dieses problematische Verhalten dem Mozilla-Team bereits 2006 in einem Bug-Report gemeldet. Es betrifft aber nur Linux und macOS als Plattform, Windows scheint sicher zu sein. Inzwischen sehen die Experten einen sprunghaften Anstieg der Versuche, PNA von Webseiten zu verwenden. Details sind diesem Blog-Beitrag zu entnehmen.
Anzeige
Das Thema Bug-Report könnte man auch mal aufgreifen. Ich weiß nicht wie da die Erfahrungen bei anderen Leuten ist.
Es ist bei den großen Playern teilweise extrem schwierig mal irgendwelche Fehler zu melden, gerade als regulärer Nutzer.
Man findet keine Adressen, der reguläre Support ist unfähig. Wenn man das Impressum anschreibt kommt noch eine relativ intelligente Antwort zurück und bedanken sich, dass man den Fehler gemeldet hat. Man soll ihn aber bitte unter Link XY selber melden oder erst mal Software zum Melden installieren. Link XY enthält dann aber gar kein entsprechendes Meldeoption, man darf dann wieder suchen.
Deshalb frag mich auch immer, was "gemeldet" heißt. In vielen Fällen ist es offensichtlich, dass nichts passiert oder man den "falschen" Weg gewählt hat.
"ordentliche" Firmen sollten einen Link anbieten:
Create a text file called security.txt under the .well-known directory of your project.
also firma.tld/.well-known/security.txtx
Der Vorschlag ist auf "securitytxt.org"
>> Es ist bei den großen Playern teilweise extrem schwierig mal irgendwelche Fehler zu melden, gerade als regulärer Nutzer.
Für Mozilla Produkte kannst du das über Bugzilla melden:
https://support.mozilla.org/de/kb/mozilla-bug-report-oder-feature-request-erstellen
Ist einfach und findet auch Beachtung bei Mozilla. Es muss halt nur in Englisch sein.
Ich würde bei Firmen, wo ich nicht sofort einen einfach zugänglichen Security-Kontakt finde, das BSI vorschicken. Ja, ernsthaft:
"Sollten IT-Produkte, IT-Systeme oder IT-Dienstleistungen von Herstellern bzw. Produktverantwortliche außerhalb der Bundesverwaltung betroffen sein, sollten Sie die Schwachstelle zuerst an den Hersteller bzw. Produktverantwortlichen melden. Wenn diese nicht auf Ihre Schwachstellenmeldung reagieren oder der Abbruch des CVD-Verfahrens droht, können Sicherheitsforschende sich an das BSI wenden."
https://www.bsi.bund.de/DE/IT-Sicherheitsvorfall/IT-Schwachstellen/it-schwachstellen_node.html
Für Österreich dasselbe Spiel mit CERT.at. Schweizer:innen können sich an das BACS wenden, https://www.ncsc.admin.ch
Bei Bugs die offensichtlich die Sicherheit beeinflussen gehe ich total mit.
Du hast aber auch Programfehler, die teilweise nur "sehr komisch" sind und/oder "nur" das Produkt unbrauchbar machen.
Erstere könnte und kann man ggf. noch über den Security-Kontakt melden, da kann man den Fehler auch entsprechend formulieren. Nach dem Motto: "In Situation XY steigt plötzlich der RAM-Bedarf an, ohne erkennbaren Grund. Solange man die Ursache kennt kann es theoretisch alles sein, also auch was Sicherheitsrelevantes". Die "reagieren" dann meist schnell und "prüfen" das dann, aber verlieren dann meist auch schnell die Lust. Am Ende wird der Fehler nicht behoben, wurde vmtl. auch gar nicht untersucht.
Das große Problem was ich sehe, hinter jedem BUG könnte theoretisch auch ein größeres Problem stecken. Im Regelfall wird der DAUs oder der halbwegs versierte Nutzer zwar das Problem eingrenzen können, aber der Hersteller muss es dann genauer untersuchen. Wenn man aber derartige Probleme nicht melden kann ODER der Support zu dumm ist ODER die Probleme dann nicht verfolgt werden, dann deckt man ja auch nicht per Zufall Sicherheitsprobleme auf.
>> Es ist bei den großen Playern teilweise extrem schwierig mal irgendwelche Fehler zu melden, gerade als regulärer Nutzer.
Ich kann Dir und jedem anderen nur nahelegen, bei deutschen Unternehmen keine Bugs zu melden wenn Du keine Erfahrung damit hast oder das nicht regelmäßig und professionell im Auftrag ausführst.
Du riskierst je nach Fall unschöne Post von Anwälten mit EV und saftigen Kostennoten. Wenn Du selbst programmierst sogar wettbewerbrechtliche Konseqzenzen wenn Du einem anderen Softwarehersteller an den Karren pinkelst. Das geht bis hin zu Ermittlungen eines LKA wegen angenommener Computerkriminalität und plötzlichen Hausdurchsuchungen in der Frühe.
Nutze den CCC als Ansprechpartner.
Die Erfahrung kann ich nur bestätigen. Ich hatte in meinem Browser immer die bevorzugte Sprache deaktiviert (Weil Ebay (zumindest damals) die Angebote nach bevorzugter Sprache zensiert – Man sieht viele Angebote sonst gar nicht mehr in den Ergebnissen, egal, was man tut und egal welches Ebay man besucht. Ebay sagt, es seien angebliche Zensuren basierend auf Spracheinstellung begründet mit Sicherheit, aber den dubiosen und oft gefälschten Chinamüll sieht man trotzdem. Es geht hier übrigens nicht mal um was verbbotenes oder so, sondern nur um Mineralien und Steine.).
Das Fehlen der bevorzugten Sprache hat den Strato Webmailer mangels vordefinierter Default-Sprache auf Strato.DE am Laden gehindert. Der tat dann schlicht und einfach gar nix mehr außer 3 blinkende Ladepunkte zu zeigen. Hab das an Strato gemeldet und eine überaus qualifizierte Person sagte, ich solle meine Browsereinstellungen ändern. Nach ca. 3 Jahren hat man das dann auch tatsächlich mal geschafft, das zu beseitigen.
Windows ist hier ausnahmsweise mal sicher, denn es verwirft IP Pakte an 0.0.0.0 da sie nicht Teil der IP-Adress-Spezifikation ist. Diese Adresse als Ersatz für localhost oder 127.0.0.1 zu nehmen, ist in den TCP/IP-Spezifikationen eigentlich nicht vorgesehen, dass (manche) unixoide OS das dennnoch tun, ist out of spec. Gestern gab es wo anders schon eine Sicherheitsmeldung zu dem Thema, ich müsste erst im Browserverlauf suchen wo das war, da gab es nähere Details zu 0.0.0.0 unter Windows, MS hat hier einfach mal nur vorbildlich gehandelt, kommt selten vor, sollte man aber anerkennen.
Tja, unter Windows wäre das nicht passiert.
Sorry, das musste einfach sein :)
Bitte nicht schon wieder :-(
Langsam reicht es – und nervt auch…
so wie die Linux/OpenSource Jünger? Tja schon Scheiße das eigene Gift zu trinken ;-P
>>> … 0.0.0.0 … nicht Teil der IP-Adress-Spezifikation <<<
Würden Sie bitte Rücksicht auf hier mitlesende Auszubildende nehmen, statt hier (bestenfalls) Halbwahrheiten zu verbreiten? Selbstverständlich ist 0.0.0.0 Teil der Spezifikation, s. RFC 1122 Abschnitt 3.2.1.3 Buchstabe (a).
Das hier?
(a) { 0, 0 }
This host on this network. MUST NOT be sent, except as
a source address as part of an initialization procedure
by which the host learns its own IP address.
See also Section 3.3.6 for a non-standard use of {0,0}.
Hat dein Azubi "MUST NOT be sent" gelesen. "MUST NOT" ist im Englischen ein Ausdruck, dass etwas strengstens verboten ist – das ist mit britischer höflichkeit ausgesprochen noch eine Stufe höher wie "it is forbidden to". Googelt man weiter, findet man die wahre Bedeutung von 0.0.0.0, hier ein paar Fundstellen (Google Suchbegriff "using 0.0.0.0 for localhost") :
0.0.0.0 has a couple of different meanings, but in this context, when a server is told to listen on 0.0.0.0 that means "listen on every available network interface". The loopback adapter with IP address 127.0.0.1 from the perspective of the server process looks just like any other network adapter on the machine, so a server told to listen on 0.0.0.0 will accept connections on that interface too.
0.0.0.0 (in this context, when binding a service) is the unspecified address, essentially meaning any address on any interface on this host. That address cannot be used in any other way, neither as source nor as destination in an actual packet.
Auf Empfängerseite bedeutet 0.0.0.0, nimm alles entgegen egal von wo es kommt, evtl. sogar egal für welche IP-Adresse es bestimmt ist. Aber als Zieladresse ist es nicht definiert.
Kannst auch das hier mal lesen: https://medium.com/@davedash/what-is-0-0-0-0-versus-localhost-16aacf0e8edc
—
Noch eine Erklärung auf Deutsch
Die Browser verwenden 0.0.0.0 dabei ähnlich wie localhost/127.0.0.1 – nur eben mit dem Unterschied, dass Sicherheitsroutinen beim Aufruf von 127.0.0.1 dafür sorgen, dass keine problematischen Codes eingeschleust werden können. Bei der Verwendung von 0.0.0.0 fehlen diese, da die Adresse eigentlich nicht zum normalen Adressraum des Internetprotokolls gehört.
https://winfuture.de/news,144389.html
Es gibt einen extra RfC in dem diese Begriffe:
MUST, MAY und SHOULD … genau definiert werden.
Das ist klare Syntax, keine sprachliche Marotte.
Wie ja bei anderen Gesetzen im RL auch üblich.
Die RfC sind mitnichten Gesetze. Ja, die Konsequenzen, wenn man sich nicht an die RfC hält, können weitreichender sein als das bei Gesetzen der Fall ist, aber es sind dennoch keine Gesetze.
Ein Gleichnis ist keine Gleichsetzung, überlesen Sie das "andere" einfach.
Auch Jon Postels Robustheitsprinzip "Be liberal what you accept, be conservative in what you send" ist kein Gesetz; es kann bei FEHL-Interpretation der IPv4-Adresse 0.0.0.0 als 127.0.0.1 bzw. des IPv4-Subnetzes 0.x.y.z als 127.x.y.z auf Senderseite und fehlender Prüfung beim Empfänger "hübsche" Folgen haben.
Das sagt Wikipedia: https://de.wikipedia.org/wiki/0.0.0.0
Also haben am Ende doch irgendwie beide recht? Die IP-Adresse 0.0.0.0 ist Teil der Spezifikation, erfüllt aber eine spezielle Funktion und ist nicht routing-fähig.
WIKIPEDIA, die BILD des INTERNET
Hier das originale RFC zum Nachlesen ->
https://datatracker.ietf.org/doc/html/rfc1122
1 +
0.0.0.0 MUST NOT be sent als Teil der Spezifikation auszulegen ist vielleicht richtig, aber eigenwillig.
Das steht da wortwörtlich so in der RFC so drin. Obiges Zitat hab ich mir nicht ausgedacht. Und MUST NOT wurde sogar von den Autoren dort in Großbuchstaben geschrieben. Wie und was will und kann man da noch dagegen argumentieren, es steht da Schwarz auf Weiß, es sei denn man hat ein schwarzes Browser-Theme…
FWIW: "MUST"/"SHOULD"/… in all-caps ist Standard in den RFCs.
Meine Antwort bezog sich auf Anonym und seine mitlesenden Azubis. Nicht, dass das falsch rüberkam. Seine Auslegung der Spezifikation finde ich etwas seltsam.
Weitere Anwendung z.B. bei Filtern:
– 0.0.0.0/0 – alle Addressen
– 0.0.0.0/8 – Bogon
– 0.0.0.0/32 – 0.0.0.0 als einzelne Adresse
Übrigens denke ich, dass RFC 1122 die 0.0.0.0 als Zieladresse in einem IP-Paket meint. Wenn ich unter Linux ein "ping 0.0.0.0" starte, wird daraus nicht ein IP-Paket mit der Zieladresse 0.0.0.0., sondern es wird an 127.0.0.1 geschickt.
Laut diversen Sachen die ich gelesen habe, wird es nicht an 127.0.0.1 geschickt, sondern es wird 127.0.0.1 und all seine Kontrollmechanismen und Filter herum, darüber sind also Sachen möglich, vor denen 127.0.0.1 schützen würde.
Die Softwareentwickler der betroffenen Webbroswer verdienen einen Grosse-Halle-voller-Leute-Gruppen-Facepalm. Und die vom Firefox einen doppelten.
Hier ein uBlock Filter für all die ungeschützten Mitleser hier!
||0.0.0.0^$important,third-party
||[::]^$important,third-party
Genießt das Wochenende, es wird warm!
Merci dafür und auch dir ein schönes WoE!
Ich habe mir heute uBlock einmal näher angesehen. Noch blicke ich so gar nicht durch, und im Vergleich zu NoScript scheint es auch deutlich komplizierter für den normalen und auch erfahrenen Anwender zu bedienen sein.
Es ist auch eine grösserer Funktionsumfang:
NoScript kann die Scripte von Hosts in (Sub)Domains zu ladenden Scripte blockieren, uBlock so ziemlich alle Elemente einer Seite (inkl. Laden von Scripts).
Und natürlich bedeutet "mehr Funktionalität" auch zwingend "höhere Komplexität", zumindest soweit die Funktionalität für den User konfigurierbar bleiben soll.
Schon wenn Sie sich für den Anfang nur ein paar Filterlisten heraussuchen haben sie einen Zugewinn, von da aus kann man ja je nach Zeit, Interesse und Lust verfeinern.
Don't trust the localhost network because it is "local"—add a minimal layer of authorization, even when running on localhost.
"Google Chrome, Mozilla Firefox und Apple Safari planen Updates, um das Problem zu beheben. Bis diese Patches vollständig implementiert sind, empfiehlt Oligo Security, zusätzliche Sicherheitsmaßnahmen zu ergreifen, wie die Verwendung von PNA-Headern (Private Network Access), die Überprüfung von HOST-Headern und die Verwendung von HTTPS- und CSRF-Tokens (Cross-Site Request Forgery)." Quelle: notebookcheck
Kann das mal bitte jemand verständlich erläutern, für mich sind das nämlich böhmische Dörfer? Nachfrage an alle, die besser Bescheid wissen: Ist die Lücke für Desktop-Rechner, die nicht an ein Netzwerk angeschlossen sind, sondern bloß über den Router ins Internet gehen, relevant? Und was kann der unbedarfte User, der kein IT-Experte ist, tun?
Das ist in so fern relevant, dass lokal laufende Webdienste oder Komponenten auf dem Client angegriffen werden können. Mir fällt da zuerst das BAe Portal für Gerichte und Anwälte ein, wo eine gammelige Java App am Clienten einen solchen lokalen Webserver zur Authentifizierung via Browser-Plugin nutzte und über diesen Vektor damit auf die Füsse gefallen ist. Zahlreiche (Electron) Apps wie Editoren, Passwort-Manager und Videokonferenzsystem-Clients machen vergleichbaren Schmus. Mir ist da der Zoom-Client für den Mac in Erinnerung geblieben, der selbst bei Deinstallation den lokalen Webserver weiter laufen ließ.Entwickler Maschinen, mit lokal laufenden Datenbank-Servern, Containern und Netzwerkdiensten sind ebenfalls bedroht, da diese über diese Lücke für ein Javascript aus dem Internet exponiert sind. Nur einige Beispiele.
> Und was kann der unbedarfte User, der kein IT-Experte ist, tun?
Nicht viel, vielleicht keine Schmus-Software installieren, die auf Deinem Rechner lokale Dienste oder Server aufmacht. Den meisten ist aber die Funktionsweise von Software eher nicht bekannt.
Es gibt einen extra RfC in dem diese Begriffe:
MUST, MAY und SHOULD … genau definiert werden.
Das ist klare Syntax, keine sprachliche Marotte.
Wie ja bei anderen Gesetzen im RL auch üblich.
Was ich nicht verstehe:
Warum ist es ein Problem, das beim Client gelöst werden muss.
Was passiert überhaupt?
Ich kenne da so einen DNS Host Eintrag, der auf 127.0.0.1 auflöst.
Die größte Warensammlung….
Es funktioniert nur unter HTML Programmern, die einen Webserver lokal laufen haben und dieses Ei nicht Kennen,klar.
Aber warum sollte der Webbrowser 127.0.0.1 verbieten?
Und soweit ich weiß, ist 0.0.0.0 das Ergebnis, wenn es für eine Route keine Lösung gibt.
Also ein Problem des Routings…
Einige #Client-Module überwachen einen #TCP/#UDP-#Port auf Upgrade-Befehle mit 0.0.0.0:45xxx anstatt mit 127.0.0.1:45xxx
#Windows-#Rechner sind nicht betroffen, da #Microsoft sich dafür entschieden hat, 0.0.0.0 in seinem #Betriebssystem komplett zu blockieren.
Angegriffen werden können über die #Schwachstelle aber nur Systeme auf Basis von #MacOS und #Linux.
Auch Handy sind nicht ohne Probleme 😉
Genutzte #Browser auf diesen #Systeme haben somit ein Problem.
#RFC 1122
Es verbietet 0.0.0.0 als Zieladresse in #IPv4 und erlaubt es nur unter bestimmten Umständen als Quelladresse, wie beim Verwendung in #DHCPDISCOVER-Paket beim #DHCP-Handschlag, wenn eine #IP zum ersten Mal zugewiesen wird. 0.0.0.0 wird manchmal in /etc/hosts-Dateien verwendet, um bestimmte #Domains zu blockieren (als #Adblock dienend) oder, wenn sie in #Netzwerkrichtlinien verwendet werden, sind die #CIDR-Blöcke 0.0.0.0/32-alle IPs erlaubt.
0.0.0.0 wird manchmal in /etc/hosts-Dateien verwendet, um bestimmte Domains zu blockieren (als Adblock dienend) oder, wenn sie in Netzwerkrichtlinien verwendet werden, sind die CIDR-Blöcke 0.0.0.0/32-alle IPs erlaubt.
#Firefox:
Hier ist eine Lösung im Gange und #Mozilla hat die #Fetch-Spezifikation geändert, um 0.0.0.0 zu blockieren.
Auch die #Defcon #Hacking #Konferenz, diese findet vom 8. bis 11. August in Las #Vegas statt, wird über diese #Sicherheitsfragen die seit 2006 bekannt ist, sprechen.
https://defcon.org/
…kleine Korrektur:
der CIDR-Block, der alle IPs umfasst, ist 0.0.0.0/0
/32 ist ein single host.