ransomware
Pod koniec marca, gdy napisaliśmy o ataku ransomware GandCrab na klientów dostawców usług zarządzanych, doszliśmy do wniosku, że raczej nie jest to odizolowany przypadek. Dostawcy usług zarządzanych są zwyczajnie zbyt kuszącym celem dla cyberprzestępców, aby go zignorowali.
Okazuje się, że mieliśmy rację. W kwietniu uwagę naszych ekspertów przykuło ransomware, które zostało nazwane Sodin. Od innych różniło się tym, że wykorzystywało luki nie tylko w systemach zabezpieczających dostawców usług zarządzanych, ale także w platformie Oracle WebLogic. I chociaż ransomware wymaga zwykle udziału użytkownika (na przykład ofiara musi uruchomić plik umieszczony w wiadomości phishingowej), w tym przypadku było inaczej.
Szczegóły techniczne na temat tego ransomware znajdziecie w tym poście w serwisie Securelist. Z naszego punktu widzenia najciekawsze w związku z tym szkodliwym programem są metody jego dystrybucji.
Sposoby dystrybucji Sodin
Na potrzeby rozprzestrzeniania szkodliwego programu poprzez platformę WebLogic atakujący wykorzystali lukę CVE-2019-2725 w celu wykonania polecenia w interpreterze poleceń PowerShell na podatnym serwerze Oracle WebLogic. W ten sposób mogli przesłać na serwer droppera, który z kolei mógł zainstalować ransomware Sodin. Łaty dla tej luki zostały udostępnione w kwietniu, jednak pod koniec czerwca odkryto podobną lukę — CVE-2019-2729.
W atakach wykorzystujących dostawców usług zarządzanych Sodin przedostaje się na urządzenie ofiary na różne sposoby. Ataku tego trojana doświadczyli użytkownicy co najmniej trzech dostawców. Jak wynika z tej historii opisanej w serwisie DarkReading, czasami atakujący dostarczali trojana poprzez konsolę zdalnego dostępu Webroot i Kaseya. W pozostałych przypadkach, opisanych w serwisie Reddit, atakujący przedostali się do infrastruktury dostawców usług zarządzanych poprzez połączenie RDP, zwiększyli uprawnienia, dezaktywowali rozwiązania zabezpieczające i kopie zapasowe, i wreszcie pobrali na komputery klienckie ransomware.
Co powinni zrobić dostawcy usług
W pierwszej kolejności należy potraktować poważnie kwestię przechowywania haseł umożliwiających dostęp zdalny, a także używać autoryzacji dwuetapowej wszędzie tam, gdzie to możliwe. Konsole zdalne — Kaseya oraz Webroot — obsługiwały autoryzację dwuetapową. Co więcej, po incydencie programiści nakazali ich używanie. Jak widać, atakujący, którzy rozprzestrzeniają szkodliwe oprogramowanie Sodin, nie czekają na okazję, lecz aktywnie testują różne sposoby dystrybucji go wśród dostawców usług zarządzanych. Dlatego konieczne jest dokładne przeanalizowanie wszelkich narzędzi wykorzystywanych w tym obszarze. Jak już wspomnieliśmy, dostęp zdalny RDP powinien być wykorzystywany wyłącznie w ostateczności.
Dostawcy usług zarządzanych, zwłaszcza ci, którzy oferują usługi cyberbezpieczeństwa, powinni skupić się na zabezpieczeniu swojej infrastruktury bardziej niż na zabezpieczeniu infrastruktury swoich klientów.
Co powinny zrobić inne firmy
Oczywiście nadal najważniejszą rolę ma aktualizacja oprogramowania. Przedostawanie się szkodliwych programów do infrastruktury poprzez luki, które zostały wykryte i zamknięte wiele miesięcy temu, to wstydliwy przykład dobrowolnie popełnionego błędu.
Firmy wykorzystujące platformę Oracle WebLogic powinny najpierw zapoznać się ze wskazówkami Oracle Security Alert Advisories dla obu luk — CVE-2019-2725 i CVE-2019-2729.
Rozsądnym krokiem jest także używanie niezawodnego rozwiązania bezpieczeństwa zawierającego podsystemy, które potrafią wykryć ransomware i ochronić prze nim stacje robocze.
Porady