Bezpieczeństwo sterowników PLC¶

Sterownik PLC jest często tym urządzeniem, które przychodzi na myśl jako pierwsze w kontekście urządzeń przeznaczonych dla przemysłu. Jego bezpieczeństwo możemy rozważać w warstwie:

• logiki, czyli programu na nim działającego,
• konfiguracji, czyli np. uprawnień do zmiennych,
• usług udostępnianych na zewnątrz (np. serwer WWW czy usługa SNMP),
• oprogramowania wbudowanego (firmware),
• komunikacji, czyli np. bezpieczeństwa protokołu konfiguracyjnego.

Oczywiście wszystkie te zagadnienia będą się przeplatać. Konfiguracja może mieć np. wpływ na to, jakie usługi będą udostępniane, a niedostępność usług może być spowodowana błędem w oprogramowaniu wbudowanym.

Bezpieczeństwo logiki¶

Stosunkowo trudno jest napisać logikę w taki sposób, aby wprost z tego powodu wynikały podatności w rozumieniu cyberbezpieczeństwa. Można jednak utrudnić atak na innych warstwach poprzez zastosowanie kilku zasad, np.:

• odpowiedni podział bloków programu – co ułatwi jego przegląd,
• zdefiniowanie wartości granicznych dla zmiennych,
• logowanie czasu cyklu wykonania programu.

Po dokładną listę i szczegóły odsyłam do Top 20 Secure PLC Coding Practices. Z doświadczenia wynika, że jest to temat niemal całkowicie nieznany wśród programistów PLC.

Warto też wspomnieć o możliwości zabezpieczenia logiki przed odczytem przez nieuprawnioną osobę w przypadku pozyskania przez nią plików projektowych. Funkcję tę nazywa się know-how protection, a powstała ona w celu ochrony własności intelektualnej. Jej implementacja zależy od producenta, ale najczęściej polega na symetrycznym szyfrowaniu fragmentów projektu z wykorzystaniem podanego hasła.

Jeszcze kilka lat temu jakość implementacji tego mechanizmu była bardzo niska i stosunkowo łatwo można było to hasło odzyskać (wręcz zdarzały się przypadki zapisywania go czystym tekstem w pliku projektowym!). Obecnie jest lepiej, ale nadal trzeba pamiętać, że jest to mechanizm podatny na ataki siłowe. O ile do zabezpieczenia kopii zapasowych lepiej jest stosować zewnętrzne mechanizmy szyfrowania całych plików, to w przypadku gdy atakujący chciałby pozyskać kod poprzez pobranie go ze sterownika, takie szyfrowanie będzie na pewno utrudnieniem.

Bezpieczna konfiguracja¶

Bezpieczna konfiguracja będzie w dużej mierze zależała od tego, na co pozwala dane urządzenie. Każdy producent będzie udostępniał inne opcje. Nowsze sterowniki posiadają możliwość ustawienia hasła do zapisu i odczytu logiki (np. Application Protection w sterownikach Schneider Electric czy Access Control w sterownikach Siemensa S7-1500).

Inna możliwa opcja to konfiguracja uprawnień do konkretnych zmiennych. Można wybrać, czy zmienna ma być widoczna, możliwa do odczytu lub możliwa do zapisu z poziomu panelu HMI (protokół S7) oraz protokołu OPC UA.

Bezpieczeństwo usług¶

Ważną zasadą bezpieczeństwa jest to, żeby wszystko, z czego nie korzystamy, zostało wyłączone. W rzeczywistości zazwyczaj zostawiane są ustawienia domyślne. Znaczna część urządzeń przemysłowych ma np. wbudowany serwer WWW mający umożliwić prostszą konfigurację – i w większości przypadków nie jest on ani potrzebny, ani wykorzystywany i po wdrożeniu mógłby zostać wyłączony. Praktyka pokazuje, że często pozostaje włączony z domyślnymi danymi logowania. Wiele podatności dotyczy właśnie tego komponentu, bo dochodzi tu całkiem nowa klasa błędów związana z bezpieczeństwem aplikacji webowych. Innym przykładem może być serwer FTP czy Telnet.

Błędy w oprogramowaniu wbudowanym (firmware)¶

Może również zdarzyć się tak, że mimo poprawnej konfiguracji i w odpowiedni sposób napisanego kodu atak zostanie przeprowadzony z wykorzystaniem podatności związanej z tym, jak dane są przetwarzane. Takie podatności znajduje się dzięki analizie plików oprogramowania (często potrzebna jest analiza wsteczna) albo przez fuzzing, czyli automatyczne wysyłanie dużej liczby odpowiednio spreparowanych danych i obserwowanie zachowania aplikacji czy urządzenia. W przypadku urządzeń automatyki przemysłowej najczęściej punktem wejścia będą protokoły sieciowe, w tym słabo udokumentowane protokoły przemysłowe.

Protokoły administracyjne¶

Wiele sterowników jest programowanych i konfigurowanych przy użyciu innego protokołu niż wykorzystywany do standardowej komunikacji. Tak było w przypadku ataku na rafinerię w Arabii Saudyjskiej w 2017 roku, kiedy zamknięty protokół TriStation miał zostać użyty do zmiany zawartości pamięci sterownika SIS i w efekcie do niezauważalnej podmiany jego logiki.

W przypadku urządzeń Rockwell Automation okazało się, że wszędzie używany jest ten sam zaszyty na stałe klucz (ang. cryptographic key), którego poznanie pozwala przeprogramować sterownik, a nawet podmienić firmware. Ogłoszono nawet, że nie może to zostać naprawione przez wydanie aktualizacji, więc jego poznanie daje otwarte drzwi do wielu urządzeń z serii CompactLogix, ControlLogix czy GuardLogix, jeśli nie działają w trybie RUN.

Innym przykładem jest protokół UMAS zbudowany na bazie funkcji o kodzie 90 protokołu Modbus. Został on stworzony przez firmę Schneider Electric na potrzeby programowania jej sterowników. Nie ma do niego dokumentacji, a pierwszy raz głośno zrobiło się o nim przy okazji projektu BaseCamp w 2012 roku. Od tego czasu jego możliwości poddawano wszechstronnej analizie i w Internecie można już znaleźć jego dokładny opis.

Mimo że brzmi to niewiarygodnie, to nadal można za pomocą protokołu UMAS wyłączyć wiele sterowników firmy Schneider Electric, niezależnie od ustawienia hasła.