'Veel industriële controlesystemen zijn via internet te benaderen'

Beveiligingsbedrijf Kaspersky waarschuwt dat het door onderzoek heeft vastgesteld dat 220.558 industriële controlesystemen via internet te benaderen zijn. Daarvan behoren er minstens 17.000 toe aan grote bedrijven.

Kaspersky schrijft dat het onderzoek is uitgevoerd aan de hand van de zoekmachines Shodan en Censys, waarmee internet te doorzoeken is naar bepaalde soorten apparaten. De meer dan 200.000 ic-systemen zijn aanwezig op ongeveer 188.000 hosts in 170 verschillende landen, met grote aantallen in de VS en Europa. Door te zoeken naar apparaten die door hun grootte of prijs alleen aan grote bedrijven kunnen toebehoren, kon het bedrijf meer dan 17.000 systemen toeschrijven aan deze groep.

Van die groep gebruike 91 procent van de systemen volgens de onderzoekers onveilige protocollen, zoals http, telnet, Modbus en Siemens S7. Daardoor zijn ze bijvoorbeeld kwetsbaar voor man-in-the-middle-aanvallen. Ongeveer 3 procent bevat kritieke kwetsbaarheden waardoor op afstand code uitgevoerd kan worden. Het bedrijf stelt dat industriële controlesystemen, die vaak gebruikt worden in belangrijke sectoren als energie, watervoorziening en transport, oorspronkelijk zijn ontworpen voor afgesloten omgevingen.

Daar komt bij dat het aantal kwetsbaarheden in ic-systemen een gestage groei doormaakt. Tussen 2010 en 2015 groeide het aantal bekende lekken van 19 naar 189. Voor 26 van de kwetsbaarheden uit 2015 zijn exploits beschikbaar, vult Kaspersky aan. Zo is er een veelvoorkomende kwetsbaarheid door voorgeprogrammeerde inloggegevens. Een aanvaller kan daarvan gebruikmaken om controle over een systeem te verkrijgen. Er komen niet altijd patches uit voor gevonden kwetsbaarheden, zo is er voor 15 procent van de in 2015 gevonden lekken geen oplossing.

Kaspersky merkt op dat geavanceerde aanvallen op ics-componenten geen nieuw verschijnsel zijn. Het wijst daarbij op de aanval op een energiecentrale in Oekraïne, waarbij veel mensen zonder stroom kwamen te zitten. Ook Stuxnet is een voorbeeld van geavanceerde malware. Deze werd ingezet om de Iraanse uraniumverrijkingsinstallatie bij Natanz binnen te dringen. Onlangs vond beveiligingsbedrijf FireEye een nieuw soort ics-malware die eigenschappen van Stuxnet vertoont.

Reacties (71)

[MadMarky]

Gelukkig is de EU bezig met wetgeving rondom de beveiliging van dit soort systemen.
Zie ook: nieuws: Europarlement stemt in met nieuwe regels voor internetbeveiliging
En ook: nieuws: EU investeert 450 miljoen euro in samenwerkingsverband voor internetb...

[Reactie gewijzigd door MadMarky op 22 juli 2024 21:55]

[RoestVrijStaal]

Eigenlijk diep triest dat er voor zoiets belangrijks als beveiliging wetgeving moet komen

[kidde]

Voor elektrische installaties is dat ook (oa NEN 1010/3140) en voor machines is er de Europese machine richtlijn (EG42) . Die zorgen dat werknemers die machines bedienen of repareren zo veilig mogelijk kunnen werken. Iedereen vind het normaal dat dit wettelijk geregeld is, veiligheid staat als het goed is voorop in de industrie en bij nalatigheid zijn managers zelfs hoofdelijk aansprakelijk, denk oa aan SE Fireworks en Chemiepack. Voor drukinstallaties en explosieve omgevingen zijn extra regels, respectievelijk stoomwezen / ATEX.

Maar voor crackers die op een beveiligingscirciut inbreken en deze veranderen is nog geen richtlijn, dus kunnen werknemers nog kwetsbaar zijn. Het lijkt me niet meer dan logisch dat daar ook regels voor komen, als werknemer moet je kunnen vertrouwen dat je veilig kan werken en met gevaarlijke machines met slechte beveiliging kan je dat niet.

[Reactie gewijzigd door kidde op 22 juli 2024 21:55]

[Verwijderd]

Ik denk dat hij bedoeld dat beveiliging nul komma nul prioriteit heeft voor veel bedrijven die dit soort systemen maken.

[kidde]

Ik denk dat hij bedoeld dat beveiliging nul komma nul prioriteit heeft voor veel bedrijven die dit soort systemen maken.

