Przez długi czas bezpieczeństwo systemów sterowania automatyką przemysłową było ignorowane. Mimo, iż coraz więcej systemów jest podłączanych do internetu, podejście zmienia się bardzo powoli, czego dowodzą kolejne wykryte błędy.
Głównym produktem firmy Tridium jest Niagara Framework – platforma służąca do integracji sterowania wieloma systemami różnych dostawców. Znajduje ona zastosowanie w wielu obszarach. Korzystają z niej szpitale do sterowania sprzętem medycznym, zarządcy budynków do integrowania systemów bezpieczeństwa fizycznego, przeciwpożarowych, klimatyzacji i wentylacji czy lotniska do integracji tysięcy czujników i systemów alarmowych. Wśród 11 milionów podłączonych urządzeń w 52 krajach znajdują się także budynki należące do Pentagonu, FBI, DEA czy innych amerykańskich agencji federalnych.
Przykładowa architektura systemu (źródło: Tridium)
Brak podstawowych zabezpieczeń
Zasłyszane na konferencji plotki o dziurach w systemie zachęciły dwóch badaczy do bliższego przyjrzenia się Niagara Framework. Po dwóch dniach spędzonych z dokumentacją systemu i wersją demo interfejsu udostępnioną w sieci odnaleźli trywialny błąd typu directory traversal, pozwalający atakującemu odczytać zdalnie plik konfiguracyjny config.bog z nazwami użytkowników i hashami ich haseł. Złamanie hashy pozwala atakującemu na uzyskanie pełnego dostępu do konsoli www, umożliwiającej zarządzanie urządzeniami podłączonymi do systemu.
Badacze wybrali ścieżkę odpowiedzialnego ujawnienia, więc do tej pory nie opublikowali informacji o wszystkich odnalezionych błędach. Z dokumentu wydanego wczoraj przez producenta, ostrzegającego przed potencjalnym zagrożeniem, możemy wyczytać kolejną ciekawostkę – w przypadku, gdy włączone jest konto guest, dowolny użytkownik próbujący uzyskać dostęp do systemu, automatycznie dostanie uprawnienia na poziomie tego konta, bez względu na to, czy konto jest zabezpieczone hasłem, czy nie. Dodatkowo prawdopodobnie system dostarczany jest z domyślnym loginem i hasłem użytkownika, którego zmiana nie jest wymuszana.
Mistrzowski czas reakcji
W całej historii, oprócz trywialności odkrytych błędów, najciekawsza jest reakcja producenta. Po pierwsze, błędy zostały odkryte i zgłoszone w styczniu tego roku. Producent w ogóle nie zareagował, mimo wielu eskalacji ze strony amerykańskiego rządowego zespołu CERT. Dopiero duży artykuł w Washington Post poświęcony tematowi podziałał – kilka dni później pojawiły się zarówno aktualizacje, jak i instrukcje dla użytkowników, jak zabezpieczyć system.
To nie nasza wina
Drugim aspektem sprawy jest próba zrzucenia przez producenta odpowiedzialności na użytkowników systemu. To oni wystawili system do internetu, to oni nie zmienili domyślnych haseł, to oni nie zmienili domyślnych uprawnień do plików konfiguracyjnych… Wszystkie zarzuty są prawdziwe, jednak aż do wczoraj użytkownicy systemu Niagara Framework nie dysponowali żadną instrukcją ani wskazówkami, co powinni zrobić, by podnieść bezpieczeństwo systemu. Dodatkowo, niektóry funkcje systemu znacząco utrudniały jego zabezpieczenie, a problemy, odkryte przez badaczy w styczniu, były zgłaszane już rok wcześniej w wyniku audytu bezpieczeństwa u jednego z klientów.
Podejście producenta do tematu bezpieczeństwa dobrze ilustruje jeden przykład – firma oświadczyła, że spróbuje przenieść plik konfiguracyjny w inne miejsce, trudniejsze do znalezienia, by usunąć problem zdalnego doczytywania haseł przez dowolnego użytkownika.
Trzeba przyznać, że sektor automatyki przemysłowej potrafi wiele wybaczyć w obszarze bezpieczeństwa. Jak widać, można być jednym z czołowych dostawców i w ogóle nie przejmować się błędami w swoich produktach – a klienci i tak przyjdą i kupią. Zapewne wiele lat zajmie zmiana tak niedbałego podejścia do kwestii bezpieczeństwa.
