Onderzoekers: kwetsbaarheid in kabelmodems treft vele miljoenen exemplaren

Onderzoekers hebben een kwetsbaarheid gevonden in kabelmodems met een onderdeel van Broadcom. Als een aanvaller zijn doelwit op een malafide webpagina krijgt, kan hij remote code execution vanaf de modem uitvoeren. In Europa zou het gaan om 200 miljoen modems.

De kwetsbaarheid, die de vier Deense onderzoekers Cable Haunt noemen, zit in de Broadcom-spectrum analyzer van kabelmodems. Het onderdeel wordt normaal gesproken gebruikt om de modem tegen energiefluctuaties in de kabel te beschermen. Daarnaast gebruiken providers het om op afstand de modem uit te lezen. Deze zou geen bescherming tegen dns rebinding attacks hebben, standaard-credentials gebruiken en een fout in de firmware hebben.

Zonder het doelwit op de malafide webpagina te krijgen, werkt de aanval niet; de spectrum analyzer is namelijk alleen toegankelijk vanuit het lan. Een alternatief op deze invalshoek is voor de aanvaller om te verbinden met het netwerk en zelf de modem aan te spreken. Eenmaal in de buurt van de modem is het een kwestie van een buffer overflow-aanval en een kwaadwillende kan code uitvoeren vanaf de modem. De onderzoekers geven voorbeelden van doeleinden: de dns-server veranderen, mitm-aanvallen uitvoeren, de firmware in zijn geheel vervangen, de modem aan een botnet toevoegen en meer.

De onderzoekers hebben een lijst met kwetsbare modems opgesteld, maar zeggen erbij dat er mogelijk veel meer modellen kwetsbaar zijn, gezien het grote aantal. Nederlands grootste kabelprovider, Ziggo, levert aan klanten doorgaans een Compal CH7465LG-ZG, maar die staat niet op de lijst. De Compal 7284E en 7486E wel. Het is dus echter niet zeker dat Ziggo-modems hiermee buiten schot blijven. Voor wie dit zelf thuis kan en wil testen, hebben de onderzoekers een script op hun site staan.

Reacties (118)

[Dacuuu]

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

[AndrewF]

Ik heb de test gedraaid op mijn netwerk achter een Telenet kabel modem:

We could not find ip and port for spectrum analyzer. This could mean you are not vulnerable or that we did not test for the correct IP, port or credentials

Update: dit is met een model van type “24*8 DOC 3 EMTA(DOCSIS)” in modem-only modus. Routing/Firewall/Wifi doe ik zelf met ubiquity gear.

[Reactie gewijzigd door AndrewF op 22 juli 2024 22:40]

[cobex]

Kan je specifieren welke modem precies? Dank!

[AndrewF]

Model van type “24*8 DOC 3 EMTA(DOCSIS)” volgens de info op “mijn telenet”

[djs909]

Dat is dus gewoon een docsis 3 met 24 down en 8 up channels.

[bamboe]

Thank you for clicking on this link.
Your modem will recieve the newest firmware
so we can always acces your network.
Thank you for your trust in our hacking team...

[Waterfietser]

Ik snap niet waarom je een min krijgt, ik snap niet waarom zo’n tool niet gewoon terecht komt op de site van de leverancier maar op github...

[King4589]

Via de link in het artikel kom je op pagina van de onderzoekers uit waar me met één klik op de github uitkomt met het test script. Dus daarom github.
Een post met deze link toevoegen is onnodig maar helaas wel een goede manier om +2 te krijgen.

[mcbeef]

Typisch, je punt niet kunnen bekrachtigen met argumenten, dan de ander maar ridiculiseren.

Edit: typo

[Reactie gewijzigd door mcbeef op 22 juli 2024 22:40]

[bamboe]

Ik vond het zelf wel interesant dat in het artikel staat: Zonder het doelwit op de malafide webpagina te krijgen, werkt de aanval niet
De eerste reactie die je dan tegen komt is een link naar een externe website, ik wou gewoon iedereen weer even na laten denken.

[mcbeef]

Precies!

[divvid]