Dat klopt en is ook absoluut mijn ervaring. WTB / E-Engineers kunnen vaak niet goed inschatten wat de risico's zijn van op afstand inloggen op deze machines, zien vooral de voordelen van ondersteuning op afstand door de leverancier.
Meestal leeft het idee dat het allemaal wel zal meevallen en de ICT afdeling de boel wel zal beveiligen.

Net even opgezocht, de machine richtlijn (vooral mechanische eisen) is 63 pagina's maar voor inloggen op afstand kan de leverancier goedkoop broddelwerk leveren. Dus een begin zou al zijn dat bewezen onveilige protocollen als http en telnet niet gebruikt mogen worden als veiligere alternatieven zoals ssh en https voorhanden zijn, en dat genoemde protocollen altijd naar de veiligste versie bijgewerkt moeten kunnen worden. Veel bedrijven hebben denk ik al 'best practices' en regels voor inloggen op afstand (alleen vanuit VPN met firewall, USB standaard gesloten, wachtwoord-rotatie etc) , dit in de machine richtlijn opnemen zou er al voor zorgen dat er aandacht voor komt.

[Reactie gewijzigd door kidde op 22 juli 2024 21:55]

[fsfikke]

Dat hangt natuurlijk vooral af van de professionaliteit van het bedrijf. Bij de grote jongens staat de beveiliging van controlesystemen al jaren in de picture. Daar gelden ook een stuk strengere en uitvoerigere eisen dan regionale standaarden. Als een uurtje downtime een bedrijf miljoenen kost of zelfs de potentie heeft catastrofes te veroorzaken met nog veel hogere sancties denkt men er wel over na om dit soort systemen strikt gescheiden te houden van het internet en zelfs van devices die op zich weer in contact kunnen hebben met het internet zoals laptops die in het bedrijfsnetwerk hangen.

Wetgeving lijkt dan ook meer een middel om bedrijven voor hun eigen onwetendheid te beschermen en bewustwording te creëren.

[Reactie gewijzigd door fsfikke op 22 juli 2024 21:55]

[Verwijderd]

Voor elektrische installaties is dat ook (oa NEN 1010/3140) en voor machines is er de Europese machine richtlijn (EG42) .

Maar ervoor zorgen dat een elektrische installatie veilig is kan je beschouwen als een haalbaar doel. Een beperkt aantal richtlijnen en die pas je elke 10 jaar aan.

In IT gaat het over een veel moeilijker te omschrijven doel. Natuurlijk zijn er aantal standaard maatregelen te nemen maar we weten maar al te goed dat er elke dag nieuwe zwakheden boven water komen. Je kan die niet allemaal in regelgeving vangen. Daarmee kom je al snel in terminologie als inzetverplichting, up to date houden, patch niveau op orde houden en ben je in hoge mate afhankelijk van de goedwillendheid van de leveranciers. Ik zie niet veel in een strakke regelgeving in deze materie en ben bang dat men 'aan de regels voldoen' belangrijker vind dan daadwerkeljk proactief te werken.

[kidde]

Natuurlijk zijn er aantal standaard maatregelen te nemen maar we weten maar al te goed dat er elke dag nieuwe zwakheden boven water komen. Je kan die niet allemaal in regelgeving vangen. Daarmee kom je al snel in terminologie als inzetverplichting, up to date houden, patch niveau op orde houden en ben je in hoge mate afhankelijk van de goedwillendheid van de leveranciers.

Een treffendere verwoording van het laten voldoen van je mechanische machines aan de machinerichtlijn heb ik nog nooit gelezen!

Persoonlijk denk ik dat het omgekeerd is, de IT doelstellingen zijn juist veel eenvoudiger dan die in van de machine richtlijn. Het enige dat de IT moet doen, is zorgen dat het systeem niet onbedoeld veranderd kan worden, het zijn slechts een paar draadjes die beveiligd moeten zijn. Dat is veel eenvoudiger dan alle mogelijke posities van een machine bewijzen dat ook bij te verwachten misbruik de boel veilig is, dat bij een noodstop alle hydrauliek en pneumatiek stilstaat en geen gassen vrijkomen, en als toch dat die gassen worden afgevangen en dat dit ook goed gaat bij blikseminslag of uitvallen stroom. Bij IT gaat het voornamelijk over welke protocollen en en vanaf welk domein / IP, welke besturingssystemen en versies toegestaan zijn, alleen bijwerkbare software-systemen hebben, USB poorten blokkeren en wachtwoord-beleid, is geen raketwetenschap zolang je de regels simpel houdt.

[Reactie gewijzigd door kidde op 22 juli 2024 21:55]

[Iblies]

Hoe wou je het dan doen?

