mgrube/cve-2019-9673Write-up
HINWEIS: Ich habe diesen Fehler vollständig an das Freenet-Team gemeldet und mit ihnen zusammengearbeitet, um ihren Patch zu verifizieren. Der Patch ist jetzt in der neuesten Version von Freenet bereitgestellt.
Ich habe kürzlich eine Sicherheitslücke in Freenet entdeckt, die es einem Angreifer ermöglichen könnte, ein Ziel zu deanonymisieren oder schädliche Dokumente über Freenet zu senden.
Diese Sicherheitslücke betrifft Freenet-Nutzer, die Firefox als ihren Browser verwenden. Sie ermöglicht Deanonymisierung und anderes schädliches Verhalten auf dem Computer eines Nutzers. Sie ist in allen Versionen bis einschließlich 1483 vorhanden.
Dieser Exploit nutzt eine Diskrepanz zwischen Firefox und Freenet bei der Behandlung von MIME-Typen aus. Freenet wird mit Filtern für viele verschiedene Inhaltstypen ausgeliefert – es wurde viel Aufwand betrieben, um sicherzustellen, dass nur wohlgeformte und nicht-skriptbasierte Inhalte ohne eine Reihe von Warnungen an den Nutzer gerendert werden können.
Freenet leistet im Allgemeinen gute Arbeit bei der korrekten Behandlung von Daten und gibt dem Nutzer die Möglichkeit festzulegen, ob er eine andere Behandlung wünscht.
Firefox hingegen ist bei der Bestimmung des MIME-Typs einer Datei etwas differenzierter. Genauer gesagt, wie hier dokumentiert. Der größte Teil des auf dieser Seite dokumentierten Prozesses entzieht sich der Kontrolle eines Angreifers, insbesondere wenn er über Freenet angreifen muss. Eine Sache, die innerhalb der Kontrolle eines Angreifers liegt, ist jedoch der MIME-Typ der eingefügten Daten. Beim Einfügen von Daten in das Freenet-Netzwerk kann ein Nutzer den MIME-Typ angeben – wenn dieses Feld leer gelassen wird, werden die Daten als application/octet-stream behandelt und erhalten die gesamte vorgesehene Behandlung in Bezug auf Warnungen.
Wenn wir uns jedoch den HTTP-Abschnitt der Mozilla-Dokumentation ansehen, stellen wir fest, dass Firefox tatsächlich eigene Vermutungen über den MIME-Typ der Daten anstellt, wenn bestimmte Bedingungen von der Anwendung, die den Inhalt ausliefert, nicht erfüllt werden. Insbesondere wenn der Content-Encoding-Header von einer Anwendung nicht gesendet wird, führt Firefox tatsächlich ein MIME-Sniffing durch, um zu entscheiden, was damit geschehen soll. Wenn der erste Datenblock kein Text ist, behandelt Firefox die Datei als den MIME-Typ, der durch die Dateierweiterung angegeben wird.
Es stellt sich heraus, dass Freenet diesen Header in seinen Antworten nicht gesendet hat, was es uns ermöglicht, dies in etwas Brauchbares zu verwandeln. Da unsere Daten als MIME-Typ text/plain eingefügt werden können, was offensichtlich keine ausgefeilte Filterung erhält, aber als jeder MIME-Typ ausgeliefert werden kann, der durch die Dateierweiterung angegeben wird, haben wir nun einen Weg, ein ungefiltertes HTML-Dokument (oder PDF oder .docx...) auszuliefern. Das ist eine große Sache, denn normalerweise wird empfohlen, alle gefährlichen Inhalte in einen Ordner oder einen temporären Bereich herunterzuladen und außerhalb des Browsers zu öffnen.
Dies ist ein kurzes Video des funktionierenden Exploits – in diesem Fall zur Auslieferung einer ungefilterten HTML-Datei.
Für ein funktionierendes Beispiel installieren Sie Version 1483 oder früher und navigieren Sie zu:
Wer zu Hause mitmachen möchte, kann die neueste verwundbare Version von Freenet hier erhalten.
Wie könnten wir das also in der realen Welt nutzen?
Es zeigt sich, dass Freenet die Datei als den durch ihre Erweiterung angegebenen Typ behandeln wird, wenn Sie auf einer Seite, die der Nutzer bereits durchstöbert, innerhalb von Freenet auf Ihre schädlichen Inhalte verlinken. Freenet wird erkennen, dass der erste Teil unserer Daten binär ist, und den Nutzer warnen, dass unsere Datei schädlich ist.
:(
Das bedeutet, dass wir, wenn unser Ziel unsere schädliche Seite mit aktiviertem JS betrachten soll, extern darauf verlinken müssen. Das ist eigentlich in Ordnung, da die beliebtesten Nachrichtensysteme von Freenet nicht über Freenets Web-Proxy laufen.
Wenn beispielsweise die Demo-URI aus diesem Dokument innerhalb von FMS verlinkt würde, gäbe es keine zusätzliche Prüfung und wir könnten unsere Payload ausführen.
Um eine Reihe von Freenet-Nutzern zu deanonymisieren, wäre es nur nötig, Inhalte mit einem interessanten Titel zu erstellen, eine Datei einzufügen, deren erster Datenblock binär ist, und dann eine überzeugende Webseite zu erstellen, die im Hintergrund stillschweigend IP-Adresse und Aktivitäten meldet. Kombinieren Sie dies mit einem Werkzeugsatz wie dem BeEF-Framework, und Sie haben einige interessante Möglichkeiten.
Natürlich können wir dies auch als Vektor nutzen, um eine schädliche PDF-, .docx-Datei oder andere Dateien auszuliefern und einen dauerhafteren Zugang zum Computer des Nutzers zu erlangen.
Die Behebung dieses Fehlers ist recht einfach: Von nun an wird FProxy bei der Auslieferung von Inhalten immer den HTTP-Header Content-Encoding übergeben. Dieser Header weist den Firefox-Browser an, MIME-Typen explizit so zu behandeln, wie sie von FProxy definiert werden. Infolgedessen werden Daten vom Typ text/plain immer als Klartext gerendert und nicht als anderer MIME-Typ behandelt.
Dieser Fehler war alles in allem recht einfach – dennoch hatte er das Potenzial, die Funktionalität von Freenet erheblich zu beeinträchtigen. Die Prüfung von MIME-Typen ist wirklich wichtig, und eine wichtige Lehre aus diesem Fehler ist, dass MIME-Typen nicht immer konsistent behandelt werden, wenn Daten von einem Programm an ein anderes übergeben werden.
Fügen Sie einfach einige Daten mit dem MIME-Typ text/plain in Freenet ein, wobei der erste Block nur binäre Daten enthält. Firefox wird sie als den Typ behandeln, den die Dateierweiterung angibt, und sie wird dem Nutzer direkt zugestellt, anstatt von Freenet gefiltert zu werden. Senden Sie sie an Ihre Opfer über FMS oder Frost. Sammeln Sie ihre IP-Adressen oder bringen Sie sie dazu, eine binäre Payload auszuführen. Profit!