Ik geef je groot gelijk, dit soort dingen zou uit de koker van ons ict preventie team kunnen komen. Naast de echte spam berichten herken ik inmiddels de security fishing mails ook heel goed.

[DeDooieVent]

ict preventie team

Hadden wij die hier ook maar

[McBacon]

Ook de Technicolor EPC3928AD (EuroDocsis 3.0 2-PORT Voice Gateway) geleverd vanuit Ziggo is vulnerable; http://192.168.100.1:8080 geeft de analyser (zonder credentials zelfs) en het testscriptje crashed ook het modem.

Overigens geeft die pagina op dit modem heel mooi geen Content-Type header mee, dus Firefox geeft gewoon de plaintext weer en Chrome rendered zijn standaard error page met de melding "invalid response". Ik moest de HTML op een webservertje van mezelf zetten om vervolgens te zien dat hij alleen werkt in Chrome en Safari. Na één van die browsers erbij gepakt te hebben zie ik eindelijk de analyser, maar om hem te laten werken moest ik natuurlijk nog de websocket URL in de embedded JavaScript aanpassen (ff het IP hardcoden i.p.v. een substr() call). Ik had eerst geprobeerd om een "edit headers" extension te gebruiken maar dan bleef de page eindeloos laden en werd ik uiteindelijk redirected naar 192.168.0.1. O.o

[MikeyV]

Ligt het nu aan mij of is Broadcom de laatste tijd nogal wat bokken aan het schieten?

Onderzoekers hebben een kwetsbaarheid gevonden in kabelmodems met een onderdeel van Broadcom.

Dit is twee dagen geleden gepubliceerd.

https://www.us-cert.gov/n...dcom-WiFi-Chipset-Drivers

April 2019.

https://www.cybersecurity...nerable-to-cyber-attacks/

Dat was m.i. twee jaar geleden een issue.

Een flinke lijst kun je hier zien...

Dit soort dingen zijn voor mijn werkgever enerzijds meer dan genoeg aanleiding Broadcom te weren uit de Thin Clients, Fat Clients en Telestick. Helaas (nog) niet uit de smartphones...

Iemand trouwens ook al enig idee of er al aanvallen zijn en of in de Docsis-modems ook sprake is van extra kwetsbaarheid door nog meer Broadcom-onderdelen?

[Reactie gewijzigd door MikeyV op 22 juli 2024 22:40]

[tonkie_67]

Broadcom is al jaren op overname pad en op veel gebieden wereldleider: dus dan dikke kans dat ze ook vaak aan bod komen mbt bugs. En omdat ze een heel breed scala aan netwerk (-ondersteunende) chipsets aanbieden is het dus ook vaak raak op security gebied.
En al heel lang leveren ze prima hardware maar is de bijbehorende software e/o firmware niet altijd op hetzelfde kwaliteitsnivo.
Regelmatig lopen wij aan tegen onvolkomenheden in de sdk van hun chipsets die in onze (en ook veel andere switchboeren incl bepaalde Cisco Nexus modellen) switches gebruikt worden. Bedoel hier de Brcm StrataXgs family zoals Tomahawk, Trident etc.

En hetzelfde zag je vroegah ook bij hun 10G NICs. De BRCM57800 series NICs waren heel goed, maar firmware en drivers waren "minder". Tegenwoordig is die tak van QLogic maar die namen ook alle bijbehorende int.prop. over en vele developers: dus dat diezelfde kaarten nu plots QLogic heeten maakt (nog?) niet veel uit voor de kwaliteit van de code

[Reactie gewijzigd door tonkie_67 op 22 juli 2024 22:40]

[D0phoofd]

Ik denk niet dat het aan Broadcom zelf ligt. Maar aan de firmware van de modems. Die stellen de poort open om door de ISP (op afstand) het modem uit te lezen. De exploit werkt dus om deze te exploiteren dmv een bufferOverflow. Omdat deze poort ook open staat op het LAN zijde van het netwerk.

[MikeyV]

