Miljoenen apparaten kwetsbaar door zelfde encryptiesleutels
Onderzoekers waarschuwen dat miljoenen apparaten op internet zoals routers, IP-camera's en modems kwetsbaar zijn doordat ze dezelfde encryptiesleutels gebruiken. Aanvallers kunnen hierdoor man-in-the-middle-aanvallen uitvoeren en versleuteld verkeer afluisteren en ontsleutelen.
Daardoor zou gevoelige informatie in verkeerde handen terecht kunnen komen. Het probleem speelt bij zogeheten embedded apparaten, waaronder routers, modems, IP-camera's en VoIP-telefoons. Onderzoekers van beveiligingsbedrijf SEC Consult bekeken voor hun onderzoek de firmware van meer dan 4.000 van dergelijke apparaten, afkomstig van meer dan 70 fabrikanten.
Er werd vooral gekeken naar cryptografische sleutels in de firmware, zoals publieke sleutels, privésleutels en certificaten. Het gaat dan vooral om sleutels die worden gebruikt om verbinding via SSH te maken en X.509-certificaten die voor HTTPS worden gebruikt. In totaal werden bij de ruim 4.000 onderzochte apparaten meer dan 580 unieke privésleutels aangetroffen.
Deze informatie werd vervolgens gecorreleerd met data van grootschalige internetscans. Daaruit kwam naar voren dat de dataset met de 580 unieke sleutels de privésleutels van 9% van alle HTTPS-hosts op het web bevat en de privésleutels van meer dan 6% van alle SSH-hosts. Tenminste 230 van de 580 sleutels werden actief gebruikt en op miljoenen hosts aangetroffen.
De sleutels worden door fabrikanten toegevoegd om verbinding via HTTPS en SSH aan te bieden. Het probleem is dat alle apparaten met de betreffende firmware dezelfde sleutels gebruiken. Opmerkelijk was dat dezelfde sleutels in de producten van verschillende fabrikanten werden aangetroffen. Een certificaat van Broadcom werd bijvoorbeeld in meer dan 480.000 apparaten op internet gevonden, onder andere van Linksys en ZyXEL. Het probleem speelt ook bij Cisco, Huawei, Ubiquiti Networks en andere fabrikanten. De kwetsbare apparaten staan vooral in de Verenigde Staten (26,3%) en Mexico (16,5%).
Oplossing
SEC Consult werkte samen met het CERT Coordination Center (CERT/CC) van de Carnegie Mellon Universiteit om de betrokken fabrikanten alsmede browserontwikkelaars te waarschuwen. Inmiddels hebben sommige partijen updates uitgebracht. Fabrikanten krijgen daarnaast het advies om voor elk apparaat unieke cryptografische sleutels te gebruiken. Daarnaast moeten internetproviders ervoor zorgen dat remote toegang via de WAN-poort tot de apparatuur van hun abonnees niet mogelijk is. Als laatste krijgen eindgebruikers het advies om de generieke SSH-sleutels en X.509-certificaten op hun apparaten door unieke versies te vervangen. Het CERT/CC stelt echter dat in veel gevallen er geen praktische oplossing voorhanden is.
-1 Het doelwit met een netwerkproduct dat met een standaard key/certificaat is ingesteld
-2 Een doelwit dat zelf niet snapt/wil snappen wanneer een verbinding veilig is bij key/certificaatgebruik.
-3 Toegang tot netwerkcommunicatie tussen het doelwit en het netwerkproduct
Bij ingredient 3 heb je als doelwit al een veel groter probleem.
Bij ingredient 2 is het principe van het bestaan van keys/certificaten in het algemeen al teniet gedaan.
Bij ingredient 1 is er een redelijke kans dat het netwerkproduct al via http of zelfs telnet valt te beheren door het doelwit
Hoeveel apparaten zijn er in NL gevonden? Aan de grafiekjes te zien een paar honderd met een administrator interface aan het netwerk hebben geknoopt.
Is het een nieuwe kwetsbaarheid? Nee. Dat het (her)gebruik van standaard keys, certificaten, authenticatiegegevens onderdeel kan zijn van netwerkproducten is niet alleen bij specialisten bekend maar komt ook met enige regelmaat in het nieuws. Een recent voorbeeld: http://www.cio.com.au/article/578415/cisco-warns-default-ssh-keys-shipped-three-products/
Is het genereren van unieke keys/certificaten de oplossing? Zolang het doelwit niet snapt wat veilige communicatie is zet het voor veel scenarios geen zoden aan de dijk. Zet daarnaast dat het doelwit op gebied al meer steken laat vallen (ingredient 3) en er valt nauwelijks winst te behalen met dit lapmiddel.
Moeten producenten van apparatuur die aan netwerken worden geknoopt dan maar doorgaan met het toepassen van niet unkieke keys of certificaten? Nee, maar hoe serieus zijn de producenten met security bezig in hun hele productontwikkeling als je de basisprincipes achter keys en certificaten al niet wenst toe te passen.
Ligt alle blaam bij de producenten? Waarom accepteren de kopers / eigenaren van de apparaten dat een basisonderdeel van veilige communicatie niet op orde is en blijven ze de producten kopen of gebruiken? Snappen ze het principe van de keys en de certificaten wel en vinden ze het belangrijk zelf ook verantwoordelijkheid te nemen als ze een apparaat gebruiken?
Daarnaast moeten internetproviders ervoor zorgen dat remote toegang via de WAN-poort tot de apparatuur van hun abonnees niet mogelijk is.
Dit lijkt mij niet echt wenselijk.
Ik heb het liefst dat mijn provider mij voorziet in een goed werkende verbinding, en zich verder nergens mee bemoeit.
Als ik op mijn modem / router een poort openzet omdat ik iets van buitenaf wil inzien / beheren, is dat mijn keuze, en daarmee ook mijn verantwoordelijkheid om dit degelijk te beveiligen, doe ik dat niet, en wordt er misbruik van gemaakt, is dat ook mijn eigen probleem, ik zie daarom ook geen reden voor een provider om zich hier in te mengen.
Daarom hebben we nu allerlei botnets van embedded apparatuur.
Daarnaast moeten internetproviders ervoor zorgen dat remote toegang via de WAN-poort tot de apparatuur van hun abonnees niet mogelijk is.
Dit lijkt mij niet echt wenselijk.
Ik heb het liefst dat mijn provider mij voorziet in een goed werkende verbinding, en zich verder nergens mee bemoeit.
Als ik op mijn modem / router een poort openzet omdat ik iets van buitenaf wil inzien / beheren, is dat mijn keuze, en daarmee ook mijn verantwoordelijkheid om dit degelijk te beveiligen, doe ik dat niet, en wordt er misbruik van gemaakt, is dat ook mijn eigen probleem, ik zie daarom ook geen reden voor een provider om zich hier in te mengen.
Wat bedoeld wordt in het artikel is denk ik dat de default connectivity op de WAN poort disabled moet zijn, niet op poorten die forwarden naar achterliggende nodes. Dit is voor de meeste (lees:unskilled) gebruikers voldoende. Wil je toch toegang tot het device zelf, bijvoorbeeld ssh naar je router/firewall over het Internet, moet je daar wat voor doen.
Prima uitgangspunt.
Daarnaast moeten internetproviders ervoor zorgen dat remote toegang via de WAN-poort tot de apparatuur van hun abonnees niet mogelijk is.
Dit lijkt mij niet echt wenselijk.
Ik heb het liefst dat mijn provider mij voorziet in een goed werkende verbinding, en zich verder nergens mee bemoeit.
Als ik op mijn modem / router een poort openzet omdat ik iets van buitenaf wil inzien / beheren, is dat mijn keuze, en daarmee ook mijn verantwoordelijkheid om dit degelijk te beveiligen, doe ik dat niet, en wordt er misbruik van gemaakt, is dat ook mijn eigen probleem, ik zie daarom ook geen reden voor een provider om zich hier in te mengen.
Wat bedoeld wordt in het artikel is denk ik dat de default connectivity op de WAN poort disabled moet zijn, niet op poorten die forwarden naar achterliggende nodes. Dit is voor de meeste (lees:unskilled) gebruikers voldoende. Wil je toch toegang tot het device zelf, bijvoorbeeld ssh naar je router/firewall over het Internet, moet je daar wat voor doen.
Prima uitgangspunt.
En toch staat dat niet zo in het artikel; er staat:
Daarnaast moeten internetproviders ervoor zorgen dat remote toegang via de WAN-poort tot de apparatuur van hun abonnees niet mogelijk is.
"moeten zorgen dat .. remote _niet_ mogelijk is"
Je doet een leuke aanname; zekers. Ben ik het er mee eens; ook nog wel.
Maar een aanname..
Assumption is the mother of all f*ckups
Ik heb het liefst dat mijn provider mij voorziet in een goed werkende verbinding, en zich verder nergens mee bemoeit.
Als ik op mijn modem / router een poort openzet omdat ik iets van buitenaf wil inzien / beheren, is dat mijn keuze, en daarmee ook mijn verantwoordelijkheid om dit degelijk te beveiligen, doe ik dat niet, en wordt er misbruik van gemaakt, is dat ook mijn eigen probleem, ik zie daarom ook geen reden voor een provider om zich hier in te mengen.
Op zich valide, maar het zou beter zijn, wanneer je jouw provider moet vragen dit mogelijk te maken. Veel gebruikers snappen er niets van en zijn kwetsbaar zodra op het apparaat zelf de mogelijkheid van remote beheer open staat.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Netwerk Security Engineer
Luchtverkeersleiding Nederland
Als Netwerk Security Engineer ontwerp en optimaliseer je onze technische netwerk- en beveiligingsinfrastructuur. Je stuurt tech-nische veranderingen aan op basis van de gestelde architectuur kaders en helpt mee met de uitvoering ervan. Ben jij een gedreven professional met passie voor netwerk-beveiliging? Dan is deze functie als Netwerk Security Engineer bij Luchtverkeersleiding Nederland (LVNL) iets voor jou!
Lead Network Security Engineer
Luchtverkeersleiding Nederland
Word Lead Network Security Engineer bij LVNL. Ontwerp en implementeer security-oplossingen die de luchtverkeersleidings-systemen veilig houden. Solliciteer nu en draag bij aan onze cyberweerbaarheid! Als Lead Network Security Engineer bij LVNL ben je verantwoordelijk voor het ontwerpen, implementeren en optimaliseren van de netwerkbeveiliging die cruciaal is voor de veilige en efficiënte werking van het luchtverkeersleidingssysteem in Nederland.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?