Unitymedia Sind wir von Cable Haunt betroffen?

[Khaos]

Ein dänisches Forscherteam hat eine neue Schwachstelle in Kabelmodems gefunden. Leider konnte ich keine Stellungnahme von Unitymedia dazu finden. Sind wir nun betroffen? Ist ein Fix in Arbeit oder gar schon gepatcht?
Mehr Info dazu hier: https://cablehaunt[dot]com/

 

[F-orced-customer]

https://cablehaunt.com/

The reason for this is that the vulnerability originated in reference software, which has seemingly been copied by different cable modems manufacturers when creating their cable modem firmware.

Dann sind alle betroffen.

 

[rv112]

Vermutlich ja. Es ist also wie immer: es gibt Lücken immer und überall. Die meisten sind nicht gefunden, die wenigsten werden tatsächlich genutzt.

 

[Khaos]

Dann sind alle betroffen.

Mit "wir" waren "alle Unitymedia Kunden" gemeint

Naja... Hoffen wir einfach das UM die Lücke schließt bevor sie genutzt wird. Jetzt wo so viel darüber berichtet wird.

 

[F-orced-customer]

Sollten die. Ansonsten geb ich mir demnächst selber 400/40Mbps

https://cablehaunt.com/

Change every config file

 

[y0r]

Ist ja interessant. Hat jemand die Reverse Shell des Sagem Exploits mal am TC4400 ausprobiert?

 

[F-orced-customer]

Warum fragste das nicht im TC4400 infothread?

 

[y0r]

Weil es um den Exploit geht und der TC4400 zugemüllt ist.

 

[F-orced-customer]

OK. Wer testet die Fritzboxen?

https://github.com/Lyrebirds/cable-haunt-vulnerability-test

 

[sch4kal]

Weil es um den Exploit geht und der TC4400 zugemüllt ist.

Glaub ich nicht, die Adressen der dafür benötigten Funktionen dürften verschieden sein mit denen des S@gemcom.

Aber das wäre mal generell interessant, um an die eCos-Shell zu kommen:

snmpset -v2c -c private 192.168.0.1 1.3.6.1.4.1.4413.2.2.2.1.9.1.2.1.0 i 2
snmpset -v2c -c private 192.168.0.1 1.3.6.1.4.1.4413.2.2.2.1.9.1.2.1.0 i 0
snmpset -v2c -c private 192.168.0.1 1.3.6.1.4.1.4413.2.2.2.1.9.1.2.1.0 i 2

Im unprovisionierten Zustand... vermutlich dürfte es bei uns die 192.168.100.1 sein, aber evtl. hört auch kurzzeitig beim Bootup was auf die 192.168.0.1 ? Das viele DOCSIS CPEs und auch der Standard einfach IPs aus dem RFC1918 Bereich okkupieren gehört eigentlich auch bestraft...

 

[sch4kal]

OK. Wer testet die Fritzboxen?

https://github.com/Lyrebirds/cable-haunt-vulnerability-test

Nutzlos, die haben keinen Spectrum Analyzer.

 

[sch4kal]

Wer postet das Zeug jetzt eig. im Nachbarforum ? ^^

 

[Joerg123]

ich weiss jetzt nicht wie es mit Connectbox und Modems aussieht, aber wenn es ein Broadcom-Chipsatz Problem ist, dann ist die Fritzbox aussen vor ? dafür haben die Kabelfritten doch schon seit Ewigkeiten den Intel-Puma-Bug *g*

 

[F-orced-customer]

Buffer overflow geht Plattform(chipsatz)übergreifend.

 

[y0r]

Glaub ich nicht, die Adressen der dafür benötigten Funktionen dürften verschieden sein mit denen des S@gemcom.

Schon richtig. Die Entwickler schreiben auch, dass bei anderer Firmware erst die interessanten Adressen gefunden werden müssen. Da steht halt einfach sinngemäß in einem Satz: "ach, ihr müsst dazu nur die Firmware disassemblen um die Adressen zu finden"

 

[sch4kal]

Buffer overflow geht Plattform(chipsatz)übergreifend.