Ik deel die mening maar ten dele. In het onderzoek In het rapport Cable Haunt (https://github.com/Lyrebi...atest/download/report.pdf) wordt expliciet gesproken over Broadcom cable modems. Of andere DSL-modems kwetsbaar zijn zal verder onderzoek uit moeten wijzen... Tot die tijd wijs ik toch naar Broadcom...

Ik schrijf met opzet DSL-modems omdat ik het idee krijg dat VDSL-modems evengoed kwetsbaar kunnen zijn als die ook dezelfde Broadcom chip bevatten...

[Reactie gewijzigd door MikeyV op 22 juli 2024 22:40]

[The Third Man]

De spectrum analyzer is een onderdeel van Broadcom's middleware, vandaar dat het dus alle modems met hun SOC's treft tenzij ze de vendor de exploit heeft ondervangen (wat waarschijnlijk nergens het geval is) of als de vendor de spectrum analyzer onbereikbaar heeft gemaakt (wederom waarschijnlijk nergens het geval). Juist als de exploit in een firmware zou zitten dan zou het alleen 1 vendor of groep van samenwerkende vendors treffen.

[tonkie_67]

Zoals ik de aanvullende info lees is het 'foute' stuk code van broadcom zelf. Dr isp e/o modemfabrikant kan bij het compileren van de (per isp/modemboer specifieke) firmware alleen met andere credentials compileren; maar als je de firmware file (de binary; de source heb je normaliter niet) door je tools haalt kan je die aangepaste credentials achterhalen.
Dus is toch Brcm (zie overigens ook verderop voor een andere comment van mij mbt Brcm code. (Drivers & firmware)

Edit: momenteel direct hieronder. Post van 2200)

[Reactie gewijzigd door tonkie_67 op 22 juli 2024 22:40]

[Groentjuh]

Het testscriptje kon op mijn modem (een Compal CH7465LG-ZG als router) niets vinden. Het scriptje geeft wel aan dat dat natuurlijk nog niets betekend. Het is mogelijk dat je niet vatbaar bent, maar het kan ook dat de inloggegevens niet kloppen.

[Reactie gewijzigd door Groentjuh op 22 juli 2024 22:40]

[gjs]

De Compal CH7465LG-ZG heeft geen Broadcom chipset, De Technicolor TC7210z heeft dat wel.

[Reactie gewijzigd door gjs op 22 juli 2024 22:40]

[R4gnax]

De Compal CH7465LG-ZG heeft geen Broadcom chipset, De Technicolor TC7210z heeft dat wel.

In oud-Ziggo gebied staan er nog steeds Ubees die destijds uitgeleverd zijn zoals de EVW3200; EVW320B; EVW3210; of EVW321b. Geen idee eigenlijk wat die aan boord hebben, maar vziw is het wel zo dat Ubee ook Broadcom chipsets verwerkt.

[Reactie gewijzigd door R4gnax op 22 juli 2024 22:40]

[leadpumper]

Ik heb een Ubee EVW321B en die is inderdaad vulnerable.

[Steenvoorde]

Ik heb dat script even bekeken, maar volgens mij gaat dit niet werken als je modem in bridge-mode staat. Hij is immers niet direct met mijn LAN verbonden, is dit een correcte aanname?

[TechSupreme]

In bridge modus is het modem onzichtbaar voor de LAN side inderdaad.

[Jerie]

In mijn geval nog prima bereikbaar op 192.168.100.1 ipv 192.168.0.1

[TechSupreme]

Ik heb de Compal CH7465LG-ZG die standaard op 192.168.178.1 staat en hij is niet bereikbaar. Ook even in 192.168.100.1/24 range gescanned en niks. Dit heb getest door mijn laptop direct op het modem in te prikken en mijn laptop een satic IP te geven.

[Reactie gewijzigd door TechSupreme op 22 juli 2024 22:40]

[Powermage]

Hier de Connectbox en ondanks bridging naar mijn eigen router prima bereikbaar op 192.168.100.1

[MrMonkE]

Hoe haal je je modem dan weer uit bridge modus?
Fabrieks reset?!

[TechSupreme]

Zowel het aan en uit zetten doet de Ziggo helpdesk op een afstand.

[Interbert]

In voorheen Ziggo gebied inderdaad alleen de Ziggo helpdesk, maar in oud UPC gebied kan de klant het ook zelf.

[Wildfire]

In bridged mode is de webinterface van het modem nog prima bereikbaar en is het modem vanaf het LAN dus gewoon zichtbaar.

[TFHfony]

Dit is afhankelijk van het type modem. De connectbox is wel toegankelijk, maar de TC7210 bijvoorbeeld is in bridgemode niet meer te benaderen via de webinterface.

[valkenier]

Tuurlijk wel. via http://192.168.178.1

[TFHfony]

Nee hoor, daar ook niet...

[Crazy Harry]

Yep, daar wel, zojuist getest...

[Rinaldootje]

Als je ziggo modem in bridge staat, zul je die kunnen berijken via: http://192.168.100.1

[blorf]

Ik heb geen Ziggo, maar vreemd dan, aangezien bridgen inhoudt dat je modem geen lokaal netwerk hoeft te regelen. De eerstvolgende router/gateway bepaalt wat je lokale subnet wordt, waar het modem als het goed is niks over heeft te vertellen. Blijkbaar geen echte bridge mode of onnodige poespas erbij...

Wat is de host van 192.168.100.1? En wat gebeurt er als je zelf 'toevallig' lokaal subnet 192.168.100 aanhoudt?

[Reactie gewijzigd door blorf op 22 juli 2024 22:40]

[Rinaldootje]

Aangezien Ziggo nog altijd bij "hun" modem moeten kunnen komen, zoals firmware update, bepaalde instellingen voor docsis, waar de klant niet bij mag komen, staat de modem niet in zijn geheel in bridge modus. Er is altijd nog een gedeelte actief. Daarom kunnen zowel de beheerders (Ziggo) als jij nog bij het modem.
Zou ook van de zotte zijn, als je dit wilt terug draaien, dat je er dan niet meer bij kan komen.
Zoals @valkenier hieronder ook al zegt, dit is tevens onderdeel van de docsis specificaties.

[jongetje]

Precies, anders zou telefonie ook lastig worden op een modem in bridge.

[valkenier]

De meeste gebridgede modems zitten op 192.168.100.1 volgens de docsis specs. Alleen de tc7210 doet dat niet, die zit op 192,168.178.1

[Reactie gewijzigd door valkenier op 22 juli 2024 22:40]

[TFHfony]

Nee hoor, daar ook niet.
Ik moest vandaag toevallig toch mijn TC7210 vervangen door een Connectbox dus gelijk even bij de zakelijke helpdesk nagevraagd:

fZiggo -> Modem NIET bereikbaar in Bridge
fUPC -> Modem bereikbaar via 192.168.100.1 en/of 192.168.178.1 (afhankelijk van de configuratie)

[ShadowLord]

Correctie: Bij fZiggo is een Connectbox in bridge mode gewoon bereikbaar op 192.168.100.1 (mits je eigen router dat adres niet blokkeert).

[TFHfony]

Inderdaad... ik zie het hier ook.
De TC7210 deed dat dus niet hier in fZiggo. Die was compleet onbereikbaar. Maar die werd nogal warm en had last van packetdrops. Dus sinds vandaag de trotste gebruiker van een Connectbox... Al zal dat ook nog maar voor 10 dagen zijn ivm overstap op glasvezel.

[arjan1995]

Wat is fZiggo?

[TFHfony]

Geeft aan welk gebied van voor de overname van Ziggo door UPC:
fZiggo -> Oud Ziggo (Casema, @Home, etc...) gebied
fUPC -> Oud UPC gebied

[Durandal]

f van former

[Wim-Bart]

Tuurlijk wel. via http://192.168.178.1

Heb deze dan ook geblocked in myin pfSense doos. Beheer van netwerk componenten zoals mijn ESX, pihole, pfSense kan alleen maar vanaf een specifiek ip adres. Omslachtig maar moet dan mijn systeem handmatig een ip geven.

[sympa]

Hij is wél zichtbaar, op 192.168.100.1 namelijk.
Probeer maar, daar krijg je (als je thusirouter het niet blokkeert) de admin-pagina van het modem, als dat in bridge mode staat.

[TechSupreme]

Even lezen wat hierboven al staat. Jij hebt een ander modem en daarnaast schijnt het dat het anders is per regio.

[sympa]

Eens, maar het is dus niet zo (zoals vaker gemeld) dat een modem in bridge-mode niet manageable is vanaf het LAN. Staat zelfs in de DOCSIS standaard als ik me niet vergis. Dit om mensen te waarschuwen die denken: "ik heb bridge mode, niks aan de hand dus."
Uiteraard zijn er genoeg modems die niet kwetsbaar zijn, en mischien ook wel modems die deze feature niet implementeren.

[D0phoofd]

De exploit werkt op basis van een websocket verbinding. Die werkt echter niet in een webrowser (geen 'standaard' WS protocol zoals ik het las). Daarvoor is deze tool gemaakt om te testen of de verbinding bestaat in het netwerk. Het enige wat je hoeft te doen is

targets = ['192.168.100.1']

aan te passen in het script.

Overigens kan ik mijn Connectbox niet bereiken op het private ip (duh). Als hij in een 'echte' bridge staat, doe het modem allen L2. Je krijgt dus direct een publiek IP op je eigen router.

[Reactie gewijzigd door D0phoofd op 22 juli 2024 22:40]

[Bardman1]

Hmm bridged aka brug. MaW je gebruikt de router als modem. Het routing gedeelte is niet meer bruikbaar en moet je zelf gaan regelen op jouw netwerk, waar van toepasing.

Je krijgt met een dhcp request een publiek ip adres op de netwerkkaart. waarvan je jouw mac adres aan de provider hebt gegeven.

Zoals jij het uitlegt is het een gateway. Werkt ook, en is voor de provider makkelijker om dat ze geen contact met de klant hoeven te hebben. Zelf zou ik dat niet willen, heeft wel wat meer beveiliging nodig maar opnsense gaat daar erg goed me om. (en dat in een Hyper-v omgeving:-))

