Alisa Shevchenko
Starszy analityk wirusów, Kaspersky Lab

Artykuł ten jest próbą przyjrzenia się, w jaki sposób szkodliwe programy rozwinęły techniki autoochrony. Opisuje ich ewolucję, w miarę jak przetrwanie wirusów stawało się coraz trudniejsze, oraz zawiera analizę obecnej sytuacji.

Na początku należy zdefiniować znaczenie terminu "autoochrona szkodliwego oprogramowania", który nie jest tak jednoznaczny, jak mogłoby się wydawać na pierwszy rzut oka. Gdy szkodliwe oprogramowanie atakuje programy antywirusowe, bez wątpienia mamy do czynienia z formą autoochrony. Jeśli zaciera swoje ślady, jest to również pewien rodzaj autoochrony, chociaż nie jest to już tak oczywiste. Jeszcze mniej oczywistą formą autoochrony jest ewolucja szkodliwych programów. Jednak jednym z czynników motywujących twórców wirusów poszukujących nowych platform, które mogą zostać zainfekowane, oraz nowych luk w systemie, jest rozprzestrzenianie nowych wirusów na wolności na obszary, gdzie do tej pory nikt nie zadał sobie trudu, aby szukać szkodliwego kodu, ponieważ jeszcze nigdy go tam nie znaleziono.

Aby uniknąć nieporozumienia odnośnie tego, co jest technologią autoochrony a co nią nie jest, w artykule tym zbadano tylko najpopularniejsze i najbardziej oczywiste metody autoochrony szkodliwego oprogramowania. Obejmują one przede wszystkim różne sposoby modyfikowania i kompresowania kodu w celu ukrycia obecności szkodliwego kodu w systemie oraz przerywania działania rozwiązań antywirusowych.

• Klasyfikacja autoochrony szkodliwego oprogramowania
• ŹródÅ‚a: polimorfizm, zaciemnianie oraz szyfrowanie
• Wirusy ukrywajÄ…ce siÄ™
• Kompresory
• Rootkity
• Zwalczanie rozwiÄ…zaÅ„ antywirusowych
• Co przyniesie przyszÅ‚ość
• Trendy i prognozy
• Wnioski

Klasyfikacja autoochrony szkodliwego oprogramowania

Istnieje wiele różnych rodzajów technik autoochrony szkodliwego oprogramowania, które można sklasyfikować na wiele różnych sposobów. Celem niektórych z tych technologii jest obejście baz danych sygnatur wirusów, podczas gdy inne mają utrudnić analizę szkodliwego kodu. Niektóre szkodliwe programy mogą próbować ukryć się w systemie, podczas gdy inne nie chcą marnować na to cennych zasobów procesora i zamiast tego wolą wyszukiwać i zwalczać określone typy ochrony antywirusowej. Te różne taktyki można klasyfikować na wiele sposobów i zaszeregować do różnych kategorii.

Ponieważ celem tego artykułu nie jest stworzenie ścisłego systemu klasyfikacji technik autoochrony szkodliwego oprogramowania, rozważmy system klasyfikacji, który umożliwi zrozumienie tego zagadnienia na poziomie intuicyjnym. Uwzględniliśmy dwa najważniejsze naszym zdaniem kryteria, które posłużą nam do sporządzenia wykresu punktowego, gdzie dwie osie reprezentują te kryteria.

Pierwszym kryterium jest poziom aktywności autoochrony szkodliwego programu. Najbardziej pasywny szkodliwy program w ogóle nie próbuje się bronić, tj. nie zawiera żadnego takiego kodu. Zamiast tego, autor takiego programu tworzy dla niego rodzaj tarczy. Aktywniejsze systemy autoochrony celowo stosują agresywne techniki.

Drugim kryterium jest stopień wyspecjalizowania mechanizmu autoochrony szkodliwego programu. Formy autoochrony o najwęższej specjalizacji stosowane są przez szkodliwe programy, które w określony sposób zakłócają funkcjonowanie danego programu antywirusowego. Bardziej ogólne mechanizmy autoochrony chronią szkodliwe programy przed wszystkim poprzez utrudnianie wykrycia obecności wirusa w systemie na wszelkie możliwe sposoby.

