image

Vitale infrastructuur kwetsbaar door kritiek lek in Rockwell Logix-controllers

vrijdag 1 april 2022, 13:00 door Redactie, 4 reacties

Systemen in de vitale infrastructuur zijn kwetsbaar door een kritiek beveiligingslek in Logix-controllers van fabrikant Rockwell Automation, waardoor Stuxnet-achtige aanvallen mogelijk zijn. De impact van de kwetsbaarheid, aangeduid als CVE-2022-1161, is op een schaal van 1 tot en met 10 beoordeeld met een 10.0. Via het beveiligingslek is het mogelijk om de software van de controllers op afstand aan te passen.

Logix-controllers worden gebruikt voor de aansturing van industriële processen, zoals de assemblagelijnen van fabrieken. Volgens het Cybersecurity and Infrastructure Security Agency (CISA) van het Amerikaanse ministerie van Homeland Security worden Logix-controllers in meerdere vitale sectoren wereldwijd gebruikt en is misbruik van het beveiligingslek eenvoudig.

De kwetsbaarheid bevindt zich in de firmware van de controllers. "Het laat aanvallers user-readable programmacode naar een andere geheugenlocatie schrijven dan de uitgevoerde gecompileerde code, waardoor de aanvaller de een en niet de ander kan aanpassen", aldus onderzoekers van securitybedrijf Claroty die het probleem ontdekten.

Normaliter zijn Logix-controllers via de Studio 5000 Logix Designer te programmeren, maar via een eerder beveiligingslek, namelijk de aanwezigheid van een hard-coded key, is het mogelijk om direct met de Logix-controller te communiceren en de software zonder de Logix Designer aan te passen.

"Een aanvaller met de mogelijkheid om programmable logic controller (PLC)-logica aan te passen kan fysieke schade aan fabrieken toebrengen die de veiligheid van assemblagelijnen en de betrouwbaarheid van robots in gevaar brengen, of zoals we met Stuxnet zagen, kunnen aanvallers de centrifuges van een uraniumverrijkingsfaciliteit beschadigen", aldus de onderzoekers, die specifiek keken of Logix-controllers kwetsbaar zijn voor Stuxnet-achtige aanvallen. Het CISA adviseert organisaties verschillende mitigaties om eventuele aanvallen te voorkomen.

Image

Reacties (4)
01-04-2022, 13:21 door Anoniem
Die is natuurlijk zo oud als de weg naar Rome... Als er wat op het apparaat gezet kan worden en de engineer 'denkt' dat wat hij ziet daar per definitie op draait... Tsja.
01-04-2022, 15:03 door Anoniem
Dit is vast geen backdoor die nu naar buiten komt als lek van onze vrienden uit Milwaukee zeker?
Backdoors zitten alleen in china producten en zijn nog minder vaak gezien dan Yeti en Nessie
01-04-2022, 16:37 door Anoniem
Ik moest even het bronbericht lezen om de vulnerabilty te begrijpen. De instructie in bytecode (binary) kan dus verschillen van de textual code (source code) die de programmeur / operator ziet. Dat is inderdaad wel een probleem als het in een blackbox zoals een PLC zit. Leuke vondst.
03-04-2022, 14:42 door Anoniem
Door Anoniem: Ik moest even het bronbericht lezen om de vulnerabilty te begrijpen. De instructie in bytecode (binary) kan dus verschillen van de textual code (source code) die de programmeur / operator ziet. Dat is inderdaad wel een probleem als het in een blackbox zoals een PLC zit. Leuke vondst.

Het is m.i. precies hetzelfde probleem als wanneer de binary code voor een 'normale' computer niet overeenkomt met wat wat de compiler gemaakt had van de source code .

Dat was een belangrijke component van de Solarwinds hack, waarin de code in het build-proces (dus buiten het zicht van de normale IDE) geinjecteerd werd.

Het is misschien nog wat ongebruikelijker in PLC land om zich te realiseren dat er uiteindelijk een computer is, en dat het pad van ontwikkel-station naar code op de chip omzeild kan worden .
Maar ook developers van normale software zullen zelden - en zeker niet routinematig - de uiteindelijke binary code terug-disassembleren en naast de HLL source leggen . (of - bytecode , zoals voor een JVM)
Het is ook een vaardigheid die niet zo veel developers hebben

Dat maakt build systemen extreem belangrijk - en het is helaas al _fors_ lastig om "repeatable builds" te laten gebeuren, zodanig dat de output van meerdere build systemen vergeleken kan worden.
Het is naief om te denken dat als je maar dezelfde compiler en zelfde opties gebruikt voor dezelfde source code, er een binary uitkomt die bit-identiek is.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.