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

sf3978 · 13 Feb 2014

JohnDoe42 schrieb:
versucht - trotzdem "sieht" die Testbox mein restliches LAN und ich kann das (AVM-) WebIF der Testbox erreichen ...

Evtl. mit tcpdump, ping, traceroute, ... versuchen festzustellen, wie die Datenpakete von der Testbox ins restliche LAN kommen.

HabNeFritzbox · 13 Feb 2014

Oder einfach den FritzHonigtopf an LAN 4 ins Gastnetz verbannen. Portweiterleitung ins Gastnetz sollte auch gehen.

JohnDoe42 · 14 Feb 2014

HabNeFritzbox schrieb:
Oder einfach den FritzHonigtopf an LAN 4 ins Gastnetz verbannen.

Gute Idee, werde ich machen.
Grüße,

JD.

Marcus F. · 14 Feb 2014

Honigtöpfe usw.

Lohnt sich der Aufwand noch? Wenn jetzt zu den 20% aus der BSI-Meldung noch die Zwangsupgedateten der Kabelprovider kommen, dürften Angriffsversuche nicht mehr so lukrativ sein. Hinzu kommt noch, dass der Rest wahrscheinlich den https-Port nicht offen hat.
Und wie soll ein Versuch eines Trittbrettfahrers (dürften in der absoluten Mehrheit sein) von einem wirkungsvollen Angriff unterschieden werden?

Marcus

JohnDoe42 · 14 Feb 2014

Zum Thema "Lohnt sich der Aufwand noch" ein paar Logs von heute:

Code:

Feb 14 08:54:49 fritz kern.warn kernel: [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=217.82.128.71 DST=192.168.178.1 LEN=48 TOS=0x00 PREC=0x00 TTL=119 ID=27848 DF PROTO=TCP SPT=4346 DPT=443 WINDOW=65535 RES=0x00 SYN URGP=0 
Feb 14 08:54:49 fritz kern.warn kernel: [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=217.82.128.71 DST=192.168.178.1 LEN=48 TOS=0x00 PREC=0x00 TTL=119 ID=27863 DF PROTO=TCP SPT=4350 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0 
Feb 14 08:54:52 fritz kern.warn kernel: [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=217.82.128.71 DST=192.168.178.1 LEN=48 TOS=0x00 PREC=0x00 TTL=119 ID=27886 DF PROTO=TCP SPT=4346 DPT=443 WINDOW=65535 RES=0x00 SYN URGP=0 
Feb 14 08:54:52 fritz kern.warn kernel: [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=217.82.128.71 DST=192.168.178.1 LEN=48 TOS=0x00 PREC=0x00 TTL=119 ID=27890 DF PROTO=TCP SPT=4350 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0 
Feb 14 08:54:58 fritz kern.warn kernel: [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=217.82.128.71 DST=192.168.178.1 LEN=48 TOS=0x00 PREC=0x00 TTL=119 ID=27935 DF PROTO=TCP SPT=4346 DPT=443 WINDOW=65535 RES=0x00 SYN URGP=0 
Feb 14 08:54:58 fritz kern.warn kernel: [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=217.82.128.71 DST=192.168.178.1 LEN=48 TOS=0x00 PREC=0x00 TTL=119 ID=27938 DF PROTO=TCP SPT=4350 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0 
Feb 14 08:55:10 fritz kern.warn kernel: [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=217.82.128.71 DST=192.168.178.1 LEN=48 TOS=0x00 PREC=0x00 TTL=119 ID=27974 DF PROTO=TCP SPT=4355 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0 
Feb 14 08:55:13 fritz kern.warn kernel: [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=217.82.128.71 DST=192.168.178.1 LEN=48 TOS=0x00 PREC=0x00 TTL=119 ID=27994 DF PROTO=TCP SPT=4355 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0 
Feb 14 08:55:19 fritz kern.warn kernel: [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=217.82.128.71 DST=192.168.178.1 LEN=48 TOS=0x00 PREC=0x00 TTL=119 ID=27996 DF PROTO=TCP SPT=4355 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0 
Feb 14 09:32:10 fritz kern.warn kernel: [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=79.216.179.202 DST=192.168.178.1 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=55718 DF PROTO=TCP SPT=50238 DPT=443 WINDOW=65535 RES=0x00 SYN URGP=0 
Feb 14 09:32:10 fritz kern.warn kernel: [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=79.216.179.202 DST=192.168.178.1 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=41405 DF PROTO=TCP SPT=50239 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0 
Feb 14 09:32:11 fritz kern.warn kernel: [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=79.216.179.202 DST=192.168.178.1 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=35573 DF PROTO=TCP SPT=50239 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0 
Feb 14 09:32:11 fritz kern.warn kernel: [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=79.216.179.202 DST=192.168.178.1 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=23210 DF PROTO=TCP SPT=50238 DPT=443 WINDOW=65535 RES=0x00 SYN URGP=0 
Feb 14 09:32:12 fritz kern.warn kernel: [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=79.216.179.202 DST=192.168.178.1 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=4561 DF PROTO=TCP SPT=50239 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0 
Feb 14 09:32:12 fritz kern.warn kernel: [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=79.216.179.202 DST=192.168.178.1 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=65170 DF PROTO=TCP SPT=50238 DPT=443 WINDOW=65535 RES=0x00 SYN URGP=0 
Feb 14 09:32:13 fritz kern.warn kernel: [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=79.216.179.202 DST=192.168.178.1 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=51169 DF PROTO=TCP SPT=50239 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0 
Feb 14 09:32:13 fritz kern.warn kernel: [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=79.216.179.202 DST=192.168.178.1 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=59843 DF PROTO=TCP SPT=50238 DPT=443 WINDOW=65535 RES=0x00 SYN URGP=0 
Feb 14 09:32:14 fritz kern.warn kernel: [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=79.216.179.202 DST=192.168.178.1 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=53933 DF PROTO=TCP SPT=50239 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0 
Feb 14 09:32:14 fritz kern.warn kernel: [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=79.216.179.202 DST=192.168.178.1 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=19938 DF PROTO=TCP SPT=50238 DPT=443 WINDOW=65535 RES=0x00 SYN URGP=0 
Feb 14 09:32:15 fritz kern.warn kernel: [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=79.216.179.202 DST=192.168.178.1 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=63935 DF PROTO=TCP SPT=50239 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0 
Feb 14 09:32:15 fritz kern.warn kernel: [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=79.216.179.202 DST=192.168.178.1 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=63907 DF PROTO=TCP SPT=50238 DPT=443 WINDOW=65535 RES=0x00 SYN URGP=0

Grüße,

JD.

SF1975 · 14 Feb 2014

Hallo,
@JD:
Mal für den DAU .... was kann man aus dem Log entnehmen?

HabNeFritzbox · 14 Feb 2014

Dass irgendwer irgendwelche Daten irgendwie sendet. Also eher wenig bis nichts. Besonders wenn man bei der Schwachstelle keine Logindaten braucht.

Bei dem ganzen Abweichungen zum Thema fällt es auch ned mehr auf.

JohnDoe42 · 14 Feb 2014

Zunächst mal nichts Besonderes ... solange ich (noch) nicht den https-Request auf Port 443 aufzeichnen kann bzw. dieser nix Besonderes hergibt.
Allerdings paßt das Muster (eine IP, viele abwechselnde Versuche auf Port 80 [Identifizierung der Box] und Port 443 [Ausnutzen der Lücke]) zu denen der vorangegangen Tage. Und ich meine, mich auch an die IPs erinnern zu können.

Entscheidend ist (zumindest für meine Box) die Statistik (wie ich bereits mehrfach schrieb): Die massive Kombination von Versuchen auf Port 80 und Port 443 von einer IP kannte ich vor dem 28.01. nicht. Die Frequenz wird seitdem stetig kleiner, aber die Muster bleiben.

JohnDoe42 · 14 Feb 2014

Ich warte mit dem Fragen mal, bis ich die https-Requests ordentlich aufzeichnen kann ...

RalfFriedl · 14 Feb 2014

Ideal wäre noch ein zwischengeschalteter Router oder eine eigene Netzwerkkarte am Linux Router.

Iptables auf der Box ist auch eine gute Lösung, solange man davon ausgeht, dass der Angreifer diese nicht abschalten kann. In diesem Fall würde ich davon ausgehen, da es dem Angreifer nicht darum geht, mit viel Aufwand an diese eine Box zu kommen, sondern mit einfachen Mitteln aus einer großen Anzahl von Boxen die zu finden, wo er etwas tun kann.

Außerdem wäre es sinnvoll, die Box auf eine IP-Adresse aus einem anderen Netzwerk zu konfigurieren als das restliche interne Netzwerk. Das ist zwar auch nicht absolut sicher, macht es dem Angreifer aber auch nochmal schwerer. Am Router muss man dann dementsprechend zwei interne Adressen konfigurieren.

HabNeFritzbox · 14 Feb 2014

Ralf, schon mal was von Gastzugang gehört?

JohnDoe42 · 14 Feb 2014

@ RalfFriedl:

Könnte es sein, daß es

Code:

openssl s_server -accept 443  [B]-debug[/B] -cert cert.pem -key key.pem &> /tmp/$(date +%Y%m%d-%H%M%S).log

heißen müßte ?

RalfFriedl · 15 Feb 2014

Debug zeigt nur zusätzliche Angaben zur Verschlüsselung. Ich habe es mal ausprobiert, ohne eine Eingabe bricht der Server die Verbindung sofort ab.

Aber so sollte es funktionieren:

Code:

echo HTTP/1.1 501 Server Error | openssl s_server -accept 443 -cert cert.pem -key key.pem &> /tmp/$(date +%Y%m%d-%H%M%S).log

Am Besten auch mal ausprobieren mit

Code:

wget -O /dev/null --no-check-certificate https://127.0.0.1/

Wget zeigt dann den Fehler 501 vom Server an, und der Server sollte etwas in der Art protokollieren:

Code:

GET /test HTTP/1.1
User-Agent: Wget/ (linux-gnu)
Accept: */*
Host: 127.0.0.1
Connection: Keep-Alive

@HabNeFritzbox
Gastzugang habe ich schon gehört, aber noch nicht verwendet. Sollte aber passen.

JohnDoe42 · 15 Feb 2014

@ RalfFriedl: Okay, danke für die Tips. Ich werde das probieren.

@ HabeNeFritzbox: Gastzugang ist unbrauchbar, weil man aus dem eigentlichen Heimnetz die Testbox nicht mehr "sieht", insbesondere keinerlei Zugriff z.B. per SSH hat.

robot_rap · 15 Feb 2014

Spacefish schrieb:
Du kannst dir auch einfach die key.pem von deiner fritz.box ziehen und die SSL Verbindungen im wireshshark entschlüsseln (solange kein dh key exchange verwendet wird).

Zumindest auf meiner Box (7390, 06.03) ist die key.pem mit einem Passwort geschützt, sodass ein Entschlüsseln des SSH-Traffics mit Wireshark nicht funktioniert. Wer kennt das Passwort für die websrv_ssl_key.pem?

HabNeFritzbox · 15 Feb 2014

SSH läuft eh nicht mit Standard Mitteln und müsste erst erweitert werden. Gastzugang hat doch gerade den Zweck, dass man nicht ins Heimnetz oder umgedreht kommt. Daher dann auch wenn noch ne Freigabe dafür anlegen.

Gastzugang ist sicherer und einfacher, also extra noch 3. Router zwischen und 2. LAN Karte und ähnliches.

Ändert Thema am besten noch um, aktuell passt ja eher "Wie richte ich Weiterleitung ein?" oder "Wie richte ich openSSL ein?" oder "Wie tausche ich Zertifikat aus" oder "Wem Gehört IP xy?"

hph · 16 Feb 2014

Ich habe die genauen Details zur AVM-Sicherheitslücke aufgeklärt, Shellcode dazu geschrieben und vor gut einer Stunde der heise.de-Redaktion übermittelt. Sie wissen nun genauestens Bescheid und werden es hoffentlich bald einen Artikel dazu schreiben.
Die Lücke werde ich nicht preisgeben, auf Ratespielchen lasse ich mich auch nicht ein.

Ursächlich war jedenfalls eine mangelnde Inputvalidierung in einem "von außen" erreichbaren Dienst, über die man man Shell-Befehle absetzen konnte.

Wer der Meinung ist, dass ich Lüge, der notiere sich bitte folgenden SHA-256 Hash.

Code:

8492a4ef22a5d8c50b7e6782cd1c37a5f127d51cb3a11da3c857875c8d42ac7e

HabNeFritzbox · 16 Feb 2014

Etwas mehr Infos kannst ruhig beschreiben dazu. Sonst bringt die Info auch keinem etwas.

Wie von mir schon mal vermutet konnte direkt die php Datei ausgeführt werden und andere Variablen gesetzt werden womit man auf andere Verzeichnisse kommt?

Muss ja keine genau Anleitung sein, aber Dienst oder grob kann man es doch beschreiben.

hph · 16 Feb 2014

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.

Hinckley · 16 Feb 2014

Moin,

wenn ich die FW 5.50 und höher auf meine 7270v2 aufspiele funktioniert die nicht mehr in dem Umfang wie ich sie brauche...
Also auch keine Lösung. Die FW 5.50 und höher ist Müll, bleibt mir nur den Fernzugriff abzuschalten - kann ich mit leben

Viele grüße Hinckley

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

IPPF-Promi

HabNeFritzbox

Guest

Aktives Mitglied

Neuer User

Aktives Mitglied

SF1975

Guest

HabNeFritzbox

Guest

Aktives Mitglied

Aktives Mitglied

IPPF-Urgestein

HabNeFritzbox

Guest

Aktives Mitglied

IPPF-Urgestein

Aktives Mitglied

Aktives Mitglied

HabNeFritzbox

Guest

Mitglied

HabNeFritzbox

Guest

Mitglied

Neuer User

Statistik des Forums