Kwetsbaarheid in tcp/ip-stack maakt rce's en DoS op iot-apparaten mogelijk

Beveiligingsonderzoekers hebben kwetsbaarheden ontdekt in vier veelgebruikte tcp/ip-stacks die voor dns in internet-of-thingsapparaten worden gebruikt. Door die kwetsbaarheden uit te buiten is het mogelijk apparaten offline te halen of over te nemen.

Het gaat om negen verschillende kwetsbaarheden die werden ontdekt door beveiligingsbedrijf Forescout. Dat vangt de kwetsbaarheden samen onder de noemer Name:wreck. Zeven van die kwetsbaarheden zitten in de tcp/ip-stack van Nucleus NET en NetX, een zit in FreeBSD en er zit er een in IPnet. Inmiddels heeft Forescout contact opgenomen met deze organisaties. De kwetsbaarheden zouden gerepareerd zijn in die stacks, al moeten fabrikanten van bijvoorbeeld iot-apparaten die wel nog doorvoeren.

De exploits hebben in de meeste gevallen betrekking op de dns-server en hoe die namen valideert bij het parsen of bij het comprimeren. Daardoor is het mogelijk een denial-of-service uit te voeren en een apparaat offline te halen, en in sommige gevallen zelfs om een remote code execution mogelijk te maken.

Praktische uitbuiting van de kwetsbaarheden vereist wel dat een aanvaller toegang heeft tot het interne netwerk van een slachtoffer. Forescout noemt daarbij een van de negen kwetsbaarheden die in Nucleus NET kunnen worden uitgevoerd. In een voorbeeld beschrijft Forescout ook dat een aanvaller vervolgens een eigen dhcp-server moet opzetten waarmee een eigen dns kan worden gepusht naar het apparaat.

CVE	Stack	Kwetsbaarheid	Score
CVE-2020-7461	FreeBSD	Remote code execution	7.7
CVE-2016-20009	IPnet	Remote code execution	9.8
CVE-2020-15795	Nucleus NET	Remote code execution	8.1
CVE-2020-27009	Nucleus NET	Remote code execution	8.1
CVE-2020-27736	Nucleus NET	Denial-of-service	6.5
CVE-2020-27737	Nucleus NET	Denial-of-service	6.5
CVE-2020-27738	Nucleus NET	Denial-of-service	6.5
CVE-2021-25677	Nucleus NET	Dns-spoofing	5.3
CVE-2021-25677	NetX	Denial-of-service	6.5

Reacties (45)

[Boudewijn]

Waar ik vooral van schrik is dat die kwetsbaarheid in IPnet (met CVSS score 9.8...) een CVE-2016* ID heeft gekregen. Dat impliceert dat dat CVE dus al 4.5 jaar geleden toegewezen is, en de kwetsbaarheid al even bekend is. Waarom is dit niet in een redelijke termijn gefixed? Okay het product wordt niet meer gesupport door vxWorks, maar dit is wel een heel ernstige ...

Dat bugs (en dus in mindere mate kwetsbaarheden) worden gevonden is prima en hoort erbij, maar traag fixen is niet zo prima.

[Reactie gewijzigd door Boudewijn op 26 juli 2024 01:51]

[bzzzt]

Dat is met de hele embedded markt een probleem. Producten worden gebouwd rond een specifieke versie van een OS, eventueel goedgekeurd en blijven dat levenslang draaien. Als je klanten niet om een update staan te schreeuwen ga je zelf ook niet hard lopen.
Nu is niet iedere kwetsbaarheid even problematisch. Als er geen IP stack ingeschakeld is zal het voor veel producten niet uitmaken welke lekken daar in zitten...

[Reactie gewijzigd door bzzzt op 26 juli 2024 01:51]

[Boudewijn]

