Onderzoekers vinden 19 kwetsbaarheden in tcp/ip-library van veel iot-apparaten

Beveiligingsonderzoekers hebben meerdere kwetsbaarheden ontdekt in een veelgebruikte tcp/ip-stack die is geïmplementeerd in veel iot-apparaten. Een van de lekken kan onder andere gebruikt worden voor remote code executions.

Het gaat om een verzameling van 19 kwetsbaarheden in een specifieke tcp/ip-implementatie. Die is afkomstig van een Amerikaans softwarebedrijf genaamd Treck. De library van het bedrijf wordt gebruikt in veel verschillende iot-apparaten, waaronder veelal industriële apparatuur. De kwetsbaarheden werden ontdekt door het Israëlische beveiligingsbedrijf JSOF. Dat noemt zelf elektriciteitsnetwerken, medische apparatuur, en apparaten in de transportsector en luchtvaart, al geeft het geen concrete voorbeelden.

De onderzoekers noemen de verzameling van kwetsbaarheden Ripple20. Die naam werd gekozen omdat de onderzoekers denken dat de kwetsbaarheden een 'ripple'-effect hebben voor iot-apparatuur door heel 2020 heen.

Van de 19 kwetsbaarheden hebben er twee een score van tien gekregen op een schaal van ernstigheid. Het gaat daarbij om CVE-2020-11896 en CVE-2020-11897. De eerste is een kwetsbaarheid waarmee een remote code execution kan worden uitgevoerd op een apparaat. Dat kan door geïnfecteerde tcp/ip-pakketjes via een ipv4-tunnel te sturen. Dat kan wel alleen bij apparaten die een bepaalde Treck-configuratie draaien. De tweede kwetsbaarheid werkt op dezelfde manier, maar alleen bij ipv6-pakketjes.

Een andere ernstige kwetsbaarheid is CVE-2020-11901, waarmee ook een rce kan worden uitgevoerd via een dns-request. Er zijn ook kwetsbaarheden waarmee data kan worden afgelezen, en een use-after-free-kwetsbaarheid.

JSOF zegt dat Ripple20 waarschijnlijk niet alle kwetsbaarheden in Trecks tcp/ip-library bevat. Ook zeggen de onderzoekers dat nog lang niet alle kwetsbare apparaten online zijn gevonden. JSOF zegt dat het zoveel mogelijk fabrikanten heeft gewaarschuwd voor de kwetsbaarheden, maar dat er waarschijnlijk nog veel apparaten ook kwetsbaar zijn zonder dat iemand dat nog weet.

Het beveiligingsbedrijf werkte voor het naar buiten brengen samen met Treck. Dat heeft inmiddels patches beschikbaar voor alle 19 kwetsbaarheden. Wel moeten fabrikanten die dus nog zelf doorvoeren.

Reacties (51)

Die naam werd gekozen omdat de onderzoekers denken dat de kwetsbaarheden een 'ripple'-effect hebben voor iot-apparatuur door heel 2020 heen

Het is wel weer gezocht hoor. De fouten zijn erg genoeg om aandacht te krijgen, maar de mode om iedere fout maar een naam te geven begint een beetje vermoeiend te worden. Zeker nu het "grappige" of "interessante" namen moeten. "ripple" heeft niks te maken met de fout zelf maar zegt vooral iets over hoe belangrijk deze onderzoekers hun eigen ontdekking vinden.

Iedereen hoopt natuurlijk ooit een brilliante ontdekking te doen die als een schokgolf door onze maatschappij gaat en alles anders maakt, maar om je eigen werk vooraf al zo aan te duiden is wel een beetje arrogant.

Ik wil de ernst van deze fouten niet bagatelliseren, het ziet er inderdaad ernstig uit, maar die naam...

Toch valt er absoluut wat te zeggen voor het geven van namen aan grotere risico’s. Mensen in het wereldje hebben genoeg aan CVE’s maar die weten waarschijnlijk sowieso wel snel genoeg van dit soort kwetsbaarheden af.

Als je het grote publiek (via journalisten) wil bereiken omdat je wil dat ze updates draaien dan heb je niets aan een kwetsbaarheid die CVE-2020-9368 heet.

Als aandacht krijgen voor een probleem vooral zou werken op basis van opvallende namen dan lijkt er iets grondig mis met de intentie van de ontvanger. En ik betwijfel of dat het echte probleem is. Eerder dat de ontvangers meer waarde hechten aan wat opvalt dan zelf goed beseffen wat nodig is om objectief aandacht voor risicos te hebben en daar voldoende aandacht aan te kunnen schenken.

Zo'n "ontvanger" is mijn buurvrouw van achter in de zestig die een internetdeurbel heeft gekocht. Haar intenties zijn een deurbel hebben waarmee ze op haar telefoon te zien krijgt dat er iemand aanbelt. Haar intenties zijn niet om wekelijks een veiligheidsanalyse van haar deurbel te doen door databases door te spitten.

En, ik ben zelf eigenlijk ook zo'n "ontvanger" met een slimme thermostaat. Ook al weet ik redelijk wat van cybersecurity ga ik toch niet iedere week eventjes door de CVE database om te kijken of mijn thermostaat daar deze week ineens genoemd wordt. Dan ben ik toch ook afhankelijk een email van de fabrikant of van journalisten die het oppikken en beschrijven in een van de media die ik lees.

Zou er misschien regelgeving moeten komen zodat veel problemen met IoT voorkomen kunnen worden? Ik denk het wel. Maar tot die tijd ben je dus afhankelijk van regelmatige bewustwordingscampagnes onder digibete eindgebruikers.

[Reactie gewijzigd door Maurits van Baerle op 18 juni 2020 15:25]

pertinent mee oneens. mensen onthouden namen nou eenmaal beter. een gek nummer achter cve is netzoals alle andere nummers achter cve's voor je hersenen. geef het een naam met een ezelsbruggetje en mensen onthouden het super makkelijk. ik onthou nu al wat ripple20 is, omdat de naam de consequenties aankaart. het spreekt gewoon veel meer naar hoe mensen dingen leren en onthouden. cve benamingen zijn goed voor analyseren en indexeren, niet voor onthouden.

Ik ben het met je eens dat het makkelijker te onthouden is. Het spreekt meer tot de verbeelding dan een saaie technische paper, een cve benaming als cve-2020-9368 of een scoregetal 10 over risico. Zeker als er ook nog een leuk logo'tje bij zit en men er ook nog een eigen website bij heeft. Maar dat is naar mijn mening niet alleen waar het om moet gaan en ook niet wat de intenties lijken van de personen die het hanteren. De benaming zijn in het algemeen meer gericht op het aandacht genereren dan werkelijk aan te geven of het echt een risico is of wat mogelijke risico's zijn. Prima als het helpt en de ontvanger er creatief mee om kan gaan om het verstandig te gebruiken, maar @CAPSLOCK2000 geeft niet voor niets aan het al zat te zijn omdat het te makkelijk is. Heel veel kwetsbaarheden die in meerdere merken zitten of diverse gebruikers hebben hebben namelijk een ripple effect afhankelijk van hoe je er naar kijkt.

Meerdere van de kwetsbaarheden die een naam en logo hebben meegekregen blijken in de praktijk niet zo heel er risicovol te zijn omdat er heel veel afhankelijkheden zijn om er echt last van te hebben. En ondertussen kregen die kwetsbaarheden dan wel veel aandacht in de media terwijl andere kwetsbaarheden nauwelijks aan bod komen. Als het doel is om risico's te verminderen is de oplossing dus niet om vooral naar die namen en logo's te gaan kijken en dan de rest liever te negeren omdat het niet aantrekkelijk genoeg is. Want dan gaat het duidelijk niet meer om de risico's maar om het voeden van leuke behoefte.