Na wykresie punktowym zostały przedstawione różne rodzaje mechanizmów autoochrony szkodliwych programów. Wykres ten stanowi jedynie prosty przykład, który można wykorzystać do kategoryzowania różnych sposobów autoochrony szkodliwego oprogramowania. Model ten opiera się na dokładnej analizie zachowań szkodliwego oprogramowania, z konieczności jest jednak subiektywny.

Rys. 1. Wykres punktowy technologii autoochrony szkodliwego oprogramowania.

Mechanizmy autoochrony szkodliwych programów mogą spełniać jedno lub więcej zadań. Obejmują one:

1. utrudnianie wykrywania wirusa przy użyciu metod opartych na sygnaturach;
2. utrudnianie analitykom wirusów analizowania kodu;
3. utrudnianie wykrywania szkodliwego programu w systemie;
4. utrudnianie działania oprogramowania bezpieczeństwa, takiego jak program antywirusowy czy zapora sieciowa.

Ze względu na nieczęste występowanie i stosunkowo niewielką liczbę szkodliwych programów dla innych platform, w artykule tym będą analizowane tylko szkodliwe programy stworzone dla systemu operacyjnego Windows (oraz jego poprzednika DOS). Wszystkie zbadane w tym artykule trendy odnoszą się do plików wykonywalnych szkodliwego oprogramowania (EXE, DLL oraz SYS) oraz w pewnym stopniu również do makrowirusów i wirusów skryptowych, dlatego też ta ostatnia kategoria nie będzie rozpatrywana oddzielnie.

Źródła: polimorfizm, zaciemnianie oraz szyfrowanie

Ponieważ polimorfizm, zaciemnianie oraz szyfrowanie spełniają tę samą funkcję, chociaż w różnym stopniu, najlepiej rozpatrywać je wszystkie razem. Początkowo, modyfikowanie szkodliwego kodu służyło dwóm celom: utrudnianiu wykrycia plików oraz utrudnianiu analitykom wirusów badania kodu.

Mimo że początki szkodliwego oprogramowania sięgają lat 70. ubiegłego stulecia, programy te zaczęły stosować autoochronę dopiero pod koniec lat 80. Pierwszym wirusem, który próbował bronić się przed narzędziami antywirusowymi, był wirus dla systemu DOS - Virus.DOS.Cascade. Szkodnik ten bronił się poprzez częściowe szyfrowanie swojego kodu. Metoda ta nie była jednak całkiem skuteczna, ponieważ każda nowa kopia tego wirusa - mimo że różniła się od poprzednich - nadal zawierała niezmieniony fragment kodu, który za każdym razem zdradzał wirusa. W rezultacie, wirus ten nadal był wykrywany przez programy antywirusowe. Mimo to, twórcy wirusów zaczęli iść w nowym kierunku i dwa lata później pojawił się pierwszy wirus polimorficzny - Chameleon (Virus.DOS.Chameleon). Chameleon, znany również jako 1260, oraz Whale, który pojawił się w tym samym czasie, w celu ochrony swojego kodu wykorzystywały złożone metody szyfrowania i zaciemniania. Dwa lata później wyłoniły się tzw. generatory polimorficzne, które można było wykorzystać jako nowy mechanizm obrony szkodliwych programów.

Wyjaśnienia wymagają dwie kwestie: dlaczego modyfikowanie kodu może zostać wykorzystane w celu utrudnienia wykrywania plików oraz w jaki sposób działa wykrywanie plików.

Do niedawna działanie programów antywirusowych polegało wyłącznie na analizowaniu kodu plików. Najwcześniejsze metody wykrywania, oparte na sygnaturach, koncentrowały się na szukaniu dokładnych sekwencji bajtów, często w określonej pozycji od początku pliku, w kodzie binarnym szkodliwego programu. Późniejsze heurystyczne metody wykrywania również wykorzystywały kod pliku, stosowały jednak bardziej elastyczne, oparte na prawdopodobieństwie podejście do szukania wspólnych sekwencji bajtów szkodliwego oprogramowania. Naturalnie, szkodliwe programy łatwo mogą obejść ten rodzaj ochrony, jeżeli każda kopia programu będzie zawierała nową sekwencję bajtów.