Klopt maar veel devices van de laatste 5 jaar hebben wel een op stack... Die ook zomaar aan een netwerk kan hangen. Als je dit al 5 jaar weet als fabrikant en er niets aan doet... Tsja dat noem ik eigenlijk wel kwalijk. Het is echt een heel serieuze kwetsbaarheid, dit is gewoon een recept voor de volgende mirai-like iot worm als je heel cynisch bent. Gelukkig zit het meeste spul wel achter NAT (niet ervoor bedoeld maar in dit geval wel fijn), maar het blijft natuurlijk niet fraai.

[Reactie gewijzigd door Boudewijn op 26 juli 2024 01:51]

[GertMenkel]

Volgens de bijbehorende blogpost is de kwetsbaarheid dan ook in 2016 gevonden voor hardware en software die destijds al buiten support valt.

Als ik nu een lek vind in Windows XP, gaat Microsoft echt geen patch meer uitrollen. Als je professioneel IoT-apparaten inkoopt, moet je ook rekening houden met de levensduur van software. Als die levensduur "ongespecificeerd" of "minder lang dan we er mee gaan werken" is, is het aan jou als bedrijf om de risico's van dit soort dingen op je te nemen.

Als er bedrijven worden getroffen door lekken in software waarvan al tijden is aangekondigd dat ze niet meer onderhouden worden, is het duidelijk dat de mitigaties die bedrijven hebben moeten implementeren om hun apparatuur te beschermen niet voldoende was, of dat het bedrijf dom is geweest bij het inkopen van hun IoT.

[goarilla]

Kerel, Ik denk dat je vandaag de dag nog altijd embedded toestellen kan kopen die draaien op linux 2.2.x.

[GeroldM]

Heb je ergens een nieuw TP-Link routertje in je netwerk hangen? Draait nog steeds op Linux kernel 2.6.x als ik het me goed herinner. D-Link is niet veel beter, LinkSys ook niet. NetGear is iets minder slecht maar ook bij hun is er meer dan genoeg rumte voor verbeteringen. Asus apparatuur was vaak het beste , maar ook niet zonder pijnpunten.

Consumenten-spul is helemaal niet zo veilig als de verpakking beweerd. Kan het document (PDF) wat ik hierover heb gedownload niet meer terugvinden. De link

[TrekVogel]

Interessant, dank voor de link naar de pdf.

[EmbeddedPower]

Heel interessant!
Mooi om te zien hoe groot de verschillen tussen de fabrikanten zijn, ook in beschikbare kwetsbaarheden.

Ik ben benieuwd naar wat de resultaten voor kwetsbaarheden in een alternatief als OpenWRT zouden zijn.

[TrekVogel]

Eigenlijk zou me dit niet moeten verbazen maar toch schrik ik hier wel een beetje van.

Even opgezocht: 2.2.0 is van januari '99!
De laatste patch is van februari 2004.

[nickyhaan]

Ik zit in de industriele cybersecurity en je wilt niet weten hoevaak ik nog oude meuk tegenkom .. zelfs regelmatig nog Win NT4 machines...

[batjes]

Zal wel schelen dat Microsoft met Windows 8 eindelijk de tcp/ip stack van FreeBSD vervangen heeft met een eigen stack. Anders waren er mogelijk nog vele miljarden apparaten kwetsbaar.

Ik ben ergens wel benieuwd of Windows 7 of ouder ook kwetsbaar zijn. Windows 7 is nog behoorlijk veel in gebruik.

[GertMenkel]

Wanneer heeft Windows ooit code van FreeBSD gedraaid? WinSock is al een eigen implementatie sinds voor de NT4 dagen, en de rest van de netwerkstack komt ook niet uit FreeBSD.

Het gaat hier om IoT-devices die op een eigen, minimaal OS draaien. Ik kan hier niets vinden over Windows, laat staan Windows 7.

[Reactie gewijzigd door GertMenkel op 26 juli 2024 01:51]

[batjes]

https://en.wikipedia.org/wiki/Winsock
"Windows Sockets code and design are based on BSD sockets,"

Oude tcp/ip tools zoals nslookup.exe hadden ook een copyright melding van Berkeley, in Win8 en Win10 heeft nslookup.exe de copyright van Microsoft zelf.

Die BSD legacy is pas met Win8 vervangen door die van Microsoft zelf.

