[Info] 17.2.2014 Hack gegen AVM-Router auch ohne Fernzugang (heise.de)

[lolly3]

Für die 7270v1 gibt es ja ein Update mit WDS-Möglichkeit. Wenn mich nicht alles täuscht läuft diese Firmware auch auf einer 7270v2, damit würde die Kiste aber IPv6-untauglich. Auch für die 7270er bei o2 gibt es ein solches xx.04.89 Update.

Ich habe nun selber AVM angeschrieben und bekam heute eine Antwort mit folgendem Link als Lösung:
http://service.avm.de/support/de/SK...S-Betrieb-nach-FRITZ-OS-Update-nicht-moeglich

Ganz am Schluss der Seite steht dann folgendes:
"Wenn Sie auf das WDS-Verfahren nicht verzichten können, installieren Sie die Beta-Firmware für Ihre FRITZ!Box 7270 v2/v3, die wir in den kommenden Tagen bereitstellen werden. Mit dieser Beta-Firmware auf Basis eines älteren FRITZ!OS wird die FRITZ!Box das WDS-Verfahren unterstützen und dennoch genauso wie mit dem aktuellen Sicherheits-Update vor allen bekannten Angriffsmustern geschützt."

Dann bin ich ja mal gespannt!
Danke AVM!

@erik

..Das betroffene Gerät steht in Übersee..

Das hatte ich mit der Box meiner Mutter in den USA auch. Ich hab sie gebeten sich einen Windows Rechner zu leihen (sie hat nur einen Mac) und dann TeamViewer QuickSupport runter zu laden und auszuführen (ohne Intsallation!) dann mussten sie mir nur noch die ID vom Bildschirm ablesen und ich habe dann das rukerneltool aus der Ferne auf dem Rechner ausgeführt, meine mit Annex A gepatchte Firmware auf den Rechner übertragen und bin dann mit dem rukerneltool dann soweit, dass sie nur noch die Box Stromlos machen musste, im Tool auf "OK" klicken musste und dann das Netzteil nur wieder einstecken musste.
Und es hat geklappt!

 

[daheim]

Moin,

was ist aber mit UPnP an Port 49000 bei meinem Speedport W 722V (TypA), der von AVM hergerstellt ist ( gemäß MAC) ? Hier kann nichts abgeschaltet werden. Dieser Port ist, wie der Scan von Heise zum Port 32764, stattdessen 49000 als Ziel des Scans eingegeben, gekennzeichnet als g e f i l t e r t, also offen ohne Antwort. Besteht hier eine Gefahr? Das neue Update der Firmware (anläßlich der Fritzbox-Diskussion) ist von der Telekom eingespielt.

 

[sweetie-pie]

Eigentlich ist ja alles gesagt, aber ich habe zufällig noch den verlinken Blog-Beitrag gefunden.

Es spricht also schon einiges dafür, dass AVM geahnt hat, dass sie da wohl eine ordenliche Leiche im Keller haben.
Die Provider wurden also zeitnah informiert und sogar mit einem Maßnahmenkatalog unterstützt. Was die dann tatsächlich davon gemacht haben, ist fraglich.
Die Informationspolitik vom AVM zum (End-)Kunden bleibt m.E. eher unglücklich. Taktik-Strauß kann in Zeiten wo Whistle-Blowing hip ist, ordentlich nach hinten los gehen...

Nachtrag:
Richtig gut finde ich diesen Satz von AVM an die Provider:

Es muss davon ausgegangen werden, dass die empfohlene Sperre des Ports 443 nicht von allen Kunden unmittelbar befolgt wird. Deshalb sind aus unserer Sicht die netzseitigen Maßnahmen sehr wichtig und wir bitten Sie um Eruierung und ggf. Umsetzung.

 

[nordicwalker]

wenn ich linux mint oben habe, sehe ich alle portzugriffe auf dem desktop, https geht auf 443. Es ist normal unter https://www.google.com

 

[sweetie-pie]

[Edit Novize: Überflüssiges Fullquote des Beitrags direkt darüber gelöscht - siehe Foren-Regeln]

