W ostatnim czasie CERT Polska obserwuje zwiększoną liczbę ataków na przemysłowe systemy sterowania (ICS/OT) dostępne bezpośrednio z internetu. Podobne przypadki odnotowali również nasi zagraniczni partnerzy. Ataki te najczęściej są motywowane aktywistycznie lub politycznie i mają na celu medialne wykorzystanie udanego ataku. Warto zaznaczyć, że CERT Polska odnotował również przypadki, w których atak miał realny wpływ na działanie fizycznych systemów.

W związku z obserwowanym zagrożeniem CERT Polska od trzech lat prowadzi działania pod nazwą #BezpiecznyPrzemysł, w ramach których w sposób zautomatyzowany poszukiwane są źle zabezpieczone urządzenia przemysłowe dostępne z internetu. W przypadku wykrycia błędnej konfiguracji właściciel urządzenia (jeśli to możliwe) otrzymuje powiadomienie o związanym z tym zagrożeniu wraz z rekomendacjami.

Niestety w wielu przypadkach urządzenia przemysłowe podłączone są do internetu przez routery komórkowe, których adres IP wskazuje na operatora komórkowego, którego karta SIM została użyta. W takiej sytuacji nie mamy możliwości dotarcia do właściciela, możemy jedynie przekazać informacje do operatora telekomunikacyjnego. Dlatego kluczowa jest świadomość zagrożeń związanych z wystawieniem urządzeń do internetu i znajomość najlepszych praktyk realizacji dostępu zdalnego tam, gdzie jest on konieczny – zarówno po stronie właścicieli urządzeń, jak i firm wdrażających i sprzedających rozwiązania OT.

W związku z poważnym zagrożeniem wzywamy podmioty posiadające systemy przemysłowe do podjęcia natychmiastowych działań i wprowadzenia opisanych poniżej rekomendacji.

Techniczny opis zagrożenia

Obserwujemy działania licznych grup, najczęściej prorosyjskich, które wykorzystując ogólnodostępne serwisy, takie jak Shodan, Zoomeye czy Censys, wyszukują urządzenia i aplikacje związane z przemysłowymi systemami sterowania. Najczęściej ataki przeprowadzane są na dostępne z internetu:

• panele WWW systemów HMI i SCADA z brakiem uwierzytelniania lub słabym hasłem,
• usługi VNC z brakiem uwierzytelniania lub słabym hasłem, dające zdalny dostęp do panelu HMI czy systemu SCADA,
• routery z modemem komórkowym z domyślnym lub słabym hasłem albo posiadające znane podatności,
• protokoły przemysłowe bez uwierzytelniania, jak Modbus, BACnet czy PCOM.

Poniżej prezentujemy fragment filmu opublikowanego przez jedną z grup prorosyjskich, który pokazuje modyfikację parametrów pracy gminnej oczyszczalni ścieków, po uzyskaniu do niej dostępu przez usługę VNC ze słabym hasłem:

Najważniejsze zalecenie

Kategorycznie odradza się eksponowanie bezpośrednio do internetu systemu umożliwiającego sterowanie procesem przemysłowym, nawet jeśli wydaje się, że jest on skonfigurowany w trybie tylko do odczytu. Oznacza to, że:

• NIE NALEŻY umożliwiać bezpośredniego zdalnego połączenia z wykorzystaniem protokołów jak VNC czy RDP oraz oprogramowania zdalnego wsparcia technicznego,
• NIE NALEŻY umożliwiać bezpośredniego zdalnego dostępu do panelu WWW systemów sterowania i wizualizacji, nawet jeśli stosowane jest silne hasło,
• NIE NALEŻY udostępniać portów, na których działają protokoły przemysłowe – w szczególności umożliwiające konfigurację urządzenia.

Jeśli do odczytu lub sterowania procesem wymagany jest zdalny dostęp, należy skorzystać z VPN z wieloskładnikowym uwierzytelnianiem. Dotyczy to również małych instalacji, które najczęściej padają ofiarą ataków.

Zalecenia szczegółowe

Poniższe rekomendacje są rozbudowane i zdajemy sobie sprawę, że nie każdy podmiot będzie w stanie je wdrożyć. W pierwszej kolejności należy zatem zadbać o opisane powyżej najważniejsze zalecenia.

CERT Polska/CSIRT NASK w zakresie opisanego problemu rekomenduje:

1. Zmniejszenie do minimum ekspozycji sieci przemysłowej, zarówno sieci lokalnej, jak i punktów styku, poprzez identyfikację i ograniczenie do koniecznych połączeń „z" i „ do" tej sieci.
2. Przeprowadzenie przeglądu zdalnego dostępu i ograniczenie go do niezbędnego minimum, w szczególności należy zwrócić uwagę na modemy komórkowe i metody zdalnego dostępu podwykonawców.
3. W przypadku gdy zdalny dostęp jest potrzebny, powinien być zawsze realizowany za pomocą VPN z wieloskładnikowym uwierzytelnianiem.
4. Tam, gdzie to możliwe, ograniczenie dostępu do VPN dla określonych adresów IP lub ich zakresów. Przykładowo: gdy podmiot nie ma współpracowników ani podwykonawców zagranicznych, rekomenduje się ograniczenie możliwości nawiązania sesji VPN tylko dla polskich adresów IP.
5. W przypadku gdy niezbędny jest zdalny przesył danych telemetrycznych za pomocą sieci komórkowej, rekomenduje się wykorzystanie prywatnych APN-ów.
6. Zmianę domyślnych danych uwierzytelniających z zastosowaniem dobrych praktyk związanych z silnymi hasłami (o ile urządzenie takie hasła wspiera) na wszystkich urządzeniach, w szczególności tych posiadających interfejs webowy, oraz wyłączenie niewykorzystywanych kont.
7. W miarę możliwości, gdy nie ma przeciwwskazań, aktualizowanie wykorzystywanych systemów, w szczególności podczas planowych postojów.
8. Stosowanie segmentacji sieci – minimalnie na styku sieci przemysłowej z innymi sieciami, a preferencyjnie, zależnie od rozmiaru i złożoności sieci, również wewnątrz.
9. Przeprowadzenie analizy widoczności urządzeń poprzez zewnętrzne skanowanie zakresu adresacji należącej do obiektu czy wykorzystanie narzędzi typu Shodan.
10. Tam, gdzie to możliwe zdalny dostęp powinien być realizowany na żądanie. Każde prowadzenie zdalnych czynności na systemie powinno zostać odnotowane w sposób pozwalający jednoznacznie zidentyfikować czas, cel i źródło prowadzonych prac.
11. Wykrywanie anomalii w ruchu sieciowym, w szczególności odbiegających od połączeń realizowanych podczas normalnego trybu pracy instalacji.
12. Utwardzenie konfiguracji wykorzystywanych urządzeń i oprogramowania przez wyłączenie niewykorzystywanych funkcji i konfigurację wbudowanych dodatkowych mechanizmów bezpieczeństwa. Często domyślnie są one nieaktywne.
13. Zgłoszenie osoby kontaktowej do CSIRT NASK, aby usprawnić ścieżkę reakcji w przypadku wykrycia tego typu incydentu.
14. Zarejestrowanie się w systemie n6 przez podanie swojej adresacji IP i domeny, co pozwoli na wysyłanie przez CERT Polska powiadomień w przypadku wykrycia nieprawidłowości.

Case Study

Na początku roku CSIRT NASK otrzymał od CSIRT MON informację o atakach brute force na usługę SMTP jednego z podmiotów. Atak prowadzono z dwóch adresów IP. Alarmujące było to, że na obu adresach widoczne były usługi związane z systemami przemysłowymi – na jednym był to port 502 (protokół Modbus), a na drugim port 102 (protokół S7) oraz panel WWW sterownika Siemens S7-1200. Po dokładniejszej analizie uznano, że cechą wspólną, nietypową dla tego typu urządzeń, jest port 22 (SSH). Dodatkowo na jednym z adresów na porcie 80 był dostępny panel WWW komórkowego routera przemysłowego Elmatic Sparrow. Z dużym prawdopodobieństwem stwierdziliśmy, że zaobserwowane wcześniej protokoły przemysłowe zostały udostępnione właśnie za pomocą tego routera komórkowego.

Nadal nie było jednak jasne, jak atakujący mógł przeprowadzić atak brute force, wychodząc z danego adresu IP. W tym celu musiałby albo przejąć router i wykonywać to bezpośrednio z niego, albo prowadzić atak z zainfekowanego urządzenia wewnątrz sieci. W danym momencie bardziej prawdopodobna wydawała się druga możliwość.

Udało się nam nawiązać kontakt z jednym z dotkniętych podmiotów i poprosić go o analizę ruchu wewnątrz sieci. Okazało się, że żaden podejrzany ruch nie był widoczny, mimo że ataki nadal trwały. W takiej sytuacji, o ile ruch został poprawnie zebrany, ataki musiały wychodzić bezpośrednio z routera komórkowego, co prawdopodobnie powodowało, że były one niewidoczne dla systemów monitorujących sieć wewnętrzną.

Przeszukując dostępne źródła, nie natrafiliśmy na żadne znane podatności dotyczące routera Elmatic Sparrow ani NavigateWorx (który technicznie jest tym samym urządzeniem). Poprosiliśmy dotknięty podmiot o pozwolenie na zalogowanie się na urządzenie, ale podmiot nie miał informacji o danych logowania – urządzenie zostało zainstalowane przez firmę trzecią. Bardzo niepokojące było to, że domyślne ustawienia: login i hasło (admin:admin) zadziałały. Jednak w interfejsie webowym nie było bezpośrednio możliwości przeprowadzenia omawianego ataku (o ile nie została użyta podatność w tym interfejsie).