De TCP/IP stack in Windows kwam grotendeels van BSD af, wat eigen dingetjes toegevoegd, maar de code/functionaliteit is grotendeels gelijk. Ik meen me te herinneren dat een Windows developer ooit aangaf van "Als wij het zelf moeten bouwen, zouden we het net zo bouwen als BSD dat gedaan heeft, dus hebben we het maar overgenomen".

Vandaar dat ik benieuwd ben of Windows 7 hier kwetsbaar voor is, gezien het probleem in de TCP/IP stack zit en niet zo zeer alleen "IoT" OSsen. (BSD is ook geen IoT OS)

[GertMenkel]

Ze hebben de API van BSD inderdaad gepakt, maar de originele BSD is niet hetzelfde als de huidige FreeBSD. Ook is de API alleen maar een set functienamen en types natuurlijk; de implementatie in de code is gebaseerd op een commercieel product van een andere derde partij. De API is overgenomen om te zorgen dat software compatible was met elkaar, omdat voor Winsock ook al andere socketlibraries voor DOS waren geschreven die de BSD-socket-API gebruikten.

De TCP-, IP- en DNS-stacks zelf is wel door Microsoft gemaakt, alleen hebben ze in tools als ftp, nslookup, finger, rcp en rsh code van BSD overgenomen. De probleemcode zit vooral in de onderliggende stack, en niet zozeer in enige overgenomen code van BSD, dus het lek zal niet van toepassing zijn op enige versie van Windows verwacht ik. De stack binnen Windows zelf kan ook niet zomaar worden overgenomen, aangezien DNS en drivers in Windows heel anders werken dan in Unix.

De wijzigingen aan Windows 8 zijn voor zover ik weet niet zozeer dat ze Berkeley's code uit de stack zelf hebben gehaald, maar dat ze de Winsock-API hebben uitgebreid om met minder overhead verkeer te kunnen sturen in een manier die niet direct compatible is met de oude API.

[Anoniem: 30722]

Scheelt dat IoT devices niet vanaf internet bereikbaar zijn, maakt het risico een heel stuk kleiner

[Yariva]

*kugh* Zegt iets met IPv6.

Overigens zijn er ook zat mensen met "IOT" devices op IPv4 die hun apparatuur wel naar buiten publiceren.

[Reactie gewijzigd door Yariva op 26 juli 2024 01:51]

[The Zep Man]

*kugh* Zegt iets met IPv6.

Met IPv6 houdt het niet automatisch in dat een apparaat met een global unicast address ook op het internet bereikbaar is. Goede routers hebben er altijd nog een firewall tussen zitten, die standaard alles van buiten naar binnen blokkeert.

Verder zijn er, zoals je noemt, ook voldoende mensen die met IPv4 de boel openzetten, via handmatige port forwardings of Universal Plug & Play. De stommiteit die daarin voorkomt neem je niet weg met IPv6.

[Reactie gewijzigd door The Zep Man op 26 juli 2024 01:51]

[Yariva]

Maar de modus die jij noemt zal wel 9/10 keer aanwezig zijn op iedere huis-tuin en keuken router (IPv6 SLAAC) om het gebruikersgemak te verhogen.

Daarbij geld het zelfde principe over de firewall. Je noemt een degelijk product en daar ben ik het met je eens. Maar of ook iedere router / modem standaard de firewall netjes heeft geconfigureerd betwijfel ik.

[arjankoole]

Precies. Niets van mij kan vanaf buiten benaderd worden via IPv6. En sommige devices die ik slecht vertrouw kunnen niet naar internet, en/of andere vlans.

[Anoniem: 30722]

Helaas levert Ziggo nog altijd geen IPv6 uit (indien je het modem in bridge hebt staan)

En als je het wel hebt, kwestie van je firewall goed inregelen... (ook voor IPv4 trouwens, maar daar helpt NAT je enorm)

Daarbij: gooi IoT in een eigen subnet, scheelt een hoop gedoe

[Yariva]