W tym celu można zastosować techniki polimorficzne oraz metamorficzne, które zasadniczo - bez zagłębiania się w szczegóły technologiczne - umożliwiają szkodliwemu programowi mutację na poziomie bajta podczas tworzenia swojej kopii. Jednocześnie funkcjonalność programu pozostaje niezmieniona. Szyfrowanie i Zaciemnianie wykorzystywane są przede wszystkim w celu utrudnienia analizy kodu, jeśli jednak zostaną zaimplementowane w określony sposób, rezultatem może być odmiana polimorfizmu, czego przykładem jest wirus Cascade, którego każda kopia została zaszyfrowana przy pomocy unikatowego klucza. Zaciemnianie może tylko utrudnić analizę, gdy jednak zostanie zastosowane do każdej kopii szkodliwego programu w inny sposób, utrudnia skuteczne wykorzystanie metod wykrywania opartych na sygnaturach. Nie można jednak powiedzieć, że którakolwiek z wyżej wymienionych taktyk jest skuteczniejsza niż jakakolwiek inna, jeśli chodzi o autoochronę szkodliwego oprogramowania. Należałoby raczej powiedzieć, że skuteczność tych technik zależy od konkretnych warunków oraz sposobu ich zaimplementowania.

Wykorzystanie polimorfizmu jest stosunkowo rozpowszechnione jedynie w odniesieniu do wirusów plikowych dla systemu DOS. Nie bez przyczyny. Tworzenie kodu polimorficznego to bardzo czasochłonne zadanie, które jest uzasadnione jedynie w przypadkach, gdy szkodliwy program rozmnaża się samodzielnie: każda nowa kopia zawiera bardziej lub mniej unikatową sekwencję bajtów. Większość współczesnych trojanów nie jest zdolnych do samodzielnego rozmnażania się, stąd polimorfizm nie ma tu zastosowania. Z tego powodu od zmierzchu ery wirusów plikowych dla systemu DOS polimorfizm stosowany jest rzadziej. Metoda ta wykorzystywana była gównie przez twórców wirusów, którzy chcieli popisać się swoimi umiejętnościami, a nie stworzyć jakąś szczególnie użyteczną funkcję.

Rys. 2. Kod polimorficzny robaka P2P-Worm.Win32.Polip

W przeciwieństwie do polimorfizmu, zaciemnianie wykorzystuje się nadal, podobnie jak inne metody modyfikowania kodu, które w dużym stopniu utrudniają analizę kodu.

Rys. 3. Zaciemniony kod w trojanie Trojan-Dropper.Win32.Small.ue

Od czasu, gdy pojawiły się metody wykrywania oparte analizie zachowania i zaczęły wypierać metody oparte na sygnaturach, techniki modyfikacji kodu stały się mniej użyteczne jeśli chodzi o utrudnianie wykrywania szkodliwego oprogramowania. To wyjaśnia, dlaczego polimorfizm oraz podobne technologie nie są obecnie powszechnie stosowane i tak naprawdę są sposobem na utrudnienie analizy szkodliwego kodu.

Wirusy ukrywajÄ…ce siÄ™

Ukrywanie szkodliwych programów w systemie stało się drugą metodą autoochrony przed wykryciem, jaką opanowali twórcy wirusów w erze systemu DOS. Technika ta po raz pierwszy została wykorzystana w 1990 r., a konkretnie stanowiła część arsenału wirusa, o którym już wspominaliśmy - Whale. Ukryty wirus w ten czy inny sposób przechwytywał usługi systemowe DOS i przekazywał fałszywe dane użytkownikowi lub programowi antywirusowemu - na przykład "wyczyść" zawartość sektora startowego zamiast prawdziwej zawartości, która została zainfekowana przez szkodliwy program.

