Wstęp

Najnowszy raport firmy Kaspersky Lab na temat ewolucji złośliwego oprogramowania opisuje wydarzenia związane z bezpieczeństwem, jakie miały miejsce w pierwszym kwartale 2006 roku i prawdopodobnie wpłyną na przyszły rozwój złośliwego kodu i zagrożeń cybernetycznych. Raport przeznaczony jest dla specjalistów z dziedziny bezpieczeństwa IT oraz użytkowników zainteresowanych złośliwym kodem.

• Współczesny Cryptonomicon: nowe ofensywy, nowe defensywy
• Ataki na MacOS X
• PrzyszÅ‚ość wirusów (rootkity vmware, rootkity sektora startowego, backdoory bios)
• WieÅ›ci z frontu mobilnego

Współczesny Cryptonomicon: nowe ofensywy, nowe defensywy

Branża antywirusowa nieustannie Å›ledzi rozwój zÅ‚oÅ›liwego kodu. Autorzy wirusów i ich “twory”, ciężka artyleria w wojnie cybernetycznej, napotykajÄ… na swej drodze pancerz tworzony przez branżę antywirusowÄ…. Twórcy wirusów zawsze bÄ™dÄ… o krok wyprzedzali firmy antywirusowe, które mogÄ… tylko jak najszybciej reagować na nowe zagrożenia. Branża antywirusowa wykorzystuje wiele nowoczesnych technologii, takich jak ochrona proaktywna, analiza heurystyczna czy emulacja, które znacznie utrudniajÄ… stworzenie niewykrywalnego wirusa. Jednak niektóre z zagrożeÅ„ “przyszÅ‚oÅ›ci” pojawiajÄ… siÄ™ już teraz. Aby je zwalczać firmy antywirusowe bÄ™dÄ… musiaÅ‚y stworzyć nowe technologie.

Wielokrotnie pisaliśmy już o przypadkach, gdy cyberprzestępcy, zamiast wykorzystywać po cichu zainfekowane komputery użytkowników (kradnąc z nich hasła, wykorzystując je do tworzenie sieci maszyn zombie itd.), uciekają się do bezpośredniego szantażu, żądając od swoich ofiar okupu. Obecnie metoda ta realizowana jest na dwa sposoby: poprzez szyfrowanie danych użytkownika lub modyfikowanie informacji systemowych.

Użytkownicy szybko zauważają, że z ich danymi nie wszystko jest w porządku. Kontaktuje się z nimi szkodliwy użytkownik z żądaniem przelania określonej sumy na jego konto EGold, Webmoney albo inne. Wysokość okupu zależy od tego, jak zasobna w mniemaniu szantażysty jest jego ofiara. Znane są przypadki, gdy użytkownik miał zapłacić 50 dolarów, ale również takie, gdy szantażyści żądali ponad 2 tys. dolarów. Pierwszy taki przypadek szantażu miał miejsce w 1989 roku. Obecnie metoda ta zyskuje coraz większą popularność.

W 2005 roku najbardziej znanym przykładem tego typu cyberprzestępstwa były ataki przeprowadzone przy użyciu trojanów GpCode i Krotten. Pierwszy z nich szyfruje dane użytkownika; drugi modyfikuje rejestr systemowy komputera ofiary, co powoduje, że komputer przestaje działać.

Największą aktywnością wykazał się autor trojana GpCode - w zeszłym roku analitycy z firmy Kaspersky Lab wykryli ponad dwa tuziny różnych wariantów tego modułu szyfrującego pliki. Chociaż autor nieustannie zmieniał algorytm szyfrowania, analitycy z Kaspersky Lab zawsze potrafili go złamać, a następnie dodać do antywirusowych baz danych procedury wykrywania i deszyfrowania. Nie było potrzeby tworzenia specjalistycznych narzędzi.

Od 2006 roku autorzy podobnych programów próbowali radykalnie zmieniać wykorzystywane metody szyfrowania w celu utrudnienia branży antywirusowej deszyfrowanie danych. W styczniu pojawił się GpCode.ac, najnowszy wariant tego trojana.

GpCode.ac znacznie różnił się od swoich poprzedników, przede wszystkim tym, że wykorzystywał jeden z najbardziej znanych i bezpiecznych publicznych algorytmów szyfrowania - RSA. Wcześniej autor trojana wykorzystywał własne algorytmy szyfrowania, jednak w przypadku trojana GpCode.ac postanowił najwyraźniej wytoczyć ciężkie działo.

