OPC UA naderbij bekeken

Abstract

PLC’s zijn al enkele decennia de ruggengraat van de industrie. Ze kunnen moeiteloos een ingewikkeld industrieel proces aansturen d.m.v. diverse I/O’s.  Maar het simultaan behandelen van meerdere gebruikers die opvragen hoe het met de productie gesteld is, behoort niet tot het takenpakket van een PLC.

Om die reden werd OPC ingevoerd, wat origineel stond voor het cryptische OLE for Process Control. Men zag echter snel een kans om, in tegenstelling tot de gesloten protocollen van de PLC’s, hier een open standaard van te maken. Zo werd OPC als Open Platform Communications geboren.
OPC bestaat dus uit een server en één of meerdere clients, waarbij de server enerzijds de taak heeft om de “taal” van de PLC’s te spreken en anderzijds de meerdere, simultane gebruikers toegang te geven tot diezelfde data. Dit op een gecontroleerde en veilige (lees: safe) manier.

OPC-DA (Data Access) was de eerste versie en stamt reeds uit 1996. De focus lag op het gebruik van Microsoft technologieën zoals OLE (Object Linking & Embedding), XML, .NET, DCOM en zelfs SOAP. Eén ding ontbrak echter bij OPC-DA: security.
OPC-UA (Unified Architecture) probeert ook die laatste horde te nemen en biedt mogelijkheden tot vergevorderde security. De standaard werd reeds uitgebracht in 2006, maar zoals dat met standaarden en specificaties gaat wordt hier zeer geregeld aan gesleuteld. De recentste versie is 1.03 en dateert uit oktober 2015.

Bron: https://opcfoundation.org/about/opc-foundation/history/

Dit artikel poogt een, vanuit een security en netwerk technisch standpunt na te gaan in welke mate OPC UA veilig kan worden ingezet.

Concreet

OPC-UA is een standaard waarbij alle details van het protocol/framework kunnen worden opgevraagd bij de OPC Foundation. Helaas is de toegang enkel voorbehouden voor leden: https://opcfoundation.org/developer-tools/specifications-unified-architecture

Alles wat hier wordt vermeld, is uitgeschreven zonder inzage in deze documenten. Het is dan ook aan de makers van de OPC-UA software om deze richtlijnen strikt of minder strikt te volgen.
We mogen ervan uitgaan dat de standaard correct is opgesteld, maar dat de echte veiligheid en bruikbaarheid van OPC-UA afhangt van de implementatie per fabrikant.
Dit artikel heeft niet als doel om een overzicht van de fabrikanten te geven maar wel om tips te geven bij het gebruik van OPC-UA.

OPC-UA heeft ondersteuning voor encryptie, ondertekening, pakketsequentie, authenticatie, rechten en logging, waardoor het alles aan boord heeft om inderdaad een veilig alternatief te zijn voor OPC-DA. Maar om meteen met de deur in huis te vallen: de ondersteuning is aanwezig maar zal niet werken zonder de noodzakelijke configuratie!
Zoals bij veel andere systemen zal de beveiliging van een OPC-UA implementie dus staan of vallen bij hoe goed de configuratie werd gedaan.

Een paar technische details

OPC-UA is een open standaard en heeft als groot voordeel dat er toch heel wat softwaremakers mee aan de slag zijn gegaan. Er zijn dan ook reeds heel wat Open Source implementaties van OPC-UA: https://github.com/open62541/open62541/wiki/List-of-Open-Source-OPC-UA-Implementations

Het is eenvoudig om m.b.v. bijvoorbeeld Python een bestaande OPC-UA server te ondervragen, dit demonstreert ook de eenvoud van het opbouwen van een OPC-UA verbinding:

Bovenstaand is een voorbeeld van de technische opbouw van een verbinding, zoals deze veel voorvalt:

De authenticatie (initiële verbinding met de server) gebeurt m.b.v. certificaten, hier is het dus noodzakelijk dat het certificaat (uaexpert.der in bovenstaand voorbeeld) goedgekeurd is bij de server, dit wordt namelijk uitgewisseld.
Bij sommige server implementaties verloopt dit simpel: probeer gewoon eerst te verbinden.
Dit zal initieel falen maar het gebruikte certificaat komt in een lijst van goed-te-keuren verbindingen. Eenmaal het certificaat van de gebruiker is goedgekeurd, zullen nieuwe verbindingspogingen wel werken.

Als we echter het verkeer bekijken in een netwerkanalyse tool zoals bijv. Wireshark zien we toch herkenbare data die over het netwerk voorbijkomen:

• Hier valt meteen op dat Wireshark geen enkel probleem heeft om ieder en elk pakketje te identificeren en te tonen. Als we bijvoorbeeld naar pakket 50 kijken (ReadRequest, wat overeenkomt met het ophalen van de PLC waarde):

We zien hier een “SecureChannelId” wat dus zogenaamde replay attacks moet tegenhouden, maar wat het niet tegenhoudt, is bijv. een zogenaamde “Man-In-The-Middle” aanval: iemand die dit verkeer ziet langskomen kan eenvoudig de “Identifier String” aanpassen naar een andere waarde zodat de gebruiker ongevraagd iets anders doet of opvraagt dan bedoeld.

• Uiteraard is het ook mogelijk om het antwoord te zien (ReadResponse):

Hier zien we duidelijk “Boolean: True”, wat in het pakket vertaald wordt naar een binaire “1”. Het is triviaal om dit te wijzigen naar een “0” bij het onderscheppen van het verkeer om zodoende toch verwarring te scheppen in het OPC-UA verkeer.

Is OPC-UA nu in de fout? Wat is nu de oorzaak? Bij het opbouwen van de verbinding werd het sleutelwoord “Sign” gebruikt, terwijl een meer beveiligde keuze “SignAndEncrypt” zou zijn. Bij “SignAndEncrypt” wordt elk pakket afzonderlijk geëncrypteerd, net zoals dat bij bijv. HTTPS het geval is.

Het gaat dus puur om configuratiekeuzes, er zijn dus een aantal zogenaamde Best Practices om rekening mee te houden.

Best Practices, OPC-UA samenvatting

Bij het opzetten van eender welke OPC-UA server is het dus belangrijk om de initiële configuratie zo veilig mogelijk te doen:

Als er zonder nadenken een OPC-UA server wordt geïnstalleerd bestaat de kans dat het eruit ziet zoals hiernaast, let op de “None” optie. Deze optie laat toe om zonder authenticatie te verbinden met de OPC-UA server. Bij het configureren staat deze optie dus best uit.

Verder is er zichtbaar dat er voor elke sleutellengte (128 Bytes of 256 Bytes, beide zijn OK) twee mogelijkheden zijn: Sign of Sign & Encrypt. Eventueel kan Sign uitgeschakeld worden, maar aan de serverkant is dit niet noodzakelijk. Het is wél belangrijk om dan bij OPC-UA clients die gebruik maken van een onbeveiligd medium (bijv. internet), zéker de Sign & Encrypt mode te gebruiken.

Als extra optie is het ook mogelijk om, bovenop het gebruik van certificaten, ook nog gebruikers en/of wachtwoorden te gebruiken. OPC-UA kan deze gebruiken om afzonderlijke gebruikers toegang te geven tot afzonderlijke nodes en/of objecten. Standaard (bijv. bij de Kepware afbeelding zoals hierboven) staat echter “Anonymous” toegang open en kan iedereen dus aan alles na een succesvolle verbinding, wat meestal niet wenselijk is.

Conclusie

Een goede en veilige manier om OPC-UA te configureren zou er dus uit bestaan om te kiezen voor Basic256 met Sign & Encrypt in combinatie met een gebruikersnaam/wachtwoord (bij gebruik van meerdere objecten/gebruikers).

Er is echter nog een tweede aspect dat van belang is, en dit staat in principe los van OPC-UA maar is echter ook zeer belangrijk: software bugs of fouten.
Als er tijdens het programmeren van een software fouten worden gemaakt die toelaten dat iemand anders “slechte” zaken kan uitvoeren op uw infrastructuur, dan wordt dit een Security Bug of heel technisch een Common Vulnerability & Exposure (CVE) genoemd. Deze krijgt dan de, in de security wereld bekende, CVE-code, zoals bijv. CVE-2016-7090.

Er zijn op dit moment reeds een tweetal dergelijke fouten gevonden in de OPC-UA gerelateerde software:

• CVE-2009-3241: een oude fout uit 2009 in Wireshark versie 1.2.0 waarbij Wireshark crasht indien het een foutief gemaakt OPC-UA pakket probeert te doorgronden. De oplossing is simpel: updaten naar versie 1.2.1 of hoger.
• CVE-2017-12069: iets recenter (eind 2017) werd een fout gevonden in een aantal Siemens SIMATIC producten (PCS7, WinCC, NET PC, IT Production …) in het afhandelen van OPC-UA gebruikers.
  Voor bepaalde producten (WinCC en IT Production) is er een update, maar voor PCS 7 en NET PC raadt Siemens aan om OPC-UA gewoon uit te zetten.

Dus naast een correcte configuratie van OPC-UA is het ook belangrijk om eventuele updates te installeren, uiteraard in de mate van het mogelijke.