Technologie ukrywania się stworzone dla systemu operacyjnego DOS odrodziły się 10 lat później jako technologie rootkit dla systemu operacyjnego Windows.

Mechanizmy wykorzystywane w celu ukrywania wirusów w systemie zostały szczegółowo omówione w sekcji o rootkitach.

Kompresory

Stopniowo wirusy - szkodliwe programy, które potrafią funkcjonować jedynie w ciele ofiary i nie są zdolne do istnienia jako oddzielne pliki - zastępowane są przez trojany, które stanowią całkowicie niezależne szkodliwe programy. Proces ten rozpoczął się w czasie, gdy Internet był jeszcze wolny i bardziej ograniczony niż obecnie. Dyski twarde i dyskietki były niewielkie, co oznaczało, że rozmiar programu miał istotne znaczenie. W celu zmniejszenia rozmiaru trojana twórcy wirusów zaczęli wykorzystywać tak zwane kompresory - nawet w erze systemu DOS. Kompresory to wyspecjalizowane programy, które kompresują i archiwizują pliki.

Efektem ubocznym stosowania kompresorów jest to, że skompresowane szkodliwe programy są trudniejsze do wykrycia przy użyciu metod plikowych.

Podczas tworzenia nowej modyfikacji istniejącego szkodliwego programu twórca wirusów najczęściej zmienia kilka linijek kodu, pozostawiając trzon programu nietknięty. W skompilowanym pliku bajty określonej sekwencji kodu zostaną również zmienione, a jeśli sygnatura wirusa oprogramowania antywirusowego nie będzie zawierała tej konkretnej sekwencji, szkodliwy program nadal będzie wykrywany tak jak poprzednio. Problem ten można rozwiązać poprzez spakowanie programu za pomocą kompresora, ponieważ zmiana nawet jednego bajta w źródłowym pliku wykonywalnym generuje zupełnie nową sekwencję bajtów w spakowanym pliku.

Rys. 4. Widoczna różnica pomiędzy kodem spakowanym i niespakowanym

Kompresory nadal są powszechnie wykorzystywane. Różnorodność programów kompresujących i poziom ich zaawansowania zwiększa się. Wiele współczesnych kompresorów, oprócz kompresowania pliku źródłowego, wyposaża go również w dodatkowe funkcje autoochrony, których celem jest utrudnienie rozpakowania i analizy pliku przy użyciu debuggera.

Rootkity

W celu ukrycia swojej obecności w systemie w pierwszych latach nowego tysiąclecia szkodliwe programy dla systemu operacyjnego Windows zaczęły stosować technologie ukrywania się. Jak już wspomniano wcześniej, nastąpiło to około 10 lat po wyłonieniu się koncepcji programów ukrywających się i zaimplementowaniu jej dla systemu DOS. Na początku 2004 roku firma Kaspersky Lab natrafiła na zaskakujący program, którego nie można było zobaczyć w procesach Windows oraz na liście plików. Dla wielu ekspertów zajmujących się wirusami był to początek czegoś nowego - poznania technologii ukrywania się szkodliwych programów dla systemu Windows - oraz zapowiedź nowego trendu w przemyśle tworzenia wirusów.

Termin "rootkit" wywodzi się od narzędzi uniksowych przeznaczonych do zapewnienia użytkownikowi niesankcjonowanych uprawnień administratora w systemie, tak aby nie został zauważony przez administratora systemu. Obecnie termin rootkit obejmuje wyspecjalizowane narzędzia wykorzystywane w celu ukrywania informacji w systemie, jak również szkodliwe programy o funkcjonalności umożliwiającej im maskowanie swojej obecności. Można tu zaliczyć oznaki zarejestrowanych aplikacji od tzw. osób trzecich: ciąg tekstowy na liście procesów, plik na dysku, klucz rejestru czy nawet ruch sieciowy.