Eerder iets grondig mis met de kennis van de ontvager bij IoT, loop maar gelijk welk productiebedrijf, als die productie plat valt krijg je alle aandacht en anders hoepel je maar op met je bangmakerij waar we niets van begrijpen.

Of loop anders even naar je dealer van je wagen, dat is immers ook een IoT geworden en vraag daar even na welke CVE nummers aangepakt zijn in de laatste update, welke update?

De kaarten van je navigatie, die kan je krijgen, na eens te swipen met je visa en een afspraak te maken want er is maar 1 technieker die weet hoe dat moet en hij is op verlof. Maar security? Daar kennen wij niets van. Ik zal is kijken in de computer die op Windows 7 draait met Iexplore 10.0 met java 8 versie 126, iets recenter slikt de gigantische dure dealer software immers niet.

En zo gaat dat door in heel die IoT wereld waar je bitter weinig mensen uit de IT gaat tegenkomen, probeer daar dan maar eens een mentaliteit te laten veranderen. Een catchy naam dat ze in de media hebben gelezen met wat bangmakerij, uit ervaring, daar zijn ze wel gevoelig aan.

[...]


Ik wil de ernst van deze fouten niet bagatelliseren, het ziet er inderdaad ernstig uit, maar die naam...

Could be worse. Ze hadden het ook Doomsday kunnen noemen ofzo.

Tsunamigeddon!

IOT apparaten staan er om bekend om vaak niet meer geüpdatet te worden. Er zijn heel veel goedkope apparaatjes die lekker aan internet hangen waar niemand naar om kijkt. Dat zo'n veelgebruikte library, zoveel fouten bevat inclusief tweemaal remote code execution, in combinatie met dat er niet naar omgekeken wordt... Ik denk idd dat we hier nog veel over gaan horen.

De S in de afkorting IoT is van security....

See what you did there...

Dit is geen nieuwe constatering... en helaas ik vrees dat het nog wel even mis zal blijven gaan.
Al is het alleen maar vanwege de al geïnstalleerde legacy.. ( en daar komt alleen maar meer van).

M.i. is het een noodzakelijke voorwaarde dat alle IoT hardware in een separaat VLAN draait ZONDER direct contact met internet. ongeacht welke hardware het is.

Treck is er trots op dat ze al 20 jaar stacks maken. En ze zijn niet de enige.

@qless:
De linux stack is al enige tijd een geharde stack. En er zijn linux edities die in z'n geheel (met een graphisch display in 14MB pasten). nanolinux, uit 2015. En wat langer geleden was er een pico-linux computer (rond 2003 oid) die zo groot was als een Ethernet connector. (Die zat er dan ook op). Kan helaas geen referentie meer vinden).
Dus kleine distro's waren mogelijk.

Als ik zo'n 'arrogante' onderzoeker was had ik 't shockwave genoemd. Ripple vind ik best nog wel bescheiden klinken.

Waarom is er geen gebruik gemaakt van bestaande Unix stack?

Waarschijnlijk is die te groot/teveel features voor dit soort devices.

Voor devices die een embedded Unix/Linux variant draaien kan dit.
Maar veel IoT devices hebben inderdaad helemaal niet de specs om dat te draaien. Kleine microcontrollers hebben flashgeheugens onder 1 MB en werken met RAM geheugen dat vaak nog kleiner is. De meeste fabrikanten bieden een eigen TCP/IP stack aan, die kan werken met de hardwarearchitectuur.

Meer recente kleine microcontrollers hebben soms wel een aantal MB aan flash, echter wordt er dan vaak gekozen voor een klein en simpel OS met realtime gedrag en geen boottijden, dat testbaar is en geschikt is voor het platform.

[Reactie gewijzigd door Ablaze op 18 juni 2020 11:24]

Ik heb hier 24/7 een LPC1343 (32KB flash, 8KB RAM) draaien waarvoor ik een port van een ENC28J60 Ethernet driver naar LwIP heb gemaakt. Dat soort devices zijn nog altijd actueel, ook al zijn er zwaardere platformen die geen drol kosten