Onze eigen minister Kamp was ook van mening dat het gebruik van zijn gmail niet onveilig was... En dat moet je hem zeker kwalijk nemen, alleen moeten we daarbij niet de vergissing maken dat hij de enigste is.

Strakke richtlijn, wat sowieso het minimale is, voor alle EU landen waarbij je de norm stelt voor jezelf, maar dat je dat ook verwacht van bedrijven waar mee je samenwerkt.

[Verwijderd]

Nogal een verschil, of het een publiek figuur (minister) of een private instelling is...

[Rataplan_]

Mooi, het zoveelste dat de EU bedenkt. Maar hoe denk je dat ze dit gaan handhaven? Ik vind het een erg mooi streven maar ik moet het nog zien gebeuren...

[kidde]

Kwestie van verantwoordelijkheid: Als je een machine verkoopt, beloof je op papier als producent zelf dat hij voldoet aan de richtlijnen. Dit is Europees verplicht voor alle leveranciers. De overheid is geen partij bij een verkoop van een machine, ambtenaren comtroleren dus niets, ze leveren alleen spelregels. Gebeurt er dan een ongeluk met die machine en is de gebruiker niets te verwijten, dan is de leverancier verantwoordelijk.

Werkt al jaren zo voor regels wat betreft het mechanisch gedeelte van machines. Als de leverancier verantwoordelijk wordt, doen ze doorgaans echt wel hun best omdat ongevallen in ernstige gevallen kunnen lijden tot het faillissement van vooral kleinere bedrijven.

[itcouldbeanyone]

In theory klopt wat je zegt.
maar in de praktijk gebeurt ook vaak, fabrikant zegt A=A en B=B
tussenpersonnen maken er A=Z en B=0 van
en elke keer tekenen ze om de verantwoordlijkheid een stukje op zij te schuiven.
waarna het uiteindelijk onduidelijk word wie er echt verantwoordelijk is.

[Morress]

Wetten hebben en wetten naleven/controleren is helaas nog een wereld van verschil.

[Verwijderd]

Wetten hebben en wetten naleven/controleren is helaas nog een wereld van verschil.

De handhaving en controle op industrienormen etc is anders behoorlijk streng en effectief. Ik zie problemen met het maken van de regels maar zie niet in waarom de handhaving van een IT norm moeilijker zou zijn dan bijvoorbeeld een brandblusinstallatie.

[AMS76]

IT is oneindig meer complex dan bijv. een brandblusinstallatie. Je kunt een en ander wel testen, maar 100% zeker dat ze dan ook aan de wetgeving voldoen, of belangrijker: dat het echt veilig is, is lastig te constateren. Als dom voorbeeld: Je kunt een PLC wel alleen bereikbaar maken via een VPN op een apart VLAN oid, maar ja, dan plugt er toch iemand een andere kabel in een switch, waar de VLAN's toch niet zo goed op dicht gezet waren als dat zou moeten, en je kunt er plots ook via een andere weg bij (en hoe test je dat dan?).

[MadMarky]

Het verschil zou dan zijn dat nutsbedrijven kunnen worden aagesproken op hun slechte beveiliging vóórdat ze gehackt zijn en de boel in het honderd is gelopen.

Of er ook echt gecontroleerd gaat worden is een ander verhaal, maar wat bewustzijn kweken kan al heel wat doen.

[Morress]

Aanspreken en controleren ligt dan al aardig dicht op elkaar. Ik pleit voor een eu instantie die actief grote kwetsbare ondernemingen controleerd en helpt waar nodig.

[Spikie]

Steeds meer systemen worden gekoppeld.
Van oorsprong ontworpen als functioneel stand alone systeem. Stap gemaakt om systemen aan elkaar te koppelen in de productie omgeving.
Tot zo ver nog steeds gesloten systemen zonder koppeling naar de boze buitenwereld.

Dan gaan we het volgende doen:
- Die systemen koppelen aan het kantoor netwerk
- Directe toegang tot productiesystemen voor onderhoud en storing oplossen op afstand
Nu zijn we dus te benaderen, met een systeem dat volledig is gericht op functionaliteit en (totaal) niet op veiligheid.

Met de enorme push nu:
- Ethernet gebaseerde protocollen tot field niveau
- IoT (heerlijk loze term vanwege vele ge/misbruik heeft iedereen een eigen invulling
- Industry 4.0
Alles moet gekoppeld, met elkaar communiceren en gegevens delen.

Gevolg is dat je een enorme hoeveelheid legacy systemen krijgt die te benaderen via netwerken, volledig gericht op functionaliteit zonder enige Industrial Security om de systemen te beschermen.
Bewustzijn is laag, "wie wil nou in mijn systeem kijken" en " zo´n vaart zal het wel niet lopen" hoor je vaak. Gevolg is dat legacy systemen open en bloot aan het net hangen, nieuwe systemen nog steeds functioneel worden ontwerpen waarbij veiligheid een ondergeschoven kindje is en de risico´s alleen maar toenemen.
Grote leveranciers werken aan bewustwording, bieden nieuwe systemen met security maatregelen, training, etc. maar de bereidheid bij klanten en bedrijven is nog steeds laag.
Het is te hopen dat er heel snel een grote omslag wordt gemaakt, want het gaat niet alleen om kleine productie installaties waar niemand iets van merkt, ook om publieke infrastructuur (bruggen, sluizen), drinkwatervoorziening, voedselproductie, geneesmiddelen productie, etc.

[Bas1234567]

Klopt helemaal. Het bedrijf waar ik nu afstudeer is niet anders. Een van de nieuwe productiecellen die hier door een externe partij gebouwd wordt moet zelfs van buitenaf bereikbaar zijn anders wilde het bedrijf geen service agreement afsluiten.

Van de ene kant begrijpelijk. Het kunnen checken van systeem voordat er een monteur heen gestuurd wordt kan een hoop tijd/geld schelen. Van nieuwe systemen mag je dan hopen dat er meteen (goed) nagedacht wordt over de beveiliging. Maar ook hier worden, precies zoals je zegt, steeds meer oude systemen gekoppeld en benaderbaar vanuit het netwerk.

Ik ben zelf geen IT'er dus durf niks over te beveiliging hiervan te zeggen en als engineer zie ik ook juist de voordelen hiervan. Maar als ik zo om me heen kijk/luister zien de meeste engineers alleen de voordelen, zijn blind voor de gevaren en maken de IT afdeling uit voor incompetent als die zeggen dat iets niet kan of moeilijk te maken/implementeren is.

[CEx]

Ze kunnen het ook remote beschikbaar maken via VPN of citrix.

Wat te vaak gebeurt is dat men vlug en snel "iets openzet" zonder na te denken over een goede oplossing. Sinds de CPB richtlijnen zie je dat op dat vlak nu al eerder nagedacht wordt. Ik zeg, kom maar op met die richtlijn.

[teaser]

Ik werk voor een bedrijf dat automatisatie doet, en toevallig is service ook een deel van mijn job. Inderdaad, remote access is een voorwaarde voor een service agreement. In 99% van de service oproepen die software gerelateerd zijn (PLC of hoger niveau) is het niet nodig om een engineer on site te sturen. De klant is zo veel sneller geholpen, en het kost allemaal minder in uren en verplaatsing.
Uiteraard is die remote toegang enkel mogelijk over een VPN. Ik ken geen enkele klant waarbij een 'open en blote' toegang tot hun systeem mogelijk is. Vanuit mijn perspectief vind ik het dus verbazend dat er toch zoveel systemen toegankelijk blijken te zijn, omdat een VPN toch standaard is.

[Verwijderd]

Die legacy protocollen zijn ook zo heerlijk ouderwets en makkelijk te hacken / onderscheppen. Vaak simpele ascii stringetjes over ethernet heen als "virtueel" compoortje o.a.

Er zit vaak wel een beveiliging omheen. Maar als je eenmaal door dat ene beveiligingslaagje heen bent kun je echt overal met gemak bij omdat overal nog oude system gekoppeld zijn via van die simpele gateways e.d. protocol convertertjes.

Het bewustzijn is er totaal niet. Ik merk dat wel in de branche. Men geeft weinig tot geen ene shit erom.

[Falcon10]

Dit heeft vooral te maken met het feit dat de moderne westerse bedrijven het amerikaanse bussiness model gebruiken, zijnde : meer winst, door minder middelen.
Gevolg hiervan is dat er meer en meer geautomatiseerd wordt, en dat onderhoud hierop ook minder mag kosten, maw oa besparing op personeelskosten, zijnde minder personeelsleden, en het personeel dat ze hebben moet ook van thuis/vakantie aan de systemen kunnen raken, want dat is goedkoper ipv ze steeds tot op de fabriek te laten komen.
Tevens is onderhoud op deze systemen goedkoper vanuit het buitenland door specialisten aldaar, en zijn veel van de programmas enz voor zulke processystemen uit het buitenland afkomstig, dus zobiezo een internetconnectie nodig voor support door deze firma.
Valt dan nog eens bij dat deze systemen dikwijls beheerd worden door interne AMRA, analyzer en automatisatie diensten, wat geen echte interne ICT diensten zijn, en die ook niet genoeg kennis hebben van beveiligingsproblemen waardoor deze zobiezo al op een laag pitje staat en er bv geen gebruik gemaakt wordt van een beveiligde toegang via tokens naar een soort remote server met Citrix of VM omgeving die vervolgens met een FW geconnecteerd wordt aan het processysteem waar tevens nog eens een RDP server staat vanwaar je pas "echt" connectie maakt naar de procesgestuurde systemen.

Merk dit soort gedrag meer en meer op bij de grote bedrijven waar ik regelmatig zit, en het is dweilen met de kraan open door gebrek aan kennis bij het hogere management.

[MSalters]

Tsja, dit helpt Kapersky's geloofwaardigheid niet echt.

"onveilige protocollen, zoals http [zijn] kwetsbaar voor man-in-the-middle-aanvallen. "

Dit is onzin. Het veronderstelt dat een aanvaller een kwaadaardig systeem in het midden tussen twee systemen kan plaatsen, wat dan aangezien wordt en vertrouwd door de twee originele systemen. Maar dat gaat alleen op als die twee systemen elkaar uberhaupt vertrouwden!. Om een concreet voorbeeld te noemen wat aantoon hoe fout die aanname is: Apache Webs Server communiceert met web browsers via HTTP, maar het is vanzelfsprekend niet zo dat Apache die webbrowsers ook maar voor een seconde vertrouwt.

Ik snap wel waarom ze deze FUD publiceren Als niet-technische CEO's dit soort onderzoeken lezen, dan krijgt Kapersky misschien wel wat opdrachtjes. Het zou T.net sieren als ze zich wat kritischer opstelden, in plaats van PR berichtjes copy-pasten.

[Reactie gewijzigd door MSalters op 22 juli 2024 21:55]

[Femme]

Ze hebben wel een punt hoor. Om bijvoorbeeld modbus tcp te nemen: super handig protocol en veel gebruikt om te communiceren met bijvoorbeeld plc's en I/O modules. Het protocol kent niet eens het concept van een gebruikersnaam en wachtwoord. Dit maakt het dus een stuk lastiger om communicatie te beveiligen. Beveiliging doe je dus in eerste instantie door scheiding van netwerken, het blokkeren van fysieke toegang tot het netwerk en het gebruik van een VPN voor communicatie over internet.

[Viruskiller]

Modbus tcp, Profibus, Profinet, ASI-bus,... zijn allemaal [b]veld[/b-]bussystemen. Je zal ze hoogstens via de rooting van de PLC-sturing van buitenaf kunnen bereiken. Je dient dus je machine/fabriek fysiek af te schermen.

Siemens S7 is trouwens geen protocol, maar een reeks van PLC's.

[Femme]

De beveiliging afhankelijk maken van fysieke afscherming is niet van deze tijd, zeker als de communicatie plaatsvindt over een medium dat apparaten op grote afstand met veel tussenliggende schakels met elkaar kan verbinden.

Ook voor een lokale veldbus is het niet meer van deze tijd dat er geen beveiliging op de communicatie plaatsvindt. Stel je voor: indringers weten zich toegang te verschaffen tot een productielocatie (bijvoorbeeld een raffinaderij) en manipuleren de communicatie op een veldbus waardoor het productieproces in de soep loopt, met alle gevolgen van dien.

[farlane]

In dat geval is het aannemelijk dat de aanvallers ook fysiek toegang hebben tot de veldbus en zouden ze ook simpelweg de draden kunnen doorknippen om alles in de soep te laten lopen.

[Verwijderd]

Indringers in een raffinaderij (overigens gewoon over een hek springen/klimmen in de meeste gevallen) kunnen een heleboel meer en sneller schade toebrengen dan ingewikkeld gemanipuleer met de lokale veldbus. Dit is ook de hoofdreden dat lokale veldbussen niet of nauwelijks digitaal beschermd worden.
Met veldbus protocollen die gebruikt worden in SCADA omgevingen voor RTUs over grote afstanden zoals DNP3 wordt nu wel vaker encryptie toegepast.

[GekkePrutser]

Sinds bijv. Modbus ook op TCP beschikbaar is, is de kans natuurlijk veel hoger dat het onverhoopt wel via-via aan internet gaat hangen. Een VLANnetje verkeerd en het is al gebeurd. Toen het alleen maar RS485 snoertjes waren, was het inderdaad een stuk lastiger.

En dan heb ik het nog niet eens over de admins die het expres koppelen omdat het nou eenmaal super handig is als je vanuit een centrale lokatie overal bij kan. "En het is toch een intranet dus het is wel veilig"... Hoe vaak je dat niet hoort.

En inderdaad, fysieke scheiding is niet genoeg zoals Femme ook zegt. Zie stuxnet, dat was speciaal gebouwd om over de air gap heen te springen via USB sticks die door toeleveranciers meegenomen werden voor firmware upgrades.

(PS: Goede documentaire hierover: Zero Days)

[Reactie gewijzigd door GekkePrutser op 22 juli 2024 21:55]

[bozk]

"onveilige protocollen, zoals http [zijn] kwetsbaar voor man-in-the-middle-aanvallen. "

Volgens mij bedoeld Kapersky gewoon simpel weg; HTTP unencrypted over het lijn heen, waarbij een HTTPS wel encrypted is.

[borft]

Mwah, browser gaan er meestal wel vanuit dat de data die ze van een web server krijgen OK is. HTTP is kwetsbaar voor mitm aanvallen, omdat er geen manier is om de andere kant te identificeren (althans, niet als onderdeel van het protocol). Het is prima mogelijk een transparante proxy op de lijn te zetten, zonder dat de ontvanger of verzender die doorheeft. Verder is het dan ook nog mogelijk om de payload van requests aan te passen. Oftewel, het is, iig wat mij betreft, een geldig punt.

[atacama]

Als ik de bron snel doorlees is het eerder een (versimpelde) samenvatting dan een copy-paste van het bericht. Het persbericht is namenlijk een langer bericht dat de gemiddelde bezoeker hier wil lezen
In het bericht staat dat die systemen/protocollen een extra mogelijkheid geven voor aanvallers dmv een man in the middle aanval.

Ik ben niet bekend met alle genoemde systemen/protocollen. Maar bij http is het inderdaad zo dat een man in the middle zeer gemakkelijk kan worden uitgevoerd.
Dit heeft niets met aannames te maken. Daarnaast zijn er meer manieren om tussen 2 systemen te komen dan er 1 fysiek neer te zetten. Als je de DNS/routing systemen kan beinvloeden ben je al een heel eind natuurlijk.

[Reactie gewijzigd door atacama op 22 juli 2024 21:55]

[kozue]

Onzin natuurlijk. Als de communicatie over het internet verloopt heb je geen controle meer over wat er tussen zit. Jouw ISP, de AMSIX en nog vele andere providers in vele landen zitten tussen jouw verbinding met een buitenlandse server, en dat zijn allemaal punten die je niet zou moeten vertrouwen, want je weet niet wat daar gebeurt (het hele vertrouwen-aspect is dus niet relevant).
Om het nog maar niet eens te hebben over aanvallen op de routing-protocollen, die ook al uit de oertijd stammen. Zo kun je verkeer tussen Amsterdam en Utrecht omleiden via Rusland.

Verder staat er niet dat er daadwerkelijk mitm aanvallen uitgevoerd werden, maar dat de protocollen daar vatbaar voor zijn, wat inderdaad klopt.

[Armin]

Dit is onzin. Het veronderstelt dat een aanvaller een kwaadaardig systeem in het midden tussen twee systemen kan plaatsen, wat dan aangezien wordt en vertrouwd door de twee originele systemen. Maar dat gaat alleen op als die twee systemen elkaar uberhaupt vertrouwden!.

Precies, en die aanname is dan ook getest. Het gaat in dit onderzoek expliciet om systemen die commando's/opdrachten vanaf de open buitenwereld ontvangen. Een protocol als telnet, http, etc is dan kwetsbaar voor MitM.

Merk verder opd at ook als je de andere kant beperkt vertrouwd, dan nog zijn er gevaren. Denk aan buffer overflows of andere data input routines met bugs. Tenzij je geheel geen data accepteerd van de buitenwereld (end dus ook geen HTTP GET ondersteund) wordt het lastig qua beveiliging met inherent onveilige prortocollen.

[Khaine]

Het is en blijft bizar. Ik meen mij een filmpje te herinneren wat van Youtube is verwijderd waarop een talk te zien was van een hacker op DEF CON die met random URL scannen op diverse systemen kon inloggen. 1 Van de systemen waar hij bij kon was van een frans bedrijf wat een stuwdam nabij een klein dorpje beheerde. Die hadden voor het gemak van de engineers een SCADA systeem aan het internet geknoopt. In zijn talk geeft hij aan kinderlijk eenvoudig het inloggen op dergelijke systemen was (ze zijn immers gebouwd in de tijd dat access control niet heel relevant was).

Uit eerste hand weet ik dat in mijn stagetijd rond 2004 bij een bedrijf wat professionele IP-camera's verkocht de demonstratiecamera's ook altijd op basis van IP+port in te zien waren. Sommigen hadden ook pan-rotate aan boord. Als deze dan op het dak van gebouw tegenover je waren gepositioneerd had je dus effectief gezien een inkijk in de bedrijfsvoering van medewerkers binnen het bedrijf. Zeker toen men met superzoom lenzen om de hoek kwam.

Mij verbaast het dus ook niets dat dit gebeurt. Veel kritieke systemen horen nu eenmaal niet online benaderbaar te zijn. En als je als engineer dan toch aan op afstand erbij moet, dan verwacht je op zn minst een VPN connectie.

[Wouter M.]

Bedoel je dit filmpje misschien: "115 batshit stupid things you can put on the internet in as fast as I can go by Dan Tentler" https://www.youtube.com/w...=FLzTcBmTVvHihpGaK-hdKkKQ

Zeker een aanrader om te kijken. Het is echt fascinerend om te zien wat voor dingen er allemaal aan het publieke internet worden gekoppeld, zonder VPN. En in dit filmpje gaat het volgens mij dan ook nog om unauthenticated VNC, dat is dus niet alleen via het publieke internet beschikbaar, maar ook nog eens zonder wachtwoord.

[Khaine]

Goed gevonden! Dat was niet het exacte filmpje maar de opvolger ervan. Wel dezelfde spreker dus (ik heb de 110-variant gezien).

Inderdaad een aanrader om te kijken.

[RobinF]

Is die grafiek niet semi-open deur? Grotere landen zullen meer bereikbare controlesystemen hebben omdat er meer systeem staan. Het percentage is dus gelijk.

Mijns inziens is het beter om het aantal bereikbare controlesystemen te noemen per inwoner (makkelijk) of aantal bedrijven ofzo (lastiger)

[Cornelisjuh]

Daarnaast speelt afstand ook een rol, Amerika kan best uitgestrekt zijn. Ik kan me voorstellen dat men dan eerder voor een systeem dat op afstand te benaderen is zal kiezen.

[Reactie gewijzigd door Cornelisjuh op 22 juli 2024 21:55]

[Aikon]

Er is een groot verschil tussen 'op afstand benaderbaar' en 'via internet'. Op afstand benaderbaar is geen probleem en idd vaak wenselijk.

[Amanoo]

Dan nog moet je zo'n systeem niet zomaar online kwakken. Ik zou zeggen dat je dan een VPN moet gebruiken, al zijn die natuurlijk ook niet perfect en zou het kunnen dat systemen die via VPN te benaderen zijn ook zijn meegeteld.

[Rafe]

Als Shodan en Censys ic-systemen achter een virtual private network kunnen benaderen is er wat mis met de configuratie

[bigbadbull]

dit is blijkbaar niet zo 1/1, bvb België staat in de top 10 en voor Nederland.
En dacht niet dat België tot de 10 grootste lande behoorde.
Al is de industrialisatie graad van België veel groter dan pakweg Polen schat ik.

[Armin]

Is die grafiek niet semi-open deur? Grotere landen zullen meer bereikbare controlesystemen hebben omdat er meer systeem staan.

Inderdaad!

Behalve die laatste opmerking: Het percentage is dus gelijk.

Je zou dus moeten delen door bijvoorbeeld inwoners / oppervlakte om een meer vergelijkbare maat te krijgen. De percentages blijken dan niet gelijk te zijn.

Zo werd al gemeld dat Belgie het slechter doet dan Nederand, maar Nederland doet het weer slechter dan de VS als je per inwoner bekijkt.

Deels zal het ook wel toeval zijn. Land X gebruikt machine A vaker, welke kwetsbaar is en land Y juist machine B. Maar zorgelijk blijft het niettemin.

[Overlord2305]

Opzich niet, anders zou rusland ook hoger moeten staan dan bijvoorbeeld Nederland en Belgie, ook waneer je alleen kijkt naar het aantal inwoners

[equit1986]

en waar zijn de landen zoals Zuid Korea en China? ook grote landen, veel inwoners e.d.

[Dukey]

Ik schat dat dit issue alleen maar groter word met de hype omtrent IoT (internet of things).

[johnkeates]

Dat lijkt me niet. IoT ≠ Industriele controlesysteem. Daarnaast wort IoT vaak ook wel binnen consumenten netwerken achter NAT gebruikt, of via een non-internet systeem zoals Zigbee/X10/LoRAWAN enz.

[WienerBlut]

Ik was onlangs op een "IoT" conferentie voor de machine industrie en daar proberen fabrikanten zoals bijvoorbeeld Siemens etc. alles internet enabled aan te bieden. IoT is in dit geval misschien wel misbruikt als buzzword/marketingkreet...

Er springen fabrikanten zoals Barracuda Networks in dit gat om deze systemen achter een NAT te krijgen etc., maar ik vroeg op de stands van bijv. PLCs of deze systemen direct op via het internet benaderbaar zouden moeten kunnen zijn, zonder NAT etc. Antwoord zal niemand verrassen: geen probleem!

In hun hoofden is een IP adres analoog aan "goed voor aan het internet"... Bizar gewoon.

Het event: http://www.iot-vienna.at/taid2015/doku.php

edit: event toegevoegd

[Reactie gewijzigd door WienerBlut op 22 juli 2024 21:55]

[AMS76]

Klopt, ik merk in de praktijk vaak dat leveranciers van industrieële machines hun spullen graag rechtstreeks, zonder NAT of firewall, aan het internet willen hangen. Waarom? Bij navraag meestal kennisgebrek, 'zo kunnen wij er ook op inloggen'. Vaak gewoon via Telnet of http, zonder enige vorm van encryptie.
Als je dan uit gaat leggen dat dat anders moet, bots je vaak op een muur van onwil en onbegrip...

[mae-t.net]

Als consumer grade IoT spul in de industrie doordringt (en dat zal het wel doen) dan wordt het niet gewoon een groter issue, maar een veel groter issue.

[Tweekzor]

Deze conclusie komt ook elke paar maanden weer opnieuw uit een onderzoek gerold zeg. Neemt niet weg natuurlijk dat het een zeer kwalijke zaak is, vaak worden deze systemen met standaard of zeer zwak wachtwoord aan het internet gehangen. Het blijft apart om op een paar honderd plekken op de wereld in te kunnen loggen op camerasystemen met "admin:admin". Wel altijd iets nieuws te zien daardoor

[skatebiker]

Wederom bevestigt dit mijn verbazing dat ondanks allerlei (terechte) beveiligingsmaatregelen, alles maar klakkeloos met internet verbonden moet worden.

Industriele systemen zouden dat zeker niet moeten, en als het wel moet, alleen via een veilige VPN, maar ook consumentenproducten niet. En ook ieder OS zou standaard van een firewall voorzien moeten worden waarbij nieuwe apps standaard geen internet verbinding hebben (op een paar na zoals bijv. een browser, play / app store), tenzij de gebruiker dat expliciet aangeeft.
Dan krijgt malware ook veel minder kans.
Maar daar zullen veel app makers niet blij mee zijn omdat ze dan geen prive gegevens kunnen opharken.

[cdwave]

Plus natuurlijk dat zo'n onderzoek niet veel verder gaat dan "Oh, poort 80 accepteert een verbinding, dus HTTP, check". Dat er achter die HTTP server nog een heel scala aan beveiliging zou kunnen zitten voor je toegang krijgt tot meer dan alleen de "landing page", daar zal wel niet naar gekeken worden.

[johnkeates]

No shit, dit is op z'n minst al 5 jaar public knowledge. Kijk op shodan om maar wat te noemen, of de publicaties op DEF CON 20 en nieuwer. Hell, zelfs op http://vncroulette.com kan je industriële systemen tegen komen die via VNC op WAN zonder wachtwoord een GUI hebben. Veelal dingen zoals industriële vriezers, chemische installaties, opslagsystemen, skiliften enz, maar industrieel is het wel. Je kan er ook bruggen en presentatiesystemen tegenkomen.

[Amanoo]

Hoe komen ze erbij om niet op zijn minst een VPN er tussen te zetten? Eerst op het netwerk moeten inloggen? Veel te ingewikkeld, gewoon online kwakken die hap. Zelfs ik gebruik een VPN voor mijn systemen waar niet zomaar iemand bij mag, en dan hebben we het nog over dingen als de management van mijn Minecraft server.

[Reactie gewijzigd door Amanoo op 22 juli 2024 21:55]

[johnkeates]

Zelfs SSH is te hoog gegrepen voor de meeste 'beheerders' lijkt het... De security van veel systemen lijkt nog vooral op het 'zolang ze m'n nummer niet weten kunnen ze ook niet bellen' uit het telefoonmodem tijdperk.

[jeroen3]

Er is een zoekmachine gespecialiseerd in het vinden van Internet of Things. Deze indexeert per apparaat type/merk en probeert gelijk of de standaard passwords nog werken.
https://www.shodan.io/

De industrie loop enorm achter. Zo ook nog in deze video van twee lift-hackers.
https://youtu.be/ZUvGfuLlZus?t=3386

Maar er zijn ook bedrijven die het wel proberen! Zoals https://ewon.biz/ welke VPN remote access bieden via OpenVPN voor bij je PLC installatie.

[Reactie gewijzigd door jeroen3 op 22 juli 2024 21:55]