Agentschap Telecom zet formulier online voor melden onveilige iot-apparatuur

Het Nederlandse Agentschap Telecom heeft een formulier online gezet die mensen kunnen gebruiken om gebrekkige beveiliging in iot-apparatuur aan te melden. Het Agentschap neemt dan vermoedelijk contact op met de betrokken fabrikanten.

Het formulier heeft een tekstvak voor merk en typenummer van de apparatuur en een omschrijving van de manier waarop de beveiliging tekortschiet. Als voorbeelden geeft het AT routers met een makkelijk standaardwachtwoord, babyfoons waarbij derden kunnen meekijken en kindertablets zonder automatische software-updates.

Met het meldpunt loopt het Agentschap vooruit op Europese regels rondom beveiliging van op iot-apparatuur. Het AT heeft ook onderzoek laten doen naar de beveiliging van enkele tientallen populaire iot-apparaten. Van de 22 apparaten waren er twee zonder makkelijk te vinden beveiligingsproblemen: Nest Learning-thermostaat V3 en de babyfoon Alecto IVM-100.

Veel van de beveiligingsproblemen zijn wel ernstig, maar niet kritiek. De Huawei B315s-22, een 4g-router, haalt updates binnen via een niet beveiligde http-verbinding. Ook diverse speelgoeditems bleken slecht beveiligd. Een RC Spy Tank met camera bleek helemaal geen beveiliging te hebben. Het onderzoek richtte zich op routers, speelgoed, ip-camera's en slimme sloten. De onderzoekers keken onder meer updates en voerden scans uit met beveiligingsoftware Nessus.

Reacties (31)

[michielRB]

Princeton heeft op dit moment een onderzoeksproject lopen naar het gedrag van IoT apparaten. Een applicatie wordt lokaal geinstalleerd op je LAN en is in feite een verpakte Wireshark. Logs worden naar servers van Pinceton geupload en jouw logs zijn en blijven voor jou beschikbaar.
De logs worden verder volledig geanonimiseerd voor het onderzoek.
https://iot-inspector.princeton.edu/
Ik denk er zelf toch sterk aan om dit te gaan installeren, ondanks dat ik maar zeer beperkt aantal IoT apparaten heb. Ik ben in mijn situatie overigens banger voor Android apps geinstalleerd op de teelfoons van met name mijn kinderen. (zelf heb ik bijv LineageOS zonder GAPPS op mijn telefoon, wat het phone-home gevaar al een stuk kleiner maakt.)

[beany]

Goed initiatief, maar waarom moet het melden via een PDF Wat is er mis met een formulier op de website die je kan invullen?

[dutchmartin]

Omdat het agentschap Telekom niet veel digitaal heeft. Toen ik daar mijn marifooncertificaat wilde aanvragen moest dat ook op papier.

[PorcupineTree]

Het PDF formulier is nu vervangen door een webformulier. Makkelijker te gebruiken.
Omdat je geen formulier meer per email hoeft te versturen, is het ook makkelijker om anoniem te melden, als je dat wil.

[bazs2000]

Genoeg IoT-apparaten op Linux die gewoon onveilig zijn hoor.

[jpsch]

Website geeft aan dat pdf met Mac of Windows gebruikt moet worden.

[bazs2000]

En wie Linux gebruikt weet dat dit niet persé nodig is, ik snap het probleem niet zo.

[MrMonkE]

"De Huawei B315s-22, een 4g-router, haalt updates binnen via een niet beveiligde http-verbinding."



Echt.. dat kun je toch niet maken anno 2019.
Misschien was het een vereiste ..

[1337aldi]

Met HTTPS is er weer een volgend probleem: het up to date houden van het benodigd certificaat. Wat doe je als het certificaat is verlopen? Firmware update downloaden gaat niet (met het nieuwe certificaat), omdat HTTPS niet meer werkt.

[Reactie gewijzigd door 1337aldi op 23 juli 2024 13:31]

[VHware]

Automatiseren met Let’s Encrypt bv

[wica]

Op de server, die gebruikt wordt om updates vanaf te halen. Hoeft alleen het certificaat up to date gehouden te worden.
Mocht je device zodanig lang niet geupdate zijn, dat je device verouderde root certificaat heeft of libraries bevatten, die de dan geldende standaard niet onder steunen. Dan mag dat betreffende devices alle functies uitschakelen, waardoor die alleen nog te updaten is door middel van fysieke toegang tot dat betreffende device.

Ik heb totaal geen bezwaar tegen een killswitch, zolang ik zelf maar de software kan aanpassen. Waarna het een risico is, wat ik zelf voor gekozen heb.