W jaki sposób technologie rootkit, które mają na celu ukrycie szkodliwych programów w systemie, tak bardzo utrudniają wykrywanie szkodliwych programów przy użyciu programu antywirusowego lub innego oprogramowania bezpieczeństwa? Odpowiedź jest bardzo prosta: narzędzie antywirusowe to zewnętrzny agent, podobnie jak użytkownik. Zazwyczaj, jeśli użytkownik nie widzi czegoś, program antywirusowy również tego nie zobaczy. Jednak niektóre rozwiązania antywirusowe implementują technologie, dzięki którym "widzą więcej", przez co wykrywają wirusy, których użytkownicy nie mogą zobaczyć.

Rootkit opiera się na tej samej zasadzie co wirusy ukrywające się dla systemu DOS. Spora liczba rootkitów posiada mechanizmy, które modyfikują łańcuch odwołań systemowych (Execution Path Modification). Ten rodzaj rootkita może działać jak funkcja przechwytywania zlokalizowana w określonym punkcie drogi, na której następuje wymiana poleceń lub informacji. Tego typu rootkit modyfikuje polecenia i informacje w celu zniekształcenia ich lub kontrolowania tego, co ma miejsce po stronie odbiorcy bez jego wiedzy. Teoretycznie liczba punktów, w których może być zlokalizowana funkcja przechwytywania, jest nieograniczona. W praktyce, istnieje obecnie kilka różnych metod powszechnie stosowanych w celu przechwytywania funkcji API oraz funkcji systemowych jądra. Przykładem tego rodzaju rootkita są powszechnie znane narzędzia Vanquish oraz Hacker Defender, jak również szkodliwe programy takie jak Backdoor.Win32.Haxdoor, Email-Worm.Win32.Mailbot i niektóre wersje robaka Email-Worm.Win32.Bagle.

Rys. 5.Przechwycenie ZwQueryDirectoryFile powoduje ukrycie pliku sterownika na liście plików.

Innym powszechnym typem technologii rootkit jest Direct Kernel Object Modification (DKOM), który może być traktowany jako "insider" modyfikujący informacje i polecenia bezpośrednio w ich źródłach. Rootkity te zmieniają dane systemowe. Typowym przykładem jest narzędzie FU; te same funkcje można znaleźć w Gromozonie (Trojan.Win32.Gromp).

Nowsza technologia, która oficjalnie mieści się w klasyfikacji rootkitów, ukrywa pliki w alternatywnych strumieniach danych (ADS) w systemach plików NTFS. Technologia ta po raz pierwszy została zaimplementowana w 2000 r. w szkodliwym programie Stream (Virus.Win32.Stream), po raz drugi natomiast w 2006 r. w postaci Mailbot oraz Gromozon. Mówiąc ściśle, wykorzystanie ADS to nie tyle sposób na "przechytrzenie" systemu, co wykorzystanie mało znanych funkcji, przez co technologia ta nie ma szans na szerokie rozpowszechnienie.

Rys. 6. Szkodliwy program Mailbot (Rustock) wykorzystuje strumień foldera systemowego.

Można wyróżnić jeszcze inną rzadką technologię, która tylko częściowo kwalifikuje się do kategorii rootkitów (jednak w jeszcze mniejszym stopniu odpowiada ona innym rodzajom autoochrony szkodliwego oprogramowania omówionym w tym artykule). Tego typu szkodliwe programy nie posiadają ciała na dysku. Obecnie znamy dwóch przedstawicieli tej podgrupy: Codered, który pojawił się w 2001 r. (Net-Worm.Win32.CodeRed) i występuje w tej formie tylko w kontekście MS IIS, oraz wykryty niedawno Trojan typu "proof of concept", który przechowuje swoje ciało w rejestrze.

Obecnie technologie rootkit zmierzają w kierunku wirtualizacji i wykorzystywania funkcji systemowych - innymi słowy, przenikają jeszcze głębiej do systemu.

Zwalczanie rozwiązań antywirusowych

Szkodliwe programy stosujące aktywną obronę istniały od zawsze. Mechanizmy autoochrony obejmują:

• Przeszukiwanie systemu w celu znalezienia produktu antywirusowego, zapory sieciowej lub innego narzÄ™dzia bezpieczeÅ„stwa, a nastÄ™pnie przerwanie dziaÅ‚ania tego narzÄ™dzia. PrzykÅ‚adem może być szkodliwy program, który szuka okreÅ›lonego produktu antywirusowego na liÅ›cie procesów, a nastÄ™pnie próbuje przerwać dziaÅ‚anie tego programu.
• Blokowanie plików i otwieranie ich z wyÅ‚Ä…cznym dostÄ™pem jako ochrona przed skanowaniem plików przeprowadzanym przez oprogramowanie antywirusowe.
• Modyfikowanie pliku hosts w celu zablokowania dostÄ™pu do stron z uaktualnieniami antywirusowymi.
• Wykrywanie zapytaÅ„ wysyÅ‚anych przez system bezpieczeÅ„stwa (na przykÅ‚ad okno zapory sieciowej wyÅ›wietlajÄ…ce zapytanie "Czy zezwolić na to poÅ‚Ä…czenie?") oraz imitowanie klikania klawisza "Zezwól".

W rzeczywistości, sprecyzowany atak na rozwiązanie bezpieczeństwa bardziej przypomina reakcję kogoś, kto został przyparty do muru, niż aktywny atak. Teraz, gdy firmy antywirusowe analizują nie tylko kod zawarty w szkodliwych programach, ale również ich zachowanie, szkodliwe programy są mniej lub bardziej bezsilne. Ani polimorfizm, ani kompresory, ani nawet technologie ukrywania się nie zapewnią szkodliwym programom całkowitej ochrony. Z tego powodu szkodliwe programy koncentrują się na pewnych przejawach lub funkcjach tzw. wroga. Naturalnie, czasami mechanizmy autoochrony stanowią jedyne rozwiązanie; w przeciwnym razie nie byłyby tak rozpowszechnione, ponieważ posiadają zbyt wiele wad z punktu widzenia maksymalnej, wszechstronnej obrony.

Co przyniesie przyszłość?

Ochrona antywirusowa nieustannie ewoluuje: od analizy plików po analizę zachowania programów. W przeciwieństwie do analizy plików, której podstawy zostały wyjaśnione w sekcji dotyczącej polimorfizmu i zaciemniania, analiza zachowań nie opiera się na pracy z plikami, ale ze zdarzeniami występującymi na poziomie systemu, jak "wyszczególnij wszystkie aktywne procesy w systemie", "utwórz plik o tej nazwie w pokazanym folderze" oraz "otwórz port wskazany przez dane przychodzące". Poprzez analizowanie łańcucha tych zdarzeń program antywirusowy może oszacować stopień, w jakim komponent generujący te procesy jest potencjalnie szkodliwy, i w razie konieczności wyświetlić ostrzeżenie.

Analiza zachowań może być jednak myląca, jeśli chodzi o terminologię. Na przykład mechanizm analizy behawioralnej może występować pod różnymi nazwami: HIPS, ochrona proaktywna, heurystyczna lub sandbox. Jednak niezależnie od nazwy, jedna rzecz jest jasna: szkodliwe programy okazują się bezsilne wobec analizy zachowań. Będzie to najprawdopodobniej miało wpływ na przyszłą ewolucję szkodliwych programów.

Innymi słowy, twórcy wirusów muszą znaleźć jakiś sposób na obejście analizy zachowań. Nie wiadomo, w jaki sposób będą próbowali pokonać tę przeszkodę. Pewne jest to, że wykorzystywanie zaciemniania na poziomie zachowań jest zasadniczo nieskuteczne. Ewolucja diagnostyki środowiskowej jest jednak bardzo interesująca, ponieważ częściowo zakłada ona wzrost "samoświadomości" wirusa, co umożliwiłoby mu określenie, gdzie dokładnie jest zlokalizowany: w "rzeczywistym świecie" (w czystym środowisku roboczym użytkownika) czy też w "matriksie" (pod kontrolą oprogramowania antywirusowego).

Technologie diagnostyczne mają swoje precedensy: niektóre szkodliwe programy, jeśli zostaną uruchomione w środowisku wirtualnym (takim jak VMWare lub Virtual PC), natychmiast unicestwiają siebie. Poprzez wbudowanie takiego mechanizmu autodestrukcji do szkodliwego oprogramowania jego autor uniemożliwia analizę szkodnika, która często przeprowadzana jest w środowisku wirtualnym.