[tonkie_67]

In bridge mode kan een apparaat ook een ip adres hebben maar dat kan/mag dan niet je gateway ip/next hop zijn.
Wordt ook vaak genoeg gedaan bij switches: je geeft een vlan interface een ip adres maar je gebruikt dat niet als je gateway.
Je kan zelfs een ander subnet gebruiken en sommige mensen denken dat dat extra beveiliging is (niet dus)... maar een apparaat in bridge mode kan prima een ip hebben

[Bardman1]

IDD tegenwoordig kan je meerdere uitleg geven, maar ik ben van de generatie VDU, als je weet wat ik bedoel, en een gateway was toen duidelijk het apparaat waar de naam voor staat, gateway. Als je nu kijkt naar de RFC's is er zoveel uitleg mogelijk. En een bridge ook. maw een brug naar jou pc /server.

Dus bij de één blijft het publieke ip adres op het apparaat (modem/router) en bij de brug verhuist dat publieke ip naar het mac adres, eigenlijk ook IP adres, naar het eerste apparaat NA de modem/ router.
En om die reden moet je het dan ophalen met een DHCP request.

Gateways zijn er al vanaf 1986 een Vlan's zijn er pas vanaf ongeveer 2001 volgens de RFC's

In de RFC's staan dan inmiddels meerdere beschrijvingen van de de diverse hardware, maar er is niet beter dus moeten we het er mee doen. Gelukkig zijn er nog geen fabrikanten die daar hun wil opleggen. MS heeft het geprobeerd maar heeft wat dat betref gefaald. MS standaards, soms goed maar vaak heel erg lock-in, bah.

