Standardowe praktyki bezpieczeństwa obecne w branży technologii informacyjnej niekoniecznie przenoszą się na działy IT innych firm, również tych z sektora przemysłu. Może to prowadzić do scenariusza, w którym wdrażane zostają zaawansowane i kosztowne produkty bez odpowiedniego zabezpieczenia. Godne uwagi jest to, że podatności w ICS mogą skompromitować całe organizacje, ujawniając brak podstawowych zasad bezpieczeństwa.

Poważne problemy w rozwiązaniu B & R

W czwartek 30 maja 2019, firma badawcza Positive Technologies ogłosiła odkrycie podatności w systemach automatyzacji procesów przemysłowych APROL firmy B&R Automation. Jak pisze TechRepublic (a my się z nimi zgadzamy), w żadnym wypadku nie jest to przełomowe odkrycie strategii na miarę ataku bizantyńskiego*. Wykryte luki są po prostu przypadkiem ignorowania podstawowych zaleceń bezpieczeństwa – wyłączenia niezaszyfrowanego dostępu do FTP i narzędzi pobierających informacje o użytkownikach (protokół Finger), uniemożliwienie dostępu SSH jako root (za pomocą haseł), limitowanie prób dostępu, szyfrowanie dostępu do VNC i wyłączenie anonimowego dostępu LDAP do serwerów. Co więcej, badacze Positive Technologies wskazują również na „błędy w dostępie do pamięci w komponencie TbaseServer, błędy w komponentach AprolLoader i AprolSqlServer oraz SQL injection w systemie EnMon (monitorowanie i zapis zużycia energii) z możliwością wprowadzania dowolnych poleceń do serwera”.

Architektura systemu B & R APROL

Kolejnym problemem jest to, że chociaż B&R Automation wypuścił patche, użytkownicy wcześniejszych wersji APROL R będą musieli ręcznie zainstalować aktualizacje. W związku z tym, istnieje prawdopodobieństwo, że część systemów wykorzystujących rozwiązanie pozostanie niezabezpieczonych. Przede wszystkim w warunkach przemysłowych, rozprzestrzenianie się podatności ICS jest ogromnym zagrożeniem bezpieczeństwa, zapewniając podatny grunt dla cyberataków. Przykładem może być WannaCry, który nadal zbiera żniwa, mimo łat udostępnionych kilka lat temu.

Podatności w sterowniku Siemens

Dzień później, 31 maja dowiedzieliśmy się o kolejnych podatnościach ICS. Tym razem okazało się, że sterowniki PLC LOGO! mają trzy luki, które umożliwiają potencjalnemu atakującemu zmianę konfiguracji urządzenia, dostęp do plików projektu, odszyfrowanie plików i dostęp do haseł. W przeciwieństwie do problemów w APROL może się wydawać, że to niewiele, ale…

LOGO! to inteligentny moduł logiczny, dedykowany do małych projektów automatyzacji w przemyśle (kontrola sprężarek, przenośników taśmowych, kontroli drzwi itp.) i nie tylko. Urządzenia te odnajdują się w domach i budynkach użyteczności publicznej (sterowanie oświetleniem, kontrola dostępu itp.). Wdraża się je na całym świecie i zyskały popularność dzięki łatwej kontroli zdalnej. Niestety, podatności dotyczą wszystkich wersji SIEMENS LOGO!8 BM. Ciekawostką jest to, że według naszych źródeł dwa tygodnie temu Siemens wydał publikację zapewniającą, że nie ma znanych eksploitów, które byłyby ukierunkowane w kierunku wspomnianych luk.

W związku z tymi rewelacjami, pentesterzy z SySS opublikowali materiały zawierające więcej szczegółów o błędach, a także wideo, demonstrujące przeprowadzanie ataku.

Krytyczne zasoby pod lupą

Ponieważ przemysłowe systemy sterowania bywają szeroko wykorzystywane w sektorach energetycznych, mogą mieć wpływ na całą gospodarkę. Dlatego podatności ICS stanowią duże zagrożenie, zwłaszcza w sektorze produkcyjnym. Wnioskując dalej, mogą oddziaływać na bezpieczeństwo całych państw! Mimo to liczba luk wykrytych w przemysłowych systemach sterowania wzrosła o 30% w 2018 r. Z kolei udział krytycznych punktów wzrósł o 17% w porównaniu z rokiem 2017 (dane opracowane przez Positive Technologies). Pod względem nowo odkrytych luk w swoich rozwiązaniach prym wiódł Schneider Electrics (69 podatności). Tuż za nim Siemens (66) a następnie Advantech (37) i Moxa (36). Za najbardziej wrażliwe komponenty uznano przemysłowy sprzęt sieciowy (m.in. switche), systemy HMI/SCADA  i urządzenia PLC/RTU (Programmable Logic Controler / Remote Terminal Unit).

