Onderzoek: thuisrouters vol kwetsbaarheden en hard-coded wachtwoorden
De beveiliging van routers voor eindgebruikers laat ernstig te wensen over. De apparaten zitten vol bekende kwetsbaarheden, maken vaak gebruik van hard-coded wachtwoorden en ontvangen lange tijd geen beveiligingsupdates, zo blijkt uit onderzoek van het Fraunhofer Institute for Communication, Information Processing and Ergonomics FKIE (pdf).
Voor het onderzoek werden 127 routers van zeven grote leveranciers onderzocht. De onderzoekers hadden zich van tevoren vijf onderzoeksvragen gesteld: wanneer was het apparaat voor het laatst geüpdatet, welke OS-versie werd er gebruikt en hoeveel bekende kwetsbaarheden zijn hierin aanwezig, welke exploitmitigatietechnieken zijn er toegepast, bevatten de firmware-images privésleutels en wordt er van hard-coded wachtwoorden gebruikgemaakt.
De onderzoekers noemen de resultaten alarmerend. Elke router bleek meerdere kwetsbaarheden te bevatten. 46 routers hadden al meer dan een jaar geen beveiligingsupdate ontvangen. In veel routers waren honderden bekende beveiligingslekken aanwezig en zelfs wanneer routers werden geüpdatet, werden veel van deze bekende kwetsbaarheden niet verholpen.
Tevens blijkt dat routerfabrikanten zelden technieken toepassen die misbruik van kwetsbaarheden moeten voorkomen of bemoeilijken en maakt een aanzienlijk deel gebruik van hard-coded wachtwoorden. De onderzoekers stellen dat fabrikant AVM het beter doet dan de andere leveranciers als het om security gaat, maar ook in de apparaten van AVM werden problemen aangetroffen. Verder doen Asus en Netgear het op sommige aspecten beter dan D-Link, Linksys en TP-Link. De zevende fabrikant die werd getest was Zyxel.
Het grootste deel van de onderzochte routers draait op Linux (91 procent). Een probleem is echter dat het vaak om oudere versies gaat. Zo gebruikt meer dan een derde van de routers Linux-kernel versie 2.6.36 of ouder. De laatste update voor 2.6.36 verscheen in februari 2011. Dit zorgt ervoor dat de routers vaak tal van kwetsbaarheden bevatten. De "beste" routers hadden tenminste 21 kritieke kwetsbaarheden en 348 beveiligingslekken die als "high" waren beoordeeld. Gemiddeld bevatten de routers 53 ernstige beveiligingslekken. De meeste kwetsbaarheden met het stempel high worden in de Linksys WRT54G aangetroffen, namelijk 579.
Wachtwoorden
Een ander onderdeel van het onderzoek richtte zich op de aanwezigheid van hard-coded wachtwoorden. Dit zijn wachtwoorden die meestal niet door de gebruiker zijn te wijzigen, voor elk product hetzelfde zijn en niet zomaar door systeembeheerders zijn uit te schakelen.
Het beruchte Mirai-botnet maakte gebruik van hard-coded Telnet-wachtwoorden om honderdduizenden IoT-apparaten te compromitteren. Ondanks het risico van dergelijke wachtwoorden vonden de onderzoekers in vijftig routers hard-coded wachtwoorden. Daarnaast bleken zestien routers eenvoudig te raden of bekende wachtwoorden te bevatten. Alleen in de firmware-images van Asus werden geen hard-coded wachtwoorden aangetroffen.
Privésleutels
Daarnaast zochten de onderzoekers naar de aanwezigheid van privésleutels , die bijvoorbeeld voor het signeren van data worden gebruikt of voor het beveiligen van de communicatie. De aanwezigheid van een privésleutel in de firmware is een risico, aangezien een aanvaller hiermee het apparaat kan nabootsen en man-in-the-middle-aanvallen kan uitvoeren, aldus de onderzoekers. Alleen op AVM na werden er in de firmware van alle fabrikanten privésleutels aangetroffen. Gemiddeld gaat het om vijf sleutels per firmware-image. De Netgear R6800 spant met dertien privésleutels op één apparaat de kroon.
"Samengevat laat ons onderzoek zien dat er geen enkele router zonder kwetsbaarheden is en geen enkele leverancier het op alle securityvlakken perfect doet. Er moet veel meer worden gedaan om thuisrouters net zo veilig als huidige desktops en servers te maken", zo concluderen de onderzoekers.
Maar wat ik zou willen weten is: wat kunnen gebruikers doen om zo min mogelijk last van de aanwezige kwetsbaarheden te hebben, en in hoeverre helpt dit?
Bijv. als je de default zwakke inlogcredentials wijzigt in je eigen (sterke) credentials dan is dit punt toch uit de wereld?
Ook ben ik benieuwd in hoeverre er mogelijkheden zijn om vanaf de WAN de boel onveilig te maken als remote login disabled is. Uitgaande dus van de doorsnee praktische situatie (met verstandige instellingen),
en niet uitgaande van wat er "theoretisch" of "met default instellingen" allemaal aan mankeert.
Immers aanwezigheid van veel kwetsbaarheden is één ding.
Maar je gaat hier pas echt last van krijgen als een (externe) attacker er in de praktijk ook daadwerkelijk vrij gemakkelijk bij kan en dit hem wat oplevert terwijl jij er als gebruiker schade door lijdt.
Ik vraag me alleen af hoe ze dat dan doen, want uiteindelijk heeft de router wel een private key nodig. (en inderdaad niet overal een identieke private key die iedereen uit de firmware kan kopiëren) De router zal die key zelf aanmaken. Als hij die zelf ondertekend, moet je allerlei capriolen uithalen om hem door de browser goedgekeurd te krijgen. Of je laat hem extern ondertekenen. Ik ken alleen Lets's Encrypt waar dat geautomatiseerd en gratis kan. Maar dan heb je wel een domeinnaam nodig.
Ben benieuwd hoe AVM dat gebruikersvriendelijk doet.
Is dit niet een algemeen probleem wat speelt bij veel IoT oplossingen, dus niet alleen routers/modems.
Alleen komt het in dit rapport nu naar voren voor Thuisrouters...
Heb thuis ook nog een "oude router" liggen, echter gebruik deze nu alleen als een Switch. (Alleen LAN, geen Wifi)
Zelf heb ik deze router een statisch IP adres gegeven zonder Gateway, oftewel kan niet meer routeren naar het internet.
Ik weet dat er oude firmware op zit, helaas zijn er ook geen updates meer voor.
Je kan mogelijk alleen deze router aanvallen als je al op het interne netwerk zit.
AVM doet wel meer goed op de Fritz box . Voor diverse (? alle) , maar zeker security relevante instellingen moet je de config wijziging bevestigen door een knop op de router in te drukken, of een nummer te bellen met een aangesloten telefoon.
En management kan (standaard) alleen vanaf de LAN zijde.
Dat is een heel grote barriere voor hackers die via een browser exploit of desktop overname de router ongemerkt willen herconfigureren - er moet iemand fysiek iets doen die ter plaatse is.
(Je ziet soms klagers erover die fritzboxen op meerdere sites beheren. Dat gaat dan niet. - ja, end-user security betekent inderdaad 'remote beheer' moeilijk of onmogelijk maken)
dat gaat me iets te vlug. Linux valt heel lean en mean op te zetten waarbij alle extra modules en dingen die je op een router niet nodig hebt en dan heb je dus ook niet zo veel aan updates aan modules of drivers die niet gebruikt en niet aanwezig zijn in die kernel of op die router.
je kunt lezen uit de .pdf van het rapport:
" We just have look at the Linux Kernel versions,because it is the most used OS as presented in section 2.1. FACT detects the Kernel Version bya regular expression and verifies that the file is not a text file3. This reduces the chance of falsepositives because configuration or documentation files are ignored. Finally, we have a look atthe number of known vulnerabilities in this kernel versions. "
er is dus niet gekeken of een vulnerability op een kernel version dan daadwerkelijk ook op de router / in de firmware aanwezig is.
maargoed het rapport zit vol met mooie grafiekjes en plaatjes, dus het zal wel weer helemaal geweldig zijn :P
off-topic:
dit zelfde gedonder heb ik ook regelmatig met die security audit rakkers die met een eenvoudige Nessus of Outpost niet verder kijken dan een versie nummer en nog nooit van backporting oid gehoort hebben: https://access.redhat.com/security/updates/backporting/. hoe vaak ik niet uit de RPM changelog dan de CVEs haalt die wel gefixed zijn en laat zien dat er geen issue is. zucht, een fool with a tool...
Ik vraag me alleen af hoe ze dat dan doen, want uiteindelijk heeft de router wel een private key nodig. (en inderdaad niet overal een identieke private key die iedereen uit de firmware kan kopiëren) De router zal die key zelf aanmaken. Als hij die zelf ondertekend, moet je allerlei capriolen uithalen om hem door de browser goedgekeurd te krijgen. Of je laat hem extern ondertekenen. Ik ken alleen Lets's Encrypt waar dat geautomatiseerd en gratis kan. Maar dan heb je wel een domeinnaam nodig.
Ben benieuwd hoe AVM dat gebruikersvriendelijk doet.
Mijn AVM Fritz box genereert een self-signed certificaat .
Geldig voor
The certificate is only valid for the following names: <WAN IPv4>,<WAN IPv6>, fritz.box, www.fritz.box, myfritz.box, www.myfritz.box, fritz.nas, www.fritz.nas
(idd niet geldig voor het LAN-ip ).
dit zelfde gedonder heb ik ook regelmatig met die security audit rakkers die met een eenvoudige Nessus of Outpost niet verder kijken dan een versie nummer en nog nooit van backporting oid gehoort hebben: https://access.redhat.com/security/updates/backporting/. hoe vaak ik niet uit de RPM changelog dan de CVEs haalt die wel gefixed zijn en laat zien dat er geen issue is. zucht, een fool with a tool...
Juist auditors die goed hun werk doen. Complimenten aan hun werken.
dit zelfde gedonder heb ik ook regelmatig met die security audit rakkers die met een eenvoudige Nessus of Outpost niet verder kijken dan een versie nummer en nog nooit van backporting oid gehoort hebben: https://access.redhat.com/security/updates/backporting/. hoe vaak ik niet uit de RPM changelog dan de CVEs haalt die wel gefixed zijn en laat zien dat er geen issue is. zucht, een fool with a tool...
Juist auditors die goed hun werk doen. Complimenten aan hun werken.
Nee, geen complimenten.
Een versienummer van een applicatie is geen exacte identificatie van 100% unieke code.
Het identificeert de upstream versie van een bepaalde code , en daarmee gesupporte features, verwachte configuratie stijl etc.
De _exacte_ versie wordt geidentificeerd op basis van de rpm of debian package.
De upstream applicatie kan besluiten een issue pas te fixen vanaf een latere release - terwijl de distributie een langere support garantie heeft op de oudere versie .
Het is voor een distributie niet acceptabel om naar een veel nieuwere upstream release te gaan - met bijna de garantie dat dingen anders werken of stoppen met werken bij hun klanten.
Dus zal de distributie fixes , en soms features, backporten naar de versie die in de distributie gebruikt wordt.
Je kunt gewoon niet altijd de _exacte_ versie aan de buitenkant herkennen . Auditors horen dat te weten.
dit zelfde gedonder heb ik ook regelmatig met die security audit rakkers die met een eenvoudige Nessus of Outpost niet verder kijken dan een versie nummer en nog nooit van backporting oid gehoort hebben: https://access.redhat.com/security/updates/backporting/. hoe vaak ik niet uit de RPM changelog dan de CVEs haalt die wel gefixed zijn en laat zien dat er geen issue is. zucht, een fool with a tool...
Juist auditors die goed hun werk doen. Complimenten aan hun werken.
onzin. noob auditors kijken alleen naar een base versie nummer, en niet naar de built nummer van een distro en als ze dat wel zouden doen en de changelog zouden checken, dan is alles weer goed, dat een eenvoudige noob auditor dit niet snapt /weet, betekent niet dat dat niet kan. elke keer krijg je de discussie en daarna de 'oh ja' enlightenment maarja, jaartje verder weer een verse nieuwe noob auditor en het rondje gebeurt weer.
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?