image

Duitse overheid zet laatste stap richting veiligheidskeurmerk voor routers

maandag 6 juli 2020, 11:12 door Redactie, 5 reacties

De Duitse overheid heeft een specificatie opgesteld om de veiligheid van routers te testen, waarmee de laatste stap richting een veiligheidskeurmerk voor routers is gezet. Twee jaar geleden publiceerde het Bundesamt für Sicherheit in der Informationstechnik (BSI), onderdeel van het Duitse ministerie van Binnenlandse Zaken, technische beveiligingsrichtlijnen voor routers voor particulieren.

Routers spelen een steeds grotere rol in de digitalisering van het huishouden en zijn daarmee een aantrekkelijk doelwit voor aanvallers, aldus het BSI. Met de publicatie van de richtlijn hoopt het BSI om routers beter bestand tegen aanvallen te maken. Zo moeten routers updates kunnen ontvangen. Verder moeten fabrikanten melden hoelang ze de router blijven ondersteunen en moeten ze ernstige kwetsbaarheden patchen. Ook moet de router over een firewall beschikken, geen onnodige diensten draaien en moet elke router een eigen uniek "preset" wachtwoord krijgen.

In samenwerking met testcentra, fabrikanten, telecomproviders en maatschappelijke organisaties is er nu een specificatie opgesteld waarmee kan worden getest of routers aan de richtlijnen van het BSI voldoen. Het opstellen van de testspecificatie was ook de laatste stap om een veiligheidscertificering voor routers mogelijk te maken. De Duitse overheid wil straks een veiligheidskeurmerk introduceren waarmee gebruikers eenvoudig kunnen zien dat het apparaat aan de veiligheidseisen voldoet. Het BSI roept nu testcentra en beveiligingsproviders op om hun medewerkers te laten erkennen als examinator van de beveiligingsrichtlijn.

Reacties (5)
06-07-2020, 12:00 door [Account Verwijderd] - Bijgewerkt: 06-07-2020, 12:00
De standaard ligt niet erg hoor als ik het zo lees, maar wellicht is dat noodzakelijk voor partijen als Huawei (die geholpen hebben bij het 'testen' van deze richtlijn). Wel WPA2 verplichten, maar nergens WPA3 noemen als MUST of SHOULD. Nergens melding gemaakt van Protected Management Frames (als MUST of SHOULD) om deauthenticatie aanvallen te voorkomen.

Mooi stukje nog: "To prevent attacks on secured connections and on the router itself all (private) cryptographic keys and secrets MUST NOT be shared by multiple devices in the factory setting and initialized state." Daar kunnen ze bij KPN nog wat van leren, als je het verlopen certificaat (mijnmodem.kpn) debacle hebt meegekregen van vandaag.
06-07-2020, 12:03 door Erik van Straten - Bijgewerkt: 06-07-2020, 12:08
Hoewel in TR03148.pdf in "2.3 Threat Model" (pagina 14) in de tekst en figuur 2 wordt onderkend dat een aanvaller aan LAN/WLAN zijde een bedreiging vormt, zie ik (tenzij ik met m'n neus kijk) alleen authenticatie-eisen voor gebruikers (beheerders in dit geval), niet voor de router zelf.

Nb. verderop in TR03148.pdf wordt er verwezen naar TR-02102-2 (te vinden in https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-2.html) maar daarin staan geen eisen aan het soort certificaten dat je zou moeten gebruiken.

Als authenticatie van de router niet goed geregeld is, kan een MITM de gebruiker laten denken dat hij zijn wachtwoord invoert op de inlogpagina van de router, terwijl het gaat om een device waar de aanvaller toegang tot heeft. Met het zo verkregen wachtwoord kan de aanvaller vervolgens op de echte router inloggen.

Zie ook https://security.nl/posting/640348/IoT+authenticiteit en mijn bijdrage https://security.nl/posting/663515 over KPN die in al haar Experiabox V10A modems dezelfde private key en (recentelijk verlopen) PKI-overheid certificaat inzet. Zo moet het dus niet wat mij betreft, het BSI zou hier verstandige eisen voor moeten bedenken en opnemen.

Aanvulling:
Door iatomory: Mooi stukje nog: "To prevent attacks on secured connections and on the router itself all (private) cryptographic keys and secrets MUST NOT be shared by multiple devices in the factory setting and initialized state." Daar kunnen ze bij KPN nog wat van leren, als je het verlopen certificaat (mijnmodem.kpn) debacle hebt meegekregen van vandaag.
Ah dank daarvoor, heb ik toch met m'n neus gekeken want dat stukje heb ik gemist! Wel jammer dat de BSI geen concrete suggesties doet hoe je dit kip/ei probleem oplost - want lastig is dit gewoon wel, vooral voor doorsnee gebruikers.
06-07-2020, 12:13 door [Account Verwijderd] - Bijgewerkt: 06-07-2020, 12:14
Door Erik van Straten: Ah dank daarvoor, heb ik toch met m'n neus gekeken want dat stukje heb ik gemist! Wel jammer dat de BSI geen concrete suggesties doet hoe je dit kip/ei probleem oplost - want lastig is dit gewoon wel, vooral voor doorsnee gebruikers.
Een aardige beschrijving van hoe Plex dit probleem heeft opgelost is te lezen op https://blog.filippo.io/how-plex-is-doing-https-for-all-its-users/. Maar dat is dus een oplossing die de router maker zou moeten uitrollen, niet iets wat je als gebruiker kunt implementeren. Althans, niet eenvoudig lijkt mij.
06-07-2020, 14:09 door Anoniem
Door iatomory:
Door Erik van Straten: Ah dank daarvoor, heb ik toch met m'n neus gekeken want dat stukje heb ik gemist! Wel jammer dat de BSI geen concrete suggesties doet hoe je dit kip/ei probleem oplost - want lastig is dit gewoon wel, vooral voor doorsnee gebruikers.
Een aardige beschrijving van hoe Plex dit probleem heeft opgelost is te lezen op https://blog.filippo.io/how-plex-is-doing-https-for-all-its-users/. Maar dat is dus een oplossing die de router maker zou moeten uitrollen, niet iets wat je als gebruiker kunt implementeren. Althans, niet eenvoudig lijkt mij.
Dank voor de link naar Plex

Over je eerdere opmerking: wat is "hoog"? Ik denk dat deze standaard ervoor gaat zorgen dat het merendeel van de routers af gaat vallen en daarmee op den duur de veiligheid omhoog gaat. Zo moeten de gecertificeerde routers (naast veilige basis instellingen) nu patched krijgen, en dat die voor een "high severity" issue (CVSS van >6.0) snel een patch moet komen (snel als in: "without undue delay", en dat van te voren bekend is tot hoe lang die patches geleverd gaan worden.

Kortom: iedereen die daarna een niet-gecertificeerde router koopt weet dat hij daarmee een probleem heeft. Wat mij betreft een verbod op dat soort routers.
06-07-2020, 22:12 door Erik van Straten
Door iatomory: Een aardige beschrijving van hoe Plex dit probleem heeft opgelost is te lezen op https://blog.filippo.io/how-plex-is-doing-https-for-all-its-users/.
Het is een interessante aanpak, maar ik zie nergens hoe je zeker weet dat de hash in een domeinnaam *.hash.plex.direct van de betreffende server is en niet (tevens) aan een andere server toegekend kan worden.

Rekening houdend met het risico van DNS rebinding attacks zie ik ook niet zo snel hoe dit veilig zou kunnen zijn voor routers met uitsluitend beheertoegang aan LAN/WLAN zijde.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.