Zespół Kaspersky Lab ICS CERT przeanalizował protokół OPC UA (Object Linking and Embedding for Process Control Unified Automation), który służy do bezpiecznego przesyłania danych między serwerami a klientami w systemach przemysłowych, łącznie z infrastrukturą krytyczną. W trakcie analizy wykryto 17 luk dnia zerowego w implementacji protokołu, które mogą umożliwić przeprowadzenie ataków DoS, jak również zdalne wykonanie kodu.
Znaleziono także kilka błędów w produktach komercyjnych stworzonych w oparciu o ten protokół. Wszystkie luki zostały zgłoszone twórcom i usunięte do końca marca 2018 r.
OPC UA to protokół przemysłowy, opracowany i udostępniony przez OPC Foundation w 2006 r. w celu zapewnienia niezawodnej i bezpiecznej transmisji danych między różnymi systemami w sieci przemysłowej. Protokół ten jest powszechnie stosowany przez znanych producentów we współczesnych zakładach przemysłowych, w branży produkcyjnej, ropy i gazu, farmaceutycznej i innych. Jego bramy są instalowane przez coraz więcej przedsiębiorstw przemysłowych w celu zapewnienia komunikacji w ramach zautomatyzowanej kontroli procesów i telemetrii, jak również w systemach monitoringu i telesterowania, umożliwiając ujednolicenie procesów zarządzania w takich przedsiębiorstwach. Protokół ten jest ponadto wykorzystywany w przemysłowym Internecie Rzeczy (IIoT) oraz elementach inteligentnych miast, którymi coraz bardziej zaczynają interesować się cyberprzestępcy.
Eksperci z Kaspersky Lab ICS CERT przeanalizowali architekturę i produkty OPC UA. Po zbadaniu jego otwartego kodu źródłowego (dostępnego w serwisie GitHub), w tym przykładowego serwera, odkryto, że kod aktualnych implementacji protokołu zawiera błędy powstałe na etapie projektowania i pisania. Nie powinny one występować w tak popularnym oprogramowaniu dla infrastruktury krytycznej. Łącznie w produktach OPC Foundation zidentyfikowano 17 luk dnia zerowego. Zostały one zgłoszone twórcom poszczególnych produktów, którzy zastosowali odpowiednie łaty.
Ponadto Kaspersky Lab ICS CERT przeanalizował oprogramowanie osób trzecich oparte na tym protokole przemysłowym, w tym rozwiązania czołowych producentów w branży. W większości przypadków stwierdzono, że błędy spowodowane były tym, że twórcy nie stosowali poprawnie niektórych z funkcji implementacji protokołu. W innych przypadkach luki wynikały z niepoprawnych modyfikacji wprowadzonych do infrastruktury protokołu. Eksperci wykryli niespełniające wymogów bezpieczeństwa zastosowanie funkcji w produkcie komercyjnym, mimo że oryginalna implementacja OPC Foundation nie zawierała błędów. W efekcie modyfikacje w logice protokołu, dokonane przez producentów z niewiadomych powodów, prowadziły do funkcjonalności, która stanowiła ryzyko.
Wszystkie luki wykryte w implementacjach protokołu OPC UA mogły spowodować poważne szkody dla przemysłu. Z jednej strony istniało ryzyko problemów związanych z atakiem DoS, który mógłby stanowić poważne zagrożenie dla systemów przemysłowych poprzez zakłócenie lub przerwanie procesów przemysłowych. Z drugiej strony luki te umożliwiały zdalne wykonanie kodu, co oznaczało, że atakujący mogli wysłać dowolny rodzaj poleceń do serwera w celu kontrolowania procesów przemysłowych lub dalszego włamywania się do sieci.
– Bardzo często twórcy oprogramowania mają zbyt duże zaufanie do protokołów przemysłowych oraz implementują technologię w swoich rozwiązaniach bez testowania kodu produktu pod względem bezpieczeństwa. Opisane w tym przykładzie luki mogą mieć wpływ na całe linie produkcyjne, dlatego producenci muszą być czujni wobec takich powszechnie dostępnych technologii. Inną pułapką jest pomysł, aby samemu zaprojektować własne oprogramowanie. Wielu sądzi, że może to być wydajniejsza i bezpieczniejsza alternatywa dla istniejących już rozwiązań, jednak nawet całkowicie nowe oprogramowanie może zawierać wiele luk w zabezpieczeniach – powiedział Siergiej Temnikow, starszy badacz ds. bezpieczeństwa, Kaspersky Lab ICS CERT.
Kaspersky Lab zaleca organizacjom, aby:
- przywiązywały szczególną wagę do kontroli bezpieczeństwa oraz testów — jest to niezbędny krok w procesie rozwoju aplikacji, nawet jeżeli stosowane są już istniejące rozwiązania i protokoły,
- przeprowadzały audyty oraz testy penetracyjne w celu zidentyfikowania luk w zabezpieczeniach,
- izolowały procesy rozwoju oprogramowania, tak aby w przypadku zhakowania aplikacji, atakujący nie mogli uzyskać dostępu do sieci.