[tonkie_67]

Ik weet niet of hier een generatieverschil is: zit nog diep in de cli-wereld en verafschuw (meestal) de gui's om hetzelgde te doen.
En rfcs zijn al vrij lang lastig te begrijpen, zelfs op oudere en eenvoudige protocollen (stp,lldp en zelfs snmp: heb vrij geregeld discussies met klanten dat onze switches de rfc al dan niet geimplementeerd hebben en antwoord is zelden zwary/wit...

[Bardman1]

Bedoel ik, maar ik na ook niets beter bedenken. Want om dit aan fabrikanten een of software boeren over te laten.
Altijd een gepuzzel met RFC's, het klopt altijd wel maar dan de interpretatie.
Mijn ervaring is dat de discussies bijna atijd komen omdat bestaande protocollen in de loop der tijd aangevuld worden met meer functionaliteit. Grr weer in de boeken, voor de zoveelste keer, maar hoort bij het vak

[tonkie_67]

Yep.. is er idd met de jaren niet simpeler op geworden. Kijk alleen maar naar RFC1149 met daarna toevoeging van QoS in RFC2549 en vervolgens moest ook de ipv6 implementatie komen via rfc6214
En dat zijn dan ook nog zeer eenvoudige rfcs vergeleken met heel veel andere rfcs

[Steenvoorde]

Dat is het inderdaad, ik had al diverse adressen geprobeerd, maar 192.168.100.1 geeft inderdaad de setup pagina in een browser. Ik krijg trouwens wel een publiek adres op mijn router.

[hcQd]

Ook in bridge is de webinterface van deze modems nog bereikbaar, dus dat zou ik niet op voorhand aannemen.

[Steenvoorde]

Je hebt gelijk. Ik kan de pagina benaderen op basis van het internet IP adres, inloggen lukt niet maar het apparaat is inderdaad zichtbaar.

[HKLM_]

Op mijn technicolor in bridge kan ik op mijn 192.168.178 adres gewoon inloggen op de modem van ziggo.

[The Reeferman]

Dat is een LAN IP adress geen WAN.

[tonkie_67]

Maar de bug werkt ook alleen aan de lan kant, staat in t artikel. Dus waarom verwacht je ergens een wan adres?

[The Reeferman]

Had het niet goed genoeg gelezen blijkbaar, thx voor de verbetering. Moet er nog eens wat meer over lezen.

Was ook een beetje in de war door dat dat onderdeel van de modem blijkbaar wel een rol speelt bij het remote management door de provider.
"Daarnaast gebruiken providers het om op afstand de modem uit te lezen."

En hier had ik ook enige moeite mee voor te stellen hoe dat "in de buurt van een modem" geïnterpreteerd moet worden.
"Eenmaal in de buurt van de modem is het een kwestie van een buffer overflow-aanval en een kwaadwillende kan code uitvoeren vanaf de modem."

[tonkie_67]

Moet ook toegeven dat artikel niet altijd even super opgezet was en als je dan ook een stel vd reacties leest kan je ook de brontxt (deels) vergeten. Gebeurt mij ook vaak genoeg (maar als ik zie/lees hoe fel sommige mefe-tweakers af en toe reageren als een andere tweaker (of auteur) een foutje maakt krijg ik het idee dat ik als enige niet perfect ben.... felheid van reacties slaat imho vaak nergens op.

[ajolla]

In de buurt van het modem kun je proberen via wifi in te hacken?

[Steenvoorde]

Ik krijg alleen een login prompt te zien als ik het externe adres gebruik. Als ik het 192.168.178 adres gebruik dan krijg ik een timeout. Wellicht moet mijn router deze routering ook ondersteunen...

[sympa]

Probeer 192.168.100.1.

[Sorcix]

Het lijkt inderdaad enkel een probleem wanneer je modem rechtstreeks verbonden is met je lokaal netwerk. Helaas is dat bij veel providers het geval omdat ze de modem en router combineren. Heb je een modem, of een modem/router combinatie in bridge, dan lijkt het heel moeilijk te exploiten.

[tonkie_67]

Als je router in een 'router on a stick' setup zou hebben en dus lan en wan in hetzelfde fysieke broadcast domain (ethernet, niet qua ip (sub)netwerk dan kan t alsnog fout gaan. En die setups komen voor..... why I dont know, but it happens). (Of zetten t 192.168 netwerk als secondary adres op de wan kant van router/nat-box zodat ze zelf bij het modem kunnen voor beheer en monitoring (web, snmp of api)....

[Wildfire]

Mijn Ziggo modem staat ook bridged, maar het modem is nog gewoon benaderbaar op zijn webinterface. Dus ik neem aan dat het ook bridged van toepassing kan zijn.

-- Edit: spuit 11. Toen ik het bericht opende stonden die andere reacties er nog niet, ik had sneller moeten typen

[Reactie gewijzigd door Wildfire op 22 juli 2024 22:40]

[kodak]

Hangt van de configuratie af. Bridge sluit niet uit dat er andere manieren zijn waarmee je modem toch bereikbaar is voor beheerfuncties. Je kan het dus beter maar nagaan in plaats van een aanname te doen.

[Bozebeer38]

Vind het qua kwetsbaarheid nog wel meevallen.

Iemand moet met een busje voor je deur staan om in te breken op je modem, of je moet een of andere vage website bezoeken.

Dat laatste lijkt me dan nog het grootste gevaar.

[MikeyV]

Besmette advertenties zijn ook een optie... Je kunt dan een Javascriptje meesturen die de zaak regelt.

[Bozebeer38]

Als besmette JavaScripts al er doorheen komen, is je OS of firewall etc., niet up-to-date.

[MikeyV]

Nadeel is dat de JavaScript in kwestie mogelijk nog niet is opgenomen in de blacklists... En niet vergeten dat ads en besmettingen nog steeds een kat en muisspel zijn.

[blorf]

Je moet eerst een andere kwetsbaarheid gebruiken om of op de configuratiepagina (die voor remote open moet staan) te komen, of buffer-overflow te veroorzaken via wifi.
Het is een 'secundaire' kwetsbaarheid...

[kodak]

Dat is niet helemaal correct. Het uitgangspunt van de onderzoekers lijkt dat er alleen een webinterface in het lan beschikbaar is waarop de aanval dan werkt. Maar bij modems waar door verkeerde of standaard configuratie wel een internetfacing interface bestaat is het dus maar de vraag of die veilig is.

[bartje]

Als ik de kwetsbaarheid lees lijkt he me eenvoudig op te lossen middels firmware update. Dat de provider kan pushen.

[MikeyV]

Dat kan wel maar de ISP moet wel de mogelijkheid houden om het modem op afstand uit te lezen, firmware te pushen en te resetten. Lijkt me een flinke puzzel... Niet vergeten dat de firmware 9 van de 10 keer ISP-name branded is.

[bartje]

Klopt. Maar dan rebounding kan al opgelost worden. Default credentials is wat lastiger. Maar dat maakt het probleem mender dringend. Als het branded is moet de isp naar de leverancier stappen.

[sympa]

De specrtum analyzer op het LAN is bedoeld om monteurs in het huishouden inzicht te geven in de signaalkwaliteit.
Verder gaat het management van kabelmodems meestal via een 10.nogiets IP-adres aan de WAN-kant. Daar kan een attacker hopelijk niet bijkomen.

[kodak]

Wat is eenvoudig?
De ISPs en fabrikanten zullen eerst moeten weten dat de kwetsbaarheid bestaat en in welke producten en versies. Ik lees bij de onderzoekers helaas niet terug dat ze daar heel erg hun best op hebben gedaan om ISPs en fabrikanten te bereiken. Dat komt er dus op neer dat er nog werk nodig is om te zorgen dat ISPs en fabrikanten het wel weten.
Daarnaast is het helaas niet ongewoon dat ISPs en fabrikanten de updates niet altijd meer updaten. Waarschijnlijk zullen de actuele apparaten wel tzt een update krijgen.
Voor modems met automatisch updaten zullen de firmware updates dan makkelijk uit te rollen zijn, maar er zijn in veel netwerken ook veel modems die geen automatische updates accepteren omdat ze bijvoorbeeld van de gebruiker zelf zijn of het beheer is aangepast.

[jhabets]

Op de Ziggo site kan ik nog niets terugvinden daarom maar een vraag in de community gesteld.

https://community.ziggo.nl/veilig-internet-201/aanpak-ziggo-modems-verhelpen-cable-haunt-beveiligingslek-51274

[Inproba]

Heb je het al getest op je eigen modem, dat het daadwerkelijk zo is?

Lees de laatste alinea van het bericht nog eens goed.

[snollygoster]

En dan een telefoontje van de security afdeling van Ziggo krijgen dat je bij deze bent afgesloten wegens het vermoeden van hacken zeker; Ik kijk wel uit..

[kodak]

Ziggo heeft een responsible dislosure policy. Als je verantwoord test mag je er wel op rekenen dat ze daar goed mee om gaan.

[i-chat]

Dus je hebt een remote monitoring systeem dat jij als groot bedrijf bij honderdduizenden klanten draait en.

A: dns rebinding is mogelijk.... dat is behoorlijk knullig, maar niet ongebruikelijk in ouderwetse systemen, ik gok dat dit systeem al zo lang in gebruik is dat het uit de tijd komt waarin beveiliging nog nauwelijks een issue was.
B: er zit een fout in de firmware .... patch die dan?
C: je gebruikt standaard credentials .... (en wat is er mis met een certificaat gebaseerd inlog systeem zoals bijv bij SSH gebruikelijk is? waarom moet je in godsnaam admin/admin of ziggo/welkom gebruiken?

[Reactie gewijzigd door i-chat op 22 juli 2024 22:40]

[Blokker_1999]

Als je A normaal vindt, waarom ben je dan verbaasd om C? Certificaat gebasseerd inloggen vereist toch net wat meer rekenwerk want het is een stuk complexer. En met goede beveiliging zou dat ook geen probleem zijn. Indien de socket enkel toegankelijk was vanuit de ISP dan kon je in principe zelfs zonder login proces werken.

En wat B betreft: je moet je er eerst van bewust zijn dat er een fout in zit voordat je deze kunt verhelpen. En dan is het nog maar de vraag of deze eenvoudig te verhelpen is, of dat de ISPs de modems zullen moeten wissellen.

[blissard]

Als de modems niet te repareren zijn, zou de ISP dan verplicht zijn om de modems te vervangen?

[R4gnax]

Als de modems niet te repareren zijn, zou de ISP dan verplicht zijn om de modems te vervangen?

Vanaf het moment dat de nieuwe EU 2019/770 en /771 richtlijnen gaan gelden zeker.

Maar wss. nu ook al. Als je een modem huurt als onderdeel van je aansluiting, dan valt dat vermoedelijk gewoon onder de dienst die je afneemt. En die moet zonder (veiligheids)problemen werken.

[Terrestrial]

Er zitten nog wel meer lekken in die modems, bijv. ik weet dat het mogelijk is om letterlijk alle modems die Ziggo levert te klonen. Ik weet niet exact hoe ze technisch toegang verkrijgen tot de juiste certificaten, maar ik weet wel dat het al heel lang kan en dus zo lek is als een vergiet. Qua beveiliging lijkt Ziggo ook erg laks, hun Irdeto ACS 0602 smartcards zijn ook al jaren te klonen.

[supersnathan94]

Ziggo is al een paar jaar gestopt met het activeren van smartcards dus ik weet niet of een kloon dan nog werkt. Dat terzijde, volgens mij is dat alleen maar beneficiair voor de klant . Wij hebben bijvoorbeeld nog wel smartcards in gebruik omdat we die horizonbox niet willen (niet betalen, maar ook gewoon niet willen hebben).

[Terrestrial]

Ziggo is niet gestopt met het activeren van irdeto smartcards, ze worden nog steeds geleverd aan mensen in de oude regio's. Alleen kun je zelf geen kaartje meer kopen en laten activeren. Maar dat heeft niks te maken met deze oudere versie van de kaarten, daar zijn er een hoop van in omloop en zolang die blijven werken zullen klonen dat ook doen. En hetzelfde geldt voor modems.

[JB Zimmerman]

Getest met: Thomson TWG 870 wifi-modem

Mijn modem is bereikbaar op 192.168.100.1

Resultaat:
Scanning ports between 23 and 10000 for adresses: ['192.168.100.1']
192.168.100.1 : 23
192.168.100.1 : 80
('192.168.100.1', 23) is not a websocket endpoint (WebSocketException: did not receive a valid HTTP response)
('192.168.100.1', 80) is not a websocket endpoint (WebSocketException: did not receive a valid HTTP response)
We could not find ip and port for spectrum analyzer. This could mean you are not vulnerable or that we did not test for the correct IP, port or credentials. Please refer to the repo if you want to expand the list of IPs, ports and credentials you are scanning.
Thank you for testing your modem, do you want to send your results to Cable Haunt? (Y/n)
n

[kodak]

Welke firmware versie?