[Info] [Update] Telefonie-Missbrauch (anscheinend doch) Massenhack von AVMs Fritzboxen

[derneueFritz]

eben gerade auf einer FB von KD vor Ort gesehen: Firmware steht jetz auf 6.04., vor kurzem 5.56.
Würde gern die Ferwartung wieder auf machen.
Ist denn mit dem update diese Shell-Sicherheitslücke nun endgültig gestopft?!

 

[HabNeFritzbox]

hph@ Kannst doch trotzdem was mehr Infos rausgeben, ob z.B. Logindaten verwendet wurden von irgendwo her, oder die gar nicht nötig waren.

Oder Tipp welches Modul oder so man entfernen sollte, wer kein Update machen möchte oder ähnliches.

derneueFritz@ In 6.03 bzw. den 6.04 Betas sind laut Changelog gefixt wurden.

 

[koyaanisqatsi]

@HabNeFritzbox: Die URL Encodete Injection die du hier gepostet hast, ist in erster Linie auf CGI gemünzt.
Denn php-cgi ist zwar PHP aber wird als CGI ausgeführt um PHP zu interpretieren.
Und CGIs gibt es auf der Fritz!Box. Und LUA wird auch als CGI ausgeführt?!

Ja wird es...

deepbase # l cgi-bin/
total 245
drwxr-x---    2 root     root           151 Feb  7 16:06 ./
drwxr-x---    8 root     root            84 Feb  7 16:06 ../
-rwxrwxrwx    1 root     root         23448 Feb  7 16:06 capture_notimeout*
-rwxrwxrwx    1 root     root         19344 Feb  7 16:06 cgiMain*
-rwxrwxrwx    1 root     root         86140 Feb  7 16:06 firmwarecfg*
[b]-rwxrwxrwx    1 root     root         50648 Feb  7 16:06 luacgi*[/b]
-rwxrwxrwx    1 root     root         18920 Feb  7 16:06 nasupload_notimeout*
lrwxrwxrwx    1 root     root            22 Feb  7 16:06 system_status -> /usr/bin/system_status*
-rwxrwxrwx    1 root     root         10304 Feb  7 16:06 tr064cgi*
-rwxrwxrwx    1 root     root         24520 Feb  7 16:06 webcm*
-rwxrwxrwx    1 root     root         15456 Feb  7 16:06 webtrace*

...dann ist eine injection wie bei PHP auch auf LUA (login.lua?) denkbar.

 

[HabNeFritzbox]

Jo, mir schon teils klar, die FB reagiert ja auch auf fritz.box/cgi-bin und leitet auf Startseite um, so wie es sein sollte wenn. Wenn man anderes abruft, kommt eine Datei nicht gefunden Seite.

Und httpd bzw. Apache laufen ja unter anderem mit FastCGI Modul.

 

[hph]

Ist denn mit dem update diese Shell-Sicherheitslücke nun endgültig gestopft?!

Ich kenne dein FB Modell nicht und daher kann ich zu deinem Fall nichts sagen. Wende dich am besten an AVM oder deinen Provider.
Ich selbst habe die Lücke auf einer 7270 v3 nachvollzogen. Dort wurde der Bug mit dem Image FRITZ.Box_Fon_WLAN_7270_v3.74.05.54.image gefixed: Mein Shellcode funktionierte nicht mehr. Allerdings habe ich noch nicht genauer nachgeschaut, ob die Lücke auch gründlich gestopft wurde.

@HabNeFritzbox: Der Angriff kommt völlig ohne Kenntnis der Logindaten aus. Eine sichere Lösung auf anfälligen Boxen ist nach wie vor das Abschalten der Fernwartung. Allerdings ist diese Lücke dann immer noch aus dem LAN ausnutzbar.

 

[koyaanisqatsi]

...und nach wie vor: Keine Freigaben auf die Standardports 21, 80, 443 u.s.w.

 

[pumana]

Nein, PHP-Dateien habe ich überhaupt noch nie auf einer FB gesehen (habe aber auch nur eine 7270). Zumindest so viel kann ich noch verraten: Modelle, bei denen die Fernwartung über htaccess abgesichert ist (z.B. 7112), scheinen nicht betroffen zu sein.

Diese Behauptung widerspircht der Tatsache, dass AVM Updates für 7170 herausgebracht hat. Dort ist der Fernzugang auh per htaaccess gesichert, trotzdem scheint es, dass die Lücke da ist.

 

[hph]

Nach genauerem Studium des Fixes auf der 7270 v3 bin ich der Meinung, dass es wohl nicht mehr möglcih ist _diese_ Vulnerability auszunutzen. Nach weiteren Schwachstellen habe ich nicht gesucht. Vielleicht mache ich das eines Tages mal, wenn ich mehr Zeit habe.

