Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

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.

Door Mark Hendrikman

Nieuwsposter

12-01-2020 • 12:19

118 Linkedin Google+

Reacties (118)

Wijzig sortering
Kan je specifieren welke modem precies? Dank!
Model van type “24*8 DOC 3 EMTA(DOCSIS)” volgens de info op “mijn telenet”
Dat is dus gewoon een docsis 3 met 24 down en 8 up channels.
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. :D :D

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
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.
Precies, anders zou telefonie ook lastig worden op een modem in bridge.
Even lezen wat hierboven al staat. Jij hebt een ander modem en daarnaast schijnt het dat het anders is per regio.
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.
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.
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...
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
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 _/-\o_ _/-\o_ }:O
Maar de bug werkt ook alleen aan de lan kant, staat in t artikel. Dus waarom verwacht je ergens een wan adres?
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."
In de buurt van het modem kun je proberen via wifi in te hacken?
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)....
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.


Om te kunnen reageren moet je ingelogd zijn


Apple iPhone 11 Microsoft Xbox Series X LG OLED C9 Google Pixel 4 CES 2020 Samsung Galaxy S20 4G Sony PlayStation 5 Nintendo Switch Lite

'14 '15 '16 '17 2018

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2020 Hosting door True