Trendy i prognozy

Po zbadaniu obecnych trendów oraz skuteczności stosowanych podejść można sformułować następujące wnioski odnośnie omówionych wyżej metod autoochrony szkodliwego oprogramowania:

1. Rootkity wykazują tendencję w kierunku wykorzystywania funkcji sprzętowych oraz w kierunku wirtualizacji. Jednak metoda ta nie osiągnęła jeszcze punktu szczytowego i w nadchodzących latach prawdopodobnie nie stanie się głównym zagrożeniem ani nie będzie powszechnie wykorzystywana.
2. Technologia blokująca pliki na dysku: znane są dwa programy typu " proof of concept", które udowodniły, że można spodziewać się rozwoju na tym obszarze w niedalekiej przyszłości.
3. Wykorzystanie technologii zaciemniania nie odgrywa istotnej roli, nadal jest jednak stosowane.
4. Wykorzystanie technologii, które wykrywają narzędzia bezpieczeństwa oraz zakłócają ich działanie, jest bardzo popularne i szeroko stosowane.
5. Wykorzystanie kompresorów jest rozpowszechnione i ciągle wzrasta (zarówno pod względem ilościowym, jak i jakościowym).
6. Przewidywany jest rozwój wykorzystywania technologii wykrywających debuggery, emulatorów oraz wirtualnych maszyn, jak również technologii diagnozy środowiska w celu zrekompensowania masowego przejścia produktów antywirusowych na wykorzystywanie analizy zachowań.

   
   Rys. 7. Przybliżony rozkład technologii autoochrony szkodliwego oprogramowania od początku 2007 r.

   Nie trudno zauważyć, że kierunki ewolucji technologii autoochrony szkodliwego oprogramowania zmieniają się zgodnie z ewolucją szkodliwych programów oraz ochrony przed nimi. Gdy większość szkodliwych programów infekowało pliki, a programy antywirusowe stosowały wykrywanie oparte na sygnaturach, dominującymi formami autoochrony szkodliwego oprogramowania był polimorfizm oraz ochrona kodu. Obecnie szkodliwe programy są w większości niezależne, a programy antywirusowe stają się coraz bardziej proaktywne. Na podstawie tych faktów można przewidywać, które mechanizmy autoochrony szkodliwych programów będą rozwijały się intensywniej niż inne:

   1. Rootkity. Dzięki temu, że są niewidoczne w systemie, mają oczywistą przewagę - nawet jeśli nie mogą w ten sposób uniknąć wykrycia. Z dużym prawdopodobieństwem możemy spodziewać się nowych rodzajów szkodliwych programów, które nie będą posiadały ciała, a następnie - implementacji technologii wirtualizacji.
   2. Zaciemnianie i szyfrowanie. Metoda ta będzie powszechnie stosowana do czasu, gdy będzie utrudniała analizę kodu.
   3. Technologie wykorzystywane do zwalczania rozwiązań bezpieczeństwa opartych na analizie zachowań. Można spodziewać się pojawienia się nowych technologii, ponieważ obecnie wykorzystywane (ukierunkowane ataki na programy antywirusowe) nie są skuteczne. Możliwe, że pojawią się metody wykrywania wirtualnych środowisk lub rodzaj szyfrowania behawioralnego.

Wniosek

Co można jeszcze dodać na zakończenie? Samo istnienie szkodliwych programów spowodowało powstanie i rozwój ochrony przed nimi. Teraz będziemy świadkami wyłonienia się i rozwoju autoochrony szkodliwego oprogramowania przed szkodliwymi programami. To z kolei grozi nigdy niekończącym się konfliktem, w którym nie natura, a technologia jest uzbrojona po zęby.

