O oprogramowaniu zabezpieczającym wiemy bardzo wiele i prawdopodobnie jako jedyni w Polsce weryfikujemy efektywność ochrony, starając się wskazywać najskuteczniejsze rozwiązania w wykrywaniu szkodliwego kodu. Ale nie bylibyśmy obiektywni, gdybyśmy nie przedstawiali drugiej strony medalu. Domniemanie, że antywirusy bardziej szkodzą, niż chronią, jest niekiedy bardzo trafne, a czasami naciągane. Jak jest tym razem?
Obiekty COM i rejestr systemowy Windows
Programy ochronne do wykonywanych operacji na plikach i procesach systemu często wymagają najwyższych uprawnień. Jest to logiczne, ale antywirusy to także „oprogramowanie”, które może zawierać mniej lub więcej poważnych luk bądź niepoprawnie wdrożonych zabezpieczeń przed wstrzykiwaniem obcego kodu.
Uprzywilejowane operacje, które wykonywane są w systemie, mają swoją implementację w sterownikach jądra systemu (ring-0) i w usługach działających w trybie użytkownika (ring-3) oraz mogą się ze sobą komunikować. Z tego też powodu (w niektórych przypadkach) proces antywirusa odpowiadający za graficzny interfejs pozwala uruchamiać operacje, które wymagają najwyższych uprawnień do:
- konfigurowania oprogramowania ochronnego;
- wydawania polecenia skanowania, kasowania plików, przywracania z kwarantanny;
- eksportowania i importowania konfiguracji;
- blokowania procesów;przepuszczania i blokowanie ruchu internetowego;
- skanowania szyfrowanej komunikacji;
- wyłączania ochrony na stałe lub czasowo;
- i wielu innych;
Niektórzy producenci operacje pomiędzy antywirusem a systemem realizują za pośrednictwem obiektów COM, a te z kolei mogą być użyte do wykonania kodu binarnego, na przykład dezaktywującego ochronę w czasie rzeczywistym i to pomimo włączonej funkcji auto-ochrony. Technika ataku „COM hijacking” może być stosowana przez złośliwe oprogramowanie do uruchamiania aplikacji bez używania okienek i bez wymogu przyznania uprawnień administratora (omijanie UAC). Korzystając z obiektów COM, możliwe jest ukrycie plików i kluczy rejestru przed innymi procesami w trybie użytkownika — o wstrzykiwaniu kodu do uruchomionych już procesów nie wspominając.
Generalnie celem technologii COM jest dostarczenie interfejsu umożliwiającego programistom sterowanie i manipulowanie obiektami innych aplikacji, w tym uruchamianie pewnych funkcji w systemie operacyjnym za pomocą zdefiniowanych przez Microsoft unikalnych identyfikatorów CLSID. Dla przykładu identyfikator {21EC2020-3AEA-1069-A2DD-08002B30309D} otworzy okno z panelem sterowania. Z kolei inny identyfikator może uruchomić skrypt, plik binarny, wyłączyć Windows Update, dodać regułę do firewallu, sterownik, usługę, itp. Każdy taki identyfikator jest zapisany w rejestrze systemowym.
Zadaniem badaczy było udowodnić, że odkryta technika ominięcia auto-ochrony z wykorzystaniem przechwytywania obiektów COM i uruchamiania złośliwego kodu jest możliwa do przeprowadzenia w warunkach produkcyjnych.
Tę technikę ataku pokazał James Forshaw w swoim odkryciu, gdzie obiekty COM mogą być wykorzystane też do podwyższenia uprawnień w hiperwizorze Oracle VirtualBox. Krótko mówiąc, technika „COM hijacking” pozwala uruchamiać własne pliki binarne, zupełnie niespokrewnione z programem źródłowym. James udowodnił, że w przypadku podatności CVE-2017-3563 dla VirtualBox’a można pominąć sygnaturę PE załadowanego pliku DLL poprzez wczytanie podpisanej przez Microsoft biblioteki scrobj.dll, która pozwoli uruchomić kod JScript lub .NET. Atakujący będzie mógł manipulować pamięcią przechwyconego procesu i korzystać dowoli z API systemu. A to jest już bardzo niebezpieczne.
Testy przeprowadzono na produktach:
- Kaspersky Lab
- Kaspersky Free (18.0.0.405)
- Kaspersky Antivirus (17.0.0.611)
- Kaspersky Endpoint Security (10.3.0.6294)
- Symantec
- Symantec Norton Security Deluxe (22.10.1.10)
- Symantec Endpoint Protection (14.0.3752.1000.105)
- Bitdefender
- Bitdefender Antivirus Plus 2018 (22.0.8.992)
- Bitdefender Gravityzone (Endpoint Security Tools 6.2.25.953)
- Comodo
- Comodo Internet Security Premium (10.0.1.6258)
- Trend Micro
- Trend Micro Maximum Security (22.10.1.10)
Testy wykazały, że taka sama podatność CVE-2017-3563 może zostać użyta do uruchomienia kodu JScript lub .NET przez proces oprogramowania antywirusowego z włączoną funkcją auto-ochrony. W niektórych przypadkach możliwe jest nawet uruchomienie takiego kodu i podniesienie uprawnienia do najwyższego, czyli „NT AUTHORITYSYSTEM”.
Najwięcej „powodów do zadowolenia ma silnik antywirusowy” firmy Kaspersky Lab, który jako jedyny wykrył wstrzyknięty skrypt. Jednak nie ma się z czego cieszyć, ponieważ ominięcie ochrony było na tyle proste, że wystarczyło wczytać złośliwy plik za pomocą obiektów COM z rejestru zawierającego klucz do adresu URL, a nie ścieżkę do pliku.
Z przeprowadzonego eksperymentu wynika, że możliwe jest ingerowanie w procesy antywirusów, dezaktywowanie ochrony pomimo zabezpieczenia konfiguracji hasłem, ukrywanie szkodliwego oprogramowania, czy manipulowanie plikami na dysku z uprawnieniami systemowymi. Podejrzewa się nawet, że możliwe jest rozszyfrowywanie komunikacji SSL/TLS.
Przywracanie plików z kwarantanny
Jak powszechnie wiadomo, kwarantanna to obszar odizolowany od folderów użytkownika, często też szyfrowany. Wymaga najwyższych uprawnień do zapisu bądź odczytu (chociaż nie zawsze). Kwarantanna jest także pewnym zabezpieczeniem przed fałszywymi alarmami — pliki potraktowane jako złośliwe da się przywrócić. Wiadomo też, że dane w kwarantannie muszą być w jakiś sposób zabezpieczone przed niepowołanym dostępem — na przykład przed innymi procesami lub przed kradzieżą klucza szyfrującego pliki — dlatego też uruchomiony proces antywirusa odpowiedzialny za przywracania danych z kwarantanny (niestety) nie zawsze jest wykonywany z uprawnieniami lokalnego użytkownika, a niekiedy z uprawnieniami „SYSTEM”. Jest to błędne założenie deweloperów, ponieważ jak udowodniono w teście, proces lokalnego użytkownika odwołujący się do procesu z uprawnieniami „SYSTEM” przekazuje informację z żądaniem, która powinna zwrócić odpowiedź i przywrócić plik z uprawnieniami procesu lokalnego użytkownika. Może zabrzmieć to trochę skomplikowanie, ale w przypadku testowanych produktów, funkcja sprawdzająca uprawnienia nie została zaprogramowana z należytą starannością, dlatego przywracany plik z kwarantanny jest tworzony w docelowej lokalizacji z uprawnieniami „NT AUTHORITYSYSTEM” zamiast z uprawnieniami lokalnego użytkownika. W konsekwencji:
Autor malware może napisać takiego szkodnika, który wyświetli okienko z informacją o uruchomienie programu z podwyższonymi uprawnieniami (UAC), podszywając się pod proces antywirusa.
No dobra, ale jak to wykorzystać w praktyce? Tradycyjnie. Atakujący musi jakimś sposobem przetransportować złośliwy kod do systemu: wykorzystać lukę w systemie, zastosować atak drive-by download, przesłać wirusa przez lukę w protokole SMB lub zdać się na socjotechnikę — pamiętając jednocześnie, aby wirus był całkowicie niewykrywalny dla antywirusa. Trudne? Niekoniecznie.
Przekazywanie uprawnień pomiędzy procesami dotyczy nie tylko kwarantanny, ale także usuwania plików za pośrednictwem specjalnego modułu, zwanego często „niszczarką plików” (file shredding), importowania ustawień, czy chociażby eksportowanie logów do pliku. Wszystkie te operacje są wykonywane „ręcznie” przez użytkownika lub automatycznie w wyniku zaplanowanych operacji w konsoli administratora. Funkcje niezwiązane z bezpośrednim dostępem do plików (takie jak ustawienia sieciowe, skanowanie SSL/TLS) to obszary, które nie zostały przetestowane, ale raport wskazuje, że mogą dawać inne wektory do skutecznych ataków i pole do popisu autorom złośliwego oprogramowania.
Pozostałe szczegóły techniczne są dostępne w raporcie PDF.
Jaka jest skala problemu?
Produkty, które zostały poddane testowi penetracyjnemu, należą do firm najbardziej renomowanych, uzyskujących najlepsze wyniki w niezależnych testach ochrony. Dlatego zdecydowano się sprawdzić akurat te rozwiązania, aby zwrócić uwagę opinii publicznej no i samych producentów, którym zdarzają się wpadki od czasu do czasu. Nie jest to jednak tak apokaliptyczna sytuacja, aby już teraz przeskakiwać do panelu sterowania i usuwać oprogramowanie, które mimo wszystko stoi na straży bezpieczeństwa, wyłapując przynajmniej te znane i bardziej zaawansowane zagrożenia.
Wykorzystywanie procesów antywirusa do uruchomienia złośliwego kodu z pewnością dotyczy innych rozwiązań pozostałych firm, ale nie wszystkich. Możemy więc założyć, że oprogramowanie, które korzysta z technologii firm Bitdefender, Kaspersky Lab, Trend Micro i Symantec (nie są nam znane „desktopowe” produkty korzystające z technologii firmy Comodo) mogą w mniejszym lub większym stopniu być tak samo podatne na opisane błędy w zabezpieczeniach. Trudno to zweryfikować jednoznacznie bowiem to, w jaki sposób mniejsze firmy wykorzystają gotowe technologie w swoich produktach (często skopiowane prawie 1:1), uwarunkowane jest różnymi zmiennymi. Na poprawkę korygującą należy wziąć jeszcze od kilku do kilkudziesięciu rodzajów zestawów SDK, które oferuje np. firma Bitdefender. Bez testów nie sposób przewidzieć, który antywirus spoza powyższej listy jest podatny, a który nie jest.
Co w takiej sytuacji zrobić?
Najlepiej ograniczyć się do uruchamia aplikacji tylko z określonych lokalizacji lub programów dodanych do białych list. Nie bez znaczenia są podpisy cyfrowe plików binarnych. Te nieautoryzowane przez urząd certyfikacji powinny być uznane za niebezpieczne i tak traktowane w hermetycznych środowiskach. W przypadku oprogramowania Bitdefender GravityZone i Kaspersky Endpoint Security manipulowanie procesami antywirusa z wykorzystaniem kwarantanny nie było możliwe na domyślnej polityce bezpieczeństwa. Nie dotyczyło to wszystkich sprawdzonych produktów (co wcale nie znaczy, że producentom należy się jakaś pochwała). Warto takie ograniczenie wprowadzić dla pracowników. Ze względów bezpieczeństwa dostęp do ustawień antywirusa powinien mieć tylko administrator lub osoba do tego upoważniona.
Badanie porusza jeszcze jeden problem. Otóż producenci mogą celowo faworyzować klienta biznesowego. Za sektorem małych i średnich przedsiębiorstw oraz dużych firm i korporacji przemawiają duże pieniądze. Nie bylibyśmy zaskoczeni, gdyby producenci dla maszyn firmowych dostarczali lepszy poziom ochrony przed złośliwym oprogramowaniem i lepiej dopracowany kod.
Użytkownikom pozostaje postępować z każdym nieznanym plikiem jako z potencjalnym zagrożeniem. Wykorzystać opisywany atak nie będzie łatwo w praktyce, dlatego nie warto pozbawiać się tej podstawowej ochrony. Miejmy nadzieję, że to badanie dotrze do osób decyzyjnych i problem z uruchamianiem złośliwego kodu przez procesy programu ochronnego zostanie szybko naprawiony.
Przy okazji może warto zainteresować się czymś innym niż tradycyjnym „antywirusem”?