Ik gebruik de esp8266 en esp32.
Die kosten idd bijna niets.
En programma-technisch hetzelfde als de Arduino.

Die heb ik zelf ook in allerlei varianten liggen en je kunt ze inderdaad prima in het Arduino ecosysteem gebruiken. De standaard SDK's zijn echter gebaseerd op FreeRTOS en C, wat ik zelf op ook op de LPC's gebruik.

Deze apparaten hebben vaak heel beperkte opslag-, reken- en accucapaciteit. Je wil alles zo compact en licht mogelijk maken. Bestaande moderne oplossingen zijn dan weer net geschreven voor systemen met veel rekenkracht en waarbij bestandsgrootte van zoiets iets minder belangrijk is.

Al eens een volledige netwerk applicatie geïmplementeerd met 64Kbyte RAM of minder?

Over zulke applicatie gaat het hier.

Omdat een microcontroller niet zomaar in staat is Linux of een unix-compatible OS te booten.

Er zijn wel projecten voor het draaien van een uitgeklede Linux kernel op high-end ARM microcontrollers, maar voor IoT is dat vaak niet interessant. Het hele verdienmodel van IoT is dat je goedkoop simpele sensor/actuator apparaten op bestaande infrastructuur kan plakken. In de gelinkte borden zie je high-end MCU's (100+ MHz, 2MB FLASH: 7+ $/stuk) met daarbij extern SDRAM.

Dit in tegenstelling tot bvb de zeer populaire ESP32 of ESP8266 chipsets die ook met WiFi kunnen praten voor een fractie van die kosten, maar zij het met een gespecialiseerde embedded TCP/IP stack.

Als je nagaat dat de bill of materials kosten van een gemiddeld apparaat zomaar 3-7x op z'n kop gaan, mag je zelf doorrekenen wat de meerkosten zijn voor het toevoegen van IoT connectivity met Linux support. Je praat dan waarschijnlijk over meerprijzen van 20-30 euro op apparaten die in de basis slechts dat bedrag 'mogen' kosten.

[Reactie gewijzigd door Hans1990 op 18 juni 2020 12:01]

Oopsy.... en aan welk soort iot-apparaten moet ik dan denken (graag namen, merken (en typenummers))

Voorbeelden die ik noem zijn overgenomen van hier. Denk aan software in Intel Trusted Execution Environments (zoals AMT), wat draait op veel professionele notebooks. Andere apparaten zijn bijvoorbeeld HP netwerkprinters.

Een lijstje van getroffen leveranciers is hier te vinden. Helaas nog geen lijst met exacte apparaten. Een probleem is dat het zoveel apparaten betreft dat iedere fabrikant dat zelf moet inventariseren.

[Reactie gewijzigd door The Zep Man op 18 juni 2020 10:30]

De vendors staan in het document / site dat gelinkt is.

Vooral industriële apparatuur staat in het artikel. Nou zou ik die niet direct aan internet hangen en afschermen in een apart VLAN...

Ik heb zelf een paar van die Chinese stopcontacten die ik via een app kan bedienen... verwacht niet dat ze erg veilig zijn dus maar in een apart netwerkje gezet met alleen toegang tot internet maar niet naar mijn intranet.

Het zal je verbazen hoeveel industriële apparatuur nog gewoon rechtstreeks aan het internet hangt.

Nee hoor, daar is bij mij geen enkele verbazing

Vooral industriële apparatuur staat in het artikel.

Professionele notebooks en standaard HP netwerkprinters zijn niet zozeer industrieel, maar wel breed verspreid.

erg veilig zijn dus maar in een apart netwerkje gezet met alleen toegang tot internet maar niet naar mijn intranet.

Waarom zet je ze niet in een netwerk zonder stopcontacten internetverbinding en beheer je ze met een machine die een netwerkaansluiting heeft in beide netwerken?