[Falcon]

Daar zijn diverse oplossingen voor, geen reden om het niet te doen.

[1337aldi]

Voor linux gebaseerde IOT apparaten is het inderdaad niet zo moeilijk, maar ik doelde meer op de wat kleinere devices, die niet linux draaien.

[Falcon]

Heb je een voorbeeld?

[wica]

Devices die gebruik maken van o.a. het LoRa netwerk, die 10 jaar met 2 batterijen doen.
Dit netwerk is zodanig langzaam, dat we het hebben over 300bps t/m 22kbps.

Dit soort devices hebben dus eigenlijk niet de accu capaciteit en snelheid om een volledige update binnen te halen. Wat vaak in de vorm van een hele firmware is.

[Falcon]

Maar het ging over het veilig (en in dit specifieke geval HTTPS (met certificaten)) ophalen van een update (incrementeel of volledig).

Niet over bandbreedte en accu capaciteit.

Ik kan mij voorstellen dat de updates voor dit soorten devices dmv andere (beveiligde) protocollen worden gedistribueerd.

[1337aldi]

Bijvoorbeeld Ikea's smart home producten, die schijnbaar ook updates doen over HTTP ipv. HTTPS, zie : https://mjg59.dreamwidth.org/47803.html . Omdat de updates zelf signed zijn vormt dit geen (?) risico.

[Falcon]

Op basis van dit artikel zie ik nog steeds geen reden waarom de IKEA smart producten geen HTTPS gebruiken.

Even los van dat de firmwares zelf signed zijn.

[sfc1971]

Dan update je toch het certificaat voordat het verlopen is? Zie het probleem niet.

[smiba]

Tja aan de andere kant, als de updates signed zijn kan je ook moeilijk er narigheid instoppen.

Of https nou zo veel moeite was geweest is een andere kwestie

[MrMonkE]

Ja, jij en @1337aldi hebben een goed punt

[jurroen]

Jawel. Signed firmware is beter dan HTTPS.

Slides van de OpenBSD package manager, maar de informatie gaat ook op voor firmware

[D_Jeff]

"Scan met Nessus"

Kortom, iedereen met Backtrack / Kali Linux en de juiste updates van Metasploit had dit dus ook kunnen ontdekken.
Nessus draait onder water een aangepaste versie van Metasploit: Een stukje payload scripting hoeft niet meer gedaan te worden. Verder nog wel de 'bewuste' limitatie van 1 exploit per scan kunnen gebruiken

Het extraatje hierin is het mooie pdf rapportje voor de manager

(er zijn mooiere automated pentest tools op de markt de alle know sh*t scannen in 1 scan. Ik vrees dat er dan wellicht nog meer gevonden wordt, qua Security)

[defixje]

Ja ik dacht daar dus ook aan toen ik het las. Beetje apart.

Maar als het maar veiliger wordt, dat is het doel.

[CAPSLOCK2000]

Het AT heeft ook onderzoek laten doen naar de beveiliging van enkele tientallen populaire iot-apparaten. Van de 22 apparaten waren er twee zonder makkelijk te vinden beveiligingsproblemen:

Zouden we het niet moeten omdraaien en (ook) een register maken met apparaten die wel veilig zijn?
Het is natuurlijk fundamenteel onmogelijk om te bewijzen dat een apparaat echt veilig is, maar een goed keurmerk dat de belangrijkste zaken controleert zou welkom zijn.
Want met zoveel onveilige apparaten wordt het anders behoorlijk lastig om nog iets te kopen. Als 9/10 keer blijkt dat het apparaat dat je hebt uitgezocht onveilig is dan hebben mensen er snel genoeg van.
Daarbij weet je nog niks als een apparaat niet in het register van onveilige apparaten staat, want er is vast een hoop naamloze Chinese troep die in zo'n kleine oplages verkocht wordt dat het lang kan duren voor die in het register komt.

[GreatDictator]

Zouden we het niet moeten omdraaien en (ook) een register maken met apparaten die wel veilig zijn?

Sowieso een stuk makkelijker gezien de enorme hoeveelheid onveilige IoT-apparaten.

[01--Rolf--01]

Definitie wat is onveilig?
Dan hoe weet jij dat iemand iemand anders op jouw iot-apparatuur kan meekijken dan wel inloggen?

[wica]

Er komt vast een keurmerk, die dit oplost voor de consument.

[01--Rolf--01]

Best een goed idee deze tool thanks voor de info ( hier draaien 3xcams Pi Domoticz ESP NAS wil best wel weten of er iemand anders ook hiermee connectie heeft )