Lese bitte den verlinkten Beitrag, dann lösche deinen Post, denn er macht keinen Sinn.:bier:

 

[pfax]

443 Lücke im Apfel

...
Es spricht also schon einiges dafür, dass AVM geahnt hat, dass sie da wohl eine ordenliche Leiche im Keller haben.

isch habe koine Äpfel
sondern Fritten, aber trotzdem,

So machen es andere
http://support.apple.com/kb/HT6147
"Impact: An attacker with a privileged network position may capture or modify data in sessions protected by SSL/TLS"

Und was meinen die dazu:
"For the protection of our customers, Apple does not disclose, discuss, or confirm security issues until a full investigation has occurred and any necessary patches or releases are available."

Für Alle, die nicht neudeutsch sprechen (gekürzt):
Ein Angreifer im Netz kann SSL/TLS Daten abgreifen und verändern.
Um unsere Kunden zu schützen sagen wir erst mal garnix. Das ist Firmen-Habitus.

Ob deren Problemchen mit SSL kleiner als das vom Fritzchen ist, mag jeder für seine Anwendung entscheiden.

 

[Micha0815]

...
Die echten Opfer sind kaum der Rede wert (Zahlenmässig).
Haben keinen Schaden (Kulanz), nur der Schreck war gross.
...

Naja! Ein anderes Szenario ist auch anzudenken.

1. ist unbekannt, wielange und wieviel z.B. SIP-Account-Passwörter abgefischt wurden. Erst durch die strafbare Verwendung derselben ist die Lücke imho evident geworden.

2. Wenn die Provider oder der Kunde selbst nicht aktiv die SIP-Passwörter ändern, können die erbeuteten auch zu einem späteren Zeitpunkt Verwendung finden. Dazu nützt eine sichere FW nur für die Zukunft.

3. auf den dunklen Seiten des WWW soll es Kriminelle geben, die Handel mit erbeuteten Kreditkartendaten, Mailaccounts usw. betreiben.

Die Zahl der echten Opfer mag z.Zt. noch gering sein, nur könnte diese demnächst ansteigen.

LG

 

[andilao]

Im Gegensatz zu Kreditkartennummern etc. lassen sich SIP-Passwörter bei praktisch allen mir bekannten Anbietern recht schnell ändern. Wer jetzt nach der Kenntnisnahme der Sicherheitslücke und dem sehr gut möglichen "Verlust" aller in seiner Fritzbox gespeicherten relevanten Passwörter nicht handelt oder "handeln lässt", dem kann man nicht mehr helfen.

 

[masss]

Kreditkartennummern lassen sich schon schnell ändern, nur leider nicht kostenfrei. Es kostet dich einen Anruf 'Karte verloren bitte sperren' und ca. 15 Euro

 

[Spacefish]

Installieren von noscript bringt nix. Der Angriff ist durch einen einzigen GET request möglich. Der Angreifer muss also nur das src Attribut eines img Tag auf betreffende URL setzen und der Browser generiert den get request, beim Versuch das Bild zu laden. Aktuell bietet wie schon erwähnt nur das Update einen wirklichen Schutz. Ändern des ports hilft aber natürlich auch, da der Angreifer ja 80 bzw 443 erwartet idr.

 

[schlegel11]

[Edit Novize: Überflüssiges Fullquote des Beitrags direkt darüber gelöscht - siehe Foren-Regeln]