Router poprzez interfejs webowy posiada wbudowane narzędzie pozwalające nagrać ruch sieciowy na interfejsie WAN. Wykorzystaliśmy je i udało się potwierdzić wychodzące ataki brute force na znaczną liczbę podmiotów:

Podejrzewaliśmy wykorzystanie nieznanej podatności, więc skontaktowaliśmy się z firmą Elmark Automatyka będącą jedynym dystrybutorem urządzenia Elmatic Sparrow w Polsce. Reakcja firmy była pozytywna i otrzymaliśmy egzemplarz urządzenia do testów.

Po uruchomieniu routera i sprawdzeniu otwartych portów zauważyliśmy, że poza panelem WWW dostępna jest również usługa SSH na porcie 22. Port ten widzieliśmy też wcześniej, otwarty na urządzeniach, z których był prowadzony atak. Okazało się, że w domyślnej konfiguracji możliwe jest zalogowanie do usługi SSH również z użyciem poświadczeń admin:admin, a co więcej, jest ona domyślnie włączona na interfejsie WAN:

Byliśmy pewni, że w ten sposób uzyskamy dostęp do powłoki systemu, gdzie znajdziemy skrypt prowadzący atak. Jednak po zalogowaniu okazało się, że router udostępnia jedynie bardzo ograniczoną powłokę CLISH.

Podczas prowadzonych testów nie udało się nam z eskalować z ograniczonej powłoki i nie znaleźliśmy sposobu na uruchomienie dodatkowych poleceń pozwalających wykonać atak z konta admin. Nie znaleźliśmy również (w czasie krótkich testów) żadnej podatności pozwalającej uzyskać zdalny dostęp do powłoki systemu.

Potwierdziliśmy natomiast, że na obu dotkniętych adresach IP działało hasło admin:admin do SSH (a na jednym z adresów nie było dostępnego panelu WWW). W związku z tym nasza uwaga jeszcze mocniej skoncentrowała się na tej usłudze. Niestety nie mogliśmy dostać fizycznie urządzeń, które były zaatakowane, aby poddać je dokładniejszej analizie.

Kolejną hipotezą, którą rozważyliśmy było wykorzystanie usługi SSH, posiadającej domyślne poświadczenia, do stworzenia tunelu, który pozwoliłby skorzystać z routera jako proxy do prowadzenia ataków.

Przetestowaliśmy, czy taki sposób wykorzystania zadziała na naszym egzemplarzu urządzenia:

ssh -p 22 -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedKeyTypes=+ssh-rsa -N -D 127.0.0.1:1080 [email protected]

Powyższa komenda powinna otworzyć lokalnie port 1080, z którego cały ruch przychodzący będzie tunelowany przez urządzenie. Potwierdziliśmy, że faktycznie jesteśmy w stanie uzyskać adres IP urządzenia, odwołując się do zasobu w internecie:

Po przedstawieniu tych informacji dotkniętym podmiotom i we współpracy z nimi udało się potwierdzić, że istotnie był to użyty wektor ataku.

W tym przypadku tunel został użyty do przeprowadzenia ataków brute force na inne usługi w internecie, ale tego typu atak mógł posłużyć również do uzyskania dostępu do wewnętrznej sieci LAN atakowanego podmiotu, co byłoby znacznie groźniejsze. W konsekwencji możliwe byłoby uzyskanie poprzez tunel bezpośredniego połączenia z urządzeniami przemysłowymi wewnątrz sieci. Co więcej, nawet jeśli podmiot korzystałby z VPN skonfigurowanego na urządzeniu dla dostępu do sieci LAN, to pozostawienie na urządzeniu usługi SSH ze słabym hasłem pozwoliłoby atakującemu ominąć VPN.

Razem z firmą Elmark Automatyka podjęliśmy działania, aby znaleźć właścicieli wszystkich routerów Elmatic Sparrow oraz NavigateWorx, widocznych w internecie, i powiadomić ich o konieczności zmiany domyślnego hasła i wyłączenia nadmiarowych usług. Dodatkowo firma Elmark Automatyka przygotowała na swojej stronie internetowej, a także rozesłała do klientów poradnik, jak bezpiecznie skonfigurować urządzenie oraz ma w planach dołączenie wydrukowanej ulotki na ten temat do pudełka z urządzeniem. Mamy również nadzieję, że w kolejnych wydaniach firmware domyślne ustawienia zostaną zmienione na bezpieczniejsze.

Przedstawiony przypadek pokazuje, jak ważne są: zmiana domyślnych poświadczeń, utwardzanie konfiguracji urządzenia przez ograniczanie dostępnych usług oraz monitorowanie sieci – na wypadek gdyby atakujący użyli urządzenia do ataku na sieć lokalną.

Dziękujemy firmie Elmark Automatyka za wzorową współpracę i zachęcamy innych dostawców w Polsce do tworzenia w języku polskim instrukcji bezpiecznej konfiguracji dla urządzeń przemysłowych.