[Reactie gewijzigd door The Zep Man op 18 juni 2020 12:19]

[...]
Waarom zet je ze niet in een netwerk zonder stopcontacten

Is een netwerk op batterijen veel veiliger dan?

Dit had mij ook de logischere oplossing geleken en zo probeer ik het ook te doen. alleen doe ik het dan via mn openwrt 'firewall'. apparte groep voor automatisering apparaten, vanaf prive lan en prive wan kan ik wel met hen communiceren, maar zij niet met mij of het internet. compleet geissoleerd.

Waarom zet je ze niet in een netwerk zonder internetverbinding en beheer je ze met een machine die een netwerkaansluiting heeft in beide netwerken?

Dan zal het wel niet via de app kunnen. Die machine zou dan software moeten draaien die verbinding met die stopcontacten kan maken, en verbinding naar buiten kan maken voor de app. Dan moet die software er wel zijn.

Goedkope Chinese zooi die alleen via een cloud app bediend kunnen worden

Uit de lijst confirmed affected manufacturers/vendors baart me vooral “Schneider Elektric/APC “ zorgen. Ik heb een aantal ups’en met lan/web interface in mijn netwerk.

[Reactie gewijzigd door DoctorBazinga op 18 juni 2020 10:42]

De APC's draaien Treck software.

Volgens Tom's Guide lijkt het te gaan om iig een APC Smart-UPS C 1500.

[Reactie gewijzigd door styno op 18 juni 2020 11:05]

Dan hebben er veel modellen die stack.
APC/Schneider gebruikt al jaren vrijwel dezelfde base voor het merendeel van hun apparaten.

APC Smart-UPS C 1500.

Oeps ...

Heb hier er 2 van draaien ...

Zo lang je die interface niet publiek aanbiedt en fysieke toegang tot je netwerk ook in orde is, dan valt deze impact wel mee....

Schneider Electric en Rockwell Automation, kunnen we er vanuit gaan dat om de embedded tcp/ip stacks van hun PLC's gaat? Dat zijn dan een heleboel kwetsbare industriele installaties....

Zoals men al zegt, the S in IoT stands for Security.

Ja IoST mocht niet, leest teveel als de naam van een populaire TV serie. Daarom is de S stil.

Je vraagt je dan toch af waarom er pas een specialist ingehuurd wordt om naar kwetsbaarheden te zoeken nu deze software al wijd verspreid in gebruik is, in plaats van vooraf..

Nu mag de klant betalen.

Hoe moet ik dit voor me zien?

‘Hallo, u heeft vorig jaar 20 apparaten gekocht van ons. Wilt u even geld overmaken zodat we kunnen laten onderzoeken of ze wel veilig zijn?’

Of

‘Hallo, we hebben onze producten onderzocht en ze blijken zo lek als een mandje qua beveiliging. Wilt u even betalen voor het onderzoek?’

In beide gevallen gaat een klant toch zeggen: Dat is in de eerste plaats de verantwoordelijkheid van de leverancier. En bij echt kritische zaken zal men toch vooraf informeren naar certificatie qua veiligheid.

Omdat security geen vereiste was, tenminste het was geen feature waar geld voor gevraagd kon worden.

OK, maar waarom dan achteraf wél onderzoeken, door de leverancier zelf? Dat kan toch alleen maar problemen zoals claims opleveren?

Het zal maar in je verwarmingsketel zitten waarna een hacker even de firmware aanpast om even een brandje te stichten (volle 'gas' + geen circulatie + geen veiligheden).

Ik krijg echt schrik van dit soort dingen, het is wachten tot er eens iets ernstig gebeurd.

het is wachten tot er eens iets ernstig gebeurd.

Zoals het laten ontploffen van uraniumverrijking centrifuges? Of het uitschakelen van de elektriciteit van grote gebieden? Of het openzetten van (stuwdam) sluizen? Of het fysiek saboteren van grote generatoren?

Nee, daar hoeven we niet op te wachten, het is al gebeurd.