W ostatnich kilku latach sytuacja staje się coraz bardziej krytyczna. Ktoś z podziemia cyberprzestępczego (lub "badacze" ubrani w białe kapelusze) rozwija kod typu "proof of concept" w celu uniknięcia stosowanych obecnie środków ochrony. Osoba ta, w celu promowania siebie, ogłosi, że kod jest "niewykrywalny". Trzeba jednak podkreślić, że kod ten będzie niewykrywalny jedynie na poziomie jedno lub dwustopniowego obejścia znanych funkcji bezpieczeństwa, nie będzie jednak niewykrywalny w 100%. Stworzenie jednostopniowego obejścia jest stosunkowo proste, jeśli ktoś jest zaznajomiony z mechanizmami ochrony.

Informacje takie powodują zaniepokojenie wśród pewnej liczby użytkowników, którzy nie wiedzą, jak działają szkodliwe programy oraz programy antywirusowe ("Czy mój program antywirusowy ochroni mnie przed tym nowym typem zagrożenia?"). W takiej sytuacji osoby tworzące metody autoochrony muszą tylko wykorzystać część zasobów, aby odzyskać swoją reputację i rozwinąć obejście, zazwyczaj jednostopniowe. W końcu ich reputacja zostanie uratowana, a system: szkodliwe oprogramowanie - oprogramowanie antywirusowe - użytkownik powróci do stanu początkowego i znów będziemy mieli do czynienia z tym samym błędnym kołem. Każda nowa iteracja prowadzi do jeszcze bardziej zaawansowanego szkodliwego oprogramowania oraz silniejszych środków obrony.

Chciałabym podkreślić, że proces ten zużywa wiele zasobów, jest bezsensowny i nie ma końca. Wszystkie trzy strony w tym konflikcie muszą zwiększyć swoją świadomość sytuacji. Zachęcam użytkowników do poszerzenia wiedzy w tym zakresie, aby mogli przekonać się, że żaden środek ochrony nie gwarantuje 100% zabezpieczenia, a najlepsza metoda ochrony przed zagrożeniami to zapobieganie im. Namawiam osoby, które piszą wirusy, aby rozważyły swoje intencje oraz motywy, jakie kierują nimi podczas publikowania kodu "proof of concept", który tylko dolewa oliwy do ognia. Wzywam również osoby zajmujące się tworzeniem ochrony, aby starały się spojrzeć na problem z nowej strony i wyprzedzały wroga nie tylko o jeden krok. Być może nie ujrzymy szybko końca tego wyścigu zbrojeń, możemy jednak nie dopuścić do tego, aby wymknął się spod kontroli.

---

* Polimorfizm — technologia pozwalajÄ…ca samodzielnie rozmnażajÄ…cemu siÄ™ programowi na caÅ‚kowite lub częściowe zmodyfikowanie swojego wyglÄ…du zewnÄ™trznego i/lub struktury kodu podczas procesu replikacji.

* Zaciemnianie — poÅ‚Ä…czenie różnych podejść stosowanych w celu maskowania kodu źródÅ‚owego programu, tak aby jak najbardziej utrudnić czytanie go i analizowanie przy jednoczesnym zachowaniu jego peÅ‚nej funkcjonalnoÅ›ci. Technologie zaciemniania mogÄ… być stosowane na poziomie każdego jÄ™zyka programowania (Å‚Ä…cznie z jÄ™zykami wysokiego poziomu, jÄ™zykami skryptowymi i asemblera). PrzykÅ‚adem bardzo prostego zaciemniania jest dodawanie do kodu neutralnych instrukcji (które nie zmieniajÄ… funkcjonalnoÅ›ci programu) lub sprawianie, że kod jest trudniejszy do odczytania poprzez wykorzystanie nadmiernej iloÅ›ci przeskoków bezwarunkowych (lub bezwarunkowych przeÅ‚Ä…czeÅ„ pod postaciÄ… przeskoków warunkowych).

* Jest to odniesienie do kilku terminów stosowanych w żargonie bezpieczeństwa komputerowego:Czarny Kapelusz (złośliwy haker) oraz Biały Kapelusz (specjalista od zabezpieczeń wykorzystujący techniki hakerskie do legalnych, etycznych celów).

Źródło: Kaspersky Lab