Hier würde ich schon fast das Plugin "RequestPolicy"(https://addons.mozilla.org/de/firefox/addon/requestpolicy/) empfehlen also auch neben dem Update

 

[NanoBot]

Sollte in diesem Fall nicht RequestPolicy helfen ?

Denn dieses AddOn ist ja extra als Schutz gegen unerwünschte oder sogar gefährliche Cross-Site-Requests gedacht. Mehr Infos dazu gibt es hier: https://www.requestpolicy.com/

Upps, da war schlegel11 um 2 Minuten schneller als ich

 

[tim70]

Ändern des ports hilft aber natürlich auch, da der Angreifer ja 80 bzw 443 erwartet idr.

was haltet ihr davon:

websrv {
port = "23128";
https_port = "23443";
read_timeout = 15m;
request_timeout = 30s;
keepalive_timeout = 5m;
nokeepalive = "*";
errordir = "/usr/www/html/errors";
webdir = "/usr/www";
cgidir = "cgi-bin";
indexfn = "index.var", "index.htm", "index.html";
users_only_for_https = yes;
cors_allow_origins = "*.avm.de";
cors_allow_headers = "SOAPACTION", "Content-Type", "Origin";
cors_allow_methods = "GET", "POST", "OPTIONS";
cors_max_age = 1d;
}

Habe die Ports bisher an einem Speedport geändert. Portnumern nur als Beispiel - was haltet ihr davon?
Falls keine weiteren Ports offen sind, sollte es doch so möglich sein die Ports vor einfachen Skripts zu vertecken.
Allerdings, was wenn ein Skript alle durchprobiert?

Und ja ich habe verstanden dass die Lücke jetzt geschlossen ist, bei eingespieltem Update - trotzdem würde ich die Standardports ändern.

 

[scolopender]

Allerdings, was wenn ein Skript alle durchprobiert?

Dann macht das Deine Aktion zwecklos.

G., -#####o:

 

[tim70]

[Edit Novize: Überflüssiges Fullquote des Beitrags direkt darüber gelöscht - siehe Foren-Regeln]

denke ich nutzes es dennoch - eine Funktion die den Host für die Wartung der Box beschraänkt wäre schön

Sry für den Fullquote

 

[Spacefish]

Du kannst die Wartung auf bestimmte ip Adressen beschränken mit iptables halt.
Ein Angreifer würde idr. Nicht alle ports probieren, solange er nicht dich als einziges Ziel hat, da das viel zu zeitaufwändig ist.

 

[koyaanisqatsi]

Habe die Ports bisher an einem Speedport geändert.
Allein diese Änderung bewirkt, dass der Googlebot dich nicht (so leicht) findet.
Vorrausgesetzt natürlich, sie werden nicht extern wieder auf 80 oder 443 freigegeben.

 

[R0cket]

Es scheinen auch andere Router als die von AVM gehackt worden zu sein:

http://www.bbc.co.uk/news/technology-26287517

Das sieht nach System aus für mich.

Da scheinen nahezu alle Anbieter von Routern Die Türen für Hacker offengelassen zu haben.

Ich hoffe das war Absicht und nicht Unvermögen.

Das alles ist eine Riesen Katastrophe.

 

[sibsnonto]

Ruft man die Seite mit einem Rechner im Netz der Fritzbox auf, führt diese fremdgesteuert einige Befehle aus, die unter anderem dafür sorgen, dass die Konfigurationsdatei des Routers auf einen externen Server kopiert wird. Diese Datei enthält neben dem Administrations-Passwort der Fritzbox auch viele andere sensible Daten im Klartext, etwa die DSL- und DynDNS-Zugangsdaten.

Quelle: http://www.heise.de/security/meldun...-AVM-Router-auch-ohne-Fernzugang-2115745.html

Die Einstellungen bei meiner 5140 (die ja nicht betroffen sein soll), habe ich jetzt auch mal exportiert über das Webinterface. Dort finde ich kein Administrations-Passwort im Klartext.


Warum steht das bei den Neueren im Klartext in der export Datei ???
Trifft das dort nur auf die DSL-Zugangsdaten zu oder auch auf das Passwort für das Webinterface ?

Kann man die Export-Funktion nicht abstellen irgendwie ?

 

[hph]

Intern werden sämtliche Passwörter verschlüsselt abgelegt und so auch exportiert. Als Schlüssel dient ein hardwarespezifisches Geheimnis. Somit kann die Box jederzeit alle Passwörter ver- und entshclüsseln. Das muss sie größtenteils auch können, um z. B. E-Mails zu versenden, sich beim Internetanbieter einzuwählen oder die DynDNS zu updaten. Allerdings, und das ist eine Designschwäche, speichert sie auch alle Loginpasswörter, mit denen man sich bei der FB einloggt, verschlüsselt. Anstattdessen sollte sie das Passwort hashen, z.B. mit PBKDF2 und SHa-256.