Ik denk niet dat de situatie "Modem staat in bridge bij Ziggo" echt representatief is voor de gehele IPv6 ondersteuning vanuit de ISP's in NL. Hoewel het van mij nog een stuk meer mag zijn, zijn KPN, Ziggo, Freedom etc. al goed op weg met de IPv6 ondersteuning.

Daarnaast helpt NAT "in zekere mate" met de beveiliging maar is dit meer toeval, NAT is nooit bedoeld als security feature en zo moet het ook echt niet gebruikt worden. NAT helpt ons om IPv4 nog even wat verder door te trekken maar met IPv6 op de hoek hebben we het hopelijk (ooit) niet meer nodig. En mocht die situatie er zijn is een lokale FW echt een vereiste.

Ik heb mijn eigen IoT meuk ook in een apart netwerkje maar dit is natuurlijk niet representatief met de gemiddelde NL'er die een slimme deurbel wilt aanschaffen.

[Anoniem: 30722]

NAT is inderdaad "Security by accident"

En tuurlijk moeten bedrijven veilige oplossingen leveren, maar mogen we van consumenten inmiddels ook niet verwachten dat ze een basiskennis hebben van een veilig netwerk?

Stel: we bouwen auto's, voorzien ze van gordels, airbags, camera's, sensors.... dan willen we toch ook dat mensen hun rijbewijs halen?
En ja, er is zeker een taak weggelegd voor router fabrikanten om instellingen zo duidelijk en eenvoudig mogelijk te maken, security by design etc. Blok alles maar wat inkomend is, meeste hebben het niet nodig, maar laat mensen zelf ook verantwoordelijkheid nemen voor hun aangesloten spullen.

Over de uitrol van IPv6, nee, dat gaat nog helemaal niet lekker, ik vraag ziggo hier slechts 20 jaar lang naar, maar het enige verdienmodel voor ze is DS Lite, besparen op IPv4 adressen. Als ze het echt wilden, hadden we al lang een goede Dual Stack oplossing kunnen hebben. (Zakelijke klanten kunnen dit immers wel krijgen). De andere providers, helaas geen optie hier.

[tweaknico]

"Accidental false sense of security" is een betere beschrijving.

Om NAT te compenseren zijn er zoveel hacks in applicaties getopt, zijn er (met wisselend succes) ALG's in routers gekomen, PNP om het te omzeilen, TURN/STUN in diverse smaken (met fouten en compensatie voor fouten etc.) etc.

In mijn beleving is NAT een grote "Net:Wreck" ... om on topic te blijven.

[The Zep Man]

Blok alles maar wat inkomend is, meeste hebben het niet nodig, maar laat mensen zelf ook verantwoordelijkheid nemen voor hun aangesloten spullen.

Verantwoording kan alleen met handhaving en gevolgen. Vergelijk het met je autorijbewijs, als in dat je niets zou mogen hosten zonder gekwalificeerd te zijn. Daar moeten dan controles voor zijn. Bij staandehouding wordt je gevraagd naar je rijbewijs. Zoiets heb je dan ook online nodig.

Een probleem dat je dan krijgt is dat men iets vanuit het buitenland gaat hosten. Daar houdt de autorijbewijs analogie dan ook een beetje op.

[tweaknico]

Of wat XS4ALL vroeger deed.... Kwam er overlast uit je netwerk, dan werd je in quarantaine geplaatst tot het opgelost was. met een kans om het redelijk snel weer open gezet te krijgen, en als het dan alsnog fout bleek dan had je meer werk.... NB overlast kon ook zijn het aanbieden van services waar een bekende zwakheid/exploit in zat.

[aikebah]

Of als je pech had een beroerd gekozen custom poort die toevallig door een hype malware worm gebruikt wordt.... wordt je preventief in quarantaine geplaatst op basis van een open poort.

Gelukkig wel met een kundige helpdesk waarmee je de root-cause wel kunt achterhalen (na de 'selfservice unblock' in no-time opnieuw in quarantaine gekomen dus toen toch maar eens die helpdesk gebruikt)