Jednak i tym razem analitycy z Kaspersky Lab triumfowali. Zdołali uzyskać kopię głównego pliku trojana odpowiedzialnego za szyfrowanie. W większości przypadków było to wcześniej niemożliwe, ponieważ trojan usuwa się z systemu, jak tylko dostarczy swoją szkodliwą funkcję. Kilka godzin analizy kodu doprowadziło analityków do klucza, który został użyty do zaszyfrowania danych. Jednak do złamania RSA niezbędny jest klucz deszyfrujący, który oczywiście nie został umieszczony w trojanie. Na szczęście, autor trojana popełnił poważny błąd - użył 56-bitowego klucza, który pod względem bezpieczeństwa jest zbyt krótki. Wykorzystując wiedzę o działaniu algorytmu RSA i obecnych metodach łamania takich algorytmów na współczesnych komputerach PC, nasi analitycy złamali klucz w przeciągu minut. Do antywirusowych baz danych dodaliśmy procedurę deszyfrowania pliku. Nie było potrzeby tworzenia osobnego narzędzia.

Jednak twórcy wirusów nie zamierzali się poddać. W marcu, wyciągając wnioski z nieudanych prób swoich poprzedników, ktoś (być może sam autor GpCode) wypuścił nowy program z klasy RansomWare (jest to nazwa, jaka pojawiła się na określenie podobnych trojanów w kilku artykułach opublikowanych przez branżę antywirusową oraz specjalistów z dziedziny bezpieczeństwa, patrz: http://en.wikipedia.org/wiki/Ransomware oraz http://www.halfbakery.com/idea/Computer_20ransomware).

Szkodliwi użytkownicy nie wykorzystują już algorytmów szyfrowania. Cryzip.a nie stosował RSA, AES ani PGP. Trojan ten skanuje komputer ofiary w poszukiwaniu dokumentów użytkownika, takich jak dokumenty MS Office, dokumenty w formacie PDF, pliki .zip, pliki graficzne i wiele innych. Każdy znaleziony plik umieszczany jest w osobnym, chronionym hasłem pliku ZIP.

Autor trojana Cryzip.a był tak uprzejmy, że powiadomił swoje ofiary, że hasło do pliku ZIP składa się z ponad 10 symboli, dlatego nie warto próbować łamać go za pomocą metody "brute force". Dostępne obecnie programy do łamania haseł do plików ZIP za pomocą "brute force" potrafią zdobyć hasło zawierające od 1 do 5 symboli w ciągu 5-10 minut. W przypadku hasła zawierającego 6-7 symboli, potrzeba znacznie więcej czasu i wysiłku.

Znalezienia hasła podjęło się jednocześnie kilka firm antywirusowych. Niektóre z nich zdołały uzyskać kopię pliku trojana, którego analiza pozwoliła na ustalenie hasła użytego do kompresji pliku. My jednak, nie posiadając pliku trojana, zastosowaliśmy metodę "brute force" - próbowaliśmy złamać hasło przy użyciu różnych znanych ataków kryptograficznych na archiwa ZIP. Dzięki temu udało nam się skrócić czas potrzebny na złamanie hasła tą metodą. Nie wdając się w szczegóły procesu możemy wyjawić, że zdołaliśmy otworzyć archiwum chronione hasłem w ciągu zaledwie jednego wieczoru.

Jako hasła autor trojana użył ścieżki katalogu: C:Program FilesMicrosoft Visual StudioVC98. Sądził najwidoczniej, że nawet jeśli firmy antywirusowe przechwycą trojana, analitycy uznają, że jest to typowy ciąg tworzony przez pliki napisane w języku Visual C++, a nie poszukiwane przez nich hasło.

W każdym razie problem z przywróceniem danych użytkownika został rozwiązany. Niestety, nie dało się ich przywrócić za pomocą oprogramowania antywirusowego. Jednak, znając hasło, użytkownik mógł przywrócić dane samodzielnie.

Warto wspomnieć o trzecim złośliwym programie wykazującym podobne zachowanie. Program ten - Skowor.b - w przeciwieństwie do swojej pierwszej wersji (robaka pocztowego) nie jest zdolny do rozprzestrzeniania się za pośrednictwem poczty elektronicznej. Skowor.b próbuje rozprzestrzeniać się poprzez tworzone przez siebie zasoby. Podobnie jak GpCode i Cryzip, po uruchomieniu szkodnik wyświetla komunikat dla użytkownika, informujący, że aby otrzymać hasło, za pomocą którego można usunąć robaka, użytkownik musi restartować system pięciokrotnie. Jeśli tego nie uczyni, robak będzie próbował zaszyfrować ważne pliki i zmienić hasło administratora oraz użytkownika na komputerze ofiary. Na szczęście, kod robaka zawiera wiele błędów, dlatego nie działa tak, jakby chciał tego jego autor.

Wszystkie incydenty, które miały miejsce w pierwszym kwartale 2006 roku, świadczą o tym, że szantaż cybernetyczny staje się jednym z najniebezpieczniejszych i najszybciej rozwijających się przestępstw cybernetycznych. W związku z tym, użytkownicy powinni zwracać szczególną uwagę na wykonywanie kopii zapasowych swoich danych. Chociaż do tej pory potrafiliśmy przywrócić zaszyfrowane dane, istnieje niebezpieczeństwo, że w przyszłości ktoś zastosuje lepszy algorytm szyfrowania lub technikę zip.

Nie możemy zapomnieć, że trojany nie rozprzestrzeniają się na komputery ofiary samodzielnie. Mogą zostać zainstalowane przez złośliwe oprogramowanie, które jest już obecne w systemie, lub przeniknąć przez luki w zabezpieczeniu przeglądarki. Jedynym sposobem ochrony przed trojanami jest regularne skanowanie systemu i wszystkich pobieranych plików przy użyciu oprogramowania antywirusowego, instalowanie łat, niezwłoczne aktualizowanie systemu operacyjnego, jak również wykonywanie kopii zapasowych wszystkich istotnych danych.

Jak postąpić w przypadku, gdy dane zostały już zaszyfrowane? Jak pokazują opisane wyżej incydenty, firmy antywirusowe potrafią pomóc w takich sytuacjach, dostarczając rozwiązanie w stosunkowo krótkim czasie. Użytkownicy nie powinni ulegać szantażystom, ponieważ spełnienie żądań twórców wirusów tylko zachęci ich pisania i rozprzestrzeniania nowych wariantów.

Ataki na Mac OS

Apple stał się w ostatnich latach niekwestionowanym liderem na rynku IT. Sensacyjne doniesienie o tym, że nowe wersje MacOS będą działały z procesorami Intel, spowodowało, że wiele osób ujrzało przyszłość tradycyjnych komputerów osobistych w zupełnie innym świetle. Do tego momentu komputery osobiste stanowiły pole walki pomiędzy platformami opartymi na Windowsie i Linuksie. Wiele osób czekało na możliwość wykorzystania systemu MacOS. Potencjalna popularność i stały wzrost liczby przyszłych wersji systemu MacOS przyciągnęły uwagę nie tylko użytkowników i specjalistów IT, ale również twórców wirusów i hakerów na całym świecie.

W tym miejscu nie będziemy wyliczać krytycznych luk, jakie zostały wykryte w systemie MacOS w ciągu ostatnich kilku miesięcy, ani podawać, jak szybko można włamać się do komputera z systemem MacOS podłączonego do Internetu. Zamierzamy trzymać się tematu tego artykułu, którym są wirusy komputerowe. Do niedawna MacOS X nie stanowił poważnego celu ataków twórców wirusów - istniało tylko kilka prostych koni trojańskich dla tego systemu, garstka exploitów i to wszystko.

Jednak luty 2006 roku przyniósł odpowiedź na pytanie, czy możliwe jest napisanie wirusa dla MacOS X. Początek całej historii miał miejsce na kilku forach i stronach użytkowników MacOS X, gdzie zaczął pojawiać się plik zip o nazwie "latestpics.tgz", który miał zawierać zrzuty ekranu z nieopublikowanej jeszcze najnowszej wersji OSX - wersji 10.5 lub Leopard.

W rzeczywistości plik ten zawierał robaka, który został później nazwany Leap. Szkodnik ten rozprzestrzeniał się poprzez IChat. Po przeniknięciu do komputera ofiary infekował aplikacje systemowe (jak klasyczny wirus) nie przestając rozprzestrzeniać się. Leap udowodnił, że OS X podatny jest na infekcje.

Zaledwie dwa dni po wykryciu robaka firmy antywirusowe otrzymały nową próbkę złośliwego programu atakującego OS X, kolejnego robaka, który został następnie nazwany Inqtana. W przeciwieństwie do robaka Leap, szkodnik ten nie infekował plików. Wcześniej podobny wektor infekcji wykorzystywały tylko mobilne złośliwe programy. Inqtana rozprzestrzeniał się poprzez Bluetooth, tak jak Cabir, prawdopodobnie najbardziej znany robak dla telefonów komórkowych. Jest to bardzo interesujący przykład symbiozy, gdzie technologie transmisji danych opracowane dla urządzeń przenośnych zostały następnie wykorzystane do infekowania standardowych komputerów.

Inqtana wykorzystywał lukę w zabezpieczeniu usługi Bluetooth File and Object Exchange (CAN-2005-1333) w OS X v10.4.1, Mac OS X Server v.10.4.1, Mac OS X v10.3.9 oraz Mac OS X Server v10.3.9. Luka ta została załatana przez firmę Apple w czerwcu 2005 roku. Jeśli atakowany komputer przyjął plik, robak próbował uzyskać dostęp do plików i folderów znajdujących się poza ścieżką systemową Bluetooth File and Object Exchange. Następnie Inqtana instalował się do systemu i automatycznie uruchamiał ciągłe skanowanie w poszukiwaniu nowych urządzeń w technologii Bluetooth.

Po kilku dniach udało się zidentyfikować autora robaka Inqtana, którym okazał się Kevin Finisterre, aktywny członek społeczności OSX. W wywiadach udzielonych niektórym mediom (na przykład http://www.securityfocus.com/columnists/389) wyjaśnił, że napisał szkodnika, żeby zwrócić uwagę (zarówno użytkowników jak i producentów) na kwestie bezpieczeństwa. Chciał w ten sposób wymusić tworzenie nowych, bezpieczniejszych rozwiązań.

Z naszego punktu widzenia, takie metody nie mogą być w żaden sposób usprawiedliwione. Z reguły nie prowadzą one do naprawienia problemów, za to dostarczają twórcom wirusów gotowy kod złośliwy. Takie niezależne badania ułatwiają również życie hakerom. Najbardziej niepokojące jest to, że stają się one coraz powszechniejsze. W pierwszym kwartale 2006 roku odnotowaliśmy kilka przypadków stworzenia i opublikowania - rzekomo dla celów naukowych - potencjalnych technologii wirusowych.

Przyszłość wirusów: rootkity vmware, rootkity sektora startowego, backdoory bios

Najbardziej interesującym wydarzeniem z dziedziny "teoretycznej wirusologii komputerowej" było stworzenie trzech programów typu Proof of Concept (PoC) - wyłącznie w celach naukowych. Jednakże wykorzystane technologie mogą stanowić poważne zagrożenie: podziemie komputerowe bez wątpienia zastanawia się, jak mogłoby je wykorzystać w przyszłości.

Pierwszą z tych technologii jest prototypowy backdoor, umieszczony w sektorze startowym, który przejmuje kontrolę przed startem systemu operacyjnego. Taki sposób ładowania się backdoora pozwala mu na modyfikowanie wielu funkcji systemowych. Backdoor ten został po raz pierwszy zaprezentowany opinii publicznej przez firmę eEye Digital Security w sierpniu 2005 roku.

Chociaż niemal wszystkie współczesne rozwiązania antywirusowe potrafią skanować sektor startowy dysków (historia wirusów i rozwiązań antywirusowych rozpoczęła się od wirusów sektora startowego), wciąż bardzo trudno jest wykryć przechwycenie lub zastąpienie funkcji systemowych. Nadal nie rozwiązano tego problemu w odniesieniu do trojana i oprogramowania antywirusowego w systemie operacyjnym, nie mówiąc już o sytuacji, gdy backdoor zostaje uruchomiony przed systemem operacyjnym.

Backdoor ten wzbudził ogromne zainteresowanie i zapoczątkował pojawienie się podobnych programów. W styczniu 2006 roku John Hesman, pracownik Next-Generation Security Software, poinformował, że funkcje Advanced Configuration and Power Interface pozwalały na stworzenie programów z funkcjonalnością rootkita, które mogły być zapisane w pamięci BIOS.

Wirusy, które zapisują się w pamięci BIOS, nie są niczym nowym. W 1998 roku pojawił się wirus CIH (Chernobyl), który czyścił pamięć BIOS, jeśli nie mógł uzyskać do niej dostępu. Wkrótce powstały programy trojańskie, które przeprowadzały podobne ataki. Hesman stworzył kod PoC, który pozwalał na zwiększenie przywilejów systemowych oraz odczytanie danych z pamięci komputera ofiary.

Po zapisaniu do pamięci BIOS złośliwy kod jest trudniejszy do wykrycia niż backdoor sektora startowego.

W marcu żywą dyskusję wywołała koncepcja niewykrywalnego rootkita wykorzystującego technologię maszyn wirtualnych. Czy jednak istniał rzeczywisty powód do niepokoju i czego tak naprawdę dotyczyła dyskusja?

Projekt stworzenia rootkita działającego na poziomie niższym niż system operacyjny powstał na University of Michigan i był sponsorowany przez firmę Microsoft. Szczegóły przedostały się do opinii publicznej po opublikowaniu programu konferencj iEE Symposium on Security and Privacy, który zawierał kod PoC tego rootkita.

Wszystkie złośliwe programy działają w tym samym środowisku co rozwiązania antywirusowe, co oznacza, że żadne z nich nie ma przewagi nad innym. Silniejszą pozycję będzie miało oprogramowanie działające na niższym poziomie w systemie. Badanie prowadzone w Michigan miało na celu przeniesienie złośliwego kodu poza środowisko systemu, przez co byłby w nim niewidoczny.

W tym celu pomiędzy systemem operacyjnym a sprzętem stworzono dodatkowy poziom - Virtual Machine Monitor (VMM). Podczas uruchamiania komputera kontrola przekazywana jest z BIOS-u do VMM z obejściem standardowej sekwencji ładowania właściwego systemu operacyjnego użytkownika. Innymi słowy, cała interakcja pomiędzy aplikacjami użytkownika a sprzętem będzie odbywała się poprzez VMM.

Oprócz uruchomienia systemu operacyjnego użytkownika, VMM uruchamia inny system operacyjny. W tym systemie operacyjnym mogą zostać uruchomione złośliwe programy. Oba systemy operacyjne mają tę samą podstawę - VMM - która bezpośrednio łączy się ze sprzętem.

Praktyczny przykład wykorzystania takiego rootkita: VMM przekazuje dane wprowadzane przez klawiaturę zarówno do systemu operacyjnego użytkownika jak i "złośliwego" systemu operacyjnego, gdzie są one przechwytywane i przesyłane do zdalnego szkodliwego użytkownika z obejściem systemu operacyjnego użytkownika i zainstalowanego rozwiązania antywirusowego. Zarówno kod rootkita, jak i wszystkie ślady jego obecności w systemie zlokalizowane są poza systemem operacyjnym użytkownika, dlatego nie mogą zostać wykryte w systemie operacyjnym, niezależnie od tego jak silne i skuteczne jest oprogramowanie antywirusowe i zapora ogniowa.

W celu stworzenia rootkita Proof of Concept dla Windows XP naukowcy wykorzystali kod źródłowy Virtual PC, gościnny złośliwy system operacyjny i zmodyfikowali niektóre sterowniki systemu operacyjnego użytkownika.

Pomimo pozornego zagrożenia ze strony tego rootkita uważamy, że nie ma potrzeby wywoływania alarmu. Po pierwsze, napisanie takiego rootkita jest trudne i chociaż wykorzystuje on gotowy silnik VMM, ogromna większość twórców wirusów nie posiada odpowiednich umiejętności.

Po drugie, nie można ukryć dodatkowego poziomu pomiędzy sprzętem a systemem operacyjnym, ponieważ obecność takiego poziomu będzie miała wpływ na funkcjonowanie zaatakowanego komputera:

• spowolni sekwencjÄ™ rozruchu
• spowoduje obciążenie procesora i spowolni dziaÅ‚anie systemu
• zmieni rozmiar dostÄ™pnego obszaru na dysku (rootkit wykorzystujÄ…cy maszynÄ™ wirtualnÄ… potrzebowaÅ‚ 100 - 200 MB)
• praca z plikami graficznymi bÄ™dzie utrudniona z powodu prymitywnej emulacji sterownika karty graficznej
• zmodyfikowane zostanÄ… pliki systemowe niezbÄ™dne do prawidÅ‚owego dziaÅ‚ania systemu operacyjnego z emulowanym (nieprawdziwym) sprzÄ™tem.

Po trzecie, wykrycie wirtualnego rootkita jest stosunkowo łatwe. Poza opisanymi wyżej symptomami, najprostszym sposobem na zidentyfikowanie takiego złośliwego kodu jest uruchomienie komputera z urządzenia zewnętrznego, a następnie przeskanowanie z niego dysku twardego. Jeśli rootkit wykorzystujący wirtualną maszynę będzie emulował ponowne uruchomienie systemu, co według naukowców miało miejsce podczas ich testów, a rootkit przejmie kontrolę i ukryje się, użytkownik będzie musiał tylko wyciągnąć wtyczkę z gniazdka.

SubVirt razem z BootRoot firmy eEye sygnalizują początek epoki, w której użytkownicy będą potrzebowali ochrony sprzętowej.

Oprócz kodów Proof of Concept, które mogą mieć decydujący wpływ na zagrożenia wirusowe w nadchodzących latach, nieustannie pojawiają się nowe wcielenia starych technologii, które zostały ulepszone i dostosowane do nowych okoliczności. Najbardziej widać to na przykładzie klasycznych infektorów plików - obecnie złośliwe programy tego typu modyfikowane są w taki sposób, aby mogły wprowadzać swój kod do innych programów.

W 2004 roku wykryto backdoora Backdoor.Win32.PoeBot. Szkodnik ten działa według następującego schematu: szkodliwy użytkownik konfiguruje znanego backdoora, w tym przypadku z rodziny Backdoor.Win32.SdBot, i przy użyciu technologii EPO (Entry Point Obscuring - ukrywanie punktu wejściowego) wstrzykuje go do popularnego programu, takiego jak WinRar. Program ten jest następnie rozprzestrzeniany w ten sam sposób co programy trojańskie. W rezultacie firmy antywirusowe będą wolniej reagowały na takie zagrożenie, gdyż wymagają one zlokalizowania złośliwego oprogramowania i wykluczenia możliwości fałszywych alarmów w stosunku do programu-nośnika (w tym przypadku WinRar), w przeciwnym razie legalne oprogramowanie będzie wykrywane jako złośliwe - niestety zdarza się to wielu firmom antywirusowym.

W 2005 roku pojawił się Virus.Win32.Bube. Ta rodzina wirusów-trojanów infekuje plik EXPLORER.EXE, a następnie kilka razy na godzinę próbuje pobrać inne programy trojańskie. Bube skutecznie przemienia EXPLORER.EXE w program Trojan-Downloader.

Po Bube pojawił się Virus.Win32.Nsag, Downloader działający w sposób jeszcze bardziej ukradkowy. Wirus infekuje bibliotekę systemową WININET.DLL, wstrzykując swój złośliwy kod do funkcji HttpSendRequestA. W ten sposób trojan przejmuje kontrolę nad aktywnością sieciową na komputerze ofiary.

Na początku 2006 roku pojawiło się kilka podobnych trojanów, co świadczy o tym, że podziemie komputerowe uważa takie programy za bardzo dochodowe.

Weźmy na początek trojana Trojan-Spy.Win32.Banker.alr. Program ten został stworzony w celu kradzieży informacji z komputera ofiary. Oprócz tego modyfikuje sfc.dll oraz sfc_os.dll w taki sposób, aby uniemożliwić przywrócenie plików systemowych. Podobne trojany pojawiają się dość często, dlatego analitycy Kaspersky Lab postanowili sklasyfikować nowe warianty jako osobną rodzinę.

Trojan.Win32.Patched.a

Trojan.Win32.Patched.a infekuje svchost.exe poprzez dodanie kodu, który załaduje plik o nazwie mshost.dll (Trojan-Spy.Win32.Agent.ki), a następnie uruchomi go w celu wykonania.

Trojan.Win32.Patched.b

Trojan.Win32.Patched.b infects a system file which has been chosen at random by adding code, which then launches the Trojan from an NTFS stream text file. The name of the text file is usually the same as that of the infected program. For instance, if the Trojan has infected the sysformat.exe file, the main Trojan component will be launched from the sysformat.txt stream. (C:WINDOWSsystem32sysformat.txt:tamrofsys.exe)

Trojan.Win32.Patched.b infekuje wybrany losowo plik systemowy poprzez dodanie kodu, który następnie uruchamia trojana ze strumienia NTFS pliku tekstowego. Nazwa tego pliku tekstowego zazwyczaj jest taka sama jak nazwa zainfekowanego programu. Jeżeli, na przykład, trojan zainfekował plik sysformat.exe, główny komponent trojana zostanie uruchomiony z sysformat.txt (C:WINDOWSsystem32sysformat.txt:tamrofsys.exe).

Trojan.Win32.Patched.c

Trojan.Win32.Patched.c infekuje wybrany losowo plik systemowy, na przykład notepad.exe. Dodaje on do pliku niewielki fragment kodu, co oznacza, że wraz z notepad.exe z folderu systemowego Windows uruchomiony zostaje plik .log.

Dlaczego trojany te działają w ten sposób i jakie będą przyszłe trendy?

Nie jest żadną tajemnicą, że programy antywirusowe i zapory ogniowe monitorują pewne obszary rejestru systemowego i aktywności sieciowej. Jednak, aby nie zakłócać pracy użytkownika, który zmienia konfigurację systemu, wszystkie rozwiązania służące zapewnieniu bezpieczeństwa posiadają listę wyjątków. W 2005 i 2006 roku mogliśmy się przekonać, że twórcy wirusów wykazują coraz większą inwencją w wykorzystywaniu niestandardowych metod w celu ominięcia i "wyprowadzenia w pole" aplikacji bezpieczeństwa. Metody te obejmują uruchomienie trojana nie poprzez klucz rejestru systemowego Run, ale poprzez aktywowanie zainfekowanego pliku systemowego oraz pobranie programu trojańskiego z pliku explorer.exe lub wininet.dll.

Wykrycie takich czynności jest stosunkowo trudne, poza tym firmy antywirusowe potrzebują dodatkowego czasu na stworzenie procedur wykrywania i leczenia zainfekowanych bibliotek systemowych.

W niedalekiej przyszłości mogą pojawić się złośliwe programy tworzone zgodnie z zasadą: skoro monitorowane są zmiany w konfiguracji modułów systemu operacyjnego, będziemy modyfikowali same moduły. Takie podejście od dawna stosują autorzy wirusów podczas tworzenia rootkitów dla Uniksa.

Wieści z frontu mobilnego

Z dnia na dzień zwiększa się zagrożenie ze strony mobilnych złośliwych programów. W 2005 roku trojany tworzone w celu infekowania urządzeń przenośnych pracujących pod kontrolą systemu Symbian stanowiły zaledwie strużkę; pod koniec roku ta strużka zmieniła się w strumyk. Obecnie analitycy Laboratorium Antywirusowego Kaspersky Lab każdego tygodnia dodają do antywirusowych baz danych do 10 nowych trojanów atakujących smartfony. Znaczna liczba tych trojanów jest pisana w Azji, w szczególności w Korei Południowej. Państwo to jest niewątpliwie liderem w tworzeniu wirusów dla telefonów komórkowych.

Wraz z nieustanną ewolucją technologii mobilnych następuje szybki rozwój złośliwego kodu.

W lutym pojawiły się dwa zupełnie nowe złośliwe programy. Pierwszy z nich został wykryty przez Kaspersky Lab, po tym jak jeden z użytkowników poinformował firmę, że ogromna liczba stron przeznaczonych dla użytkowników telefonów komórkowych rozprzestrzenia program o nazwie RedBrowser. Według autorów programu, RedBrowser miał umożliwić uzyskanie dostępu do stron WAP bez nawiązania połączenia internetowego. Było to możliwe poprzez wysłanie i otrzymanie SMS-a zawierającego kod strony.

Użytkownik musiał tylko pobrać program na swój telefon komórkowy. Program rzeczywiście wysyłał SMS-y, nie umożliwiał jednak połączenia z Internetem. Wiadomości wysyłane były na płatne numery, a koszt jednego SMS-a wynosił 5-6 dolarów amerykańskich.

W wyniku analizy okazało się, że trojan jest plikiem JAR napisanym dla J2ME, systemu operacyjnego wykorzystywanego przez większość współczesnych telefonów. Do niedawna sądzono, że stworzenie programu, który potrafiłby infekować większość telefonów jest niemożliwe. Wyobrażenia te zmienił RedBrowser. Trojan ten występował na wolności już od pewnego czasu i zdążył spowodować infekcje. Otrzymał nazwę Trojan-SMS.J2ME.RedBrowser.a, a wkrótce po pojawieniu się pierwszej wersji wykryto kolejną.

Pojawienie się złośliwego programu dla J2ME miało takie samo znaczenie jak pojawienie się pierwszego robaka dla smartfonów w 2004 roku. Wciąż trudno jest ocenić stopień tego zagrożenia; jednak możliwość infekowania standardowych telefonów oznacza, że firmy antywirusowe będą musiały rozpocząć prace nad rozwiązaniami antywirusowymi dla takich urządzeń. Istnieje ponadto niebezpieczeństwo, że podobne trojany wysyłające SMS-y na płatne numery zostaną stworzone także dla smartfonów z Symbianem.

Zwiększa się liczba smartfonów i urządzeń PDA z Windows Mobile. Do niedawna znane były tylko dwa złośliwe programy dla Windows Mobile/Pocket PC: wirus Duts oraz backdoor Brador. Jednak ich liczba znacznie wzrosła w lutym 2006 roku.

Cała historia zaczęła się od opublikowania przez organizację MARA (Mobile Antivirus Researchers Association) informacji prasowej o otrzymaniu wirusa od anonimowego autora. Był to kod typu Proof of Concept, który miał rzekomo infekować zarówno komputery PC działające pod kontrolą systemu Windows, jak i telefony z Windows Mobile. Wiadomość ta wzbudziła duże zainteresowanie zarówno mediów jak i branży antywirusowej, ponieważ wirusy dla Windows Mobile są rzadkością, a program ten posiadał pełną funkcjonalność wirusa wieloplatformowego.

Do organizacji MARA zgłosiły się zarówno media jak i firmy antywirusowe z prośbą o udostępnienie próbki do analizy w celu dodania sygnatury tego wirusa do antywirusowych baz danych. Wszystkie spotkały się jednak z taką samą odpowiedzią: najpierw należy wstąpić do MARA, ponieważ reguły organizacji zabraniają udostępniania próbek osobom nie będącym jej członkami.

Było to dość nieoczekiwane posunięcie. Od początku branża antywirusowa kierowała się pewnymi zasadami, do których należało również regularne wymienianie się próbkami z innymi firmami. W tym celu firma nie musi być członkiem innej organizacji. Dodatkowo, jeśli chodzi o wirusa typu Proof of Concept, firmy przekazują sobie próbki tak szybko jak to tylko możliwe, aby zapewnić ochronę maksymalnej liczbie użytkowników. Taka współpraca to standard. Firmy antywirusowe rywalizują ze sobą tylko w dziedzinie marketingu i usług.

Nic dziwnego, że firmy antywirusowe odmówiły wstąpienia do tak mało znanej organizacji - czy warto przydawać rozgłosu i wiarygodności takiej grupie z powodu jednego wirusa? Wątpliwości wzbudzali również niektórzy członkowie tej organizacji. MARA liczyła około 10 członków, z których większość nie była znana w branży antywirusowej, ponadto nie można było się z nimi skontaktować. Najbardziej znanym członkiem organizacji był dr Cyrus Peikari, autor książek na temat bezpieczeństwa oraz dyrektor generalny AirScanner, niewielkiej firmy tworzącej oprogramowanie antywirusowe dla telefonów komórkowych. Peikari stał się znany po opublikowaniu kodu źródłowego WinCE.Duts wraz z artykułem analitycznym, który stanowił swego rodzaju przewodnik dla twórców wirusów dla Windows Mobile. Najbardziej niepokojące było to, że współautorem tego artykułu był Ratter, członek grupy 29A, do której należą twórcy wirusów. To właśnie Ratter był autorem wirusa Duts i przekazał jego kod źródłowy Peikariniemu.

W wyniku niezaaprobowanej przez branżę antywirusową współpracy Peikariniego z twórcami wirusów ucierpiała zarówno jego własna reputacja jak i reputacja AirScanner.

Wirus wieloplatformowy, który otrzymał od organizacji MARA nazwę Crossover, wywołał mnóstwo wątpliwości. Nie było jasne, dlaczego firmy antywirusowe musiały wstąpić do MARA, aby otrzymać próbkę, podejrzenia rodziła również współpraca Peikariniego ze znanym twórcą wirusów. Inna niewyjaśniona kwestia dotyczyła wysłania wirusa do członka grupy MARA, a nie - tak jak zwykle ma to miejsce w przypadku wirusów Proof of Concept - do firmy antywirusowej.

Branża antywirusowa postanowiła zerwać kontakty z MARA. 8 marca 2006 roku Cyrus Peikari opublikował szczegółową analizę wirusa Crossover, łącznie z jego kodem. Powstał więc kolejny podręcznik pisania wirusów dla Windows Mobile. Nie podano żadnego współautora, a ze strony organizacji MARA usunięto listę członków.

Branży antywirusowej udało się w końcu uzyskać próbkę wirusa, któremu nadano nazwę Cxover.

Po uruchomieniu Cxover skanuje system operacyjny. Jeśli został uruchomiony na komputerze PC, wirus szuka dostępnych urządzeń przenośnych za pomocą ActiveSync, a następnie kopiuje się na nie. Po przeniknięciu do telefonu lub urządzenia PDA Cxover próbuje ponownie skopiować się do komputera PC. Potrafi również usuwać pliki użytkownika z urządzeń przenośnych.

Cxover udowodnił, że możliwe jest stworzenie wirusa, który będzie funkcjonował zarówno na komputerach osobistych, jak i na urządzeniach przenośnych. Jego kod źródłowy został opublikowany, wkrótce przekonamy się, jakie będą tego konsekwencje. Jedna rzecz jest pewna - wirusy takie nie pozostają już tylko w sferze teorii.

Źródło: Kaspersky Lab