Ja, aber dieser Explizite in der Startfrequenz des Spectrum Analyzers geht nur bei Broadcom-basierten DOCSIS SoCs, wüsste nicht das die Puma-Chips eCos nutzen würden. Sicher wird es bei Intel auch genug BO geben, die haben ja schon mit ihrer Implementierung der spekulativen Codeausführung so ihre Sicherheitsprobleme ^^

 

[sch4kal]

Schon richtig. Die Entwickler schreiben auch, dass bei anderer Firmware erst die interessanten Adressen gefunden werden müssen. Da steht halt einfach sinngemäß in einem Satz: "ach, ihr müsst dazu nur die Firmware disassemblen um die Adressen zu finden"

Ja sicher, so haben sie die Lücke ja überhaupt erst entdeckt ^^ So eine reverse Shell zum eCos wäre natürlich recht nett zum Spielen

 

[sch4kal]

Der PoC des Sagemcom F@st 3890 (https://github.com/Lyrebirds/sagemcom-fast-3890-exploit) funktioniert beim TC4400 wohl augenscheinlich nicht:

jw@jw-thinkpad ~/sagemcom-fast-3890-exploit $ python exploit.py * Serving Flask app "exploit" (lazy loading) * Environment: production WARNING: This is a development server. Do not use it in a production deployment. Use a production WSGI server instead. * Debug mode: on * Running on http://0.0.0.0:8085/ (Press CTRL+C to quit)
127.0.0.1 - - [12/Jan/2020 13:20:14] "GET / HTTP/1.1" 200 -
127.0.0.1 - - [12/Jan/2020 13:20:14] "GET /exploit.js HTTP/1.1" 200 -
127.0.0.1 - - [12/Jan/2020 13:20:15] "GET /favicon.ico HTTP/1.1" 404 -

...öffnet sich keine Shell, TC4400 bleibt weiterhin erreichbar.

 

[MichaelBre]

Sollten die. Ansonsten geb ich mir demnächst selber 400/40Mbps

https://cablehaunt.com/

Wer erstellt ein Configfile mit 1000/1000 und teilt die entsprechende Anleitung?

 

[rv112]

Bringt Dir kaum etwas, da der Upstream eh schon fast überall mit 50 am Limit läuft . 80 war das Maximum was ich mal geschafft habe, aber auch nur Vormittags.

 

[MichaelBre]

Das ist immerhin doppelt so viel wie jetzt.
Danke Business 400
Bei der nächsten Laufzeit wird es doch wieder ein Privatkunden Tarif, hoffentlich gibt es bis dahin bei mir Gigabit und einen entstörten OFDM fürs TC4400.

Mit welchem Tarif konntest du 80 Mbits im Upload erreichen?

Zudem bleibt die Frage wie lange das seitens UM unentdeckt bleibt. Irgendwo wird da sicherlich eine Nachricht aufschlagen.

 

[Andreas1969]

Mit welchem Tarif konntest du 80 Mbits im Upload erreichen?

Mit 2 TC4400 natürlich, jeweils 400/40 provisioniert

 

[rv112]

Fast, 1000/50 jeweils. Wobei bei mir inzwischen Abends nicht mal mehr die 50 ankommen. QAM16 sei dank...

 

[MartinP_Do]

Mir ist Stabilität meiner gebuchten und bezahlten 100/5 Datenraten lieber. als die Möglichkeiten eines auf einfachem Wege "aufgeknackten und beschleunigten" Kabelmoden.

Abends ist nach meinen CableloadMonitor - Messungen in der Regel nur noch 100 ... 300 MBit/s im von mir genutzten Kabelsegment von der verfügbaren Bandbreite NICHT genutzt.
Da kämen mir gerade ein paar Skript Kiddies im Segment recht, die plötzlich für Tests dauerhaft viel Bandbreite belegen, um sich permanent zu beweisen, dass sie die tollsten Hacker des Universums sind ...

 

[rv112]

Ist die CMTS gut programmiert, gibt es eh nicht mehr als das Gebuchte bzw. ein falsches Configfile führt zum Fehler. Ich bezweifle dass hier überhaupt jemand Erfolg hat.