Neem ze ook zeker niets kwalijk.... weten zij veel dat ik er toevallig iets anders op host. De worm was op dat moment wel volop in de publiciteit vanwege de snelle verspreiding, dus liever wat obscure false positives dan de hele internet wereld exposed laten omdat je (nog) geen goed onderscheid kunt maken tussen een zichzelf snel verspreidende worm en legitiem obscuur poortgebruik - in mijn geval de webmail op een custom poort om de minst ervaren script kiddies vast weg te houden).

[dasiro]

subnet, vlan, firewall, ... je kan nog veel meer compartimenteren, maar dat is slechts good practice/symptoombestrijding en lost het inherente probleem niet op (zijnde fabrikanten die de nieuwe stack moeten implementeren of je zou het zelf willen proberen ).

[vincedd]

helaas is in de beveiligingswereld weinig apparatuur met ipV6 te vinden

[The Zep Man]

helaas is in de beveiligingswereld weinig apparatuur met ipV6 te vinden

Elk beetje router(software) heeft prima IPv6 ondersteuning.

In de beveiligingswereld is juist veel apparatuur met IPv6 ondersteuning. Er is echter weinig IoT apparatuur.

[Reactie gewijzigd door The Zep Man op 26 juli 2024 01:51]

[vincedd]

Ik heb het hierbij over alarm apparatuur tegen inbraak. Niet over routers

[Vordreller]

U bent uw /s vergeten.

[Anoniem: 30722]

Wat had ik moeten zoeken en vervangen?

/s/geen/idee/g ?

[Alex3]

/s = sarcasme
s/ = vervangen.

[JWerken]

Helaas is dit alleen voor tweakers mogelijk. Voor alle anderen die geen idee hebben wat een router is is het gewoon een device dat vol en open aan het ,boze, internet hangt.

[nullbyte]

Praktische uitbuiting van de kwetsbaarheden vereist wel dat een aanvaller toegang heeft tot het interne netwerk van een slachtoffer.

[bzzzt]

Zou verboden moeten worden producten bijna generieke namen als 'NetX' of 'IPnet' te geven. Totaal onmogelijk om op te zoeken, dus hoe kom ik er nou achter welke electronica ik bij de recycler in moet leveren?

[TrekVogel]

Nou ja, weggooien hoeft niet altijd. Wellicht is er een goede custom firmware beschikbaar.

[bzzzt]

Custom firmware is redelijk uitzonderlijk voor veel apparaten. Denk aan home cinema receivers, smart keukenapparatuur of verlichtingsystemen.
Ben heel benieuwd hoeveel fabrikanten een ook maar enigszins deugend security support model gebruiken.

[delphium]

Overdrijven is ook een vak. Om kwetsbaarheden te kunnen misbruiken moet een aanvaller al toegang hebben tot je lokale netwerk. Als dat bij jou het geval is, hoe je alleen je router maar te vervangen en een nieuw wachtwoord voor je WiFi te bedenken.

[bzzzt]

Tenzij je een lek IoT apparaat hebt wat een reverse proxy opent naar je eigen netwerk.
Het beveiligen van een netwerk houdt niet op bij de buitenkant.

[TrekVogel]

Ik ben bang dat toegang tot een gemiddeld privé netwerk krijgen nou niet echt heel lastig zal zijn.

[TrekVogel]

Dat is wel waar, maar veel apparaten die je noemt zijn nog steeds goed bruikbaar zonder internet toegang. Daar geldt dus ook voor dat ze niet meteen naar de recycling hoeven.

[svennd]

Lijkt me dat een dhcp update voldoende is eg voor de freebsd :
https://www.freebsd.org/s...BSD-SA-20:26.dhclient.asc
https://www.freebsd.org/s...s/SA-20:26/dhclient.patch

Ik zoek een POC

[cariolive23]

Ligt het aan mij, of werken die hyperlinks naar de CVE database niet?

[D11]

De eerste 2 werken bij mij wel. De overige geven "CVE ID Not Found".

[Reactie gewijzigd door D11 op 26 juli 2024 01:51]