Diese Behauptung widerspircht der Tatsache, dass AVM Updates für 7170 herausgebracht hat. Dort ist der Fernzugang auh per htaaccess gesichert, trotzdem scheint es, dass die Lücke da ist.

Pardon. Mein Fehler! Die Schwachstelle scheint wohl in allen Modellen zu existieren. In den Modellen, in denen jedoch Fernwartung per htaccess gesichert ist, ist die Lücke nur aus dem LAN ausnutzbar (wo kein htaccess benutzt wird). Vermutlich daher das Update für die 7170.

 

[andilao]

Da bin ich mal erleichtert, weil ich noch eine 3170 im Ferienhaus betreibe und für einen VPN-Zugang der Aufwand zu groß wäre. Da ich den Zugang per LAN/WLAN auch mit htaccess-HTTPS aktiviert habe (per "users_only_for_https = no"), dürfte die Lücke ja auch lokal nicht nutzbar sein.

 

[jack380]

Habe bei mir eh keinen Fernzugriff aktiviert, bin aber überrascht, dass es noch ein upgrade für die fb 7170 gibt.

Kann es beim upgrade zu Problemen kommen wenn man ein paar Modifikationen installiert hat? (FritzLoad, ext file system, busybox ...)

Würde sehr ungern alle Einstellungen verlieren.

 

[RalfFriedl]

@HabNeFritzbox: Der Angriff kommt völlig ohne Kenntnis der Logindaten aus. Eine sichere Lösung auf anfälligen Boxen ist nach wie vor das Abschalten der Fernwartung.

Natürlich kommt der Angriff ohne Kenntnis der Logindaten aus. Dass man mit Logindaten auf die Box zugreifen kann, wäre ja keine Überraschung.

 

[HabNeFritzbox]

Anfangs stand ja noch in den Medien, dass es wohl mit den Daten versucht wurde welche im Umlauf sind und das BSI gewarnt hatte. Dieses hat sich ja hier mit der Zeit geklärt, und trifft ja nicht zu.

 

[hph]

Kann es beim upgrade zu Problemen kommen wenn man ein paar Modifikationen installiert hat? (FritzLoad, ext file system, busybox ...)

Das kann ich nicht beurteilen, da ich den Firmware-Upgrade-Prozess nicht genau kenne und nicht weiß, wie und wo sich die Modifikationen einnisten.

 

[Christoph]

Eine kleine, aber wichtige Bitte:

Zum Schutze derer, die ihre Box noch nicht upgedated haben, aber auch, um es den Kriminellen oder auch Trittbettfahrern nicht zu erleichtern, vermeidet bitte entsprechende Details hier.


Besten Dank!

 

[HabNeFritzbox]

Genaue Anleitung, bestimmtes Modul oder ähnliches wurde ja nicht konkret genannt, von daher doch alles im grünen Bereich.

 

[hph]

@Christoph: Genau aus diesem Grund habe ich heise informiert und nicht direkt einen full-disclosure in meinem Blog geposted. Auf die Weise kann heise, als unabhängige Institution, die Lücke prüfen und bestätigen, dass die Sicherheitslücke mit entsprechenden Patches gestopft wurde. Ebenfalls aus diesem Grund habe ich so wenig Information wie möglich hier preisgegeben. Falls das schon zu viel war, bitte ich um Entschuldigung.

 

[Spacefish]

Jungs es werden einfach Parameter 1:1 an ne Shell weitergegeben von einem der binarys in cgi-bin, dass ist in etwa mit ner sql Injection zu vergleichen. Man braucht dafür keine Login Daten. Wie's genau geht werde ich euch auch nicht sagen. Das kommt eh früh genug raus...
Im Endeffekt schreibt man sich halt mit cat nen remoteshell binary auf die box, startet es und verbindet sich dann.

Ich fände es cool wenn AVM SELinux verwenden würde. Damit könnte man solche Angriffe präventiv verhindern, auch wenn solche "Bugs" in der Software drinne sind.

in dem Sinne: https://xkcd.com/327/

 

[hph]

Hier die aktuelle Ticker-Meldung von heise: http://www.heise.de/newsticker/meld...-AVM-Router-auch-ohne-Fernzugang-2115745.html

 

[Spacefish]

Naja,

dazu muss der Browser aber zugriff auf Fritz.Box per Javascript oder ein Plugin durch eine anderen Website zulassen. Das ist aber dank cross-domain security meist nicht möglich. Ich denke der "Angriff" gehört zu den eher unwarhscheinlichen Szenarien. Dazu müsste man den Browser mit einem Parameter starten, dass die Cross-Domain Policys nicht durchgesetzt werden.

 

[JohnDoe42]

Ich habe mir nochmal Gedanken zu der Geschichte gemacht, insbesondere um den/die möglichen Urheber.
Natürlich wurde/wird die Lücke genutzt, um Telefoniegeräte anzulegen und damit Geld zu verdienen .... aber könnte es nicht sein, daß das nur ein "Kollateralschaden" der Lücke war/ist ?
Nach Durchsicht der meiner Logs der letzten Monate gibt es eine IP, die konstant in den Verbindungsversuchen auftaucht:

Feb  9 12:30:44 fritz kern.warn kernel: [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=141.212.121.34 DST=192.168.178.1 LEN=44 TOS=0x00 PREC=0x00 TTL=237 ID=54321 PROTO=TCP SPT=44201 DPT=443 WINDOW=65535 RES=0x00 SYN URGP=0 
Feb  9 16:34:32 fritz kern.warn kernel: [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=141.212.121.10 DST=192.168.178.1 LEN=60 TOS=0x00 PREC=0x00 TTL=46 ID=30248 DF PROTO=TCP SPT=15625 DPT=443 WINDOW=14600 RES=0x00 SYN URGP=0 
Feb  9 16:34:33 fritz kern.warn kernel: [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=141.212.121.10 DST=192.168.178.1 LEN=60 TOS=0x00 PREC=0x00 TTL=46 ID=30249 DF PROTO=TCP SPT=15625 DPT=443 WINDOW=14600 RES=0x00 SYN URGP=0 
Feb  9 16:34:35 fritz kern.warn kernel: [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=141.212.121.10 DST=192.168.178.1 LEN=60 TOS=0x00 PREC=0x00 TTL=46 ID=30250 DF PROTO=TCP SPT=15625 DPT=443 WINDOW=14600 RES=0x00 SYN URGP=0 
Feb 10 16:06:55 fritz kern.warn kernel: [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=141.212.121.56 DST=192.168.178.1 LEN=44 TOS=0x00 PREC=0x00 TTL=237 ID=54321 PROTO=TCP SPT=53515 DPT=443 WINDOW=65535 RES=0x00 SYN URGP=0 
Feb 12 22:53:42 fritz kern.warn kernel: [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=141.212.121.208 DST=192.168.178.1 LEN=44 TOS=0x00 PREC=0x00 TTL=235 ID=54321 PROTO=TCP SPT=37126 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0 
Feb 12 23:39:47 fritz kern.warn kernel: [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=141.212.121.236 DST=192.168.178.1 LEN=44 TOS=0x00 PREC=0x20 TTL=235 ID=54321 PROTO=TCP SPT=46983 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0 
Feb 13 06:43:08 fritz kern.warn kernel: [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=141.212.121.130 DST=192.168.178.1 LEN=44 TOS=0x00 PREC=0x20 TTL=238 ID=54321 PROTO=TCP SPT=42748 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0 
Feb 13 22:22:20 fritz kern.warn kernel: [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=141.212.121.63 DST=192.168.178.1 LEN=44 TOS=0x00 PREC=0x20 TTL=238 ID=54321 PROTO=TCP SPT=40321 DPT=443 WINDOW=65535 RES=0x00 SYN URGP=0 
Feb 14 03:17:13 fritz kern.warn kernel: [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=141.212.121.224 DST=192.168.178.1 LEN=44 TOS=0x00 PREC=0x00 TTL=237 ID=54321 PROTO=TCP SPT=54071 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0 
Feb 14 04:09:46 fritz kern.warn kernel: [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=141.212.121.75 DST=192.168.178.1 LEN=44 TOS=0x00 PREC=0x00 TTL=237 ID=54321 PROTO=TCP SPT=42883 DPT=443 WINDOW=65535 RES=0x00 SYN URGP=0 
Feb 16 15:21:16 fritz kern.warn kernel: [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=141.212.121.56 DST=192.168.178.1 LEN=44 TOS=0x00 PREC=0x00 TTL=238 ID=54321 PROTO=TCP SPT=41307 DPT=443 WINDOW=65535 RES=0x00 SYN URGP=0 
Feb 17 13:50:57 fritz kern.warn kernel: [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=141.212.121.29 DST=192.168.178.1 LEN=44 TOS=0x00 PREC=0x00 TTL=238 ID=54321 PROTO=TCP SPT=47352 DPT=443 WINDOW=65535 RES=0x00 SYN URGP=0

Diese führen u.A. hierher. Ich möchte jetzt auch keine Verschwörungstheorie anstoßen, aber in Snowden-Zeiten ist das nach meinem Dafürhalten zumindest merkwürdig. Ein Emeritus dieser Einrichtung äußert sich u.A. hier. Desweiteren taucht diese Uni hier auf.
Nochmal: Das soll keine Spekulation sein - aber Fakt ist, daß diese IPs seit Monaten konstant Verbindungsversuche auf Port 443 unternehmen. Und eigentlich sollte es doch nach meiner Einschätzung nicht so lange dauern, den kleinen öffentlichen IP-Space einiger Provider in D zu scannen ... jedenfalls nicht, wenn man nicht mehr als einmal scannt.
Grüße,

JD.