Krytyczne zasoby firm z branży paliwowej są szczególnie narażone na ataki cybernetyczne

Prawdopodobnie coraz częściej będziemy słyszeć o incydentach bezpieczeństwa dotykających krytycznej infrastruktury. Niedawno głośno było o malware Triton czyli złośliwemu oprogramowaniu, które wcześniej uderzyło w giganta naftowego Arabii Saudyjskiej – Petro Rabigh. W tym przypadku hakerzy wykorzystali oprogramowanie do manipulowania procesami przemysłowymi i przypadkowego spowodowania zamknięcia procesu. Ze względu na namacalne ryzyko fizycznego uszkodzenia infrastruktury, Technology Review nazwało to “najbardziej niebezpiecznym atakiem z wykorzystaniem malware w historii”. Z kolei według FireEye rosyjskie laboratorium badawcze związane z rządem jest odpowiedzialne za rozwój Tritonu. Czy echa Tritonu będą rozlegały się równie boleśnie jeszcze długo, podobnie jak WannaCry?

Podatności ICS w kraju nad Wisłą

Jako kraj mamy szczęście. Nie doświadczyliśmy jeszcze poważnych konsekwencji ataków na infrastrukturę krytyczną. Ba, nie mieliśmy nawet poważnego wycieku danych kompromitującego służby państwowe lub wielkie korporacje. W związku z tym, nasz Internet nie huczy na temat problemów producentów rozwiązań ICS. Czyżby w Polsce nie było klientów B & R i SIEMENS? Podobnie informacje o tym, że w Polsce znaleziono ślad oprogramowania BlackEnergy, odpowiedzialnego za „incydent” na Ukrainie przeszły bez echa. Czytamy o tym, że w firmach nie egzekwuje się polityk bezpieczeństwa a oprogramowanie, mające uchodzić za bezpieczne, naszpikowane jest backdoorami. To, że do tej pory Polska nie była na celowniku światowych cyberprzestępców nie oznacza, że tak pozostanie. Polskie oddziały kilku światowych firm już raz oberwały rykoszetem przy okazji ataku ransomware Petya.

Podsumowując, zadajmy sobie pytanie: Co mogło by się stać, gdyby opisane podatności ICS ujawniły się u kluczowych klientów? Jakie konsekwencje powinny zostać wyciągnięte w stosunku do producentów, a jakie działania organizacje powinny podjąć wewnętrznie? Z całą pewnością nie życzymy nikomu aby ucierpiał na skutek opisanych problemów. Dlatego chcemy z Wami budować wzajemną świadomość zagrożeń cyberprzemysłu. Dzięki temu możliwe będzie uchronienie się przynajmniej przed częścią z nich, zwłaszcza jeśli w grę wchodzą zaniedbania na poziomie podstawowych zasad bezpieczeństwa w organizacjach. Tym, których interesuje bardziej biznesowe podejście do tematu zapraszamy do naszego artykułu o przewidywaniach rozwoju dla branży IT & OT.

* Bizantyjski atak generuje błędy w systemach, które wymagają jednomyślności, co skutkuje utratą usług danego systemu. W związku z tym, bizantyjskie awarie są uważane za najbardziej ogólną i najtrudniejszą klasę awarii w ogóle. Algorytmy konsensusu, rozwiązujące ten problem, znajdują zastosowanie między innymi w operacjach z wykorzystaniem kryptowalut.

Spragniony źródeł i głodny wiedzy? Częstuj się:

https://www.techrepublic.com/article/vulnerabilities-discovered-in-industrial-equipment-increased-30-in-2018/

https://www.techrepublic.com/article/vulnerabilities-in-industrial-control-systems-surface-lack-of-basic-security-hygiene/

https://www.helpnetsecurity.com/2019/05/31/siemens-logo-vulnerabilities

https://cert-portal.siemens.com/productcert/pdf/ssa-542701.pdf

https://www.syss.de/fileadmin/dokumente/Publikationen/Advisories/SYSS-2019-013.txt https://www.syss.de/fileadmin/dokumente/Publikationen/Advisories/SYSS-2019-012.txt https://www.syss.de/fileadmin/dokumente/Publikationen/Advisories/SYSS-2019-014.txt

https://www.eenews.net/stories/1060123327

https://www.technologyreview.com/s/613054/cybersecurity-critical-infrastructure-triton-malware/

https://101blockchains.com/consensus-algorithms-blockchain/

PS Podczas gdy nasz artykuł się pisał, zauważyliśmy, że żadne łącze do rodziny APROL na stronie B & R nie działa. Ze względu na zaistniałą sytuację, zastanawiamy się czy to przejściowe problemy czy też element zaplanowanej strategii? https://www.br-automation.com/pl/produkty/systemy-sterowania-procesem/aprol-software/

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *